/** * PropOffice Property UIs - Version 3 presentation. * * The canonical composition, measured off the supplied reference: * * a centred heading and a centred region subheading, generous whitespace, * then one contained landscape photograph per listing with an opaque white * information panel meeting its right edge and dropped a little below its * top; large minimal chevrons in the photograph's lower corners; one * pagination dot per listing on the same line, centred. * * Three relationships carry the design and everything else follows from them. * * - The photograph is a PROPORTION, not a height. The reference's picture is * 1175x622 - a ratio of 1.89 - and a component built on a pixel height stops * being the reference the moment the column it sits in is not 1175px wide. * So the media is an aspect-ratio box, and the height control overrides it * rather than defining it. * * - The panel is ANCHORED, not inset. It meets the photograph's right edge * exactly and is dropped 8% of the photograph's height below its top: two * different numbers on two different axes. A single symmetric inset - a * padded layer with the card floated into a corner - cannot express that, * which is why the panel is positioned against the photograph's edges * directly. * * - The arrows and the dots share ONE LINE near the foot of the photograph. * In the reference both sit 52px above its lower edge; they are one piece of * navigation, not two decorations that happen to be near each other. * * Colour comes from Elementor's Global Colors wherever a colour is a brand * decision, with this plugin's own design tokens as the fallback so a widget * rendered without a Kit still resolves. Nothing here reads a hex value off the * reference screenshot. * * Every value an agency might reasonably want to change is read from a custom * property with a fallback, in the pattern base.css describes: the fallback is * this composition's starting point, and the token is what an Elementor control * writes when somebody chooses otherwise. * * --ppui-panel-width's fallback carries more weight than the others. Nothing * declares that token - not base.css, not the control's default - so 40% is * what a Version 3 widget actually opens at, in both layouts, until an editor * moves the slider. The other fallbacks here back up a token that is declared * elsewhere; this one is the value. */ /* ------------------------------------------------------------ Component */ /* * The palette, bound once. * * Each role reads an Elementor Global Color first and this plugin's own token * second. That order is the whole point: on a site with a Kit the agency's * brand decides what "the accent" is, and on a page without one - a shortcode * on a non-Elementor template, the test harness, a theme that ships no Kit - * the component still resolves to the PropOffice design system rather than to * `unset`. * * Written at one class so every shared Appearance control still wins: Elementor * writes colours to `{{WRAPPER}} .propoffice-properties`, which is this same * element at a specificity no stylesheet selector here can reach. */ .propoffice-properties--version-3 { --ppui-v3-ink: var(--e-global-color-secondary, var(--ppui-text)); --ppui-v3-accent: var(--e-global-color-primary, var(--ppui-primary)); --ppui-v3-muted: var(--e-global-color-text, var(--ppui-muted)); /* * The panel is opaque and white in this composition - not a scrim, not a * translucent overlay, not a blur. It is expressed through the shared * overlay pair rather than a background of its own so that Background and * Background Opacity go on driving it, and the surface itself is the * design system's own token rather than a literal colour. */ --ppui-overlay: var(--ppui-v3-panel-surface, var(--ppui-surface)); --ppui-overlay-opacity: var(--ppui-v3-panel-opacity, 1); --ppui-panel-text: var(--ppui-v3-ink); --ppui-title-color: var(--ppui-v3-ink); --ppui-price-color: var(--ppui-v3-accent); --ppui-stat-value: var(--ppui-v3-ink); --ppui-stat-icon: var(--ppui-v3-ink); --ppui-location-color: var(--ppui-v3-muted); /* * The shape the navigation is laid out against. * * The photograph's, in this layout, because the slider shows one listing and * nothing else. Layout 2 reveals a slice of the neighbours either side, so * the row spans more than the current picture and says so there. */ --ppui-v3-nav-ratio: var(--ppui-v3-frame-ratio, 1.89); /* * Where a chevron sits, as three terms rather than as a rule per case. * * A chevron's placement varies along three axes that have nothing to do with * each other: the LAYOUT says where the current photograph's edge is, the * arrow position says whether the chevron stands on the picture or reaches * back out beside it, and the BREAKPOINT says how far in from that edge it * then sits. Written as rules, that is eight selectors competing on class * count, and the pair that lost is exactly how the chevrons ended up out over * a neighbouring listing: Layout 2 took the outside variant's gutter away and * had no way to take back the negative inset that reached into it. * * As terms there is no contest to win. Each axis owns one token, nothing * declares a token another axis owns, and the eight cases are the eight sums. * All three are zero-or-default in the canonical composition, so a widget * that touches no control resolves to exactly the offset - the number this * stylesheet has always drawn. */ --ppui-v3-current-inset: 0px; --ppui-v3-arrows-gutter: 0px; --ppui-v3-arrow-reach: 0px; --ppui-v3-arrow-step: var(--ppui-v3-arrow-offset, 24px); /* * How far a chevron stands ABOVE the picture's foot, which is a separate * number from how far it stands in from the side. Layout 2's specification * gives an inset of 50px on the left and the right and no figure for the * vertical, so the vertical stays where it was and stays the Offset control's * to move. */ --ppui-v3-arrow-rise: var(--ppui-v3-arrow-offset, 24px); --ppui-v3-arrow-edge: calc( var(--ppui-v3-current-inset) - var(--ppui-v3-arrow-reach) + var(--ppui-v3-arrow-step) ); /* * What one chevron takes out of the picture's width: its own box, plus the * step it stands in from the edge. The dots are inset by this on each side so * the row of them is laid out in the space BETWEEN the arrows rather than * across the whole photograph - which is what stops a long row running * underneath them. */ --ppui-v3-arrow-slot: calc(var(--ppui-nav-size, 56px) + var(--ppui-v3-arrow-step)); /* * The column the information card occupies, which the navigation keeps out of. * * Zero wherever the card leaves the picture's foot clear - which is the whole * of the canonical composition, and Layout 2 on a desktop once the card is * capped. It is not zero on a tablet, where the picture is too short to hold * the card and a navigation band above it; there the navigation goes beside * the card instead, and that breakpoint says so. */ --ppui-v3-card-reserve: 0px; /* * A contained card surrounded by whitespace, which the reference treats as * part of the design rather than as margin left over. The cap does nothing * in a column narrower than it; what it prevents is a full-width Elementor * section turning a feature card into an edge-to-edge page hero. */ margin-inline: auto; max-inline-size: var(--ppui-v3-max-width, 1200px); /* * The component is the thing the design is measured against, so it is the * thing the type is sized against: every clamp below is written in `cqi`, * one per cent of THIS element's inline size, rather than in `vw`. * * The difference is not academic. An editor can put this widget in a 625px * Elementor column on a 1440px screen, and viewport units size that card's * title for the screen - a 44px place name in a 250px panel, with the panel * growing through the bottom of its own photograph to hold it. The reference * is a proportion of a card, not a proportion of a monitor, and the numbers * are calibrated so that a component at the reference's own width reaches * the reference's own sizes. */ container-type: inline-size; } /* --------------------------------------------------------------- Header */ /* * The space below the header belongs to the header, so it leaves with it. * * Putting the gap here rather than above the gallery is what keeps the four * visibility combinations honest: when neither element is shown the renderer * emits no header at all, and with the header goes the only margin between it * and the gallery. */ .propoffice-properties--version-3 .propoffice-pui-v3__header { margin-block-end: var(--ppui-v3-header-gap, 44px); max-width: 100%; } /* * Centred, because that is the canonical composition. * * The alignment control starts at "centre" too, and an editor who chooses * otherwise overrides this. Stating it here as well is what keeps the reference * layout correct without depending on the panel having written anything. * * Both elements wrap rather than overflow: a heading is editable text and a * subheading names a region, so either can be longer than the component is wide. * Breaking a word is ugly; a horizontal scrollbar on the whole page is worse. */ .propoffice-properties--version-3 .propoffice-pui-v3__heading, .propoffice-properties--version-3 .propoffice-pui-v3__subheading { max-width: 100%; overflow-wrap: break-word; text-align: center; } /* * Sized against the component rather than at a fixed number, because the * reference is one width of many. Each clamp is set so that a component at the * reference's own width reaches the reference's own type size and stays * readable either side of it - the relationship is what is being reproduced, * not a screenshot's pixel count. */ .propoffice-properties--version-3 .propoffice-pui-v3__heading { color: var(--ppui-v3-heading-color, var(--ppui-v3-ink)); font-size: var(--ppui-v3-heading-size, clamp(1.5rem, 1.15rem + 3cqi, 3.25rem)); font-weight: 700; line-height: 1.15; margin: 0; } /* * The region selector. It is a peer of the heading rather than a caption of it * - same weight, accent colour, its own line - which is why it carries a * dropdown indicator rather than reading as a subtitle. */ .propoffice-properties--version-3 .propoffice-pui-v3__subheading { color: var(--ppui-v3-subheading-color, var(--ppui-v3-accent)); font-size: var(--ppui-v3-subheading-size, clamp(1rem, 0.85rem + 0.85cqi, 1.5rem)); font-weight: 700; line-height: 1.4; margin: var(--ppui-v3-subheading-gap, 0.7rem) 0 0; } /* * The words and the indicator stay inline-level so that the alignment control - * which writes text-align on the paragraph - moves them together. A flex row * here would centre the pair correctly and then ignore "left" and "right", * because those are not values justify-content understands. */ .propoffice-properties--version-3 .propoffice-pui-v3__subheading-text { vertical-align: middle; } .propoffice-properties--version-3 .propoffice-pui-v3__subheading-indicator { display: inline-flex; block-size: 0.8em; inline-size: 0.8em; margin-inline-start: 0.45em; vertical-align: middle; } .propoffice-properties--version-3 .propoffice-pui-v3__subheading-indicator svg { block-size: 100%; display: block; inline-size: 100%; } /* ----------------------------------------------------- Property changes */ /* * How one property replaces another. * * Taken from the supplied reference recording, measured rather than guessed. * Across three consecutive property changes the incoming listing entered from * the right with its leading edge at roughly 45% of the width, travelled left, * and came to rest in 234ms, 284ms and about 250ms. Plotted against normalised * time the positions were 0.30, 0.56, 0.67, 0.84, 0.90, 0.98 - a deceleration * that tracks cubic-bezier(0.25, 0.1, 0.25, 1) closely. Nothing faded and * nothing scaled: the photograph, its panel and everything on the slide moved * together as one plane. * * So this is the shared slider's own horizontal movement, at the reference's * speed and with its curve stated rather than inherited. Swiper writes the * duration inline from the Transition Speed control and leaves the curve to CSS, * which is the seam this uses - no second slider, no keyframes, no JavaScript. * * The curve is spelled out rather than written as `ease`, which is the same * four numbers, because a theme resetting transitions to `linear` further down * the cascade would otherwise take the deceleration with it and nothing would * name what had been lost. */ .propoffice-properties--version-3 .swiper-wrapper { transition-timing-function: var(--ppui-v3-transition-easing, cubic-bezier(0.25, 0.1, 0.25, 1)); } /* * A property change is movement across the screen, which is exactly what a * visitor who asks for reduced motion is asking not to have. Swiper still * advances - the property changes, the panel changes, the pagination follows - * it simply arrives rather than travels. */ @media (prefers-reduced-motion: reduce) { .propoffice-properties--version-3 .swiper-wrapper { transition-duration: 1ms !important; } } /* ---------------------------------------------------------------- Frame */ /* * One listing: the photograph, and the panel positioned against it. * * The frame is a positioning context and nothing else. Its height is the * photograph's height, because the photograph is the only thing in its flow - * the panel is taken out, which is what "the panel overlaps the image" means * structurally. Nothing the panel contains can make the picture taller, and a * listing with a great deal to say cannot reshape the composition. */ .propoffice-properties--version-3 .propoffice-pui-v3__frame { position: relative; } /* * The photograph is a proportion. * * `aspect-ratio` with `block-size: auto` means the picture is 1.89 times as * wide as it is tall at every width the component is given, which is the * reference's own shape. The height control still overrides it completely: a * definite block-size makes aspect-ratio inert, so an editor who sets 500px * gets 500px. That control registers no default precisely so that this * fallback is what a fresh widget opens at. * * The listing's featured image is painted by this box rather than embedded as * an element inside it, which is what makes the container the owner of the * composition: a background has no intrinsic size to impose, so no upload can * decide how tall a property stands. The renderer supplies one custom property * - which photograph - and every decision about how it is drawn stays here, * where the shared image controls can reach it. * * `cover` rather than the shared Image Fit value: `contain` and `scale-down` * letterbox, which this composition explicitly does not do, and `fill` has no * background-size equivalent. The anchor remains the shared Image Position * control, which maps to background-position exactly. */ .propoffice-properties--version-3 .propoffice-pui-v3__media { aspect-ratio: var(--ppui-v3-frame-ratio, 1.89); background-image: var(--ppui-v3-featured-image, none); background-position: var(--ppui-image-position, center center); background-repeat: no-repeat; background-size: cover; block-size: var(--ppui-v3-frame-height, auto); inline-size: 100%; overflow: hidden; position: relative; } /* * Drawn only when a listing has no usable photograph, so the container reads as * deliberate rather than blank. */ .propoffice-properties--version-3 .propoffice-pui-v3__placeholder { block-size: 100%; inline-size: 100%; object-fit: cover; } /* * The whole-frame link is a stretched, empty anchor rather than a wrapper, so * the panel's own button stays a separate target instead of becoming a link * inside a link. It sits under the panel so anything in there remains clickable. */ .propoffice-properties--version-3 .propoffice-pui-v3__link { inset: 0; position: absolute; z-index: 1; } /* * It is an empty anchor, so without this its focus ring would be a zero-sized * outline nobody can see - and it is the primary route to the listing for anyone * navigating by keyboard. */ .propoffice-properties--version-3 .propoffice-pui-v3__link:focus-visible { outline: 3px solid var(--ppui-v3-focus, var(--ppui-v3-accent)); outline-offset: -3px; } /* ------------------------------------------------------ Information panel */ /* * The panel is placed inside the photograph by an AREA and an ALIGNMENT. * * Those are the two halves of the model, and keeping them apart is what makes * nine placements one rule instead of nine layouts. * * The AREA is the four insets: the photograph, held off each edge by that * side's offset. It is where the card is allowed to be, and at the offsets this * composition opens at - zero on every side - it is the photograph exactly. Each * side reads a token of its own, so moving the card away from the right edge * cannot move it away from the top as well; one value driving four sides is the * universal inset this replaced. * * An offset therefore means the same thing on both axes without meaning the * same distance on both. Against an edge the card is anchored to it is the gap * from that edge exactly - Right at 30px puts 30px of photograph beside the * card. On an axis set to centre there is no edge to measure from, so the offset * narrows the space and the card re-centres in what is left, which moves it by * half. Both are the same rule; only the alignment differs. * * The navigation is NOT subtracted from that area, and the separation between * the two is not a number either of them holds. They are two layers over one * photograph: the card is centred in the picture, the navigation sits near its * foot, and the gap is what those two placements leave between them - about * seventy pixels at the reference's proportions, and proportional, so it holds * at every width. Reserving a strip inside the card's box would have produced * the same screenshot by making one component's size move the other, which is * exactly the coupling the navigation was rewritten to lose. * * The ALIGNMENT is two margin pairs. An absolutely positioned box with both * insets set and a definite size in that axis hands its leftover space to its * auto margins: `auto auto` centres it, `0 auto` pushes it to the start, `auto * 0` to the end. That is real centring rather than an arithmetic imitation of * it - it holds for any card width, any photograph size, any column, and it * keeps holding while the card's own height changes as a listing with more to * say replaces one with less. The control writes the pair through a selectors * dictionary, so the stored value stays "center" and the stylesheet composes * with the margin. The fallbacks below are the composition's own opening * placement - `auto 0` across, `auto auto` down: flush right, centred - so a * widget rendered outside Elementor starts where the panel says it does. * * `fit-content` in the block axis is what makes the vertical half work at all. * A box with both `top` and `bottom` set and `height: auto` fills the space and * has no leftover to give away, so auto margins compute to zero and every * vertical alignment looks like "top". `fit-content` is the content's height, * capped at the space available - so there is leftover to distribute, and a * card too tall for its area still stops at the navigation instead of running * through it. * * What this replaces was a Position select of four corners and one Inset * applied to all sides of whichever was chosen. It could not express "centred" * at all, and could not move the card on one axis without moving it on the * other, because a corner is one value carrying two decisions. */ .propoffice-properties--version-3 .propoffice-pui-v3__card { block-size: fit-content; inline-size: var(--ppui-panel-width, 40%); inset-block: var(--ppui-v3-card-offset-top, 0px) var(--ppui-v3-card-offset-bottom, 0px); inset-inline: var(--ppui-v3-card-offset-left, 0px) var(--ppui-v3-card-offset-right, 0px); margin-block: var(--ppui-v3-card-align-y, auto auto); margin-inline: var(--ppui-v3-card-align-x, auto 0); max-inline-size: 100%; /* * No minimum. A floor is not a smaller version of a width, it is a * different answer: at min(260px, 100%) every setting below roughly 28% of * the component produced the same panel, so the slider moved and nothing * did - and 200px selected rendered 260px. */ min-inline-size: 0; position: absolute; z-index: 2; } /* * The surface: opaque, rectangular, unshadowed. * * All three are stated rather than left to a default, because all three were * wrong before. Square by default because the reference composition is * architectural - the panel is a block of paper laid on a photograph, and a * radius softens it into a floating SaaS card. No shadow for the same reason; * the panel is separated from the picture by being opaque, which is enough. * * The padding is proportional rather than fixed. The reference pads the panel * by a tenth of its own width horizontally and by two thirds again as much * vertically - 48px and about 79px on a 473px panel, and percentage padding resolves against the element's inline * size on every side - so that relationship survives the panel being 470px * wide on one page and 300px on another. Whatever the shared Padding control * writes replaces it outright. */ .propoffice-properties--version-3 .propoffice-pui-v3__card-inner { background: color-mix(in srgb, var(--ppui-overlay) calc(var(--ppui-overlay-opacity, 1) * 100%), transparent); border-radius: var(--ppui-panel-radius, 0); box-shadow: var(--ppui-v3-panel-shadow, none); color: var(--ppui-panel-text); padding: var(--ppui-panel-pad, 16.5% 10%); } /* * Elegant and relatively lightweight, which is the reference's most distinctive * decision and the easiest one to lose. A property title here is a place name * set large and thin, not a headline set heavy - it reads as the name of * somewhere rather than as an advertisement for it. */ .propoffice-properties--version-3 .propoffice-pui-v3__title { color: var(--ppui-title-color); font-size: var(--ppui-v3-title-size, clamp(1.25rem, 1.05rem + 2.4cqi, 2.75rem)); font-weight: var(--ppui-v3-title-weight, 300); line-height: 1.15; margin: 0; overflow-wrap: break-word; } /* * Prominent, and clearly secondary to the photograph. It is the accent colour * and the heaviest weight on the panel, at about two thirds of the title's * size - prominence from colour and weight rather than from being the biggest * thing in the composition. */ .propoffice-properties--version-3 .propoffice-pui-v3__price { color: var(--ppui-price-color); font-size: var(--ppui-v3-price-size, clamp(1.0625rem, 0.85rem + 1.6cqi, 1.875rem)); font-weight: 700; line-height: 1.2; margin: var(--ppui-v3-price-gap, 0.45em) 0 0; overflow-wrap: break-word; } /* ---------------------------------------------------------------- Stats */ /* * The figure row: a value, then its pictogram, repeated. * * That order is the reference's and it is not interchangeable with the other * one. Reading "3" and then a bed is reading a quantity and then its unit, * which is how the row scans as a list of facts; a leading icon turns each * pair into a labelled field and the row into a specification table. */ .propoffice-properties--version-3 .propoffice-pui-v3__stats { align-items: center; display: flex; flex-wrap: wrap; gap: 0.35em var(--ppui-v3-stat-gap, 1.5em); list-style: none; margin: var(--ppui-v3-stats-gap, 1.05em) 0 0; padding: 0; } .propoffice-properties--version-3 .propoffice-pui-v3__stat { align-items: center; color: var(--ppui-stat-value); display: inline-flex; font-size: var(--ppui-v3-stat-size, clamp(0.875rem, 0.7rem + 0.85cqi, 1.375rem)); gap: 0.4em; line-height: 1.2; } /* * The supplied artwork is drawn on a 32-unit grid and painted with * `currentColor`, so the shared Icon Colour control still reaches it and the * shape is scaled by CSS rather than by editing the file. `--color1` is bound * alongside because that is the custom property the supplied files name for * their own colour, and an asset used directly should still answer to it. */ .propoffice-properties--version-3 .propoffice-pui-v3__stat-icon { --color1: var(--ppui-stat-icon); block-size: var(--ppui-stat-icon-size, 1.05em); color: var(--ppui-stat-icon); flex: none; inline-size: var(--ppui-stat-icon-size, 1.05em); } /* ---------------------------------------------------------------- Agent */ /* * Who is selling it: a round portrait, a name, and the agency beneath it. * * There is deliberately no rule above this block and no surface behind it. The * reference separates the agent from the figures with space alone, and the * agent reads as the last line of the panel rather than as a second component * that happens to be inside it. * * The row wraps because the portrait will not shrink and the name will, so on a * panel narrow enough the picture takes the width and the identity is squeezed * to nothing rather than moving below it. It costs nothing at any width the two * fit side by side. */ .propoffice-properties--version-3 .propoffice-pui-v3__agent { align-items: center; display: flex; flex-wrap: wrap; gap: var(--ppui-v3-agent-gap, 0.85em); margin-block-start: var(--ppui-v3-agent-space, 1.6em); } .propoffice-properties--version-3 .propoffice-pui-v3__agent-photo { block-size: var(--ppui-v3-agent-photo-size, clamp(40px, 4.4cqi, 52px)); border-radius: 50%; flex: none; inline-size: var(--ppui-v3-agent-photo-size, clamp(40px, 4.4cqi, 52px)); object-fit: cover; } .propoffice-properties--version-3 .propoffice-pui-v3__agent-identity { display: flex; flex-direction: column; min-inline-size: 0; } .propoffice-properties--version-3 .propoffice-pui-v3__agent-name, .propoffice-properties--version-3 .propoffice-pui-v3__agent-agency { overflow-wrap: break-word; } /* * The person is named in the reading weight and the agency beneath them in a * smaller, heavier one. That inversion is the reference's: the name is who you * are dealing with, the agency is the mark it is sold under. */ .propoffice-properties--version-3 .propoffice-pui-v3__agent-name { color: var(--ppui-panel-text); font-size: var(--ppui-v3-agent-name-size, clamp(0.9375rem, 0.8rem + 0.55cqi, 1.1875rem)); font-weight: 400; line-height: 1.3; } .propoffice-properties--version-3 .propoffice-pui-v3__agent-agency { color: var(--ppui-panel-text); font-size: var(--ppui-v3-agent-agency-size, clamp(0.8125rem, 0.75rem + 0.25cqi, 0.9375rem)); font-weight: 700; line-height: 1.3; } /* ------------------------------------------------------------------ CTA */ /* * Off by default, because the reference panel carries no button - the whole * photograph is the link. It exists for an installation that needs an explicit * target and is styled to belong to the panel when it is switched on. * * The button gives way rather than sticking out. It is an inline-block sized by * a label that does not wrap, so on a narrow panel it stood proud of the * padding and outside the panel itself. Capping it at the content width and * letting the label wrap is what makes a narrow panel look deliberate instead * of broken; nothing changes at a width the label fits on one line, because the * box shrink-wraps to its text there. */ .propoffice-properties--version-3 .propoffice-pui-v3__cta { background: var(--ppui-cta-bg, var(--ppui-v3-accent)); border-radius: var(--ppui-panel-radius, 0); color: var(--ppui-cta-text); display: inline-block; margin-block-start: 1.5em; max-inline-size: 100%; overflow-wrap: break-word; padding: 0.7em 1.4em; text-align: center; text-decoration: none; transition: background-color 160ms ease, color 160ms ease; } .propoffice-properties--version-3 .propoffice-pui-v3__cta:hover, .propoffice-properties--version-3 .propoffice-pui-v3__cta:focus-visible { background: var(--ppui-cta-bg-hover, var(--ppui-cta-bg)); color: var(--ppui-cta-text-hover, var(--ppui-cta-text)); } /* --------------------------------------------------------- Slider chrome */ /* * This composition's starting numbers for the shared slider's own tokens. * * They are declared here, on the slider root, because that is where slider.css * declares them - a value set on an ancestor would be shadowed by the shared * declaration rather than overriding it. The reference asks for 56px chevrons * and about 22px between the dots; the shared defaults are 44px and 8px, which * are right for a compact carousel and wrong for a full-width gallery. * * The dots are drawn in the inverse text colour rather than the border grey, * because in this composition they sit on a photograph rather than under one. * * The panel writes the same tokens to the same element, at a specificity a * theme-scoped selector cannot reach, so an editor still wins. */ .propoffice-properties--version-3 .propoffice-pui-slider { /* * Both indicator colours, and they are the same colour. * * Every dot is white, resting and current alike: the current listing is told * apart by the circle drawn around it, not by the dot changing colour. Two * tokens rather than one because the panel offers Colour and Active Colour * separately, and a site that wants them to differ is entitled to. * * Declared here, at two classes, on purpose: the Colour controls register no * default, so Elementor writes nothing until an editor picks one - and when * they do, Elementor's rule names four classes and wins. * * The literal at the end of each chain is a guard. `--ppui-text-inverse` is * declared in base.css, and an unresolved custom property does not degrade * gracefully - `background: var(--undefined)` computes to transparent, and * the dot is simply not drawn. Measured, with base.css absent: exactly that. */ --ppui-dot-active-color: var(--ppui-text-inverse, #ffffff); --ppui-dot-color: var(--ppui-text-inverse, #ffffff); --ppui-nav-size: 56px; /* * In this composition the chevron IS the button, so the glyph is the whole * of the size rather than a small mark centred in a larger target. Version 1 * and Version 2 register an Icon Size control and Version 3 does not, which * is the same statement made in the panel: there is one number here, and the * Arrow Size control is it. * * Bound to the token rather than fixing the svg's own box, because slider.css * sizes each direction's glyph from these tokens at three classes - a rule a * version-scoped selector cannot outrank, and one that quietly kept the * arrows at the shared 1.25rem while a stylesheet said otherwise. Writing the * token instead leaves the shared rules in charge, so the per-direction * overrides and any control that writes them still work. * * The supplied chevron is drawn on a 16x32 grid, so a square box of this size * draws it half as wide as it is tall - the reference's proportion, from the * artwork's own geometry rather than from a second number here. */ --ppui-nav-icon-size: var(--ppui-nav-size, 56px); position: relative; } /* --------------------------------------------------------------- Arrows */ /* * The arrows are placed against the photograph, so the box they are placed * against has to be the photograph's. * * The shared navigation row is an absolutely positioned flex group - arrows * around a counter, moved as one unit - and it is only as wide as its contents. * Version 3 does not move that group; it places each arrow separately, and an * absolutely positioned arrow resolves its offsets against the nearest * positioned ancestor, which is the row. Left at that, both arrows land beside * the row's zero-width centre: the previous arrow ends up to the *right* of the * next one, with every offset still computing to exactly what was asked for. * * Stretching the row over the photograph makes it a positioning context rather * than a bar, which is what this composition needs it to be. Three classes so * the shared two-class rule is beaten wherever the two stylesheets land in the * cascade. It stops taking pointer events, or an invisible full-size box would * sit over the photograph and swallow the whole-frame link. * * Over the PHOTOGRAPH, and not over the slider, and the difference is the whole * reason this box is described twice. The slider is as tall as everything it * holds - which is the picture plus the dots when they sit below it, and the * picture plus the whole information panel on a phone. An arrow anchored to the * slider's foot therefore left the photograph whenever anything was added under * it: choosing "below" for the dots dropped the chevrons onto the picture's * lower edge, and a phone put them beside the agent's name. * * So the row is anchored to the top and given the photograph's own shape - the * same ratio, the same height override, the same fallback. A box of the same * width with the same proportion IS the picture's height, at every width, in * every column, without anything having to measure it. * * The width is stated, and that is what keeps the ratio working in one direction * only. An absolutely positioned box whose width is left `auto` does not take * its width from its left and right insets once it has an aspect ratio and a * definite height: the ratio decides the width instead. With no Property Media * Height that never shows - the height is the one left open and the ratio fills * it in - but the moment the control gives the photograph a height, the row * became that height times the ratio wide, and nothing else. Measured on Layout 2 * at 1440px, where the slider is 1200px: a 520px photograph drew a 1474px row and * a 700px one a 1984px row, and because every arrow edge, the current-listing * inset and the dots' insets are percentages OF this row, the next chevron and * the dots slid off the photograph, past the component and out of the viewport * as the picture grew - while a shorter picture left them stranded mid-frame. * * Stated as the width the insets already describe - the positioning box less * the gutter on each side - the width can only ever come from the slider, and * the ratio is left to decide the one dimension it is for: the height, and only * when no height has been set. */ .propoffice-properties--version-3 .propoffice-pui-slider .propoffice-pui-slider__nav { align-items: center; aspect-ratio: var(--ppui-v3-nav-ratio); block-size: var(--ppui-v3-frame-height, auto); inline-size: calc(100% - 2 * var(--ppui-v3-arrows-gutter)); inset: 0 var(--ppui-v3-arrows-gutter) auto; justify-content: center; margin: 0; pointer-events: none; transform: none; } /* * The gutter an outside arrangement holds open beside the photograph, given * back to the box the navigation is laid out against. * * An absolutely positioned box resolves its insets against its ancestor's * PADDING box, so leaving the row at zero would span the gutter as well - a box * wider than the photograph and, at the photograph's own proportion, taller than * it, dropping the chevrons and the dots below the picture by exactly the gutter. * Both are stated from the one token so the row narrows by precisely what the * padding widened. */ .propoffice-properties--version-3 .propoffice-pui-slider { padding-inline: var(--ppui-v3-arrows-gutter); } .propoffice-properties--version-3 .propoffice-pui-slider .propoffice-pui-slider__arrow, .propoffice-properties--version-3 .propoffice-pui-slider .propoffice-pui-slider__counter { pointer-events: auto; } /* * Large and minimal: a glyph on the photograph rather than a button with a * surface. The hit area stays the full configured size even though nothing is * painted behind it, because a 56px target that looks like a 28px chevron is * still a 56px target. * * The offset is one number on both axes, which is the reference's arrangement: * the chevron's centre sits the same distance from the photograph's side as * from its foot. Bottom rather than centred - level with the panel they would * read as a picture viewer with a caption beside it rather than as one listing. */ .propoffice-properties--version-3 .propoffice-pui-slider__arrow { align-items: center; background: none; block-size: var(--ppui-nav-size, 56px); border: 0; color: var(--ppui-nav-color, var(--ppui-text-inverse)); cursor: pointer; display: inline-flex; inline-size: var(--ppui-nav-size, 56px); inset-block-end: var(--ppui-v3-arrow-rise); justify-content: center; opacity: var(--ppui-v3-arrow-opacity, 0.85); padding: 0; position: absolute; top: auto; transform: none; transition: color 160ms ease, opacity 160ms ease; z-index: 3; } .propoffice-properties--version-3 .propoffice-pui-slider__arrow:hover, .propoffice-properties--version-3 .propoffice-pui-slider__arrow:focus-visible { color: var(--ppui-nav-color-hover, var(--ppui-text-inverse)); opacity: 1; } .propoffice-properties--version-3 .propoffice-pui-slider__arrow--prev { inset-inline-start: var(--ppui-v3-arrow-edge); } .propoffice-properties--version-3 .propoffice-pui-slider__arrow--next { inset-inline-end: calc(var(--ppui-v3-arrow-edge) + var(--ppui-v3-card-reserve)); } /* * Outside arrows are placed beyond the photograph, so the slider root carries a * gutter wide enough to hold them - otherwise they would be positioned over the * page rather than over the component. * * Naming the gutter is the whole of this variant. Everything that has to know * about it already reads it: the slider opens the padding, the navigation row * narrows by it, the dots are inset by it, and the arrows reach back out through * it because the edge they measure from subtracts it. A layout that wants no * gutter - Layout 2, or a phone - says so by setting this one token to zero, and * every one of those follows without a rule of its own. */ .propoffice-properties--version-3.propoffice-pui-v3--arrows-outside { --ppui-v3-arrows-gutter: calc(var(--ppui-nav-size, 56px) + var(--ppui-v3-arrow-offset, 24px)); /* * The chevron reaches back out through the whole gutter AND past its own * step, which is what leaves the step standing as clearance between the * chevron and the picture rather than as an indent into it. The gutter is one * arrow plus one offset wide, so an arrow that starts a gutter-and-a-step out * ends exactly one offset short of the photograph. */ --ppui-v3-arrow-reach: calc(var(--ppui-v3-arrows-gutter) + var(--ppui-v3-arrow-step)); } /* ----------------------------------------------------------- Pagination */ /* * One dot per listing, on the arrows' line. * * Where the row sits is carried by tokens rather than written into four * competing rules, and that is a structural decision rather than a stylistic * one. Each position is a different combination of five properties - an inset, * an anchor, a transform, an alignment and whether the row is in flow at all - * and the readable way to write that is one rule that reads five values and a * short block per position that sets them. * * Written as rules instead, each position has to be selected with the version * class AND the variant class AND the slider AND the pagination, and anything * that later needs to move the row - the phone composition below - has to beat * four classes for every position separately or silently lose to whichever one * the editor happened to choose. That is exactly what happened: a phone rule * placing the dots on the photograph was outranked by the desktop centring, and * the row came out half a component wide with an aspect ratio measured off it. * * With tokens there is no contest to win. A breakpoint re-declares the values on * the component root and every position follows. */ .propoffice-properties--version-3 { --ppui-v3-dots-align: flex-end; /* * The dots are laid out in the space BETWEEN the chevrons. * * Each side is the slice a neighbour is showing plus the slot one arrow * occupies, so the row always ends where an arrow begins. The gutter is not in * this sum and no longer needs to be - the dots are inside the navigation row, * and the row has already been inset by it. * * This is what makes the overlap impossible rather than unlikely. The dots * used to be centred in a box the width of the whole photograph, with no * bound and no knowledge of the arrows: twenty listings on a phone produced a * row wider than the picture, and `justify-content: center` centred the * overflow - three dots off each side of the photograph and two underneath * each chevron. Bounded to the space between them, a long row wraps inside it. */ --ppui-v3-dots-inline-end: calc( var(--ppui-v3-current-inset) + var(--ppui-v3-card-reserve) + var(--ppui-v3-arrow-slot) ); --ppui-v3-dots-inline-start: calc(var(--ppui-v3-current-inset) + var(--ppui-v3-arrow-slot)); --ppui-v3-dots-justify: center; --ppui-v3-dots-lift: var(--ppui-v3-dot-offset, 24px); --ppui-v3-dots-pad-inline: 0px; --ppui-v3-dots-position: absolute; /* * The dots take the navigation row's own height, and that ends a whole class * of bug. * * They used to rebuild the photograph's box for themselves - an aspect ratio * and a height token, evaluated against a different width from the one the * arrows used - so the two boxes agreed only by arithmetic, and when they * disagreed they disagreed silently. Inside the row there is nothing to * rebuild: the row IS the box the arrows are placed from, and the dots are in * it, so they share the arrows' line by construction rather than by agreement. */ --ppui-v3-dots-size: 100%; --ppui-v3-dots-space-above: 0px; --ppui-v3-dots-top: 0; } /* * The row takes the photograph's box, exactly as the arrows do, and the bullets * are aligned to its foot and lifted onto the arrows' centre line. * * The lift is the offset both controls measure from, plus half the difference * between an arrow box and an indicator - so the dots and the chevrons sit on one * line and stay on it when either Offset, the Arrow Size or the Dot Size changes. * That arithmetic is only true because every indicator is the same height, which * is why each one is the same square whether or not its circle is drawn; see * below. * * slider.css positions the row with left/top plus a translate, and its defaults * centre it *below* the viewport, so every one of those properties is stated * here rather than left half-overridden: an inset without its transform leaves * the row shifted by half its own width, which is a full-width box hanging off * the left of the component. */ .propoffice-properties--version-3 .propoffice-pui-slider .propoffice-pui-slider__pagination.swiper-pagination { align-items: var(--ppui-v3-dots-align); block-size: var(--ppui-v3-dots-size); bottom: auto; /* * One line, in both layouts. A row longer than the space between the chevrons * is not wrapped into a second row and not allowed to spill out of the ends of * the picture either - it slides behind the window below instead, which is the * only arrangement that keeps every indicator its stated size on one line at * any number of listings. */ flex-wrap: nowrap; /* * Spacing is stated centre to centre, and flex spaces boxes by their edges, so * the gap is the pitch less one whole indicator. Clamped at nothing: a pitch * smaller than an indicator puts the circles edge to edge rather than on top * of one another. */ gap: max(0px, var(--ppui-v3-dot-pitch, 16px) - var(--ppui-v3-dot-box)); justify-content: var(--ppui-v3-dots-justify); left: var(--ppui-v3-dots-inline-start); margin: var(--ppui-v3-dots-space-above) 0 0; padding: 0 var(--ppui-v3-dots-pad-inline) calc(var(--ppui-v3-dots-lift) + (var(--ppui-nav-size, 56px) - var(--ppui-v3-dot-box)) / 2); /* * The row declines pointer events - an invisible full-size box over the * photograph would swallow the whole-frame link - and everything in it a * visitor presses has to take them back. The arrows and the counter already * did; pagination nobody can click is not pagination. */ pointer-events: auto; position: var(--ppui-v3-dots-position); right: var(--ppui-v3-dots-inline-end); top: var(--ppui-v3-dots-top); transform: none; z-index: 3; } .propoffice-pui-v3--dots-bottom-left { --ppui-v3-dots-justify: flex-start; --ppui-v3-dots-pad-inline: var(--ppui-v3-dot-offset, 24px); } .propoffice-pui-v3--dots-bottom-right { --ppui-v3-dots-justify: flex-end; --ppui-v3-dots-pad-inline: var(--ppui-v3-dot-offset, 24px); } /* * Below the photograph rather than over it, for a composition whose lower edge * is busy. In flow rather than positioned, so the dots add their own height * instead of overlapping whatever follows the component - which means giving up * the picture's box, its lift and its alignment together. */ .propoffice-pui-v3--dots-below { --ppui-v3-dots-align: center; --ppui-v3-dots-inline-end: var(--ppui-v3-current-inset); --ppui-v3-dots-inline-start: var(--ppui-v3-current-inset); --ppui-v3-dots-lift: 0px; --ppui-v3-dots-size: auto; --ppui-v3-dots-space-above: var(--ppui-v3-dot-offset, 24px); /* * The foot of the navigation row is the foot of the photograph, so "below the * picture" is the row's own 100% - stated as the placement token like every * other position. Dropping into normal flow is not available to something the * row contains, and the chevrons' slot is not subtracted here: below the * picture there is nothing to avoid, so the dots centre on the whole width. */ --ppui-v3-dots-top: 100%; } /* * ...and the height it used to add by being in flow is added by the slider, so a * component whose dots sit below its picture is still as tall as its dots and * still cannot overlap whatever follows it. * * On the slider rather than the component, because the navigation row is placed * against the slider's padding box: padding here lengthens the component without * moving the row, the picture or the arrows by a pixel. */ .propoffice-properties--version-3.propoffice-pui-v3--dots-below .propoffice-pui-slider { padding-block-end: calc(var(--ppui-v3-dot-offset, 24px) + var(--ppui-v3-dot-box)); } /* * The indicator: a solid white dot, and a circle around the current one. * * Every dot is the same solid white in every state - resting, current and * hovered. Nothing grows, nothing recolours, nothing hollows out. The only * difference the current listing makes is the circle drawn around its dot, with * air between the two. * * The geometry is settled, and written down in * docs/designs/FEATURED-CARD-VERSION-3-PAGINATION.md: * * 1px border + 2px clear space + 8px dot + 2px clear space + 1px border = 14px * * The current indicator's painted outer diameter is 14px ON PURPOSE. The final * specification also calls the outer circle "12px", which the three measurements * beside it cannot produce; the 8px dot, the 2px clearance and the 1px border were * decided authoritative, so the circle is 14px, every indicator reserves the same * 14px square, and the pitch is 16px centre to centre. Do not shrink the dot or * the clearance to reach 12. * * Three boxes, and each has one job. The bullet is the control: a fixed square * built outwards from the dot the panel's Size sets - the dot, the air on each * side and the circle's border on each side, `--ppui-v3-dot-box` below - and it is * the same square in every state, so the row cannot move when the current listing * changes. The dot is `::after`, inset from the square by the border and the air, * which leaves exactly the Size an editor chose. The circle is `::before`, drawn * on the current listing only and laid over the square's edge, so it adds nothing * to anything's size. * * The circle is a layer rather than the bullet's own border because a border is * snapped to whole device pixels. On a display scaled to 125% a 1px border is * drawn 0.8px wide, and a bordered bullet then either grows its outer edge (and * the pitch with it) or shrinks its inside (and the dot with it) - measured, the * dot came out 8.4px. As a layer, the snapping is absorbed by the air between the * dot and the circle, and the dot, the square and the pitch stay the numbers * they were given. */ .propoffice-properties--version-3 .propoffice-pui-slider__pagination .swiper-pagination-bullet { /* * The square carries no fill and no border of its own: the dot is the fill * and the circle is the border, each on its own layer. */ background: transparent; border: 0; border-radius: 50%; box-sizing: border-box; /* * Stated here rather than left to the shared stylesheet's `--ppui-dot-size`, * which is the whole mark in Versions 1 and 2: this mark is a dot with room * for a circle around it, and the square has to hold both. */ height: var(--ppui-v3-dot-box); /* * Full strength by default. The indicator used to be faded so a solid mark * sat quietly on a photograph; the specification asks for solid white, and a * faded white dot is a grey one. The token is still read, because a control * writing a token no stylesheet reads is a control that does nothing. */ opacity: var(--ppui-v3-dot-opacity, 1); position: relative; width: var(--ppui-v3-dot-box); } /* * The dot. Solid in every state - never a hole, never a transparent centre. */ .propoffice-properties--version-3 .propoffice-pui-slider__pagination .swiper-pagination-bullet::after { background: var(--ppui-dot-color); border-radius: 50%; content: ""; inset: calc(var(--ppui-v3-dot-ring-width, 1px) + var(--ppui-v3-dot-inset, 2px)); position: absolute; } /* * The current listing: the same square and the same dot, with its circle drawn. * * `box-shadow: none` takes off the ring this composition used to draw outside the * active bullet - an accent spread that made the current mark read as larger. The * circle asked for here sits INSIDE the square every indicator already has. */ .propoffice-properties--version-3 .propoffice-pui-slider__pagination .swiper-pagination-bullet-active { background: transparent; box-shadow: none; opacity: var(--ppui-v3-dot-active-opacity, 1); } .propoffice-properties--version-3 .propoffice-pui-slider__pagination .swiper-pagination-bullet-active::before { border: var(--ppui-v3-dot-ring-width, 1px) solid var(--ppui-v3-dot-ring, var(--ppui-dot-active-color, #ffffff)); border-radius: 50%; content: ""; inset: 0; position: absolute; } .propoffice-properties--version-3 .propoffice-pui-slider__pagination .swiper-pagination-bullet-active::after { background: var(--ppui-dot-active-color); } /* * Hover softens a resting indicator and does nothing else - same dot, same * colour, same size, and no circle. The specification allows a pointer to be * answered with a little less opacity, and that is the whole of the answer: a * hover that recoloured the dot would break "solid white in all states", and one * that added a circle would say "current" about a listing that is not. * * The current indicator is left alone, because it is already the answer. */ .propoffice-properties--version-3 .propoffice-pui-slider__pagination .swiper-pagination-bullet:hover:not(.swiper-pagination-bullet-active) { opacity: var(--ppui-v3-dot-hover-opacity, 0.75); } /* * The window itself: the box clips, and the row slides behind it. * * The pagination's box is already exactly the space between the two chevrons, so * it is the right window without being given a size. Clipping it is what stops a * long row reaching the arrows, leaving the photograph, or dragging the * document's own width out past the viewport - all three measured at twenty * listings on a 375px screen. * * The shift is written by slider.js and read here. Nothing moves until a row is * longer than its window, and every indicator keeps the size the design gives it * - which is the whole reason this is not Swiper's own dynamic bullets, measured * drawing 2.6px marks where the design says 8. */ .propoffice-properties--version-3 .propoffice-pui-slider__pagination.swiper-pagination { overflow: hidden; } /* * Written as the placement token rather than as `justify-content`, because the * rule that sets that property names four classes and this one could only name * two. A custom property declared on the element itself is nearer than one * declared on the component root, and nearness is what decides a token - so this * reaches the row whatever the selectors say. */ .propoffice-properties--version-3 .propoffice-pui-slider__pagination--windowed { --ppui-v3-dots-justify: flex-start; } /* * ...and an indicator the window cannot show whole is not drawn at all. * * The window is counted in whole indicators, but its box is whatever space the * chevrons leave, so the neighbours either side of the run it shows can still * reach into it - and a clipped neighbour is half a dot. `visibility` rather than * `display`, because the row's positions are what the window is worked out from: * a hidden indicator keeps its place, stops painting and stops taking clicks. */ .propoffice-properties--version-3 .propoffice-pui-slider__pagination .propoffice-pui-slider__bullet--outside { visibility: hidden; } .propoffice-properties--version-3 .propoffice-pui-slider__pagination .swiper-pagination-bullet { transform: translateX(var(--ppui-dot-shift, 0px)); /* * An indicator is its stated size or it is not an indicator. * * A single-line row is a flex row, and a flex item shrinks by default: with * more listings than the space between the chevrons could hold, the browser * quietly squeezed every dot instead of overflowing - six circles came out at * under 7px on a phone. Shrinking is the one thing the specification names as * forbidden, so the dots decline it. */ flex: 0 0 auto; transition: background-color 160ms ease; } /* ------------------------------------------------------------- Layout 1 */ /* * Layout 1 is the canonical composition described at the top of this file, and * everything above draws it. What remains here is the one thing that is Layout * 1's rather than Version 3's: it is the layout with no neighbours, so the * slider shows exactly one listing and the photograph runs the full width of * the component. * * The section is kept as a named place rather than removed so that a rule which * genuinely belongs to one layout has somewhere to go, and so the two layouts * stay legibly separate. */ .propoffice-pui-v3--layout-1 .propoffice-pui-slider__viewport { inline-size: 100%; } /* ------------------------------------------------------------- Layout 2 */ /* * The same markup, arranged differently. * * Layout 2 puts the current listing in the middle with the previous and next * listings peeking in beside it. Those neighbours are real slides - the shared * slider reveals them through a fractional slidesPerView - so nothing here * renders a preview. What this section does is make them read as neighbours * rather than as three equal panels: shorter, quieter, and without the * information panel, which belongs to the current listing alone. * * How far in the current photograph starts is a function of the preview amount * and nothing else. With p per cent revealed on each side the viewport holds * 100 + 2p per cent of a slide, so the current one begins at p / (100 + 2p) of * the width. That expression appears below wherever something has to sit inside * the current photograph rather than inside the viewport - which is what keeps * the arrows in the reference's position at any preview amount, instead of only * at the one the reference happened to use. * * Written as one flat expression on purpose. The readable version - a fraction * token divided into a second calc - is invalid: a division whose denominator * contains a var() resolves to nothing, the whole declaration is dropped at * computed-value time, and the rule underneath quietly wins. Nothing warns, and * the arrows simply appear somewhere else. */ .propoffice-properties--version-3.propoffice-pui-v3--layout-2 { --ppui-v3-current-inset: calc(100% * var(--ppui-v3-preview, 25) / (100 + 2 * var(--ppui-v3-preview, 25))); /* * The navigation box spans the viewport, and in this layout the viewport is * wider than the current photograph by the slice of each neighbour it shows. * A box of the picture's own ratio would therefore be too tall by exactly * that much, and the arrows would sit below the picture rather than on it - * so the ratio is widened by the same 100 + 2p the inset above divides by. */ --ppui-v3-nav-ratio: calc( var(--ppui-v3-frame-ratio, 1.89) * (100 + 2 * var(--ppui-v3-preview, 25)) / 100 ); /* * Outside arrows are Layout 1's arrangement. Layout 2's reference puts them * inside the current photograph, and the inset above is already reaching * further in than any gutter would reach out - so there is no gutter here, * and this is where that is said. * * It has to be said as the token rather than as a padding reset. Taking the * padding away on its own left the arrows still measuring from a gutter the * component no longer held: they went the width of one arrow past the * component's own sides and came to rest over the neighbouring listings, * which is the "arrows escaping the stage" this layout showed the moment an * editor chose Outside. Zeroing the token instead closes the padding, the * navigation row's inset, the dots' inset and the arrows' own edge together, * because all four read it. * * This declaration matches the outside variant's own selector on class count * and comes after it, which is what settles the two. */ --ppui-v3-arrows-gutter: 0px; --ppui-v3-arrow-reach: 0px; /* * The card is lifted to the top of the picture below, which is what gives the * navigation the foot of it back. * * It used to be centred, and in this layout that was the whole of the * collision: the photograph is narrowed to make room for the neighbours while * the card stays the same FRACTION of it, so the card is much narrower, its * words wrap into more lines, and its fit-content height grew to 107% of the * picture on the acceptance page - overhanging it at both ends, with the next * chevron drawn inside it. Anchored to the top with a stated margin, the card * ends where its content ends and the band beneath it belongs to the * navigation, which is the arrangement the reference draws. * * So there is no reserved column here: previous and next go back to the * picture's own edges, where the specification puts them. */ } /* * Layout 2's specified geometry: the chevrons 50px in from the sides of the * CURRENT photograph, and the dots on their line. The card's half of the * specification - the top of the picture, flush with its right edge - is the * rule after this one. * * On the ROOT, and that is the whole reason this rule is where it is. * `--ppui-v3-arrow-edge` and `--ppui-v3-arrow-slot` are composed on the root out * of the step, and a custom property is substituted where it is DECLARED, not * where it is used - so a step written on the slider arrived after both sums had * already frozen the root's 24px and moved nothing. The arrows stayed at 24px * while every token said 50. Setting the step on the same element the sums are * declared on is what makes them recompute. * * The step can be stated here because nothing Elementor writes is called that: * the Offset control writes `--ppui-v3-arrow-offset`, which Layout 1's step reads * and this one does not. These numbers are the specification's rather than the * panel's in this layout; Layout 1 goes on reading the control. */ .propoffice-properties.propoffice-properties--version-3.propoffice-pui-v3--layout-2 { --ppui-v3-arrow-step: 50px; } /* * Where Layout 2's card opens: 50px below the top of the picture, anchored there. * * Both numbers are the REGISTERED DEFAULTS of Layout 2's own Vertical Position and * Offsets, and that is the only way a placement reaches a real page. Elementor * writes every control - including a default nobody has touched - at * `.elementor-{doc} .elementor-element.elementor-element-{id} .propoffice-properties`, * four classes, and the tokens it writes there beat any declaration a stylesheet * makes of them. This layout used to declare the two tokens on the root at three * classes and lose: a render without Elementor's CSS drew the card 50px down, * and a published page drew it centred on Layout 1's defaults, with its lower * edge over the next chevron and, on a taller card, over the dots. * * So nothing here declares a token. This rule reads the same two tokens every * layout reads, Elementor's are the only declarations of them, and the fallbacks * are Layout 2's own numbers - the registered defaults - for a render with no * Elementor at all. */ .propoffice-properties--version-3.propoffice-pui-v3--layout-2 .propoffice-pui-v3__card { inset-block-start: var(--ppui-v3-card-offset-top, 50px); margin-block: var(--ppui-v3-card-align-y, 0 auto); } /* * The card stops above the navigation, and stops there by arithmetic. * * Anchored to the top with a stated margin, the card still ends wherever its own * words end - `block-size: fit-content` - and in this layout that was 5px into * the chevrons' band on the reference content and 36px into it on a listing with * four figures. The card is not allowed to move and the chevrons are placed by * the specification, so what is left is the height, and this is the cap. * * It is the picture's height less the three numbers that are already spoken for: * the margin above the card, the chevron's own box, and how far that box stands * off the foot. Nothing is measured and nothing is hard-coded - change the top * margin, the arrow size or the offset and the cap follows, because it is made of * them. The card's own bottom therefore lands exactly on the top of the tallest * thing in the navigation row. * * `overflow: hidden` is the other half, and it is what makes the cap real rather * than decorative: the panel's surface is drawn by an inner element sized to its * content, so a capped card that did not clip would have gone on painting white * over the chevron and nothing would have looked any different. What it takes off * is the panel's own bottom padding, which is proportional and generous - 16.5% * of the card's width, about 52px here - so the words are the last thing to feel * it rather than the first. */ @media (min-width: 1025px) { .propoffice-properties--version-3.propoffice-pui-v3--layout-2 .propoffice-pui-v3__card { max-block-size: calc( 100% - var(--ppui-v3-card-offset-top, 50px) - var(--ppui-v3-arrow-rise) - var(--ppui-nav-size, 56px) ); overflow: hidden; } } /* * The indicator's geometry, on the slider, because that is the element Elementor * writes the panel's Size and Spacing to. * * Size and Spacing arrive as tokens NO stylesheet declares - `--ppui-v3-dot-size` * and `--ppui-v3-dot-pitch` - and that is the whole of how the two controls work. * Elementor writes a control at * `.elementor-{doc} .elementor-element.elementor-element-{id} .propoffice-pui-slider`, * four classes, and it writes the registered default whether or not an editor * has touched the control. Declaring the same token here would be a contest this * file loses on every real page, which is exactly how this indicator measured * right in a bare render and was drawn at the registered 10px and 22px on a page. * With no declaration there is no contest - not with Elementor's weight, not with * the order the stylesheets load in, and not between the editor's preview and the * published page, which write the same token to the same element. The fallback in * each `var()` is for a render with no Elementor at all, and it agrees with the * registered default. * * The box is composed HERE rather than on the component root. A custom property * substitutes its `var()`s where it is declared, and the root is an ancestor of * the element Elementor writes to: composed there it would freeze at the fallback, * and the panel would move the gap but never the dots. */ .propoffice-properties--version-3 .propoffice-pui-slider { /* 8px + 2 * (2px + 1px) = 14px at the defaults: the square, and the circle. */ --ppui-v3-dot-box: calc( var(--ppui-v3-dot-size, 8px) + 2 * (var(--ppui-v3-dot-inset, 2px) + var(--ppui-v3-dot-ring-width, 1px)) ); /* * Swiper spaces its own bullets with a 4px margin either side, from * `.swiper-pagination-horizontal.swiper-pagination-bullets .swiper-pagination-bullet` * - three classes, which the shared stylesheet's `margin: 0` at two does not * beat. The dots came out 8px further apart than the number that spaced them. * Zeroing Swiper's own variable leaves the flex gap as the only thing spacing * them. */ --swiper-pagination-bullet-horizontal-gap: 0px; } /* * The neighbours are shorter than the current listing, and the difference is * proportional rather than a fixed number of pixels, so it survives the height * control being changed. * * The alignment is what makes that possible at all. Swiper's wrapper is a flex * row, and a flex row stretches its items to the tallest by default - so every * slide came out the same height however short the neighbours were asked to be, * and the rule below looked correct while doing nothing. Centring the row lets * each slide take its own height, and puts the shorter neighbours on the current * listing's centre line, which is where the reference has them. */ .propoffice-pui-v3--layout-2 .swiper-wrapper { align-items: center; } /* * A neighbour is drawn shorter by widening its aspect ratio, which is the one * expression that survives both ways of sizing the photograph: it holds when * the composition is running on its proportion, and the explicit height beside * it holds when an editor has set one. A neighbour shows no panel and has * nothing to grow for, so its height is stated and the media crops inside it. * * Written as a two-part ratio - `calc(...) / var(...)` - rather than as one * calc that divides. `aspect-ratio` takes a numerator and a denominator, and * either may be a var(); `calc()` may not divide BY one. The calc form parses, * resolves to nothing at computed-value time, is dropped in silence, and leaves * every neighbour at the current listing's full height with the Neighbour * Height control apparently doing nothing - which is exactly what it did until * the slash moved outside the calc. */ .propoffice-pui-v3--layout-2 .propoffice-pui-slider__slide .propoffice-pui-v3__media { aspect-ratio: calc(var(--ppui-v3-frame-ratio, 1.89) * 100) / var(--ppui-v3-preview-height, 70); block-size: var(--ppui-v3-neighbour-height, auto); transition: aspect-ratio 240ms ease; } .propoffice-pui-v3--layout-2 .swiper-slide-active .propoffice-pui-v3__media { aspect-ratio: var(--ppui-v3-frame-ratio, 1.89); block-size: var(--ppui-v3-frame-height, auto); } /* * The information panel belongs only to the current property. * * Hidden rather than omitted, because every slide carries the same markup - * that parity is what lets one renderer serve both layouts, and it is what a * test holds. Swiper moves the active class as the slider moves, so the panel * travels with the current listing without anything re-rendering. * * Before Swiper initialises there is no active slide, and every panel would * show. The container class Swiper adds on initialisation gates the whole rule, * so a page that never receives the library reads as a plain sequence of * listings with their panels - which is what the static mode looks like. */ .propoffice-pui-v3--layout-2 .swiper-initialized .propoffice-pui-slider__slide:not(.swiper-slide-active) .propoffice-pui-v3__card { opacity: 0; pointer-events: none; visibility: hidden; } .propoffice-pui-v3--layout-2 .propoffice-pui-slider__slide:not(.swiper-slide-active) .propoffice-pui-v3__media { filter: saturate(0.92); } /* * The chevrons and the dots need nothing said about them in this layout. * * Both are placed from --ppui-v3-current-inset, which this layout has already * set to the slice a neighbour is showing, so both move onto the current * photograph by themselves - and go on tracking it when the preview amount * changes, rather than at the one amount a rule here would have hard-coded. * * That absence is what makes "below" work here too. When this layout wrote the * dots' insets itself it did so at two classes, which outranked the single class * that lifts the row out of the picture, and the pair had to be undone again in * a third rule naming all three variants. Reading one token instead leaves the * position an editor chose in charge of the position. */ /* ------------------------------------------------------------ Responsive */ /* * A tablet keeps the composition and gives the panel more of the photograph. * * The reference's proportions are a desktop reading: at 900px the panel's 40% * is 360px of picture, and a title, a price, a row of figures and an agent do * not sit comfortably in it. Widening the panel and shortening the photograph * is a deliberate adaptation of the same design rather than a different one - * the panel still meets the right edge, still drops from the top, and the * navigation still shares its line. */ @media (max-width: 1024px) { .propoffice-properties--version-3 { --ppui-v3-frame-ratio: 1.6; } .propoffice-properties--version-3 .propoffice-pui-v3__card { inline-size: var(--ppui-panel-width, 48%); } /* * Layout 2's navigation moves BESIDE the card here, because there is nowhere * beneath it to go. * * A tablet narrows the picture twice over - this breakpoint shortens it to a * 1.6 proportion, and Layout 2 takes a third of its width for the neighbours - * so the picture is 296px tall while the card needs 241 of them. Capping the * card there does not trim padding, it cuts the agent's name off: measured at * 166px against 241, with the panel's whole 75px of padding gone and 26px of * content after it. So the cap stops at the desktop breakpoint and the * navigation steps sideways instead. * * The reserve is the card's own width, which this stylesheet already knows as * a fraction: the card is `--ppui-panel-width` of the PICTURE, and the picture * is 100 / (100 + 2p) of the row the arrows are placed against, so the card is * the product of the two. Written flat, because a division whose denominator * is a token resolves to nothing and takes the whole declaration with it. * * The step comes down with it. 50px is a desktop number, and after the reserve * there is about half the picture left: two 50px insets and two chevrons would * leave the dots 34px to stand in. */ .propoffice-properties.propoffice-properties--version-3.propoffice-pui-v3--layout-2 { --ppui-v3-arrow-step: 12px; --ppui-v3-card-reserve: calc( var(--ppui-panel-width, 48%) * 100 / (100 + 2 * var(--ppui-v3-preview, 25)) ); } } /* * A phone shows the information as a block beneath the photograph rather than a * panel over it. The shared width control already resolves to 100% at that * breakpoint; what changes here is composition - the panel returns to the * frame's flow and takes a row of its own, so a tall panel no longer covers the * picture it belongs to. * * This is the one breakpoint where the panel is not positioned, and every * property that positioned it has to be given back: an absolutely positioned * box with `inset-block-start: 8%` does not become a block by being told its * width is 100%. */ @media (max-width: 767px) { /* * A taller crop, because a 1.89 landscape strip is a band on a phone. * * The ratio is the only thing the photograph needs told: the media reads it, * and so does the box the navigation is laid out against, so narrowing it * here moves the picture and the chevrons and the dots together. The height * control is deliberately not restated - it writes the same token at every * breakpoint, and a mobile-only alias here would shadow the mobile value an * editor had set. */ .propoffice-properties--version-3 { --ppui-v3-frame-ratio: 1.4; } /* * Everything that positioned the card is given back together. * * An absolutely positioned box does not become a block by being told its * width is 100%: its insets, its margins and its fitted height all have to * return to their flow values in one place, or the card stays a layer over a * photograph it is supposed to be underneath. * * Behind the placement class now, because a phone has two answers to this and * an editor picks one. Layout 1 always carries `below` and is therefore * unchanged by the addition; Layout 2 carries whichever its control holds. */ .propoffice-properties--version-3.propoffice-pui-v3--mobile-card-below .propoffice-pui-v3__card { block-size: auto; inline-size: 100%; inset: auto; margin: 0; position: static; } /* * The stylesheet has to be told the neighbours have gone, or it goes on * laying the navigation out around them. * * The renderer stands them down for a phone showing the card inside the * photograph by giving Swiper one full slide there. The preview amount is also * what the navigation is laid out from - it widens the row's ratio and insets * the chevrons and the dots to the current picture - and left at 25 the two * disagreed: Swiper drew a full-width photograph, the stylesheet placed the * navigation for one two thirds as wide, and the chevrons and every dot came to * rest on the card. * * So the renderer says so with `--mobile-preview-none`, worked out from the * settings it hands Swiper, and this restates the two terms the preview feeds: * no neighbour's slice to step in from, and a row of the photograph's own * shape. Those two and not the preview amount itself, because Adjacent Property * Preview writes that token on the root at four classes - its registered 25, on * every page - and the zero this stylesheet used to declare lost to it: * measured, the chevrons stood 90px above the picture's foot and 66px in from * its sides. Nothing writes the two terms but this file. A preview an editor * does set for a phone still reaches the navigation, because the renderer then * leaves the class off and Elementor's phone value is the one Swiper was given. */ .propoffice-properties--version-3.propoffice-pui-v3--layout-2.propoffice-pui-v3--mobile-preview-none { --ppui-v3-current-inset: 0px; --ppui-v3-nav-ratio: var(--ppui-v3-frame-ratio, 1.4); } /* * ...and the other answer: the card stays the layer it is on a desktop. * * Only three things have to change to bring that composition down to a phone, * and all three are proportions rather than a new arrangement. The card takes * most of the picture's width, because forty per cent of a photograph that is * itself a third of a 375px screen is eighty pixels and no card. It comes down * off the top by a phone-sized margin rather than the desktop's fifty. And it * is capped clear of the navigation exactly as the desktop card is, out of the * same three numbers - the margin above it, the chevron's box, and how far * that box stands off the foot - so the arrows and the dots keep the band they * sit in. * * The margin is stated as the inset rather than as the Offsets token, so the * panel's top offset stands down on a phone without this file declaring a * token the panel writes. */ .propoffice-properties--version-3.propoffice-pui-v3--mobile-card-inside .propoffice-pui-v3__card { inline-size: var(--ppui-v3-mobile-card-width, 86%); inset-block-start: var(--ppui-v3-mobile-card-top, 12px); /* * The cap takes the navigation's band and no more. A phone has 234px of * picture and the panel wants 194 of them, so the margin between them is * the panel's own padding and nothing else: asking for a further gap * below the card cost 8px of the agent's name, measured. The card's foot * therefore lands on the top of the chevron's box, which is clear of it * without being clear of it by anything. */ max-block-size: calc( 100% - var(--ppui-v3-mobile-card-top, 12px) - var(--ppui-v3-arrow-rise) - var(--ppui-nav-size, 40px) ); overflow: hidden; } /* * Proportional padding is a panel-over-a-photograph decision. Full width on * a phone it would be 15% of 375px of vertical air, so the block returns to * a stated rhythm. */ .propoffice-properties--version-3 .propoffice-pui-v3__card-inner { padding: var(--ppui-panel-pad, 1.75rem 1.5rem); } /* * The navigation follows the PHOTOGRAPH, and on a phone the photograph is no * longer the whole component: the panel is beneath it, so the slider's own * lower edge is somewhere under the agent's name. * * Both navigation layers are therefore given the photograph's own box - the * full width, anchored to the top, with the composition's aspect ratio - and * everything inside them goes on being placed from its foot exactly as it is * on desktop. Nothing has to know how tall the picture is, because a box the * same width with the same ratio IS that height, at any width and inside any * column. * * This is what replaced a `100vw / ratio` calculation. That expression is * right only where the component is the viewport: a widget in a padded * Elementor section is narrower than 100vw, so the arrows sat below the * picture by exactly the section's padding - correct in a full-bleed preview * and wrong on every real page. */ /* * Smaller chevrons, because at 56px each they would cover a third of a * phone-width picture between them. Stated as a token here AND as the * control's own mobile default, because Elementor prints a registered * default at {{WRAPPER}} specificity that no media query in a stylesheet can * beat - a rule here alone would preview correctly and do nothing on a page. */ .propoffice-properties--version-3 .propoffice-pui-slider { --ppui-nav-size: 40px; } /* * Only the step changes: how far in from its edge a chevron sits. Which edge * that is stays the layout's answer, so a phone showing neighbours keeps its * arrows on the current photograph without this breakpoint knowing there are * neighbours. */ .propoffice-properties--version-3 { --ppui-v3-arrow-rise: var(--ppui-v3-arrow-offset-mobile, 12px); --ppui-v3-arrow-step: var(--ppui-v3-arrow-offset-mobile, 12px); } /* * Layout 2's specified 50px is a desktop number: on a phone-width picture two * of them plus two chevrons is most of the width, and there would be nothing * left between them to put the dots in. Restated on the same element at the * same three classes, and later in the file, which is what settles the two - * a media query carries no specificity of its own. */ .propoffice-properties.propoffice-properties--version-3.propoffice-pui-v3--layout-2 { --ppui-v3-arrow-step: var(--ppui-v3-arrow-offset-mobile, 12px); /* * ...and no column to keep out of: a phone puts the card in normal flow * BENEATH the picture, so the whole width of it is the navigation's again. */ --ppui-v3-card-reserve: 0px; } /* * There is no room beside a phone-width picture to stand an arrow in, so the * outside arrangement has no gutter here either. Matching that variant's own * selector on class count and coming after it is what settles the two - a * media query adds no specificity of its own. */ .propoffice-properties--version-3.propoffice-pui-v3--arrows-outside { --ppui-v3-arrows-gutter: 0px; --ppui-v3-arrow-reach: 0px; } /* * The navigation needs nothing said about it at this breakpoint. * * Both layers are laid out against the photograph's own box, and the ratio * that box is drawn at is a token this breakpoint has already narrowed - so * the arrows and the dots follow the picture onto a phone by themselves, * including the part where the picture stops being the foot of the component * because the panel is underneath it. What is left is the lift, which is a * different number here because the arrows are. */ .propoffice-properties--version-3 { --ppui-v3-dots-lift: var(--ppui-v3-arrow-offset-mobile, 12px); } /* * The panel sits below the photograph on a phone, in both layouts, so a * neighbour's shortened proportion has nothing to be shorter than. */ .propoffice-pui-v3--layout-2 .propoffice-pui-slider__slide .propoffice-pui-v3__media, .propoffice-pui-v3--layout-2 .swiper-slide-active .propoffice-pui-v3__media { aspect-ratio: var(--ppui-v3-frame-ratio, 1.4); } /* * ...and with nothing shorter to centre, the centring has to go, because the * navigation is anchored to the top of the slider and a centred row moves the * photograph off it. * * On desktop this row is centred so a shortened neighbour sits on the current * listing's centre line. Here the panel is in normal flow beneath each * picture, so a slide is as tall as its own listing's words - and the tallest * of them sets the row's height while the current one is centred inside it. * The photograph then starts half that difference below the slider's top, * taking the picture away from the box the chevrons and the dots are placed * against: on the reference content that was 48px, which put both of them a * long way above the foot of a picture they are supposed to be sitting on, * and by an amount that changed with whichever listing had the longest title. * * Top-aligned, every photograph starts where the slider does, which is where * the navigation already starts. */ .propoffice-pui-v3--layout-2 .swiper-wrapper { align-items: flex-start; } } /* --------------------------------------------------------------- Motion */ @media (prefers-reduced-motion: reduce) { .propoffice-properties--version-3 .propoffice-pui-v3__cta, .propoffice-properties--version-3 .propoffice-pui-slider__arrow, .propoffice-properties--version-3 .propoffice-pui-slider__pagination .swiper-pagination-bullet { transition: none; } }