html {
position: fixed;
font-size: 16px;
font-family: 'Roboto', Arial, sans-serif;
height: 100dvh;
width: 100dvw;
overflow-x: hidden;
overflow-y: hidden;
margin: 0px;
padding: 0px;
}
/*
All three layers of the backdrop live here, on ONE element, so they paint
in the same frame.
The vignette used to be a background on .radial_background - a div inside
Home.razor - while the colour wash was here. With prerender:false that div
does not exist until the circuit connects, so the wash painted from the
static HTML immediately and the vignette dropped on top of it a moment
later. Two paints, visibly.
Layer order is first-on-top: vignette over the blue and violet washes,
over the base colour.
*/
body {
position: fixed;
background: radial-gradient(circle at center, rgba(0, 0, 0, 0) 66%, rgba(0, 0, 0, 0.12) 80%, rgba(0, 0, 0, 1)), radial-gradient(circle at 20% 20%, #1e40af 0%, transparent 45%), radial-gradient(circle at 80% 80%, #7c3aed 0%, transparent 45%), #050816;
height: 100dvh;
width: 100dvw;
overflow-x: hidden;
overflow-y: hidden;
margin: 0px;
padding: 0px;
}
/*
.btn-link is Bootstrap's, and nothing in this project applies it yet. It
is listed here so a link-styled button matches a real link the day one is
written, which is the same bet the validation rules at the bottom make.
*/
a, a:link, .btn-link {
color: white;
text-decoration: underline;
text-decoration-color: rgba(255,204,102,0.5);
text-decoration-thickness: 2px;
text-shadow: 0px 0px 2px rgba(0,0,0,0.7);
transition: all 0.2s ease;
}
a:hover, .btn-link:hover {
cursor: pointer;
text-decoration-color: rgba(255,204,102,1);
}
/*
=====================================================================
THE GOLD AURA - the standing signal that a thing can be pressed.
BUILT AND ACCEPTED 2026-08-28. It began as a trial - the user asked to
live with it before committing - and every value it replaced is still
kept verbatim in a "Before:" comment beside its replacement. Those are
HISTORY now rather than revert instructions, and they are worth keeping:
each one answers "why is this number what it is", and most of them were
arrived at by being wrong first. See the tuning history in CLAUDE.md
under "The gold aura is the clickable affordance".
THIS FILE IS THE ONLY PLACE THE VALUES LIVE. Five other files consume
them and none restates one: WindowFrame.razor.css (.window_button,
.close_button, .window_content), WindowLauncher.razor.css
(.launch_button), MinimizedWindowGroupList.razor.css
(.window_drawer_entry), SettingsMenu.razor.css (.settings_entry) and
Toolbar/ToolbarItem.razor, which changed variant when .btn-primary
changed meaning. Tuning the interface's buttons is one edit here.
WHAT IT IS. A soft gold glow at rest, brightening on hover, with the
border going gold while the control is held down. It is what the window
chrome has always worn - .window_button in WindowFrame.razor.css,
.launch_button in WindowLauncher.razor.css, .window_drawer_entry in
MinimizedWindowGroupList.razor.css - and the whole value of it is that
it is the SAME signal everywhere, so "this responds to a press" is
learned once rather than per screen.
EVERY CONSUMER READS THESE TOKENS, AND NOTHING RESTATES THEM. There is
one aura in this application at one set of numbers:
.window_button WindowFrame.razor.css
.launch_button WindowLauncher.razor.css
.window_drawer_entry MinimizedWindowGroupList.razor.css
.btn here, and therefore every button in the app
.settings_entry SettingsMenu.razor.css
THAT ENDED A DRIFT THAT WAS ALREADY THERE, which is the whole argument
for tokens. The three chrome components each spelled their glow out, and
by the time anyone compared them they no longer agreed: the launcher sat
at 3px blur / 3px spread and did NOT grow on hover, while the other two
sat at 2px/2px and grew to 5px. Nobody decided that - it is what three
copies of one value do. Tuning the aura is now a single edit here, and
no consumer can be left behind.
TWO BEHAVIOURS CHANGED when the chrome was folded in on 2026-08-28, and
both are the point rather than a side effect. The launcher's glow now
GROWS on hover like everything else. And all three chrome controls
answer a plain :active where they used to want :hover:active, which can
only ever match a mouse - so a keyboard Space or Enter now gets the same
acknowledgement a click does, where before it got nothing.
WHAT IS DELIBERATELY *NOT* WEARING IT: Components/UI/CheckBox, which is
a stripped of border and background on purpose ("a control the
user reads, not a call to action competing with Submit") - an aura needs
a rim to sit outside of, and a glowing rectangle around a line of text
is not that. Nor .launcher_view_button and .launcher_tile, which live
inside the launcher menu: a grid of tiles each carrying a glow is the
haze this was just tuned away from, and .launcher_view_active already
spends a gold border on "this is the view you are in", which would
collide with the aura's "held down".
The hue is carried as bare channels so one number governs every alpha.
=====================================================================
*/
:root {
--aura-hue: 255, 204, 102;
/*
THE DARK RIM THE GLOW SITS OUTSIDE OF, and it is what makes the aura
read as an aura. A box-shadow is painted immediately outside the
border box, so with nothing separating the control's own fill from
the glow the two blend and it looks like a fuzzy edge rather than a
halo around a defined object. All three chrome controls have carried
this from the beginning - .window_button, .launch_button and
.window_drawer_entry are each 1px solid black - and leaving it off
the application's own buttons is exactly what looked wrong.
1px is not a token: Bootstrap's --bs-btn-border-width is already 1px
and so is every chrome control, so there is nothing to reconcile.
*/
--aura-border: black;
/*
THE GEOMETRY, AND HOW IT ARRIVED HERE. The two numbers do different
jobs and reaching for the wrong one is how "too strong" gets answered
by making the glow blurrier instead of smaller:
SPREAD is the solid extent of the glow. It is what makes an aura
feel heavy, and it is the first dial to turn.
BLUR only decides how softly that edge ends.
Both came down on 2026-08-28, in two passes, after the user reported
the aura was "a bit too strong" once it was on everything. The
original figures were the chrome's own, chosen for a handful of 26px
pills spaced along a titlebar and a drawer; a screenful of full-width
buttons and cards is a different picture, because the glows are no
longer isolated from one another and what reads as a highlight on one
control reads as haze over a form.
was 2px blur / 2px spread, into 5px / 2px on hover
then spread down one: 2px/1px into 5px/1px
now hover blur down one: as below
Visible glow is roughly spread + blur/2, so rest went from about 3px
to 2px, and hover from about 4.5px to 3px.
IF IT IS STILL TOO STRONG the next dial is the rest alpha, 0.5 ->
0.35. Size before colour: the hue is what ties this to the rest of
the interface and should be the last thing to move.
*/
/* At rest: present but quiet, so a screenful of controls does not glare. */
--aura-rest: rgba(var(--aura-hue), 0.5) 0 0 2px 1px;
/* Hover: full strength and a wider blur. Brightness AND size, because
a change in only one of them is easy to miss on a small control.
The RIM STAYS BLACK through hover - the chrome only ever swaps it on
:active, so brightening it here would be a second signal saying the
same thing and would leave nothing left to say for the press. */
--aura-hover: rgba(var(--aura-hue), 1) 0 0 4px 1px;
/* Held down: the rim itself goes gold - the one part of a press that is
a hard edge rather than a glow. Named as the pair of --aura-border
rather than as an "edge", because two tokens a shade apart in meaning
and a shade apart in name is how the wrong one gets used. */
--aura-border-active: rgba(var(--aura-hue), 1);
/* Keyboard focus, matching what CheckBox, SettingsMenu and
TermsAgreement already draw. A solid ring OUTSIDE the glow rather
than simply a brighter glow, because focus has to be tellable apart
from hover and one diffuse shadow is not tellable from another. */
--aura-focus-ring: 2px solid rgba(var(--aura-hue), 0.9);
--aura-focus-offset: 2px;
/*
THE INSET OFFSET, for a control with no room OUTSIDE itself. A ring
at the positive offset above is drawn 4px beyond the border box
(2px offset + 2px width), which is fine for a button sitting in a
strip that clips generously - and wrong for an element that fills its
container, because whatever clips that container cuts the ring off
and the focus indicator simply vanishes. .window_content is the case:
it fills the window body, and .window_container is overflow: hidden.
Kept beside its positive twin, and the two are a PAIR: this is the
negative of the ring's own width, so changing that width means
changing both.
*/
--aura-focus-inset: -2px;
}
/*
=====================================================================
THE BUTTON SURFACE - what a button is MADE of, as opposed to what the
aura says about it.
ADDED 2026-08-28, when the aura had been on every button for a day and
the thing underneath it was still Bootstrap's. The report was the
DataGrid sample: its paginator arrows and every column filter are
`.btn-secondary`, so a window full of chrome had a row of flat #6c757d
grey slabs across the bottom of it. Bootstrap's palette is a different
product's, and no amount of gold around the outside fixes a grey fill.
THE ANSWER IS THE CHROME'S OWN SURFACE, because it already existed and
already worked: a translucent dark pill on the backdrop, a black rim,
and the aura outside that. .window_button has been drawn that way from
the beginning and .window_drawer_entry copied it; these tokens are now
the single source for all three plus every .btn.
TRANSLUCENT RATHER THAN A FLAT COLOUR IS THE WHOLE POINT. The backdrop
is a radial wash of blue and violet over near-black, so a button that
lets it through sits IN the page, while an opaque grey sits on top of
it. That is the difference being complained about, and it is why the
value is an rgba and not a hex.
=====================================================================
*/
:root {
/*
.window_button's own fill, now shared. Dark enough to carry white
text at any point on the backdrop, transparent enough that the wash
still reads through it.
*/
--button-bg: rgba(64, 64, 64, 0.5);
/*
THE DEFAULT ACTION - lighter AND less translucent, which is two dials
moving together on purpose: over a near-black backdrop the base fill
composites to about rgb(34,34,34) and this to about rgb(68,68,68), so
it reads as a more solid object rather than merely a paler one.
WHAT EARNS IT: being the button ENTER presses, and there is at most
one of those in a section. That is Section's own Submit, which is the
only `type="submit"` in the application; the Complete windows and
TermsAgreement carry .btn-primary on the single action their window
exists to offer, which is the same idea in a section that is not a
form. Everything else - the Forgot pair, "I Do Not Agree", Resend
Code, and every DataGrid paginator and filter toggle - is
.btn-secondary and stays at --button-bg.
SO .btn-primary NOW MEANS SOMETHING ENFORCEABLE BY READING: one per
section. A second one in the same section is a bug, not a style
choice, because two buttons cannot both be what Enter does.
Tuning: raise the alpha for "more solid", raise the grey for
"brighter". They are independent and both are legible on this
backdrop up to about rgba(128,128,128,0.8) before it stops reading as
the same family of button.
*/
--button-bg-primary: rgba(96, 96, 96, 0.7);
/*
DESTRUCTIVE, and it is .close_button's fill rather than a new
colour. The chrome already had to answer "how does a button say
this one is different" and answered it with a red tint at the same
alpha, which is why Close does not look like a fifth titlebar
button. .btn-danger gets the same, so "Sign out everywhere else"
keeps saying what it does.
*/
--button-bg-danger: rgba(255, 0, 0, 0.5);
/*
White rather than --bs-body-color. The fill is translucent dark
whatever the theme says, so the text on it has to be light - and
.btn's default is --bs-body-color, which on a light theme would be
near-black on a dark pill.
*/
--button-color: #fff;
/*
10px, which is .window_button's and .window_drawer_entry's. It also
overrides .btn-sm's smaller radius, deliberately: a small button is
still the same kind of object.
*/
--button-radius: 10px;
}
/*
Bootstrap's .btn, which is what every button in this application wears:
Section's Submit, every Return, Login's two Forgot buttons, the consent
dialog's pair, DataGrid's paging arrows and filter toggles, and User
Sessions' three sign-out buttons.
HERE RATHER THAN IN A COMPONENT, for the same reason .btn-link above is
here - the class is somebody else's and a dozen components wear it, so a
rule in any one .razor.css would be scoped to that component's own
markup and silently miss the rest.
.btn-link IS EXCLUDED THROUGHOUT. It is styled as a link a few rules up
- white text with a gold underline - and a link wearing a button's glow
would be claiming to be both at once. Nothing applies it yet; the
exclusion is written now so that the day something does, it still reads
as a link.
ORDERING AND SPECIFICITY ARE LOAD-BEARING, and both were read off the
vendored Bootstrap 5.3.3 rather than assumed:
- app.css loads AFTER bootstrap.min.css (App.razor), so a tie on
specificity is broken in our favour. Do not reorder those two links.
- The ONLY box-shadow Bootstrap puts on a button is
`var(--bs-btn-focus-box-shadow)`, and it declares that variable on
.btn at (0,1,0). Redefining it at (0,2,0) turns every focus path it
has - including the .btn-check ones nothing here uses yet - gold,
without a rule of ours per selector.
- :hover, :active and :focus-visible are written at (0,3,0) so they beat
Bootstrap's `.btn:first-child:active` (0,3,0, earlier) and
`.btn:focus-visible` (0,2,0).
- The disabled rule is LAST on purpose: it ties with :hover on
specificity, and a tie is broken by source order.
No transition is declared. Bootstrap's own already names box-shadow
among the four properties it animates - and nothing here should reach
for `all`, which is the rule the launcher's tiles record the hard way.
*/
.btn:not(.btn-link) {
box-shadow: var(--aura-rest);
--bs-btn-focus-box-shadow: var(--aura-hover);
/*
THE RIM IS SET THROUGH BOOTSTRAP'S OWN VARIABLES, NOT AS A
border-color OF OURS, and that is what keeps this to four lines.
Bootstrap paints a button's border from --bs-btn-border-color and
swaps it for the hover, active and disabled ones across half a dozen
selectors, several of them at (0,3,0) - `.btn:first-child:active`,
`:not(.btn-check) + .btn:active`, `.btn.active`, `.btn.show`.
Overriding the VALUES means every one of those paths paints the rim
we want, with no rule of ours per selector and no specificity to
lose. It is the same move the focus box-shadow above makes.
The variants declare these at (0,1,0) - .btn-secondary and friends -
so this rule at (0,2,0) beats all of them.
ONE FAMILY THIS WOULD BE WRONG FOR: .btn-outline-*, whose whole
design is a transparent fill with a COLOURED border. Nothing in this
application uses one, so the selector is left readable rather than
carrying an exclusion for a case that does not exist; if an outline
button is ever added, exclude it here rather than fighting it there.
*/
--bs-btn-border-color: var(--aura-border);
--bs-btn-hover-border-color: var(--aura-border);
--bs-btn-disabled-border-color: var(--aura-border);
--bs-btn-active-border-color: var(--aura-border-active);
/*
THE FILL DOES NOT MOVE - NOT ON HOVER, NOT ON PRESS (2026-08-28, on
the user's report that the background shifting under the cursor was
not wanted).
Bootstrap darkens a button twice as you use it: .btn:hover paints
--bs-btn-hover-bg and the active selectors paint --bs-btn-active-bg,
so .btn-primary walks #0d6efd -> #0b5ed7 -> #0a58ca. None of the
chrome does that. .window_button, .launch_button and
.window_drawer_entry hold one background for their whole life and
say everything through the aura: the glow brightens on hover, the
rim goes gold on press. Two signals for one state is one more than
the interface needs, and it is the fill - not the glow - that reads
as the button itself changing.
Pointing each at its own resting value is what neutralises it, and
it is deliberately NOT `transparent`: --bs-btn-bg resolves per
variant, so .btn-primary keeps its blue and .btn-danger its red.
Bootstrap's :focus-visible also paints --bs-btn-hover-bg, so that
path is covered by the same line.
The COLOUR pair goes with them for completeness. It changes nothing
today - every variant in use has --bs-btn-color and
--bs-btn-hover-color both #fff - but a variant where they differ
would reintroduce exactly the flicker this removes.
Before: none of these six lines existed; Bootstrap's own hover and
active backgrounds applied.
*/
--bs-btn-hover-bg: var(--bs-btn-bg);
--bs-btn-active-bg: var(--bs-btn-bg);
--bs-btn-hover-color: var(--bs-btn-color);
--bs-btn-active-color: var(--bs-btn-color);
/*
AND THE SURFACE ITSELF - see "THE BUTTON SURFACE" above for why.
This is what makes .btn-primary, .btn-secondary and .btn-sm stop
being Bootstrap's blue, grey and small-radius and start being this
product's one button. The markup does not change: every button in
the application already carries .btn, and the variant class beside
it now decides nothing except whether it is destructive.
The variants declare all five at (0,1,0), so this rule at (0,2,0)
beats every one of them. The hover and active pairs above resolve
through --bs-btn-bg, so they follow this automatically rather than
needing their own values.
*/
--bs-btn-bg: var(--button-bg);
--bs-btn-color: var(--button-color);
--bs-btn-disabled-bg: var(--button-bg);
--bs-btn-disabled-color: var(--button-color);
--bs-btn-border-radius: var(--button-radius);
}
/*
THE DEFAULT ACTION. See --button-bg-primary for what earns this and why
there is at most one per section: it is the button Enter presses.
Fill only. The rim, the radius, the aura and all three of its states are
the same as every other button's - being the default action is a matter
of weight, not of being a different kind of control, and giving it a
louder aura as well would spend the one signal that means "pressable" on
something else.
(0,2,0), the same as .btn:not(.btn-link) above, so it wins by being
later - and it is mutually exclusive with .btn-danger below in practice,
so the order of those two relative to each other does not matter.
*/
.btn-primary:not(.btn-link) {
--bs-btn-bg: var(--button-bg-primary);
--bs-btn-disabled-bg: var(--button-bg-primary);
}
/*
THE ONE VARIANT THAT STILL MEANS SOMETHING BEYOND WEIGHT. Primary above
is louder; this one is a different STATEMENT. Flattening it would be the
one place this change could do harm - "Sign out everywhere else" is the
only button in the application that ends something the user cannot get
back.
A TINT AT THE SAME ALPHA, not a different kind of button: black rim,
same aura, same radius, same translucency. Exactly what .close_button
does in the titlebar, and for the same reason.
After .btn:not(.btn-link) rather than before it - the two selectors are
both (0,2,0), so this only wins by being later. --bs-btn-hover-bg and
--bs-btn-active-bg are declared up there as var(--bs-btn-bg), and custom
properties resolve per element, so they pick this value up on a danger
button without being restated.
*/
.btn-danger:not(.btn-link) {
--bs-btn-bg: var(--button-bg-danger);
--bs-btn-disabled-bg: var(--button-bg-danger);
}
.btn:not(.btn-link):hover {
box-shadow: var(--aura-hover);
}
/*
The rim on :active is already handled by --bs-btn-active-border-color
above; this restates it as a CATCH-ALL, because Bootstrap's active
selectors are `.btn:first-child:active` and `:not(.btn-check) + .btn:active`
and neither reaches a button that is neither the first child nor preceded
by an element sibling. Cheap insurance against a markup shape nobody
thought about, and it is the rule that carries the box-shadow anyway.
*/
.btn:not(.btn-link):active {
border-color: var(--aura-border-active);
box-shadow: var(--aura-hover);
}
.btn:not(.btn-link):focus-visible {
box-shadow: var(--aura-hover);
/* Bootstrap sets `outline: 0` on this selector; this puts one back. */
outline: var(--aura-focus-ring);
outline-offset: var(--aura-focus-offset);
}
/*
NO AURA ON A BUTTON THAT CANNOT BE PRESSED, and that is not tidiness.
The aura's whole meaning is "this responds to a press", so a disabled
button wearing it is an invitation the button then refuses - and that is
the common case rather than a rare one: Section keeps its Submit
disabled until the form validates, so every half-filled form in the
application would be glowing at a control that does nothing. Sessions
disables its row buttons the same way while a revoke is in flight.
Bootstrap already sets pointer-events: none on a disabled button, so
:hover cannot fire on one either; this covers the rest state, and being
last covers the tie with :hover if that ever changes.
*/
.btn:not(.btn-link):disabled,
.btn:not(.btn-link).disabled {
box-shadow: none;
}
/*
TEXT INPUTS, so a form does not sit there glowing Bootstrap blue in a
gold interface (2026-08-28). This was the last blue left in the
application: `.form-control:focus` painted a `#86b7fe` border and a
`0 0 0 .25rem rgba(13,110,253,.25)` ring, which is Bootstrap's accent and
not this product's.
A LIKE-FOR-LIKE SWAP RATHER THAN THE BUTTON TREATMENT. Bootstrap says
focus with a border colour plus a ring; this says the same two things in
gold. The buttons' AURA is deliberately not applied - the aura means
"this responds to a press", and an input is typed into rather than
pressed, so it would be claiming the wrong thing. What it does share is
the ring itself, which is the one focus indicator every control in this
application now draws: CheckBox, TermsAgreement's scroller, the Settings
cards, every .btn and all three chrome controls.
`:focus` RATHER THAN `:focus-visible`, matching Bootstrap and correct for
a text field: a caret placed with the mouse still has to be findable, so
this is one of the few cases where a mouse focus should show a ring.
Bootstrap's own literals are hardcoded rather than variables here, so
unlike .btn this cannot be done by redefining a --bs-* value; it takes a
real rule. (0,2,0) ties with `.form-control:focus`, and app.css loads
after bootstrap.min.css, so the tie breaks our way. box-shadow: none is
what removes the blue ring.
.form-select is included ahead of a caller for the reason .btn-link above
is: nothing renders one yet - the tenant and portal dropdowns planned for
registration would be the first - and having it here means the first one
written matches everything around it. .form-check-input is deliberately
NOT included: this project uses Components/UI/CheckBox instead, which
draws its own ring already.
NOTE ON .invalid: app.css gives an invalid field a red outline, and that
outline is suppressed while the field has focus - by Bootstrap's
`outline: 0` before this change and by the ring after it, identically,
since (0,2,0) beats (0,1,0) either way. So this is not a regression, and
the ValidationMessage below the field is what carries the error while
somebody is typing in it.
*/
.form-control:focus,
.form-select:focus {
border-color: var(--aura-border-active);
outline: var(--aura-focus-ring);
outline-offset: var(--aura-focus-offset);
box-shadow: none;
}
/*
=====================================================================
End of the gold aura section.
=====================================================================
*/
ul {
list-style-position: inside;
}
/*
Drawer menus - the launcher's and the minimized-group ones - sit above
the drawer scrim, which is itself above the window popup layer (1000).
Bootstrap's own .dropdown-menu z-index is 1000, which would leave a menu
blurred underneath the very scrim it raised.
Global rather than in either component's stylesheet: the class is applied
by two different components, and CSS isolation would scope a rule in
either of them to that component's own markup only.
*/
.window_drawer_menu {
z-index: 1600;
}
/*
Global for the same reason .window_drawer_menu is: the class is worn by
both the launcher's dropdown and the minimized-group ones, and a rule in
either component's stylesheet would be scoped to that component's own
markup and miss the other.
*/
.menu {
/*
The menu's lift, in three layers, held in a variable so a variant can
ADD to it rather than restate it - .window_group_menu does exactly
that, and before this it silently replaced the lot.
1. a large soft drop, which is what puts the menu above the page
2. a tight ambient ring, so the edge does not dissolve into a dark
backdrop - the drawer scrim blurs everything behind an open menu
3. an inset 1px catch light along the top, the glass edge
*/
--menu-shadow: 0 40px 120px rgba(0,0,0,0.55), 0 0 8px 4px rgba(0,0,0,0.5), inset 0 1px 0 rgba(255,255,255,0.12);
position: absolute;
border-radius: 10px;
border: 1px solid rgba(0,0,0,.25);
background-color: rgba(64,64,64,0.5);
box-shadow: var(--menu-shadow);
margin: 0px;
padding: 0px;
overflow: hidden;
}
/*
These three layers sat on a .menu::before for a while and painted NOTHING,
which is worth writing down because putting them back there is the obvious
thing to try. The pseudo-element was `content: ""` and nothing else - a
zero-size inline box - so its shadow had no box to cast from. Neither of
the two ways of finishing it works:
- Give it `position: absolute; inset: 0` and the OUTER layers vanish. An
element's own box-shadow is not clipped by its own overflow, but a
DESCENDANT's is, and .menu is overflow: hidden - which it has to be, or
a hovered first or last item squares off the 10px corner. So layers 1
and 2 can only ever live on .menu itself.
- The inset layer would survive that, but it then scrolls. .window_group_menu
is overflow-y: auto with a max-height, and an absolutely positioned child
of a scroll container is anchored to the scroll origin, not the border
box. Measured in the browser: the overlay sat 0.8px below the menu top at
scrollTop 0 and -79.2px at scrollTop 80, i.e. it slid straight out of the
frame it was meant to be part of. An inset shadow on .menu does not move,
because a background does not scroll with content.
The one thing an overlay would have bought is painting the catch light
OVER the first child rather than under it, and that is not worth the two
problems above: in the launcher the first child is a separator band at 10%
white, so the highlight reads through it almost unchanged, and in the group
menu the 6px padding means nothing reaches the top edge at all.
*/
/*
A window's notice band - something the reader needs to know that is NOT
about a field, rendered above the content rather than as a
ValidationMessage. Two windows use it for what their OPENER had to say
(RegisterConfirm, ResendCodeComplete); Logout uses it for a message it
writes itself.
THAT THIRD CASE IS FORCED RATHER THAN CHOSEN, and it is the sharpest reason
this class exists. Logout is a Section form with no fields, and Section
derives its Submit button's disabled state from whether the message store
holds anything - a store refilled only by a validation pass, which is raised
only by a field change or another submit. With no fields there is no field
change, so a failure written as a ValidationMessage would disable the only
button on the window forever. A plain element cannot do that.
Global for the same reason .menu and .window_drawer_menu are: three separate
components wear it, and CSS isolation would scope a rule in any one of their
stylesheets to that component's own markup and miss the others. It WAS a
copy in two of them - byte-for-byte identical, and named
.register_confirm_notice in both, so the resend window's stylesheet was named
after the register window and changing one colour meant editing two files.
Warning-coloured rather than error-coloured on purpose: nothing has gone
wrong that the reader did, and whatever the message is about is still
recoverable by trying again - ask for the code again, press Logout again.
That is a different message from "that failed, give up".
*/
.window_notice {
margin-bottom: 12px;
padding: 10px 12px;
/* The amber the drawer and the focus rings already use, so this reads as
part of the same interface rather than as a browser default. */
border: 1px solid rgba(255, 204, 102, 0.55);
border-radius: 6px;
background-color: rgba(255, 204, 102, 0.12);
color: inherit;
font-weight: 600;
}
/*
The class names below are BLAZOR'S, not ours - no markup in this project
writes any of them, and none should. `modified`, `valid` and
`invalid` are applied to an input by the EditContext's field CSS class
provider, and `validation-message` is what the ValidationMessage and
ValidationSummary components render. So they are styled here for the same
reason the default Blazor template styles them: they turn up the moment a
form does.
Forms exist now - Login, Register, RegisterConfirm and ResendCode all
render one - so these DO match, which they did not when the note here said
otherwise. Still do not write any of them by hand: the EditContext and the
ValidationMessage component are the only things that should apply them.
*/
.valid.modified:not([type=checkbox]) {
outline: 1px solid #26b050;
}
.invalid {
outline: 1px solid indianred;
}
.validation-message {
color: indianred;
}