/* =========================================================================== projects-list.css — the Showcase / Grid view switch for the projects band. Status: shipped, every master community. `emaar-community.html?c=`, all sixteen of them. It began as a Dubai Creek Harbour pilot gated on that slug; the gate is gone from projects-list.js and the rules below now match wherever that script writes `data-em-pv`, which is every community page with a properties band on it. The portfolio runs from 43 projects to 1, and nothing here counts. The two compositions are set by the MEASURE the band has, not by how many cards are in it: a community of one gets the same Showcase entry as a community of forty-three, reading "01 / 01" above it. WHAT THIS IS, AND WHAT IT IS NOT -------------------------------- It is NOT a second listing. There is one grid, one card per project, one set of images, one filter state — `.em-pf__grid` and `.em-pc`, built by places-pages.js from community-projects.js. This file gives that ONE set of elements a second presentation, chosen by `data-em-pv` on the band: data-em-pv="grid" the approved three-up grid. The card's LAYOUT is places.css's, untouched; the only thing this file gives it is the action ladder (§8). data-em-pv="showcase" one entry per SCREEN, in the delivered-projects chapter's composition (emaar-completed.html — see .ll-band in launches.css): an index above the name, the photograph taking nearly two thirds of the band and alternating side down the page. The largest the work is shown anywhere on this site. TWO VIEWS. List and Split were here and are gone — the same entry at two smaller measures, which made a three-position control out of one real choice. What is left is that choice: ONE project given the screen, or ALL of them given a wall. Showcase is now the default. Showcase alone carries `data-em-pl`, and every rule about the ENTRY — the eyebrow, the marks, the editorial type — is written against that scope. The rules that decide how many columns the band has, and which side of the row the photograph sits on, read `data-em-pv` itself. The ACTION LADDER is the exception and is written against the bare `[data-em-pv]`, because both views now use it. That is why switching views cannot lose a filter, a search, a bedroom selection or a Load-more: nothing is rebuilt, nothing is re-fetched, no image is requested twice, and the enquire / floor-plan delegates keep the same nodes they were bound to. It is the house's own instinct, the one ledge-bar.css already states — TWO PRESENTATIONS, ONE ELEMENT. DESIGN-STANDARDS.md §2 — one component, one definition ------------------------------------------------------- §2 forbids a HOST PAGE restyling a shared component from its own stylesheet, because two hosts then disagree about one component. Nothing here can cause that disagreement: every rule that touches `.em-pf__grid`, `.em-pc` or their parts is scoped inside `[data-em-pl]` or `[data-em-pv]`, two attributes that exist only where this file's own script put them. A page that does not load this pair of files has no scope for these rules to match — and the community template is the only page that loads them. Same contract as community-bar.css, and the same exit: delete the two lines from emaar-community.html and the page is byte-for-byte what it was. THE IMAGE RATIO IS NOT NEGOTIATED HERE --------------------------------------- The photograph keeps `.em-shot--16x10` — `--em-ratio-landscape`, "THE default photograph on this site" (04-layout.css §12). The list does not re-crop it, does not letterbox it and does not ask for a second file. It is the same ``, with the same `srcset`, made larger by being given more of the row. Measured at 1440: grid 382.9 x 239.3, showcase 750 x 469 — 3.84x the area, the same 1.6 ratio, the same bytes on the wire. Showcase is the widest column any view here gives the photograph, and it is still the same ``, the same `srcset` and the same `sizes` that places-pages.js wrote at render. No candidate is re-requested when the view changes, because none of the four views changes what the browser was asked for. The file's own measurements are in section 7; if a future record ever ships a larger original, this is the view that would use it. --------------------------------------------------------------------------- */ /* ———————————————————————— 1 · The view switch ———————————————————————— It rides the count line, directly above what it controls, which is the only row in the band that is about the SET rather than about the filter. The filter bar answers "which projects"; this answers "how they are shown", and putting it in the filter bar would have taken its width from the search field at every viewport. The control is the band's own segmented control — .em-pf__seg's geometry, type, tracking and selected plate, restated here rather than borrowed, because one component must not reach into another it happens to resemble. Two states, mutually exclusive, one always on: that is still a segment, and DESIGN-STANDARDS §8 says the shape carries the behaviour. They sit LARGEST FIRST — Showcase, then Grid — because that is the one thing the two positions differ by: how much of the band one project gets. Showcase is on the front of the control, and it is what the band opens on. SHOWCASE stays on the control below 1024 even though it stacks there. It is not a lie: the grid is one-up on a phone too, and a control that disappears at a width is a control the reader cannot find again. */ .em-pv { display: flex; align-items: center; justify-content: space-between; flex-wrap: wrap; gap: 12px 20px; margin-top: 16px; /* the count's own margin, moved up here */ } .em-pv > .em-pf__count { margin-top: 0; } .em-pv__seg { display: flex; flex: none; margin-left: auto; border: 1px solid var(--em-line-ctl); border-radius: var(--em-r); overflow: hidden; background: var(--em-surface); } .em-pv__b { display: inline-flex; align-items: center; gap: 8px; white-space: nowrap; padding: 11px 16px; min-height: var(--em-control-min); border: 0; background: none; cursor: pointer; font: inherit; font-size: 11px; font-weight: 600; letter-spacing: .14em; text-transform: uppercase; color: var(--em-ink-body); transition: background var(--em-t) ease, color var(--em-t) ease; } .em-pv__b + .em-pv__b { border-left: 1px solid var(--em-line-ctl); } .em-pv__b:hover { background: rgba(var(--em-rgb-ink), .04); color: var(--em-ink); } .em-pv__b[aria-pressed="true"] { background: var(--em-ink); color: var(--em-on-ink); } /* The glyph is a second signal, never the only one: the word LIST or GRID is on the button at every viewport, and the selected plate is the third. DESIGN-STANDARDS §8, and the brief's own accessibility line. */ .em-pv__i { width: 15px; height: 15px; flex: none; } @media (max-width: 599px) { /* Below 600 the count and the labels will not share a line — at 390 the count measures 152px and the switch 182px against a 350px column. The switch takes the row and stays a 44px target. 600 because that is the ladder's phone step, and because it is the width at which places.css already narrows this card's buttons. */ .em-pv__seg { margin-left: 0; flex: 1 1 100%; flex-wrap: wrap; } .em-pv__b { justify-content: center; padding: 11px 6px; font-size: 10px; letter-spacing: .08em; gap: 5px; } /* FOUR across a 320px card is 70px a button, and SHOWCASE alone asks for 62px of label before its glyph. So the fourth position wraps the row rather than squeezing it: two and two, each half the card, each still a 44px target. The WORD is what states the behaviour and it stays, at full size, at every width — which is the thing that could not be given up, and the reason the row wraps instead. The wrap also costs the seam a border: .em-pv__b + .em-pv__b draws a left edge on every button but the first, which on a second line draws one hanging at its start. The bottom row's first button takes it back and the two rows are separated by a top edge instead. */ .em-pv__b { flex: 1 1 50%; } .em-pv__b:nth-child(3) { border-left: 0; } .em-pv__b:nth-child(n+3) { border-top: 1px solid var(--em-line-ctl); } .em-pv__i { width: 14px; height: 14px; } } /* ——————————————————— 2 · Parts that exist only in the list ——————————————————— projects-list.js adds a handful of small things to each card ONCE, at boot: an index, a status eyebrow, three marks, the break in the action ladder and the arrow on Explore. All of them are display:none here and are switched back on by the scope that wants them — the eyebrow and the marks inside the list scope, the index inside Showcase alone, and the last two inside BOTH views, because the ladder is both views' now (§3, §8). A display:none element contributes no box, no gap and no flex basis, so anything a view does not ask for costs it nothing at all. */ .em-pl__n, .em-pl__eyebrow, .em-pl__i, .em-pl-br, .em-pc__explore > .em-cta__a { display: none; } /* ———————————————————————— 3 · The list ———————————————————————— One column of rows. The gap is the band's own rhythm, opened up: a list row is read as an entry, not as a tile in a wall, and it needs air on both sides of it to read that way. */ [data-em-pl] .em-pf__grid { grid-template-columns: 1fr; gap: clamp(34px, 3.6vw, 52px); } /* The entry, in its NARROW form: picture, then words under it. This is what both views fall back to — the list below 1024, and the split everywhere, because a split column is never wide enough to seat the words beside the picture. It is written first and the wide form overrides it at 1024, so the one composition that has to work in a 280px column is the one that needs no media query to get there. */ [data-em-pl] .em-pc { display: grid; grid-template-columns: 1fr; row-gap: 18px; align-items: start; /* stacked: centring has nothing to centre */ } /* ——— the photograph ——— Same element, same ratio, same file. The only thing this rule does is let it have the column. */ [data-em-pl] .em-pc__pic, [data-em-pl] .em-pc__body { grid-column: 1; } /* The status plate comes OFF the photograph in this view and is said in words at the head of the entry instead (see .em-pl__eyebrow below). One fact, one place: a large photograph carries a plate badly, and the entry's first line is where a reader scanning a list looks for it. Nothing is lost — the eyebrow is built from the badge's own text. */ [data-em-pl] .em-badge { display: none; } /* ——— the words ——— */ [data-em-pl] .em-pc__body { padding-top: 0; display: block; /* no bottom-pinning: a list row is independent of its neighbours, so nothing needs to line up across the row the way three grid cards do */ } [data-em-pl] .em-pl__eyebrow { display: flex; align-items: center; gap: 9px; font-size: 10.5px; font-weight: 600; letter-spacing: .20em; text-transform: uppercase; color: var(--em-ink-eyebrow); margin-bottom: 13px; } /* 6px of metal. DESIGN-STANDARDS §1 — gold is an accent and never a fill; a mark this size is the accent, and places-ui.js says the same of its own engravings. The plate's sand dot would be invisible on cream, so the light ground gets its own pair. */ .em-pl__dot { width: 6px; height: 6px; border-radius: 50%; flex: none; background: var(--em-accent); } .em-pl__dot--explore { background: transparent; border: 1px solid var(--em-ink-mute); } /* The system's own h3 step — clamp(23px, 2.3vw, 31px) — not a hand-cut clamp, so this heading tracks the scale everywhere and needs no size of its own at any breakpoint. Against the grid card's clamp(19px,1.5vw,22px) it is 31px to 21.6px at 1440: the editorial step the list is for. */ [data-em-pl] .em-pc__name { font-size: var(--em-text-h3); line-height: 1.1; } /* A short rule under the name, the same hairline the eyebrow component draws. It is the entry's own floor and it is what makes the block read as editorial rather than as a stretched card. */ [data-em-pl] .em-pc__name::after { content: ''; display: block; width: 54px; height: 1px; background: var(--em-line-rule); margin-top: 17px; } /* ——— the marks ——— places-ui.js's construction exactly: 24-unit grid, 1.1 stroke, round caps, currentColor, no fills. One weight, one grid — a bed beside a bedroom count reads as the same engraving a golf course does. The three facts EMAAR publishes beside its OWN icons on the source listing are the bedroom string, the price and the unit count (see the provenance note at the head of community-projects.js). This view marks those three and invents no fourth. */ [data-em-pl] .em-pl__i { display: inline-block; width: 16px; height: 16px; flex: none; color: var(--em-ink-mute); vertical-align: -3px; } [data-em-pl] .em-pc__meta { display: flex; align-items: center; gap: 9px; font-size: 13.5px; color: var(--em-ink-body); margin-top: 16px; } /* The price line loses the grid card's rule and auto-margin — both of those exist to align three cards ACROSS a row, and there is no row here. */ [data-em-pl] .em-pc__facts { margin-top: 13px; padding-top: 0; border-top: 0; gap: 6px 20px; } [data-em-pl] .em-pc__price { display: inline-flex; align-items: center; gap: 9px; font-size: 19px; } [data-em-pl] .em-pc__units { display: inline-flex; align-items: center; gap: 8px; font-size: 12.5px; } /* ——— the actions ——— The same four, in the same order, with the same labels and the same destinations. What changes is their WEIGHT. The quad gave all four the same box because three tiles abreast have no room to say anything else; read down a band, that reads as four equal offers on every card of every community, and the eye has to price each one afresh. So both views spend the register 05-components.css already publishes: Book Now .em-btn PRIMARY — the transaction. One per entry. Explore .em-btn-o SECONDARY — the destination. A real alternative. Enquire text — a form, opened here. Floor Plans text — a drawer, opened here. Neither box changes style, label or destination; they stop being stretched to the column and are sized to their words, which is what makes two boxes look like two boxes rather than a block. The two utilities keep their 44px target, their uppercase label voice and their hairline — the hairline just moves from around them to under them. Note what stays a box and why: .em-cta is the system's text link and its contract is that it NAVIGATES. Enquire and Floor Plans act on this page, so they are not given that class — they are quiet buttons, and now that this ships site-wide the tier belongs in 05-components.css under its own name. That is the one thing still owed on this file. */ [data-em-pl] .em-pc__acts { display: flex; flex-wrap: wrap; align-items: center; column-gap: 12px; row-gap: 0; margin-top: 24px; padding-top: 0; max-width: none; } /* The two boxes come back to the SYSTEM's own button. places.css compresses every button in this card — 11px/16px padding at 10.5px type — because a grid tile is 383px wide and has to seat two of them in half of that. A list row does not: the entry's measure is 473px at 1440 and the button was reading as a smaller component's button. So the list restores 05-components.css's own numbers (11px label, 12px/20px on the primary, 12px/24px on the secondary) and puts a floor under the width, so the pair holds the head of the actions block instead of sitting in the corner of it. Nothing about the button is invented: only the grid's compression is lifted. 176px is the widest floor the ladder allows. At 1024 the words' column is 371px, and 176 + 12 + 176 = 364 — the pair stays on one line at every width it is a pair at. */ [data-em-pl] .em-pc__acts .em-btn, [data-em-pl] .em-pc__acts .em-btn-o { flex: 0 0 auto; min-width: 176px; font-size: var(--em-text-label); padding: 12px var(--em-button-padding-x); } [data-em-pl] .em-pc__acts .em-btn-o { padding: 12px 24px; } /* ——— from here to the end of the section, the ladder is BOTH views' ——— Written against the bare `[data-em-pv]` and not against `[data-em-pl]`: the register of an action is a fact about the action, not about the measure the entry is set at, and a reader who switches views should not find Enquire weighted one way on the left of the control and another on the right. Only the numbers below — the floor under the two boxes, the size of the break — are per-view, and those are in §7 and §8 where the measures are. */ [data-em-pv] .em-pc__explore > .em-cta__a { display: inline; } /* the break between the two registers — one line, no furniture. It is what makes the wrap DETERMINISTIC: the utilities cannot ride up beside a box on a card that has no Book Now, which is the reflow places.css rejected the flex quad for by name. */ [data-em-pv] .em-pc__acts .em-pl-br { display: block; flex: 0 0 100%; height: 14px; } /* the quiet pair */ [data-em-pv] .em-pc__enquire, [data-em-pv] .em-pc__acts .em-plans-btn { flex: 0 0 auto; display: inline-flex; align-items: center; gap: 8px; background: none; border: 0; border-radius: 0; padding: 0; min-height: var(--em-control-min); color: var(--em-ink-body); font-size: 10.5px; letter-spacing: .14em; transition: color var(--em-t) ease; } [data-em-pv] .em-pc__acts .em-plans-btn { margin-left: 26px; } [data-em-pv] .em-pc__acts .em-plans-btn svg { width: 14px; height: 14px; color: var(--em-ink-mute); } /* the words carry the rule, so it sits on the label and not at the foot of the target — the same 1px, 3px clear, that .em-cta__l has always used */ [data-em-pv] .em-pl-l { border-bottom: 1px solid var(--em-line-ctl); padding-bottom: 3px; transition: border-color var(--em-t) ease; } [data-em-pv] .em-pc__enquire:hover, [data-em-pv] .em-pc__acts .em-plans-btn:hover { background: none; border-color: transparent; color: var(--em-ink); } [data-em-pv] .em-pc__enquire:hover .em-pl-l, [data-em-pv] .em-pc__acts .em-plans-btn:hover .em-pl-l { border-bottom-color: currentColor; } /* ———————————————————————— 4 · Hover ———————————————————————— Restrained on purpose, and the card's OWN language: the photograph's scale(1.04) is places.css §.em-pc and already applies here, unchanged, so the two views hover identically. The arrow is the only thing added, and it is the .em-cta__a transform the system has always used — 4px, one duration, one curve. No lift, no shadow, no card movement. */ [data-em-pv] .em-pc:hover .em-pc__explore > .em-cta__a { transform: translateX(4px); } /* ———————————————————————— 5 · The switch itself ———————————————————————— A 240ms fade-and-settle on the container, so the reader sees that the LAYOUT changed rather than wondering whether the set did. Transform and opacity only — nothing that can move the page or cost a reflow — and it is off entirely under reduce, where the swap is instant. */ @media (prefers-reduced-motion: no-preference) { [data-em-pv] .em-pf__grid.is-pv-swap { animation: em-pv-swap 240ms var(--em-e-soft) both; } @keyframes em-pv-swap { from { opacity: 0; transform: translateY(7px); } to { opacity: 1; transform: none; } } } /* ———————————————————————— 6 · Narrower ———————————————————————— Showcase's two compositions, each chosen against what the GRID is already doing at that width — a view that is not visibly bigger than the grid beside it has no reason to exist. 1024 and up Two columns, the photograph in the larger one: 750 x 469 at 1440 against the grid's 383 x 239, and 589 x 368 at 1024 against the grid's 461 x 288. The narrowest desktop case is the one that sets the ratio, because that is where the grid's own cards are biggest. §7 draws it. 1023 and down it stacks and the picture takes the whole measure — 707px at 768, against the grid's 344px. There is no second column to put the words in below 1024, which is what "desktop measure" means for this view. Only 599/600, 1023/1024 and 1439/1440 are on this build's breakpoint ladder (tools/ds_check.py). Two of them are enough for this view. */ @media (max-width: 1023px) { [data-em-pl] .em-pf__grid { gap: clamp(38px, 5vw, 48px); } } @media (max-width: 599px) { /* On a phone the grid is ALREADY one-up and full-measure, so no list layout can make the picture larger — it is the same width in both views, by arithmetic, and §20 asks only that the ratio hold, which it does: the same .em-shot--16x10, the same file, the same bytes. What the list gives a phone is the HIERARCHY — the status said in words above the name, a rule under it, the three marked facts, and the price at editorial size rather than folded into a row of small print. */ [data-em-pl] .em-pc__meta { font-size: 13px; margin-top: 14px; } [data-em-pl] .em-pc__price { font-size: 17px; } [data-em-pl] .em-pc__name::after { margin-top: 14px; width: 46px; } [data-em-pl] .em-pl__i { width: 15px; height: 15px; } [data-em-pl] .em-pc__acts { margin-top: 20px; } /* The pair still fits side by side at 320: places.css already spends less air either side of a button below 600, and the two labels together ask for 194 of the 280px the card has. The utilities keep their own line and close up a little, the whole point being that they no longer cost a second row of full-width bars on a phone. */ [data-em-pv] .em-pc__acts .em-pl-br { height: 12px; } [data-em-pv] .em-pc__acts .em-plans-btn { margin-left: 20px; } /* Below 600 the floor would be wider than half the card, so the pair shares the row instead — the halves the grid's own ladder gives them (§8), at this view's type size. A card with nothing to book keeps the whole measure for Explore, exactly as .em-acts--nobook used to. */ [data-em-pl] .em-pc__acts .em-btn, [data-em-pl] .em-pc__acts .em-btn-o { flex: 1 1 0; min-width: 0; padding-left: 12px; padding-right: 12px; } [data-em-pl] .em-pf__grid { gap: 40px; } } /* ———————————————————————— 7 · Showcase ———————————————————————— The delivered-projects chapter, brought to this band. launches.css §7 draws it for emaar-completed.html — an index, an eyebrow, the name at the h2 step, and ONE photograph on the page ground beside the words, its side alternating down the page. Everything below is that composition. The three places it departs from `.ll-band` each say why they do. WHAT IT DOES NOT BORROW, AND WHY NOT ------------------------------------- That chapter also carries a tagline, three paragraphs of Emaar's own prose, an amenity row and a handover film. This band has none of the four. community-projects.js publishes a name, a bedroom string, a price, a unit count and one photograph per project — that is the whole record — and most of the portfolio has no prose entry anywhere in this build (twenty-two of Dubai Creek Harbour's forty-one alone). Writing the paragraph would be writing Emaar's copy for it; showing the amenity row only for the projects that have one would make every other project read as the lesser of the pair — and that ratio is worse, not better, on the communities with more projects than Creek Harbour. So the words column carries what the card has always carried, at the editorial size, and the room the prose would have taken went to the photograph instead — which is the whole of what this view is for. THE PHOTOGRAPH, WHICH IS THE POINT ----------------------------------- It gets 1.85 of the row's 2.85 parts. Measured, not estimated: 1440 1280 1024 showcase 750 x 469 736 x 460 589 x 368 list 686 x 429 673 x 420 538 x 336 split 584 x 365 572 x 358 458 x 286 grid 383 x 239 375 x 235 461 x 288 3.84x the grid's area at 1440 and 1.20x the list's, at the one ratio the site has (--em-ratio-landscape, 04-layout.css §12). It is the same ``, the same `srcset` and the same `sizes` places-pages.js wrote at render — the view is bigger, the request is not, and switching views re-requests nothing. At 1440/2x the browser takes the 1200w candidate and draws it at 750 CSS px; the largest original on disk is 1620w, so if this view is approved for every community, `sizes` is the one line worth revisiting, and it belongs in places-pages.js beside the render, not here. 1.85 is a FLOOR ON THE WORDS, not a ceiling on the picture. The binding case is 1024, the narrowest width this two-column form is used at: the words get 318px there, and the action ladder's first line is two boxes at 144 + 12 + 144 = 300 of it. Give the photograph more and that pair breaks to two rows. That is what sets the ratio — nothing about the number is aesthetic. */ [data-em-pv="showcase"] .em-pf__grid { grid-template-columns: 1fr; /* .ll-done + .ll-done's own rhythm. One entry is meant to hold the screen, so the next one is kept off it. */ gap: clamp(56px, 7vw, 104px); } /* ——— the index ——— `.ll-band__n` to the property: display face, 13px, tracked, tabular so the figures do not shuffle as the filter renumbers them. It is the only part of the card that belongs to Showcase alone, which is why §2 hides it and only this scope brings it back. It says "03 / 11" where eleven is what the filter has left on screen, not "03 / 41" — the number is where you are in what you are looking at. See number() in projects-list.js for why that is read from the DOM rather than counted by :nth-child(). */ [data-em-pv="showcase"] .em-pl__n { display: block; font-family: var(--em-display); font-size: 13px; letter-spacing: .12em; color: var(--em-ink-mute); font-variant-numeric: tabular-nums; margin-bottom: 15px; } /* ——— the eyebrow ——— `.ll-band__area` draws an 18px rule before its words. This eyebrow already carries a mark before its words — the status dot, which is a FACT (gold for available, outline for open to explore) where the rule is only furniture. Two markers on one line is one too many, so the dot keeps the position and the rule is not drawn. The line otherwise sets exactly as .ll-band__area: 10.5px, 600, .20em, uppercase, on --em-ink-eyebrow. */ /* ——— the name ——— The system's own h2 step, as the chapter's heading uses. Against the list's h3 that is 42px to 31px at 1440 — the size difference is most of what tells a reader at a glance which of the two views they are in. The rule beneath it lengthens with it. */ [data-em-pv="showcase"] .em-pc__name { font-size: var(--em-text-h2); } [data-em-pv="showcase"] .em-pc__name::after { width: 72px; margin-top: 20px; } @media (min-width: 1024px) { /* Two columns, the picture in the larger one, and `align-items: center` rather than stretch — the .ll-band composition exactly, and the same one the list uses. A name that wraps to three lines grows past the picture and the picture centres against it; neither column is ever stretched to the other, so nothing floats in a gap. 1024 for the same reason the list stops there: below it, a two-column entry has no column to put the actions in. */ [data-em-pv="showcase"] .em-pc { grid-template-columns: minmax(0, 1.85fr) minmax(0, 1fr); column-gap: clamp(30px, 3.4vw, 54px); row-gap: 0; align-items: center; } [data-em-pv="showcase"] .em-pc__pic { grid-column: 1; grid-row: 1; } [data-em-pv="showcase"] .em-pc__body { grid-column: 2; grid-row: 1; } /* The alternation. `data-em-alt` is written by projects-list.js over the cards that are VISIBLE, so the zigzag survives a search, a segment, a bedroom filter and Load more — :nth-child() would have counted the hidden ones and put two pictures running on the same side. The TRACKS swap with the picture, not just the columns. launches.css learned this the hard way and says so: leave the wide track on the left and a flipped entry renders its photograph into the narrow one, so alternating the side silently alternates the size and every second project reads as the lesser of the pair. The picture keeps its weight; only the side changes. */ [data-em-pv="showcase"] .em-pc[data-em-alt="1"] { grid-template-columns: minmax(0, 1fr) minmax(0, 1.85fr); } [data-em-pv="showcase"] .em-pc[data-em-alt="1"] .em-pc__pic { grid-column: 2; } [data-em-pv="showcase"] .em-pc[data-em-alt="1"] .em-pc__body { grid-column: 1; } /* The action ladder is the list's, unchanged in register, label, order and destination. Only the FLOOR under the two boxes moves: 176px is what the list's 1.45fr column can seat a pair in, and this column is narrower by design — 406px at 1440, 318px at 1024 — because the photograph took the difference. 144px is the floor that pair fits in at 1024 (144 + 12 + 144 = 300 of 318, measured) and it is still above the 139px FLOOR PLANS asks for above 600. `flex: 0 0 auto` is kept from the list, so a project with nothing to book leaves Explore at its own width instead of stretching one lone button across the column. */ [data-em-pv="showcase"] .em-pc__acts .em-btn, [data-em-pv="showcase"] .em-pc__acts .em-btn-o { min-width: 144px; } } /* ———————————————————————— 8 · The grid's action ladder ———————————————————————— The grid's LAYOUT is not this file's business and is not touched: the tile, the photograph, the badge, the name, the price row and the bottom-pinned actions block are all places.css's, exactly as they were. The one thing that changes is which REGISTER each of the four actions is in, and it changes for the reason §3 gives: Book Now .em-btn PRIMARY — the transaction. One per card. Explore .em-btn-o SECONDARY — the destination. A real alternative. Enquire text — a form, opened here. Floor Plans text — a drawer, opened here. places.css's `.em-acts--quad` gave all four the same box because three tiles abreast have no room to say anything else. Forty-one tiles of four equal offers is a menu, and the reader prices each one afresh every time. Sorting them is the same edit the other view already made, so the two views now weight the same action the same way — which is the whole reason it is here and not left as a Showcase-only refinement. §3 already published the register, the underline, the hover and the arrow against the bare `[data-em-pv]`, so they are not restated. What is below is only what the GRID's measure needs that Showcase's does not. WHY THE QUAD'S GRID GOES BACK TO FLEX -------------------------------------- places.css chose `display: grid` for the quad to stop a wrapping flex row reflowing: on a card with no Book Now, Floor Plans would slide up into Enquire's place and the wall would read as noise. That reasoning is intact, and it is answered rather than ignored — the break (`.em-pl-br`, §3) is a `flex: 0 0 100%` node between the boxes and the utilities, so the line ALWAYS breaks there, on every card, book or no book. Two registers, two lines, on every card of every community. The nobook case keeps its own answer too: with `flex: 1 1 0` on the boxes, a lone Explore takes the whole measure, which is exactly what `.em-acts--nobook > .em-pc__explore { grid-column: 1 / -1 }` did for it. The boxes stretch here and are sized to their words in Showcase. That is not an inconsistency: three tiles abreast are read ACROSS, and a row of buttons that each stop at their own label makes three cards look like three different components. Showcase has no row to line up with. */ [data-em-pv="grid"] .em-pc__acts { display: flex; flex-wrap: wrap; align-items: center; column-gap: 8px; row-gap: 0; } /* The tile keeps places.css's compressed button — 11px/16px at 10.5px — and only stops being a quarter of a grid. The pair halves the measure: 181px each at 1440, 146px at 1024 where the band is three-up at its narrowest, and 175px at 1100 where it drops to two. Every one of those is above the 139px FLOOR PLANS asks for, and BOOK NOW and EXPLORE are narrower still. */ [data-em-pv="grid"] .em-pc__acts .em-btn, [data-em-pv="grid"] .em-pc__acts .em-btn-o { flex: 1 1 0; min-width: 0; } /* Tighter than the entry's 14px: this line sits inside a tile with a photograph above it, not in a column of its own, and a forty-three-project community pays for it forty-three times. */ [data-em-pv="grid"] .em-pc__acts .em-pl-br { height: 11px; } [data-em-pv="grid"] .em-pc__acts .em-plans-btn { margin-left: 22px; } /* The two utilities are quiet text on this card as well, so the 44px target they keep is the only height they cost. Left-aligned under the pair — they are read as a footnote to the two offers above them, and centring them would have made them look like a third and fourth offer. */ [data-em-pv="grid"] .em-pc__enquire, [data-em-pv="grid"] .em-pc__acts .em-plans-btn { justify-content: flex-start; } @media (max-width: 599px) { /* One tile to the row, full measure: the pair has the whole card and the utilities close up, the same arithmetic §6 does for the other view. */ [data-em-pv="grid"] .em-pc__acts .em-btn, [data-em-pv="grid"] .em-pc__acts .em-btn-o { padding-left: 12px; padding-right: 12px; } }