/* * Front-page hero — one fold, three screens, advancing sideways. * * The client asked for the reference site's behaviour: the front page must not * scroll down through the three pictures, they have to arrive on their own, one * after another, moving sideways. So the three slides sit on a flex track that * translates horizontally, and everything that used to be a scroll-driven * reveal is now keyed to which slide is active. * * Every slide is built from the same layers, in this order: * * 1. the photograph — object-fit: contain, in a box that stops short of the * right edge, so nothing is ever cropped ("nie kadrować" was said of both * photographs by name) and the copy keeps the left of the frame; * 2. two grey diagonal bands entering from the left, one wider and lighter, * one narrower and darker, so that where they overlap the ground reads * darker still — the "dwa pasy o różnej przezierności" from the brief. * They fly in at slightly different speeds, which is what separates them * in flight instead of letting them travel as one block; * 3. a third band entering from the right — on all three screens since 07.08, * when the client asked for the one the third screen was missing; * 4. the copy, and on the first screen dr Zawadzki's portrait. * * The bands carry NO edge. They used to be finished with a 2px copper hairline * along the diagonal, because a dark wedge over a dark photograph was otherwise * invisible; the client read that hairline as the light edge the reference site * does not have and asked for it to go. What keeps the wedges readable now is * that they fly across a photograph that is no longer darkened underneath them. * * Horizontal axis: every text block starts on --dd-hero-inset, the same 1200px * page container the sticky bar and the subpages use, so the hero copy and the * logo share one edge at every width. * * Progressive enhancement: the carousel layout is gated behind html.dd-js. With * no JavaScript the track wraps and the three screens stack vertically, which * is the behaviour this section had before — every picture and every line still * reachable, just by scrolling. */ /* --- The frame --------------------------------------------------------- */ .dd-hero { /* one fold — the section never hands over a half-filled screen */ --dd-hero-fold: calc(100vh - var(--dd-header-height)); /* horizontal axis shared with the menu bar and every subpage */ --dd-hero-inset: max(var(--dd-gutter), calc((100% - var(--dd-container)) / 2 + var(--dd-gutter))); /* how far the diagonal leans, as a share of the slide's width */ --dd-hero-lean: 12%; /* * How far a band travels on its way in. * * It used to be -118% of the band's OWN width, which on a 1440 screen worked * out at 878px for the widest of them — measured against the reference, which * flies its panels a flat 2000px, 1.39 of that screen. Ours was under half * the distance in the same time, so it read as a shape being slid into place * rather than one crossing the screen. * * Stated against the viewport, with a floor so a phone still gets a real * flight (700px is 1.8 screens at 390) and a ceiling so a 4K window does not * turn it into a 3000px sprint. */ --dd-hero-band-travel: clamp(700px, 140vw, 2200px); /* * The curve, measured off the reference rather than guessed * (qa/ref-sielska-motion.md): power2.inOut, i.e. easeInOutCubic. It is * symmetrical — the band accelerates, peaks at the middle of its flight and * brakes. The old cubic-bezier(0.22, 0.78, 0.24, 1) was an ease-out: full * speed from the first frame, then a long crawl into place. Same distance, * same duration, completely different thing to watch. */ --dd-hero-ease: cubic-bezier(0.65, 0, 0.35, 1); /* * The strip at the foot of the fold that no photograph may enter. It is the * floating CTA's own reserve plus room to breathe: measured against the * pill, the pictures were ending 13-25px above it at five width/screen * combinations, which reads as a photograph resting on a button rather than * as two things that happen to share a corner. */ --dd-hero-media-foot: calc(var(--dd-cta-reserve) + 1.5rem); /* * ONE type scale for the whole carousel. * * The sizes used to be container-relative (cqw against each screen's own * text field), and the three fields are deliberately different widths — * 528px, 308px and 408px of content at 1440. So the same role came out at * a different size on every screen: the headline ran 29.6px on the * portrait and 20.8px on the treatment room, where it is the only thing * written on the fold and sat at the floor of its own clamp. Sizing off * the viewport instead means a role is one size wherever it appears, and * the column widths go back to being a layout decision only. * * The absolute level is set against the site the client named: at 1440 * sielskaklinika.pl carries its hero copy at 46px and 55px, and at 390 at * 37px — measured, not eyeballed. Ours ran at 20.8-29.6px on the same * screen, which is the "za małe" in the report. * * The lead is the base and the sentence is derived from it, because the * ratio between them is the client's own instruction ("sentence half * again the size of the line above"). Changing the scale cannot break it. */ /* The middle of the range is where a plain vw clamp fails: at 2.9vw the floor held from 390 all the way to ~900px, so a 768px tablet was shown the phone's type in twice the space. Stated as base + vw it grows the whole way — 29px at 390, 35px at 768, 46px at 1440 and up, which is the reference's own 37px/46px bracket. */ --dd-hero-lead: clamp(1.8rem, 1.42rem + 1.62vw, 2.875rem); /* * The sentence is derived from the lead ON THE ELEMENT (see .dd-hero__script * and .dd-hero__script--large), not through a custom property declared here. * * It was a property here until 23.08, written as * `calc(var(--dd-hero-lead) * 1.5)`, and that is a trap this file has to * name rather than merely avoid. A custom property is substituted where it * is DECLARED: `--dd-hero-script` resolved `--dd-hero-lead` against .dd-hero * and inherited downwards already resolved, so the phone branch's override * of `--dd-hero-lead` on .dd-hero__slide never reached it. Measured on the * live page at 360x640: lead 22.4px, sentence 43.2px — a ratio of 1.93 where * the client's instruction is 1.5, and the same 43-44px on every phone in * the grid whatever its height. * * The consequence was not typographic. The sentence is the tallest block of * copy on the opening screen, and being blind to the fold it cost the same * on a short phone as on a tall one — so the photograph, the only elastic * row in the column, paid the whole difference. That is the "napis przykrywa * za dużą część mojego zdjęcia" of the 23.08 mail. */ --dd-hero-byline: clamp(1.1rem, 0.95rem + 0.5vw, 1.4rem); position: relative; overflow: hidden; background: #0a0806; } @supports (height: 100svh) { .dd-hero { /* svh = the short viewport, so a phone's collapsing URL bar cannot push the first screen past the fold */ --dd-hero-fold: calc(100svh - var(--dd-header-height)); } } .dd-hero__track { display: flex; flex-wrap: wrap; } .dd-js .dd-hero__track { flex-wrap: nowrap; /* * The sweep is the change of picture, and nothing else — it must be OVER * before the arrival starts, or it carries every layer with it. * * Measured at 1s (qa/ref-sielska-motion.md, our column): every band, every * line of copy and both photographs started moving in the same millisecond * and stopped in the same millisecond, because the track was moving them. * A layer's own travel showed up only as the difference against a 1440px * sweep running at 4188px/s — the reason the screen arrived as one rigid * block. The reference has no sweep at all: it cross-fades and the kadr * stands still while the panels cross it. * * We keep the sweep, because a slider that moves sideways is what the client * asked for, but it is short and it is finished at 700ms — after which the * frame is still and the bands fly across a screen that is not itself moving. */ transition: transform 0.7s var(--dd-hero-ease); } .dd-hero__slide { position: relative; flex: 0 0 100%; width: 100%; height: var(--dd-hero-fold); /* * 420, not 480. The floor is there for windows too short to give the slide a * usable stage at all, but at 480 it also caught the ordinary short laptop: * at 1366x560 the fold is 472px, the floor overrode it, and the first screen * ended 8px below the window — the section built to fill exactly one fold * arrived with a scrollbar already on it. Below 420 the floor still holds and * the slide is allowed to overflow, which is the lesser fault. */ min-height: 420px; overflow: hidden; background: #0a0806; } /* * Screen 1 carries no photograph of its own, so its wash is the portrait — and * the portrait was retouched onto a flat light ground, which makes it the * brightest surface of the three once blurred. It is taken down harder than the * other two: this screen has to stay the intro's closing frame, near-black with * a warm cast, and it is the one screen the client has already approved. * * The copper is painted over the wash rather than under it, and it stays on the * LEFT, under the copy. It used to sit at 74% — behind the portrait — and that * put a halo around the silhouette, the one thing the client asked twice to be * rid of ("bez rozjaśnień wokół sylwetki", P6). */ .dd-hero__slide--first { background: #070403; } /* * Each wash is exposed for its own photograph, not with one shared setting. * The three pictures do not share a key: the treatment room is a back-lit glass * wall, the sculpture stands in a dark hall, and the portrait is a figure on a * light ground. With one brightness for all three the bands measured 3.06 over * the treatment room and 1.29 over the sculpture (band-contrast.js) — the same * choreography, invisible on one screen out of three. * * The target is the same on every screen: enough ground under the band that the * band's own darkening lands at 3:1 or better. */ .dd-hero__slide--first .dd-hero__wash img { filter: blur(44px) saturate(0.22) brightness(0.82) contrast(0.85); } .dd-hero__slide--first .dd-hero__wash::after { background: radial-gradient(42% 52% at 24% 44%, rgb(198 116 64 / 15%), rgb(198 116 64 / 5%) 56%, transparent 78%), linear-gradient(100deg, rgb(7 4 3 / 56%), rgb(7 4 3 / 28%) 46%, rgb(7 4 3 / 20%)); } /* --- The ground the bands cross ----------------------------------------- */ /* * Why this layer exists, in one number: measured with band-contrast.js, a band * crossing the old near-black slide changed the luminance of what it covered by * a contrast ratio of 1.02 in the middle of the screen and 1.22 at the very * edge. The reference's panels change theirs by 3.5 and 5.67. A band that * changes nothing is invisible however fast it flies, which is why retiming the * choreography twice never fixed "animacje działają inaczej niż na sielskiej". * * The reference gets its contrast from dark panels over a full-bleed * photograph. We cannot bleed the photographs — both were sent back with an * instruction not to crop them. So each screen lays its own picture down a * second time, blurred past recognition and darkened, purely as a surface for * the bands to darken further. The picture itself is unchanged and on top of it, * contained and whole. * * The blur is large enough that no feature survives it: at 40px on a 960px * source there is no face, no window frame and no sculpture in the wash, only * the photograph's own light and colour. That is deliberate — it is a texture, * not a second copy of the picture, and it must not read as one. */ .dd-hero__wash { position: absolute; z-index: 0; inset: 0; overflow: hidden; background: #0a0806; } .dd-hero__wash img { width: 100%; height: 100%; object-fit: cover; /* scaled up so the blur's soft edge falls outside the frame instead of painting a pale border along it */ transform: scale(1.18); /* Saturation is held right down. Blurred at full strength the wash paints what the photograph happens to contain — a green treetop, a red chair — as coloured smears behind a picture that is trying to be the subject. Nearly grey, it reads as light and shade, which is all it is for. */ filter: blur(40px) saturate(0.28) brightness(0.88) contrast(0.88); } /* * The wash is held down just enough to stay the dark hero the brand is, and no * further. The temptation is to darken the left, where the copy sits — but the * copy's contrast is the BAND's job, exactly as on the reference, where the * type stands on a panel that is 78% black. Darkening the ground as well leaves * the band nothing left to darken, which is what the first attempt at this * measured: 1.35 at the left edge against 6.54 on the reference. */ .dd-hero__wash::after { position: absolute; inset: 0; content: ''; background: linear-gradient( 100deg, rgb(10 8 6 / 46%), rgb(10 8 6 / 18%) 46%, rgb(10 8 6 / 12%) ); } /* --- The photographs ---------------------------------------------------- */ /* * `contain`, not `cover`. Both photographs were sent back with an instruction * not to crop them — the treatment room because the client wants the full * height of the glass wall and the treetop behind it, the sculpture because * the original is an upright frame and the height of the hall is the point. * A contained picture in a box that leaves a dark margin on the right is the * only arrangement that keeps that true at 390px and at 1920px alike. */ /* * The frame is a flex box and the picture inside it is its own size — it used to * be a full-size element with object-fit: contain, and that arrangement cannot * carry a rounded corner: `contain` letterboxes the photograph INSIDE the * element, so a radius on the element rounds the empty margin around the picture * and leaves the picture itself square. Sized to its own content, the image box * and the photograph are the same rectangle and the corner lands where the * client can see it. * * The result is identical geometry to `contain` — max-width and max-height with * auto on both axes is the same fit — with the alignment moved from * object-position onto the flex box. */ .dd-hero__media { position: absolute; z-index: 1; display: flex; align-items: center; justify-content: center; margin: 0; } .dd-hero__media img { display: block; width: auto; height: auto; max-width: 100%; max-height: 100%; border-radius: var(--dd-radius-media); filter: brightness(0.96) saturate(0.94) contrast(1.04); } /* * The treatment room is the one photograph with strong colour in it — a * back-lit glass wall, a green treetop, an amber lamp. Blurred, those became * yellow-green smears above and beside the picture, brighter than the picture's * own sky. Held down harder than the other two, and closed further towards the * right, where the picture itself has to be the brightest thing on the screen. */ .dd-hero__slide--gabinet .dd-hero__wash img { filter: blur(40px) saturate(0.14) brightness(0.8) contrast(0.85); } .dd-hero__slide--gabinet .dd-hero__wash::after { background: linear-gradient( 100deg, rgb(10 8 6 / 46%), rgb(10 8 6 / 22%) 44%, rgb(10 8 6 / 40%) ); } /* the treatment room is landscape: it takes the width it can and sits away from both the copy on the left and the edge on the right. The bottom inset clears the floating CTA — the pill is fixed to the same corner this picture reaches into, and at 1920 it was lying 135px into the photograph. */ .dd-hero__slide--gabinet .dd-hero__media { inset: 4% 4% max(4%, var(--dd-hero-media-foot)) auto; width: 58%; } /* * The sculpture keeps its upright frame and is pulled a little further from * the right edge than the treatment room, which is the dark margin the client * asked for: "sugeruję zastosowanie prawego, ciemnego marginesu z jednoczesnym * przesunięciem zdjęcia trochę w lewą stronę". */ .dd-hero__slide--figura .dd-hero__media { inset: 3% 11% max(3%, var(--dd-hero-media-foot)) auto; width: 42%; } /* * The sculpture stands in a dark hall, so its wash needs the most exposure of * the three to give the bands a ground at all. The gradient runs the other way * here: open on the left where the two wide bands fly, closed under the * photograph, which also keeps the blurred red of the armchair from smearing * along the edge of the picture. * * That closed right end used to be justified by there being no band on the * right at all. Since 07.08 there is one (D8), and it flies over the darkest * part of this wash — but it still reads, because the band is dark itself and * the ground under it is the blurred hall rather than flat black. Measured * rather than assumed: ops/qa-scripts/band-contrast.js. */ .dd-hero__slide--figura .dd-hero__wash img { /* the most exposed wash of the three is also the one that most needs the colour taken out of it: brightened, the blurred armchair behind the sculpture printed a pink cast down the right of the fold */ filter: blur(44px) saturate(0.12) brightness(1.9) contrast(0.72); } .dd-hero__slide--figura .dd-hero__wash::after { background: linear-gradient( 100deg, rgb(10 8 6 / 12%), rgb(10 8 6 / 30%) 52%, rgb(10 8 6 / 56%) ); } /* * `contain` centres the upright frame in a box far wider than it, so the dark * margin the client asked for stopped being 11% and became 11% plus whatever * the box had left over — 414px at 1920, with the picture drifting towards the * middle of the screen. Pinning it to the right of its box gives back the * margin she specified and closes the empty pocket between copy and photograph. */ .dd-hero__slide--figura .dd-hero__media { justify-content: flex-end; /* * Above the bands, which is what keeps D8 from undoing P10. * * The new band on the right reaches `22% - 6rem` from the edge, while this * photograph is pinned 11% from it — so between roughly 990 and 1280 the * band's foot lands ON the sculpture (44px of it at 1279, nothing at 1440, * where the 1360+ rule moves the picture further left). P10 exists to keep * this photograph whole and unobscured, and a band drawn over it is * "kadrowanie" by another name. * * Raising the picture rather than narrowing the band keeps the reach the * client asked for — "o takim samym zasięgu jak w zdjęciu nr 2" — at every * width, and it is the same arrangement he proposed himself for the phone: * the bands slide UNDER the picture. 3 sits above the bands (2) and below * the copy (4). */ z-index: 3; } /* * Giving the sculpture its size back. * * Measured at 1440: 343x609 against the treatment room's 835x487. The same * height as the portrait and a third of the width of its neighbour, which is * what makes it read as the poor relation of the three. The cause is the frame: * every shot the client sent of this sculpture is 9:16 straight off a phone * (u04, u05, u06, u07, u12 — all 1152x2048), and she asked for it "koniecznie * w kadrze pionowym, tak jak w oryginale, nie kadrować". A contained upright * frame has its width decided entirely by how tall it is allowed to be, so the * only way to make it bigger is to give it more of the fold. * * What was holding it back is the strip at the foot of the fold that the * floating pill owns — 124px of it. Covering the pill's corner would crop the * photograph by another name, so the picture takes the height and moves LEFT * out of the pill's way, which is also what the client asked for: "prawy, * ciemny margines z jednoczesnym przesunięciem zdjęcia trochę w lewą stronę". * * Only from 1360px up: below that the copy column and the pill leave a gap too * narrow for a wider picture, and the current arrangement already uses the * whole strip above the pill. */ @media (min-width: 1360px) { .dd-hero__slide--figura .dd-hero__media { inset: 2.5% clamp(280px, 20%, 420px) 2.5% auto; width: min(52%, 560px); } } /* * 1280 gets the same move at half the strength. The picture's width follows its * height, so a full-height frame here would start 56px from the calligraphy — * and Great Vibes carries its swashes well outside its own box. Two thirds of * the extra height keeps 97px of air on the left and 57px to the pill, and the * sculpture still gains 19% of area. */ @media (min-width: 1280px) and (max-width: 1359.98px) { .dd-hero__slide--figura .dd-hero__media { inset: 6% clamp(260px, 21%, 300px) 6% auto; width: min(52%, 560px); } } /* --- The bands ---------------------------------------------------------- */ /* * Three planes with no edge treatment of any kind: a fill, a diagonal cut and * nothing else. The two on the left overlap on purpose — the narrower one * stands on the wider one, so the strip nearest the edge carries both fills and * reads as the denser of the two bands. That is the "dwa pasy o różnej * przezierności" the client pointed at on the reference site, and it is how the * reference builds it too: the same translucent artwork placed twice, at two * sizes, one over the other. * * The fill DARKENS, as the reference's does. It used to be a pale veil at * 6-13% — the only thing that could be seen at all over a near-black slide — * and the measurement of that decision is in band-contrast.js: 1.02 against * the reference's 3.5. Now there is a wash underneath (see .dd-hero__wash) and * a dark plane over it behaves exactly as the reference's does. Two of them * overlapping give ~0.73 combined, which is the 72-77% measured on the * reference's own panels. * * Still no hairline along the diagonal, at any density: the client read the * old copper edge as the light border the reference does not have (P5). */ .dd-hero__band { position: absolute; z-index: 2; top: -2%; height: 104%; pointer-events: none; /* leaving: short and level with the reference's 300ms exit */ transition: transform 0.3s var(--dd-hero-ease); } .dd-hero__band--a { left: 0; width: 52%; clip-path: polygon(0 0, 100% 0, calc(100% - var(--dd-hero-lean) * 3) 100%, 0 100%); background: linear-gradient(184deg, rgb(8 6 5 / 64%), rgb(12 9 7 / 56%) 58%, rgb(8 6 5 / 62%)); } .dd-hero__band--b { left: 0; width: 31%; clip-path: polygon(0 0, 100% 0, calc(100% - var(--dd-hero-lean) * 4) 100%, 0 100%); background: linear-gradient(176deg, rgb(6 5 4 / 50%), rgb(10 8 6 / 42%) 62%, rgb(6 5 4 / 48%)); } /* * The band on the right, shortened on 07.08 (D7): "prawe szare pole za mocno * przysłania kadr zdjęcia z gabinetem, proszę skrócić zasięg wysuwania się pola * o 2,5cm. Kąt nachylenia pozostawić, jest ok." * * Two things had to be separated to do that. The reach is the band's own width * — the foot of the wedge runs to its left edge — so 2.5cm comes off the width. * But the diagonal was declared as 38% OF THAT WIDTH, so taking 96px off would * also have taken 36px off the horizontal run and stood the wedge up steeper, * which is the one thing the client said to leave alone. The run is therefore * frozen as a length computed from the ORIGINAL width and the clip-path is * stated in that length: same run over the same height, so the same angle, on a * narrower plane. * * The floor keeps the wedge from collapsing into its own diagonal on a narrow * desktop window, where 22% is small enough that the trim would eat all of it. */ .dd-hero__band--right { --dd-hero-band-right-base: clamp(110px, 22%, 380px); /* * The wedge's horizontal run, stated in viewport units on purpose. * * It has to equal 0.38 x the ORIGINAL width, which is what keeps the angle * where the client left it. The obvious way to write that — reusing the * width expression inside the clip-path — is a trap: a percentage in `width` * resolves against the containing block, but a percentage in `clip-path` * resolves against the ELEMENT'S OWN box. The same `22%` therefore meant two * different lengths, the run collapsed from 120px to 42px at 1440, and the * wedge stood up steeper — the one thing "kąt nachylenia zostawić" forbids. * * Stated against the viewport there is no such ambiguity, and the three * stops mirror the base clamp exactly: 0.38 x 110px, 0.38 x 22%, 0.38 x 380px. */ --dd-hero-band-right-run: clamp(41.8px, 8.36vw, 144.4px); /* * 2,5 cm on the client's ruler, 1 cm ~= 38px, i.e. 96px — but stated as a * share of the window that reaches 96px at the 1440 the correction was * measured against. * * Flat 96px does not survive the bottom of the desktop range: the base is * 22% of the window, so at 769px it is 169px and a flat cut leaves a 73px * plane with a 64px diagonal across it — a sliver, not a band. Proportional, * the cut is 51px there and the wedge keeps a face. */ --dd-hero-band-right-trim: clamp(0px, 6.67vw, 6rem); right: 0; width: max( var(--dd-hero-band-right-run), calc(var(--dd-hero-band-right-base) - var(--dd-hero-band-right-trim)) ); clip-path: polygon(var(--dd-hero-band-right-run) 0, 100% 0, 100% 100%, 0 100%); background: linear-gradient(196deg, rgb(8 6 5 / 64%), rgb(12 9 7 / 54%) 44%, rgb(8 6 5 / 62%)); } /* --- The copy ----------------------------------------------------------- */ /* * The field is a column, not a sizing context: its width decides where the copy * wraps, never how large it is set. It used to be a container-query context and * the type read its own size off it, which is how three screens ended up with * three type scales — see --dd-hero-lead above. */ .dd-hero__field { position: absolute; inset: 0 auto 0 0; z-index: 4; display: flex; flex-direction: column; justify-content: center; width: min(56%, calc(var(--dd-hero-inset) + 620px)); padding: 2.5rem 2rem 2.5rem var(--dd-hero-inset); } /* * The opening screen carries three blocks — the experience line, the sentence * under it and the name under that — and the client asked for the first of them * to move up. Anchored to the top of the fold the column left a third of the * screen empty under the name; centred, it sat lower than it had before. So it * is centred and then lifted by half the padding below it, which puts the whole * column above the middle without stranding it against the bar. */ .dd-hero__slide--first .dd-hero__field { padding-block-end: clamp(2rem, 12vh, 7rem); } .dd-hero__field-inner { display: flex; flex-direction: column; gap: clamp(0.9rem, 1.8vh, 1.6rem); } /* * The headline of a screen — the experience line on the portrait, the statement * on the treatment room. One size for both: they are the same role, and reading * them at 29.6px on one screen and 20.8px on the next is what "czcionki nie * jednorodne" describes. */ .dd-hero__lead { margin: 0; font-family: var(--dd-font-heading); /* 600, not the 500 every other heading takes. Size is only half of how loud a line is: Playfair at 500 puts a ~3.5px stem and 1px hairlines on the screen where the reference's Open Sans Bold puts ~6px of even stroke, so at the same measured size ours carried about half the ink. */ font-weight: 600; font-size: var(--dd-hero-lead); line-height: 1.22; letter-spacing: 0.01em; color: var(--dd-color-accent); } /* * The sentence. Half again the size of the line above it, which is the ratio * the client set. Great Vibes has a small x-height and long swashes, so it is * given a looser line than an upright face would need at the same size. */ .dd-hero__script { margin: 0; /* half again the lead that is in scope here — see the note by --dd-hero-lead for why this is not a custom property */ font-size: calc(var(--dd-hero-lead) * 1.5); /* Great Vibes drops long tails and carries its swashes above the cap line, so a leading that would be generous for an upright face is tight here: at 1.2 the tail of "spotyka" ran into the "k" of "pięknem" below it. */ line-height: 1.26; color: var(--dd-color-accent-light); text-shadow: 0 2px 24px rgb(0 0 0 / 55%); } /* on the sculpture the sentence carries the whole screen and is set larger still, on three lines, as the brief asks — one deliberate step, not a third scale */ .dd-hero__script--large { font-size: calc(var(--dd-hero-lead) * 1.75); line-height: 1.2; } /* * The name under the sentence. It used to run at 15.2px with the role under it * at 12.5px — small print on the one screen that introduces the person the * clinic is named for. Both are on the scale now and neither goes under 16px. */ .dd-hero__byline { margin: 0; /* * As wide as the name and no wider, because the role underneath it is now * centred against the name (D7.08: "wypośrodkować »właściciel Kliniki« * względem Dr Tomasz Zawadzki"). Stretched to the copy column — 588px at * 1440 — there was nothing to centre against but the column itself, and the * role would have drifted out under the sentence. * * Safe in this direction only because the name is the longer line: measured * in Playfair Display at the byline's own sizes, "Dr Tomasz Zawadzki" is * 209px against 144px for "właściciel Kliniki". If that ever inverts, this * centres the name under the role instead. * * The left edge stays on --dd-hero-inset: fit-content shrinks the box to the * right, and the flex column does not stretch a box that has been given a * width. */ width: fit-content; font-family: var(--dd-font-heading); font-size: var(--dd-hero-byline); line-height: 1.45; color: var(--dd-color-accent-light); } /* * The role under the name, and only ever quieter than it. It used to be set in * the body face at 82% of the LIGHTER copper while the name above it took the * darker one — so "właściciel Kliniki" was the brighter of the two lines and * the man's name read as its caption. */ .dd-hero__byline span { display: block; font-size: 0.85em; letter-spacing: 0.01em; text-align: center; color: rgb(227 172 134 / 66%); } /* --- The portrait (first screen) --------------------------------------- */ /* * The photograph the client sent on 03.08: retouched, on a flat light ground, * "bez rozjaśnień wokół sylwetki". So there is no plate, no mat, no gilt edge * and no dark veil at the foot — every one of those was built to marry a dark * portrait to a dark screen, and all of them together were what the client read * as a memorial photograph. What is left is the picture and a shadow to lift it * off the ground. * * The corner used to be cut on the diagonal, echoing the bands. It is rounded * now: the client asked for rounded corners on photographs, and a picture that * answers the house's diagonal instead of that request is the theme arguing with * her. The diagonal language stays where it is not a photograph — the bands, the * footer, the panel on O Klinice. * * Geometry follows the source exactly: aspect-ratio .6775 is 1000:1476, so * `cover` has nothing to crop, and the height ceiling is 650px — the 500px the * old panel was capped at plus the 30% the client asked for. */ .dd-hero__portrait { position: relative; z-index: 5; display: block; aspect-ratio: 0.6775; margin: 0; padding: 0; filter: drop-shadow(0 24px 44px rgba(0, 0, 0, 0.55)); } .dd-hero__portrait-photo { display: block; width: 100%; height: 100%; object-fit: cover; border-radius: var(--dd-radius-media); } /* --- Split composition (desktop) ---------------------------------------- */ @media (min-width: 769px) { .dd-hero__slide--first { /* * The strip of ground between the black bar and the top edge of the * photograph (D1: "obniżyć moje zdjęcie, tak aby ukazać górną krawędź * zdjęcia z zaokrąglonymi narożnikami"). * * Nothing was hiding that edge — it was 8px below the bar, and the * corner it is rounded with is 14px, so the picture read as running out * from under the bar. The 8px is the `top` floor below, reached because * the frame took the whole fold and left the centring term at exactly * zero on every window shorter than ~918px, which is every laptop. * * It is subtracted from the frame HEIGHT and used as the floor of `top`, * which pins the bottom edge where it already was: the picture loses * this much height and gains exactly this much air above it, instead of * moving down onto the floating pill. Above ~918px the 650px ceiling * still binds and nothing here changes — the top edge was already clear * there (81px at 1920x1080). */ --dd-hero-portrait-head: clamp(1.25rem, 2.4vh, 1.75rem); /* the panel takes the fold minus room to breathe, and never grows past the 650px ceiling */ --dd-hero-frame-h: clamp( 260px, calc(var(--dd-hero-fold) - var(--dd-hero-media-foot) - var(--dd-hero-portrait-head)), 650px ); --dd-hero-frame-w: calc(var(--dd-hero-frame-h) * 0.6775); } .dd-hero__slide--first .dd-hero__portrait { position: absolute; right: var(--dd-hero-inset); /* Centred on the fold MINUS the strip the CTA pill owns, because the frame and the pill share the bottom-right corner. The reveal no longer moves the portrait at all — like the reference's photographs it is simply there, faded up while the bands cross it. */ /* The floor is --dd-hero-portrait-head, and the frame above was shortened by the same amount, so on a laptop the two agree and the bottom edge does not move: the old 0.5rem floor is what put the picture 8px under the bar. On a tall window the centred term wins on its own, as before. */ top: max( var(--dd-hero-portrait-head), calc((var(--dd-hero-fold) - var(--dd-hero-media-foot) - var(--dd-hero-frame-h)) / 2) ); width: var(--dd-hero-frame-w); height: var(--dd-hero-frame-h); aspect-ratio: auto; } /* the copy stops short of the portrait column, whatever that column currently measures */ .dd-hero__slide--first .dd-hero__field { width: min( calc(var(--dd-hero-inset) + 620px), calc(100% - var(--dd-hero-inset) - var(--dd-hero-frame-w) - clamp(1.5rem, 3vw, 4rem)) ); } /* * Each photograph's column starts at a known share of the slide, and the * copy has to stop before it. The statement on the treatment room used to * run over the frosted glass on the left of that picture, where copper on * a pale, back-lit surface is barely a colour at all. The treatment room * begins at 38% of the slide, the sculpture at 47%, so both columns take * the room up to that edge and no more. */ .dd-hero__slide--gabinet .dd-hero__field { width: min(37%, calc(var(--dd-hero-inset) + 400px)); } .dd-hero__slide--figura .dd-hero__field { width: min(46%, calc(var(--dd-hero-inset) + 480px)); } /* * The rhythm of the opening screen's three blocks, retuned on 07.08. * * Two requests, and they pull on the same chain from opposite ends: * D3 "sentencję »Gdzie zdrowie spotyka się z pięknem« obniżyć o 1,5-2cm" * D6 "Dr Tomasz Zawadzki subtelnie bliżej sentencji, czyli subtelnie podnieść" * So they are set together, in one pass, and measured together. * * Everything here is scoped to --first for two reasons. The gap is a * property of the column, and screens 2 and 3 have a single block of copy * each, so retuning it there would be meaningless — but .dd-hero__script is * NOT slide 1's alone: screen 3 carries it too, in the large variant that * P10 placed. An unscoped margin would have moved that sentence as well and * quietly undone a round-1 requirement the client never complained about. * * The compensation is the part that is easy to get wrong. The column is * centred in the fold, so anything added inside it lifts the whole column by * half of what was added: the naive version of D3 moves the sentence down by * half the intended distance AND drags "27 lat..." up with it. Trimming the * foot padding by the same amount holds the column's top edge still, so the * sentence moves the whole distance and the line above it does not move at * all. Verified by measurement, not by this comment. */ .dd-hero__slide--first .dd-hero__field-inner { gap: clamp(0.6rem, 1.1vh, 1.1rem); } /* * D6 needs to be visible, not merely true. The gap step above moved the name * 6px closer to the sentence in ink terms — real, and below the threshold of * the instrument the client is using. He works in half-centimetres: every * figure in his two emails is 1,5 / 2,5 / 3,5-4 cm, i.e. ~19px and up. A 6px * change reads to him as nothing having happened. * * Pulled up by a further step, the ink gap lands near 25px — a third of what * it was, which is a change he can see without being told, while still * reading as one block of copy rather than a new arrangement. */ .dd-hero__slide--first .dd-hero__byline { margin-block-start: -0.75rem; } .dd-hero__slide--first .dd-hero__script { margin-block-start: clamp(3.5rem, 8vh, 6rem); } .dd-hero__slide--first .dd-hero__field { padding-block-end: clamp(1rem, 5.3vh, 3.5rem); } } /* * "Szczególnie moje zdjęcie na stronie głównej, w laptopie czarnym, jest za * małe" (11.08), and the arithmetic of the fold says he is right. * * The frame is an upright 0.6775 rectangle, so its width is decided entirely by * the height it is allowed - and on a short window everything it has to clear is * quoted in pixels while the fold is not. Measured at 1093x614 before this pass: * a 470px fold paid 144px to the pill's reserve and the strip above the picture * and kept 326px, i.e. 69% of it, against 81% on the 1600x900 machine he holds * up as the one to match. Same CSS, same photograph, two-thirds of the size. * * Three fixed costs come down together on a short window and none of them is * paid by the composition: the bar (main.css), the pill's reserve (main.css and * floating-cta.css) and the ground above the picture, which is set here to the * corner radius itself - the D1 request was to SHOW the rounded top edge, and * 14px of ground is exactly enough to read a 14px corner. Together they hand the * photograph 58px back: 260x384 where it was 221x326, which is 40% more picture. */ @media (min-width: 769px) and (max-height: 740px) { .dd-hero__slide--first { --dd-hero-portrait-head: var(--dd-radius-media); } /* * Found while photographing the same window, and older than the 11.08 * report: the copy column is centred in the fold and the control row is * pinned to the foot of it, so the two only stay apart while the fold is * tall. At 1093x614 the column is 419px of a 510px fold - 82% - and the * dots were printed across "właściciel Kliniki". The foot padding is a * share of the window (5.3vh), so it shrank at exactly the height the * collision needed it to grow. * * Stated as what is actually down there instead: the control row's own * offset plus its height and a line of air. The column lifts by ~26px and * the row gets its strip back. It was worse before this pass, not better - * with the 144px bar the same 419px column stood in a 470px fold. */ .dd-hero__slide--first .dd-hero__field { padding-block-end: calc(clamp(1.25rem, 3vh, 2.25rem) + 2.5rem); } /* * The padding above buys the control row its strip back; it cannot buy it * from a column that is taller than the stage. The scale is set from WIDTH * alone, so the client's 1366x560 laptop is shown the full 46px lead — the * copy column measures 456px inside 380px of stage, overflows by 76px, and * "właściciel Kliniki" is printed across the dots again, this time from * below. Measured on the preview he photographed, and present in production * before this pass: the same overlap, 2px further down. * * The phone band already answers this, at the bottom of this file: the lead * is the smaller of a width ramp and a height ramp. Same construction here, * fitted to this band — 34px at 560 of window, back to the full 46 by 740, * where the stage is tall enough to hold the column as designed. The script * and the closing sentence follow, because both are declared as multiples of * the lead and that ratio is the client's. */ .dd-hero { --dd-hero-lead: min( clamp(1.8rem, 1.42rem + 1.62vw, 2.875rem), clamp(1.9rem, -0.2rem + 6.67svh, 2.875rem) ); } } /* --- Arrival animation --------------------------------------------------- */ /* * Everything below is gated on .dd-js: with no script there is no active slide * and nothing may start out hidden. */ .dd-js .dd-hero__band--a, .dd-js .dd-hero__band--b { transform: translateX(calc(-1 * var(--dd-hero-band-travel))); } .dd-js .dd-hero__band--right { transform: translateX(var(--dd-hero-band-travel)); } /* * The shape of a turn, transcribed from the reference the client keeps naming. * * Measured with requestAnimationFrame over two full cycles at 1440 and 390 — * ops/qa-scripts/ref-sielska-motion.js, tabulated in qa/ref-sielska-motion.md. * What sielskaklinika.pl does, in order, on a 7500ms turn: * * 300ms panel from the RIGHT starts, 1500ms declared, 2000px, peak 4838px/s * 500ms wider panel from the LEFT, 1300ms declared, 2000px, peak 5487px/s * 800ms narrower panel from the LEFT, 1300ms declared, 2000px, peak 5533px/s * 1500ms the copy, 1000ms declared, 50px, peak 172px/s * 2237ms everything has landed; the screen is then still for 4.3s * 6551ms all layers leave together in 312ms, back the way they came * * Three things in that list are the whole of it, and all three were missing * here. The bands cross more than a screen width, at ~5500px/s. The copy moves * forty times less than they do. And the onsets are 200-700ms apart, so no two * layers ever start together while something is always in flight. * * Ours is the same shape on a 6600ms turn — the client asked for pictures that * change faster than the reference, so every onset is pulled in proportionally * and the flights are a little shorter. The one addition is the sweep: the * client also asked for a slider that moves sideways, which the reference does * not have. It is over at 700ms, before the first band is halfway, so what * flies afterwards flies across a frame that is standing still. * * A variant tried on 06.08 sent the whole text field in as a single plane from * the left, starting alongside the bands. It was reverted the same day: with * everything moving at once the screen arrives as one rigid block. Whatever * else changes here, the layers must keep arriving one after another. */ .dd-hero__slide { /* * How far a line of copy travels. The reference moves its copy 50px while * its panels cross 2000px — a ratio of 40:1, and that contrast is what makes * the panels read as the fast thing. Ours was 72px against a band that * travelled 878px: 12:1, so the copy competed with the bands instead of * settling under them. */ --dd-hero-travel: 50px; /* onsets, in the reference's order: right band, wide left band, narrow left band, then the copy. Named so the cascade is legible as a cascade. */ --dd-hero-in-right: 0.4s; --dd-hero-in-wide: 0.6s; --dd-hero-in-narrow: 0.85s; --dd-hero-in-copy: 1.4s; /* one step of the copy's stagger — the reference separates its two lines by 300ms; ours has three to place inside a shorter turn */ --dd-hero-step: 0.2s; } .dd-js .dd-hero__slide .dd-hero__media img, .dd-js .dd-hero__slide .dd-hero__portrait { opacity: 0; transition: opacity 0.3s ease; } /* * The copy comes in from the LEFT, the same side as the two bands it sits on. * It used to come from the right, against them; the reference sends its copy * the way its panels go (x:-50px), so the text reads as something the bands * brought with them rather than as a fourth thing arriving from elsewhere. */ .dd-js .dd-hero__slide .dd-hero__field-inner > * { opacity: 0; transform: translateX(calc(-1 * var(--dd-hero-travel))); /* the leaving side of the journey: fast, and back the way it came */ transition: opacity 0.26s ease, transform 0.3s var(--dd-hero-ease); } /* * The bands. Same distance each, different durations — the difference in speed * is the whole point of having two on the left: launched alike they arrive as * one block and the second edge is never seen. * * 2016px (140vw at 1440) over 1.15s on an easeInOutCubic peaks at 3 x the mean, * i.e. ~5260px/s — the reference measures 4838-5533px/s. The old pairing was * 878px over 1s peaking at ~1800px/s. */ .dd-js .dd-hero__slide.is-active .dd-hero__band--right { transform: none; transition: transform 1.2s var(--dd-hero-ease) var(--dd-hero-in-right); } .dd-js .dd-hero__slide.is-active .dd-hero__band--a { transform: none; transition: transform 1.15s var(--dd-hero-ease) var(--dd-hero-in-wide); } .dd-js .dd-hero__slide.is-active .dd-hero__band--b { transform: none; transition: transform 1.1s var(--dd-hero-ease) var(--dd-hero-in-narrow); } /* The photograph does not travel — on the reference it is simply there, faded up under the panels while they cross it. */ .dd-js .dd-hero__slide.is-active .dd-hero__media img, .dd-js .dd-hero__slide.is-active .dd-hero__portrait { opacity: 1; transition: opacity 0.9s ease 0.45s; } .dd-js .dd-hero__slide.is-active .dd-hero__field-inner > * { opacity: 1; transform: none; transition: opacity 0.6s ease, transform 0.65s var(--dd-hero-ease); } /* Three onsets, one step apart, after the last band has started. The last line lands at 1.4 + 0.4 + 0.65 = 2.45s of a 6.6s turn, leaving 4.1s of stillness — the reference stands still for 4.3s of 7.5s. */ .dd-js .dd-hero__slide.is-active .dd-hero__field-inner > :nth-child(1) { transition-delay: var(--dd-hero-in-copy); } .dd-js .dd-hero__slide.is-active .dd-hero__field-inner > :nth-child(2) { transition-delay: calc(var(--dd-hero-in-copy) + var(--dd-hero-step)); } .dd-js .dd-hero__slide.is-active .dd-hero__field-inner > :nth-child(3) { transition-delay: calc(var(--dd-hero-in-copy) + var(--dd-hero-step) * 2); } /* * Reduced motion. There is deliberately no variant here: the arrival above is * what every visitor gets, including one whose system asks for less movement. * That is the client's decision, taken on 09.08 with the cost stated — bands * crossing 2016px are exactly the kind of large-area travel WCAG 2.3.3 (AAA) * asks to make optional, and this page addresses an audience that includes * "60+". It was chosen over the reduced variant that stood here before (a * cross-fade with nothing travelling), because on her own machine — Windows * with animations disabled — the reduced variant read as "the site does not * animate at all". * * The stop is not gone, it moved: the play/pause control in .dd-hero__controls * halts the carousel (WCAG 2.2.2), and the intro keeps its visible SKIP. * * This holds only because main.css exempts the whole .dd-hero subtree from the * global reduced-motion duration reset. Without that exemption the bands still * fly, but in 0.4s instead of 1.2s, which looks fired rather than flown. */ /* --- Controls ------------------------------------------------------------ */ .dd-hero__controls { position: absolute; z-index: 6; left: var(--dd-hero-inset); bottom: clamp(1.25rem, 3vh, 2.25rem); display: none; align-items: center; gap: 1rem; } .dd-js .dd-hero__controls { display: flex; } .dd-hero__dots { display: flex; align-items: center; gap: 0.75rem; } /* * The controls sit inside the strip the floating CTA reserves at the bottom of * every scrollport (--dd-cta-reserve, main.css). A button that starts below the * padded band counts as off-screen, so the browser CENTRES it the moment it * takes focus — clicking a dot or tabbing to it scrolled the first screen 371px * out of the fold, which is the one thing this hero is built not to do. The * reserve exists for anchors that would otherwise hide behind the pill; these * two sit in the opposite corner and need none of it, so they give it back. */ .dd-hero__dot, .dd-hero__playpause { scroll-margin-block-end: calc(-1 * var(--dd-cta-reserve)); } .dd-hero__dot { width: 44px; height: 44px; padding: 0; border: 0; background: transparent; cursor: pointer; /* the target is 44px; what is painted is the 10px pip in the middle of it. 62% is the floor that keeps the idle pip at 3:1 on the near-black ground (WCAG 1.4.11) — it is a control, not decoration. */ background-image: radial-gradient(circle at 50% 50%, rgb(227 172 134 / 62%) 0 5px, transparent 5px); } .dd-hero__dot.is-active { background-image: radial-gradient(circle at 50% 50%, var(--dd-color-accent-light) 0 6px, transparent 6px); } .dd-hero__dot:hover { background-image: radial-gradient(circle at 50% 50%, rgb(227 172 134 / 80%) 0 6px, transparent 6px); } .dd-hero__playpause { display: flex; align-items: center; justify-content: center; width: 44px; height: 44px; padding: 0; border: 0; background: transparent; cursor: pointer; color: var(--dd-color-accent); } .dd-hero__playpause:hover { color: var(--dd-color-accent-light); } /* two bars while the track is running, one triangle once it is stopped */ .dd-hero__playpause-icon { display: block; width: 12px; height: 14px; border-inline: 4px solid currentcolor; } .dd-hero__playpause[data-state='stopped'] .dd-hero__playpause-icon { width: 0; height: 0; border: 7px solid transparent; border-inline-start: 12px solid currentcolor; } /* --- Mobile ------------------------------------------------------------ */ @media (max-width: 768.98px) { /* stacked: the picture takes the top of the fold, the copy closes it from below, and the bands still cross the whole slide */ .dd-hero__slide { /* * Below the two-column breakpoint the fold does not grow with the width, * but 1.62vw of type does — so every pixel the headline gained between * 390 and 768 came straight out of the portrait, which is the flexible * row here. Measured: 260px of portrait at 390 but 224px at 600, i.e. * the picture the client asked to enlarge by 30% was SMALLER on a tablet * than on a phone. The width term grows at 1.1vw instead, which holds the * headline within 6–13% of what it was and hands the difference back. * * The HEIGHT term is the 10.08 correction. Width was the only thing this * scale ever read, and a phone is short before it is narrow: measured at * 375x553 the copy block stood 395px tall in a 409px stage — taller than * the whole of the fold it had to share with a photograph — so it climbed * onto the portrait until it covered his face. `min()` of the two clamps * means the type is bounded by whichever axis is scarcer, so a 768px * tablet keeps the 30.5px it has today and a 553px phone is given 18px. * * svh, not vh: a vh-driven font-size re-sizes every line of the hero when * the address bar collapses under the reader's thumb. * * The SLOPE of the height term is the 11.08 correction, and the complaint * it answers is "nadal widoczne są różnice w ekstrapolacji tekstu i zdjęć * na różnych smartfonach". At 2.6svh the height term is not a guard, it is * the driver: it decided the size on every phone in the grid, and because * phones differ in height far more than in width it made the headline * 18.4px on one handset and 26.6px on the next - a 45% spread on two * phones held side by side, which is exactly the difference the client * photographed. Nothing about a taller phone earns a headline half again * as large. * * At 1.25svh the same term still bottoms out where it has to and still * reaches its ceiling at a tablet's 1024px, so 768x1024 keeps the size it * has today - but across the phone band it moves 21.3px to 25.3px instead * of 18.4 to 26.6. The floor rises with it, which is the direction the * 10.08 fix was pushing against; the guard against that is measured rather * than assumed, in ops/qa-scripts/short-viewport.js, which reports where * the copy block starts against the portrait it lies over. */ --dd-hero-lead: min( clamp(1.7rem, 1.38rem + 1.1vw, 2.5rem), clamp(1.15rem, 0.9rem + 1.25svh, 1.7rem) ); /* * What the copy owes the bottom of the fold. * * It used to be the floating CTA's whole reserve plus 3.25rem — 140px of * a 520px stage — because the control row was parked ABOVE the pill to * keep clear of it. The row is beside the pill now (see .dd-hero__controls * below), so this clears one strip instead of two stacked ones: the pill * ends 64px above the foot, and 5rem leaves it 16px. */ --dd-hero-copy-foot: 5rem; /* * The veil's fade, as a length rather than as a share of the field. * * The gradient used to spend its fade over the top 18% of the copy block, * which is only safe while that block is tall: at 553px of viewport 18% * was 65px and it started on his chin, so the first line of copper type * sat on a half-strength veil over a pale blue shirt. Stated as a length * it is exactly the run-up above the type, at every fold, and the veil is * therefore at full strength across every line it carries. */ --dd-hero-veil-fade: 3rem; /* * How much of the photograph the copy is allowed to lie over. * * The one number the 23.08 complaint is about, and until now it did not * exist: the overlap was the remainder left between a portrait sized as * a share of the fold and a copy block pinned to the foot, so it was * 9% of the picture on one phone and 57% on another. Declared, it is the * same strip on every window, and it is deliberately small — the client * allowed type over the photographs ("nie będzie problemem aby tekst * wchodził na zdjęcia") and the composition wants the contact, but he * has now twice said how much is too much. */ --dd-hero-copy-overlap: 2rem; /* * The stage: the fold, unless the fold is smaller than the copy needs. * * The base rule's floor was 480px, which on a phone with its address bar * showing is TALLER than the fold — measured at 375x553, where the slide * ran to 624px in a 553px window and took the dots and the last line of * copy off the bottom of the screen. On a portrait phone the fold is the * whole of the design budget and nothing may exceed it. * * The floor still has a job, though, and it is a phone held sideways: at * 740x360 the fold is 288px, and the copy block alone is 331px whatever * the composition does. There the section is allowed to run past the fold * and be scrolled to, which is the lesser of the two failures — the other * one clips it. 400px is the copy block plus a photograph worth showing, * and it is under the shortest portrait fold in the grid (449px at * 375x553), so it never binds on the phones this fix is about. * * Both the floor and the portrait read this, or the picture goes on * sizing itself against a fold the slide is no longer using. */ --dd-hero-stage: max(400px, var(--dd-hero-fold)); min-height: var(--dd-hero-stage); display: flex; flex-direction: column; justify-content: flex-end; padding-block-end: var(--dd-hero-copy-foot); } /* * The one screen where the fold is genuinely full: a portrait, three blocks * of copy, the dots and the pill. The portrait is the flexible one — it * shrinks to whatever the copy leaves — so every gap on this screen is * spent out of the picture, and they are set as tight as they can be while * still reading as gaps. */ .dd-hero__slide--first { justify-content: center; gap: clamp(0.5rem, 1.6vh, 1.1rem); /* the portrait shrinks to fit the fold, and with nothing above it the top of the frame ended flush against the black bar — measured at 390: bar ends 144, picture began 145. */ padding-block-start: clamp(0.5rem, 2vh, 1.25rem); } .dd-hero__slide--first .dd-hero__portrait { order: -1; align-self: center; flex: 0 1 auto; width: auto; /* the +30% the client asked for has to survive the tablet too: the old ceiling of 250px was reached at 431px of viewport, so every width from there to 768 showed the same portrait with ever more black around it — 250px of picture on a 768px screen */ height: min(460px, calc(clamp(226px, 46vw, 340px) / 0.6775)); min-height: 0; /* level with the other two photographs (M-2) and below the copy, which M-1 lays over it — at 5 the portrait would have covered its own text */ z-index: 3; } /* * On the phone the photograph is a row of the slide, not a layer pinned to * its top. As a layer it held a fixed 46% of the fold and letterboxed the * picture inside it, so the treatment room — a wide frame in a tall box — * left 301px of black between itself and its caption on a 390px screen, * and the upright sculpture came out 195px wide on a 768px one. As a * growing flex row the box is the picture: it takes the height the copy * does not need, and both pictures fill it. */ .dd-hero__slide--gabinet .dd-hero__media, .dd-hero__slide--figura .dd-hero__media { position: relative; inset: auto; /* * M-2, and it is the client's own proposal: "Zbyt duże zachodzenie/ * przysłanianie pasami szarymi. Możecie je zredukować, lub wykonać tak, * aby wsuwały się pod zdjęcia? Tak jak w przypadku mojego zdjęcia (nr1)?" * * Screen 1 never drew the complaint because its portrait is at 5 and the * bands at 2. These two were at 1 — under them — and on a 390px screen * the wider band is 343px across, so it covered 94% of the treatment * room. Level 3 is above the bands and below the copy, which is what * M-1 needs on top. */ z-index: 3; order: -1; display: flex; flex: 1 1 auto; justify-content: center; width: 100%; min-height: 0; padding-inline: var(--dd-gutter); } /* * The two pictures used to be driven along different axes here, because that * was the only way `contain` stopped letterboxing them in a box of its own * height. The image is now sized by its own content (see .dd-hero__media), * so both are bounded on both axes and the browser fits each one the way * `contain` did — the wide frame by its width, the upright one by its height * — without either being told which. */ .dd-hero__slide--gabinet .dd-hero__media { flex: 0 1 auto; align-items: center; } .dd-hero__slide--figura .dd-hero__media { justify-content: center; } .dd-hero__slide--gabinet, .dd-hero__slide--figura { justify-content: center; gap: clamp(0.75rem, 2.4vh, 1.5rem); padding-block: clamp(1rem, 3vh, 1.75rem) var(--dd-hero-copy-foot); } .dd-hero__slide .dd-hero__field { position: relative; inset: auto; width: 100%; max-width: 34rem; padding: clamp(1rem, 3.5vw, 1.75rem) var(--dd-gutter); } .dd-hero__slide--first .dd-hero__field { flex: 0 0 auto; padding-block: clamp(0.5rem, 2vw, 1rem) clamp(1rem, 3.5vw, 1.75rem); /* * The veil is a band across the slide, so the box that paints it may not * be narrower than the slide. 34rem is 544px and every phone in the grid * is narrower than that, so the cap was invisible there and only showed * at 768: a 544px scrim on a 768px stage, with a hard vertical edge down * the middle of the composition where it crossed the grey wedges. The * measure it was protecting belongs to the type, which is where it is * now — same wrap, no rectangle. */ max-width: none; } .dd-hero__slide--first .dd-hero__field-inner { max-width: 34rem; } /* * The wedges, restated as an ANGLE. * * The lean is declared as a share of each band's own width — a percentage * inside clip-path resolves against the element's box, which is the trap the * right-hand band's comment already documents. That is survivable on a wide, * short desktop stage, where the three bands are 749/446/221px across a 786px * fold. It is not survivable on a phone, where the stage turns portrait: the * same three rules measured 18.9° / 15.2° / 8.7° at 1440x900 and * 9.6° / 7.6° / 3.0° at 390x844. * * Two things go wrong at once there. The diagonals flatten until they read as * vertical slabs with a slight cant — a mistake rather than a decision. And * because the three angles differ, the edges CONVERGE: the gap between the * wide left band and the right-hand wedge closed to a point partway down the * screen and left a white shard in the middle of the composition. The angle * was not even stable on one phone — 14.3° with the address bar showing, * 9.6° without it, because the run follows the width and the height follows * the fold. * * So the run is stated once, as a length off the stage's own height. Every * band takes the same one, which makes the edges parallel — parallel edges * cannot pinch, whatever the window does — and 0.222 of the stage is 12°, * which is the angle the widest band already had here and close to what the * eye reads on the desktop the client approved. * * The widths follow from it rather than being set beside it. A fixed run eats * the same absolute width out of every band, so a flat percentage no longer * describes anything: stated as 88%/52%/26% the wedges came out with a 0%, * 0% and 28% face on a 390px screen — two bare triangles and a sliver — and * the right-hand one landed exactly on top of the wide one's diagonal, which * closed the dark gap between the planes that is the whole composition. * * So each band is written as WHAT IT LEAVES at its narrow end, plus the run. * The three faces are the desktop's own proportions, measured at 1440x900: * the wide plane ends a third of the way across, the narrow one at a sixth, * and the right-hand wedge keeps a seventh of the window. Because all three * carry the same run, the dark stripe between them is the same width at the * top of the fold as at the bottom, at every screen height. */ .dd-hero__slide { --dd-hero-band-run: calc(var(--dd-hero-stage) * 0.222); } .dd-hero__band--a { width: calc(33% + var(--dd-hero-band-run)); clip-path: polygon(0 0, 100% 0, calc(100% - var(--dd-hero-band-run)) 100%, 0 100%); } .dd-hero__band--b { width: calc(16% + var(--dd-hero-band-run)); clip-path: polygon(0 0, 100% 0, calc(100% - var(--dd-hero-band-run)) 100%, 0 100%); } /* The phone keeps the geometry it had: D7 is a desktop correction (the mail says so — "patrząc na stronę przez pryzmat laptopa/komputera"), and the phone's own complaint about these bands was M-2, which is about layering, not reach. Only the base changes here; the run follows it, so the angle is the same as it has always been at this width. */ /* * M-1 — the two upright photographs, larger. * * This lives in the 768.98 branch, not in the 480 one it was first written * for. Confined to 480 it produced the defect round 1 spent a paragraph * fixing for the portrait — a picture that SHRINKS as the screen grows: * the sculpture measured 467px tall at 390 and 398px at 480, because 480 * fell back to the old arrangement where the copy takes a row of the fold. * 768.98 is where this file already switches composition, so that is the * boundary the change belongs on. * * "zbyt małe zdjęcia 1 i 3, czyli pionowe. Można je powiększyć spokojnie * o 30-50%. Nie będzie problemem aby tekst wchodził na zdjęcia." * * Nothing was holding these pictures at a declared size — the fold was. Each * of these slides is a flex column and the picture is its elastic row, so it * got whatever the copy left: 267px of portrait against a 334px ceiling that * was never reached. Enlarging therefore starts by taking the copy out of the * column, which is precisely the permission the client gave in his second * sentence. The copy becomes a layer at the foot of the fold and the picture * takes the whole of it. * * The scrim is a full-width band, not a patch behind the words: the copy * measures 350px on a 390px screen and the upright pictures are 253-277px * across, so the text cannot sit inside either of them. Its own colour is * this slide's ground (#070403), already used this way at the top of the * file — no new colour enters the palette. * * The ceiling has to come up with the floor, or freeing the fold buys * nothing: 226px of declared width is 334px of height, below the 347px that * +30% of the measured portrait would be. */ .dd-hero__slide--figura .dd-hero__field { position: absolute; inset: auto 0 0 0; } /* * Screen 1's copy is back IN the column, and screen 3's is not. The split is * deliberate and it is the 23.08 fix. * * Out of flow, the picture and the copy know nothing about each other: the * portrait takes a share of the fold, the copy is pinned to the foot, and how * much of the man the type covers is whatever is left over between two * independent numbers. Measured across the window grid that left-over ran * from 9% to 57% of the photograph — one site, one stylesheet, and the client * holding two phones that disagree. No tuning of either number fixes that, * because the quantity he is complaining about is not written down anywhere. * * In flow it is written down: the copy overlaps the picture by exactly * --dd-hero-copy-overlap, and the portrait is the elastic row, so a fold too * short for both shrinks the PHOTOGRAPH and leaves the overlap alone. * * Screen 3 keeps the layer. Its picture is dark, its copy is one block, and * its composition was approved on 11.08 — there is nothing to fix and a fix * would be a change. */ .dd-hero__slide--first .dd-hero__field, .dd-hero__slide--figura .dd-hero__field { z-index: 4; justify-content: flex-end; /* * The top padding is the veil's run-up, not breathing room. The scrim * has to be at full strength across every line of type and spend its * fade ABOVE the first one; with 2.5rem there was nowhere to spend it, * the first line sat on about half the veil, and measured against the * pale shirt behind it the copper came out at 2.2-2.7:1 — under the 4.5 * this layout owes its own copy. */ padding-block: var(--dd-hero-veil-fade) var(--dd-hero-copy-foot); /* * A veil, not a fade. The first draft ran 92% at the foot to nothing at * the top of the field, which put the opening line of copy on ~9% of * scrim — and on screen 1 that line lands on a pale blue shirt, where * copper measured nowhere near 4.5:1 and simply could not be read. * * So the scrim holds its strength across the whole of the type and * spends its fade in the strip above it. On screen 1 that strip covers * the bottom quarter of the portrait, which is his folded arms; on * screen 3 the picture is dark to begin with and the veil barely * registers. * * The fade is the run-up, exactly — `calc(100% - fade)` rather than the * 82% it was written as. A percentage is only the run-up while the field * happens to be ~440px tall, and on a short phone it was 65px of fade * reaching up onto his chin. This way the two cannot drift apart. * * Held at 94/92%, and an attempt to lend some of it back to the animation * is recorded here so it is not tried a second time. Below this veil a * flying band changes what it crosses by a contrast of 1.03, against * 2.1-2.6 above it, so the veil looks like what is killing the movement * on a phone. It is not. Dropped to 82/78% the bands went to 1.12 — and * the copper fell from 5.76:1 to 3.83:1, under the 4.5 this layout owes * its own copy. Both numbers measured, not modelled. * * The reason the veil buys so little is that under it the band is not * behind the WASH, it is behind the PHOTOGRAPH: the pictures sit at * z-index 3 and the bands at 2, which is M-2, the client's own * instruction that they slide underneath. Where the photograph is, no * veil setting can make a band visible. */ background: linear-gradient( to top, rgb(7 4 3 / 94%) 0, rgb(7 4 3 / 92%) calc(100% - var(--dd-hero-veil-fade)), rgb(7 4 3 / 0%) 100% ); } .dd-hero__slide--first .dd-hero__field { position: static; /* * How far the type lies over the photograph, stated once. * * The margin has to carry the veil's run-up as well: the fade is spent * in the strip above the first line, so pulling the field up by the * overlap alone would start the type a whole fade BELOW the picture and * the two would no longer touch at all. */ margin-block-start: calc( -1 * (var(--dd-hero-veil-fade) + var(--dd-hero-copy-overlap)) ); /* the foot belongs to the slide here, and paying it twice would reserve two strips for one row of controls */ padding-block-end: 0; } /* * The photograph is what gives way when the fold is too short for both. * * `flex: 0 1 auto` was already on this element and never did anything, * because the copy beside it was out of flow and the column therefore never * ran out of room. It does now, and the order of preference this encodes is * the client's own from 23.08: he would rather see all of a smaller * photograph than most of a larger one. * * The floor stops that trade going somewhere absurd. Below ~150px the * picture is a thumbnail of a man and there is nothing left to protect; at * that point the slide is allowed to outgrow the fold instead, which is the * same concession the landscape rule at the foot of this file already makes. */ .dd-hero__slide--first .dd-hero__portrait { min-height: 150px; } /* * The picture takes the top of the fold and the copy closes it from below, * so the two overlap only where the veil is already at full strength. * * `space-between` rather than `flex-start`, and the difference only shows on * a window with room to spare. Started, a 768x1024 tablet put its whole * composition in the top 737px and left 183px of black under the copy — * a void that did not exist while the copy was a layer pinned to the foot. * Spread, the copy is at the foot again wherever there is slack, the picture * still starts under the bar, and the gap between them is whatever is left * over. On a phone there is nothing left over, the two meet, and the * negative margin above puts the type over the picture by exactly * --dd-hero-copy-overlap. */ .dd-hero__slide--first { justify-content: space-between; padding-block-start: clamp(0.75rem, 2.5vh, 1.5rem); } /* * Both pictures are held at the TOP of the client's own bracket rather than * at what the freed fold would allow. Taking the copy out of the column left * room for +83% on the portrait and +79% on the sculpture; he wrote * "o 30-50%", and a picture nearly twice the size he sanctioned is a * different decision, not a generous reading of his. * * The two screens do not land in the same place inside that bracket, and the * reason is the photographs rather than the layout. The sculpture is dark, so * the copy can lie over it at almost any size. The portrait is on a white * studio ground, and every extra pixel of it puts another line of copper type * on a pale blue shirt — so it takes the lower half of the client's range, * where the overlap stays shallow enough for the veil to carry it. * * Sized against the FOLD, not against a flat pixel ceiling. A ceiling reached * the same 285px on every phone, and the gain the client would see depended * entirely on his window: +30% on a 844-tall screen, where the old picture * was squeezed to 219px, but +7% on a 900-tall one, where it already had 267. * A share of the fold grows with the screen, so the enlargement is real * wherever he looks at it. */ /* * 0.55, up from the 0.47 this shipped with, and the change is paid for by the * copy rather than taken from the picture's clearance. * * The fraction was tuned when the copy block cost 140px of foot and a fade * that grew with it; both are now fixed strips, and the type is bounded by * the fold as well as by the width. That gave the fold back ~90px on a phone, * and it goes to the photograph the client twice asked to see larger. * * The safety this has to keep is a measured one, not a feeling: on the source * file (1000x1476) his beard ends at 44% of the frame and his collar at 50%, * so copy may begin anywhere below ~55% and still be on his chest. Checked * across 360x640 / 375x553 / 390x664 / 390x844 / 430x932 / 768x1024 — the * worst of them starts the copy at 62% of the picture. */ .dd-hero__slide--first .dd-hero__portrait { /* * A preferred height, not a settled one. The column shrinks it when the * copy needs the room (see .dd-hero__slide--first .dd-hero__field), so * this says how large the photograph may be, and the fold says how large * it gets to be. * * A third term used to stand here, `stage - 14rem`, guarding against the * copy landing on his collar on the shortest phone. It went out with the * absolute positioning that made it necessary, and it is worth recording * that it never did the job it claimed: its comment read "14rem is what * the copy and its foot actually occupy there", and the measurement on * 23.08 put that block at ~395px — 24.7rem. It was guarding a number it * had wrong by 10rem, which is why the guard held on paper while the * client was looking at type across the middle of his own chest. */ height: min(460px, calc(var(--dd-hero-stage) * 0.55)); } .dd-hero__slide--figura .dd-hero__media { max-height: 52svh; } /* * The picture now owns the fold; the copy no longer takes a row from it - * and as of 11.08 it starts the fold rather than being centred in it. * * "Co do zdjęcia z rzeźbą, to proszę o uniesienie jego, prawie pod pole z * logo", written directly under the phone screenshots. The copy on this * screen is out of flow and pinned to the foot (see .dd-hero__field above), * so the photograph is the only flex item left and it is capped at 52svh - * which means `center` was splitting everything the cap does not use between * the picture's head and its foot. Measured: 77px of black under the bar at * 390x664 and 110px at 412x870. The taller the phone the further it sank, * which is the other half of the same message ("różnice w ekstrapolacji ... * na różnych smartfonach") arriving through the layout rather than the type. * * Started, it sits on the slide's own top padding - the same ~16px of ground * under the bar that screen 1's portrait keeps. Nothing is cropped and * nothing is resized: the cap, the frame and "koniecznie w kadrze pionowym, * nie kadrować" are all untouched, the picture only moves. The slack it * leaves goes to the foot, where the veil and the copy already live. */ .dd-hero__slide--figura { justify-content: flex-start; } /* * The right-hand wedge joins the same family: one run, so its edge stays * parallel to the two on the left instead of closing on them. * * Its face is a seventh of the window, the share it holds on the desktop the * client approved, and its total reach is that plus the shared run. The reach * therefore grows — 26% of the window before, ~47% at 390 now — but that is * arithmetic, not a change of mind: at 101px of width against a 124px run * there is no face left at all and the band is a bare triangle. * * It does not put more grey over the photographs than before. Since M-2 these * bands sit UNDER them (z-index 3 against 2), so what grows is the part in the * dark margin beside the picture — the only place the wedge is seen on a * phone at all. */ .dd-hero__band--right { --dd-hero-band-right-base: calc(15% + var(--dd-hero-band-run)); --dd-hero-band-right-run: var(--dd-hero-band-run); --dd-hero-band-right-trim: 0px; } /* * The controls and the floating CTA pill share the bottom of the fold, and * the pill owns the right-hand corner. The row used to be parked ABOVE the * pill, because at 44px a target each it is 192px wide and the pill's left * edge is at (width - 173) — measured, so on a 360px screen the last dot ran * 25px INSIDE the pill and a thumb aiming at the third screen dialled the * clinic. Stacking them was correct and it cost 136px: every slide had to * hold its copy above a control row that was itself held above the pill. * * On a phone that strip is a quarter of the stage, and it is what left the * portrait 130px wide with the copy on his face. So the row is tightened * until it fits BESIDE the pill instead: 36px targets and 2px between them * make it 152px, which clears the pill by 15px at 360 and by more at every * width above it. Both rows then share one 64px strip. * * 36px is a deliberate step down from the 44px of WCAG 2.5.5 (AAA) and stays * half again over the 24px of 2.5.8 (AA, the level this site is held to). * What is painted does not change — the pip is 10px inside the target either * way — so the row reads the same and only the dead space around it shrinks. */ .dd-hero__controls { left: var(--dd-gutter); bottom: 0.75rem; gap: 0.25rem; } .dd-hero__dots { gap: 2px; } .dd-hero__dot, .dd-hero__playpause { width: 36px; height: 36px; } } /* * A phone held sideways is the one window where the fold cannot be honoured. * * 740x360 leaves 288px of fold under a 72px bar, and the copy block alone is * 331px at the floor of its own scale — there is no arrangement of a portrait * and three blocks of type that fits. The section is therefore allowed to run * past the fold and be scrolled to, exactly as it did before this round (the old * 480px floor overran by 192px; this overruns by 182), and the stage is given * the height the composition actually needs so that what the visitor scrolls to * is right: at 470px the copy starts at 59% of the picture, on his chest. * * The portrait phones this fix is about never reach this rule, and the 400px * floor above never binds on them either — the shortest fold in the grid is * 449px at 375x553. */ @media (max-width: 768.98px) and (orientation: landscape) { .dd-hero__slide { --dd-hero-stage: max(470px, var(--dd-hero-fold)); } } /* * The narrow-phone branch used to lift the control row over the pill and make * every slide reserve the height of both. The row is 152px wide now and clears * the pill on its own at 360px, which is the narrowest width this site is built * for, so there is nothing left for this branch to correct — see the reasoning * on .dd-hero__controls above. It is gone rather than emptied, because what it * reserved was the 140px of foot that put the copy on dr Zawadzki's face. */