/* * The account screen: a themed hero above the real * [bookly-customer-cabinet] shortcode (page-mano.php's docblock explains why * the shortcode is embedded rather than rebuilt to match the mockup's own * tile grid). * * Enqueued only where it is used (plan section 1.1, engineering standards * section 7). Loads after components.css and builds on both it and * tokens.css; declares no colour of its own. * * SCOPE, HONESTLY STATED: this is a lighter pass than bookly.css gives the * booking widget. That file exists because the booking form is the page * every visitor completes a purchase through - worth fighting Bookly's own * !important rules component by component. The account cabinet is a * secondary, logged-in-only utility screen; this file brings its type, * accent colour and corner radii onto the design tokens without attempting * to restyle its Bootstrap layout piece by piece. * * VERIFIED AGAINST A POPULATED CABINET ON 2026-09-02 (WPS-035), which this * file previously asked for in as many words. The empty cabinet that earlier * reading blamed on local test data was not test data: page-mano.php called * [bookly-customer-cabinet] with no attributes, and the shortcode builds its * tabs and columns from attributes alone. With a real customer, a real * appointment and the attributes now passed, the tab content renders - and * the one thing that then did NOT work on a phone is overridden at the end * of this file. */ .am-hero { padding-block: clamp( 24px, 4vw, 44px ) clamp( 16px, 2.5vw, 24px ); } .am-hero__row { display: flex; flex-wrap: wrap; align-items: center; justify-content: space-between; gap: var( --space-3 ); } .am-hero__title { margin: 0; font-size: clamp( 28px, 4.2vw, 42px ); font-weight: var( --fw-black ); line-height: 1.08; color: var( --text-heading ); letter-spacing: var( --ls-display ); text-wrap: pretty; } /* * THE SIGN-OUT CONTROL CARRIES THE BUTTON CLASSES NOW INSTEAD OF IMITATING * THEM, and the reason came from Andrius looking at it beside the row's cancel * button on 2026-09-07: "their roundness does not look the same". * * Both declare `--radius-pill`, so the radius was never the difference - the * HEIGHT was. A pill's corner can only be half its box, and these measured * 46.4px and 44px, which is 23.2px of curve against 22px. Two more differences * came out of the same measurement, both invisible until you look for them: * this control drew its hairline in --color-border-strong where the design * system's secondary button uses --border-control, and it had no `transition` * at all, so its hover snapped while every other button on the site eases. * * The fix is to stop keeping a second copy. `.btn.btn--sm.btn--secondary` is * exactly what this was reaching for - 14px type, 11px 22px, pill, the accent * hover - and page-mano.php now says so, so the values can never drift again. * What stays here is the only thing the class set does not cover: the glyph * size, which the mockup draws a step larger than the button's own type. * * The row's cancel button cannot take the classes (it is Bookly's markup), so * it is given the same numbers by hand further down - see the note there. */ .am-logout .material-symbols-outlined { font-size: 19px; } .am-cabinet { padding-block-end: clamp( 40px, 6vw, 64px ); } .am-maintenance-invitation { display: grid; gap: var( --space-3 ); margin-block: var( --space-6 ); padding: var( --space-4 ); border: 1px solid var( --border-hairline ); border-radius: var( --radius-lg ); background: var( --surface-card ); } .am-maintenance-invitation h2 { margin: 0; color: var( --text-heading ); font-size: var( --fs-h3 ); font-weight: var( --fw-bold ); } .am-maintenance-invitation p { margin: 0; color: var( --text-body ); } .am-maintenance-invitation [data-private-maintenance-create] { min-height: 44px; justify-self: start; } .am-maintenance-invitation__result { display: grid; gap: var( --space-2 ); } .am-maintenance-invitation__result[hidden] { display: none; } .am-maintenance-invitation__result label { color: var( --text-heading ); font-weight: var( --fw-bold ); } .am-maintenance-invitation__link { width: 100%; min-height: 44px; padding: var( --space-2 ) var( --space-3 ); border: 1px solid var( --border-control ); border-radius: var( --radius-sm ); background: var( --surface-card ); color: var( --text-body ); font: inherit; } .am-maintenance-invitation__link:focus-visible, .am-maintenance-invitation [data-private-maintenance-create]:focus-visible { outline: 3px solid var( --color-accent ); outline-offset: 3px; } .am-maintenance-invitation__status { min-height: 1.5em; } /* --------------------------------------------------------------------------- * The embedded shortcode - type, accent colour, corner radii only. */ /* * THE FONT HAD TO BE HANDED OVER THROUGH BOOKLY'S OWN VARIABLE, not declared at * it (WPS-110). Andrius reported three times that the cabinet was not in the * site's typeface, and the `font-family` line below - written in WPS-033 - had * been losing silently the whole time. * * The reason is one selector. The cabinet's wrapper is * `
`, and the * scoped Bootstrap the cabinet loads (bookly-bootstrap.min.css, pulled in by the * `bookly-backend-globals` alias in lib/base/Component.php:253) declares * `#bookly-tbs { font-family: var( --bookly-font-sans, -apple-system, ... ) }`. * An id beats a class outright, so the system stack won on the very element this * rule targets, and every label, input and dialog inside inherited it. * * `--bookly-font-sans` is defined nowhere in the plugin - it exists only as the * first argument of that var(), which is Bookly leaving a theme somewhere to * stand. So the fix is to stand there rather than to out-shout the id with * `!important`: the value flows into Bookly's own declaration, and everything * inside the cabinet follows without a rule of its own. * * NOT THE PAYMENT DIALOG, THOUGH - this comment claimed it did, and it was * wrong. That dialog is mounted into a container Bookly appends to * `document.body`, so it is not inside the cabinet and inherits nothing from * here. It is handed the same variable separately, further down. * * The plain font-family below stays for everything on this page that is NOT * under the id - and because a rule that says what this theme wants is worth * keeping even where another one currently wins. */ .bookly-customer-cabinet { --bookly-font-sans: var( --font-sans ); font-family: var( --font-sans ); color: var( --text-body ); } .bookly-customer-cabinet .btn-primary, .bookly-customer-cabinet .btn-success { background-color: var( --color-ink ) !important; border-color: var( --color-ink ) !important; border-radius: var( --radius-pill ) !important; } .bookly-customer-cabinet .btn-primary:hover, .bookly-customer-cabinet .btn-success:hover { background-color: var( --color-accent-strong ) !important; border-color: var( --color-accent-strong ) !important; } .bookly-customer-cabinet a { color: var( --color-accent-text ); } .bookly-customer-cabinet .nav-tabs .nav-link.active { color: var( --color-accent-text ) !important; border-color: var( --color-accent ) !important; } .bookly-customer-cabinet .form-control { font-family: var( --font-sans ); border-radius: var( --radius-sm ); } .bookly-customer-cabinet .form-control:focus { border-color: var( --color-accent ); box-shadow: none; } /* Keep existing shadows and autofill masking; add the shared keyboard ring. */ .bookly-customer-cabinet .form-control:focus-visible { outline: 3px solid var( --focus-ring ) !important; outline-offset: 2px; } /* * Chrome paints its own pale yellow behind a field it filled in, and there is no * property that turns it off - `background` loses to the browser's own * `-internal-light-dark` rule. The inset shadow is the standard way round it: * a solid block of the card's own colour covering the whole field, painted in a * property Chrome does not override. -webkit-text-fill-color goes with it, * because the same autofill style also repaints the text. * * Andrius saw it on the profile tab (WPS-110), where the browser had filled his * email and password: two fields sitting in a colour this site does not own. */ .bookly-customer-cabinet input:-webkit-autofill, .bookly-customer-cabinet input:-webkit-autofill:hover, .bookly-customer-cabinet input:-webkit-autofill:focus { box-shadow: 0 0 0 100px var( --surface-card ) inset; -webkit-text-fill-color: var( --text-body ); caret-color: var( --text-body ); } /* --------------------------------------------------------------------------- * The dialogs - including the one that is not inside the cabinet at all. * * `.bookly-customer-cabinet .modal-content { border-radius }` stood here since * WPS-033 and never painted a pixel, for two independent reasons. * * FIRST, THE PAYMENT DIALOG IS NOT A DESCENDANT OF THE CABINET. * short_code.php:215 calls `BooklyDialogs\Payment\Dialog::render()` inside the * wrapper, but that method prints no markup: Dialog.php only enqueues * `payment-details-dialog.js` and localises its labels. The DOM arrives later * from that Svelte bundle, mounted into * `getBooklyModalContainer( 'bookly-payment-details-dialog' )`, and that helper * (backend/resources/js/common.js:129-143) appends a fresh * `
` to `document.body`. * The dialog is a sibling of the whole page. * * SECOND, AN ID BEATS TWO CLASSES - the same loss the font rule took above. * bookly-bootstrap.min.css ships `#bookly-tbs .modal-content{border-radius:.3rem}` * at (1,1,0), and `.bookly-customer-cabinet .modal-content` is (0,2,0). So the * rule was dead for the CANCEL dialog too, and that is the one a customer * actually uses. * * Everything below is rooted in `#bookly-tbs`, which BOTH containers carry - * Bookly gives the detached modals container the same id as the cabinet wrapper * - and adds `.modal-dialog` so each declaration clears Bootstrap's own rule on * specificity rather than on load order. All four dialogs share this markup, so * reschedule, cancel, delete and payment follow together. * * If Bookly ever stops duplicating that id, these rules stop matching and the * dialogs return to Bootstrap's defaults - the state they are in today. A * cosmetic regression, not a broken page. */ #bookly-tbs.bookly-modals-container { --bookly-font-sans: var( --font-sans ); color: var( --text-body ); } #bookly-tbs .modal-dialog .modal-content { background-color: var( --surface-card ); border: 1px solid var( --border-hairline ); border-radius: var( --radius-lg ); box-shadow: var( --shadow-floating ); } #bookly-tbs .modal-dialog .modal-header { align-items: center; padding: var( --space-4 ) var( --space-6 ); border-bottom: 1px solid var( --border-hairline ); } #bookly-tbs .modal-dialog .modal-title, #bookly-tbs .modal-dialog .modal-header h5 { color: var( --text-heading ); font-size: var( --fs-h3 ); font-weight: var( --fw-bold ); } #bookly-tbs .modal-dialog .modal-header .close { padding: var( --space-1 ) var( --space-2 ); background: none; border: 0; color: var( --text-meta ); font-size: 24px; font-weight: var( --fw-regular ); text-shadow: none; opacity: 1; } #bookly-tbs .modal-dialog .modal-header .close:hover { color: var( --text-heading ); } #bookly-tbs .modal-dialog .modal-body { padding: var( --space-6 ); font-size: var( --fs-sm ); } #bookly-tbs .modal-dialog .modal-footer { padding: var( --space-4 ) var( --space-6 ); border-top: 1px solid var( --border-hairline ); } /* * The two tables inside the payment dialog. `.table-bordered` draws a hairline * box around every single cell, which is Bootstrap's densest treatment and the * one furthest from this site: the panel keeps one outline, the rows keep the * lines that separate them, and the cells stop being boxes. * * THAT DIALOG IS CURRENTLY UNREACHABLE, AND THESE RULES ARE KEPT ANYWAY - said * out loud because this file treats a rule that matches nothing as a defect. * inc/customer-cabinet.php clears `payment_id` so the price column prints the * price instead of the button that opened this, and with no button the Svelte * bundle never mounts: measured on dev, `.bookly-modals-container` and * `.modal-body .table-bordered` both count 0. Nothing in Bookly changed, only * the answer it gets - one line in that file brings the dialog and these rules * back together, which is why deleting them would throw away measured work * rather than clean anything up. The rules above this comment are different: * they dress the cancel dialog, which a customer opens every time. */ #bookly-tbs .modal-body .table-responsive { margin-bottom: var( --space-4 ); border: 1px solid var( --border-hairline ); border-radius: var( --radius-md ); overflow: hidden; } #bookly-tbs .modal-body .table-responsive:last-child { margin-bottom: 0; } #bookly-tbs .modal-body .table.table-bordered { margin-bottom: 0; border: 0; color: var( --text-body ); } #bookly-tbs .modal-body .table.table-bordered th, #bookly-tbs .modal-body .table.table-bordered td { padding: var( --space-3 ) var( --space-4 ); border-inline: 0; border-top: 1px solid var( --border-hairline ); border-bottom: 0; } #bookly-tbs .modal-body .table.table-bordered thead th { border-top: 0; color: var( --text-heading ); font-weight: var( --fw-bold ); } #bookly-tbs .modal-body .table.table-bordered tbody tr:first-child > * { border-top: 1px solid var( --border-hairline ); } /* --------------------------------------------------------------------------- * THE DIALOG'S BUTTON PAIR IS THE SITE'S BUTTON PAIR, AND THAT IS THE WHOLE * ANSWER TO THE QUESTION ANDRIUS ASKED. * * He asked it on 2026-09-07 looking at this dialog: "do we not have all of this * written down in our design system - how a button should look and behave?" We * do, and it is exactly two buttons wide. The system's Button component * (`components/actions/Button.jsx`, mirrored byte for byte in base.css:215-278) * declares `variant: 'primary' | 'secondary'` and nothing else: black filling * that turns accent blue on hover, or white with a hairline border whose border * and text turn blue. There is no third variant, no destructive variant, and no * `:active` state anywhere in it. * * WHAT WAS HERE INSTEAD WAS A THIRD VARIANT NOBODY DESIGNED. "Yes" was filled * with --color-danger-text and hovered to --color-danger, and both halves of * that were wrong in the same direction. The canon (sypsena-design/SKILL.md:73) * spends red on "do / don't" examples and error text, never on a control - this * file's red button was the only one in the theme. And the hover could not be * seen: those two tokens are adjacent reds, a contrast of 1.14:1 between the two * states, and the hover is the LIGHTER of them. Andrius reported "no visual * response at all" and the rule was running the whole time. A hover measured in * the palette rather than in the eye is how a button ends up moving on paper and * standing still on screen. * * So the affirmative control becomes the primary button and the dismissal stays * the secondary one - the same pair as the header, the cookie bar and the * booking wizard's own footer. The confirmation this dialog exists to collect is * carried by its title and its sentence, which is where this site puts meaning. * * `.btn-danger` and `.btn-default` are the Bootstrap classes Bookly's * Buttons::render() prints (cancel.php:25-26); they are class hooks here, not * descriptions - the danger one no longer paints anything dangerous. * * `!important` throughout, and measured rather than assumed: Bookly's scoped * Bootstrap declares these at `#bookly-tbs .btn-danger`, the same (1,2,0) this * selector reaches with `.modal-dialog`, so a plain declaration only wins on * source order - which is not a thing to depend on across a plugin update. */ #bookly-tbs .modal-dialog .btn-danger, #bookly-tbs .modal-dialog .btn-default { display: inline-flex; align-items: center; justify-content: center; gap: var( --space-2 ); min-height: 44px; padding-inline: var( --space-6 ); border-radius: var( --radius-pill ) !important; font-family: var( --font-sans ); font-size: var( --fs-sm ); font-weight: var( --fw-bold ); line-height: var( --lh-body ); /* !important because Bookly's own `.btn` carries `transition: all .3s` and * measured 0.3s here without it - the canon's motion is 0.2s, and a * declaration that loses is worse than no declaration at all. */ transition: background var( --dur ) var( --ease ), border-color var( --dur ) var( --ease ), color var( --dur ) var( --ease ) !important; } #bookly-tbs .modal-dialog .btn-danger { background: var( --action-primary ) !important; border: 1px solid var( --action-primary ) !important; color: var( --color-surface ) !important; } #bookly-tbs .modal-dialog .btn-danger:hover { background: var( --action-primary-hover ) !important; border-color: var( --action-primary-hover ) !important; } #bookly-tbs .modal-dialog .btn-default { background: var( --surface-card ) !important; border: 1px solid var( --border-control ) !important; color: var( --text-heading ) !important; } #bookly-tbs .modal-dialog .btn-default:hover { border-color: var( --color-accent ) !important; color: var( --text-link ) !important; } /* * AND THE FOCUS RING, WHICH THIS PAGE WAS NOT GETTING - FOUND BY PRESSING TAB * RATHER THAN BY READING THE FILE. * * `base.css:331-342` gives every button on the site a 3px --focus-ring at * `button:focus-visible`, and nothing in this cabinet was reaching it. Two * different plugin layers, each losing to the theme in a different way: * * - the dialog pair: Bootstrap writes `#bookly-tbs .btn:focus { outline: 0 }` * (1,2,0) against the theme's (0,1,1), and replaces the ring with its own * glow - measured on the dismissing button, `rgba(180,186,191,.5) 0 0 0 * 3.2px`, a grey this palette does not contain; * - the row's cancel button: Tailwind's `bookly:outline-none` writes * `outline-style: none !important`, which no specificity can answer. * * So both are written out here, with the shorthand carrying `!important` * (outline-style is the half Tailwind shouts at) and the glow cleared. Invariant * I15.2 counts a missing focus indicator as a P1, and this is the one screen * where the keyboard path ends in a confirmation that cannot be taken back. */ #bookly-tbs .modal-dialog .btn-danger:focus-visible, #bookly-tbs .modal-dialog .btn-default:focus-visible, /* The invoice link (WPS-114) stands in the same cell, under the same Tailwind * `bookly:outline-none`, so it joins the selector rather than repeating it. */ #bookly-tbs.bookly-customer-cabinet td[ class*="right-0" ] .am-invoice-row:focus-visible, #bookly-tbs.bookly-customer-cabinet td[ class*="right-0" ] button[ data-slot="button" ]:focus-visible { outline: 3px solid var( --focus-ring ) !important; outline-offset: 2px; /* !important on the shadow too, and measured: without it the cancel button * kept Tailwind's own 2px focus ring underneath ours - a reddish * oklab(.64 .19 .09 / .2) on a button that is no longer red anywhere. */ box-shadow: none !important; } /* * THE PROFILE ROW THAT SAYS NOTHING (WPS-110). Bookly labels this field "WP * user" and then prints `display_name` (short_code.php:173-175) - so it repeats * the first and last name from the two fields directly above it, under a label * that promises an account identifier. WPS-109 translated the label as * "Prisijungimo vardas", which made it worse: nobody signs in with that value, * and it is not even the login. Andrius caught both, in that order. * * Relabelling it a third time would still leave a row whose content is a * duplicate, so the row goes. The translation stays in the catalogue, because * this hides the row rather than removing it - if Bookly ever changes the id * this rule hangs off, the row comes back saying something true. * * :has() is the selector this needs - the label is the only thing that * identifies the block, and the block is its parent. Supported everywhere this * site is measured; a browser without it simply shows the row. */ .bookly-customer-cabinet .form-group:has( > label[ for="bookly-wp-user" ] ) { display: none; } /* --------------------------------------------------------------------------- * The appointments table on a phone: Bookly's own responsive mode, not a width * the theme invents. * * WHAT THIS REPLACES, AND WHY THE OLD ANSWER WAS BUILT ON A PREMISE THAT NO * LONGER HOLDS. WPS-035 measured that at 390 px only the date column reached * the DOM and concluded the columns "are never rendered, so nothing can un-hide * them"; the fix was a 680 px min-width plus sideways scroll, first on the whole * cabinet and then (earlier in WPS-110) on the table's wrapper. Bookly 28.1 does * render them: it hides the columns that do not fit and re-emits them in an * expandable detail row, which is the `>` control in every row. * * The forced width is what broke that. Bookly fits columns into the * `clientWidth` of its own scroll wrapper (`div.bookly:overflow-x-auto`, * watched by a ResizeObserver), so a min-width above it tells the plugin a * 390 px phone is 680 px wide. It then emits about 600 px of columns, and the * surplus leaves the screen - with every cell carrying `bookly:text-nowrap` and * `bookly:overflow-hidden`, so the text is cut mid-word rather than wrapped. * Andrius photographed exactly that on 2026-09-07. * * Three more things came back with the lie removed, all of them Bookly's own: * the sticky first column (it resolves against that same wrapper), the edge * shadow and styled scrollbar (both gated on the responsive mode), and the * Cancel strip, which is `bookly:sticky bookly:right-0` and had been parking at * x=680 - off the right edge of the phone, which is why WPS-035's `hover: none` * override below revealed a control nobody could reach. * * The trade is real and worth stating: at 390 px the visitor may see the date * and one more column, and taps `>` for the rest. That is the ordinary * responsive-table bargain, and it is the plugin's own design rather than a * layout this theme maintains against it. * * What is left here is styling for the detail row Bookly opens, so it reads * like this site rather than like a debug dump. */ .am-cabinet .bookly-customer-cabinet tr[ data-dt-overflow-for ] > td { padding-inline: var( --space-4 ); background: var( --surface-soft ); white-space: normal; } .am-cabinet .bookly-customer-cabinet tr[ data-dt-overflow-for ] dl > div, .am-cabinet .bookly-customer-cabinet tr[ data-dt-overflow-for ] dd > div { display: grid; grid-template-columns: minmax( 0, 7.5rem ) minmax( 0, 1fr ); column-gap: var( --space-3 ); row-gap: var( --space-1 ); } .am-cabinet .bookly-customer-cabinet tr[ data-dt-overflow-for ] dt { color: var( --text-meta ); font-size: var( --fs-caption ); } .am-cabinet .bookly-customer-cabinet tr[ data-dt-overflow-for ] dd[ data-dt-col ] { overflow-wrap: anywhere; } /* * MOBILE FIRST, AS THIS REPO WRITES EVERY QUERY (AGENTS.md / config/review-rules.md * rule 7). The first version of this block was the other way round - a wide * default narrowed inside `max-width: 920px` - which reads as desktop-first even * though it renders the same, and dovanu-kuponai.css already carries a comment * explaining why that shape is refused. The phone is the default here; the * desktop lifts it. */ .am-cabinet .bookly-customer-cabinet th.bookly-dt-col, .am-cabinet .bookly-customer-cabinet tbody [ data-slot="table-cell" ] { padding-inline: var( --space-2 ); } /* * A PHONE GETS THE SHORT VERSION OF EVERY LABEL (Andrius, 2026-09-07). * * Three things shrink together, and they are one decision rather than three: * the table's type drops a step, the cancel button falls back to the icon it * already carries, and the status stops being a word. What is left is what a * visitor actually needs at a glance - when, what, how much - with the state * carried by colour and the action by its glyph. * * The status text is not removed, only made invisible: it stays in the DOM for * a screen reader, which is the whole reason this is `font-size: 0` on the * badge rather than `display: none` on its contents. Colour alone would fail * sighted users too. The responsive legend below supplies the missing names; * a date and a treatment name do not explain an appointment status. */ /* * The id again: Bookly declares the cabinet's type at `#bookly-tbs`, so a * class-only rule here measured 16px after deploy instead of the 14 it asked * for. Third time this file has met that, and the reason it is written out * every time is that the rule LOOKS correct in review. */ #bookly-tbs.bookly-customer-cabinet { font-size: var( --fs-caption ); } .am-cabinet .bookly-customer-cabinet .am-cancel__label, .am-cabinet .bookly-customer-cabinet .am-invoice-row__label { display: none; } /* * A button that has lost its words still has to be a target. Measured without * this: 42x44, which is under the floor invariant I8.2 sets in both directions. */ .am-cabinet .bookly-customer-cabinet td[ class*="right-0" ] .am-invoice-row, .am-cabinet .bookly-customer-cabinet td[ class*="right-0" ] button[ data-slot="button" ] { min-width: 44px; } /* * The badge is a pill at every width. It already became one on a phone, where * it shrinks to a dot, and Bookly's own `rounded-md` left it square-ish * everywhere else - so the same object changed shape as the screen narrowed, * which is what Andrius saw. This site rounds badges (components.css); the dot * below is that same pill with the word taken out of it. */ .am-cabinet .bookly-customer-cabinet tbody [ class*="rounded-md" ] { width: 14px; min-width: 14px; height: 14px; padding: 0 !important; border-radius: var( --radius-pill ) !important; font-size: 0; } /* * `break-word`, NOT `anywhere`. The first version used `anywhere`, which lets * the browser break inside a word rather than only between words: measured at * 606px it turned the date into "2026 / -09- / 09" and the status badge into * three stacked fragments. `break-word` breaks a long word only when it cannot * fit at all, which is what a treatment name needs and what a date must never * get. * * WHAT IS NOT HERE, AND WHY. A rule pinning the date and the status badge to one * line was written and then removed: counted in the live cabinet, `[data-dt-col]` * matches nothing at this level - it exists only inside an expanded detail row - * and the badge already carries Bookly's own `white-space: nowrap`. Two selectors * that match nothing are two rules a later reader would trust. */ .am-cabinet .bookly-customer-cabinet [ data-dt-primary ], .am-cabinet .bookly-customer-cabinet [ data-dt-secondary ], .am-cabinet .bookly-customer-cabinet [ data-dt-child ] { overflow-wrap: break-word; white-space: normal; } /* * The action lane, at the width a phone can afford. Below 921px this is also the * rule that stops the strip painting over the status badge - it is * `position: absolute; right: 0`, and a one-pixel cell gives it nothing to sit * in. * * 78px, MEASURED, WHERE IT USED TO BE 110. Below 921px the button has no words - * it is the glyph and its padding, and it measures 62px. The old 110 was sized * for a lane that also had to hold the fade's overhang; with that gone (see the * mask rule above) the surplus is just width taken from the columns. Measured at * a 466px viewport: with 110 the table overflowed its own scrollport by 26px, * with 78 it fits exactly - so this is also the line that takes the sideways * scroll off a phone at that width. */ .bookly-customer-cabinet .bookly\:sticky.bookly\:right-0.bookly\:p-0 { width: 78px !important; min-width: 78px; } @media ( min-width: 921px ) { /* * WHAT `revert` ACTUALLY DOES, AND WHY FIVE DECLARATIONS BELOW STOPPED USING * IT. The block that used to stand here read `padding: revert`, `font-size: * revert` and so on, with a comment saying the desktop hands the value "back * to what Bookly asked for". It does not: `revert` rolls a property back to * the USER-AGENT origin, discarding every author declaration - Bookly's * included. On the status badge that is the whole defect Andrius * photographed. Bookly writes `bookly:px-2.5 bookly:py-0.5`, this file * answered `padding: revert !important`, and because the `!important` wins * and `revert` drops to the user agent, the badge computed to `padding: 0` * with its word pressed against both ends of the pill. Measured on dev * 2026-09-07: 70x30 with 0px of padding and a 16px face inside a 14px table. * * The two below are left alone deliberately. Neither carries `!important`, * so Bookly's own `!important` utilities outrank them and they change * nothing either way - measured, the desktop cell still computes Bookly's * 8px 16px. They stay because the phone rules above them need an off switch * the day Bookly stops shouting. */ .am-cabinet .bookly-customer-cabinet th.bookly-dt-col, .am-cabinet .bookly-customer-cabinet tbody [ data-slot="table-cell" ] { padding-inline: revert; } .am-cabinet .bookly-customer-cabinet [ data-dt-primary ], .am-cabinet .bookly-customer-cabinet [ data-dt-secondary ], .am-cabinet .bookly-customer-cabinet [ data-dt-child ] { overflow-wrap: revert; white-space: revert; } /* The desktop has room for words, so it gets them back - at the body size the * `revert` above it happened to land on, now said out loud. */ #bookly-tbs.bookly-customer-cabinet { font-size: var( --fs-body ); } .am-cabinet .bookly-customer-cabinet .am-cancel__label, .am-cabinet .bookly-customer-cabinet .am-invoice-row__label { display: inline; } /* * THE BADGE IS THIS SITE'S PILL, WRITTEN OUT. `.ap-pill` (apie.css:101-108) * is the shape every other badge on the site takes, and its padding, size * and weight are copied here unchanged. The one addition is `line-height`, * which `.ap-pill` inherits and this one cannot: Bookly gives the badge a * 28px line box, and 28px plus the pill's own 7px would stand 42px tall * inside a 44px row. At --lh-heading the badge measures the 30px it does * today, with 14px of room around the word instead of none. * * The colours stay Bookly's. Its badge carries the status in three Tailwind * classes (`bg-green-100 text-green-800 border-green-200` for an approved * visit, and its own pair for every other state), so repainting one state * from this theme's tokens would leave the rest mismatched - and this theme * has no amber or red badge anywhere to copy the other two from. Geometry is * what Andrius reported; geometry is what changes. */ .am-cabinet .bookly-customer-cabinet tbody [ class*="rounded-md" ] { width: auto; min-width: 0; height: auto; padding: 7px 14px !important; font-size: var( --fs-eyebrow ); /* `bookly:font-medium` is one of the utilities Bookly writes with * !important - measured 500 here before this line, against the 700 every * other badge on the site carries. */ font-weight: var( --fw-bold ) !important; line-height: var( --lh-heading ); } /* * And the lane widens, because a desktop row has the width to spare for the * named button rather than its glyph alone. */ .bookly-customer-cabinet .bookly\:sticky.bookly\:right-0.bookly\:p-0 { width: 150px !important; min-width: 150px; } } /* --------------------------------------------------------------------------- * The row actions, on a device that cannot hover. * * Bookly 28.1 hides each appointment row's action bar - Cancel among them - * behind `group-hover`, so it exists in the DOM and appears when a mouse is * over the row. Measured on dev (WPS-035): at 1440 px hovering the row * revealed "Cancel"; at 390 px with touch, nothing revealed it, before or * after a tap. That makes cancelling a visit impossible on a phone, on a * site whose first rule is mobile-first and whose confirmation email invites * the customer to cancel. * * Only the reveal is overridden, and only where hover does not exist: the * pointer query is the honest expression of the actual condition, and it * leaves the desktop behaviour Bookly designed exactly as it is. * * !important is not a shortcut here - it is the only thing that wins. * Bookly ships `.bookly-css-root .bookly\:hidden { display: none !important }`, * measured through CSS.getMatchedStylesForNode rather than guessed at, and a * plain declaration loses to it however specific it is. */ @media ( hover: none ) { .bookly-customer-cabinet tbody .bookly\:group-hover\:flex { display: flex !important; } } /* --------------------------------------------------------------------------- * A LANE FOR THE ROW ACTIONS, SO THE STRIP STOPS EATING THE STATUS BADGE. * * Bookly renders Cancel as a row action rather than a column - its own source * says why (customer-cabinet.js: it "avoids the responsive column-priority * problem"). The strip lives in an extra cell Bookly makes one pixel wide on * purpose (`style="width:1px"`, `bookly:sticky bookly:right-0`), so it * overhangs the row, and a gradient fades out whatever is underneath it. * * That is right for a column of trailing text and wrong for a badge. The wash * starts 64 px (`bookly:-left-16`) plus 16 px of padding plus a 36 px button = * 116 px left of the row's right edge, and it is fully opaque for its first * 60 %. Measured against this markup at the theme's own desktop pane width * (1100 px container less two 32 px gutters = 1036 px): the status column * resolved to 206 px and the wash covered the last 15 px of the badge. Nothing * was ever clipped - `scrollWidth` matched the rendered width at every width * tried - it was painted over. * * So the cell stops being one pixel and becomes a lane wide enough to hold the * whole strip. Bookly keeps its positioning and its hover reveal; only the * reserved width changes, and `!important` is what reaches an inline width * attribute. * * Desktop only: below 921 px the sticky cell pins to the scrollport rather than * to the row, and a reserved lane would be width nobody sees. */ /* --------------------------------------------------------------------------- * AND THE FADE ITSELF GOES FLAT (Andrius, 2026-09-07: "there is some effect * like a shadow travelling right to left - can it be removed?"). * * It is Bookly's, not this theme's: a `` inside the action cell carrying * `bookly:bg-gradient-to-l`, measured 189x92 with * `linear-gradient(to left, oklch(0.985 0.002 247.839) 60%, transparent)`. It * exists to mask whatever slides under the sticky strip while the table is * scrolled sideways, and that job is real on a narrow screen - dropping the * paint outright would let a treatment name run under the button. * * So the wash becomes a flat fill instead of disappearing. The canon has no * gradients at all - backgrounds are flat single colours * (sypsena-design/SKILL.md:90). * * AND THE REASON IT WAS EVER VISIBLE IS THIS FILE'S OWN DOING, which is worth * writing down because the colour looks like a Bookly mistake and is not. The * strip is a hover affordance in the plugin: it appears when the pointer is over * the row, and the row tints to `gray-50` at the same moment, so Bookly's fade * is painted in exactly that grey and lands on a grey row. This file forces the * strip visible at every moment (see the rule further down - a cancel control * that only exists under a mouse does not exist on a phone), and that left a * hover-coloured wash sitting on a resting white row all day. Measured: the fade * is oklch(0.985 0.002 247.839) over a card that computes rgb(255,255,255). * * So the row's tint goes with it. It is Tailwind's `gray-50`, a grey this * palette does not contain, and it was carrying no information here anyway - * the action it used to reveal is now always on screen, and it has a hover of * its own. One white, at rest and under the pointer, and the mask disappears * into it in both. * * The tint is written on the CELLS, not on the row: Bookly puts `bookly:group` * on the `` and `bookly:bg-white bookly:group-hover:bg-gray-50` on every * ``. A rule aimed at `tr:hover` matches, computes, and is covered by the * cells painted on top of it - measured exactly that way before this selector * was corrected. */ /* * AND IT STOPS AT ITS OWN LANE. Bookly hangs the fade 64px past the left edge * of the action cell (`bookly:-left-16`) so the gradient has somewhere to fade * ACROSS. A flat fill has nothing to fade, so that overhang stopped being a * transition and became an eraser: measured at a 956px viewport, it painted * over the last 16px of an 82px "approved" badge - the word ended mid-letter, * which is what Andrius photographed on 2026-09-07. At 840px it covered 45% * of it, and at 800px, 94%. * * This is the one place where the flat fill above is worse than the gradient it * replaced, and the answer is not to bring the gradient back but to give the * mask the width it actually needs. The lane is reserved (110px on a phone, * 150px from 921px up - see the rules further down), so nothing else is laid * out inside it and covering exactly it is enough. Measured after: 0px of the * badge covered at every width tried. */ .bookly-customer-cabinet td[ class*="right-0" ] span[ class*="bg-gradient-to-l" ] { left: 0 !important; background: var( --surface-card ) !important; } /* Keep the resting row opaque too: Bookly animates its background after * mouseleave, underneath the transparent action cell. */ #bookly-tbs.bookly-customer-cabinet tbody tr, #bookly-tbs.bookly-customer-cabinet tbody tr:hover, #bookly-tbs.bookly-customer-cabinet tbody tr > [ data-slot="table-cell" ], #bookly-tbs.bookly-customer-cabinet tbody tr:hover > [ data-slot="table-cell" ] { background: var( --surface-card ) !important; } /* The legend uses Bookly's own status colours and translated labels. */ #bookly-tbs .am-status-legend { /* Match the date cell inset, including the table outline. */ padding-inline: calc( var( --space-4 ) + 1px ); margin-top: var( --space-3 ); color: var( --text-body ); font-size: var( --fs-caption ); } #bookly-tbs .am-status-legend__items { display: flex; flex-wrap: wrap; gap: var( --space-2 ) var( --space-4 ); margin: var( --space-2 ) 0 0; padding: 0; list-style: none; } #bookly-tbs .am-status-legend__items li { display: inline-flex; align-items: center; gap: var( --space-2 ); } #bookly-tbs .am-status-legend__dot { flex: 0 0 14px; width: 14px; height: 14px; padding: 0 !important; border-radius: var( --radius-pill ) !important; } @media ( min-width: 921px ) { #bookly-tbs .am-status-legend { display: none; } } /* --------------------------------------------------------------------------- * AND NO COLUMN SORTING EITHER, FOR THE SAME REASON AS THE CHECKBOX BELOW. * * Every heading carries a Lucide arrow and a click handler. Andrius reported the * arrow twice in one round - once because the sorted column's arrow does not * match the unsorted ones, and once because at phone width it is simply a mark * nobody can read. Both readings are right, and so is the third thing measured * while looking into it: the arrow is what pushes two headings past their * column. At a 466px viewport the price and status headings were both clipped * with the arrow and both fit without it - 14px of glyph plus its gap is the * whole difference. * * SORTING IS THE PART THAT GOES, not just its arrow, because a control that * still works while looking like a label is worse than either. The trade is * small and one-sided: this table holds one person's visits, already in date * order, of one treatment, with one specialist. Sorting them by price is an * administrator's tool on a customer's screen - the same judgement that took * the checkbox column and the staff column out. * * Nothing accessible is lost. The heading is not a button and carries no * tabindex - Bookly delegates a click to the cell - so this was a mouse-only * affordance before it was removed, and the two icons a keyboard can still * reach (expand row, expand all) are in a heading of their own that this * selector does not touch: it is scoped to `.bookly-dt-col`, which only the * sortable data columns carry. */ /* * `pointer-events` alone, with no `cursor` beside it: measured after this rule * landed, `elementFromPoint` at the middle of a heading returns the TABLE, not * the heading, so the pointer never asks this element what shape to be. A * `cursor: default` here would be a declaration that reads like it is doing * something and is not. */ .am-cabinet .bookly-customer-cabinet thead th.bookly-dt-col { pointer-events: none; } .am-cabinet .bookly-customer-cabinet thead th.bookly-dt-col svg { display: none !important; } /* --------------------------------------------------------------------------- * NO BULK SELECTION IN A PERSONAL VISIT LIST. * * Bookly's table ships a checkbox column and, once a row is ticked, a floating * toolbar that lands on top of the row it belongs to - Andrius photographed it * covering the treatment name. Both are built for an administrator working * through hundreds of appointments; a customer has one visit and one action, * and that action already exists per row. * * Hiding the column removes the toolbar with it, because the toolbar only * appears once something is selected. The expander (`>`) is a different cell * and stays - it is what opens the detail row on a phone. */ .bookly-customer-cabinet .bookly\:sticky.bookly\:left-0.bookly\:w-\[1\%\] { display: none; } /* --------------------------------------------------------------------------- * THE PROFILE FORM, AS ONE FORM. * * Two things put the save button alone in an empty corner, and neither is the * hidden "WP user" row above being wrong. * * First, the row over it is three quarters of a row. short_code.php puts four * `.form-group.col-sm-3` blocks in one `.row`, and the first is the duplicate * this file hides. `.col-sm-3` is `flex: 0 0 25%` inside `@media (min-width: * 576px)`, and `display: none` takes a flex item out of the layout rather than * leaving a cell - so from 576 px up the three password fields pack left and * the last quarter is dead. Below 576 px the column widths never apply, every * field is full width, and nothing is missing. That asymmetry is exactly why * the phone looked right and the desktop did not. * * Second, and larger: nothing in this form has a measure. Email and phone are * bare `.form-group`s, so each input stretches across the whole 1100 px * container, and Bookly floats the button right - parking it at the far end of * a line whose content stops 260 px short of it. * * So the fix is a measure, not a wider password field. `display: flex` on the * button's wrapper neutralises the float without `!important` (float has no * effect on a flex item) and gives that wrapper a height, which a div holding * only a float does not have. * * THE `#bookly-tbs` PREFIX IS LOAD-BEARING. The scoped Bootstrap declares this * grid at `#bookly-tbs .row` and `#bookly-tbs .col-sm-3`, and a class-only * selector loses to an id - the same trap that ate the font. Everything is * scoped to the profile pane because the four dialogs render outside the tab * panes and use this same grid. */ /* * CENTRED, NOT LEFT-ALIGNED. The measure alone fixed the button and left a new * problem in its place: a 560px column hugging the left edge under a tab bar * that spans the full 1100px container, with the right half of the screen * empty. Andrius read the first version as "padaryta blogai" and the reading is * right - the emptiness looks like something failed to load rather than like a * decision. Centred, the same measure reads as a form with room around it. */ /* * NO MEASURE OF ITS OWN, SO IT LINES UP WITH THE PAGE. WPS-110 first gave this * form 560px and centred it, which read as a column floating in an empty half * of the screen; then 900px, which still ended 180px short of the "Atsijungti" * button directly above it. Andrius asked for the two edges to agree, and he is * right that they should: the form, the tab bar and the hero button all belong * to the same page container, and a form that stops short of it looks like a * mistake rather than a margin. The two columns below give the width its shape. */ #bookly-tbs.bookly-customer-cabinet .bookly-js-customer-cabinet-content-profile form { max-width: none; } /* --------------------------------------------------------------------------- * THE PROFILE FORM USES THE ROOM IT HAS (WPS-110, Andrius asked for a better * use of the space). * * A centred 560px column was honest but half the screen was empty, and the * emptiness carried no meaning. The form actually holds two different errands: * the contact details a customer keeps up to date, and a password change they * make once a year. Side by side, each becomes a group a reader can take in at * a glance, and the width stops being a void. * * The placement is explicit rather than left to auto-flow because the source * order is contact, contact, contact, passwords, submit - a grid left to place * that itself would interleave the two errands. * * Below the desktop breakpoint everything returns to one column: two columns of * inputs on a phone is how forms become unreadable, and the source order is * already the right reading order. */ @media ( min-width: 921px ) { #bookly-tbs.bookly-customer-cabinet .bookly-js-customer-cabinet-content-profile form { display: grid; grid-template-columns: minmax( 0, 1fr ) minmax( 0, 1fr ); column-gap: clamp( 24px, 4vw, 56px ); align-content: start; } #bookly-tbs.bookly-customer-cabinet .bookly-js-customer-cabinet-content-profile form > * { grid-column: 1; } #bookly-tbs.bookly-customer-cabinet .bookly-js-customer-cabinet-content-profile form > .row:has( label[ for="bookly_current_password" ] ) { grid-column: 2; grid-row: 1 / span 3; align-content: start; } #bookly-tbs.bookly-customer-cabinet .bookly-js-customer-cabinet-content-profile form > .row:has( label[ for="bookly_current_password" ] ) > .form-group { flex: 0 0 100%; max-width: 100%; } #bookly-tbs.bookly-customer-cabinet .bookly-js-customer-cabinet-content-profile form > div:has( > .bookly-js-save-profile ) { grid-column: 1 / -1; } } /* --------------------------------------------------------------------------- * The reveal button inside a password field. * * main.js adds it; this puts it inside the field's right edge rather than * beside it, so the field keeps its full width and the row keeps its height. * 44px of target in a 44px field: the button is the field's own end, which is * where a thumb goes for it. */ .am-reveal-field { position: relative; } .am-reveal-field .form-control { padding-inline-end: 46px; } /* * Anchored to the BOTTOM of the group, not stretched across it. The positioning * parent is Bookly's `.form-group`, which holds the label as well as the input, * so `inset-block: 0` made a 76px button beside a 44px field - measured before * this line existed. The input is the group's last child, so pinning the button * to the bottom and giving it the field's own height puts it exactly inside the * field's right edge. */ .am-reveal { position: absolute; inset-block-end: 0; inset-inline-end: 0; height: 44px; display: inline-flex; align-items: center; justify-content: center; width: 44px; padding: 0; background: none; border: 0; color: var( --text-meta ); cursor: pointer; } .am-reveal:hover { color: var( --text-heading ); } .am-reveal:focus-visible { outline: 3px solid var( --focus-ring ); outline-offset: -3px; border-radius: var( --radius-sm ); } .am-reveal .material-symbols-outlined { font-size: 20px; } #bookly-tbs.bookly-customer-cabinet .bookly-js-customer-cabinet-content-profile .row { margin-inline: 0; column-gap: var( --space-4 ); } #bookly-tbs.bookly-customer-cabinet .bookly-js-customer-cabinet-content-profile .row > .form-group { flex: 0 0 100%; max-width: 100%; padding-inline: 0; } #bookly-tbs.bookly-customer-cabinet .bookly-js-customer-cabinet-content-profile .row > .form-group:has( > label[ for="bookly_first_name" ] ), #bookly-tbs.bookly-customer-cabinet .bookly-js-customer-cabinet-content-profile .row > .form-group:has( > label[ for="bookly_last_name" ] ) { flex: 1 1 190px; max-width: none; } #bookly-tbs.bookly-customer-cabinet .bookly-js-customer-cabinet-content-profile form > div:has( > .bookly-js-save-profile ) { display: flex; flex-wrap: wrap; justify-content: flex-end; gap: var( --space-3 ); margin-block-start: var( --space-2 ); } #bookly-tbs.bookly-customer-cabinet .bookly-js-customer-cabinet-content-profile .form-control { height: auto; min-height: 44px; } #bookly-tbs.bookly-customer-cabinet .bookly-js-save-profile { min-height: 44px; padding-inline: var( --space-6 ); } /* --------------------------------------------------------------------------- * An account with no visits behind it (WPS-110). * * page-mano.php prints this instead of the English sentence Bookly shows a * WordPress user who has never booked - the one that tells a correctly * signed-in visitor to check their credentials. Somebody who bought a gift * voucher reaches it in two clicks, so it is a real screen, not an edge case. */ .am-empty { padding: clamp( 24px, 4vw, 40px ); background: var( --surface-card ); border: 1px solid var( --border-hairline ); border-radius: var( --radius-lg ); text-align: center; } .am-empty__lead { margin: 0 0 var( --space-2 ); color: var( --text-heading ); font-size: var( --fs-h3 ); font-weight: var( --fw-bold ); } .am-empty__text { max-width: 46ch; margin: 0 auto var( --space-6 ); color: var( --text-body ); } /* --------------------------------------------------------------------------- * THE CANCEL ACTION, AS A BUTTON A PERSON CAN SEE. * * Bookly gives the row one action - an icon with a `title`, inside a strip that * is `display: none` until the row is hovered. Measured in the live cabinet: * the button renders 0x0 until hover, and on a touch screen there is no hover * at all. WPS-035 already fought half of this with a `hover: none` override, * which revealed a control that was then parked off-screen by the forced width * this task removed. * * But the deeper problem is not visibility, it is naming. Cancelling is the * errand most people arrive with (Andrius, 2026-09-07) and the one the * confirmation email invites, and it was an unlabelled red circle. main.js's * setUpCabinetCancel() puts the word inside Bookly's own button - the click, * the confirmation dialog and the AJAX stay the plugin's - and these rules stop * hiding the strip and give the button a shape. * * The lane reserved above holds a word rather than an icon. */ .bookly-customer-cabinet .bookly\:group-hover\:flex { display: flex !important; } .bookly-customer-cabinet .am-cancel__label, .bookly-customer-cabinet .am-invoice-row__label { white-space: nowrap; } /* * `width` is the one declaration here that needs !important, and it was * measured rather than assumed: with a plain `width: auto` the button kept * computing to 36px while the padding and min-height from this same rule * applied. Bookly's Tailwind build emits `bookly:size-9` as `!important` (the * same thing its `bookly:hidden` does), so the label rendered outside the * button's painted box - text with no border around it. * * ITS COLOURS MOVED DOWN TO THE SECONDARY BUTTON RULE, and the reason is worth * keeping. What stood here was `border: 1px solid --color-danger-text; color: * --color-danger-text` - a fourth button variant, white with a red rim, that * the design system does not have. Measured on dev afterwards, it was not even * that: neither declaration carried `!important` and Bookly's Tailwind writes * its colour utilities with one, so what actually painted was a borderless * white button in Tailwind's own red-500 - a hue this palette does * not contain, sitting beside a payment button that was already this site's * secondary. That difference is what Andrius saw. The button is a secondary * button now, spelled the same way as every other one, and what makes it * destructive is the dialog it opens. */ .bookly-customer-cabinet td[ class*="right-0" ] button[ data-slot="button" ] { width: auto !important; } /* * THE LANE HOLDS AT EVERY WIDTH, and the first version of it did not - it was * wrapped in `min-width: 921px`, so on a phone the cell went back to being one * pixel and the strip, which is `position: absolute; right: 0`, painted itself * straight over the status badge. Measured at 606px: `elementFromPoint` on * the approved-status badge returned the strip, not the badge. That is exactly * what Andrius reported as the status not being visible at all. * * 150px fits the named button at both sizes now that the label is one word. */ /* * THREE OF THE RULES BELOW CARRY AN ID OR AN !important, AND BOTH ARE MEASURED * RATHER THAN CAUTIOUS. Bookly ships two stylesheets over this markup and they * have to be answered differently: its scoped Bootstrap declares buttons at * `#bookly-tbs .btn`, which beats any class-only selector however long, and its * Tailwind build emits utilities like `bookly:items-center` and * `bookly:rounded-lg` as `!important`. A first pass wrote both as plain class * rules; measured afterwards, the payment button was still 3.2px-cornered, the * cancel button 8px, and the strip still vertically centred - three rules that * matched and painted nothing. */ /* * TOP, NOT MIDDLE. Bookly centres the strip vertically (`inset-y-0` plus * `items-center`) while every data cell in the row is `align-top`, so on a * phone - where the treatment name wraps to three lines - the button floated * halfway down beside text that started at the top. Andrius spotted the * mismatch; this is the one line that removes it. */ /* * ON THE MIDDLE LINE, ALL OF IT. This block asked for the opposite two hours * earlier: Bookly centres the action strip while its data cells are * `align-top`, and on a phone - where the treatment name runs to three lines - * the button floated halfway down beside text that started at the top. The * answer then was to pull the button up. Looking at a real row, Andrius asked * for the other half instead: centre the CELLS too, so the price, the status * and both buttons share one line through the row. That is the better reading * of the same complaint, and it is why the cells carry `vertical-align` here. * * `!important` on both because Bookly's Tailwind writes `bookly:align-top` and * `bookly:items-center` that way. */ .bookly-customer-cabinet tbody [ data-slot="table-cell" ] { vertical-align: middle !important; } /* * AND CENTRED ACROSS THE LANE, NOT PINNED TO ITS EDGE - Andrius asked on * 2026-09-07 for the cancel button to stand off the edge the way the invoice * link does. * * The two controls reached their position by different mechanisms, which is why * they could not line up. Bookly's strip is `position: absolute; right: 0` with * 8px of its own padding, so its button sits 8px from the cell edge whatever the * lane is worth. The invoice link is an ordinary flex box with `margin-inline: * auto`, so it centres - and the lane is 150px on a desktop against a button of * about 113px, which parks it 18px in. Measured on dev at 900px, where the lane * is narrower, the gap was 8px against 6px: the same defect, too small to see. * * Stretching the strip across the cell and centring its contents makes both * controls obey the one rule, so they agree at every width instead of at one. */ .bookly-customer-cabinet td[ class*="right-0" ] > div { right: auto !important; left: 0; align-items: center !important; justify-content: center; width: 100%; } /* * THE ROW'S ONE BUTTON IS `.btn.btn--sm.btn--secondary`, WRITTEN OUT. * Andrius asked whether the design system already had something better thought * through than what this had grown into, and it does: `.btn` in base.css - pill, * `gap: --space-2`, `--fw-bold`, `line-height: --lh-body`, and the hover that * turns the border and the text blue. * * The values are the SMALL size, and that is the second half of the answer he * gave on 2026-09-07 when he said this button and the sign-out one above it did * not look equally round. They both declared a pill; they measured 44px and * 46.4px tall, and a pill's corner is half its box. This one is Bookly's markup * and cannot carry the classes, so it carries their numbers instead - 14px type, * 11px 22px of padding - and the two now come out at the same height, from the * same source. `min-height` stays as the floor invariant I8.2 asks for; at this * size the padding already clears it, and the line is what keeps that true if * the label is ever shortened to its glyph. * * `!important` on the colours as well as the type. The size and weight needed it * because Tailwind writes `text-sm`/`font-medium` that way; the border and the * colour need it for the same reason, and that was measured the hard way - the * plain versions of these two declarations used to live 60 lines above and never * painted (see the note there). * * THE FIRST SELECTOR IS THE FALLBACK ROW'S BUTTON, and it is here because a * parallel session found it on dev: when a payment cannot be matched to the * signed-in customer, inc/customer-cabinet.php deliberately leaves the row * alone, and Bookly's own payment button comes back. That path is rare and it * is the right behaviour - an unmatched payment must never print somebody * else's number - but the button it leaves behind was arriving as a bare * Bootstrap rectangle, because this block had narrowed to the cancel button * when the payment one stopped existing. A fallback that looks broken teaches * the visitor that the page is broken. */ /* * THE INVOICE LINK IS THE THIRD SELECTOR HERE, and it shares the rule rather * than copying it (WPS-114). Three controls that sit in the same lane and do * the same kind of thing - one action on this row - have to be the same object; * a second block with the same fifteen declarations is a second block to forget * when one of them changes. * * It is an `` rather than a `