/* Global Resetting */
html{
/* width: 100%; */
/* height: 100%; */
background-color: #99ccff;
padding: 5px;
}
/* The dev and test servers announce themselves with a loud yellow page
background, so nobody trying out a new feature there mistakes it for the
real site. Page.ss puts env-dev / env-test / env-live on from
SS_ENVIRONMENT_TYPE, which means this file is now identical on all three
servers - the colour used to be hand-swapped here at deployment time, and
was only ever right by accident. Anything not recognisably dev or test
keeps the production blue above. */
html.env-dev,
html.env-test {
background-color: #ffff66;
}
body {
/* width: 100%; */
/* height: 100%; */
font-size: 75%;
/* reset font-sizes to 1em == 12px */
}
* {
font-size: 1em;
/* reset font-sizes to 1em == 12px */
padding: 0;
margin: 0;
font-family:Verdana,Helvetica,sans-serif;
list-style:none;
}
a img{
border:0;
}
.clear{
clear:both;
}
/* Layout CSS */
body {
position: relative;
background-color:#99ccff;
min-width: 760px;
max-width: 1024px;
margin: auto auto;
border-style: solid;
border-width: thin;
}
a {
color: black;
text-decoration: none;
}
a img{
border:0;
}
#Header {
width:100%;
position: relative;
background-color:#99ccff;
}
#header_left {
position: absolute;
left: 0px;
}
#header_right {
position: absolute;
right: 0px;
}
#logo {
width: 100%;
margin: 0 auto;
text-align: center;
background-color: transparent;
}
#logo img {
position: relative;
}
#MainMenu {
width: 100%;
position: relative;
margin-bottom: 0px;
border-width: 0;
}
#MainMenu ul {
background-color: transparent;
width: 100%;
overflow: hidden;
}
#MainMenu li {
list-style: none;
padding: 2px 2px;
margin: 0 1px;
background-color: #99ccff;
border-style: solid;
border-width: thin thin 0;
border-radius: 7px 7px 0 0;
float: left;
}
#MainMenu li.current {
background-color:#e0f0ff;
border-style:solid;
border-width:thin thin 0px;
cursor:default;
}
#MainMenu li.section {
background-color:#b0d0ff;
/* border-style:solid;
border-width:thin thin 0px;
border-radius:50; */
cursor:default;
}
#MainMenu a {
color: black;
font-weight: bold;
text-decoration: none;
}
#MainMenu a:hover{
text-decoration:underline;
}
#admMenu {
padding-top: 1ex;
}
#admMenu ul {
padding-left: 1em;
}
#admMenu li {
list-style-type: disc;
}
#Sidebar {
float:right;
width:160px;
padding: 10px;
}
#Sidebar h1 {
font-size: 11pt;
font-weight: bold;
padding-bottom: 6pt;
}
#Sidebar dl {
padding-bottom: 6pt;
}
#Sidebar dt {
font-size: 8pt;
font-weight: bold;
font-style: italic;
}
#Sidebar dd {
font-size: 8pt;
font-weight: normal;
/* padding-left: 1em; */
padding-bottom: 0.5em;
}
div.turfakta {
padding-top: 8px;
border-top: 2px solid limegreen;
margin-top: 5px;
}
.turfakta p {
margin-bottom: 0pt;
padding-bottom: 0.5em;
}
.turfakta p span {
font-style: italic;
}
#Sidebar a {
color: black;
text-decoration: none;
}
#Sidebar a:hover {
color: blue;
text-decoration: underline;
}
#Sidebar li.current {
font-weight: bold;
}
#ContentContainer {
background-color: #e0f0ff; /* #b0d0ff; */
background-image: url(../images/sidebar_limegreen.png);
background-position: right top;
background-repeat: repeat-y;
}
/* overflow: hidden establishes a block formatting context, so #Content can
never let a child wider than the space left over from the floated
#Sidebar bleed past its own right edge - margin-right alone only sizes
#Content's own box, it does nothing to contain what's inside it. Normally
nothing is wide enough for that to matter, and #Content is tall enough
(a full listing) that any overflow would land below where #Sidebar's box
has already ended - but a "no matches" search (turer/sok or nyheter/sok)
is short, and rendered right over AdmMenu.ss's box without this. */
#Content {
padding: 1em;
margin-right: 180px;
min-height: 400px;
overflow: hidden;
}
#Content h1 {
padding-top: 1em;
font-weight: bold;
font-family: Arial,sans-serif;
font-size: 160%;
}
#Content h2 {
font-weight: bold;
font-family: Arial,sans-serif;
font-size: 120%;
}
#Content .pubdate {font-size: 80%;}
/* The three trip-search fields plus its button, side by side. wrap plus a
min-width, same as #LoginOptions below: on a narrow window the fields drop
into a stack instead of being squeezed to a width the year inputs cannot
render in. */
#eventSearchForm, #newsSearchForm {
display: flex;
flex-wrap: wrap;
gap: 1em;
align-items: flex-end;
margin-top: 1em;
}
/* #newsSearchForm sits above its listing rather than below it, so it needs
the separating space on the other side - otherwise the first news item
butts straight up against the submit button. #eventSearchForm is still
the last thing on its page and needs no such rule. */
#newsSearchForm {
margin-bottom: 1.5em;
}
#eventSearchForm .field, #newsSearchForm .field {
display: flex;
flex-direction: column;
min-width: 8em;
}
#eventSearchForm input[type="number"], #newsSearchForm input[type="number"] {
width: 5em;
}
/* Otherwise this falls back to the browser's native default text-input
width, which is wider than the year fields' 5em and, combined with them,
is what pushed the row past #Content's available width at the page's
enforced 760px minimum. */
#eventSearchForm input[type="text"], #newsSearchForm input[type="text"] {
width: 16em;
}
/* The two ways in, side by side: email and password on the left, "Logg inn med
en annen konto" to the right of it.
Stacked - which is what the framework's tabbed form set gives you once a
second authenticator is installed - the OAuth form falls below the fold on a
short window, so somebody who has only ever signed in with Google is shown a
password field they have no password for and no visible alternative.
wrap plus a min-width is what makes that safe on a narrow window: the
columns drop back into a stack rather than being squeezed to a width the
inputs cannot render in. The order is document order, which is the order the
authenticators are registered in - see LoginPagePresentationTest, which
asserts it rather than trusting it. */
#LoginOptions {
display: flex;
flex-wrap: wrap;
gap: 2em;
align-items: flex-start;
}
#LoginOptions .form-tab {
flex: 1 1 20em;
min-width: 20em;
}
/* The notice shown to a visitor turned away from a gated server.
Set 50% larger than the body text around it: it is the only thing on that
page worth reading - the visitor did not come for the login form, they came
for a page they were refused - and at body size it reads as a caption under
the heading.
Scoped to its own class rather than to the "p.message" the framework wraps
it in, which is shared with form validation errors and every other Security
message. PageController::gateNotice() is what puts the span there.
**Qualified with .typography, and that is not decoration.** typography.css
carries ".typography *{ font-size:1em }", which is specificity (0,1,0) -
exactly the same as a bare ".gate-notice" - and that file is required after
this one, so on a tie it wins on source order. A plain ".gate-notice" rule
was silently overridden from 2026-08-13 until it was measured: the notice
computed to 13.2px, the identical size as the "Jeg har mistet passordet" and
"Registrer ny bruker" links beside it. ".typography .gate-notice" is (0,2,0)
and wins regardless of which file loads first.
The unqualified selector is kept alongside for any context outside
.typography, where nothing competes and (0,1,0) is enough. */
.gate-notice,
.typography .gate-notice {
display: block;
font-size: 1.5em;
}
/* A refused login, or any other form message the framework types as "bad".
FiOLoginForm.ss is what moves it down beside the button; this is what makes
it look like a refusal rather than a caption. Reported from testing
2026-08-14 as "should be made more visible (bold or red)" - it is both,
because the two carry different things: the weight separates it from the
field labels around it, the colour says which way the answer went.
Qualified with .typography for the same reason as .gate-notice directly
above, and the qualification is load-bearing for the same rule: typography
.css carries ".typography * { font-size: 1em }" and is required after this
file. Nothing here sets a font-size, so only the margin would have been at
risk today - but the next person to want this bigger would hit exactly the
wall .gate-notice hit.
Deliberately not .message on its own. That class is on every form message
the framework emits, "good" ones included, so styling it as an error would
turn "kontoen er bekreftet" red. */
.message.bad,
.typography .message.bad {
font-weight: bold;
color: #c00000;
margin-top: 0.5em;
}
.picture.left {
float: left;
margin-right: 10px;
}
.picture.right {
float: right;
margin-left: 10px;
}
.picture.centered {
display: block;
margin-left: auto;
margin-right: auto;
}
.picture div {
padding: 5px;
margin: 0px auto;
background: #eee;
font-size: 80%;
}
.picture.unpublished div {
background: yellow;
}
.picture div p {
margin-bottom: 0px;
text-align: left;
}
#Form_photoForm_Position li {
list-style: none;
float: left;
}
tr.upublisert {
background: #ff4;
font-style: italic;
/* display: none; */
display: table-row;
}
tr.publisert {
/* display: table-row; */
}
div.newsItem {
float: left;
width: 100%;
border-bottom: 2px solid limegreen;
}
div.thumbnail {
float: right;
border: 2px solid lightgray;
margin: 5px;
}
dt.newsHeading {
font-weight: bold;
}
dt.newsHeading a {
color: black;
text-decoration: none;
}
dd.newsSummary {
padding-bottom: 5px;
border-bottom: 2px solid limegreen;
margin-bottom: 5px;
}
.turoversikt thead th {
border-style: solid;
border-width: 0 0 thin;
}
.turoversikt tfoot th {
border-style: solid;
border-width: thin 0 0;
}
iframe {
width: 100%;
height: 600px;
}
.footer {
clear: both;
background-color: limegreen;
font-size: 80%;
color: black;
text-decoration: none;
padding: 2pt;
}