/* ===================================================================== site-v2.css -- the refreshed site look ("chrome V2") HOW THIS CASCADES TO EVERY PAGE Every page on the site renders inside Site.Master, so restyling the shared furniture here reaches all of them at once: the header, logo row, navigation, footer, and the common controls that WebForms emits on every screen (asp:Button, asp:TextBox, GridView, validators). No page markup is changed, and no page needs editing to take part. HOW IT STAYS PER-CLIENT Every colour below comes from the existing --theme-* custom properties (Styles/client-.css, overridden by the AdminTheme rows cached in Application["ThemeCssOverrides"]). Nothing here hard-codes a brand colour, so each client keeps their own palette and simply gets better typography, spacing and states. HOW IT IS SWITCHED Site.Master adds "chrome-v2" to the body and loads this file only when Utils.UseChromeV2() is true. Everything is scoped to body.chrome-v2, so with the flag off this file is not even downloaded, and with it on nothing outside the scope can be affected. NOTE ON !important The ported BeTheme stylesheets and client-*.css set many of these same properties with !important, so overriding them needs the same weight. It is used deliberately here, not as a shortcut. ===================================================================== */ body.chrome-v2 { /* Neutrals derived once, so the whole look shifts with the client's palette. */ --v2-ink: #16211f; --v2-ink-soft: #5a6b67; --v2-line: #e2e8e6; --v2-surface: #ffffff; --v2-ground: #f6f8f7; --v2-radius: 10px; --v2-shadow-1: 0 1px 3px rgba(16, 36, 32, .07), 0 4px 14px rgba(16, 36, 32, .05); --v2-shadow-2: 0 2px 6px rgba(16, 36, 32, .10), 0 10px 28px rgba(16, 36, 32, .12); --v2-focus: 3px solid rgba(255, 193, 7, .75); } /* --------------------------------------------------------------- 1. Typography. The theme already sets the family via --theme-font-family; this fixes rhythm, weight and measure. --------------------------------------------------------------- */ body.chrome-v2, body.chrome-v2 .the_content_wrapper { line-height: 1.55; color: var(--v2-ink); } body.chrome-v2 h1, body.chrome-v2 h2, body.chrome-v2 h3, body.chrome-v2 h4 { color: var(--theme-heading-color); font-weight: var(--theme-heading-weight, 600); letter-spacing: -0.01em; line-height: 1.2; text-wrap: balance; } body.chrome-v2 h1 { font-size: 30px; margin: 0 0 16px; } body.chrome-v2 h2 { font-size: 22px; margin: 28px 0 12px; } body.chrome-v2 h3 { font-size: 17px; margin: 22px 0 10px; } body.chrome-v2 p { margin: 0 0 14px; } /* --------------------------------------------------------------- 1a. ONE TYPEFACE, WHATEVER WAS PASTED IN. The registration and grant pages read as a patchwork (David, ss2, ss3, ss5) because a lot of the words on them are not ours: the declaration text, the document instructions and the affiliation blurb are all ClientContent rows, written in a rich-text editor or pasted out of Word, and they arrive carrying their own inline font-family, font-size and colour. Set beside the theme's font they look like a different website. font-family is forced -- there is no legitimate reason for a paragraph in a register to be in a different face from the one the trust chose. ICON FONTS ARE EXCLUDED: a glyph font is not typography, and forcing the body face onto one turns every icon into a stray letter. --------------------------------------------------------------- */ body.chrome-v2 #Content .the_content_wrapper, body.chrome-v2 #Content .the_content_wrapper *:not([class*="icon"]):not([class*="fa-"]):not(.fa) { font-family: var(--theme-font-family), "Segoe UI", Arial, sans-serif !important; } /* Size and colour are normalised only OUTSIDE the landing page, whose hero, stats and cards set their own on purpose. :has() keeps that exception in one place rather than needing a second body class. */ body.chrome-v2 .the_content_wrapper:not(:has(.hv2)) p, body.chrome-v2 .the_content_wrapper:not(:has(.hv2)) li, body.chrome-v2 .the_content_wrapper:not(:has(.hv2)) label { font-size: 15px !important; line-height: 1.6; /* !important because the colour being overridden is usually inline, from the editor the text was written in. Deliberately NOT applied to span: ASP.NET validators are spans with an inline red, and that red is the whole point of them. */ color: var(--v2-ink) !important; } /* Field labels are written as all through these pages. Give them one weight and one colour instead of whichever the pasted block carried. */ body.chrome-v2 .the_content_wrapper:not(:has(.hv2)) b, body.chrome-v2 .the_content_wrapper:not(:has(.hv2)) strong { font-weight: 600 !important; color: var(--v2-ink) !important; } /* Links and headings keep their own colours -- they are meant to differ. These carry the SAME :has(.hv2) exclusion as the rules above: without it the link rule outranks the landing page's own `.hv2-note a`, and the "we can email you a sign-in link" line loses its accent colour. Caught on a screenshot, which is the only way this kind of thing gets caught -- both declarations are !important and this one is simply the more specific of the two. */ /* ONLY LINKS INSIDE TEXT. An is not always a link: this codebase uses anchors as tabs and as buttons (.be-nav a.current, a.button), and they carry their own background with matching text. Forcing a link colour onto those paints dark text on a dark chip -- the Bulk Email tab went invisible exactly this way (David, ss3). Restricting the override to anchors inside a paragraph, list item or cell keeps the pasted-content fix and leaves every anchor that is really a control alone. */ body.chrome-v2 .the_content_wrapper:not(:has(.hv2)) p a:not(.button), body.chrome-v2 .the_content_wrapper:not(:has(.hv2)) li a:not(.button), body.chrome-v2 .the_content_wrapper:not(:has(.hv2)) td a:not(.button), body.chrome-v2 .the_content_wrapper:not(:has(.hv2)) p a b, body.chrome-v2 .the_content_wrapper:not(:has(.hv2)) li a b { color: var(--theme-link-color) !important; } body.chrome-v2 .the_content_wrapper:not(:has(.hv2)) .theme-heading-text, body.chrome-v2 .the_content_wrapper:not(:has(.hv2)) .theme-heading-text b { color: var(--theme-heading-color) !important; } /* Numbers line up in columns wherever they are tabulated. */ body.chrome-v2 td, body.chrome-v2 th, body.chrome-v2 input[type="text"] { font-variant-numeric: tabular-nums; } /* --------------------------------------------------------------- 1b. Page measure and breathing room. Without this the ported layout runs body text edge to edge across the full window: on a 1440px screen a paragraph is about 140 characters long, which is roughly twice a comfortable line and is what makes the page feel cramped and unfinished. Comfortable reading is 60 to 80 characters. The cap is applied to TEXT ELEMENTS ONLY, never to the content container, so admin grids, tables and the wide search panels keep the full window width they need. Vertical padding is added to the content area because the ported theme leaves almost none. --------------------------------------------------------------- */ body.chrome-v2 #Content .the_content_wrapper { padding: 30px 26px 54px; /* The theme gives this wrapper a 1% horizontal MARGIN, which survives any amount of padding work. It is replaced with auto so ordinary pages CENTRE rather than sitting hard against the left edge (David, item 7): a form or a member record pinned to the left of a 1600px window looks broken, and lifting the width cap earlier is what exposed it. */ max-width: 1240px; margin-left: auto !important; margin-right: auto !important; } /* THE WIDE SCREENS KEEP THE WHOLE WINDOW. "Wide grids for example can stay as they are" (David, item 7) -- the admin lists, searches and reports earn every pixel they can get, and squeezing them into a reading column to make the forms look tidy would be a straight downgrade. Driven by a body class from Utils.IsWideAdminPage rather than by a CSS :has() test for a grid, because that test gets it exactly backwards: the registration record David flagged carries TWELVE GridViews of its own (they are narrow detail tables), so "has a grid" would have left that page full width and capped the admin lists. The list of routes is in Utils. */ /* A WIDE PAGE IS STILL A CENTRED PAGE, JUST A ROOMIER ONE. It used to mean "no cap at all", which on a 1600px+ monitor left the admin screens sprawling against the left edge. Capping them at the 1240px reading width instead truncated the batch-pay grid. So the cap is simply wider: enough for the widest grid in the product, still centred, still bounded on a very large display (David: "as there arent that many grid columns this whole page can be centered"). Grids that still do not fit keep their own overflow-x, which they already carry -- .bp-gridwrap and #gridScrollWrapper both scroll. */ body.chrome-v2.page-wide #Content .the_content_wrapper { max-width: 1600px; } /* ...WITH THE NARROW FURNITURE ON THEM STILL CENTRED. A wide page does NOT mean everything on it sprawls. The grids get the window, because that is what they are for and capping them truncated the batch-pay columns (David, ss4). Everything else on those pages -- the message strip, the saved-searches row, the sort row, the pay tiles, the report filters -- is a form or a summary, and stretched across a 1600px monitor its fields end up metres apart. `.messages` is in this list because it IS the yellow summary box on the grant lists: "Grant Pay Lines: 11, Approved Amount ..." comes from Utils.DisplayMessage, which is the site-wide message strip (David, ss3: "except the yellow section"). Listed per element rather than "the first child", because these pages were each built by hand and share no wrapper. Nothing here can break a layout: the worst case is an element narrower than it used to be. */ body.chrome-v2.page-wide #savedsearches, body.chrome-v2.page-wide #sortPanel, body.chrome-v2.page-wide .payrep-intro, body.chrome-v2.page-wide .payrep-filters, body.chrome-v2.page-wide .payrep-actions, body.chrome-v2.page-wide .bp-head, body.chrome-v2.page-wide .bp-tiles, body.chrome-v2.page-wide .bp-bar { max-width: 1240px; margin-left: auto !important; margin-right: auto !important; } /* BATCH PAY KEEPS THE WHOLE WINDOW FOR ITS GRID. It is the widest table in the product -- actions, grant, paid, payments, total, status and accounts -- and it was still losing the Accounts column at the 1600px cap (David: "Extended the length of the grid to show all contents, maybe make it full width"). So this one page is uncapped, and the four blocks ABOVE the grid are centred instead, which is the same thing he asked for last time ("center as a whole section everything above the grid section"). Keyed off the page's own wrapper class rather than another entry in the route list -- the layout follows the markup that needs it. */ body.chrome-v2.page-wide #Content .the_content_wrapper:has(.bp-wrap) { max-width: none; } /* THE SEARCH LISTS DO THE SAME, SO THEIR BANDS CAN REACH THE WINDOW EDGE. David, 6 Aug 2026 (ss1 on /AdminGrantList/Paid): "have blue and yellow backgrounds to take entire width". They were not: the bleed below is done with negative margins against the content wrapper's own 26px padding, so a band could only ever reach the WRAPPER's edge -- and on a 1905px window the wrapper was 1652px centred, which left a 126px white gutter down both sides of the yellow message strip and the blue search card. Uncapping the wrapper on these pages is what lets the -26px bleed land on the window edge, and it costs nothing else: the grid was ALREADY full width (25_06_02_gridview.js gives #gridScrollWrapper its own vw bleed), and every narrow block on the page -- #savedsearches, #sortPanel, #searchSection > * -- is capped at 1240px and auto-centred by the rules above and below, so they simply re-centre on the wider page. Keyed off the page's own markup, the same way :has(.bp-wrap) is, rather than another entry in the route list. NOT done with `width: 100vw`, for the reason spelled out on #searchSection below: 100vw includes the scrollbar and is always ~15px too wide. */ body.chrome-v2.page-wide #Content .the_content_wrapper:has(#searchSection) { max-width: none; } /* ...and the float the list lives in has to fill that width, or the bleed only works on the left. #divPageResults is `float: left` with no width, so it shrink-to-fits its content -- 1729px of a 1853px column -- and #searchSection, which bleeds relative to IT, stopped 124px short on the right while the message strip above (a child of the wrapper, not the float) reached the edge. Same band, two different parents, which is why only one of them looked wrong. Scoped with :has(#searchSection) rather than to #divPageResults on its own: eight other pages share that id (/Audit, /AdminGrantPay, /MasterTreeList and friends), they are still capped and centred at 1600, and widening their float would move content they were never complaining about. */ body.chrome-v2.page-wide .the_content_wrapper:has(#searchSection) #divPageResults { width: 100%; } /* ...and everything ORDINARY inside that float goes back into the 1240px column, or lifting the cap just moves the old complaint down a level: the "Registrations" heading on /AdminList sat at x=153 while the page was centred and would have ended up hard against the window edge once it was not. Capped at the same 1240px as #savedsearches so the heading lines up with the row under it rather than at some third margin. The three that must NOT be capped opt out on their own and need no exception here: #searchSection carries `max-width: none !important` plus !important negative margins, and #gridScrollWrapper's width and margin are written INLINE by 25_06_02_gridview.js, which beats a stylesheet rule. Same :has(#searchSection) scope as the rule above, and for the same reason -- only the pages whose wrapper was uncapped need their contents putting back. */ body.chrome-v2.page-wide .the_content_wrapper:has(#searchSection) #divPageResults > * { max-width: 1240px; margin-left: auto; margin-right: auto; } /* THE SEARCH CARD IS A FULL-WIDTH BAND WITH CENTRED CONTENTS (David, ss3: "make the background take the entire width except the yellow section"). The tint runs edge to edge; the fields inside stay in the same 1240px column as everything else, so the band reads as part of the page rather than as a box floating in it. The bleed is done with NEGATIVE MARGINS against the content wrapper's own 26px padding, deliberately not with `width: 100vw`. 100vw includes the scrollbar, so a vw bleed is always about 15px too wide and puts a horizontal scrollbar on every one of these pages. The margins here are relative to the parent, so they cannot overshoot. !important on margin and padding because the page sets both inline. */ body.chrome-v2.page-wide #searchSection { max-width: none !important; margin-left: -26px !important; margin-right: -26px !important; padding-left: 26px !important; padding-right: 26px !important; border-left: 0 !important; border-right: 0 !important; border-radius: 0 !important; } body.chrome-v2.page-wide #searchSection > * { max-width: 1240px; margin-left: auto; margin-right: auto; } /* THE SEARCH CARD IS A FORM, AND IT WAS SET AT PROSE DENSITY. The ported theme puts `padding: 10px` on every `td`, which is right for a table of content and wrong for a column of filter fields: every row of the criteria card was 48-51px tall for a 25px control, so a card with a dozen filters ran a full screen taller than it needed to (David, 2026-08-06i: "too much vertical spacing"). 3px keeps the rows comfortably apart -- the inputs carry their own padding -- and takes about 250px off the card. Horizontal padding is deliberately left alone: it is what separates a label from its field. */ body.chrome-v2.page-wide #searchSection td { padding-top: 3px !important; padding-bottom: 3px !important; } /* ...and a label that wraps costs a whole extra row of height. The label column is a fixed width on both search cards, so nowrap cannot reflow the layout -- it only stops "Grant Submitted From:" breaking after "Grant". */ body.chrome-v2.page-wide #popup > table > tbody > tr > td:first-child { white-space: nowrap; } /* The Search / Save-search / Hide Criteria / Clear / Export row is loose INLINE content sitting straight inside the section -- a span and four bare inputs, no wrapper to centre. Auto margins do nothing to inline content, so the section centres its own text instead, and the block children put their alignment back (David: "center search section"). */ body.chrome-v2.page-wide #searchSection { text-align: center; } body.chrome-v2.page-wide #searchSection > div, body.chrome-v2.page-wide #searchSection > table, body.chrome-v2.page-wide #searchSection #sortPanel, body.chrome-v2.page-wide #searchSection .critcust { text-align: left; } /* THE MESSAGE STRIP IS A BUTTON-SIZED PILL ON THESE PAGES TOO -- there is no page-wide override of it any more (David, 2026-08-06k: "make the pill like ss1 ... i.e. not a long strip"). It went full-bleed band -> wide rounded strip -> this over three rounds. The thing that was wrong with both of the first two is that a one-line summary stretched across 1900px is a strip, not a pill, however its corners are cut. The site-wide rule further down (`display:block` + `width:fit-content` + auto margins) already hugs the text and centres it, so the fix here is to DELETE, not to add: the grant lists now get exactly the same pill as the rest of the site. The gap under it lives with that rule. The search card below it keeps its full-width bleed -- that one IS a band, and the contrast is the point. */ @media (max-width: 767px) { body.chrome-v2.page-wide #searchSection { margin-left: -18px !important; margin-right: -18px !important; padding-left: 18px !important; padding-right: 18px !important; } } /* The other end of it. A sign-in form is one short column of fields, so centring the 1240px page column around it leaves the form itself still sitting at the left with most of the screen empty beside it. These pages get a column the size of the form. See Utils.IsNarrowFormPage. */ body.chrome-v2.page-narrow #Content .the_content_wrapper { max-width: 620px; } /* The ported theme puts 30px of padding on the TOP of #Content as well, which lands between the kowhaiwhai band and the page and reads as a white gap under the band (David, ss1). The wrapper above already provides the breathing room, so this one is pure surplus. */ body.chrome-v2 #Content { padding-top: 0 !important; } /* THE PAGE TAKES THE WHOLE WINDOW. The ported theme caps .section_wrapper at 1220px, which is what kept the landing page's bands stopping short of the window edge while the header and the kowhaiwhai band above them ran full width. Lifting the cap does NOT widen the reading content: text is still capped at 74ch below, and each landing band centres its own 1120px inner wrapper. What it does widen is the furniture -- bands, grids and search panels now use the window they are given. */ body.chrome-v2 #Content .section_wrapper { max-width: none !important; } /* The V2 landing page manages its own full-bleed bands (hero, living register), so it must not inherit that horizontal padding or the bands stop short of the window edge, and it must not be capped by the reading width above. Its top padding goes too, so the hero sits hard against the tukutuku band. */ body.chrome-v2 #Content .the_content_wrapper:has(.hv2) { max-width: none; padding-top: 0; padding-left: 0; padding-right: 0; } /* Upload and import pages put their whole body inside a narrow cell and read as cramped. Give the common content blocks room. */ body.chrome-v2 .the_content_wrapper .module-content, body.chrome-v2 .the_content_wrapper .customtitle2 { line-height: 1.6; } body.chrome-v2 .the_content_wrapper p, body.chrome-v2 .the_content_wrapper ul, body.chrome-v2 .the_content_wrapper ol, body.chrome-v2 .the_content_wrapper h1, body.chrome-v2 .the_content_wrapper h2, body.chrome-v2 .the_content_wrapper h3 { max-width: 74ch; } /* A paragraph inside a table cell or a grid is layout, not prose, so the reading cap must not apply there or columns collapse. */ body.chrome-v2 .the_content_wrapper td p, body.chrome-v2 .the_content_wrapper th p, body.chrome-v2 .the_content_wrapper td ul, body.chrome-v2 .the_content_wrapper td ol { max-width: none; } /* IF A CLIENT CENTRED THE TEXT, CENTRE THE BOX IT SITS IN. --------------------------------------------------------------- The cap above is what makes this necessary. A capped block keeps `margin-left: 0`, so its box is pinned to the LEFT of the container and `text-align: center` then centres the text on the BOX rather than on the page. Anything the client did not cap -- headings with no cap, a full-width div -- centres on the page as they intended. The result is content centred on two different axes, and it reads as "not quite centred" rather than as a bug, which is why it survived this long. Measured on wct.whenua.org.nz, whose panui is centred paragraph by paragraph in the editor: card centre 953, the h5 headings centred on 954, every capped

centred on 814 -- 140px adrift. David: "are you able to know they are trying to center the content and center it?" This is how we know: the intent is written into the markup by the editor itself. Matching on the ATTRIBUTE, not on computed style, because CSS cannot see computed style -- and covering all three things editors emit: an inline `text-align`, Word's `align="center"`, and a bare

. Only auto margins are set, so nothing about the client's own styling is overridden; an element that was already full width is unaffected, because auto margins on a full-width box are a no-op. */ body.chrome-v2 .the_content_wrapper [style*="text-align:center"], body.chrome-v2 .the_content_wrapper [style*="text-align: center"], body.chrome-v2 .the_content_wrapper [align="center"], body.chrome-v2 .the_content_wrapper center { margin-left: auto !important; margin-right: auto !important; } /* --------------------------------------------------------------- 2. Header + navigation (Site.Master, therefore every page) --------------------------------------------------------------- */ body.chrome-v2 #Top_bar { background-color: var(--theme-header-bg, #fff) !important; box-shadow: 0 1px 0 var(--v2-line), 0 2px 14px rgba(16, 36, 32, .05); } body.chrome-v2 #Top_bar #menu .menu > li > a { font-weight: 600; letter-spacing: .11em; transition: color .2s ease, box-shadow .2s ease !important; } body.chrome-v2 #Top_bar #menu .menu > li > a:hover, body.chrome-v2 #Top_bar #menu .menu > li.hover > a, body.chrome-v2 #Top_bar #menu .menu > li > a:focus { color: var(--theme-accent, #1b5e20) !important; box-shadow: inset 0 -3px 0 0 var(--theme-accent, #1b5e20) !important; } /* Sub-menus: lift them off the page rather than leaving them flat. */ body.chrome-v2 #Top_bar .menu > li ul.sub-menu { border-radius: 0 0 var(--v2-radius) var(--v2-radius); box-shadow: var(--v2-shadow-2); overflow: hidden; } /* THE MENU WRAPS TO A SECOND ROW RATHER THAN BEING CRAMMED (David, item 8). The ported theme floats the top-level items in a bar of a fixed 100px height, so a menu too wide for the window either overlaps the logo or is pushed off the edge. Laying the items out with flex-wrap lets a long menu take a second row instead. That only works because the header is sticky rather than fixed under this look (see _override.css): a fixed bar reserves a guessed height, and a second row would slide underneath the page content. The row itself is right-aligned, so a wrapped menu still reads as one block against the right edge rather than drifting toward the middle. SCOPED TO 1240px AND UP, deliberately. Below that the ported theme swaps the inline menu for its own off-canvas panel -- absolutely positioned, 300px wide, with its own background -- and none of this applies to it. Reaching into that panel is how the header broke the first time: giving ul.menu a real height made #menu's white panel background paint straight over the dark bar. */ @media only screen and (min-width: 1240px) { /* #menu carries the off-canvas panel's white background at every width. It was invisible while the floated items left #menu zero-height; with a flex row it has a real height and paints over the header. */ body.chrome-v2 #Top_bar #menu { background: transparent !important; } body.chrome-v2 #Top_bar #menu > ul.menu { display: flex; flex-wrap: wrap; align-items: center; justify-content: flex-end; row-gap: 2px; } body.chrome-v2 #Top_bar #menu > ul.menu > li { float: none; } /* The theme gives each menu link the full bar height as its line-height, which is what vertically centres it. Two rows of that is a 200px header, so the links get a normal height and the flex row above does the centring instead. */ body.chrome-v2 #Top_bar #menu > ul.menu > li > a { line-height: 42px !important; height: auto !important; } /* The bar keeps its usual height with one row and grows only if a second is actually needed. */ body.chrome-v2 #Top_bar > .container, body.chrome-v2 #mastermenu.menu_wrapper { height: auto !important; min-height: 0 !important; } body.chrome-v2 #Top_bar .top_bar_left { display: flex; align-items: center; flex-wrap: wrap; gap: 0 10px; height: auto !important; min-height: 100px !important; } /* The menu takes the space the brand block does not, and is the only part allowed to wrap: the brand must never break across two lines. */ body.chrome-v2 #mastermenu.menu_wrapper { float: none !important; flex: 1 1 auto; min-width: 0; } } /* --------------------------------------------------------------- 2a. The brand block: tohu + wordmark, the prototype's top left. This replaces homepage-logo-.gif under the new look (SiteSettings.HeaderLogoImage puts the image back for a client whose own logo is worth keeping). The gain is not decorative: a raster logo cannot follow the theme or a chosen palette, cannot carry a second line under it, and is a different shape for every client in the fleet -- which is exactly what made "IWI REGISTER" impossible to stack neatly under it. Set in type, all three problems go at once. --------------------------------------------------------------- */ body.chrome-v2 a#logo.v2-brand { display: inline-flex !important; align-items: center; gap: 12px; height: auto !important; line-height: 1.15 !important; padding: 14px 0 !important; text-decoration: none !important; } body.chrome-v2 .v2-tohu { display: inline-flex; flex: 0 0 auto; } body.chrome-v2 .v2-tohu svg { display: block; } /* Both marks come from the client's accent, so the tohu belongs to whichever palette the site is wearing. */ body.chrome-v2 .v2-tohu-disc { fill: color-mix(in srgb, var(--theme-accent) 14%, transparent); } body.chrome-v2 .v2-tohu-koru { stroke: var(--theme-accent); } body.chrome-v2 .v2-brand-txt { display: inline-flex; flex-direction: column; align-items: flex-start; justify-content: center; gap: 3px; min-width: 0; } /* The trust's name, sized against the header rather than the page. --theme-menu-text is the colour the theme already uses for text on the top bar, which makes this correct on the dark headers most clients run without inventing a new setting. */ body.chrome-v2 .v2-brand-name { font-size: clamp(15px, 1.5vw, 19px); font-weight: 600; letter-spacing: -0.01em; line-height: 1.15; white-space: nowrap; color: var(--theme-menu-text, #16211f); } @media (max-width: 767px) { body.chrome-v2 .v2-brand-name { font-size: 15px; white-space: normal; } body.chrome-v2 a#logo.v2-brand { gap: 9px; } } body.chrome-v2 .brand-sub { display: block; font-size: 10.5px; font-weight: 600; letter-spacing: .2em; text-transform: uppercase; color: color-mix(in srgb, var(--theme-menu-text, #7a8a86) 62%, transparent); white-space: nowrap; padding-left: 2px; } @media (max-width: 900px) { body.chrome-v2 .brand-sub { display: none; } } /* --------------------------------------------------------------- 2c. The user pill: greeting, and the account menu folded into it. LOGOUT used to be a top-level menu item. It is here now (David, item 5: "do fold logout"), which is what took the menu from ten top-level items to nine and made room in the header. The classic look is untouched -- it keeps the plain .header-greeting and its own LOGOUT item, so a site that has not switched over is unchanged. Opens on hover AND on focus-within, so it needs no JavaScript and works from the keyboard. No :hover-only menu may ever be the only route to logging out. --------------------------------------------------------------- */ body.chrome-v2 .user-pill { position: relative; display: inline-flex; align-items: center; gap: 7px; margin-left: 26px; padding: 6px 12px; border-radius: 999px; background: color-mix(in srgb, var(--theme-accent) 14%, transparent); border: 1px solid color-mix(in srgb, var(--theme-accent) 30%, transparent); color: var(--theme-menu-text, #33413e); font-size: 12.5px; font-weight: 600; line-height: 1; white-space: nowrap; cursor: default; vertical-align: middle; } body.chrome-v2 .user-pill:hover, body.chrome-v2 .user-pill:focus-within { background: color-mix(in srgb, var(--theme-accent) 24%, transparent); } body.chrome-v2 .user-pill__caret { width: 0; height: 0; border-left: 4px solid transparent; border-right: 4px solid transparent; border-top: 5px solid currentColor; opacity: .75; flex: 0 0 auto; } body.chrome-v2 .user-pill__menu { display: none; position: absolute; top: calc(100% + 6px); right: 0; min-width: 172px; padding: 6px; border-radius: 10px; background: var(--theme-submenu-bg, #2c2c2c); box-shadow: var(--v2-shadow-2); z-index: 705; } /* THE FLICKER FIX (David, item 4: "my account not easy to click on as it flickers off sometimes"). The 6px between the pill and the menu is dead space: the moment the pointer crosses it, it is over neither element, the hover ends and the menu vanishes underneath the pointer on its way to "My account". This invisible bridge spans the gap so the pointer is never outside the pill's hover area. Keeping the gap visually and closing it for the pointer is why this is a pseudo-element rather than just top:100%. */ body.chrome-v2 .user-pill__menu::before { content: ""; position: absolute; left: 0; right: 0; top: -10px; height: 10px; } /* A little travel room at the sides as well -- the menu is wider than the pill, so a diagonal move toward it can leave the pill before it arrives. */ body.chrome-v2 .user-pill::after { content: ""; position: absolute; top: 100%; right: 0; width: 172px; height: 12px; display: none; } body.chrome-v2 .user-pill:hover::after, body.chrome-v2 .user-pill:focus-within::after { display: block; } body.chrome-v2 .user-pill:hover .user-pill__menu, body.chrome-v2 .user-pill:focus-within .user-pill__menu { display: block; } body.chrome-v2 .user-pill__menu a { display: block; padding: 9px 12px; border-radius: 7px; font-size: 13px; font-weight: 600; text-decoration: none !important; color: var(--theme-submenu-text, #e0e0e0) !important; cursor: pointer; } body.chrome-v2 .user-pill__menu a:hover { background: color-mix(in srgb, var(--theme-accent) 35%, transparent); color: #fff !important; } /* The pill is the only route to logging out under the new look, so it must survive every width. The GREETING collapses on a phone, never the pill itself. */ @media (max-width: 767px) { body.chrome-v2 .user-pill { margin-left: 12px; padding: 6px 9px; } body.chrome-v2 .user-pill__greet { display: none; } body.chrome-v2 .user-pill::before { content: "Account"; font-size: 12px; } } /* Classic only -- the plain greeting label. */ body.chrome-v2 .header-greeting { background: color-mix(in srgb, var(--theme-accent) 9%, transparent); border: 1px solid color-mix(in srgb, var(--theme-accent) 22%, transparent); color: var(--theme-accent); padding: 5px 12px; border-radius: 999px; } /* --------------------------------------------------------------- 2b. No header photo. The whole point of the new look is that identity comes from the client's colours, their kowhaiwhai band and their own words, NOT from a stock photo strip. The ported theme paints homepage-strip-.jpg across #Header_wrapper from an inline rule in Site.Master; !important is needed to beat it because that rule is written later in the document. The image file is left alone: turning the new look off puts the photo straight back. --------------------------------------------------------------- */ body.chrome-v2 #Header_wrapper { background-image: none !important; background-color: transparent !important; height: auto !important; min-height: 0 !important; } /* #Header carries min-height:250px in the ported theme purely to reserve room for that photo strip. With no photo it leaves a blank band, so it collapses to the height of the (position:fixed) top bar, which is the only thing that still needs the space. */ body.chrome-v2 #Header { height: auto !important; min-height: 100px !important; } /* --------------------------------------------------------------- 3. The kowhaiwhai band under the header. Markup is an inline SVG in Site.Master so it can be tinted from the theme vars; this only positions it. --------------------------------------------------------------- */ body.chrome-v2 .v2-band { height: 34px; background: var(--theme-koru-bg, var(--theme-heading-color)); overflow: hidden; line-height: 0; } body.chrome-v2 .v2-band svg { width: 100%; height: 34px; display: block; } /* --------------------------------------------------------------- 4. Buttons. WebForms renders asp:Button as , so these selectors reach every button on every page without a single page being edited. The theme's own button rules use !important, hence the weight here. --------------------------------------------------------------- */ /* NOTE: bare