` is excluded by
* name below as it is measured.
*/
a {
color: #2153CD !important;
}
.img-fluid {
max-width: 100%;
height: auto;
}
.list-group {
display: flex;
flex-direction: column;
padding-left: 0;
margin-bottom: 0;
border-radius: 0.25rem;
}
.table .thead-dark th {
color: #fff;
background-color: #343a40;
border-color: #454d55;
}
.table-borderless th,
.table-borderless td,
.table-borderless thead th {
border: 0;
}
.border-bottom-0 {
border-bottom: 0 !important;
}
.border-success {
border-color: #28a745 !important;
}
.border-danger {
border-color: #dc3545 !important;
}
.align-top {
vertical-align: top !important;
}
/*
* Vuetify's own classes, styled in one place.
*
* These lived in component stylesheets — `.v-btn` in EvidencePage, the dialog
* block in seven separate dialog components. Those blocks are unscoped, so the
* rules already applied to the whole app; they just did it from whenever that
* chunk happened to load. Chunk order is not a design decision.
*
* Each selector that competes with Vuetify repeats its own class once.
* Vuetify's stylesheet is injected at runtime, after this file, so at equal
* specificity Vuetify wins; `.v-btn.v-btn` is 0,2,0 against its 0,1,0 and
* settles it without `!important`. Anchoring on `.v-application` would not
* work — Vuetify teleports overlays into `.v-overlay-container`, a direct
* child of .
*/
.v-btn.v-btn {
text-transform: none;
}
/*
* Tables keep the Vue 2 build's proportions.
*
* Vuetify 2 drew a data table at 48px a row, header included. Vuetify 3 raised
* both: `--v-table-header-height: 56px` and `--v-table-row-height: 52px` at the
* default density (VTable.css:93-96), and no density token gives 48 —
* `comfortable` is 44 and `compact` is 36 — so the variables are named directly
* rather than translated through a prop.
*
* The header's colour moved too: Vuetify 2 drew an unsorted heading at 60%
* black and the sorted one at 87%. Vuetify 3 draws both at the table's own text
* colour, so every heading came out as dark as the sorted one.
*/
.v-table.v-table--density-default {
--v-table-header-height: 48px;
--v-table-row-height: 48px;
}
/*
* A table's text is 12px, as the Vue 2 build draws it. Vuetify 3's `.v-table`
* sets `0.875rem`, so on /table both the cells and the headings came out 14px
* against the Vue 2 build's 12px — the whole table two pixels large.
*
* Set on the table rather than on the cells on purpose. Vuetify gives `th`
* `font-size: inherit` (VTable.css:84-89), so the size flows down from here to
* both, and a screen that sizes its own cells still wins by saying so.
*
* The heading's weight needs a selector of its own, below.
*/
.v-table.v-table {
font-size: 12px;
}
/*
* A heading is 700, as the Vue 2 build drew it — without flattening the screens
* that say otherwise.
*
* Vuetify sets `font-weight: 500` on
* `.v-table > .v-table__wrapper > table > thead > tr > th`, which is (0,2,4).
* An earlier revision recorded this as unreachable, on the reasoning that
* beating it needs (0,3,4) and that would also outrank the components with
* their own heading weight.
*
* That was wrong, and the mistake was assuming a stronger selector has to mean
* *more classes*. Specificity compares classes first and elements only as a
* tiebreak, so adding two element names — the two `div`s Vuetify leaves
* implicit — gives (0,2,6): above Vuetify's (0,2,4), still below any rule with
* a third class.
*
* Twelve component rules set a heading weight. Sorted against Vuetify's
* (0,2,4), they fall into three groups:
*
* still win, on specificity
* (0,4,2) .workflow-container … .business-process-container / .archived-…
* (0,3,2) .training-code-container .code-list-container … (two rules)
* (0,3,2) .workflow-container .all-task-container …
* still win, on !important
* (0,2,2) .audit-container .content-table thead th
* (0,2,2) .notification-page-container .content-table thead th
* already lost to Vuetify before this rule existed
* (0,2,3) .table-comp-container .jss > thead > tr > th
*
* So this takes nothing from any rule that still had it.
*
* A fourth group has since been emptied, and the reasoning that put it here was
* wrong. `.platform-permission-container`, `.doc-setting-container` and
* `.preset-container` were listed at (0,2,2) as having already lost to Vuetify —
* true, but the Vue 2 build draws all three at **600**, so letting this rule
* override them diverged from parity rather than restoring it. Each was measured
* against the Vue 2 build and raised in its own component to (0,3,2)/(0,3,3) by
* nesting under a class already in the DOM: the permission page in one cycle,
* doc-setting and preset in another, after `/settings/version` reported 700
* against the Vue 2 build's 600.
*
* The list is scraped from every `\3c style>` block in `resources/js`, not from
* the routes that happened to be open. An earlier revision of this comment
* named five rules and called them all of them — they were simply the ones
* whose chunks had loaded.
*/
div.v-table > div.v-table__wrapper > table > thead > tr > th {
font-weight: 700;
}
.v-data-table__th.v-data-table__th {
color: rgba(0, 0, 0, 0.6);
}
/*
* A heading is grey, as the Vue 2 build drew it — including the ones the app
* writes by hand.
*
* Vuetify 2 coloured a table heading itself:
* `.theme--light.v-data-table > .v-data-table__wrapper > table > thead > tr >
* th { color: rgba(0, 0, 0, .6) }`, (0,3,4). Vuetify 3's VTable has **no**
* `thead th` colour rule at all — a heading simply inherits `.v-table`'s
* on-surface. Nothing replaced it, and that let `app.scss`'s
* `[class*='text-']` rule through: 147 `` in this app carry `text-left`,
* `text-center` or `text-right` for alignment, and each of them came out
* `#36405a`.
*
* Measured on `/settings/subscription` and `/settings/pricing`, where a rule
* dump over every sheet shows the whole story: on the Vue 2 build the only
* colour rule matching `th.text-left` is Vuetify's own, at `rgba(0, 0, 0, .6)`;
* here the only one matching is `.v-application [class*='text-']`, at
* `rgb(54, 64, 90)`. On the pricing table the heading also carries the
* "Billing Frequency" `` inside it, which inherited the navy with it.
*
* (0,2,6) for the same reason the weight rule above is: it clears
* `[class*='text-']`'s (0,2,0) — specificity compares classes first, so the
* two implicit `div`s are enough — while every screen that states a heading
* colour of its own does so with three classes (`TrainingCode.vue`'s
* `.code-list-container`, `Settings.vue`'s `.doc-setting-container`,
* `PresetSetting.vue`'s `.preset-container`, all (0,3,2)) and still wins.
* `.text-black`, which `DocNumberFormat.vue` puts on eight headings, is
* Vuetify's own utility and carries `!important`, so those stay black.
*/
div.v-table > div.v-table__wrapper > table > thead > tr > th {
color: rgba(0, 0, 0, 0.6);
}
/*
* A sorted heading stays darker, above the rule just added — hence the third
* class: (0,3,0) beats (0,2,6) on class count, and still loses to the (0,3,2)
* screen rules, which is where it sat before.
*/
.v-data-table__th--sorted.v-data-table__th--sorted.v-data-table__th--sorted {
color: rgba(0, 0, 0, 0.87);
}
/*
* A data-table cell is navy, as the Vue 2 build drew it.
*
* The same `app.scss` rule, from the other side. Vuetify 2 gave every cell it
* generated an alignment class — `text-start` by default — and
* `[class*='text-']` painted it `#36405a`; that is where this app's tables get
* their body colour, not from any rule of their own. Vuetify 3 renames the
* class `v-data-table-column--align-start`, the app rule stops matching, and
* the cell falls back to `.v-table`'s on-surface `rgba(0, 0, 0, .87)`.
* Measured on `/training-code`'s report table and again on
* `/settings/company-information`'s departments table.
*
* Keying on the renamed classes restores exactly the cells that had it: a
* `
` inside it, which inherited the navy with it.
*
* (0,2,6) for the same reason the weight rule above is: it clears
* `[class*='text-']`'s (0,2,0) — specificity compares classes first, so the
* two implicit `div`s are enough — while every screen that states a heading
* colour of its own does so with three classes (`TrainingCode.vue`'s
* `.code-list-container`, `Settings.vue`'s `.doc-setting-container`,
* `PresetSetting.vue`'s `.preset-container`, all (0,3,2)) and still wins.
* `.text-black`, which `DocNumberFormat.vue` puts on eight headings, is
* Vuetify's own utility and carries `!important`, so those stay black.
*/
div.v-table > div.v-table__wrapper > table > thead > tr > th {
color: rgba(0, 0, 0, 0.6);
}
/*
* A sorted heading stays darker, above the rule just added — hence the third
* class: (0,3,0) beats (0,2,6) on class count, and still loses to the (0,3,2)
* screen rules, which is where it sat before.
*/
.v-data-table__th--sorted.v-data-table__th--sorted.v-data-table__th--sorted {
color: rgba(0, 0, 0, 0.87);
}
/*
* A data-table cell is navy, as the Vue 2 build drew it.
*
* The same `app.scss` rule, from the other side. Vuetify 2 gave every cell it
* generated an alignment class — `text-start` by default — and
* `[class*='text-']` painted it `#36405a`; that is where this app's tables get
* their body colour, not from any rule of their own. Vuetify 3 renames the
* class `v-data-table-column--align-start`, the app rule stops matching, and
* the cell falls back to `.v-table`'s on-surface `rgba(0, 0, 0, .87)`.
* Measured on `/training-code`'s report table and again on
* `/settings/company-information`'s departments table.
*
* Keying on the renamed classes restores exactly the cells that had it: a
* `` the app writes by hand carries no alignment class on either build and
* stays `rgba(0, 0, 0, .87)` — `/compliance/index` and the team-member table
* read that on both. `td` on purpose, because Vuetify 3 puts `v-data-table__td`
* on the header cells too, and those are grey above.
*
* Matched by prefix, not by the three names, because `align` is not always an
* alignment: `CompanyInformation.vue` passes `align: 'd-none d-lg-table-cell'`
* to hide a column below `lg`, and Vuetify interpolates whatever it is given —
* `text-d-none d-lg-table-cell` on the Vue 2 build, where the app rule matched
* it like any other, and `v-data-table-column--align-d-none d-lg-table-cell`
* here. Listing `start`/`center`/`end` left that column at `rgba(0, 0, 0, .87)`
* beside its navy neighbours. A substring match is also what it is translating:
* `[class*='text-']` is one itself.
*
* (0,2,1): a class heavier than nothing, a hair below the (0,2,2) screen rules
* that already colour their own cells.
*/
td.v-data-table__td[class*=v-data-table-column--align-] {
color: #36405a;
}
/*
* An input at the default density keeps the Vue 2 build's height.
*
* 140 of the app's 722 input call sites pass no `dense`. Measured on two of
* their screens — the profile form and the audit-trail filters — each was 16px
* taller here. Measured on the profile form, where five fields stack:
*
* Vue 2 before after
* control 32px 48px 32px
* details 22px 22px 22px
* total 54px 70px 54px
*
* The reserved message line was already right; only the control was wrong, and
* `--v-input-control-height` alone does not move it. VField.css:140 reads
*
* min-height: max(var(--v-input-control-height, 56px),
* 1.5rem + var(--v-field-input-padding-top)
* + var(--v-field-input-padding-bottom));
*
* and at this density the second term is 24 + 20 + 4 = 48, so it wins whatever
* the token says. Both terms have to come down together.
*
* The variant is named because Vuetify's own rule names it —
* `.v-input--density-default .v-field--variant-underlined` sets the 48px
* (VField.css:99-103) at the same specificity, and would otherwise win on
* order. Naming it also makes the target exact: 32px with 4px of padding is
* precisely what Vuetify 3 calls a *compact* underlined field
* (VField.css:110-114). The Vue 2 build's ordinary input is Vuetify 3's
* compact one.
*
* Scoped to fields with no floating label — `--no-label` and `--single-line`,
* which is what a placeholder-only field renders as. A field with a label needs
* that top padding to have somewhere to put it, and shrinking it would print
* the label over the value.
*
* `density-compact` is untouched: the other 582 call sites are what `dense`
* maps to and already land within 2px of the Vue 2 build.
*/
.v-input--density-default.v-input--plain-underlined {
--v-input-padding-top: 4px;
}
.v-input--density-default .v-field--no-label.v-field--variant-underlined,
.v-input--density-default .v-field--single-line.v-field--variant-underlined {
--v-input-control-height: 32px;
--v-input-padding-top: 4px;
--v-field-input-padding-top: 4px;
--v-field-input-padding-bottom: 4px;
}
/*
* A selection control reserves no room for a message it does not have.
*
* Vuetify 3 gives every input a 22px `.v-input__details` unless the call site
* says `hide-details`. A dense switch on the Vue 2 build is 24px, with no
* details block at all, so the block is collapsed here.
*
* 28 call sites are affected: the 7 switches and 21 checkboxes that pass no
* `hide-details`. The other 109 already opt out.
*
* `min-height: 0` rather than `display: none`, so a control that really does
* have a validation message still grows to show it. Note that the
* `.v-messages` inside keeps its own 14px floor — this collapses the padding
* around it, not the line itself.
*
* The reasoning first written here was wider than the measurement: it said
* Vuetify 2 reserved no message space for *selection controls*, generalised
* from the switch. Checkboxes that pass no `hide-details` do reserve it — the
* docgen list's are 50px on the Vue 2 build, 24 of row plus 14 of message line
* plus margins. Keeping this rule leaves them 8px over; dropping it would leave
* them 16px over, so it stays, and the claim is narrowed to what was measured.
*/
.v-checkbox .v-input__details,
.v-switch .v-input__details,
.v-radio-group .v-input__details {
min-height: 0;
padding-top: 0;
}
/*
* A validation message sits where the Vue 2 build put it.
*
* Vuetify 3 gives every `.v-input__details` a 22px box with `padding-top: 6px`
* and `align-items: flex-end` (VInput.css:50), and `.v-text-field` insets it by
* 16px (VTextField.css:36) — except under `.v-input--plain-underlined`, which
* zeroes the inset again (line 39). The Vue 2 build's enclosed fields used a 14px box
* with no padding above it, 12px of inset and 8px of clearance below. On
* /login the message lands at x 1500 / y 149.91 there and x 1504 / y 157.91
* here: 8px low and 4px right. The field's total height already agrees — 14
* plus 8 of margin is the same 22 — so only the message inside it moved.
*
* Scoped to the enclosed variants on purpose. Read off the Vue 2 build by
* constructing each field shape in the live page, its underlined default took
* `padding: 0` and no margin where its outlined/solo/filled fields took
* `0 12px` and `margin-bottom: 8px`. One blanket rule would be right for the
* app's 524 enclosed call sites and wrong for its 212 underlined ones.
*
* The variant class lives on `.v-field`, not on `.v-input`, so the selector has
* to reach down for it — there is no flat hook for "enclosed". `:has()` takes
* the specificity of its most specific argument, which puts this at 0,4,0
* against Vuetify's 0,2,0 and settles it without `!important`.
*
* The underlined field's own 22-against-14 was left alone here at first, on
* the reasoning that Vuetify 2 also gave it `padding-top: 12px; margin-top:
* 4px` on `.v-text-field` itself, which Vuetify 3 does not, so closing the 8px
* at the bottom would only half-fix it. The two halves are independent: on
* `/activate-account` (and 65 of the app's 103 underlined fields with a
* message line) the screen zeroes the top with `pt-0 mt-0`, and the 8px at
* the bottom was the whole of the difference — the message 44px below the
* field's top against the Vue 2 build's 36, the card 6px taller. The rule
* after this one closes the bottom; the 12+4 above the field is still not
* restated, and is recorded as its own pass.
*/
.v-input:has(> .v-input__control > .v-field--variant-outlined,
> .v-input__control > .v-field--variant-filled,
> .v-input__control > .v-field--variant-solo,
> .v-input__control > .v-field--variant-solo-filled,
> .v-input__control > .v-field--variant-solo-inverted) > .v-input__details {
align-items: stretch;
margin-bottom: 8px;
min-height: 14px;
padding-top: 0;
padding-inline: 12px;
}
/*
* The underlined details box, Vuetify 2's: 14px, `padding: 0`, no margin
* (`.v-text-field__details` without the `--enclosed` rule, read off the stable
* bundle). Same key and weight as the enclosed rule above.
*/
.v-input:has(> .v-input__control > .v-field--variant-underlined) > .v-input__details {
align-items: stretch;
min-height: 14px;
padding-top: 0;
}
/*
* A field showing a message keeps its distance from it.
*
* The other half of the rule above, found on the checkout's promo code field:
* type a code that does not exist and "Code Invalid" prints hard against the
* box. Measured there —
*
* field bottom to message top | Vue 2 4px | this build 0
* whole input | Vue 2 66 | this build 62
*
* Vuetify 2 put that space under the field itself: `.v-input__slot` carried
* `margin-bottom: 8px`, `4px` under `dense` and `0` under `hide-details`
* (vuetify.css:20740-20757). Vuetify 3 declares none, so its details box butts
* against the field. The 8 below the message that the rule above restores was
* only ever the second of the two gaps.
*
* Three choices, each measured rather than picked:
*
* - **on `.v-field`**, not on `.v-input__details`. Seven login screens set
* `.v-field { margin-bottom: 4px !important }` themselves — it is how
* `/login` already looks right — and a parity margin on any other element
* would *add* to theirs, taking that field to 70 against the Vue 2 build's
* 66. Same element, same property, same 4px: the screen's `!important`
* wins and nothing moves.
* - **keyed on `:has(> .v-input__details)`**, which is Vuetify 3's own way of
* saying the field is showing something: `hide-details` renders no details
* element, and that is exactly the case Vuetify 2 zeroed. Confirmed on the
* Vue 2 build by clearing the promo code — the margin drops to 0 and the
* field returns to 40.
* - **every variant.** Vuetify 2's `.v-input__slot { margin-bottom: 8px }`
* was not scoped to the enclosed ones; this rule was, while the
* underlined details box was still deferred. Now that it is Vuetify 2's
* too, the underlined field takes the same clearance (the login screens'
* own `.v-field { margin-bottom: 4px !important }` still wins on theirs).
*/
.v-input:has(> .v-input__details):has(> .v-input__control > .v-field--variant-outlined,
> .v-input__control > .v-field--variant-filled,
> .v-input__control > .v-field--variant-solo,
> .v-input__control > .v-field--variant-solo-filled,
> .v-input__control > .v-field--variant-solo-inverted,
> .v-input__control > .v-field--variant-underlined) > .v-input__control > .v-field {
margin-bottom: 8px;
}
.v-input--density-compact:has(> .v-input__details):has(> .v-input__control > .v-field--variant-outlined,
> .v-input__control > .v-field--variant-filled,
> .v-input__control > .v-field--variant-solo,
> .v-input__control > .v-field--variant-solo-filled,
> .v-input__control > .v-field--variant-solo-inverted,
> .v-input__control > .v-field--variant-underlined) > .v-input__control > .v-field {
margin-bottom: 4px;
}
/*
* A field aligns its own text, whatever the column around it is doing.
*
* Vuetify 2 declared `text-align: left` on `.v-input` — verified by putting a
* bare `.v-input` inside a centred host on the Vue 2 build, where it computes
* `left` while `.v-text-field` and `.v-select` alone inherit `center`, so the
* declaration is on `.v-input` and nothing else. Vuetify 3 declares none, and
* the login form's `text-center` column (`Login.vue:76`) five levels up
* inherits straight through: "E-mail must be valid" was painting centred at
* x 1621.41 where the Vue 2 build starts it flush at x 1500.
*
* One class, not two. Vuetify 3 has no competing declaration, and every rule in
* the app that deliberately centres a field's text — the OTP dialog,
* `.centered-input`, the approval dialog — targets the `input` element itself
* and so already outranks this, exactly as it had to on the Vue 2 build.
*
* `left` rather than `start` because that is the value Vuetify 2 shipped; the
* app renders LTR only.
*/
.v-input {
text-align: left;
}
/*
* A placeholder is the colour it was written to be, not 38% of it.
*
* Vuetify 3 dims every field's placeholder — `opacity: var(--v-disabled-opacity)`
* on `.v-field__input input::placeholder` (VField.css:163). Vuetify 2 dimmed
* none. The app names its own #bbb and both builds compute exactly that, so the
* colour already agreed; the login placeholders were simply being painted at 38%
* of it, which over white reads as roughly #e8e8e8.
*
* The colour is named as well, and the first version of this rule was wrong to
* leave it out. Vuetify 2's placeholder was `rgba(0, 0, 0, 0.38)`; Vuetify 3's
* is `currentColor`, so lifting the opacity alone left every placeholder the
* app does *not* colour sitting at full-strength body text — the signature
* dialog's "Write here…" came out #36405a against the Vue 2 build's 38% black.
* Where the app does name a colour, as /login does with #bbb, its own rule
* still outranks this one and the opacity is what it needed.
*/
.v-field .v-field__input input::-moz-placeholder, .v-field input.v-field__input::-moz-placeholder, .v-field textarea.v-field__input::-moz-placeholder {
color: rgba(0, 0, 0, 0.38);
opacity: 1;
}
.v-field .v-field__input input::placeholder,
.v-field input.v-field__input::placeholder,
.v-field textarea.v-field__input::placeholder {
color: rgba(0, 0, 0, 0.38);
opacity: 1;
}
/*
* A field insets its contents the way the Vue 2 build inset them.
*
* This is the same 12-against-16 as the validation message one rule above, on
* the line directly over it: Vuetify 3 holds the inset in
* `--v-field-padding-start` / `-end`, defaulted to 16px on `.v-field`
* (VField.css:14-15), where every enclosed Vuetify 2 field used 12px. On
* /login it puts the placeholder's first glyph at 1504 against 1500.
*
* Vuetify 3 also adds a 6px gap either side of an inner icon
* (`.v-field--prepended { --v-field-padding-start: 6px }`, VField.css:120-125).
* Vuetify 2 added none: an inner icon took exactly its own 24px and the text
* began immediately after it. That rule outranks the variant selectors above,
* so it is answered at its own weight rather than by widening theirs.
*
* Read off the Vue 2 build by constructing each field shape in the live page
* and measuring from the field box's edge — not from a changelog:
*
* | text left | gap to right edge
* enclosed | 12 | 12
* prepended | 36 | 12 (12 + the icon's 24 + nothing)
* appended | 12 | 36
* underlined | 0 | 0
* und. prep. | 24 | 0 (0 + 24 + nothing)
*
* Simulated against real Vuetify 3 before writing: all five land on those
* numbers exactly, the floating label follows the text from 16 to 12, and no
* field changes height. The underlined default is already 0 and stays there —
* only its prepended form moves, from 30 to 24.
*
* Each selector repeats a class: this file loads before Vuetify's, so
* `.v-field--variant-outlined` alone would tie with `.v-field` and lose, and
* the icon rules need one more again to outrank Vuetify's own `.v-field.v-field--prepended`.
*/
.v-field.v-field--variant-outlined,
.v-field.v-field--variant-filled,
.v-field.v-field--variant-solo,
.v-field.v-field--variant-solo-filled,
.v-field.v-field--variant-solo-inverted {
--v-field-padding-start: 12px;
--v-field-padding-end: 12px;
}
.v-field.v-field--prepended.v-field--prepended {
--v-field-padding-start: 0;
}
.v-field.v-field--appended.v-field--appended {
--v-field-padding-end: 0;
}
/*
* A busy spinner has no track behind it, as the Vue 2 build's had none.
*
* Vuetify 3's VProgressCircular always renders two circles — an underlay at
* `rgba(0, 0, 0, 0.12)` and the coloured overlay that sweeps. Vuetify 2's
* indeterminate spinner rendered *only* the overlay: read off the live Vue 2
* page, its markup is `svg > circle.v-progress-circular__overlay` and the
* underlay element is not in the DOM at all. So every loading spinner in this
* build gained a grey ring the Vue 2 build never drew — on `/reset-password`,
* a 64px track around a white arc on a grey scrim.
*
* Scoped to `--indeterminate`, which is what 134 of the app's 136 call sites
* pass. The other two bind `:model-value` — a real progress ring, where the
* track is the point and where there is no Vue 2 rendering to measure against,
* so they are left alone rather than guessed at.
*
* `display: none` because the Vue 2 build renders no element; the box, the
* stroke width and the colour already agree.
*/
.v-progress-circular--indeterminate .v-progress-circular__underlay {
display: none;
}
/*
* A list row that was written as an icon beside a title still reads as a row.
*
* Vuetify 2's `.v-list-item` was a flex row, so `` wraps the whole panel. Measured there
* against the Vue 2 build, every label and value: "Document Name" 12px/600 →
* 12px/400, "test (2)" 14px/600 opacity 1 → 14px/400 opacity 0.6 — fourteen
* rows of it, and the value rows visibly paler as well as lighter.
*
* `inherit` rather than a number, because that is what Vuetify 2 left behind: a
* list with no opinion still lands on the app's 400, and one with an opinion
* keeps it. Stated before the dense-list rule further down, which names
* Vuetify 2's own `font-weight: 500` for a compact title and still wins on
* source order.
*/
.v-list-item-title.v-list-item-title,
.v-list-item-subtitle.v-list-item-subtitle {
font-weight: inherit;
}
.v-list-item-subtitle.v-list-item-subtitle {
opacity: 1;
}
/*
* …and it does not clip what the Vue 2 markup hung outside it.
*
* The same wrapper as the rule above, a second consequence. Vuetify 3's
* `.v-list-item__content` carries `overflow: hidden`; Vuetify 2 had no such box
* at all, so a child could sit left of the row's padding and still be drawn.
* The sidebar does exactly that: `Header.vue`'s `.lib-menu` takes
* `margin-left: -14px` to hang each expand arrow outside the label column.
*
* Measured on the expanded sidebar, 11 arrows — Library, Academy and every
* folder in the tree — sit at x 18 or 20 against a content box starting at 32
* or 34, so all eleven were cut away. Their geometry never changed: the boxes
* are identical on both builds, only the paint was missing, which is why the
* guard asserts that the arrow is the element at its own centre rather than
* asserting a position.
*
* Safe to relax because `.v-list-item-title` truncates itself — measured
* `overflow: hidden; text-overflow: ellipsis; white-space: nowrap` — so the
* content box's clipping is not what the app's ellipsis depends on. Keyed, like
* the rule above, on a box holding something that is not one of Vuetify 3's own
* title/subtitle children: that is the shape Vue 2 markup produces, and a box
* holding only a title and a subtitle keeps Vuetify's clipping untouched.
*/
.v-list-item__content:has(> :not(.v-list-item-title):not(.v-list-item-subtitle)) {
overflow: visible;
}
/*
* An icon paints itself, as Vuetify 2's did.
*
* Vuetify 2's `.v-icon` declared `color: rgba(0, 0, 0, 0.54)`. Vuetify 3's
* declares no colour at all (VIcon.css:1-17) and inherits, so every icon the
* call site does not colour picks up whatever the surrounding text is — in this
* app usually #36405a. Counted on the dashboard: 10 icons came out navy and
* four at 0.87 where the Vue 2 build painted twelve at 0.54. The Academy
* fly-out's row icons are the ones that were reported.
*
* One class, deliberately — the same weight Vuetify 2 used. Everything that
* outranked it there still outranks it here: the app bar's white icons, the
* sidebar's `.active i { color: #1890FF !important }`, a `color` prop, an
* inline style. Adding weight would fix nothing and would start overriding
* rules the Vue 2 build let through.
*
* Vuetify 3's disabled icons stay on `opacity: 0.38` rather than Vuetify 2's
* 0.38 *colour*; they paint the same and are left alone.
*/
.v-icon {
color: rgba(0, 0, 0, 0.54);
}
/*
* …and a field does not fade them on top of that.
*
* Vuetify 3 washes an input's own icons out:
* `.v-field__prepend-inner > .v-icon, .v-field__append-inner > .v-icon,
* .v-field__clearable > .v-icon { opacity: var(--v-medium-emphasis-opacity) }`
* (VField.css:231-234), which is 0.6. Vuetify 2 had no such rule — an icon was
* the colour it was given, and the rule above gives every icon Vuetify 2's own
* `rgba(0, 0, 0, 0.54)`. Stacked, that lands at roughly 0.32.
*
* Counted on `/library`: eight field icons on the Vue 2 build, seven at 0.54
* and the search bar's magnifier at `var(--text-dark-3)`, every one of them at full
* strength; the same eight here, the same colours, all at 0.6. The select
* arrows are the ones on every screen.
*
* The class is repeated because this file loads before Vuetify's: at equal
* weight the later sheet would win.
*
* Vuetify 3 already returns to 1 for a disabled, errored or focused field, so
* those cases are unchanged.
*/
.v-field__prepend-inner > .v-icon.v-icon,
.v-field__append-inner > .v-icon.v-icon,
.v-field__clearable > .v-icon.v-icon {
opacity: 1;
}
/*
* …but an icon inside a button still inherits the button's colour.
*
* The companion to the rule above, and the half its first version was missing.
* Vuetify 2 shipped `.v-btn > .v-btn__content .v-icon { color: inherit }`, so
* the 0.54 default stopped at a button's edge. Vuetify 3 has no such rule, so
* once `.v-icon` carried a colour of its own, every icon in a button took it —
* measured on the profile page, the avatar's edit pencil sits in a white-on-
* scrim overlay button and came out `rgba(0, 0, 0, 0.54)` against the Vue 2
* build's white, which is to say invisible.
*/
.v-btn > .v-btn__content .v-icon {
color: inherit;
}
/*
* A prepended widget sits where Vuetify 2 put it.
*
* Vuetify 2's `.v-input__prepend-outer` took `margin-top: 4px`,
* `margin-right: 9px`, no padding, and inherited `line-height: 1`. Vuetify 3's
* `.v-input__prepend` is padded 8px at the top, sits 16px away, aligns to
* flex-start and inherits 1.5. On the profile page that pushed the phone
* field's country selector out of line with the number beside it:
*
* | Vue 2 build | before
* prepend / dropdown y | 328 | 332
* dropdown height | 28 | 33.2
* "+62" y / height | 335 / 14 | 339 / 19.2
* number input x / width | 382.5 / 312 | 389.5 / 305
*
* The line-height is the half that is easy to miss: it is what grew the tel
* widget's own boxes by 50%, and no amount of margin would have straightened
* that.
*
* Both classes are doubled to reach (0,4,0). Vuetify claims this element from
* two directions — `.v-input--horizontal .v-input__prepend` at two classes, and
* `.v-input--density-default.v-input--plain-underlined .v-input__prepend` at
* three, which is the one that reinstated the 8px padding once the field left
* its disabled state. Three classes only tie with that, and Vuetify's sheet is
* injected after this file.
*/
.v-input.v-input .v-input__prepend.v-input__prepend {
align-items: flex-start;
line-height: 1;
margin-top: 4px;
margin-inline-end: 9px;
padding-top: 0;
}
/*
* A card in a dialog that the markup laid out as a row is a row.
*
* Both Vuetify versions leave `.v-card` itself `display: block`, so
* `class="d-flex"` alone makes it a flex row — that part did not change, and a
* first draft of this rule claimed it had. What Vuetify 3 added is a dialog
* rule: `.v-dialog > .v-overlay__content > .v-card` and its `> form > .v-card`
* sibling both set `flex-direction: column` at (0,3,0) and (0,3,1). A `d-flex`
* card inside a dialog therefore stacks, and `.d-flex` only sets `display`.
*
* The signature-limit dialog is one of them: its warning icon sat above the
* heading instead of beside it, at (40, 52) from the dialog's corner against
* the Vue 2 build's (54, 32). 59 call sites put `d-flex` on a card without
* `flex-column`; the ones inside dialogs are the ones this reaches.
*
* Deliberately not `!important`: `.flex-column` is, so a call site that asks
* for a column keeps getting one no matter how specific this rule is.
*/
.v-dialog > .v-overlay__content > .v-card.d-flex,
.v-dialog > .v-overlay__content > form > .v-card.d-flex {
flex-direction: row;
}
/*
* A checkbox is the size the Vue 2 build drew it — the tick, not a floor.
*
* An earlier cycle read this as a control-height problem: `/evidence/detail/121`
* stacks 67 checkboxes at 44px on the Vue 2 build and drew them at 56 here, so
* `--v-input-control-height` was pinned to 44 and the row came right. The tick
* was left alone, explicitly — "the tick itself is untouched".
*
* That was the wrong half. Measured again, on two screens instead of one:
*
* Vue 2 with the 44px floor
* /evidence/detail/121 44 row, 40 control 44 row, 44 control
* /library/evidence-… 36 row, 24 control 58 row, 44 control
* both screens 24x24 tick, 8px gap 40x40 tick, no gap
*
* The tick was the defect all along. Vuetify 2 drew a 24x24 tick at *every*
* density with 8px to its label; Vuetify 3 draws `--v-selection-control-size`,
* 40px at the default density, and dropped the gap. The floor then hid the
* error on one screen and created a new one on the other — the second screen's
* checkbox has a short label, so the Vue 2 build's row is the tick's own 24px
* and a 44px floor stands it 20px too tall, 65 times down one list.
*
* So the floor goes and the tick comes back. With it, `/evidence/detail/121` is
* unchanged at 44 — its height comes from its own wrapping label, not from the
* floor, which is why lifting the floor moves it by nothing — and
* `/library/evidence-submission` falls from 58 to 38 against the Vue 2 build's
* 36.
*
* The 20px glyph is Vuetify 2's `v-icon--dense`, which it gave to a selection
* control in a dense input; the fill is its
* `.v-input--selection-controls__input .v-icon { width: 100% }`, without which
* the icon cycle's `width: auto` base shrinks the box to the glyph.
*
* The floor becomes the tick's own 24px rather than going away. Vuetify writes
* `min-height: var(--v-input-control-height)` on the selection control itself
* (VCheckbox.css:4-6) and the token is a density default — 56px, 48, 40
* (VInput.css:11-24) — so deleting the declaration does not remove the floor, it
* hands it back to Vuetify: measured, both screens end up worse than they
* started, at 70 and 56. 24px says what is actually true, that a checkbox
* control cannot be shorter than its tick, and lets everything above that come
* from the content the way Vuetify 2 did. Measured identical to `0px` on both
* screens, and stated instead of it.
*
* Same rules as `.v-radio` below, on the class Vuetify 3 puts the selection
* control on for a checkbox (`.v-checkbox-btn`). Switches keep their own block:
* they are measured, closed, and a different shape.
*/
.v-checkbox.v-checkbox {
--v-input-control-height: 24px;
}
.v-checkbox-btn.v-checkbox-btn {
--v-selection-control-size: 24px;
}
.v-checkbox .v-selection-control__wrapper {
margin-right: 8px;
}
.v-checkbox .v-selection-control__input > .v-icon {
width: 100%;
height: 100%;
}
.v-checkbox-btn.v-selection-control--density-compact .v-icon {
font-size: 20px;
}
.v-checkbox.v-checkbox .v-label {
height: auto;
}
/*
* The same, one density down. `dense` maps to `density-compact`, and Vuetify 3
* gives a compact underlined field a 32px floor where the Vue 2 build had none
* at all — its dense field was purely content-sized, 26px for a 12px line.
* Measured on /workflow's three filter fields: 26px there, 32px here.
*
* The floor is `max(--v-input-control-height, 1.5rem + the field's padding)`,
* so 26 needs the padding at zero as well — 1.5rem is 24, and the text is
* centred by the field rather than by that padding.
*
* Selects were excluded here for one revision, on the reasoning that a dense
* select is taller than a dense text field. Measured, that is a per-screen
* difference rather than a per-component one — /workflow's dense selects are
* 26px on the Vue 2 build and /audit-trail's are 42px — and the exclusion left
* more total drift than it removed. It is gone.
*/
.v-input--density-compact .v-field--no-label.v-field--variant-underlined,
.v-input--density-compact .v-field--single-line.v-field--variant-underlined {
--v-input-control-height: 26px;
--v-input-padding-top: 0px;
--v-field-input-padding-top: 0px;
--v-field-input-padding-bottom: 0px;
}
/*
* `d-flex` on a list item still lays out what the item contains.
*
* Vuetify 2's `VListItem` put the default slot's children directly inside the
* item, so a call site could write `d-flex` on the item and lay them out in a
* row. Eleven do — the user menu, the library header's three menus, the academy
* category list, and two menus that space their children apart.
*
* Vuetify 3 wraps the slot in `.v-list-item__content`. The item is still the
* flex container, but its flex children are now Vuetify's own `__overlay`,
* `__underlay` and `__content` — the call site's elements are one level deeper,
* inside a block. So they stack: the academy's "Food Safety" and "(3)" went
* from one 18px line to two, and the count dropped under the name.
*
* The layout is handed down to the wrapper rather than restated. `inherit`
* takes each value from the item itself, so `justify-space-between` and
* `align-center` keep working at the call sites that wrote them, and a future
* one needs no addition here.
*/
.v-list-item.d-flex > .v-list-item__content,
.v-list-item.d-inline-flex > .v-list-item__content {
display: flex;
flex: 1 1 auto;
flex-direction: inherit;
align-items: inherit;
justify-content: inherit;
gap: inherit;
}
/*
* A disabled button stops wearing its enabled colour.
*
* Vuetify 2 gave `color` to the button as a *class*, and greyed a disabled one
* with `!important` — so the colour lost, whatever it was. Vuetify 3 writes
* `color` as an **inline style**, and dropped the `!important`. Inline beats
* every rule, so the enabled colour now survives being disabled: the
* reinitialise button on a workflow keeps `background-color: #fff` and
* `color: #000`, and Vuetify 3's disabled overlay — which lays `currentColor`
* at 46% and is calibrated for its own `rgba(on-surface, .26)`, giving exactly
* Vuetify 2's 12% grey — instead multiplies full black and paints the button
* four times too dark.
*
* Demonstrated rather than assumed: applying this branch's inline style to the
* same disabled button on the Vue 2 build changes nothing at all.
*
* 275 buttons across 96 files carry a colour and can be disabled, 37 of them
* with an inline text colour written at the call site. Fixing them one by one
* would mean 275 edits that a 276th call site would silently miss.
*
* `!important` is not a shortcut here — it is the only thing that outranks an
* inline style, and it is what Vuetify 2 itself used.
*
* The background is Vuetify 2's own `rgba(0, 0, 0, 0.12)`, read off the Vue 2
* build by constructing the classes there. This rule first used Vuetify 3's
* surface colour instead, reasoning that its disabled overlay "lays
* `currentColor` at 46% ... giving exactly Vuetify 2's 12% grey". Measured
* afterwards that is false: with the button's colour still white, the overlay
* computed `rgb(255, 255, 255)` at 46%, so it lightened. Surface white under a
* white overlay is white, and the profile screen's disabled Confirm button was
* reported as simply not being there — it was there, on a white card.
*
* That reading expired the moment this rule set the colour to
* `rgba(0,0,0,.26)`: the overlay takes `currentColor`, so it now paints black
* and *darkens*. The rule below removes it. Leaving the old sentence standing is
* what let that hide for two cycles — it read as though the overlay had already
* been accounted for.
*
* (0,4,0), Vuetify 2's own weight: its rule was
* `.theme--light.v-btn.v-btn--disabled.v-btn--has-bg`. This one first sat at
* (0,2,0) `!important`, which ties with a screen's `.reset__container
* .submit-btn { background-color: … !important }` and loses on order — on
* `/activate-account` a mistyped email left the disabled button bright green
* with faint text, and four login screens carry that same rule. At Vuetify 2's
* weight a screen rule that lost to it there loses here, and one that tied
* there (`PublicLoginDialog`'s `.v-theme--light.v-btn.submit-btn.v-btn--disabled`,
* (0,4,0), later in order) still wins.
*/
.v-theme--light.v-btn.v-btn--disabled.v-btn--variant-elevated,
.v-theme--light.v-btn.v-btn--disabled.v-btn--variant-flat {
color: rgba(var(--v-theme-on-surface), 0.26) !important;
background-color: rgba(0, 0, 0, 0.12) !important;
}
/*
* …and nothing is laid over that background, because Vuetify 2 laid nothing.
*
* Vuetify 3 renders a `` inside every button and
* raises it to `opacity: 0.4615` for a disabled elevated or flat one, filled
* with `currentColor` — which the rule above sets to `rgba(0,0,0,.26)`. The Vue
* 2 build has no such element:
*
* | background | overlay | composited
* Vue 2 build | rgba(0,0,0,.12) | none | 0.12
* before this | rgba(0,0,0,.12) | rgba(0,0,0,.26) @.46 | 0.226
*
* Nearly twice the ink. Measured on `/settings/version?tab=visibility`, whose
* Delete and Edit setting buttons matched the Vue 2 build on **every computed
* property** — colour, background, opacity, size — and still drew darker. The
* extra element is what the comparison missed, which is the lesson worth keeping:
* equal computed values are not equal paint when the markup differs.
*
* (0,4,0) is required rather than tidy. Vuetify states this on
* `.v-btn--disabled.v-btn--variant-elevated .v-btn__overlay` at (0,3,0) and its
* stylesheet is injected after this file, so the same rule at (0,2,0) left the
* overlay untouched at 0.4615 — measured, not assumed.
*
* Only elevated and flat are affected: every disabled text button on
* `?tab=general` already computes `opacity: 0` here, because those are the only
* two variants Vuetify raises it for. And a disabled button carries
* `pointer-events: none`, so no hover or focus state can want the overlay back.
*/
.v-btn.v-btn--disabled .v-btn__overlay.v-btn__overlay {
opacity: 0;
}
/*
* …and every other variant is dimmed by colour too, not by opacity.
*
* The rule above covers the two variants Vuetify 3 gives a background. For the
* rest it says `.v-btn--disabled { opacity: 0.26 }` and leaves the colour alone,
* where Vuetify 2 said
* `.theme--light.v-btn.v-btn--disabled { color: rgba(0,0,0,.26) !important }`
* and left the opacity alone — the colour-versus-opacity split again.
*
* Measured on `/settings/version?tab=general`, which renders twenty disabled
* text buttons in its status table:
*
* | Vue 2 build | this build
* button colour | rgba(0,0,0,.26) | rgba(0,0,0,.87)
* opacity | 1 | 0.26
*
* For near-black text the two land close in strength, which is why this survived
* so long. The difference shows on anything *coloured*: the Vue 2 build turns it
* grey, this build keeps the hue at 26%. The same screen's
* `.doc-setting-container .edit-btn i { color: #2153CD }` is exactly that case.
*
* (0,3,0) is Vuetify 2's own weight — the theme class sits on the button in
* Vuetify 3 just as it did in Vuetify 2 — so everything that outranked that rule
* on the Vue 2 build still outranks this one: `PublicLoginDialog`'s
* `.v-theme--light.v-btn.submit-btn.v-btn--disabled` at (0,4,0), and the nine
* components that colour the label through `.v-btn--disabled span { … !important }`.
*
* `!important` is what Vuetify 2 used, and the cycle above established why it is
* unavoidable here: Vuetify 3 writes a button's colour as an inline style, which
* nothing weaker outranks. `opacity` carries none, so a screen can still dim.
*/
.v-btn.v-btn--disabled.v-theme--light {
color: rgba(0, 0, 0, 0.26) !important;
opacity: 1;
}
/*
* …except pagination, which Vuetify 2 dimmed its own way.
*
* Vuetify 2's navigation arrow was not a `.v-btn`, so the disabled-button colour
* rule never reached it: it had `.v-pagination__navigation--disabled { opacity: .6 }`
* and kept the default `rgba(0,0,0,.54)` icon. Vuetify 3 renders it as a button,
* so it takes the generic `opacity: .26` instead:
*
* | Vue 2 build | this build
* opacity | 0.6 | 0.26
* icon colour | .54 | .26
* effective ink | 0.324 | 0.068
*
* Nearly five times fainter — the disabled arrow is close to invisible. The same
* lesson as the pagination-colour cycle: a Vuetify 2 button rule that never
* reached pagination must not start reaching it now that the markup changed.
*
* The opacity is (0,3,0), tying with the rule above and therefore placed after
* it. The colour has to go on `.v-btn__content` rather than the button, and that
* is not tidiness: **a screen's own rule reaches the arrow now too.**
* `Settings.vue` writes `.doc-setting-container .v-btn--disabled span
* { color: rgba(0,0,0,.26) !important }` (0,2,1) for its Edit and Delete
* buttons, and on the Vue 2 build that never matched an arrow — there the arrow
* was `.v-pagination__navigation--disabled`, not a button with a span. Setting
* the colour on the button leaves that rule to win on the label, which measured
* .26 where the Vue 2 build draws .54. On the content at (0,4,0) it restores the
* boundary Vuetify 2 had, and a screen's rule still decides everywhere else —
* verified on the same page's Edit buttons, which stay .26.
*/
.v-pagination .v-btn.v-btn--disabled {
opacity: 0.6;
}
.v-pagination .v-btn.v-btn--disabled .v-btn__content {
color: rgba(0, 0, 0, 0.54) !important;
}
/*
* A disabled field keeps its value legible.
*
* Vuetify 2 dimmed a disabled input through `color`, so a rule naming the input
* could keep the value black while the label and icons faded — which is what
* the Vue 2 build does. Vuetify 3 dims the whole `.v-field` with
* `opacity: var(--v-disabled-opacity)` (VField.css:22-25), and nothing inside
* an opacity layer can escape it.
*
* That matters because this app uses `disabled` as a read-only *display* mode:
* the profile shows your name and phone number until you press Edit. At 38%
* they were barely readable where the Vue 2 build draws them black.
*
* The dimming is put back where Vuetify 2 had it — on the label and the icons —
* so a disabled field still reads as disabled.
*/
.v-field--disabled.v-field--disabled {
opacity: 1;
}
.v-field--disabled.v-field--disabled .v-label,
.v-field--disabled.v-field--disabled .v-icon {
opacity: var(--v-disabled-opacity);
}
/*
* An input's font size comes from the input, as it did under Vuetify 2.
*
* Vuetify 2 declared `font-size: 16px` on `.v-input` and nothing below it, so
* the size flowed down to the slot and the native control, and a typography
* class written on the input — `caption`, which this app uses on 15 of the 19
* fields on the compliance audit plan alone — simply overrode it and took the
* whole field with it.
*
* Vuetify 3 moved the declaration down to `.v-field` (VField.css:2-6). A class
* on the input no longer reaches the control, because inheritance loses to any
* declaration on a descendant, whatever its specificity. Every `text-caption`
* field went from 12px to 16px: the Location textarea on that page is `rows=5`,
* so it grew 85px → 126px and the table with it, 766px → 906px.
*
* Putting the declaration back on `.v-input` restores both halves. `:where()`
* carries no specificity, so a typography class beats it exactly as `.caption`
* beat Vuetify 2's own rule; and a field with no such class still computes
* 16px, which is what the Vue 2 build shows for the app-bar search box.
*/
:where(.v-input) {
font-size: 16px;
}
.v-field.v-field {
font-size: inherit;
}
/*
* A list row measures the way Vue 2 measured it.
*
* Two Vuetify 2 declarations went missing, and both add height to the same
* rows:
*
* 1. `.v-list-item { padding: 0 16px }` became `padding: 4px 16px`
* (VListItem.css:1-11), and the density variants add block padding of their
* own on top (`--one-line` 4px, `--two-line` 12px, `--three-line` 16px).
* Vuetify 2 put nothing at all on the block axis: its variants set
* `min-height` and only `min-height`.
* 2. Every item carried a ghost
* `.v-list-item::after { content: ''; min-height: inherit; font-size: 0 }`,
* which made `min-height` a floor on the *content* box. Vuetify 3 dropped
* it — `::after` is the focus ring now (VListItem.css:96-110), absolutely
* positioned and so unable to carry a floor — leaving `min-height` an
* ordinary border-box floor.
*
* Together: a Vue 2 row is `call-site padding + max(floor, content)`; a Vue 3
* row is `max(floor, 8px + content)`. The 8px is invisible wherever the floor
* absorbs it — a 24px option in a dropdown is 48px on both builds — and shows
* on exactly the rows that outgrow their floor or whose component lowered it.
* Measured against `127.0.0.120`: the workflow preset screen's library rows
* 36px -> 44px and its two cards 132px -> 140px, `/library`'s document cards
* 74px -> 86px, and on the academy course page — where a `py-5` at the call
* site had already replaced the 4px, so only the ghost was missing — the video
* rows 88px -> 65px and the section panel 240px -> 192px.
*
* Restoring both reproduces Vuetify 2's arithmetic rather than approximating
* it, which is why it is safe to apply to every row: zeroing the block padding
* and re-flooring the content box is a no-op precisely when the floor was
* already winning, and that is every row the two builds already agreed on.
*
* `padding-block` is not `!important`, so a `py-*`/`pa-*` utility at the call
* site still decides the row's padding — as it did on the Vue 2 build. It does
* need three classes to outrank `.v-list-item--density-default.v-list-item--one-line`,
* which is where Vuetify 3 puts its 4px.
*
* The ghost goes on `::before`, which Vuetify 3 leaves unused on this
* component, and is placed in the `content` grid area: `.v-list-item` is a
* grid now (`"prepend content append"`), so an auto-placed pseudo-element
* would open a second row and add its height to the item instead of stacking
* with the content.
*/
.v-list-item {
--parity-list-floor: 48px;
}
.v-list-item::before {
content: "";
grid-area: content;
/*
* `inherit`, not the variable, so a component that sets its own
* `min-height` on the row still decides the floor — which is what the ghost
* did on the Vue 2 build.
*/
min-height: inherit;
font-size: 0;
}
.v-list-item--density-compact {
/* Vuetify 2's `.v-list--dense .v-list-item`. */
--parity-list-floor: 40px;
}
/*
* Two classes, so a component's own `min-height` on the row still wins on
* document order the way it did before; three for the padding, to clear
* Vuetify's density rule.
*/
.v-list-item.v-list-item {
min-height: var(--parity-list-floor);
}
.v-list-item.v-list-item.v-list-item {
padding-block: 0;
}
/*
* Vuetify 2's `.v-list-item__title` was `line-height: 1.2`; Vuetify 3's
* `.v-list-item-title` is `1.5` (VListItem.css:310-316). At the 12px the app
* writes its list titles in that is 3.6px a row, which is what remained of
* `/library`'s document cards after the padding above: 78px against stable's
* 74px.
*
* Two classes because Vuetify's own rule is one and lands after this file in
* the cascade — measured, not assumed: at a single class the cards stayed at
* 78px.
*/
.v-list-item-title.v-list-item-title {
line-height: 1.2;
}
/*
* Card text keeps the Vue 2 build's leading.
*
* Vuetify 2's `.v-card__text` set `line-height: 1.375rem` — an absolute 22px
* that the whole subtree inherits whatever its own font size. Vuetify 3 writes
* `.v-card .v-card-text { line-height: 1.425 }` (VCard.css:258-260), a factor,
* which at the 14px the card sets is 19.95px. Every line of text inside a card
* is 2.05px shorter than the Vue 2 build draws it; on the workflow preset
* screen that was the last 2px of the 33px its container card had lost.
*
* The letter-spacing is the other half of the same declaration, and it is a
* *width* difference that turns into a height one. Vuetify 2 spaced card text
* `0.0071428571em`, Vuetify 3 spaces it `0.0178571429em` — 0.1px against 0.25px
* a character at the 14px a card sets — and `letter-spacing` inherits, so it
* reaches every descendant. On `/academy` the course title
* "HACCP for Food Safety (Foundational course)" measures 339.97px on the Vue 2
* build and 348.52px here; in its 211px box that is two lines against three, so
* the card stood 210px tall against 196 and the section card holding it 287
* against 273.
*
* Three classes: Vuetify declares the spacing in its `.v-card-text` block
* (0,1,0) and the leading in `.v-card .v-card-text` (0,2,0), and its stylesheet
* lands after this file in the cascade, so two would not be enough.
*/
.v-card .v-card-text.v-card-text {
line-height: 1.375rem;
letter-spacing: 0.0071428571em;
}
/*
* A card title lays its children out in a row, as Vuetify 2's did.
*
* Reported on the workflow detail: a task card's avatar sat above "To be
* Tasked with" instead of beside it. Measured on both builds:
*
* .v-card-title | Vue 2 flex, wrap, center, 32px | this build block, nowrap, 34px
* avatar / title | 813,144 and 906,152 — one row | 813,144 and 813,163 — stacked
*
* Vuetify 2's `.v-card__title` was `display: flex; flex-wrap: wrap;
* align-items: center; line-height: 2rem; word-break: break-all`
* (vuetify.css:22636-22645). Vuetify 3's `.v-card-title` is `display: block;
* white-space: nowrap; overflow: hidden; text-overflow: ellipsis` at
* `line-height: 1.6` (VCard.css:189-207) — a single-line label. Ten titles in
* this app were written as the flex row: an avatar, a spacer and a caption, or
* a heading and a close button, relying on the row to place them.
*
* Every declaration here is one that measured differently; the padding did
* not on a screen (this app sets its own on most titles) and is left alone.
* Three classes because Vuetify states the leading in `.v-card .v-card-title`
* (0,2,0) and its sheet lands after this file. Simulated at `app.css`'s real
* position, the task card's five children land on the Vue 2 build's
* coordinates to the pixel.
*/
.v-card .v-card-title.v-card-title {
display: flex;
flex-wrap: wrap;
align-items: center;
line-height: 2rem;
white-space: normal;
word-break: break-all;
overflow: visible;
}
/*
* A vertical divider takes no space above or below it.
*
* `v-divider` renders an `
`, so Bootstrap's `hr { margin: 1rem 0 }` reaches
* it. On the Vue 2 build Vuetify's own `.v-divider--vertical { margin: 0 -1px }`
* shorthand zeroed the block axis back out; Vuetify 3 writes `margin-left: -1px`
* and leaves the block axis alone, so the 1rem lands. `/compliance/index` grew
* 10px the moment the Bootstrap rule came back.
*
* `margin-block`, not the shorthand, so a `mt-*` utility at the call site still
* decides the top margin — which is what the Vue 2 build did: that divider
* carries `mt-1` and measures 4px above, 0 below, on both builds now.
*/
.v-divider--vertical {
margin-block: 0;
}
/*
* An inset vertical divider takes its 8px from the top only.
*
* The rule Vuetify 2 wrote against the rule Vuetify 3 writes:
*
* .v-divider--vertical.v-divider--inset { .v-divider--inset.v-divider--vertical {
* margin-top: 8px; margin-top: 8px;
* min-height: 0; margin-bottom: 8px; // added
* max-height: calc(100% - 16px); max-height: calc(100% - 16px);
* } }
*
* One declaration, and it costs the line 8px of the row it stretches in.
* `/workflow`'s UI toggle — the app's only inset divider — draws 20px between
* its two buttons against the Vue 2 build's 28, in a 36px flex row on both.
*
* `max-height` is the same on both builds and applies to neither: the flex
* parent's height is not definite, so the percentage resolves to `none` and the
* margins alone decide. 36 - 8 is 28; 36 - 8 - 8 is 20.
*
* `min-height` is deliberately not restored. Vuetify 2's `0` existed only to
* undo its own `min-height: 100%` on the base vertical rule, which Vuetify 3
* does not have — this build computes `auto` where that one computes `0px`, and
* no divider in the app measures differently for it.
*
* Three classes: Vuetify's rule is two and its stylesheet is injected after this
* file, so an equal-specificity rule here would lose. `margin-top` is left to
* Vuetify, which happens to write the value Vuetify 2 wrote.
*/
.v-divider--vertical.v-divider--vertical.v-divider--inset {
margin-bottom: 0;
}
/*
* Pagination is the size and the shape the Vue 2 build drew.
*
* The control grew an element between the two majors:
*
* Vue 2 Vuetify 3
* nav.pagination (the app's) nav.v-pagination.pagination
* ul.v-pagination — the row ul.v-pagination__list — the row
* button.v-pagination__item li.v-pagination__item > button.v-btn
*
* So the page number is a `v-btn` now, and everything Vuetify 2 put on
* `.v-pagination__item` — `height: 34px`, `min-width: 34px`, `border-radius: 4px`,
* a white background and an elevation-1 shadow — has no counterpart:
* `.v-btn--icon.v-btn--density-default` sizes it `calc(var(--v-btn-height) + 12px)`
* instead, which is 48px. Measured on `/audit-trail`, the row went 43.6px ->
* 57.6px and the current page lost its filled `rgb(25, 118, 210)` pill.
*
* The size goes through `--v-btn-height` rather than `width`/`height` on
* purpose. The token is declared on `.v-btn--size-default` (0,1,0), so a rule
* at `.v-pagination__item .v-btn` (0,2,0) wins outright; `width` and `height`
* are declared on `.v-btn--icon.v-btn--density-default` (0,2,0), which would
* tie and then win on document order, since Vuetify's stylesheet lands after
* this file.
*
* `margin: .3rem` is not restated: Vuetify 3 already carries it on
* `.v-pagination__item`, the same value Vuetify 2 had, and neither is the 4px
* `border-radius` — `.v-btn--rounded.v-btn--icon` already draws it, measured
* before this rule existed. Restating either would only raise the specificity
* a screen's own rule has to clear.
*/
.v-pagination__item .v-btn {
/* 22 + 12 = the Vue 2 build's 34px. */
--v-btn-height: 22px;
min-width: 34px;
width: auto;
background: #ffffff;
/* Vuetify 2's elevation-1, read off the Vue 2 build. */
box-shadow: 0 3px 1px -2px rgba(0, 0, 0, 0.2), 0 2px 2px 0 rgba(0, 0, 0, 0.14), 0 1px 5px 0 rgba(0, 0, 0, 0.12);
/*
* The screens' own rules are written on `.v-pagination__item`, which is the
* `` now. `color` still reaches the button on its own; type does not,
* because `.v-btn--size-default` sets `font-size: var(--v-btn-size)` on the
* button itself. Same forwarding idiom as `.v-list-item__content` above.
*/
font-size: inherit;
font-weight: inherit;
line-height: inherit;
}
.v-pagination__item--is-active .v-btn {
background: #1976d2;
/* Vuetify 2's elevation-3. `App.vue:1200` already forces the white text. */
box-shadow: 0 2px 4px -1px rgba(0, 0, 0, 0.2), 0 4px 5px 0 rgba(0, 0, 0, 0.14), 0 1px 10px 0 rgba(0, 0, 0, 0.12);
}
.v-pagination__prev .v-btn,
.v-pagination__next .v-btn,
.v-pagination__first .v-btn,
.v-pagination__last .v-btn {
/* 20 + 12 = the Vue 2 build's 32px navigation button. */
--v-btn-height: 20px;
background: #ffffff;
box-shadow: 0 3px 1px -2px rgba(0, 0, 0, 0.2), 0 2px 2px 0 rgba(0, 0, 0, 0.14), 0 1px 5px 0 rgba(0, 0, 0, 0.12);
}
/*
* …and the arrows keep the room Vuetify 2 gave them.
*
* The block above notes that `margin: .3rem` is not restated because Vuetify 3
* already carries it. That is true of the numbers and not of the arrows:
* Vuetify 2 set `margin: 0.3rem 10px` on `.v-pagination__navigation`, ten pixels
* either side, while Vuetify 3 gives every child the same flat `0.3rem`
* (`.v-pagination__item, .v-pagination__first, .v-pagination__prev, …`).
*
* Measured on `/audit-trail` and `/settings/version`: 4.8px sides against the
* Vue 2 build's 10px, which pulls the arrows in against the numbers and takes
* 20.8px off the row — 154.4 against 175.2 on `/settings/version`.
*
* (0,2,0), because Vuetify states it at (0,1,0) and its stylesheet is injected
* after this file: an equal-weight rule would lose the tie.
*/
.v-pagination .v-pagination__prev,
.v-pagination .v-pagination__next,
.v-pagination .v-pagination__first,
.v-pagination .v-pagination__last {
margin: 0.3rem 10px;
}
/*
* A small chip is the size the Vue 2 build drew.
*
* Vuetify 2 sized chips with two declarations: a shared `padding: 0 12px` on
* `.v-chip`, and a height per size — 16px x-small, 24px small, 32px default.
* Vuetify 3 moved both into the size rule and changed the small one twice over
* (VChip.css:66-69): `--v-chip-height: 26px` and `padding: 0 10px`. Its default
* size is unchanged at 32px and 12px, which is why 59 of the app's 71 chips
* already matched and the 12 small ones did not.
*
* Measured on `/dashboard`, where every task row carries two: chips 24px -> 26px
* and 78/74 wide -> 74/70, which stood all nine task cards at 96px against the
* Vue 2 build's 94.
*
* Three classes because Vuetify's own rule is two. Only `small` is restated:
* the app writes no x-small, large or x-large chip anywhere, and Vuetify 2's
* numbers for those (54px and 66px) are far enough from Vuetify 3's that
* restoring them unmeasured would be a guess, not a parity fix.
*/
.v-chip.v-chip--size-small.v-chip--size-small {
--v-chip-height: 24px;
padding: 0 12px;
}
/*
* A table header's sort icon flows with the label instead of taking width off it.
*
* Vuetify 2 put the label and the sort icon straight into the `` as inline
* content, so they wrapped together and the label could use the full cell.
* Vuetify 3 wraps them in `.v-data-table-header__content`, a flex row
* (VDataTable.css:143-145) — which makes the icon a flex item that reserves its
* 18px whether or not it is visible, and it is invisible until hover
* (`opacity: 0`).
*
* On `/dashboard`'s document widget that cost the "Days before Review" column
* 8px of label: 70px wide over two lines on the Vue 2 build, 62px over three
* here, standing the header row at 54.5px against 48. The narrower label also
* redistributed the table's columns — the first went 178px -> 165 — which
* wrapped a body row that had fit, 48px -> 55. The widget measured 546px
* against 533.
*
* `display: block` is the Vue 2 layout, not an approximation of it: Vuetify 3
* aligns a column through `text-align` on the ` ` itself, and only uses the
* flex row to decide which side the icon sits on. Inline content obeys that
* `text-align`, and Vuetify 2 always put the icon after the label anyway.
*
* Two classes: Vuetify's own rule is one, and its stylesheet lands after this
* file.
*/
.v-data-table-header__content.v-data-table-header__content {
display: block;
}
/*
* The app's default leading used to be restated here as the Vue 2 build's
* `line-height: 1.5` (Vuetify 2's `.v-application` rule, which Vuetify 3
* does not ship), on both `.v-application` and `.v-overlay-container` —
* the second because Vuetify 3 teleports every overlay out of the app root
* and Bootstrap's `body` leading reached it instead. Both are superseded:
* `_typography.scss` sets the brand's Body style (14px / 20px) on both roots,
* and the brand supersedes the Vue 2 number.
*/
/*
* A pagination list carries no margin of its own.
*
* `v-pagination` renders a ``, so Bootstrap Reboot's
* `ol, ul, dl { margin-bottom: 1rem }` reaches it. Vuetify 2 zeroed it back out
* with `margin: 0` on `.v-pagination`; Vuetify 3's `.v-pagination__list` sets
* `display`, `list-style-type`, `justify-content` and `width` — and no margin.
*
* The 16px lands below the control, inside whatever wraps it:
* `/audit-trail`'s `.pagination-container` measured 59.6px around a 43.6px row.
* Same shape as the `v-divider` finding — a Bootstrap element rule that
* Vuetify 2 happened to cancel and Vuetify 3 does not.
*
* `margin-block`, so a `my-*` at the call site still decides.
*/
.v-pagination__list {
margin-block: 0;
/*
* And no indent either. `.v-application ul` below restores the 24px Vuetify 2
* put on lists inside the app, and Vuetify 2 zeroed it again on its own list
* components — `.v-pagination { padding-left: 0 }` is in the Vue 2 bundle.
* Vuetify 3 has no such rule because nothing was adding one. Measured: with
* the indent alone this reads 24px on `/audit-trail` and `/settings/version`
* where the Vue 2 build reads 0.
*
* `.v-application` in front because the indent rule is (0,1,1) and one class
* here would lose to it.
*/
}
.v-application .v-pagination__list {
padding-left: 0;
}
/*
* An underlined field sits 4px below whatever is above it.
*
* Vuetify 2's `.v-text-field { padding-top: 12px; margin-top: 4px }` applied to
* every field and was cancelled by
* `.v-text-field--enclosed { margin: 0; padding: 0 }` — so the 4px belonged to
* the *non-enclosed* field, the plain underlined one. Vuetify 3 has no
* equivalent at any variant.
*
* `--plain-underlined` is the class Vuetify 3 puts on the input root for that
* variant, and it is the one the wrapper produces for a Vuetify 2 field with no
* `outlined`, `solo` or `filled` (`propCompat.js:58-75` never returns `plain`).
* So the selector names exactly the fields Vuetify 2 gave the margin to.
*
* Measured on `/workflow`, whose filter row holds three of them: 62px against
* the Vue 2 build's 66, which was the whole of that screen's 4px. Everywhere
* else the app writes `mt-0` and wins on `!important` — as it did on the Vue 2
* build, which is why `/audit-trail`'s four underlined fields have no margin on
* either build.
*/
.v-input--plain-underlined {
margin-top: 4px;
}
/*
* An icon is the size, and the shape, the Vue 2 build drew it.
*
* Vuetify 2 sized an icon with a flat base and four rules over it, all four of
* them about a button. Read out of the Vue 2 build's own stylesheet:
*
* .v-icon.v-icon { font-size: 24px }
* .v-btn--icon.v-size--x-small .v-icon,
* .v-btn--fab.v-size--x-small .v-icon { 18px, and an 18x18 box }
* small, default { 24 }
* large { 28 }
* x-large { 32 }
* .v-btn__content .v-icon.v-icon--left,
* .v-btn__content .v-icon.v-icon--right { 18px, and an 18x18 box }
*
* Vuetify 3 has none of them. Its size is `.v-icon--size-` as a multiple of
* the surrounding text, so an icon takes its size from its context: `1.5em` of
* an `x-small` button's 10px is 15px, `1.5em` of a pagination button's 14px is
* 21px. Measured against the Vue 2 build, that was 137 glyphs at 15 against 18
* on `/evidence/detail/73`, the `/settings/version` pagination arrows at 21
* against 24, and every `--start` icon in a button square to its own font
* instead of 18.
*
* The base is Vuetify 2's selector character for character, so every app rule
* that outranked it then outranks it now; the four below carry Vuetify 2's
* specificities for the same reason, (0,3,0) and (0,4,0), and both clear
* Vuetify's own `.v-icon--size-*` at (0,1,0) even though this file loads first.
*
* `.v-btn .v-icon` no longer needs an exclusion. What the four rules leave is a
* bare icon in a button that is not an icon button, and Vuetify 2 gave that the
* 24px base too.
*/
.v-icon.v-icon {
font-size: 24px;
/*
* Vuetify 2 declared no box at all — `.v-icon` was an `inline-flex` and
* nothing more, so a glyph took its natural width. Vuetify 3 writes
* `height: 1em; width: 1em; min-width: 1em` (VIcon.css:5-16), which squares
* every Font Awesome glyph: `fa-caret-down` in the company activator is 18px
* wide here against the Vue 2 build's 11.25, and `/library`'s 13 file-type
* icons are 60 against 70. That is the whole of the activator's 199px against
* 192 — 18 - 11.25 plus 18 - 17.44 on the icon beside it.
*
* `min-width: auto`, not `0`. `auto` is the initial value — min-content for a
* flex item, 0 for anything else — which is the property being undeclared,
* and undeclared is what Vuetify 2 had. `0` is not the same thing and is
* measurably worse: three of `/library`'s 35 file icons shrink to zero width
* inside their flex row.
*/
width: auto;
min-width: auto;
height: auto;
}
/*
* Vuetify 2's icon-button map, transposed onto Vuetify 3's names.
*
* `v-size--*` became `v-btn--size-*`, and Vuetify 3's `.v-btn--icon` covers
* both of Vuetify 2's `icon` and `fab` — which is already how `AppBtn` maps
* them, so one selector family stands in for Vuetify 2's two.
*
* `min-width` and `min-height` beside `width` and `height` are not belt and
* braces. Vuetify 2's `VIcon` wrote the `size` prop out as an inline
* `font-size` and nothing else, so the rule's `height: 24px` still shaped an
* explicitly-sized glyph; Vuetify 3's writes `fontSize`, `height` *and* `width`
* inline (VIcon.js:68-70), and a stylesheet can only outrank an inline `width`
* through `min-width`. `/dashboard`'s two `small` icon buttons are the case:
* the Vue 2 build draws a 16px glyph inside a 24x24 box.
*/
.v-btn--icon.v-btn--size-x-small .v-icon {
font-size: 18px;
width: 18px;
min-width: 18px;
height: 18px;
min-height: 18px;
}
.v-btn--icon.v-btn--size-small .v-icon,
.v-btn--icon.v-btn--size-default .v-icon {
font-size: 24px;
width: 24px;
min-width: 24px;
height: 24px;
min-height: 24px;
}
.v-btn--icon.v-btn--size-large .v-icon {
font-size: 28px;
width: 28px;
min-width: 28px;
height: 28px;
min-height: 28px;
}
.v-btn--icon.v-btn--size-x-large .v-icon {
font-size: 32px;
width: 32px;
min-width: 32px;
height: 32px;
min-height: 32px;
}
/*
* Vuetify 2's `.v-btn__content .v-icon--left/--right`, under Vuetify 3's names.
* `AppIcon` already translates the call sites' `left`/`right` into
* `start`/`end`; this is the size those two carried.
*/
.v-btn__content .v-icon.v-icon--start,
.v-btn__content .v-icon.v-icon--end {
font-size: 18px;
width: 18px;
min-width: 18px;
height: 18px;
min-height: 18px;
}
/*
* An icon fills the avatar it sits in.
*
* Vuetify 2's `.v-avatar .v-icon` set `height: inherit; width: inherit`
* (and `border-radius: inherit`); Vuetify 3's VAvatar.css keeps the equivalent
* for `.v-img` and dropped it for the icon. Measured on `/dashboard`, whose
* carbon banner puts a `fa-leaf` in a `size="32"` avatar: 32x32 on the Vue 2
* build, 24x24 here.
*
* It has to come after the base above, which it ties with at two classes, and
* it is the reason that base is not the whole story: undeclaring the box let
* the leaf take its natural 27x24, which is its own width but still not the
* avatar's.
*/
.v-avatar .v-icon {
border-radius: inherit;
width: inherit;
height: inherit;
}
/*
* …and so does a raw image, which is the other half of the same Vuetify 2
* rule: `.v-avatar img, .v-avatar svg, .v-avatar .v-icon, .v-avatar .v-image
* { border-radius: inherit; display: inline-flex; height: inherit; width:
* inherit }`. Vuetify 3 keeps the sizing for `.v-img` alone (VAvatar.css:104),
* so an `![]()
` written straight into an avatar — `AvatarGroup.vue` and twelve
* other sites — draws at its natural size and is clipped to the circle.
* Measured on the workflow canvas: a user's 82×64 picture cropped to an 18px
* disc, where the Vue 2 build drew the whole picture at 14×14 inside its 2px
* of padding.
*/
.v-avatar img,
.v-avatar svg {
border-radius: inherit;
display: inline-flex;
width: inherit;
height: inherit;
}
/*
* A block button fills its box whatever `min-width` it was also given.
*
* Vuetify 2's `.v-btn--block { min-width: 100% !important }` beat the inline
* `min-width` the prop writes; Vuetify 3's rule is the same without the
* `!important` (VBtn.css:211-215), so the prop wins. The business process's
* edit / archive / duplicate buttons pass both `block` and `min-width="36px"`
* and came out 48px wide against the Vue 2 build's 137.5 — each filling a
* third of the row. Eight `block` buttons in the app pass a `min-width`.
* `max-width: none` is the rest of the Vuetify 2 declaration.
*/
.v-btn--block {
min-width: 100% !important;
max-width: none;
}
/*
* A `` lays its child out the way Vuetify 2's did.
*
* Twenty-eight sites wrap a disabled button in a `div` wearing `.v-btn` so a
* tooltip has a live element to hang from. Vuetify 2's `.v-btn` made that
* div an `inline-flex` box centring its content; Vuetify 3's `.v-btn` is an
* `inline-grid` with `max-content auto max-content` columns (VBtn.css), so a
* `block` button inside it is sized to a `max-content` column instead of the
* row — the business process's duplicate button, 48px inside a 137.5px div
* even with the rule above, because its `100%` resolved against that column.
* Vuetify 3 renders no `div.v-btn` of its own (VBtn renders a button or an
* anchor), so the tag is what tells the hand-written ones apart.
*/
div.v-btn {
display: inline-flex;
align-items: center;
justify-content: center;
}
/*
* A sort icon is 18px, which is the one size Vuetify 2 set inline rather than
* through a rule — so the base above would make it 24. Pinned at the literal
* value the Vue 2 build draws rather than handed back to
* `--v-icon-size-multiplier`, which happens to yield 18 in a table header today
* and would follow the header's type the moment that changed.
*/
.v-data-table-header__sort-icon.v-data-table-header__sort-icon {
font-size: 18px;
}
/*
* A switch is the size the Vue 2 build drew it.
*
* Vuetify 3 rebuilt the switch around `.v-selection-control` and resized every
* part of it: an inset track is 32px tall and 52px wide (VSwitch.css:49-54),
* the thumb is 24px, and the row is floored by `--v-selection-control-size`,
* which is 28px at compact density (VSelectionControl.css:40-42). The Vue 2
* build draws a 24px row around a 44x22 track with an 18px thumb.
*
* Measured on `/settings/version`, where three of them sit in the author
* permission cards: 40px each against 24, which was 48px of that page's 1683
* against the Vue 2 build's 1635.
*
* This is the case the checkbox rule above deferred by name — "radios and
* switches are selection controls too and were not measured". All 23 switches
* in the app pass `inset` and `density="compact"`, so there is one shape to
* match rather than a family. Radios are still unmeasured and still untouched.
*
* Two of the four specificities carry the fix and neither is arbitrary:
*
* - `--v-selection-control-size` is declared on `.v-selection-control` here
* because that is where Vuetify declares it, and an element's own
* declaration beats an inherited one. Put on `.v-switch` it is ignored and
* the row stops at 28px — measured, not assumed.
* - the track and thumb rules repeat `--inset` because Vuetify's own are
* `.v-switch--inset .v-switch__track` and `.v-switch--inset .v-switch__thumb`,
* two classes each, landing after this file. Two classes here lose on
* document order — measured: the row reached 24px while the track stayed
* 52x32 and the thumb 24x24.
*
* `transform: none` because Vuetify 3 shrinks an *unchecked* inset thumb to
* two thirds (`VSwitch.css:81-90`) and restores it only when the control is
* dirty. The Vue 2 build draws 18px in both states — measured on this page,
* whose third switch is off and still 18x18 — so an 18px thumb would otherwise
* read 12px when off.
*
* The control comes out 44px wide against the Vue 2 build's 56. These switches
* sit in a `justify-space-between` row, so that moves nothing — recorded rather
* than chased.
*/
.v-switch.v-switch {
--v-input-control-height: 24px;
}
.v-switch .v-selection-control {
--v-selection-control-size: 24px;
}
.v-switch--inset.v-switch--inset .v-switch__track {
height: 22px;
min-width: 44px;
}
.v-switch--inset.v-switch--inset .v-switch__thumb {
height: 18px;
width: 18px;
transform: none;
}
/*
* A radio is the size and the shape the Vue 2 build drew it.
*
* The last selection control, and the one the checkbox and switch cycles both
* deferred by name — "radios are still unmeasured and still untouched". They
* were unmeasured for a reason: 111 call sites and not one of them renders on
* any of the sixteen sweep routes, or on any route at rest, on either build.
* The measurement here is `/form-builder/form/edit/242` — a form with two radio
* fields — with its fifth section tab open, on both builds.
*
* Vuetify 2 sized a radio with three rules that Vuetify 3 has no equivalent of:
*
* .v-input--selection-controls__input { height: 24px; width: 24px }
* .v-application--is-ltr .v-input--selection-controls__input { margin-right: 8px }
* .v-input--radio-group--row .v-radio { margin-right: 16px }
*
* Vuetify 3 replaced the first with `--v-selection-control-size`, which is 40px
* at the default density and 28px at compact (VSelectionControl.css:36-42) —
* where Vuetify 2's tick was 24px at *both* — and dropped the other two
* outright, so the label butts against the tick and the radios in a row have no
* gap between them. Measured: a 28x28 tick in a 28px row against a 24x24 tick in
* a 24px one, with 0px where the Vue 2 build puts 8 and 16.
*
* The icon inside is 20px, not the 24px base. Vuetify 2 gave a selection
* control in a dense input the `v-icon--dense` class and sized it
* `font-size: 20px`; Vuetify 3 has no dense icon and draws the default 24. It
* fills its 24px tick either way, because Vuetify 2's
* `.v-input--selection-controls__input .v-icon { width: 100% }` said so — which
* the icon cycle's `width: auto` base would otherwise shrink to the glyph.
*
* Scoped to `.v-radio` throughout, deliberately. Vuetify 2's tick rules were
* written for *every* selection control, checkboxes and switches included, but
* those two were measured and closed in their own cycles and are right as they
* stand — widening these rules would move them off the numbers they were pinned
* to.
*
* `.v-radio.v-radio` for the token because Vuetify declares it on the same
* element (`.v-selection-control--density-compact`), and `.v-radio.v-radio` for
* the label because Vuetify's `.v-selection-control .v-label` is two classes and
* lands after this file. The other three compete with nothing.
*
* The 20px glyph keys off the *control's* own density class rather than the
* group's `.v-input--density-compact`. Both are present when a group sets the
* density, which is every call site the app has; a radio given `density`
* directly carries only the first, and a descendant selector would miss it.
*
* The row direction is not here — it is a renamed prop, not a rule. See the
* three `:inline` call sites.
*/
.v-radio.v-radio {
--v-selection-control-size: 24px;
}
.v-radio .v-selection-control__wrapper {
margin-right: 8px;
}
.v-radio .v-selection-control__input > .v-icon {
width: 100%;
height: 100%;
}
.v-radio.v-selection-control--density-compact .v-icon {
font-size: 20px;
}
.v-selection-control-group--inline .v-radio {
margin-right: 16px;
}
.v-radio.v-radio .v-label {
height: auto;
}
/*
* A bullet list keeps the indent Vuetify 2 gave it.
*
* A bare `` appended to `` reads `padding-left: 0` on *both* builds,
* so this is not a reset that went missing: Vuetify 2 put the indent back
* inside the app with `.v-application ul, .v-application ol { padding-left:
* 24px }`, and Vuetify 3 ships nothing equivalent.
*
* Every rich-text list the app renders has been drawing its bullets flush with
* the text, which is a content defect before it is a height one. It shows as a
* height on the academy course page, where the last item of "Who this course is
* for" has 749px of room here against 725 on the Vue 2 build and so fits on one
* line where the Vue 2 build wraps it onto two: the page measured 1458 against
* 1477.
*
* Vuetify 3's own `` components are unaffected — `.v-breadcrumbs` sets its
* own padding at higher specificity, and `.v-pagination__list` is zeroed above,
* the way Vuetify 2 zeroed `.v-pagination`.
*/
.v-application ul,
.v-application ol {
padding-left: 24px;
}
/*
* A breadcrumb carries no margin of its own.
*
* `.v-breadcrumbs` is a ``, so Bootstrap Reboot's
* `ol, ul, dl { margin-bottom: 1rem }` reaches it: `0px/16px` here against
* `0px/0px` on the Vue 2 build, where Vuetify 2's own rule cancelled it.
*
* Fourth instance of the same shape, after `hr`, the vertical divider and the
* pagination list: a `v-*` component that renders a bare element inherits
* Reboot, and Vuetify 2's resets were quietly doing that cancelling.
*/
.v-breadcrumbs {
margin-block: 0;
}
/*
* A divider is a line you can see.
*
* Vuetify 2 drew one with `border-color: rgba(0, 0, 0, 0.12)` at full opacity.
* Vuetify 3 takes the colour from `currentColor` and applies
* `opacity: var(--v-border-opacity)` — 0.12 — instead. `v-divider` renders an
* `
`, so the colour it inherits here is Bootstrap's `rgba(0, 0, 0, 0.1)`,
* and 0.1 multiplied by an opacity of 0.12 is an effective alpha of **0.012**: a
* line that is technically drawn and practically invisible.
*
* Reported on the account menu, where three of them separate the sections, and
* true of every divider in the app.
*
* Two classes: Vuetify's own rule is one and its stylesheet lands after this
* file.
*/
.v-divider.v-divider {
border-color: rgba(0, 0, 0, 0.12);
opacity: 1;
}
/*
* A list subheader keeps the Vue 2 build's leading.
*
* Vuetify 2's `.v-subheader` set no `line-height` at all and inherited
* `.v-application`'s 1.5, which at its 14px is 21px. Vuetify 3 pins
* `line-height: 1.375rem` — 22px. One pixel a subheader, and the last two of the
* account menu's card once its dividers and its subheader height are right.
*
* Two classes, because Vuetify's own rule is one and lands after this file —
* measured, not assumed: at one class the subheader stayed 22px through a full
* rebuild.
*/
.v-list-subheader.v-list-subheader {
line-height: 1.5;
}
/*
* A breadcrumb item takes no horizontal padding, as the Vue 2 build drew it.
*
* Vuetify 2's `.v-breadcrumbs__item` set none at all; Vuetify 3's
* `.v-breadcrumbs-item` adds `padding: 0 4px` (VBreadcrumbs.css:30-35). That is
* 8px an item, and the library preview's three-crumb trail measured 193px wide
* against the Vue 2 build's 169 — the dividers between them are already
* identical at `0 4px` on both.
*
* Two classes, because Vuetify's own rule is one and its stylesheet lands after
* this file.
*/
.v-breadcrumbs-item.v-breadcrumbs-item {
padding: 0;
}
/*
* A loading overlay centres its spinner, as the Vue 2 build drew it.
*
* Vuetify 2's `.v-overlay` was a centring flex box — `align-items: center;
* justify-content: center` — with `.v-overlay__content` in normal flow.
* Vuetify 3 rebuilt the component as the positioning primitive behind VDialog,
* VMenu and VTooltip, which place their own content: `.v-overlay` keeps
* `display: flex` and drops both alignment properties, and
* `.v-overlay__content` becomes `position: absolute` (VOverlay.css:26-40).
* With no insets that lands the spinner at 0,0 — on the library preview, in the
* top-left corner of the viewport with half of it behind the app bar, against
* the Vue 2 build's 928,393.5.
*
* Both declarations are needed and neither works alone: an absolutely
* positioned child is out of flow, so the alignment moves nothing until the
* content is `relative` again.
*
* `color` is Vuetify 2's `.theme--dark.v-overlay`, which every one of these
* overlays got — its `dark` defaulted to true — and is what made the spinner
* white. Vuetify 3 has no such rule, so the spinner inherited the app's body
* colour and came out near-black on the scrim.
*
* Keyed on `.app-overlay`, which AppOverlay adds, so that the dialogs, menus,
* tooltips and snackbars sharing these classes are left alone — they position
* their content through `locationStrategy` and must stay absolute.
*
* Two classes, because Vuetify's own rules are one and its stylesheet lands
* after this file.
*/
.v-overlay.app-overlay {
align-items: center;
justify-content: center;
color: #fff;
}
.v-overlay.app-overlay > .v-overlay__content {
position: relative;
}
/*
* A column is a containing block, as the Vue 2 build's was.
*
* Vuetify 2's grid opened its column rule with `position: relative` — the same
* declaration Bootstrap's does, and for the same reason: a column is the box an
* absolutely positioned child is meant to hang off. Vuetify 3's rule sets only
* `width` and `padding` (VGrid.css:29-38), so every `.v-col` stopped being a
* containing block and its absolutely positioned children started resolving
* against whatever ancestor happens to be positioned further up.
*
* Found through the profile avatar, whose `absolute` overlay is positioned by
* the app's own `top: 12px; left: 12px`: against the column it lands on the
* 100x100 avatar at 132,234, which is where the Vue 2 build draws it, and
* against the page it landed 24px up and to the left, off the picture entirely.
* Nothing else on the sixteen routes moves.
*
* Both selectors, because Vuetify writes the sized columns as `v-col-md-1` and
* the unsized one as `v-col`; an element usually carries both but not always.
* One class each is enough — Vuetify declares no `position` here to beat.
*/
.v-col,
[class*=v-col-] {
position: relative;
}
/*
* A list row's content box keeps the Vue 2 build's padding and leading.
*
* Vuetify 2's `.v-list-item__content` carried `padding: 12px 0`, and its
* `.v-list-item__subtitle` took `line-height: 1.2` from the item
* (export-pdf.css:52078-52086, 52139-52142). Vuetify 3's content wrapper
* carries no padding at all and pins the subtitle at `line-height: 1rem`
* (VListItem.css:219-224, 286-292) — 16px whatever the font size, against the
* 16.8 the app's 14px subtitle had. The file-detail sidebar's rows came out 48px
* against the Vue 2 build's 61.2, twelve of them, about 160px of panel.
*
* The padding is keyed on `.app-list-item-content` and not on Vuetify's own
* class, because Vuetify 3 wraps *every* row in a `.v-list-item__content` —
* the nav drawer's included, and those had no such element on the Vue 2 build.
* Measured: on Vuetify's class the sidebar's rows reach 54.4 and the drawer's
* correct 48 becomes 53. `AppListItemContent` renders this class at exactly the
* call sites whose Vue 2 markup wrote ``, so the padding
* lands where it landed before and nowhere else.
*
* The subtitle rule is the pair of the title's above, which an earlier cycle
* fixed for the same reason and left this one behind.
*/
.app-list-item-content {
padding: 12px 0;
}
/*
* …and 8px in a dense list, which is Vuetify 2's `.v-list--dense .v-list-item
* .v-list-item__content { padding: 8px 0 }`. The rule above was measured on
* the file-detail sidebar, whose lists are not dense, and left every compact
* list 8px too tall a row: the workflow canvas's plus menu draws its items
* 40px against the Vue 2 build's 32 (its own `min-height: 30px` floor, 8 + a
* 16px title + 8). Both selectors because Vuetify 2 named both: the density
* can sit on the list or on a single item.
*/
.v-list--density-compact .app-list-item-content,
.v-list-item--density-compact .app-list-item-content {
padding: 8px 0;
}
/*
* A dense list's subheader is inset 8px, as Vuetify 2 drew it.
*
* Vuetify 2: `.v-list--dense .v-subheader { padding: 0 8px }`. Vuetify 3 keeps
* its 16px whatever the density — and states the start side as
* `padding-inline-start: calc(16px + var(--indent-padding)) !important` at
* (0,2,0), after this file (VList.css:86-87). Hence three classes and
* `!important`, and `--indent-padding` kept in the sum so an `inset` subheader
* still indents. Measured on the plus menu: "General Task" at 16px from the
* card edge against the Vue 2 build's 8.
*
* The second rule is the one utility the app writes on a dense subheader —
* `px-0` on the library preview lists — which Vuetify 2's rule, not being
* `!important`, let win. Vuetify 3's is, so it never did here; this puts the
* utility back on top.
*/
.v-list--density-compact .v-list-subheader.v-list-subheader {
padding-inline: calc(8px + var(--indent-padding)) 8px !important;
}
.v-list--density-compact .v-list-subheader.v-list-subheader.px-0 {
padding-inline: 0 !important;
}
.v-list-item-subtitle.v-list-item-subtitle {
line-height: 1.2;
}
/*
* A button's label sits where the Vue 2 build put it.
*
* `app.scss` gives `.primary-button`, `.secondary-button` and `.gray-button`
* `padding: 10px 22px 12px 16px` — asymmetric, and taller than the 36px button
* can hold once its 19px label is inside. Vuetify 2's `.v-btn` was an
* `inline-flex` with `align-items: center`, so an over-tall label was centred
* across the padding box and overhung it symmetrically. Vuetify 3's is an
* `inline-grid`: the single content row is sized to the label and placed
* straight after `padding-top`, which drops the label from 71.5 to 74 — the
* text sitting visibly low in the box on every button the app pads that way.
*
* `align-content` centres that row in the content box, which is what flex was
* doing. Measured on the library preview, all four such buttons land on the
* Vue 2 build's numbers — 71.5, 267.5, 337 — and Reject, which takes Vuetify's
* own symmetric `0 16px`, stays at 338 on both. No button changes width or
* height and no icon moves; only the four the app pads asymmetrically shift.
*
* One class, not two: Vuetify declares `align-items` and `justify-content` on
* `.v-btn` and no `align-content`, so there is nothing here to outrank —
* verified at a single class rather than assumed.
*/
.v-btn {
align-content: center;
}
/*
* Field text is a colour at full strength, not a colour at 87% of itself.
*
* Reported as a white veil over the signature dialog's textarea: type into
* "Signature limit has been reached" on /settings/general?tab=profile-settings
* and the text comes out washed out against the Vue 2 build's near-black.
* Measured on both, with the same "asd" typed in:
*
* textarea | Vue 2 build | this build
* color | rgba(0, 0, 0, .87) | rgb(54, 64, 90)
* opacity | 1 | 0.87
*
* Two halves of one change. Vuetify 2 expressed high emphasis as a *colour* at
* full opacity — `.theme--light.v-input input, .theme--light.v-input textarea
* { color: rgba(0, 0, 0, .87) }`. Vuetify 3 expresses it as opacity instead:
* `.v-field__input { opacity: var(--v-high-emphasis-opacity) }`, the variable
* measured at 0.87 on both `.v-application` and `.v-overlay-container`.
*
* Dropping the Vuetify 2 colour rule did not merely leave the text black. It
* uncovered `app.scss`'s own `[class*='text-']` typography rule, which has
* always matched here — `.v-text-field` contains the substring, and this
* textarea carries `.text-area` besides — and which Vuetify 2's rule outranked
* at (0,2,1) against (0,2,0). With it gone the app rule wins and paints field
* text #36405a, which the 0.87 then lightens to roughly rgb(83, 90, 111): the
* veil. The two effects compound, so both halves are restored.
*
* The colour is deliberately re-declared at (0,2,1) — Vuetify 2's own weight,
* not a class more. `GeneralSetting.vue` carries `.general-container .v-input
* input { color: rgb(0, 0, 0) }` at exactly the same (0,2,1), and on the Vue 2
* build that tie is broken by order: component styles are injected at runtime,
* after the stylesheet, so the page rule wins and the profile form's inputs are
* pure black. Adding a class here would take those inputs to 87% black and
* break a page that currently matches. Same weight, same tie, same loser.
*
* The opacity is lifted on the `.v-field__input` box rather than on the
* controls, because that box is also VSelect's selection container and Vuetify
* 2 dimmed neither. Two rules had to be left alone to do it, both verified
* against the installed build rather than assumed:
*
* - a disabled field signals itself through its label and icons, which an
* earlier cycle moved the dimming onto when it lifted
* `.v-field--disabled` to opacity 1 so a read-only value stays legible.
* Those rules sit on the label and the icon, not on the box, so this rule
* neither reaches them nor is reached by them.
* - `.v-select--selected .v-field .v-field__input > input { opacity: 0 }`
* hides a select's inner input behind its selection chip. The selector here
* stops at the box and never names `> input`, so the input stays hidden —
* naming it would print the value twice.
*
* A note for the next person measuring this: `getComputedStyle` returned 1 for
* this textarea twice while the rule dump plainly said 0.87. Both readings
* followed a stylesheet being added or removed in a tab whose
* `visibilityState` was "hidden", where style recalculation is deferred. A
* forced reflow and a throwaway probe element carrying the same class agree on
* 0.87 five times running; that is the number.
*/
.v-field .v-field__input {
opacity: 1;
}
.v-field input.v-field__input,
.v-field textarea.v-field__input {
color: rgba(0, 0, 0, 0.87);
}
/*
* A select's value is the colour Vuetify 2 painted it, not the colour above it.
*
* Reported on `/audit-trail`: choose a value in a filter select and the text
* that appears reads grey. Measured on both builds with "Action" set to Logout:
*
* filled selection | Vue 2 rgba(0,0,0,.87) | this build rgb(187,187,187)
* plain select, no page rule above it
* | Vue 2 rgba(0,0,0,.87) | this build rgb(54,64,90)
*
* One defect with two faces, and the second is app-wide. Vuetify 2 gave the
* value box its own colour — `.theme--light.v-select .v-select__selections
* { color: rgba(0,0,0,.87) }`, read from that build's installed
* `vuetify.css:19493` — so nothing above it could reach the value. Vuetify 3
* ships no colour for the selection at all: `VSelect.css` styles
* `.v-select__selection` and `.v-select__selection-text` for layout only, and
* `VField.css:38-42` colours just the two enclosed variants, `solo` and
* `solo-filled`. Every other variant inherits, and inherits whatever is above:
*
* - on `/audit-trail` and `/notifications`, #bbbbbb. Both screens carry
* `.filter .v-input { color: #BBBBBB }` — in *both* builds. On the Vue 2
* build the rule is inert here, because an inherited colour never reaches
* an element that declares its own.
* - everywhere else, #36405a: `app.scss`'s `[class*='text-']` rule, which
* matches every field because the root carries `v-text-field`. The same
* navy leak the veil cycle fixed one rule above; the selection was left
* behind because that fix names `.v-field__input` as an *input element*,
* and in a select that class is on a `div`.
*
* `.v-field__input` is the Vue 3 name for `.v-select__selections`: the box
* holding the selection spans and the inner input. This migration already made
* that mapping by hand once — `settings/dialog/DocumentNumberFormatDialog.vue`
* says `.theme--light.v-select .v-select__selections` on the Vue 2 build and
* `.v-theme--light.v-select .v-field__input` here.
*
* (0,3,0) is deliberate: it is Vuetify 2's own weight. Matching it makes every
* tie resolve the way it resolved on the Vue 2 build — a page rule at (0,3,0)
* still wins, because component styles are injected after `app.css`, and one at
* (0,2,0) still loses. A weaker or stronger rule would quietly re-order screens
* that match today.
*
* Three roots rather than one. Vuetify 2 put `v-select` on autocompletes and
* comboboxes as well; Vuetify 3 does not — a `VAutocomplete` root carries
* `v-autocomplete` alone. Probed with each root in turn: with only the
* `.v-select` selector an autocomplete stays navy.
*
* The colour is stated on the box and not restated on `.v-select__selection`,
* which is what lets three rules keep winning, each verified by probe at
* `app.css`'s real position in the cascade:
*
* - `.v-field--disabled .v-select__selection` further down this file, and
* `.general-container .v-input .v-select__selection` on the profile screen.
* Both sit on the span, and a direct declaration beats an inherited one
* whatever the weights.
* - the placeholder, which has its own rule higher up and stays at
* rgba(0,0,0,.38) on both builds.
*
* Vuetify 2's *other* missing declaration, `.theme--light.v-input
* { color: rgba(0,0,0,.87) }`, would fix this too and is deliberately not
* restored: prefix and suffix text measure navy on **both** builds, so a
* baseline rule would push this build away from the Vue 2 one.
*/
.v-theme--light.v-select .v-field__input,
.v-theme--light.v-autocomplete .v-field__input,
.v-theme--light.v-combobox .v-field__input {
color: rgba(0, 0, 0, 0.87);
}
/*
* A field spaces its letters the way the browser spaces them.
*
* The second half of the same report: with the veil lifted, a *long* line in
* the signature textarea still read grey while a short line under it read
* black. Both lines, same element, same colour — so nothing was covering one
* of them. Setting both lines to identical glyphs and screenshotting showed the
* difference survives the glyph shapes, which rules out an artefact of thin
* letters at 12px.
*
* Measured on both builds:
*
* letter-spacing | Vue 2 build | this build
* textarea (12px) | normal | 0.1125px
* input (14px) | normal | 0.13125px
* select selection | normal | 0.15px
*
* Vuetify 3 declares `letter-spacing: 0.009375em` on `.v-field` and restates it
* on `.v-field__input`. Vuetify 2 declared neither. A fractional per-character
* offset accumulates along a line, so each successive glyph lands further from
* the pixel grid and is antialiased across two pixels instead of one: a
* thirty-seven character line greys out while a six character line beside it
* stays crisp. That is the "white shadow", and it is why it looked like it fell
* on one line and not the other.
*
* Vuetify 2 needed no rule for the controls because the browser already has
* one. Chrome's UA stylesheet resets `letter-spacing: normal` on `input` and
* `textarea` — verified here rather than assumed, by putting both inside a div
* at `letter-spacing: 5px`: the div's own text took 5px, a span took 5px, and
* the two controls came out `normal`. Vuetify 3's declarations are author-level
* and override that reset; Vuetify 2 never wrote one to override it with.
*
* So the two shapes are restored differently, and both values are deliberate:
*
* - `inherit` on the field and on the box. `letter-spacing` is an inherited
* property, so `inherit` is exactly "undeclare this" — it puts the box back
* to whatever the surrounding text is, which is what Vuetify 2's equivalent
* div did. A select's selection is that div, and inside a card it should
* pick up the card's own spacing, which `normal` would have flattened.
* - `normal` on the controls, restoring the UA reset the author-level
* declaration took away. `inherit` alone would leave them overriding it.
*
* `.v-field.v-field` rather than `.v-field`: Vuetify declares the spacing at
* one class and its stylesheet lands after this file.
*
* The select's own inner input is untouched — it carries no `.v-field__input`
* class and sits at `opacity: 0` behind the selection either way.
*/
.v-field.v-field,
.v-field .v-field__input {
letter-spacing: inherit;
}
.v-field input.v-field__input,
.v-field textarea.v-field__input {
letter-spacing: normal;
}
/*
* A field's border is a colour it declares, not one it inherits.
*
* Reported twice: the signature dialog's textarea border when active, and the
* department dialog's input border when active. One defect with two faces.
*
* Vuetify 2 gave the border an explicit colour for every state. Vuetify 3 gives
* it none and lets it inherit — every rule it ships for the outline sets
* *opacity*, and `error` is the one and only place it names a colour:
*
* .v-field__outline { --v-field-border-opacity: .38 }
* .v-field:hover .v-field__outline { --v-field-border-opacity: .87 }
* .v-field.v-field--focused .v-field__outline { --v-field-border-opacity: 1 }
* .v-field--error:not(.v-field--disabled) .v-field__outline { color: rgb(var(--v-theme-error)) }
*
* So the border is `currentColor` at a varying opacity, and `currentColor` is
* `#36405a` — the navy from `app.scss`'s `[class*='text-']` rule, which matches
* every field because `.v-text-field` contains the substring. This is the same
* leak the veil cycle fixed for field *text*; the border was left behind
* because that fix named `.v-field__input` and this lives on
* `.v-field__outline`.
*
* The Vue 2 values below are read from that build's own compiled stylesheet
* rather than guessed, and confirmed against the live page:
*
* outlined resting rgba(0,0,0,.38) 1px hover .86 focused primary 2px disabled rgba(0,0,0,.26)
* underlined resting rgba(0,0,0,.42) hover .87 focused primary (::after)
* filled as underlined
* solo no border in either build — nothing to state
*
* Stating the colour as black and leaving Vuetify's opacity ramp to do the rest
* is deliberate: `color: rgba(0,0,0,.38)` would multiply with that ramp and
* land at .144. Only the two opacities Vuetify 3 picks differently are pinned.
*
* ── One deliberate deviation from the Vue 2 build ──────────────────────────
*
* Where the Vue 2 build paints a focused border it uses **#1976D2**. That is
* Vuetify 2's *default* primary: that build's `plugins/vuetify.js` configures
* no theme at all, so the framework default is showing through and nobody ever
* chose it. Vuetify 2 painted the border through `primary--text`, i.e. the
* theme's primary — and this build's theme names the design system's blue,
* #2153CD (`resources/plugins/theme.js`), so the rule reads the token rather
* than restating the value. The same token is what every `color="primary"`
* paints, which is exactly Vuetify 2's mechanism.
*
* This is a departure from parity, made deliberately. A later parity sweep that
* measures #1976D2 on the Vue 2 build and "corrects" this back would be
* undoing a decision, not fixing a defect.
*
* ── Order and specificity ─────────────────────────────────────────────────
*
* `error` has to survive both rules, including on a field that is focused *and*
* invalid. Vuetify's error rule is (0,3,0) against the focus rule's (0,2,0), so
* it wins on weight — verified by building the two classes together rather than
* reasoned about: an errored focused field stays #CF2E18 and does not turn
* blue. The opacity pins are (0,2,0) and tie with Vuetify's own hover and focus
* rules, which land after this file, so hover and focus keep Vuetify's ramp —
* which is what the Vue 2 numbers want.
*
* A measurement note, because it cost a wrong first answer: reading a field's
* computed border colour immediately after its focus class appears returns the
* *previous* state. The first pass here recorded the Vue 2 focused border as
* `rgba(0,0,0,.38)` — the resting value — and only a second reading, taken
* after the class had settled, showed #1976D2. Vuetify 2's own stylesheet says
* plainly that focus inherits the primary; when a measurement and the shipped
* rule disagree, re-measure before believing the measurement.
*/
.v-field__outline {
color: black;
}
.v-field--focused .v-field__outline {
color: rgb(var(--v-theme-primary));
}
.v-field--variant-underlined .v-field__outline,
.v-field--variant-filled .v-field__outline {
--v-field-border-opacity: 0.42;
}
.v-field--disabled .v-field__outline {
--v-field-border-opacity: 0.26;
}
/*
* A switch that names no colour still turns the app's blue.
*
* Vuetify 2 gave an uncoloured switch its primary when on. Vuetify 3 gives it
* nothing, so a switch with no `color` prop paints the same grey on as off —
* on `/settings/company-information?tab=backup-data` the automatic-backup
* toggle read as off while it was on. Measured there:
*
* on, track | Vue 2 #1976D2 @ .32 | this build #424242 @ .6
* on, thumb | Vue 2 #1976D2 | this build white
*
* The theme's primary rather than the Vue 2 build's #1976D2, for the reason
* recorded on the field-border rule above: #1976D2 is Vuetify 2's *default*
* primary, showing through a build that configures no theme. Vuetify 2's
* `computedColor` fell back to `'primary'` for an uncoloured switch, and the
* token is that fallback. The two rules must move together.
*
* A call site that names its own colour still wins the track: Vuetify writes
* the prop as an inline `background-color` there, and this declaration is not
* important. The thumb has no such inline, so this paints it unconditionally —
* checked before relying on it, all six switches that pass a colour pass this
* exact blue, and `NotificationSettings.vue` overrides the thumb `!important`
* for its own.
*/
.v-switch .v-selection-control--dirty .v-switch__track {
background-color: rgb(var(--v-theme-primary));
opacity: 0.32;
}
.v-switch .v-selection-control--dirty .v-switch__thumb {
background-color: rgb(var(--v-theme-primary));
}
/*
* A label is the colour Vuetify 2 painted it, so an app rule cannot take it.
*
* `CompanyInformation.vue` carries `.company-info-container label { color:
* #2153CD }`, which is (0,1,1). Vuetify 2's `.theme--light.v-label { color:
* rgba(0,0,0,.6) }` is (0,2,0) and outranked it, so that rule never reached a
* radio, a checkbox or a field label. Vuetify 3 ships `.v-label { color:
* inherit }` at (0,1,0), which does not outrank it — and every label on the
* backup screen came out blue.
*
* That is the fourth time this migration has hit the same shape: removing a
* vendor declaration promotes an app rule that was never written to apply. The
* others were the field's text, its letter-spacing and its border.
*
* Stated at (0,2,0), Vuetify 2's own weight, and deliberately not higher: every
* app rule that outranked Vuetify 2 here still outranks this, so nothing the
* app colours on purpose moves. Vuetify 3 leaves `.v-label` at opacity 1 inside
* a selection control, so the colour carries the emphasis exactly as Vuetify 2's
* did — measured `rgba(0,0,0,.6)` at opacity 1 on both builds.
*/
.v-theme--light .v-label {
color: rgba(0, 0, 0, 0.6);
}
/*
* A radio group's control fills its row, so a column in it is a column.
*
* Vuetify 2 gave `.v-input--radio-group__input` `width: 100%`. Vuetify 3's
* equivalent, `.v-selection-control-group`, sits inside `.v-input__control`,
* which is `flex: 0 1 auto` in a wrapping flex `.v-input` — so it sizes to its
* content instead of the row. On the backup screen that left the control 1085px
* wide inside an 1810px input, and the three `v-col-4` document-type cards took
* a third of the wrong number: 362px against the Vue 2 build's 595.
*
* `width: 100%` on the group itself is not the fix and was tried first: the
* group is already as wide as the control, so it changed nothing. The control
* is what has to grow.
*
* Scoped to `.v-radio-group` because that is the scope Vuetify 2's rule had.
* Checkbox and switch groups were measured in their own cycles and are right as
* they stand.
*/
.v-radio-group .v-input__control {
flex: 1 1 auto;
}
/*
* A checked tick is the colour the control names, or the app's blue.
*
* Reported as checkbox and radio colours still differing. Measured on the
* backup screen: the Vue 2 build paints a checked control `#1976D2` and an
* unchecked one `rgba(0, 0, 0, .54)`; here both came out `rgba(0, 0, 0, .54)`,
* so a selected radio was indistinguishable from an unselected one.
*
* The cause is this stylesheet's own `.v-icon { color: rgba(0, 0, 0, .54) }`
* from the icon cycle. Vuetify 3 does not colour the tick directly at all — it
* writes the colour on `.v-selection-control__wrapper` and lets the icon
* inherit, so a blanket colour on `.v-icon` swallows it. Verified by neutralising
* that one rule against a mounted control: the tick came back `#3F51B5` for
* `color="indigo"` and `#2153CD` for `color="#2153CD"`, both of which the app
* passes at real call sites and neither of which was reaching the screen.
*
* So this is two defects in one. **44 call sites pass `color="indigo"` and ten
* more pass a hex**, and every one of them has been painting 54% black. The
* remaining 115 pass nothing and want the Vue 2 default, which Vuetify 3 does
* not have — `error` is the only state it names a colour for.
*
* The shape follows from where Vuetify writes the prop, which was measured
* rather than assumed:
*
* color="indigo" -> class `text-indigo` on `.v-selection-control__wrapper`
* color="#2153CD" -> inline `color` on the same element
* no prop -> nothing at all
*
* The default is set on the *control*, one level above the wrapper, as the
* conservative placement — it leaves the element Vuetify writes to untouched.
*
* It is worth being exact about what protects those 54 call sites, because a
* first draft of this comment got it wrong and claimed the placement did.
* It does not: Vuetify's colour utilities are `!important`
* (`.text-indigo { color: … !important }`) and a hex prop lands inline, so a
* named or hex colour outranks anything written here wherever it is written.
* Moving this default onto the wrapper was tried and changed none of them.
* What the placement buys is only that nothing here competes with the element
* Vuetify owns.
*
* The theme's primary rather than the Vue 2 build's `#1976D2` is the deviation
* settled in the field-border cycle and repeated for the switch: `#1976D2` is
* Vuetify 2's *default* primary, showing through a build that configures no
* theme, and Vuetify 2's `computedColor` fell back to `'primary'` for exactly
* this case. Two components had already hand-patched this same defect locally
* with `#2153CD`, the value the token now carries.
*
* The label is not affected: `.v-theme--light .v-label` is a declaration on the
* label itself and outranks inheritance, so a checked control's text stays
* `rgba(0, 0, 0, .6)`. The switch is not affected either — its track and thumb
* carry explicit backgrounds from the cycle above.
*/
.v-selection-control .v-icon {
color: inherit;
}
.v-selection-control:not(.v-selection-control--dirty) {
color: rgba(0, 0, 0, 0.54);
}
.v-selection-control--dirty {
color: rgb(var(--v-theme-primary));
}
/*
* A dense list titles its rows the way Vuetify 2 did.
*
* Vuetify 2: `.v-list--dense .v-list-item__title { font-size: 0.8125rem;
* font-weight: 500; line-height: 1rem }`. Vuetify 3 changes nothing about a
* title by density, so every compact list drew Vuetify's 1rem/400/1.2 instead —
* on a select's option card that is 16px/400/19.2px against the Vue 2 build's
* 13px/500/16px.
*
* `--parity-list-floor` above already restores the *row* height for the same
* lists; this is the type that went with it.
*
* Both selectors because Vuetify 2 named both: the density can sit on the list
* or on a single item.
*/
.v-list--density-compact .v-list-item-title,
.v-list-item--density-compact .v-list-item-title {
font-size: 0.8125rem;
font-weight: 500;
line-height: 1rem;
}
/*
* A treeview label is not a dense list title, whatever Vuetify 3 builds it out of.
*
* Vuetify 2 drew a node label as `.v-treeview-node__label`, which declared no
* type at all: the label took the font of whatever the call site put on the
* treeview. Every one of them puts something there — `MassAcknowledge.vue`
* writes `class="… text-caption treeview-to-select"`, so its labels were the
* caption 12px/400 on the Vue 2 build.
*
* Vuetify 3 builds the treeview out of `VList`, and its list is
* `density="compact"`, so the rule above — written for a select's option card —
* reached every treeview label in the app and made it 13px/500/16px. Measured
* on `/workflow?tab=mass-acknowledge`, ~250 file and folder rows:
*
* Vue 2 `.v-treeview-node__label` 12px / 400 / 20px
* before `.v-list-item-title` 13px / 500 / 16px
* after 12px / 400 / 18px
*
* 18px rather than the Vue 2 build's 20px is the brand's caption leading
* (`_typography.scss`, `--type-caption-line: 1.5`), which is what every other
* 12px line on the screen already reads.
*
* Three classes: the rule above is two and lands earlier in this file, and
* Vuetify's own `.v-list-item-title` is injected after `app.css` altogether.
* `letter-spacing` is deliberately left alone — the list-title block near the
* top of this file takes it off every list title on purpose.
*/
.v-treeview .v-list-item-title.v-list-item-title {
font-size: inherit;
font-weight: inherit;
line-height: inherit;
}
/*
* An empty table says so in Vuetify 2's grey.
*
* Vuetify 2 painted the placeholder row itself:
* `.theme--light.v-data-table .v-data-table__empty-wrapper { color:
* rgba(0, 0, 0, 0.38) }`. Vuetify 3 renames the row `.v-data-table-rows-no-data`
* and gives it no colour, so "No data available" inherits whatever the screen
* puts on the table — measured on `/workflow?tab=mass-route`, where it is the
* app's own `rgba(0, 0, 0, 0.87)`: the same weight as real data, in a row that
* is telling you there is none.
*
* One class is enough because nothing declares a colour on the cell itself;
* the 0.87 above it is inherited, and any declared value beats inheritance.
*/
.v-data-table-rows-no-data {
color: rgba(0, 0, 0, 0.38);
}
/*
* The chosen option is the colour Vuetify 2 painted it.
*
* Vuetify 2 gave `.v-list-item--active` its primary, so the option matching the
* select's value stood out in the card. Vuetify 3 gives it a background overlay
* and no colour at all, so it read as `rgba(0, 0, 0, .87)` — identical to every
* other option. The sixth Vuetify 2 default with no Vuetify 3 equivalent this
* migration has had to put back, after the switch and the selection-control
* tick among others; the theme's primary for the reason recorded on the
* field-border rule.
*
* Scoped to `.v-select__content`, which is the class Vuetify puts on a select's
* overlay: a select's option card is what was measured. The sidebar and the
* account menu style their own active rows and have not been compared.
*/
.v-select__content .v-list-item--active {
color: rgb(var(--v-theme-primary));
}
/*
* A disabled tick is grey, not a faded version of its colour.
*
* Reported on `/settings/permission-control`, where every checkbox is disabled.
* Measured on both builds, 32 boxes each:
*
* tick colour | Vue 2 rgba(0, 0, 0, .38) | this build #2153CD
* control opacity | Vue 2 1 | this build 0.38
*
* so the Vue 2 build draws flat grey and this one drew a washed-out blue.
*
* The cycle above gave a checked control the app's blue and let the tick
* inherit it. That rule does not exclude disabled controls, and Vuetify 3 then
* dims the whole control with
* `.v-selection-control--disabled { opacity: var(--v-disabled-opacity) }`.
* Vuetify 2 expressed disabled as a *colour at full opacity* instead — the
* same colour-versus-opacity split this migration has already met in the
* field's text, its border and its placeholder.
*
* The Vue 2 value is state-independent: checked and unchecked disabled boxes
* are both `rgba(0, 0, 0, .38)`, checked by viewing two roles, and its
* stylesheet says so directly — `.theme--light.v-input--is-disabled` sets that
* colour and `.v-input--selection-controls.v-input--is-disabled .v-icon`
* inherits it.
*
* Order matters as much as weight here, and both were checked against the
* rules above: `.v-selection-control--dirty` is (0,1,0) and loses to this at
* (0,2,0), but `.v-selection-control:not(.v-selection-control--dirty)` is also
* (0,2,0) — so this has to sit *after* it in the file, which is why it is at
* the end rather than beside its siblings. Vuetify's own disabled rule is
* (0,1,0), so `opacity: 1` clears it.
*
* Scoped to `.v-checkbox-btn` and `.v-radio` deliberately. The same
* `--disabled` class lands on a disabled *switch*, which Vuetify 2 styled with
* explicit track and thumb colours rather than a dimmed tick; those numbers
* were measured and closed in their own cycle, and `opacity: 1` reaching them
* would stop a disabled switch dimming at all.
*/
.v-checkbox-btn.v-selection-control--disabled,
.v-radio.v-selection-control--disabled {
color: rgba(0, 0, 0, 0.38);
opacity: 1;
}
/*
* A tab's label is styled by the tab, not by the page's button rules.
*
* Vuetify 2 put a tab's text straight in the tab, so it took the tab's own
* typography. Vuetify 3 renders a tab as a `
`, so Bootstrap's `hr { margin: 1rem 0 }` reaches * it. On the Vue 2 build Vuetify's own `.v-divider--vertical { margin: 0 -1px }` * shorthand zeroed the block axis back out; Vuetify 3 writes `margin-left: -1px` * and leaves the block axis alone, so the 1rem lands. `/compliance/index` grew * 10px the moment the Bootstrap rule came back. * * `margin-block`, not the shorthand, so a `mt-*` utility at the call site still * decides the top margin — which is what the Vue 2 build did: that divider * carries `mt-1` and measures 4px above, 0 below, on both builds now. */ .v-divider--vertical { margin-block: 0; } /* * An inset vertical divider takes its 8px from the top only. * * The rule Vuetify 2 wrote against the rule Vuetify 3 writes: * * .v-divider--vertical.v-divider--inset { .v-divider--inset.v-divider--vertical { * margin-top: 8px; margin-top: 8px; * min-height: 0; margin-bottom: 8px; // added * max-height: calc(100% - 16px); max-height: calc(100% - 16px); * } } * * One declaration, and it costs the line 8px of the row it stretches in. * `/workflow`'s UI toggle — the app's only inset divider — draws 20px between * its two buttons against the Vue 2 build's 28, in a 36px flex row on both. * * `max-height` is the same on both builds and applies to neither: the flex * parent's height is not definite, so the percentage resolves to `none` and the * margins alone decide. 36 - 8 is 28; 36 - 8 - 8 is 20. * * `min-height` is deliberately not restored. Vuetify 2's `0` existed only to * undo its own `min-height: 100%` on the base vertical rule, which Vuetify 3 * does not have — this build computes `auto` where that one computes `0px`, and * no divider in the app measures differently for it. * * Three classes: Vuetify's rule is two and its stylesheet is injected after this * file, so an equal-specificity rule here would lose. `margin-top` is left to * Vuetify, which happens to write the value Vuetify 2 wrote. */ .v-divider--vertical.v-divider--vertical.v-divider--inset { margin-bottom: 0; } /* * Pagination is the size and the shape the Vue 2 build drew. * * The control grew an element between the two majors: * * Vue 2 Vuetify 3 * nav.pagination (the app's) nav.v-pagination.pagination * ul.v-pagination — the row ul.v-pagination__list — the row * button.v-pagination__item li.v-pagination__item > button.v-btn * * So the page number is a `v-btn` now, and everything Vuetify 2 put on * `.v-pagination__item` — `height: 34px`, `min-width: 34px`, `border-radius: 4px`, * a white background and an elevation-1 shadow — has no counterpart: * `.v-btn--icon.v-btn--density-default` sizes it `calc(var(--v-btn-height) + 12px)` * instead, which is 48px. Measured on `/audit-trail`, the row went 43.6px -> * 57.6px and the current page lost its filled `rgb(25, 118, 210)` pill. * * The size goes through `--v-btn-height` rather than `width`/`height` on * purpose. The token is declared on `.v-btn--size-default` (0,1,0), so a rule * at `.v-pagination__item .v-btn` (0,2,0) wins outright; `width` and `height` * are declared on `.v-btn--icon.v-btn--density-default` (0,2,0), which would * tie and then win on document order, since Vuetify's stylesheet lands after * this file. * * `margin: .3rem` is not restated: Vuetify 3 already carries it on * `.v-pagination__item`, the same value Vuetify 2 had, and neither is the 4px * `border-radius` — `.v-btn--rounded.v-btn--icon` already draws it, measured * before this rule existed. Restating either would only raise the specificity * a screen's own rule has to clear. */ .v-pagination__item .v-btn { /* 22 + 12 = the Vue 2 build's 34px. */ --v-btn-height: 22px; min-width: 34px; width: auto; background: #ffffff; /* Vuetify 2's elevation-1, read off the Vue 2 build. */ box-shadow: 0 3px 1px -2px rgba(0, 0, 0, 0.2), 0 2px 2px 0 rgba(0, 0, 0, 0.14), 0 1px 5px 0 rgba(0, 0, 0, 0.12); /* * The screens' own rules are written on `.v-pagination__item`, which is the * `
- `, so Bootstrap Reboot's
* `ol, ul, dl { margin-bottom: 1rem }` reaches it. Vuetify 2 zeroed it back out
* with `margin: 0` on `.v-pagination`; Vuetify 3's `.v-pagination__list` sets
* `display`, `list-style-type`, `justify-content` and `width` — and no margin.
*
* The 16px lands below the control, inside whatever wraps it:
* `/audit-trail`'s `.pagination-container` measured 59.6px around a 43.6px row.
* Same shape as the `v-divider` finding — a Bootstrap element rule that
* Vuetify 2 happened to cancel and Vuetify 3 does not.
*
* `margin-block`, so a `my-*` at the call site still decides.
*/
.v-pagination__list {
margin-block: 0;
/*
* And no indent either. `.v-application ul` below restores the 24px Vuetify 2
* put on lists inside the app, and Vuetify 2 zeroed it again on its own list
* components — `.v-pagination { padding-left: 0 }` is in the Vue 2 bundle.
* Vuetify 3 has no such rule because nothing was adding one. Measured: with
* the indent alone this reads 24px on `/audit-trail` and `/settings/version`
* where the Vue 2 build reads 0.
*
* `.v-application` in front because the indent rule is (0,1,1) and one class
* here would lose to it.
*/
}
.v-application .v-pagination__list {
padding-left: 0;
}
/*
* An underlined field sits 4px below whatever is above it.
*
* Vuetify 2's `.v-text-field { padding-top: 12px; margin-top: 4px }` applied to
* every field and was cancelled by
* `.v-text-field--enclosed { margin: 0; padding: 0 }` — so the 4px belonged to
* the *non-enclosed* field, the plain underlined one. Vuetify 3 has no
* equivalent at any variant.
*
* `--plain-underlined` is the class Vuetify 3 puts on the input root for that
* variant, and it is the one the wrapper produces for a Vuetify 2 field with no
* `outlined`, `solo` or `filled` (`propCompat.js:58-75` never returns `plain`).
* So the selector names exactly the fields Vuetify 2 gave the margin to.
*
* Measured on `/workflow`, whose filter row holds three of them: 62px against
* the Vue 2 build's 66, which was the whole of that screen's 4px. Everywhere
* else the app writes `mt-0` and wins on `!important` — as it did on the Vue 2
* build, which is why `/audit-trail`'s four underlined fields have no margin on
* either build.
*/
.v-input--plain-underlined {
margin-top: 4px;
}
/*
* An icon is the size, and the shape, the Vue 2 build drew it.
*
* Vuetify 2 sized an icon with a flat base and four rules over it, all four of
* them about a button. Read out of the Vue 2 build's own stylesheet:
*
* .v-icon.v-icon { font-size: 24px }
* .v-btn--icon.v-size--x-small .v-icon,
* .v-btn--fab.v-size--x-small .v-icon { 18px, and an 18x18 box }
* small, default { 24 }
* large { 28 }
* x-large { 32 }
* .v-btn__content .v-icon.v-icon--left,
* .v-btn__content .v-icon.v-icon--right { 18px, and an 18x18 box }
*
* Vuetify 3 has none of them. Its size is `.v-icon--size-
` lays its child out the way Vuetify 2's did.
*
* Twenty-eight sites wrap a disabled button in a `div` wearing `.v-btn` so a
* tooltip has a live element to hang from. Vuetify 2's `.v-btn` made that
* div an `inline-flex` box centring its content; Vuetify 3's `.v-btn` is an
* `inline-grid` with `max-content auto max-content` columns (VBtn.css), so a
* `block` button inside it is sized to a `max-content` column instead of the
* row — the business process's duplicate button, 48px inside a 137.5px div
* even with the rule above, because its `100%` resolved against that column.
* Vuetify 3 renders no `div.v-btn` of its own (VBtn renders a button or an
* anchor), so the tag is what tells the hand-written ones apart.
*/
div.v-btn {
display: inline-flex;
align-items: center;
justify-content: center;
}
/*
* A sort icon is 18px, which is the one size Vuetify 2 set inline rather than
* through a rule — so the base above would make it 24. Pinned at the literal
* value the Vue 2 build draws rather than handed back to
* `--v-icon-size-multiplier`, which happens to yield 18 in a table header today
* and would follow the header's type the moment that changed.
*/
.v-data-table-header__sort-icon.v-data-table-header__sort-icon {
font-size: 18px;
}
/*
* A switch is the size the Vue 2 build drew it.
*
* Vuetify 3 rebuilt the switch around `.v-selection-control` and resized every
* part of it: an inset track is 32px tall and 52px wide (VSwitch.css:49-54),
* the thumb is 24px, and the row is floored by `--v-selection-control-size`,
* which is 28px at compact density (VSelectionControl.css:40-42). The Vue 2
* build draws a 24px row around a 44x22 track with an 18px thumb.
*
* Measured on `/settings/version`, where three of them sit in the author
* permission cards: 40px each against 24, which was 48px of that page's 1683
* against the Vue 2 build's 1635.
*
* This is the case the checkbox rule above deferred by name — "radios and
* switches are selection controls too and were not measured". All 23 switches
* in the app pass `inset` and `density="compact"`, so there is one shape to
* match rather than a family. Radios are still unmeasured and still untouched.
*
* Two of the four specificities carry the fix and neither is arbitrary:
*
* - `--v-selection-control-size` is declared on `.v-selection-control` here
* because that is where Vuetify declares it, and an element's own
* declaration beats an inherited one. Put on `.v-switch` it is ignored and
* the row stops at 28px — measured, not assumed.
* - the track and thumb rules repeat `--inset` because Vuetify's own are
* `.v-switch--inset .v-switch__track` and `.v-switch--inset .v-switch__thumb`,
* two classes each, landing after this file. Two classes here lose on
* document order — measured: the row reached 24px while the track stayed
* 52x32 and the thumb 24x24.
*
* `transform: none` because Vuetify 3 shrinks an *unchecked* inset thumb to
* two thirds (`VSwitch.css:81-90`) and restores it only when the control is
* dirty. The Vue 2 build draws 18px in both states — measured on this page,
* whose third switch is off and still 18x18 — so an 18px thumb would otherwise
* read 12px when off.
*
* The control comes out 44px wide against the Vue 2 build's 56. These switches
* sit in a `justify-space-between` row, so that moves nothing — recorded rather
* than chased.
*/
.v-switch.v-switch {
--v-input-control-height: 24px;
}
.v-switch .v-selection-control {
--v-selection-control-size: 24px;
}
.v-switch--inset.v-switch--inset .v-switch__track {
height: 22px;
min-width: 44px;
}
.v-switch--inset.v-switch--inset .v-switch__thumb {
height: 18px;
width: 18px;
transform: none;
}
/*
* A radio is the size and the shape the Vue 2 build drew it.
*
* The last selection control, and the one the checkbox and switch cycles both
* deferred by name — "radios are still unmeasured and still untouched". They
* were unmeasured for a reason: 111 call sites and not one of them renders on
* any of the sixteen sweep routes, or on any route at rest, on either build.
* The measurement here is `/form-builder/form/edit/242` — a form with two radio
* fields — with its fifth section tab open, on both builds.
*
* Vuetify 2 sized a radio with three rules that Vuetify 3 has no equivalent of:
*
* .v-input--selection-controls__input { height: 24px; width: 24px }
* .v-application--is-ltr .v-input--selection-controls__input { margin-right: 8px }
* .v-input--radio-group--row .v-radio { margin-right: 16px }
*
* Vuetify 3 replaced the first with `--v-selection-control-size`, which is 40px
* at the default density and 28px at compact (VSelectionControl.css:36-42) —
* where Vuetify 2's tick was 24px at *both* — and dropped the other two
* outright, so the label butts against the tick and the radios in a row have no
* gap between them. Measured: a 28x28 tick in a 28px row against a 24x24 tick in
* a 24px one, with 0px where the Vue 2 build puts 8 and 16.
*
* The icon inside is 20px, not the 24px base. Vuetify 2 gave a selection
* control in a dense input the `v-icon--dense` class and sized it
* `font-size: 20px`; Vuetify 3 has no dense icon and draws the default 24. It
* fills its 24px tick either way, because Vuetify 2's
* `.v-input--selection-controls__input .v-icon { width: 100% }` said so — which
* the icon cycle's `width: auto` base would otherwise shrink to the glyph.
*
* Scoped to `.v-radio` throughout, deliberately. Vuetify 2's tick rules were
* written for *every* selection control, checkboxes and switches included, but
* those two were measured and closed in their own cycles and are right as they
* stand — widening these rules would move them off the numbers they were pinned
* to.
*
* `.v-radio.v-radio` for the token because Vuetify declares it on the same
* element (`.v-selection-control--density-compact`), and `.v-radio.v-radio` for
* the label because Vuetify's `.v-selection-control .v-label` is two classes and
* lands after this file. The other three compete with nothing.
*
* The 20px glyph keys off the *control's* own density class rather than the
* group's `.v-input--density-compact`. Both are present when a group sets the
* density, which is every call site the app has; a radio given `density`
* directly carries only the first, and a descendant selector would miss it.
*
* The row direction is not here — it is a renamed prop, not a rule. See the
* three `:inline` call sites.
*/
.v-radio.v-radio {
--v-selection-control-size: 24px;
}
.v-radio .v-selection-control__wrapper {
margin-right: 8px;
}
.v-radio .v-selection-control__input > .v-icon {
width: 100%;
height: 100%;
}
.v-radio.v-selection-control--density-compact .v-icon {
font-size: 20px;
}
.v-selection-control-group--inline .v-radio {
margin-right: 16px;
}
.v-radio.v-radio .v-label {
height: auto;
}
/*
* A bullet list keeps the indent Vuetify 2 gave it.
*
* A bare `
- ` appended to `` reads `padding-left: 0` on *both* builds,
* so this is not a reset that went missing: Vuetify 2 put the indent back
* inside the app with `.v-application ul, .v-application ol { padding-left:
* 24px }`, and Vuetify 3 ships nothing equivalent.
*
* Every rich-text list the app renders has been drawing its bullets flush with
* the text, which is a content defect before it is a height one. It shows as a
* height on the academy course page, where the last item of "Who this course is
* for" has 749px of room here against 725 on the Vue 2 build and so fits on one
* line where the Vue 2 build wraps it onto two: the page measured 1458 against
* 1477.
*
* Vuetify 3's own `
- ` components are unaffected — `.v-breadcrumbs` sets its
* own padding at higher specificity, and `.v-pagination__list` is zeroed above,
* the way Vuetify 2 zeroed `.v-pagination`.
*/
.v-application ul,
.v-application ol {
padding-left: 24px;
}
/*
* A breadcrumb carries no margin of its own.
*
* `.v-breadcrumbs` is a `
- `, so Bootstrap Reboot's
* `ol, ul, dl { margin-bottom: 1rem }` reaches it: `0px/16px` here against
* `0px/0px` on the Vue 2 build, where Vuetify 2's own rule cancelled it.
*
* Fourth instance of the same shape, after `hr`, the vertical divider and the
* pagination list: a `v-*` component that renders a bare element inherits
* Reboot, and Vuetify 2's resets were quietly doing that cancelling.
*/
.v-breadcrumbs {
margin-block: 0;
}
/*
* A divider is a line you can see.
*
* Vuetify 2 drew one with `border-color: rgba(0, 0, 0, 0.12)` at full opacity.
* Vuetify 3 takes the colour from `currentColor` and applies
* `opacity: var(--v-border-opacity)` — 0.12 — instead. `v-divider` renders an
* `
`, so the colour it inherits here is Bootstrap's `rgba(0, 0, 0, 0.1)`, * and 0.1 multiplied by an opacity of 0.12 is an effective alpha of **0.012**: a * line that is technically drawn and practically invisible. * * Reported on the account menu, where three of them separate the sections, and * true of every divider in the app. * * Two classes: Vuetify's own rule is one and its stylesheet lands after this * file. */ .v-divider.v-divider { border-color: rgba(0, 0, 0, 0.12); opacity: 1; } /* * A list subheader keeps the Vue 2 build's leading. * * Vuetify 2's `.v-subheader` set no `line-height` at all and inherited * `.v-application`'s 1.5, which at its 14px is 21px. Vuetify 3 pins * `line-height: 1.375rem` — 22px. One pixel a subheader, and the last two of the * account menu's card once its dividers and its subheader height are right. * * Two classes, because Vuetify's own rule is one and lands after this file — * measured, not assumed: at one class the subheader stayed 22px through a full * rebuild. */ .v-list-subheader.v-list-subheader { line-height: 1.5; } /* * A breadcrumb item takes no horizontal padding, as the Vue 2 build drew it. * * Vuetify 2's `.v-breadcrumbs__item` set none at all; Vuetify 3's * `.v-breadcrumbs-item` adds `padding: 0 4px` (VBreadcrumbs.css:30-35). That is * 8px an item, and the library preview's three-crumb trail measured 193px wide * against the Vue 2 build's 169 — the dividers between them are already * identical at `0 4px` on both. * * Two classes, because Vuetify's own rule is one and its stylesheet lands after * this file. */ .v-breadcrumbs-item.v-breadcrumbs-item { padding: 0; } /* * A loading overlay centres its spinner, as the Vue 2 build drew it. * * Vuetify 2's `.v-overlay` was a centring flex box — `align-items: center; * justify-content: center` — with `.v-overlay__content` in normal flow. * Vuetify 3 rebuilt the component as the positioning primitive behind VDialog, * VMenu and VTooltip, which place their own content: `.v-overlay` keeps * `display: flex` and drops both alignment properties, and * `.v-overlay__content` becomes `position: absolute` (VOverlay.css:26-40). * With no insets that lands the spinner at 0,0 — on the library preview, in the * top-left corner of the viewport with half of it behind the app bar, against * the Vue 2 build's 928,393.5. * * Both declarations are needed and neither works alone: an absolutely * positioned child is out of flow, so the alignment moves nothing until the * content is `relative` again. * * `color` is Vuetify 2's `.theme--dark.v-overlay`, which every one of these * overlays got — its `dark` defaulted to true — and is what made the spinner * white. Vuetify 3 has no such rule, so the spinner inherited the app's body * colour and came out near-black on the scrim. * * Keyed on `.app-overlay`, which AppOverlay adds, so that the dialogs, menus, * tooltips and snackbars sharing these classes are left alone — they position * their content through `locationStrategy` and must stay absolute. * * Two classes, because Vuetify's own rules are one and its stylesheet lands * after this file. */ .v-overlay.app-overlay { align-items: center; justify-content: center; color: #fff; } .v-overlay.app-overlay > .v-overlay__content { position: relative; } /* * A column is a containing block, as the Vue 2 build's was. * * Vuetify 2's grid opened its column rule with `position: relative` — the same * declaration Bootstrap's does, and for the same reason: a column is the box an * absolutely positioned child is meant to hang off. Vuetify 3's rule sets only * `width` and `padding` (VGrid.css:29-38), so every `.v-col` stopped being a * containing block and its absolutely positioned children started resolving * against whatever ancestor happens to be positioned further up. * * Found through the profile avatar, whose `absolute` overlay is positioned by * the app's own `top: 12px; left: 12px`: against the column it lands on the * 100x100 avatar at 132,234, which is where the Vue 2 build draws it, and * against the page it landed 24px up and to the left, off the picture entirely. * Nothing else on the sixteen routes moves. * * Both selectors, because Vuetify writes the sized columns as `v-col-md-1` and * the unsized one as `v-col`; an element usually carries both but not always. * One class each is enough — Vuetify declares no `position` here to beat. */ .v-col, [class*=v-col-] { position: relative; } /* * A list row's content box keeps the Vue 2 build's padding and leading. * * Vuetify 2's `.v-list-item__content` carried `padding: 12px 0`, and its * `.v-list-item__subtitle` took `line-height: 1.2` from the item * (export-pdf.css:52078-52086, 52139-52142). Vuetify 3's content wrapper * carries no padding at all and pins the subtitle at `line-height: 1rem` * (VListItem.css:219-224, 286-292) — 16px whatever the font size, against the * 16.8 the app's 14px subtitle had. The file-detail sidebar's rows came out 48px * against the Vue 2 build's 61.2, twelve of them, about 160px of panel. * * The padding is keyed on `.app-list-item-content` and not on Vuetify's own * class, because Vuetify 3 wraps *every* row in a `.v-list-item__content` — * the nav drawer's included, and those had no such element on the Vue 2 build. * Measured: on Vuetify's class the sidebar's rows reach 54.4 and the drawer's * correct 48 becomes 53. `AppListItemContent` renders this class at exactly the * call sites whose Vue 2 markup wrote `