/* ========================================================================== Press Releases listing page (Figma: QF - BilAraby - WebsiteDesign-Concept-2, node 40000567:27709 "Press Releases"). Reuses the --hr-* tokens declared globally in layout-revamp.css. NOTE: .pr-hero below reproduces the same "Innerpage-hero" component used by About Us (.abt-hero), Contact Us (.cta-hero) and the Speakers listing (.spk-hero), differing only in the banner asset (getBanner('press_release') here, already wired admin-side, same as .spk-hero-bg/getBanner('speakers')). ========================================================================== */ /* yellow-500 (#d98500), not yellow-400 (#e19d33): Figma's heading (node 40000567:27717) sets the "News" span to #d98500, which is the yellow-500 token. The 400 that was here rendered a lighter, more amber orange. */ .press-releases-revamp .hr-accent { color: var(--hr-yellow-500); } /* Figma layers a soft radial dark vignette (rgba(0,0,0,.17) fading to transparent, centred near the top) over the gradient banner — without it the hero reads as a flat, uniform gradient instead of Figma's slightly moodier top. Reproduced as a second background layer on the same 704px canvas the banner itself is sized to. */ .press-releases-revamp { position: relative; /* The filter pill's raised state, shared by the active tab and the hover preview of it. Same four layers the videos listing carries as --vid-pill-shadow and the Search page as --srp-pill-shadow - three ambient drops under an inset white highlight. Was written out inline on .pr-tab.is-active; a token so the hover below cannot drift from it. */ --pr-pill-shadow: inset 0 4px 6.1px rgba(255, 255, 255, .23), 2px 23px 14px rgba(0, 0, 0, .02), 1px 10px 10px rgba(0, 0, 0, .03), 0 3px 6px rgba(0, 0, 0, .03); --pr-hero-h: 256px; background: var(--hr-cream-400) var(--pr-hero-bg) no-repeat top center; /* The band has to die above .pr-head's title, so it is derived from the hero rather than fixed. hero-banner.svg is fully transparent at 86% of its own box, so scaling to 1/0.86006 = 1.16271x the distance to cover lands the last trace of teal on the far edge of it. The distance is the hero plus 50px: .pr-listing's 64px padding-top, less ~14px of clearance so the fade finishes just before the title rather than on it. Copying About Us's flat 424px was the bug - that value is tuned to .abt-intro's 120px padding-top, and .pr-listing has only 64px, so the tail ran 45px into "BilAraby in the News". Deriving it also fixes the tablet and mobile bands, which a retuned fixed value would not: the hero shrinks there while the 64px padding does not, so the overlap came back at every breakpoint below desktop. */ background-size: 100% calc((var(--pr-hero-h) + 50px) * 1.16271); } /* Figma's angular corner wedges inside the Innerpage-hero instance: two DISTINCT vectors, "Pattern-01" (left, 305.329x160.658) and "Pattern-02" (right, 305.29x204.731, mix-blend-mode: overlay), each carrying its own cream(#f9f7ea)-to-transparent gradient at 10% fill-opacity baked into the asset. Shared verbatim with .abt-hero-decor / .cta-hero-decor / .pp-hero-decor. This page previously stretched ONE shared flourish across 37% of the band and mirrored it onto both sides. That is a different shape entirely, and scaling it by percentage meant it never held Figma's geometry at any width. Fixed sizes bottom-aligned in the band reproduce it, and .pr-hero-decor already tracks .pr-hero's height at the tablet/mobile breakpoints below, so the pair stays flush with the breadcrumb as the band shortens. The slight blur softens the vector edges to match how the wedges read in Figma's own render, where the 10% gradient dissolves into the teal rather than showing a hard diagonal. */ .pr-hero-decor { position: absolute; top: 0; left: 0; width: 100%; height: var(--pr-hero-h); overflow: hidden; pointer-events: none; z-index: 0; } .pr-hero-decor img { position: absolute; bottom: 0; max-width: none; filter: blur(1.5px); } .pr-hero-decor-left { left: 0; width: 305.329px; height: 160.658px; } .pr-hero-decor-right { right: 0; width: 305.29px; height: 204.731px; mix-blend-mode: overlay; } /* RTL keeps each pattern on its own visual side by flipping the pair, so the composition mirrors with the text direction instead of the taller wedge always sitting on the right. */ [dir="rtl"] .pr-hero-decor-left { left: auto; right: 0; transform: scaleX(-1); } [dir="rtl"] .pr-hero-decor-right { right: auto; left: 0; transform: scaleX(-1); } /* ---------- Hero / breadcrumb banner ---------- */ .pr-hero { position: relative; z-index: 1; height: var(--pr-hero-h); display: flex; align-items: flex-end; padding: 0 160px 24px; } .pr-hero-inner { position: relative; z-index: 1; max-width: 1600px; width: 100%; margin-inline: auto; } .pr-breadcrumb-row { display: flex; align-items: center; justify-content: space-between; gap: 24px; } /* Type scales with the viewport instead of sitting at a flat 20px, which on a 375px phone left "PRESS RELEASES" ellipsised to "PRESS RELEA...". Same fluid clamp as .tnc-breadcrumb / .pp-breadcrumb rather than a breakpoint step, so the trail shrinks continuously and there is no width at which it is still just too wide. The 20px ceiling keeps the Figma size untouched on desktop, and the 13px floor keeps it legible. Gap and separator scale alongside so the spacing stays proportional rather than dominating at small sizes. */ .pr-breadcrumb { display: flex; align-items: center; gap: clamp(8px, 2.2vw, 12px); min-width: 0; font-size: clamp(13px, calc(5vw - 3px), 20px); color: var(--hr-cream-500); text-transform: uppercase; } /* Full strength, not .8. Figma's Breadcrumb (inside the Innerpage-hero instance, nodes I40000567:27711;40000160:34083;40000046:12838 / :12840) sets HOME and ABOUT to a flat #f9f7ea with no opacity of their own - only the FONT WEIGHT separates them from the current crumb (Regular vs Bold). The .8 here dimmed them a further 20% on top of that, which is the difference visible between the two reference screenshots. Side effect worth knowing: the crumbs used to brighten .8 -> 1 on hover, so hover is now the underline alone. Figma defines no hover state for this component either way. */ .pr-breadcrumb a, .pr-breadcrumb span:not(.pr-breadcrumb-sep) { opacity: 1; } /* nowrap + no shrink keeps each crumb whole: they are shrinkable flex items, so they get squeezed below their text width and break internally even when the row has room. .pr-breadcrumb-current is deliberately excluded - it stays shrinkable so the article title can still ellipsise (see below). */ .pr-breadcrumb a, .pr-breadcrumb span:not(.pr-breadcrumb-sep):not(.pr-breadcrumb-current) { white-space: nowrap; flex-shrink: 0; } .pr-breadcrumb a { color: inherit; text-decoration: none; transition: opacity .2s ease; } .pr-breadcrumb a:hover { opacity: 1; color: inherit; text-decoration: underline; } /* The article title here can run long, so - unlike the other (short, static) crumbs - this one is allowed to shrink and truncates to one line with an ellipsis instead of wrapping tall enough to push "Home / Press Releases" off the top of the fixed-height hero on narrow viewports. */ .pr-breadcrumb-current { font-weight: 700; opacity: 1 !important; min-width: 0; overflow: hidden; white-space: nowrap; text-overflow: ellipsis; } .pr-breadcrumb-sep { flex-shrink: 0; width: 1px; /* Tracks the type: a fixed 16px rule looks oversized beside 13px text. */ height: clamp(11px, 0.9em, 16px); background: rgba(249, 247, 234, .5); } .pr-hero-divider { display: none; } @media (min-width: 1200px) { .pr-hero-divider { display: flex; align-items: center; flex-shrink: 0; width: 300px; margin-inline-end: calc(-160px - max(0px, (100vw - 1920px) / 2)); } /* Matches .abt-diamond on About Us, which .tnc-diamond and .pp-diamond also follow - this page was the last on the old 14px recipe, so its diamonds rendered 20px wide against the other pages' 28px and the trail ran 42px shorter, leaving a visibly longer line beside it. 20 * (sqrt(2) - 1) / 2. A rotated 20px square is 28.28px wide visually but still occupies a 20px layout box, so the 4.142px overhang per side would make neighbours merge into one continuous zigzag. This margin separates the boxes by exactly that overhang, so adjacent tips just touch - corner to corner, 0px visible gap, no merge. Carried on the diamond rather than as a `gap` on the row so the last one also spaces itself off the line. Scoped to .pr-hero-divider: .smt-hero-diamond is the summit pages' class, borrowed by this markup, and they size it from their own --smt-diamond. */ .pr-hero-divider .smt-hero-diamond { width: 20px; height: 20px; margin-inline: 4.142px; transform: rotate(45deg); background: var(--hr-cream-500); flex-shrink: 0; } /* margin-inline-start: 0 - the last diamond's own slot margin supplies the gap now, so a negative offset here would eat into it. */ .pr-hero-divider-line { flex: 1 1 auto; height: 1px; background: rgba(249, 247, 234, .5); margin-inline-start: 0; } } .pr-hero::after { content: ""; position: absolute; inset-inline: 0; bottom: 0; height: 1px; background: rgba(249, 247, 234, .35); } /* ---------- Listing section ---------- */ .pr-listing { position: relative; z-index: 1; padding: 64px 160px 100px; overflow: hidden; } .pr-listing-inner { position: relative; z-index: 1; max-width: 1600px; margin-inline: auto; } /* 80px, matching the gap below the filter row. Figma's listing frame (node 40000567:27713) puts the heading block at y=0 h=120 and the filter row at y=200 - an 80px gap - and uses that same 80 for filters->cards and cards->pagination, so the page runs on one vertical number. This was at half of it. Tightened to 40 on phones by the <=767 block, in step with the filter row's own mobile override. */ .pr-head { margin-bottom: 80px; } .pr-head h1 { font-size: 40px; font-weight: 700; color: var(--hr-brown-500); margin: 0 0 12px; } .pr-head p { font-size: 20px; color: var(--hr-brown-300); margin: 0; } /* ---------- Filters ---------- */ /* 80px below the row, not 40. Figma's listing frame (node 40000567:27713, the 1600 column) puts the filter row at y=200 h=48 and the card list at y=328 - an 80px gap - and uses that same 80 for heading->filters and list->pagination, so the whole page's vertical rhythm is one number. This was running at half of it, which read as the first card crowding the filters. Tightened back to 40 on phones by the <=767 block, where 80px of dead space costs a whole card's worth of scroll. */ .pr-filters { display: flex; flex-wrap: wrap; align-items: center; gap: 16px; margin-bottom: 80px; } /* Inert above the phone breakpoint: the wrapper exists only so the year tabs, the topic select and the date pill can scroll as ONE row down there (see the <=767 block), and display:contents leaves this row the same flat flex it has always been. */ .pr-filter-row { display: contents; } /* The auto end-margin is what keeps the field pills and the search box grouped at the end of the row. justify-content: space-between did that on its own while .pr-filters had exactly two children, but the search box is now a third - it moved out of .pr-filters-fields so it can sit on its own row on a phone - and space-between spreads a line's items to BOTH ends: on the wrapped line this row breaks into once the year list is long enough (measured: the tabs reach their content width well before 1200), it would have flung the search box to the far end with a gap beside the field pills. An auto margin only absorbs the free space on the line it sits on, so line one still pins the tabs to the start and the wrapped line below packs at the start exactly as the single .pr-filters-fields item used to. */ .pr-filters-tabs { display: flex; gap: 16px; flex-wrap: wrap; margin-inline-end: auto; } .pr-tab { display: inline-flex; align-items: center; /* BIL-581 "filters look thick": every control in Figma's filter row (node 40000567:27719) is a 48px pill - px-20 py-12 on a 24px line box, with its 1px stroke INSIDE the frame (Figma's default strokeAlign), which the row's metadata confirms as 48px frames throughout. In CSS the border sits outside the padding, so a literal 12px reading measures 12+24+12+2 = 50. Padding-block drops so each box totals Figma's 48; the controls that run a 40px line box for the Arabic descender fix take 3px instead of 11px for the same 48. */ padding: 11px 20px; border-radius: 61px; font-size: 16px; color: var(--hr-brown-500); background: rgba(236, 230, 211, .4); border: 1px solid rgba(177, 175, 165, .5); text-decoration: none; white-space: nowrap; transition: background-color .2s ease, border-color .2s ease, box-shadow .2s ease, transform .2s ease; } .pr-tab:hover { text-decoration: none; color: var(--hr-brown-500); } /* Hovering an inactive tab previews the active pill exactly - same cream-50 fill, white rim and shadow - plus a 2px lift, which is how the videos listing (.vid-tab) answers the cursor. Scoped off .is-active: that pill is already at the destination and is not a target, so it should not move. */ .pr-tab:not(.is-active):hover { background: var(--hr-cream-50, #fefefd); border-color: #fff; box-shadow: var(--pr-pill-shadow); transform: translateY(-2px); } .pr-tab.is-active { background: var(--hr-cream-50, #fefefd); border-color: #fff; /* Five-layer ambient shadow + inset white highlight, as the node carries; this had a single shadow. And Figma's active tab is Almarai REGULAR (node 40000567:27721) - the white fill and rim are what mark it, so the 700 that was here was part of why the row read heavy. */ box-shadow: var(--pr-pill-shadow); } .pr-filters-fields { display: flex; gap: 16px; flex-wrap: wrap; align-items: center; } /* Same 0.47px-clearance clip as the search field above ("حسب الموضوع" inks 6.03px below the baseline against 6.5px of room), and a sizes itself to its WIDEST OPTION, not the selected one - so this pill was 235px here and a different width on any environment whose topic list happens to be longer or shorter, which is why it looked inconsistent between screenshots. 148px is Figma's 146px frame (node 40000623:27633) plus the 2px our 1px border adds outside the padding box (Figma's stroke is inside it), so the text slot inside is Figma's own 86px - the width "Select Topic" is drawn to hug. Anything longer than the slot now truncates with an ellipsis rather than widening the pill. The open dropdown is not constrained by this, so full topic names are still readable while choosing. */ width: 148px; overflow: hidden; text-overflow: ellipsis; white-space: nowrap; font-size: 16px; color: var(--hr-brown-500) !important; background: rgba(236, 230, 211, .4) url("../images/press-releases-revamp/icon-chevron-down.svg") no-repeat; background-size: 11px; background-position: right 20px center; border: 1px solid rgba(177, 175, 165, .5); cursor: pointer; } .pr-select option { color: var(--hr-brown-500) !important; } /* The heavy dark ring that appeared once a topic was picked is the browser's own default focus outline - this control had no focus style of its own, and Chrome keeps focus on a even for a plain mouse click, so a ring here appeared on every pick rather than only for keyboard users, which is what the split above was trying to achieve. */ [dir="rtl"] .pr-select { background-position: left 20px center; padding: 3px 20px 3px 40px; } /* Figma shows this control as a "Select Date" label + calendar icon, same family as the "Select Topic" select — but a native can't take arbitrary placeholder text (empty state always renders the browser's own dd/mm/yyyy fields) and always shows the picked value in the browser's own locale format once one is set, neither of which can match a fixed label. So the pill here is a plain wrapper showing server-rendered text (either "Select Date" or the picked date, formatted) with the actual date input stretched on top at opacity:0 — clicking anywhere on the pill opens the native picker, and the visible label updates on submit/reload the same way the other filters already do. */ .pr-date-wrap { position: relative; display: inline-flex; align-items: center; gap: 8px; padding: 11px 16px 11px 20px; border-radius: 61px; font-size: 16px; line-height: 24px; color: var(--hr-brown-500); background: rgba(236, 230, 211, .4); border: 1px solid rgba(177, 175, 165, .5); cursor: pointer; white-space: nowrap; } .pr-date-icon { flex-shrink: 0; pointer-events: none; } /* Sits where the calendar icon does once a date is picked. Needs its own stacking context (position + z-index) to actually receive the click — .pr-date-input is absolutely positioned over the whole pill, so without this the invisible input would swallow clicks meant for the clear link. */ .pr-date-clear { position: relative; z-index: 1; flex-shrink: 0; display: inline-flex; align-items: center; justify-content: center; width: 16px; height: 16px; line-height: 1; font-size: 18px; color: var(--hr-brown-300); text-decoration: none; } .pr-date-clear:hover { color: var(--hr-brown-500); text-decoration: none; } .pr-date-input { position: absolute; inset: 0; width: 100%; height: 100%; margin: 0; padding: 0; border: 0; background: none; opacity: 0; cursor: pointer; appearance: none; } .pr-date-input::-webkit-calendar-picker-indicator { position: absolute; inset: 0; width: 100%; height: 100%; margin: 0; opacity: 0; cursor: pointer; } /* BIL-581 (Arabic): the block padding drops 12 -> 4 to pay for the 40px line box the input below now carries, so the pill still measures its original 50px and stays level with .pr-select, .pr-date-wrap and .pr-tab in the same row. This is where it differs from .sml-search on the summit listing, which took its pill to 60px - that row has no year tabs to stay level with. */ .pr-search { display: flex; align-items: center; gap: 8px; padding: 3px 20px 3px 16px; border-radius: 61px; background: rgba(236, 230, 211, .4); border: 1px solid rgba(177, 175, 165, .5); } .pr-search img { flex-shrink: 0; } /* line-height 40 with no block padding, rather than the 24px this carried: at 16px Almarai a 24px line box puts the baseline 17.5px down and leaves 6.5px beneath it, but Arabic INKS up to 6.34px below the baseline (the tails of ج and ع, the deepest dots of ي) against Latin's ~0.2px. That is 0.16px of clearance, and an clips to its own content box - so the bottom antialiased row of those tails was being sliced off, which reads as the text fading out along its baseline. Measured on this page: the Arabic hint clears by 2.68px, "اختر التاريخ" and "حسب الموضوع" by 0.47px. 40px is deliberately far past the 6.34px rather than tuned to it: where a browser puts the baseline inside an input's box is not something the half-leading rule pins down reliably, and a pixel either way is inside the error bars of that and of fractional device-pixel ratios. A 40px line box leaves ~14.5px under the baseline, so the deepest tail clears by ~8px and no plausible rounding reaches it. Same figure as .sml-search input. */ .pr-search input { border: 0; background: none; /* An does not inherit font-family, so without this the field falls back to the UA's Arial - which has no Arabic coverage, leaving the OS to substitute a face whose tails ink far lower than the Almarai metrics above are measured against. */ font-family: inherit; font-size: 16px; line-height: 40px; padding-block: 0; /* 0 rather than the UA's 2px, so .pr-search-placeholder - same box, same font, same line box - starts on exactly the same pixel as typed text. */ padding-inline: 0; color: var(--hr-brown-500); min-width: 180px; outline: none; } /* The visible hint is .pr-search-placeholder, a sibling span layered over the field: the input's own content-box clip is what cropped the Arabic tails, and a sibling is not subject to it. The blade renders the span already carrying .is-hidden when the field comes back with a search term, so it never flashes on load; the script pushed from that view toggles the class on every `input` event after that. inset:0 rather than a measured offset - the span shares the input's box, its font and its 40px line box, so the two strings land on the same baseline by construction rather than by tuning, in either direction. */ .pr-search-field { position: relative; display: flex; flex: 1 1 auto; min-width: 0; } .pr-search-placeholder { position: absolute; inset: 0; font-size: 16px; line-height: 40px; color: var(--hr-brown-500); opacity: 1; white-space: nowrap; overflow: hidden; text-overflow: ellipsis; /* Clicks belong to the field underneath. */ pointer-events: none; } .pr-search-placeholder.is-hidden { display: none; } /* The date pill renders both its clear link and its calendar icon and hides one of them, so an AJAX filter change can swap them without the filter row being re-rendered (see press_releases/index). */ .pr-date-clear.is-hidden, .pr-date-icon.is-hidden { display: none; } /* Browser default text-selection is a solid, full-saturation highlight that reads harshly against the frosted pill — tint it with the brand green instead, same fix already applied to the global search bar's input. */ .pr-search input::selection { background: rgba(0, 109, 98, .25); color: var(--hr-brown-900); } /* ---------- Card list ---------- */ .pr-list { display: flex; flex-direction: column; gap: 16px; margin-bottom: 48px; } .pr-card { position: relative; display: flex; align-items: center; gap: 16px; padding: 16px; border: 1px solid #fff; border-radius: 20px; /* The white gradient is translucent, so the card only ever showed the colour of whatever it was laid over. On the DETAIL page that is the #e3e1d4 watermark behind .prd-related (blog-detail/related-bg-motif.svg, blurred to a wash by the backdrop-filter that used to be here), which is what gives the card its grey there. The listing has nothing behind it but flat cream-400, so the same rule composited to ~#fdfdf8 - within three units of the white .5 body panel sitting on it, i.e. no card at all, just a white field with a photo in it. #e3e1d4 is that same watermark colour, now painted as the card's own base instead of borrowed from a decoration that happens to be behind it on one of the two pages. Under the unchanged gradient it composites to #f0eee7 -> #f4f3ee, and the body panel reads ~8 units lighter again, as in the design. The detail page keeps the grey it already had; it just no longer varies with where the motif's arms happen to fall. */ background: linear-gradient(to top, rgba(255,255,255,.45) 0%, rgba(255,255,255,.6) 76%, rgba(255,255,255,.6) 100%), #e3e1d4; /* No backdrop-filter: the stack above is opaque, so there is no backdrop left to blur - it would only force a compositing layer per card. */ box-shadow: 0 3px 3px rgba(0,0,0,.03), 1px 10px 5px rgba(0,0,0,.03), 2px 23px 7px rgba(0,0,0,.02); } .pr-card-media { flex-shrink: 0; /* Fixed 250x228, Figma's own Image frame (node 40000387:31670) inside a 260-tall card with 16px padding. This was `align-self: stretch`, which tied the photo's height to the CARD's - and the card's height depends on how far the title wraps. So the same photo rendered 250x196 where a title fit one line and 250x228 where it took two, i.e. landscape on one row and near-square on the next. Pinning the height keeps every card's photo identical whatever the copy does. The card's own `align-items: center` then centres it, which is where Figma has it (16px clear top and bottom at 260). Mobile is unaffected: the <=991 block already overrides this to width:100% / height:200px for the stacked card. */ height: 228px; width: 250px; border: 4.9px solid #eae1d4; border-radius: 16px; box-shadow: 0 20px 24px -18px rgba(0, 0, 0, .17); background-size: cover; background-position: center; background-color: var(--hr-brown-300); } .pr-card-body { flex: 1 1 auto; min-width: 0; display: flex; align-items: flex-end; justify-content: space-between; gap: 24px; padding: 24px; background: rgba(255, 255, 255, .5); border-radius: 8px; } .pr-card-copy { flex: 1 1 auto; min-width: 0; display: flex; flex-direction: column; gap: 24px; } .pr-card-text { display: flex; flex-direction: column; gap: 8px; } /* Headline over two lines. It was one nowrap line at every width above 992px, and this column is only ~629px at 1440px, so real release titles (74-115 characters) showed just 48-74% of themselves - "From Doha to Istanbul: QF's BilAraby Advances Regiona…" lost more than half, which is not enough to tell one release from another. Two lines covers the great majority of them; the clamp keeps every card the same height regardless. The clamp is desktop-only. Below 992px the title wraps freely over as many lines as it needs (see the max-width: 991.98px block), which is the existing behaviour there and worth keeping on a narrow column. */ .pr-card-text h2 { font-size: 24px; font-weight: 700; line-height: 32px; color: var(--hr-brown-700); margin: 0; } @media (min-width: 992px) { .pr-card-text h2 { display: -webkit-box; -webkit-box-orient: vertical; -webkit-line-clamp: 2; overflow: hidden; } /* The white panel always stands as tall as the photo beside it. Its height is content-driven, and the title clamp above bounds that content at two lines - so on a wide viewport where a title fits on ONE line the panel shrank to 196px against the photo's pinned 228 and sat visibly short of it (reproduced at 1920; 1280 and 1600 both wrap to two lines and happened to match at 228). 228 is also Figma's own body frame (node 40000387:31671, 1302x228, the same height as its Image), so this is the design's value rather than a prop. min-height, not height: with the title clamped, content cannot exceed 228 at this breakpoint, but a floor degrades safely if a longer date or a wrapped action row ever pushes past it - it grows instead of clipping. Scoped to >=992 so it cannot apply to the stacked card, where the panel has no photo beside it and a 228px floor would just be dead space. */ .pr-card-body { min-height: 228px; } } .pr-card-text p { font-size: 20px; line-height: 28px; color: var(--hr-brown-700); opacity: .6; margin: 0; overflow: hidden; text-overflow: ellipsis; white-space: nowrap; } .pr-card-actions { display: flex; gap: 16px; align-items: center; } .pr-card-actions a { text-decoration: none; } .pr-btn-pdf, .pr-btn-read { display: inline-flex; align-items: center; gap: 8px; padding: 16px 16px 16px 24px; border-radius: 61px; font-size: 16px; font-weight: 700; white-space: nowrap; } /* BIL-581: the glass-lit yellow of the privacy policy page's own Download PDF (.pp-pdf-btn in privacy-policy-revamp.css) - a 2px outset white rim on the top and sides, an inset white highlight, and the same four-layer ambient shadow. This button was flat yellow with no border and no shadow at all, so it read as a plain fill sitting next to the glass .pr-btn-read beside it. Keep the two in step; the yellow itself is unchanged. Vertical padding drops 16 -> 15 to absorb the new 2px top border, holding the button at the 56px every revamp pill is built to (15 + 24 + 15 + 2). DELIBERATE DEVIATION FROM THIS CARD'S FIGMA NODE - do not "correct" it back. Figma's card button (40000387:31682) draws this pill as a plain yellow fill with a 1.5px TRANSPARENT border at py-16, i.e. no white rim and 59px tall. The privacy policy page's Download PDF (.pp-pdf-btn) is the chosen source of truth for this control instead, so the two Download PDF buttons on the site match each other; confirmed as intended rather than as a Figma miss. The Read button beside it is padded to 56 to stay level with it - see its own note below. */ .pr-btn-pdf { background: var(--hr-yellow-500); color: #fff; border: 2px outset #ffffff9c; border-bottom-width: 0; padding: 15px 16px 15px 24px; box-shadow: inset 0 4px 6.1px rgba(255, 255, 255, .23), 7px 63px 18px rgba(0, 0, 0, .02), 2px 23px 14px rgba(0, 0, 0, .02), 1px 10px 10px rgba(0, 0, 0, .03), 0 3px 6px rgba(0, 0, 0, .03); } .pr-btn-pdf:hover { color: #fff; opacity: .92; } /* 20px, not the 24 of the arrow in .pr-btn-read beside it, even though Figma draws both icon instances as 24x24 frames (node I40001286:69802;40000387:31682). icon-download.svg is exported on an 18x18 artboard with the glyph running the full 17.5 of it - no padding - while icon-arrow-right.svg is a 24x24 artboard whose arrow spans only ~17.75. Boxed at the same 24 the download glyph therefore drew ~31% more ink than the arrow and read as the larger of the two. 20px puts the two glyphs at a matching visual weight, and is the size the site's other Download PDF buttons already give this same file (.pp-pdf-btn, .tnc-pdf-btn) - which is the match this button's fill and shadow were deliberately chosen for (see the note above). */ .pr-btn-pdf img { width: 20px; height: 20px; } /* Fill, border, shadow stack and type all match Figma's card button (node 40000387:31681) exactly - the one thing changed is the vertical padding, 16 -> 14.5. Figma draws this pill at py-16 against a 24px line box and 1.5px borders, which is 16 + 24 + 16 + 3 = 59px, and the Download PDF beside it at the same py-16. But the PDF button now sits at the 56px every other revamp pill uses (see its own note above), so a literal 59 here left the two buttons in the same row 3px different in height. 14.5 + 24 + 14.5 + 3 = 56 - the identical arithmetic .pp-back-to-top documents on the privacy policy page, where the same py-16-against-a-24px-line-box reading of Figma was corrected for the same reason. justify-content per Figma's justify-center; it only shows once something gives this pill more width than its content needs. */ .pr-btn-read { background: rgba(255, 255, 255, .2); border: 1.5px solid transparent; box-shadow: 7px 63px 18px rgba(0, 0, 0, 0), 4px 40px 16px rgba(0, 0, 0, 0), 2px 23px 14px rgba(0, 0, 0, .02), 1px 10px 10px rgba(0, 0, 0, .03), 0 3px 6px rgba(0, 0, 0, .03), inset 0 4px 6.1px rgba(255, 255, 255, .23); color: var(--hr-brown-500); justify-content: center; padding: 14.5px 16px 14.5px 24px; } .pr-btn-read:hover { color: var(--hr-brown-500); background: rgba(255, 255, 255, .4); } [dir="rtl"] .pr-btn-pdf img, [dir="rtl"] .pr-btn-read img { transform: scaleX(-1); } .pr-card-date { flex-shrink: 0; padding: 8px 16px; /* Figma's chip is 112x32 and its Utility/Tag/Bold style sets lineHeight 100% - i.e. 14px on 14px type, so 8 + 14 + 8 + 2 = 32. Unset here, this inherited `normal` (~19.6px at 14px Almarai) and stood 38px tall. */ line-height: 1; border-radius: 8px; background: rgba(236, 230, 211, .4); border: 1px solid rgba(177, 175, 165, .5); font-size: 14px; font-weight: 700; text-transform: uppercase; color: var(--hr-cream-900, #696862); white-space: nowrap; } /* ---------- Pagination ---------- */ .pr-pagination { display: flex; align-items: center; justify-content: flex-start; gap: 8px; } /* Figma (node 40001286:69806 "pagination"): every control - arrows, page numbers, and the ellipsis - is the same 56px glass circle (rgba white fill + 1.5px white border + inset highlight + soft outer shadow), not a plain borderless 40px text button. */ .pr-page-arrow, .pr-page-number, .pr-page-ellipsis { display: inline-flex; align-items: center; justify-content: center; width: 56px; height: 56px; border-radius: 61px; border: 1.5px solid transparent; background: rgba(255, 255, 255, .2); box-shadow: 2px 23px 14px rgba(0, 0, 0, .02), 1px 10px 10px rgba(0, 0, 0, .03), 0 3px 6px rgba(0, 0, 0, .03), inset 0 4px 6.1px rgba(255, 255, 255, .23); text-decoration: none; font-size: 16px; transition: background-color .2s ease, color .2s ease, transform .2s ease; } .pr-page-number { color: var(--hr-brown-500); } .pr-page-arrow { color: var(--hr-brown-500); } .pr-page-arrow img { width: 24px; height: 24px; } /* BIL-581: prev/next are separate left/right assets, so in RTL the glyphs have to flip with the reading direction or "previous" points away from the page it goes to - same one-liner the other listing paginations already carry. */ [dir="rtl"] .pr-page-arrow img { transform: scaleX(-1); } .pr-page-ellipsis { color: var(--hr-brown-500); } .pr-page-arrow:hover, .pr-page-number:hover { text-decoration: none; color: var(--hr-brown-500); background: rgba(255, 255, 255, .4); } .pr-page-arrow.is-disabled { opacity: .35; pointer-events: none; } .pr-page-number.is-active, .pr-page-number.is-active:hover { border-color: rgba(255, 255, 255, 0); background: var(--hr-yellow-500); color: var(--hr-cream-50); font-weight: 700; } .pr-empty { padding: 60px 0; text-align: center; font-size: 18px; color: var(--hr-brown-300); } @media (max-width: 1199.98px) { .pr-hero, .pr-listing { padding-inline: 40px; } .press-releases-revamp { --pr-hero-h: 200px; } } @media (max-width: 991.98px) { .pr-card { flex-direction: column; align-items: stretch; } .pr-card-media { width: 100%; height: 200px; } /* Two fixes to the stacked card. Alignment: .pr-card-body is a white panel carrying 24px of padding, which on the side-by-side card is what insets the copy from the image beside it. Stacked, that padding put every text element 24px to the RIGHT of the image's own left edge - measured on a 390px screen, the image starts at x=33 and the title, description, buttons and date all start at x=57, so one card showed two left edges. Stacked there is nothing left for the panel to separate, so it drops out here and the copy lines up with the image. (.sml-card-body on the Summit listing is the same markup with the same 24px and has the same misalignment - not touched here.) Spacing: gap 16 -> 24 opens up the room between the Download PDF / Read row and the date beneath it, and matches .pr-card-copy's own 24px rhythm rather than introducing a third spacing value. */ .pr-card-body { flex-direction: column; align-items: stretch; gap: 24px; padding: 0; background: none; border-radius: 0; } .pr-card-date { align-self: flex-start; } .pr-head h1 { font-size: 30px; } .pr-card-text h2 { font-size: 20px; line-height: 28px; white-space: normal; } .pr-card-text p { font-size: 16px; white-space: normal; } } @media (max-width: 767.98px) { /* 20px, the artboard's own gutter: every child of the mobile frame (40004733:79107, 402 wide) sits at x=20 on a 362 column. Was 16. */ .pr-hero, .pr-listing { padding-inline: 20px; } /* --- Hero, scoped AWAY from the press release DETAIL page --------------- That page shares this stylesheet and this class - its root is `.press-releases-revamp prd-revamp` (show.blade.php:14) - and renders the same .pr-hero, .pr-hero-decor and .pr-breadcrumb. But the artboard being matched here is the LISTING's (40004733:79107); the detail page has its own, which is not in front of me. Unscoped, the height alone would move that page's band, breadcrumb and every section under it by 13px, and press-release-detail-revamp.css reads --pr-hero-h directly in its own background-size calc. So the base 160 stays for it and only the listing takes the artboard's numbers. 173px is where the hero instance ends on the artboard (it spans y=0..173, the content frame starts at 173, and both the teal Intersect vector and the bottom hairline terminate at 172.84). 16px of padding-bottom is the breadcrumb's own clearance there: its row ends at 156.84 against that 172.84 hairline. Was the base 24. 12px type and a 12px crumb gap are the artboard's Utility/Caption style; the fluid clamp on .pr-breadcrumb (13-20px, which resolves to 17.1 here) is a truncation guard for the desktop size and has nothing to guard at 12px. */ .press-releases-revamp { --pr-hero-h: 160px; } .press-releases-revamp:not(.prd-revamp) { --pr-hero-h: 173px; } /* The band's own box, 302px, straight off the artboard: the hero instance's band child (I40004733:79109;40004531:62357) is 402x302, which is what carries the teal from full strength at the top to cream. The derived `(--pr-hero-h + 50px) * 1.16271` is tuned to the DESKTOP relationship between the hero and .pr-listing's 64px padding-top; at phone sizes it resolves to 259px, so the fade finished about 30px above where the artboard puts it. A flat value is right here precisely because the relationship it derives from is not the phone's. */ .press-releases-revamp:not(.prd-revamp) { background-size: 100% 302px; } /* The corner wedges stay on the phone hero, matching every other mobile page (.tnc-hero-decor, .pp-hero-decor, .abt-hero-decor). The artboard's mobile hero draws neither - its band is a single smooth teal-to-cream gradient - and they were hidden here for that reason; keeping the pair across the site was the call instead. Sizing is handled below. */ .press-releases-revamp:not(.prd-revamp) .pr-hero { padding-bottom: 16px; } /* One breadcrumb size site-wide on the phone, taken from the Events listing (.evt-breadcrumb in events-revamp.css): 12px type, 8px gaps, a 12px separator. Unscoped, unlike the hero rules around it - the listing and the detail page differ in band height, not in type, and the ticket asks for one size on every page. */ .pr-breadcrumb { font-size: 12px; gap: 8px; } .pr-breadcrumb-sep { height: 12px; } /* 60px above the title (the artboard's head frame starts at y=233 against a hero ending at 173) and 60px below the pagination (the content frame ends at 3512 where the footer begins, 59.62 under the pagination's 3452.4). Were 64 and 100. .pr-listing is the listing page's own section - the detail page does not render it - so this one needs no scoping. */ .pr-listing { padding-top: 60px; padding-bottom: 60px; } /* Scaled down with the band so the wedges keep their proportion of the hero width rather than swallowing a phone-width viewport. */ /* The pair has to scale across the mobile range, not sit at a fixed 190px. At 190 each, the two wedges combine to 380px whatever the screen is - so they OVERLAP in the middle of every phone narrower than 380: measured 60px of overlap at 320, 20px at 360, 5px at 375. Coverage also swung from 119% of the viewport at 320 to 50% at 767, against 31.8% on desktop. min() keeps 190px as the ceiling, so anything from ~432px up (430/440 phones included) renders exactly as before, and below that the pair holds a constant 88% of the width with a real gap between them instead of colliding. aspect-ratio carries the source vectors' own proportions (305.329x160.658 and 305.29x204.731), which at 190px resolve to precisely the 100px and 128px that were hard-coded here. */ .pr-hero-decor-left { width: min(190px, 44%); height: auto; aspect-ratio: 305.329 / 160.658; } .pr-hero-decor-right { width: min(190px, 44%); height: auto; aspect-ratio: 305.29 / 204.731; } /* Head block, from node 40004733:79111. The artboard centres both lines and runs the title at Almarai Bold 32/40 over TWO lines with "News" starting the second (its text node carries an explicit break), against a 16/24 description; the two sit 24px apart and the block ends 32px above the filters (its frame ends at y=212, the filter block starts at 244). display:block on the accent is what breaks the line without putting a
in the markup - it holds for whatever each locale's two halves are, the same way .evt-intro-inner h1 does it on the Events listing. */ .pr-head { margin-bottom: 32px; text-align: center; } .pr-head h1 { font-size: 32px; line-height: 40px; margin: 0 0 24px; } .pr-head h1 .hr-accent { display: block; } .pr-head p { font-size: 16px; line-height: 24px; } /* Search on its own full-width row, then "All years" + every year + "Select Topic" + "Select Date" as ONE horizontally-scrolling line - the same filter row the Events listing already runs (BIL-906: each listing page was wrapping or stacking these its own way, so the row looked different on every page). .pr-filter-row is the scroller; .pr-filters-fields collapses into it so the select and the date pill share that scrolling line with the tabs instead of forming a second flex row inside it. Replaces the one-control-per-row column this used to stack, which is the worst case on THIS page specifically: the tabs are one pill per year, so the column grew by a 48px row every January and pushed the first result most of a screen down. */ /* nowrap matters here: the base rule wraps, and in a WRAPPING column container a flex line takes its cross size from its widest item, so the scrolling row below would size itself to its own content width instead of stretching to the column it is supposed to scroll inside. */ /* 10px between the search row and the pill row, 8px between the pills: the phone figures the Events filter row uses, so the two read as one component. margin-bottom stays at this block's own 40 - see the note on .pr-filters for why the desktop 80 is halved here. */ /* 12px between the search row and the pill row, and 32px below the block - both the artboard's: its search field is 362x44 at y=0, the pill row sits at y=56 (so 12 clear), and the block ends at y=344 against the first card at y=376. Was 10 and 40. */ .pr-filters { flex-direction: column; flex-wrap: nowrap; align-items: stretch; gap: 12px; margin-bottom: 32px; } /* order:-1 lifts the search box above the scroller. It is the LAST child of the form (that is what puts it at the end of the desktop row), and a column cannot reorder itself any other way. flex:none so the column's stretch gives it the full width without the pill being squeezed vertically. The insets go symmetric at the 16px this block uses throughout: the base rule is 16 at the icon end and 20 at the text end (the mirror of .pr-date-wrap, which puts its icon at the other end), so what comes down here is that 20, not the 16 the icon already had. */ /* 1px of block padding, not 3: the artboard's search field is 44px tall (node 40004733:79118), and 1 + the 40px line box + 1 + the 2px our border adds outside the padding box is exactly that. The 40px line box is deliberately untouched - it is what keeps the Arabic tails clear of the input's own content-box clip. Radius, fill and the glass rim are the base rule's; only the height changes here. */ .pr-search { order: -1; flex: none; padding: 1px 16px; } /* 14px to match the pills below it. The 40px line box is deliberately NOT touched - it is what keeps the Arabic tails clear of the input's own content-box clip (full note on .pr-search input), and against 3px of block padding it still totals the 48px pill this whole filter row is drawn to. The hint span shares the input's box and baseline, so it has to move with it or the typed text and the hint render at two sizes. */ .pr-search input, .pr-search-placeholder { font-size: 14px; } /* Overrides the base min-width:180px, which on a 320px screen would push the pill wider than the column. */ .pr-search input { width: 100%; min-width: 0; } .pr-filter-row { display: flex; flex-wrap: nowrap; align-items: center; gap: 8px; overflow-x: auto; /* Room for the active pill's shadow inside the scroll box, cancelled again on the outside so the layout does not move. `overflow-x: auto` makes overflow-y compute to auto as well, so this box clips vertically too and was slicing the shadow off flat along its bottom edge. Same clearance .vid-filters / .tlk-filters / .evt-filter-row carry. */ padding-block: 8px 40px; margin-block: -8px -40px; /* The row is meant to run past the edge, so a bar would only add noise on the platforms that draw a persistent one. */ scrollbar-width: none; -ms-overflow-style: none; } .pr-filter-row::-webkit-scrollbar { display: none; } .pr-filters-fields { display: contents; } /* Both of these undo a desktop rule that fights the scroller: flex-wrap would break the years onto a second line inside it (the base rule wraps, and there is one tab per year), and the `auto` end-margin would shove the select and the date pill to the far end of the scroll content on any phone wide enough to fit the pills. */ .pr-filters-tabs { flex: none; flex-direction: row; flex-wrap: nowrap; gap: 8px; margin-inline-end: 0; } /* flex:none on every pill in the row: it is meant to overflow and scroll, so nothing in it may be squeezed to fit, and width:auto undoes the full-width column this block used to stack. 13px of block padding against a 20px line box holds the 48px pill the filter row is drawn to (see .pr-tab) now that the type is down to 14px; 20px -> 16px inline is the phone figure the Events row uses. */ /* 11px of block padding: 11 + the 20px line box + 11 + 2px of border is the artboard's 44px pill (its Button frames - All Years 86x44, Select Year 103x44 - are 44 throughout). Was 13, which drew the desktop 48. */ .pr-tab { flex: none; width: auto; padding: 11px 16px; font-size: 14px; line-height: 20px; } /* Fixed width, tighter than the desktop rule's 148px - and it still cannot be `auto`: a bare