/* The family called 'SourceSansPro' is now served by the real Source Sans Pro faces, which have been vendored in this directory all along. It used to be served by MyriadPro-Light + MyriadPro-Semibold, and that mapping was the single reason this UI read as washed out. `MyriadPro-Light` declares `usWeightClass: 300`: it is a Light cut, and it was bound to `font-weight: normal`. So every paragraph, label, table cell and form field in the product - all of it nominally weight 400 - was actually painted in a 300 face. Not a colour problem. The strokes themselves were thin. Light cuts at 12-14px are a readability failure that the industry spent the back half of the 2010s walking away from: a 300 weight is a display face, sized for headlines, and it loses stem contrast at body sizes on exactly the low-DPI external monitors this kind of software is read on all day. Source Sans Pro is what the CSS always claimed to be loading, is by the same designer as Myriad (Robert Slimbach) and is the same humanist-sans genre, so the product's typographic character carries over - but it ships true 400, 600 and 700 cuts instead of a Light standing in for regular. Real italics, too. Nothing declared an italic face before, so every `em` was synthetically obliqued by the browser. That matters here specifically: italic on the AI report surface denotes gene symbols, which is semantic, not decorative, and a slanted Light face is a poor way to carry meaning. `swap` on body text: the fallback renders immediately and is replaced when the webfont arrives, so text is never invisible. Icon fonts below take `block` instead, for the opposite reason. */ /* Light is declared at 300, where it belongs, rather than standing in for normal. The three rules that ask for 300 are all large display figures - the 34px storage total, the 30px stat values, the 34px pathway count - where a light weight is a legitimate treatment and has stroke mass to spare. They were written when 300 silently resolved to the Light face, so this keeps them rendering as their author saw them. Body text asks for 400 and cannot reach this: with 300 and 400 both present, a 400 request matches 400 exactly. What the old mapping got wrong was binding Light to `normal`, not shipping a Light at all. */ @font-face { font-family: 'SourceSansPro'; src: url('fonts/SourceSansPro-Light.ttf') format('truetype'); font-weight: 300; font-style: normal; font-display: swap; } @font-face { font-family: 'SourceSansPro'; src: url('fonts/SourceSansPro-Regular.ttf') format('truetype'); font-weight: 400; font-style: normal; font-display: swap; } @font-face { font-family: 'SourceSansPro'; src: url('fonts/SourceSansPro-Semibold.ttf') format('truetype'); font-weight: 600; font-style: normal; font-display: swap; } @font-face { font-family: 'SourceSansPro'; src: url('fonts/SourceSansPro-Bold.ttf') format('truetype'); font-weight: 700; font-style: normal; font-display: swap; } @font-face { font-family: 'SourceSansPro'; src: url('fonts/SourceSansPro-Italic.ttf') format('truetype'); font-weight: 400; font-style: italic; font-display: swap; } @font-face { font-family: 'SourceSansPro'; src: url('fonts/SourceSansPro-SemiboldItalic.ttf') format('truetype'); font-weight: 600; font-style: italic; font-display: swap; } @font-face { font-family: 'SourceSansPro'; src: url('fonts/SourceSansPro-BoldItalic.ttf') format('truetype'); font-weight: 700; font-style: italic; font-display: swap; } /* Icon fonts ------------------------------------------------------------------ `block`, not `swap`. An icon font's codepoints are in a private use area that no fallback font has a glyph for, so swapping to the fallback draws a row of empty boxes: on a cold load this page showed tofu in place of every icon in the header, the toolbars and the upload cards until the font arrived. `block` renders nothing at all for that window, which reads as an icon that has not painted yet rather than as one that is broken. */ @font-face { font-family: 'CustomIcons'; src: url('fonts/CustomIcons.ttf') format('truetype'); font-style: normal; font-display: block; } /* Re-declared here only to add font-display. font-awesome.min.css is vendored, so editing it would lose this on the next upgrade; this file is linked after it in index.html, so the later face wins. Same three sources, same order. */ @font-face { font-family: 'FontAwesome'; src: url('../font-awesome/fonts/fontawesome-webfont.woff2?v=4.4.0') format('woff2'), url('../font-awesome/fonts/fontawesome-webfont.woff?v=4.4.0') format('woff'), url('../font-awesome/fonts/fontawesome-webfont.ttf?v=4.4.0') format('truetype'); font-weight: normal; font-style: normal; font-display: block; } /*BODY STYLES*/ root { display: block; } :root { --main-max-width: 1900px; /* Typography --------------------------------------------------------------- SourceSansPro is vendored locally via the @font-face rules above; the fallback chain keeps metrics close if the webfont fails to load. Use this token instead of hardcoding a family so the UI stays typographically consistent. */ --pa-font-sans: 'SourceSansPro', 'Source Sans Pro', 'Segoe UI', system-ui, sans-serif; /* Measure ------------------------------------------------------------------- How wide running text is allowed to get, in characters, independently of how wide the thing holding it is. The page column is sized for the Step 3 enrichment grid, which is far past the width a line of prose can be read at, so any paragraph sharing that column needs its own cap. Two, because the two kinds of prose in the app are read differently: body copy inside a card is read in sequence, and an empty-state note is a sentence or two glanced at, which wants the shorter line. */ --pa-measure: 105ch; /* running text inside a card */ --pa-measure-note: 78ch; /* empty-state notes */ /* Ink colours -------------------------------------------------------------- Hue and saturation are preserved from the original palette; only lightness moves, so the UI keeps its colour identity. Measured against #EEEEEE, the darkest light panel fill in this stylesheet, rather than against white. That distinction has already caught this palette out twice: tuning against white alone left every token at 4.13-4.48:1 on the grey panels of Step 3, and a retune against #F3F3F3 still left them at 4.38-4.41:1 on the #EEEEEE surfaces of Step 4. Tuning against the darkest surface makes every lighter one pass by construction. What that earlier pass got wrong was the target, not the method. It aimed at AA (4.5:1) and stopped, which landed the entire palette in a 5.3-5.4:1 band on white - every token the same distance above the line, and that line is the legal floor for "can be perceived", not a setting for text somebody reads for an hour. A palette clustered just above a minimum is what "washed out" means in practice, and it is what this one looked like. The four tokens that carry actual running text - muted body copy, inline `b`, `strong`/infoTip accents, links - now target AAA (7:1) on white, which puts them at 6.0-6.4:1 on the #EEEEEE panels. That is roughly where the mainstream systems put body ink (Tailwind gray-600 7.5:1, GitHub Primer fg.default 15:1 with fg.muted 5.7:1 reserved for genuinely secondary text), and it is a full step darker than a floor-hugging 5.3. `--pa-accent-orange` and `--pa-accent-green` stay where they are: both are used on headings and badges at large sizes, where 3:1 is the threshold and darkening them further would cost the palette its warmth for no gain. */ --pa-link: #0060BA; /* was #006ACC 5.34:1 -> 6.21:1 */ --pa-link-hover: #24785D; /* orig #2E9B78 3.46:1 */ --pa-accent-blue: #19589E; /* was #1F6BC1 5.34:1 -> 7.17:1 */ /* The AI colour. Every AI surface in the application is meant to be the same blue -- the mark, the two Step 1 headings that carry it, the consent, the conversion controls, the widget -- and until now only some of them were: inputformat.css read `var(--pa-ai-blue, #4A90D9)` against a token that was declared in dark.css and nowhere else, so in the light theme it fell back to a colour no other blue in the app uses, and the marks in the section headings took the heading's ink and were not blue at all. Declared here it resolves to the accent for the light theme and to dark.css's own #4A90D9 in the dark one, which is what that file already intended. --pa-ai-action-bg is deliberately NOT redeclared by the theme: it is a fill that carries white text, and white on dark.css's lighter blue measures 3.0:1. */ --pa-ai-blue: #19589E; --pa-ai-action-bg: #19589E; --pa-ai-action-bg-hover: #124676; --pa-accent-orange: #AD5022;/* orig rgb(209,96,42) 3.59:1 */ --pa-ink-muted: #595959; /* was #6B6B6B 5.33:1 -> 7.00:1 */ --pa-bold-blue: #37587C; /* was #446E9B 5.32:1 -> 7.37:1 */ --pa-accent-green: #247B21; /* orig #288824 3.90:1 on #EEEEEE */ /* Focus ring. Chosen to clear 3:1 (WCAG 2.4.11) against every surface the ring actually lands on: white panels 3.65:1, the #F2F2F2 button toolbar 3.26:1, and the #222 header bar 4.36:1. It is drawn with outline-offset, so it sits on the surface behind a control rather than on the control's own fill - which is why the green and red button fills do not constrain the choice. */ --pa-focus-ring: #0A84FF; /* Surfaces and controls ---------------------------------------------------- The app had three corner radii in play - 2px on cards, 3px on form fields, 4px on buttons - which is the kind of drift that reads as unfinished rather than as a decision. Two values now: one for surfaces, one for the controls that sit on them. Deliberately conservative. This is research software whose subject is the data on screen, so the chrome earns nothing by competing with it: no gradients, no transforms, no lift-on-hover. The shadow is two very low alpha layers, enough to separate a card from the #F3F3F3 page and no more, and the border is a touch cooler than the old #E9E9E9 so cards read as defined rather than washed out against that grey. */ /* The page behind the cards. #F3F3F3 was a neutral grey, which is the colour a surface gets when nobody chose one: it reads as unpainted rather than as a background. This is the same warmth an ivory paper stock has - enough to make the white cards on it read as white, which a card on grey never quite does, and enough that the page looks lit rather than switched off. A light counterpart to the --pa-surface-page dark.css already defines, so the two themes now name the same thing. */ --pa-surface-page: #FAF9F5; /* The quiet surface - toolbars, hovers, the compact left menu. This token had only ever been declared in dark.css, so every light-mode use of it was resolving to its `var(--pa-surface-quiet, #F1F2F4)` fallback, and #F1F2F4 is cold: its blue channel sits three above its red. Declaring the light value here is what the dark sheet has always assumed existed. #F3F2ED carries the same +5 red-over-blue as --pa-surface-page above, and is within 0.1% relative luminance of the #F1F2F4 it replaces (0.8866 vs 0.8873), so the contrast figures measured against the old value - the 8.6:1 noted further down this file among them - all still hold. */ --pa-surface-quiet: #F3F2ED; /* The rest of the surface family, and the two control inks that go with it. Same story as --pa-surface-quiet above: dark.css has declared all of these for a long time, but the light `:root` never did, so every light-mode reader fell through to whatever literal its own `var(..., #fallback)` happened to carry. The MORE regulator-target network is written entirely against these names, which meant the one panel in the application authored against the design system was also the only one not painted by it - it rendered in #f5f5f7 / #fafafa / #333, cold greys, on a warm ivory page. Values chosen from the warmed literals already used throughout this file (#F6F6F6 -> #F6F5F0, #F5F5F5 -> #F5F4EF, #FAFAFA -> #F9F8F4) so nothing shifts for anything that was already using those by hand; naming them is what lets network-views.css describe both graph surfaces at once. --pa-ink-body and --pa-ink-title are deliberately NOT declared here. They are read in 22 places in this file with per-site fallbacks that differ on purpose, and unifying those is a typographic decision of its own, not a side effect of wiring up two network panels. */ --pa-surface: #FFFFFF; --pa-surface-toolbar: #F6F5F0; --pa-surface-sunken: #F5F4EF; --pa-surface-subtle: #F9F8F4; --pa-ink: #18181B; --pa-ink-control: #3F3F46; --pa-ink-label: #52525B; /* A control sitting on a toolbar band: its resting fill, the fill it takes under the cursor, and the one it takes while pressed. These exist as their own tokens rather than as reuses of --pa-surface because "lights up under the cursor" is not the same colour move in the two themes. On the ivory band a control brightens to white; on dark.css's #212227 band it has to go lighter than the band, and --pa-surface there is #1E1F23 - darker. Written as --pa-surface, the hover looked right in light mode and inverted in dark. */ --pa-control-bg: #FFFFFF; --pa-control-hover-bg: #FFFFFF; --pa-control-active-bg: #EEEDE7; /* The quiet panel fills scattered through this file were warmed to match: #FAFAFA -> #F9F8F4, #F6F6F6 -> #F6F5F0, #F5F5F5 -> #F5F4EF. Warmed at constant lightness, deliberately - every contrast figure recorded in the comments below was measured against the old values, and a swap that moves hue without moving luminance leaves all of them true (each pair differs by under 1% relative luminance). Mixing cold greys into a warm page is what makes an interface look assembled from parts rather than designed; it is also the tell that the greys were never chosen, only defaulted to. They are still literals rather than a token because there are twelve of them across nine unrelated components, and turning that into a token is a refactor with its own risk, not a colour change. */ --pa-radius: 8px; /* cards, panels, dialogs */ --pa-radius-sm: 6px; /* inputs, small surfaces */ /* Buttons -- every one of them, filled or outline, labelled or icon-only. They were split between two shapes and nobody had decided which: the header bar, the "Load example" chips in the How-it-works cards, the job chip and the theme toggle were all fully rounded at 999px, while every other button in the application -- the ExtJS ones the framework draws, the form's own .button, the toolbar options, the converter's controls, the cookie banner -- took --pa-radius-sm's 6px. Two radii on one screen is the tell that neither was chosen; a pill button is also the shape the rest of the interface's small round things already use (.po-job-chip, the omic chips), so the app ends up with one answer instead of two. Not applied to inputs, which keep --pa-radius-sm: a rounder text field reads as a search box, and most of these are not. Nor to the segmented two-option toggles, which are a group of one shape rather than two buttons. 8px, not the 999px the header was using. Fully round was the first attempt at making them one shape and the owner's read was that it is too much: at this size a pill is a chip, and these are buttons. 8px is the radius the cards and panels already take, so a button now agrees with the surface it sits on instead of introducing a third curve. */ --pa-radius-btn: 8px; /* buttons */ /* An alpha of the ink rather than a fixed grey. The same hairline then sits correctly on a white card, on the ivory page and on the #EEEEEE panels of Step 4, instead of being tuned for one of them and looking cold on the other two. Resolves to about #E7E7E8 on white, which is where #E4E4E7 already was, so nothing shifts - it just stops being wrong elsewhere. */ --pa-border: rgba(24, 24, 27, 0.10); /* How far a card's contents stand off its own border. Body copy used to sit about 5px from the edge while the card's heading sat at 20, so text ran into the frame around it and the two never lined up. One value for both. */ --pa-card-inset: 26px; --pa-shadow: 0 1px 3px rgba(24, 24, 27, 0.08), 0 1px 2px -1px rgba(24, 24, 27, 0.06); --pa-shadow-inset: inset 0 1px 2px rgba(24, 24, 27, 0.14); /* Kept short enough to feel like feedback rather than animation. Collapsed to 0.01ms by the prefers-reduced-motion block near the end of this file. */ --pa-transition: 150ms ease; /* Page column --------------------------------------------------------------- The application was pinned to the left edge. On a 1867px viewport the content measured 1300px wide starting at x=20, leaving 547px of dead space down the right - not a wide layout, a narrow one shoved into a corner. One column, centred, that the header contents and the content boxes both align to. 1400px is the width of the Step 3 enrichment grid, the widest thing in the application, so the column holds it without reintroducing the horizontal scrolling that removing the rail just cured. It was 1560px, which is wider than the laptop screens most of this is read on: with the old 20px floor the max() below always chose that floor on a 1440px display and the whole rule did nothing, leaving the results within 40px of the right edge. The cap engages at 1480px rather than 1600px now, and the floor is a margin you can actually see rather than a hairline. The gutter is `max()` so nothing changes below the cap - this only does work on displays wide enough to have the problem. */ --pa-page-max: 1400px; /* The rail is sized so the results column's visible edge lands on the header's "Job view" pill, the same way the TOC's width is the wordmark's: the header is the ruler for everything under it. The pill starts 166px right of the gutter (147px of wordmark + 19px of menu margin, both constants), and the ExtJS step containers add 20px of their own inset between the column edge and a card's border, so 146 + 20 puts the card exactly under the pill at every viewport width. Was 206, which left the cards 60px right of anything else in the header - a rail nothing above it shared. */ --pa-rail: 146px; /* The gutter was `max(40px, (100vw - 1400px) / 2)`, which on the 1440-1512px laptops this is mostly read on resolved to the 40px floor or a little over it - 56px at 1512. That is a hairline by the standards of any page meant to be read rather than operated, and it is the specific thing that made the application feel like it was pressed against the sides of the window. Measured on anthropic.com at a 1512px viewport for comparison: content 1279px wide inside a 116.5px gutter, or 7.71% of the viewport each side. Not a floor it happens to land on - a proportion it holds. So the floor becomes proportional too. 7.5vw tracks that reference within a few pixels, the 24px minimum keeps a phone from losing the text to its own bezel, and the 160px cap stops the proportion running away on a very wide display - past which the `(100vw - --pa-page-max) / 2` term takes over again and the column caps at 1400px exactly as before. Between roughly 1280 and 1600px the proportional term now wins, so the column there IS narrower than it was - 1286px rather than 1400px at 1512. That is the trade, and it is deliberate: those widths were previously spending the difference on a 40-56px margin, which is not a column. It costs the enrichment grid nothing, because the results view does not read this token. It is `#mainViewCenterPanel.pa-has-toc`, and the media block near the end of this file pads it from --pa-gutter-railed instead, which is unchanged. Note also that the old rule never actually delivered 1400px on a 1440px laptop either - max(40, 20) is 40, for a 1360px column - so the width the grid was sized against was only ever reached at 1480px and up, where the second term still wins today. 1280 -> 96 (was 40) 1440 -> 108 (was 40) 1512 -> 113 (was 56) 1680 -> 140 (was 140) 1920 -> 260 (was 260) 2560 -> 580 (unchanged) */ --pa-gutter: max(clamp(24px, 7.5vw, 160px), calc((100vw - var(--pa-page-max)) / 2)); /* The contents sidebar is chrome, not content, so the results column is centred in what is left after it - not in the viewport. Padding the left by rail + gutter while padding the right by gutter alone would push the column off-centre by the width of the rail. */ --pa-gutter-railed: max(40px, calc((100vw - var(--pa-rail) - var(--pa-page-max)) / 2)); } /* Keyboard focus ------------------------------------------------------------ The vendored ExtJS Neptune theme ships `.x-webkit :focus { outline: none }`, which strips the focus ring from every focusable element in the app - buttons, links, grid rows, form fields alike. Keyboard and screen-magnifier users get no indication of where they are (WCAG 2.4.7 Focus Visible). Restored here rather than in the theme file, because that file is vendored and any change to it would be lost on an ExtJS upgrade. Three details that matter: - `!important` is unavoidable. Neptune's rule is `outline: none !important`, so neither a later source position nor higher specificity can beat it. Verified in the browser: literal colours, longhand properties and higher specificity all still computed to `outline-style: none`; only `!important` took effect. - `:focus-visible`, not `:focus`. The ring appears for keyboard navigation but not when a control is clicked, which is the visual noise that usually motivates suppressing focus rings in the first place. - The `.x-webkit` prefix on the first selector matches Neptune's own specificity; the bare selector below it covers browsers where ExtJS does not add that class and no suppression exists. `outline` is painted outside the border box and takes no space, so this cannot shift any ExtJS layout. */ .x-webkit :focus-visible, :focus-visible { outline: 3px solid var(--pa-focus-ring) !important; outline-offset: 2px; } body { background-color: #000; font-family: var(--pa-font-sans) !important; /* Left-aligned rather than justified: the app renders text in narrow ExtJS panels and table cells, where justification without hyphenation opens large inter-word "rivers" and hurts readability. */ text-align: left; font-size: 14px !important; -webkit-font-smoothing: antialiased; -moz-osx-font-smoothing: grayscale; } span.helpTip { color: var(--pa-ink-muted); } span.helpTip:hover { color: var(--pa-link); } span.helpTip:before { content: "\f059"; font: normal normal normal 14px/1 FontAwesome; padding-left: 8px; } span.infoTip { color: var(--pa-accent-blue); margin-left: 15px; display: block; font-size: 12px; } span.infoTip:before { content: "\f05a"; font: normal normal normal 12px/1 FontAwesome; color: var(--pa-accent-blue); margin-left: -15px; margin-right: 4px; } span.commentTip { color: var(--pa-ink-muted); display: block; font-style: italic; font-size: 12px; margin-bottom: 4px; } .x-body { background-color: #000 } b {color: var(--pa-bold-blue);} /*TITLES STYLES*/ /* `font-weight: lighter` is a *relative* keyword, not an absolute one: it steps down from the inherited weight, so on a 400 body it resolved to 100. Every heading in the product was asking for Thin. Measured in Chrome, `h4` on the landing page computed to `font-weight: 100`. A heading's job is to outrank the paragraph beneath it, and weight is the cheapest way to say so. 600 - Semibold, a real cut in the family above - is the standard choice for UI headings; it separates from 400 body copy without the blockiness 700 brings at these small heading sizes. */ /* The scale below h2 used to be colour-coded rather than sized: h3 teal (#007383), h4 green, h5 a third teal (#056E66). Three hues, no relationship between them, and each one a step *down* the document outline while reading as a step up in emphasis. That was invisible at the top level, because the landing page and the results cards override h2 and h3 locally (`div.contentbox h2` / `h3` below). It was not invisible one level in. Everything that lives inside a panel - the network's Tools and Details columns, the pathway view's information strip, the cluster panels, the omic upload boxes - titles its sections with bare h4 and h5, so a settings column read as green heading, teal sub-heading, green heading, teal sub-heading down its whole length, with the actual controls in near-black underneath. Colour was marking nothing: every one of those headings is the same kind of thing. One ink, three sizes, one weight. Hierarchy is carried by size and by the space around a heading, which is what the level-1 surfaces already do; colour goes back to meaning links, significance tints and omic type-coding. Sizes come down with the colour. 20px for an h3 and 16px for an h4 were display sizes inside 260px-wide panels, where they wrapped a two-word label onto two lines; the body copy they title is 13px. */ h1, h2, h3, h4 {font-weight: 600;margin: 0;} h2 {color: var(--pa-accent-orange);font-size: 23px;} h3 {font-size: 16px;color: #27272A; margin: 10px 0px;} h4 {font-size: 14px;color: #27272A; margin: 10px 0px;} h5 {font-size: 12.5px; margin: 10px 0px; color: #3F3F46; font-weight: 600;} a {text-decoration: none;color: var(--pa-link);} a:hover {color: var(--pa-link-hover);} /***************************************************************************** **** STYLES FOR HEADER AND TOOLBARS ********************************************** *****************************************************************************/ .toolbar { border-width: 0; padding: 10px 20px; height: 50px; /*z-index: 100;*/ } /* The session bar's avatar. It was a 30x30 PNG that is in neither the repository nor the deployed image; it is a FontAwesome glyph now, which needs a size because nothing ever sized the either. Muted rather than full ink: it labels the account control beside it and should not outweigh it. Nothing renders this today - MainView constructs SessionInfoBar and never adds it to a container, under a TODO saying as much - so the rule is here for whenever that widget is wired up, not because a broken image is on screen now. */ .sessionAvatar { font-size: 24px; line-height: 30px; color: var(--pa-ink-muted); } /* Chrome ---------------------------------------------------------------------- Successive passes lightened this bar from #222222 to #33343A and it still read as heavy, because the weight was never really the shade - it was that two solid dark masses, the header band and the 65px rail, framed the screen on two sides and between them held every piece of navigation in the application. So the rail is gone: its markup now renders inside this bar (see MainView.js), and the bar itself goes white with a hairline under it. Navigation stops being a coloured region of the layout and becomes a row of controls, which is the pattern the reference site uses and the reason its chrome disappears behind its data. The bar keeps its 50px height on purpose: .secondTopToolbar below is pinned with `top: 50px`, so the height is load-bearing, not cosmetic. */ .mainTopToolbar { background: #FFFFFF; border-bottom: 1px solid var(--pa-border); display: flex; align-items: center; gap: 16px; /* The bar stays full-bleed - a centred white strip on a white page would be invisible - but its contents sit on the page column, so the wordmark lines up with the left edge of the content beneath it. */ padding-left: var(--pa-gutter); padding-right: var(--pa-gutter); } /* One control system for the header row --------------------------------------- Folding the step actions into this row exposed that they had never been designed to sit beside each other. Measured, the bar held: Sign in / Log in #5b5a59 charcoal fill, 10px type, 27px tall Reset #D43E3A solid red, 14px type, 32px tall Run PaintOmics solid green, 14px type, 32px tall Load example solid teal, 14px type, 32px tall Sharing options white, 14px type, 32px tall the nav pills light grey, 12.5px type, 999px radius Two heights, two type sizes, four fills and two corner radii, in one row. That is what read as "very different visual effect" - the controls were not disagreeing about hierarchy, they were disagreeing about what a control is. So: one shape for everything in this row - the nav's pill, 30px tall, 12.5px type - and hierarchy expressed by weight instead of by everything shouting at once. Exactly one control is filled, the primary action for the step; the rest are ghosts, and destructive intent is carried by red ink rather than a red field. A Reset button does not need to be the loudest thing on screen. The border is #878787 on every ghost, not a tinted red for the destructive one: a red pale enough to read as a hint (#D9A6A2, #C08A86) measures 2.12 and 2.91 against white and misses the 3:1 that WCAG 1.4.11 wants of a control's boundary, while the neutral makes 3.59. Ink #24252A is 15.29 and the destructive #B3261E is 6.54. */ .mainTopToolbar .button, .secondTopToolbar .button, .paToolbarMiniature .button { display: inline-flex; align-items: center; gap: 6px; height: 30px; padding: 0 13px; border: 1px solid #878787; border-radius: var(--pa-radius-btn); background-color: #FFFFFF; color: #24252A; font-size: 12.5px; line-height: 1; white-space: nowrap; } .mainTopToolbar .button:hover, .secondTopToolbar .button:hover { background-color: var(--pa-surface-quiet); color: #111111; border-color: #767676; } /* The step's primary action - Run PaintOmics, Next step - is the one thing that stays filled, so the eye still lands on it immediately. */ .secondTopToolbar .button.btn-success { background-color: #3A843A; /* white label 4.62:1 */ border-color: transparent; color: #FFFFFF; } .secondTopToolbar .button.btn-success:hover { background-color: #31702F; border-color: transparent; color: #FFFFFF; } .mainTopToolbar .button.btn-danger, .secondTopToolbar .button.btn-danger, .paToolbarMiniature .button.btn-danger { background-color: #FFFFFF; color: #B3261E; border-color: #878787; } .mainTopToolbar .button.btn-danger:hover, .secondTopToolbar .button.btn-danger:hover { background-color: #FCF2F1; color: #8F1E17; border-color: #767676; } /* .btn-sm set 10px, which is where the account button's odd size came from. */ .mainTopToolbar .button.btn-sm { font-size: 12.5px; } /* The Sign in / Log out button sat on a dark bar and needed a #858585 border to reach the 3:1 that WCAG 1.4.11 asks of the information identifying a control. On white its own #5b5a59 fill is 6.88:1 against the bar, so the fill now carries the boundary by itself and the border goes back to transparent - the earlier fix is not reverted so much as made unnecessary by the surface underneath it changing. The `margin-left: auto` that pins the corner to the right belongs to neither this button nor the switch any more: it is on .headerUtilities below, the wrapper that holds both. Giving it to the switch alone - the arrangement before this - meant the switch absorbed all the free space in the row and the account button merely followed it, which is exactly how a bare moon ended up floating on its own between the step actions and a labelled pill. */ .mainTopToolbar .button { /* The account control is the design system's HeaderButton tone="account" - a filled charcoal pill, not one of the step ghosts - so its fill has to be restated here. The base `.button` above does carry #5b5a59, but at (0,1,0) it loses to the shared `.mainTopToolbar .button, .secondTopToolbar .button` rule that paints every header control white, and with the transparent border below that left this one at 1.00:1 against the white bar: WCAG 1.4.11 had nothing to measure. The shape set by that rule - 30px pill, 12.5px type, 999px radius - is unchanged; only the fill and its label ink return. */ background-color: #5B5A59; /* --pa-btn-neutral-bg, 6.88:1 on the white bar */ color: #E2E2E2; /* --pa-btn-neutral-ink, 5.31:1 on the fill */ border-color: transparent; float: none; margin-left: 0; margin-right: 0; } /* (0,3,0), which is what it takes to beat the ghost hover declared above. */ .mainTopToolbar .button:hover { background-color: #117EA9; /* --pa-btn-neutral-bg-hover, white label 4.58:1 */ color: #FFFFFF; border-color: transparent; } /* One bar, not two ----------------------------------------------------------- The step actions - Load example / Run PaintOmics / Reset on Step 1, Go back / Next step on Step 2, the Step 4 view controls - lived in their own 50px band pinned directly under the header. Two stacked bars for what is one row of chrome, and because this band is `position: fixed` it was not occupying layout space but *covering* the first 50px of the content underneath. It now sits in the header row itself, right-aligned and clear of the account button. Nothing about the markup changes - the band is still the same fixed element, it just moves up and shrinks to its contents - so every step keeps building its own buttons exactly as before. The content below gains back the 50px it was losing to the overlay. `row-reverse` preserves the original visual order: these buttons were laid out with `float: right`, so the first in the DOM sat rightmost, and a plain flex row would have reversed them. */ /* `!important` throughout, and it is load-bearing rather than lazy. On Step 1 this band is a plain box, but on Step 4 it is an ExtJS container whose layout the framework manages, and the framework writes `left: 0; width: 1440px; top: 0` as *inline* styles. A stylesheet declaration cannot beat an inline one without !important, so without these the Step 4 toolbar stayed full-width, wrapped its five buttons onto two rows and sat on top of the pathway. The inner span is ExtJS's box wrapper and carries the same inline width, which is why it needs the override too. `position` was the one declaration in this block that did not carry it, and that is the whole reason Step 4's toolbar did not line up with the other three steps. On Step 4 the band is a child of a vbox, so ExtJS gives it `.x-box-item`, and Neptune declares .x-box-item { position: absolute !important; } which beats a plain `position: fixed` no matter how specific this selector is. So the band computed to `absolute`, and every other declaration here then resolved against the wrong containing block: `top: 0` meant the top of #pathwaysPanelsWrapper rather than of the viewport, which is 50px down, and the inline `left: 0` -- never overridden, because a fixed element does not need it -- stretched the box from the panel's left edge to `right`. Measured: position absolute, top 50, left 109, the buttons packed to the right of a 973px box and reading as a centred second row under the header, where every other step has them in the header itself. `left: auto` is the other half. Without it the inline `left: 0px` survives the switch to fixed and pins the band to the viewport's left edge, so it is the pair that has to be stated, not just the position. */ .secondTopToolbar { position: fixed !important; left: auto !important; top: 0 !important; /* --pa-header-utilities is the distance from the right edge of the viewport to the left edge of .headerUtilities, written by fitHeaderNav() on every resize and every view change. It replaces a literal `var(--pa-gutter) + 178px`, which was 132 of account button plus 30 of switch plus a 16 gap, counted by hand and true only while all three kept those exact sizes. It was already wrong in a state the app reaches by itself: signing out removes the account button, and the band went on reserving room for it. The fallback is the old number, so a browser that somehow renders this before the first measurement lands where it used to rather than on top of the corner. The +16 matches the divider's own 16px margin on the far side, which is what centres that hairline between the two groups. */ right: calc(var(--pa-header-utilities, calc(var(--pa-gutter) + 178px)) + 16px) !important; width: auto !important; height: 50px; padding: 0; display: flex; flex-direction: row-reverse; align-items: center; gap: 8px; background: transparent; border-bottom: 0; box-shadow: none; z-index: 201; } /* The buttons were floated; inside a flex row the float is ignored but the margins are not, and they would fight the gap above. */ .secondTopToolbar > span, .secondTopToolbar > span > div { width: auto !important; display: flex !important; align-items: center; gap: 8px; } .secondTopToolbar .button { float: none; margin: 0; } /* The corner that is not about the analysis -------------------------------- The theme switch and the account button do the same kind of job - neither belongs to the step on screen - and they now say so by sitting together in one group at the end of the row, behind a divider. That divider is the point of the wrapper. The header carries three different kinds of control: navigation, the actions for this step, and these two. With nothing marking the boundary, an icon-only switch in a run of labelled pills reads as something left behind rather than as a member of a group, which is the complaint this answers. A hairline costs one pixel and does the whole job. */ .mainTopToolbar .headerUtilities { flex: 0 0 auto; display: flex; align-items: center; gap: 8px; margin-left: auto; } /* Hidden with opacity rather than display so its 9px stays in the group's measured width. fitHeaderNav() reserves space for that width, and a divider that came and went would move the step actions sideways every time a view mounted its toolbar. Shown by :has(), not by a class from JavaScript. The first version asked fitHeaderNav() to write `.has-step-actions`, which meant a decorative hairline depended on that function's scheduling - and that scheduling is known to go stale (see the note on watchHeaderFit). Measured on the results page it did: the divider was present on one load and absent on the next, from nothing but which run happened to be last. The stylesheet can answer "is a step toolbar on screen" by itself, and a selector cannot be out of date. */ .mainTopToolbar .headerUtilities::before { content: ''; flex: 0 0 auto; width: 1px; height: 20px; /* 16, matching the gap .secondTopToolbar leaves on the other side, so the hairline sits centred between the two zones. Measured at 8 it was closer to the switch than to Reset, which made it read as an ornament belonging to the switch instead of as the boundary between two groups - the opposite of the job. The 8px inside the group stays 8, so the switch and the account button are still visibly tighter to each other than either is to this line. */ margin-right: 16px; /* --pa-border is a 0.10 alpha, correct for a panel edge sitting against a filled surface but too faint to read as a boundary in open space. This one has 16px of white either side of it and one pixel to make its case. */ background: rgba(24, 24, 27, 0.18); opacity: 0; transition: opacity var(--pa-transition); } body:has(.secondTopToolbar) .mainTopToolbar .headerUtilities::before { opacity: 1; } #header { float: none; flex: 0 0 auto; display: flex; align-items: center; height: 32px; /* No `margin-left: -5px`. It pulled the mark five pixels outside the toolbar's own gutter, so the wordmark did not start on the page rail - and once the cards below were brought onto that rail, five pixels of overhang is exactly the kind of miss that reads as sloppy rather than as optical correction. The mark is a square SVG with no side bearing to compensate for. */ cursor: pointer; } #header img { height: 28px; float: none; } /* Dark ink now that the bar is white. The wordmark also stops being the largest thing in the interface - at 26px it outsized every heading in the analysis below it, which is the same complaint as the omic cards. */ #header h1 { font-size: 19px; margin: 0 0 0 9px; font-weight: 400; color: #1A1A1A; white-space: nowrap; } /* No rule for .appVersion any more: MainView.js stopped emitting the chip. The header is the row where the nav pills and the step actions grow towards each other, and fitHeaderNav() compacts the pills and then strips their labels to keep them apart; a build number between the wordmark and the first pill spent about 50px of exactly that contested space. Kept as a note rather than as a dead rule, so the next person to look for the version in the header finds out where it went instead of finding styling for an element that is not there. */ #footer { max-width: 65px; } /*********************************************************** ***STYLES FOR LATERAL MENU** ******************************* ***********************************************************/ /* Header navigation ----------------------------------------------------------- This was a 65px dark rail down the left edge holding six stacked items. It now lives in the header as a horizontal pill group, which is what finally takes the weight out: the navigation stops occupying a region of the layout and the analysis gets the full width of the window. The markup is unchanged - same