/*
 * responsive.css — a teljes reszponzivitás rétege.
 *
 * MIÉRT KÜLÖN FÁJL ÉS MIÉRT UTOLSÓ: a többi stíluslap az eredeti oldalról MÉRT
 * értékeket hordozza, és 1025px felett pixelre egyeznie kell vele. Ez a réteg
 * ezért szándékosan úgy van megírva, hogy a desktop megjelenést ne mozdítsa el:
 * ami itt feltétel nélküli, az csak akkor lép működésbe, ha a tartalom amúgy
 * kilógna; a többi 1024px alatti médialekérdezésben ül.
 *
 * MIÉRT KELLETT EGYÁLTALÁN: az eredeti oldal NEM reszponzív. A mobil menüjét
 * user-agent alapján kapcsolta (nem viewport szerint), és három kemény
 * töréspontja volt — 480 / 767 / 1024 —, köztük semmi. A 480 és 1024 közötti
 * sávban emiatt látványosan törik. Itt tehát szándékosan ELTÉRÜNK az
 * eredetitől: ez az egyetlen olyan pont a projektben, ahol a „legyen olyan,
 * mintha semmi nem változott volna” elv alá van rendelve annak, hogy az oldal
 * minden eszközön használható legyen.
 *
 * A BÖNGÉSZŐ-NAGYÍTÁS NEM KÜLÖN ESET. A page zoom a CSS-képpontban mért
 * viewportot csökkenti — egy 1440px-es ablak 200%-on 720 CSS-képpont széles —,
 * tehát a médialekérdezések ugyanúgy hatnak rá. Amit a 280…2560px-es
 * szélesség-söprés lefed, azt minden nagyítási szint is örökli. Ezért nincs
 * külön „zoom-kezelés”: helyette az van, hogy EGYETLEN szélességen sincs
 * vízszintes túlcsordulás.
 */

/* ═══ 1. Túlcsordulás elleni védelem ══════════════════════════════════════
 *
 * Ezek feltétel nélküliek, de csak akkor változtatnak bármin, ha a tartalom
 * egyébként kilógna a helyéről. Desktopon tehát hatástalanok.
 */

/*
 * Grid- és flex-gyerekek alapértelmezett minimuma `auto`, ami a min-content
 * méret — egy hosszú szó vagy egy nem törhető beágyazás emiatt szétfeszíti a
 * szülőt ahelyett, hogy tördelne. A 0-s minimum ezt oldja.
 */
.br-cards > *,
.br-news > *,
.br-card,
.br-footer__inner,
.br-footer__meta,
.br-footer__list,
.br-nav__item {
	min-width: 0;
}

/* Beágyazott tartalom sosem szélesebb a helyénél. */
img,
svg,
video,
iframe,
embed,
object {
	max-width: 100%;
}

/*
 * Hosszú szó, URL vagy e-mail cím ne feszítse szét a szülőt. A `break-word`
 * csak akkor tördel, ha muszáj — a normál szövegképet nem érinti.
 */
.br-content,
.br-card,
.br-acc__body,
.br-post,
.br-footer,
.br-title-band {
	overflow-wrap: break-word;
}

/*
 * Táblázat: ha nem fér ki, a SAJÁT dobozában legyen görgethető, sosem az egész
 * lap. A `display:block` szándékosan csak a burkolóra megy — magára a
 * táblázatra téve elromlana a cellák igazítása.
 */
.br-content table {
	max-width: 100%;
}

.br-table-wrap {
	max-width: 100%;
	overflow-x: auto;
	-webkit-overflow-scrolling: touch;
}

/* ═══ 1b. A fejlécmenü túllógása ══════════════════════════════════════════
 *
 * A `.br-nav` az eredetiben `margin-inline-end: -21px`-et kap: a menü
 * szándékosan túllóg a 1140px-es rácson jobbra. Széles ablakon ez a konténer
 * és a képernyő széle közti résbe fér bele, tehát láthatatlan.
 *
 * Amint viszont a viewport a konténer szélességéhez közelít, a rés elfogy, és
 * a túllógás már a KÉPERNYŐRŐL lóg le — vízszintes görgetést csinálva MINDEN
 * oldalon. Mérve: 1140px-en +21, 1160px-en +11 képpont; a törés az 1040–1179px
 * sávot érinti, és mind a kilenc oldalt.
 *
 * Ez az a hiba, amit a készülék-preset alapú vizsgálat nem talál meg: a
 * szokásos méretek (1024, 1366, 1440) pont átugorják a sávot. A böngésző-
 * nagyítás viszont EGYENESEN belesétál — egy 1440px-es ablak 125%-on 1152 CSS-
 * képpont széles, ami a sáv közepe. Ezért kellett a sűrű, 20 képpontonkénti
 * söprés.
 *
 * A küszöb pontosan ott van, ahol a rés eléri a 21px-et: (v − 1140) / 2 ≥ 21,
 * tehát v ≥ 1182. Alatta nullázzuk a túllógást — 1182px felett, és így a
 * desktop-referencián is, az eredeti viselkedés marad.
 */
@media (max-width: 1181px) {
	/*
	 * A menü NEM nullára megy, hanem ugyanarra a peremre, mint a logó.
	 *
	 * Előbb 0-ra állítottam, hogy a rács alá csúszva ne lógjon ki — ez viszont
	 * a JOBB oldalon ugyanazt a hibát csinálta, amit a bal oldalon javítottunk:
	 * mérve 1040 és 1140 képpont között a menü utolsó pontja pontosan a kijelző
	 * szélén ült (jobb rés = 0). A `--br-gutter` innentől mindkét oldalt
	 * ugyanúgy tartja.
	 */
	.br-nav {
		margin-inline-end: var(--br-gutter);
	}
}

/* ═══ 2. Margók keskeny kijelzőn ══════════════════════════════════════════ */

/*
 * ── PEREM A RÁCS ALATTI SÁVBAN ───────────────────────────────────────────
 *
 * A konténer 1140 képpontos rácson ül, 10 képpont belső behúzással. 1182
 * képpont FÖLÖTT ez rendben van: a rács köré bőven jut margó. ALATTA viszont
 * a konténer 100 %-os lesz, és a 10 képpont az EGYETLEN, ami elválasztja a
 * tartalmat a kijelző szélétől.
 *
 * MÉRVE, mi történt eddig ebben a sávban (a logó bal széle):
 *
 *     1040–1140 px   kezdőlap: 0 px  ← a kijelző széléhez ért
 *     1160 px        kezdőlap: 10 px
 *
 * A megrendelő ezt Safariban, 125 %-os nagyításnál látta — és nem véletlenül:
 * egy 1440 képpontos ablak 125 %-on 1152 CSS-képpontot ad, 130 %-on 1108-at,
 * vagyis pont ebbe a sávba esik. A böngésző-nagyítás ugyanúgy szűkíti a
 * viewportot, mint egy kisebb ablak — csak sokkal többen használják.
 *
 * 1182 alatt ezért 20 képpont perem jár. A rácsos elrendezés (1182 fölött)
 * érintetlen marad.
 */
/*
 * A peremet EGYETLEN változó adja, és mind a konténer behúzása, mind a logó
 * margója ebből olvas (lásd layout.css). Így a fejléc és a tartalom nem tud
 * elválni egymástól: ha az érték változik, MINDKETTŐ vele mozdul.
 */
@media (max-width: 1181px) {
	:root {
		--br-gutter: 20px;
	}
}

@media (max-width: 767px) {
	:root {
		--br-gutter: 16px;
	}
}

@media (max-width: 380px) {
	:root {
		--br-gutter: 12px;
	}
}

/*
 * A FEJLÉCBEN ilyenkor NULLA a logó saját margója.
 *
 * A `.br-header__inner` maga is `.br-container`, tehát a fenti 20 képpontos
 * behúzást megkapja — a `.br-header__inner { padding-inline: 0 }` a
 * layout.css-ben van, ez a fájl pedig UTÁNA tölt be azonos fajsúlyon, így a
 * behúzás érvényesül. Ha a logó megtartaná a saját 10 képpontos margóját is,
 * a kettő ÖSSZEADÓDNA: mérve 60 képpont a szöveg 40-je helyett — vagyis a
 * fejléc megint elcsúszna a tartalomtól, csak a másik irányba.
 */


/* ═══ 3. Kártyarácsok folyamatos átrendeződése ════════════════════════════
 *
 * Az eredeti a négy oszlopot egyetlen ugrással vitte kettőre 480px-nél, tehát
 * 481 és 1024 között négy oszlop szorongott: 540px-en 135px jutott egyre.
 * A vonalzós (`--ruled`) változat miatt nem `auto-fit`-et használunk — ott nem
 * lehet tudni, melyik elem zárja a sort, és a válaszfalak rossz helyre
 * kerülnének. Helyette kiszámítható lépcsők vannak, csak sűrűbben.
 */
@media (max-width: 767px) {
	.br-cards--4 {
		grid-template-columns: repeat(2, minmax(0, 1fr));
	}

	.br-cards--4 > * {
		padding-block: 20px;
	}

	/* a függőleges válaszfal csak a páratlan (bal oldali) elemek után marad */
	.br-cards--4.br-cards--ruled > *:not(:last-child) {
		border-inline-end: 0;
	}

	.br-cards--4.br-cards--ruled > :nth-child(odd) {
		border-inline-end: 3px solid var(--br-primary);
	}

	/* A háromoszlopos változatot jelenleg egy oldal sem használja, de a
	   komponens létezik (components.css) — ha egyszer előkerül, ne kelljen
	   újra végigmenni ezen. */
	.br-cards--3 {
		grid-template-columns: repeat(2, minmax(0, 1fr));
	}

	.br-cards--3.br-cards--ruled > *:not(:last-child) {
		border-inline-end: 0;
	}

	.br-cards--3.br-cards--ruled > :nth-child(odd) {
		border-inline-end: 3px solid var(--br-primary);
	}
}

/*
 * 380px alatt két oszlop is szorong: a feliratok két-három betűnként törnek.
 * Itt egy oszlop marad, és a válaszfalak vízszintesre fordulnak.
 */
@media (max-width: 380px) {
	.br-cards--4,
	.br-cards--3,
	.br-cards--2 {
		grid-template-columns: minmax(0, 1fr);
	}

	.br-cards--ruled > *:not(:last-child) {
		border-inline-end: 0 !important;
		border-block-end: 3px solid var(--br-primary);
		padding-block-end: 18px;
	}

	.br-cards--ruled > *:not(:first-child) {
		padding-block-start: 18px;
	}
}

/* ═══ 4. Folyamatosan skálázódó címsáv ════════════════════════════════════
 *
 * Az eredetiben a címsáv két fix méret között ugrik: a mért desktop-érték
 * (--br-title-size, alapból 33px) 481px-től felfelé, és a szintén MÉRT
 * telefon-érték (--br-title-size-sm) 480px alatt. A kettő között nincs átmenet,
 * így 500px körül egy hosszú cím még teljes méretben szorong.
 *
 * A clamp itt SZÁNDÉKOSAN nem tartalmaz kitalált számot: az alsó és a felső
 * határ is a téma saját, az eredetiről leolvasott értéke. Csak a köztes
 * viselkedés új — a lépcső helyett folyamatos átmenet.
 *
 *   1025px felett : 4.6vw ≥ 47px, tehát mindig a felső határ nyer
 *                   → a desktop pixelre változatlan
 *   480px alatt   : a vw-tag a mért telefon-érték alá esik, tehát az alsó
 *                   határ nyer → pontosan az, amit az eredeti rendelt
 *   köztük        : folyamatos, ugrás nélkül
 *
 * Az első kísérletem itt egy beégetett 22px-es felső határ volt, rossz
 * osztálynévre — az 33px-ről 22px-re fogta vissza minden 1024px alatti címet,
 * és a 768px-es pixel-diffet 3,6%-ról 9,5%-ra rontotta. Ezért van itt most
 * változó, és ezért mérünk minden módosítás után.
 */
.br-title-band__title {
	font-size: clamp(
		var(--br-title-size-sm, var(--br-title-size)),
		4.6vw,
		var(--br-title-size)
	);
	line-height: clamp(
		var(--br-title-size-sm, var(--br-title-size)),
		4.6vw,
		var(--br-title-size)
	);
}

/* ═══ 5. Érintőfelületek ══════════════════════════════════════════════════
 *
 * Csak durva mutatóeszközön (ujj), egérrel érintetlen marad. A 44px az a
 * méret, ami alatt a találati arány érezhetően romlik.
 */
@media (pointer: coarse) {
	/*
	 * A kinyíló menü elemei: ezek lebegő rétegben ülnek, tehát a növelésük az
	 * oldal magasságát egyáltalán nem érinti — tiszta nyereség.
	 */
	.br-nav__link,
	.br-mobile-nav__list a,
	.br-mobile-nav__list button,
	.br-mobile-panel__close {
		min-height: 44px;
		display: flex;
		align-items: center;
	}

	.br-mobile-panel__close {
		min-width: 44px;
		justify-content: center;
	}

	/*
	 * A GYIK harmonika sorai SZÁNDÉKOSAN nincsenek itt.
	 *
	 * Első nekifutásra rájuk is 44px-et tettem, és a GYIK-oldal 172 képponttal
	 * lett hosszabb — a 768px-es pixel-diff 3,6%-ról 9,5%-ra ugrott. Cserébe
	 * semmit nem nyertünk: a sor teljes szélességű, tehát a célfelülete már így
	 * is 768×27 képpont, és a WCAG 2.2 AA minimuma 24×24. Egy amúgy is könnyen
	 * eltalálható elemért nem éri meg az egész oldalt szétnyújtani.
	 *
	 * A tanulság általános: az érintőfelület a terület, nem a magasság.
	 */

	.br-burger {
		min-width: 44px;
		min-height: 44px;
	}

	/*
	 * A lábléc linkjei mérve 119–188 × 21 képpont. A szélességgel nincs baj, a
	 * 21px magasság viszont a WCAG 2.2 AA 24×24-es minimuma ALATT van — és épp
	 * ezek a jogi meg kapcsolati hivatkozások (süti- és adatkezelési
	 * tájékoztató, e-mail, cím), amikre tényleg rá kell tudni találni.
	 *
	 * 32px és nem 44px: a 24-es minimumot harmadával meghaladja, miközben
	 * linkenként ~11 képpontot ad hozzá a lábléchez a 23 helyett. A 44 (Apple
	 * ajánlása) itt már négy-öt link után látványosan széthúzná az oldal alját,
	 * cserébe olyan elemeknél, amik szélességben amúgy is nagyok.
	 */
	.br-footer__list a {
		display: flex;
		align-items: center;
		min-height: 32px;
	}

	/*
	 * A regisztrációs űrlap vezérlői: mérve a legördülők 38px, a rádiógombok és
	 * jelölőnégyzetek 20px magasak voltak — ujjal mindkettő eltéveszthető, és ez
	 * pont azon az oldalon számít, amiért az egész site létezik.
	 *
	 * SZÁNDÉKOSAN CSAK A TAPINTHATÓ FELÜLET NŐ. A jelölőnégyzet maga marad 20px
	 * (felnagyítva idegenül nézne ki); helyette a köré írt CÍMKE lesz teljes
	 * szélességű és 44px magas, tehát a szöveget megérintve is működik. Se
	 * szerkezet, se osztálynév, se JS nem változik — a Gravity Forms saját
	 * működését nem érintjük.
	 */
	.gform_wrapper select,
	.gform_wrapper input[type="text"],
	.gform_wrapper input[type="email"],
	.gform_wrapper input[type="tel"],
	.gform_wrapper input[type="number"],
	.gform_wrapper input[type="date"] {
		min-height: 44px;
	}

	.gform_wrapper .gchoice {
		display: flex;
		align-items: center;
		min-height: 44px;
	}

	.gform_wrapper .gchoice label {
		display: flex;
		align-items: center;
		flex: 1;
		min-height: 44px;
		padding-block: 4px;
	}

	.gform_wrapper .gform_footer button,
	.gform_wrapper .gform_footer input[type="submit"] {
		min-height: 48px;
	}
}

/* ═══ 6. Fekvő telefon ════════════════════════════════════════════════════
 *
 * Fekvő tájolásban a kijelző magassága 380px körüli. A ragadós fejléc ilyenkor
 * a látható terület negyedét enné el, a kinyíló menü pedig nem férne ki —
 * ezért ott a fejléc együtt görget a lappal, a menü pedig görgethető.
 */
@media (max-height: 450px) and (orientation: landscape) {
	.br-header {
		position: static;
	}

	.br-mobile-panel {
		/*
		 * Előbb vh, utána dvh: a régebbi böngésző az elsőt érti és a másodikat
		 * eldobja, az újabb felülírja. iOS Safariban ez nem kozmetika — ott a
		 * 100vh a böngészősávot IS beleszámolja, tehát a menü alja a képernyőn
		 * kívülre kerülne, és épp a legalsó menüpont válna elérhetetlenné.
		 */
		max-height: 100vh;
		max-height: 100dvh;
		overflow-y: auto;
	}
}

/* ═══ 7. Beágyazott, fix méretű idegen tartalom ═══════════════════════════
 *
 * A reCAPTCHA egy 304px széles iframe, aminek a méretét a Google rögzíti —
 * 320px-es kijelzőn a margókkal együtt kilógott, és ettől az EGÉSZ lap
 * vízszintesen húzhatóvá vált (mérve: a lap 326px széles lett).
 *
 * Amit NEM csinálunk: `transform: scale()`. Egyrészt a Gravity Forms saját,
 * kétosztályos szabályai felülírják a mienket (kipróbálva: a transform „none”
 * maradt), másrészt egy összecsippentett jelölőnégyzetet nehezebb eltalálni
 * ujjal — egy captchánál ez közvetlenül regisztráció-vesztés.
 *
 * Amit csinálunk: a mező a SAJÁT dobozában legyen görgethető. A hiányzó néhány
 * képpontot a látogató elhúzhatja a widgeten belül, a lap elrendezése viszont
 * érintetlen marad. A `.gform_wrapper` előtag azért kell, hogy a fajsúly
 * megelőzze a bővítmény saját szabályát.
 */
@media (max-width: 400px) {
	.gform_wrapper .ginput_container.ginput_recaptcha,
	.gform_wrapper .ginput_recaptcha,
	.gform_wrapper .g-recaptcha {
		max-width: 100%;
		overflow-x: auto;
		-webkit-overflow-scrolling: touch;
	}
}

/* ═══ 8. PDF-beágyazás keskeny kijelzőn ═══════════════════════════════════ */
@media (max-width: 480px) {
	.br-pdf__frame {
		width: 100%;
		height: min(70vh, 520px);
		height: min(70dvh, 520px);
	}
}

/* ═══ 9. Vékonyabb fejléc keskeny kijelzőn ════════════════════════════════
 *
 * Mérve: 390px-es telefonon a fejléc 118 képpont magas volt — a 844 képpontos
 * képernyő 14%-a, ragadós fejlécként végig. A logó 91×64, körülötte bőven
 * üres hely; ez a méret desktopra készült, ahol van hova tenni.
 *
 * A --br-header-h átírásával a mobil panel fejrésze is együtt mozog (az is
 * ebből számol), tehát a csukott és a nyitott állapot között a logó nem ugrik.
 */
/*
 * ── A LOGÓ MÉRETE, MÁSODIK NEKIFUTÁS ─────────────────────────────────────
 *
 * Az első körben a fejléc vastagsága volt a panasz, ezért 118 képpontról 72-re
 * vittem, a logót pedig 64-ről 46-ra. A logó ezzel TÚL kicsi lett, és a hely
 * sem oszlott el körülötte: mérve 12 képpont fölötte, 24 alatta.
 *
 * Most a logó nagyobb (46 → 56), a szimmetriát pedig nem beállított értékek
 * adják, hanem a szerkezet: a `.br-header__inner` függőlegesen KÖZÉPRE igazít
 * (lásd layout.css), tehát a maradék hely magától oszlik el egyenlően — és
 * akkor is együtt marad, ha a magasság később változik.
 *
 * A fejléc 72-ről 88-ra nő. Ez még mindig jóval a kiindulási 118 alatt van, és
 * a 844 képpontos telefonképernyőnek a 10,4 %-a (a korábbi 14 % helyett).
 */
@media (max-width: 767px) {
	:root {
		--br-header-h: 88px;
	}

	.br-header__logo-img {
		width: auto;
		height: 56px;
	}

	.br-header__inner {
		min-height: var(--br-header-h);
	}
}

@media (max-width: 380px) {
	:root {
		--br-header-h: 76px;
	}

	.br-header__logo-img {
		height: 48px;
	}
}

/* ═══ 10. Lábléc keskeny kijelzőn ═════════════════════════════════════════
 *
 * Három baj volt rajta, mind a desktop-elrendezés maradványa:
 *
 *   1. Egy elárvult 1 képpontos világosszürke vonal ült a kapcsolati és a jogi
 *      lista között. Desktopon ez a két oszlop elválasztója; egymás alá
 *      csúsztatva véletlennek látszik, nem szándéknak.
 *   2. A közök egyenetlenek voltak — a lista-váltásnál nagyobb ugrás, a
 *      listákon belül kisebb.
 *   3. A sorok középre voltak igazítva, DE mindegyik ikonnal kezdődik: emiatt
 *      minden sor más x-en indul, és a blokk széle rojtos.
 *
 * A megoldás: a sorok egy közös, középre helyezett blokkon belül balra
 * igazítva állnak, így az ikonok egy oszlopba esnek és a szövegek egy vonalra.
 * Az elválasztó a lista-váltásnál egy 3 képpontos, félig áttetsző fehér sáv —
 * ugyanaz a jelrendszer, mint a kártyák válaszfalai.
 */
@media (max-width: 1024px) {
	/*
	 * Soronkénti középre igazítás: mind a négy elem a saját szélességével áll
	 * a lap közepén.
	 *
	 * Volt egy köztes változat, ahol a blokk egészében állt középen és a sorok
	 * közös bal szélhez húztak — attól az ikonok egy oszlopba estek. Az itt
	 * választott megoldás ezt feladja: cserébe minden sor optikailag a lap
	 * tengelyén ül, ami a lábléc rövid, egyenként is olvasható sorainál
	 * nyugodtabb képet ad.
	 */
	.br-footer__bar .br-footer__inner {
		display: flex;
		flex-direction: column;
		align-items: center;
		gap: 0;
	}

	/*
	 * Flex és nem grid: a layout.css a jogi listát `column-reverse`-szel fordítja
	 * meg, mert az eredeti keskeny elrendezés Adatkezelési–Süti sorrendű volt a
	 * desktopéval szemben. Griddel ez a megfordítás némán kiesett, és felcserélődött
	 * a két hivatkozás. Egy sorrend-változás nem látszik hibának — épp ezért kell
	 * figyelni rá.
	 */
	.br-footer__list {
		display: flex;
		flex-direction: column;
		align-items: center;
		gap: 2px;
		width: 100%;
		margin: 0;
	}

	.br-footer__list a {
		display: flex;
		align-items: center;
		gap: 10px;
		min-height: 32px;
	}

	/* az ikonok fix szélessége tartja egy vonalon a szövegkezdeteket */
	.br-footer__list .br-svg {
		flex: none;
		width: 16px;
		height: 16px;
	}

	/*
	 * A megfordítást ÚJRA ki kell mondani. A fenti `.br-footer__list` szabály
	 * ugyanolyan fajsúlyú, mint a layout.css `--legal` szabálya, viszont később
	 * jön, ezért felülírta a `column-reverse`-t — és a két jogi hivatkozás
	 * némán helyet cserélt. Sorrend-változást semmilyen automatikus ellenőrzés
	 * nem jelez; csak a képernyőkép nézése fogja meg.
	 */
	.br-footer__list--legal {
		flex-direction: column-reverse;
	}

	/* a véletlennek látszó vékony szürke vonal helyett szándékos elválasztás */
	.br-footer__list--legal {
		border-block-start: 0;
		margin-block-start: 16px;
		padding-block-start: 16px;
		position: relative;
	}

	.br-footer__list--legal::before {
		content: '';
		position: absolute;
		inset-block-start: 0;
		inset-inline: 0;
		height: 3px;
		background: rgb(255 255 255 / 26%);
	}
}

/* ═══ 11. Hírkártyák egymás alatt ═════════════════════════════════════════
 *
 * Desktopon a három hírkártya egy három oszlopos rácsban ül, ahol az oszlopköz
 * választja el őket. Egy oszlopra összecsukva viszont nincs, ami elválassza:
 * mérve NULLA képpont a kártyák között — a „Tovább olvasom »” után rögtön a
 * következő kép jön, és az egész egyetlen összefolyó szalaggá válik.
 *
 * A rács `gap`-je desktopon szándékosan 0 (az eredeti mérete), ezért nem azt
 * írjuk át, hanem a sorok közét adjuk hozzá — az oszlopköz így érintetlen marad.
 */
@media (max-width: 767px) {
	/*
	 * A rács osztálya `.br-posts--grid` — az első nekifutáskor `.br-news`-ra
	 * írtam a szabályt, ami nem létezik ezen az oldalon, tehát némán nem
	 * csinált semmit. A kártyák akkor is elváltak, mert a belső margó és a
	 * keret hatott; a mérésem viszont a befoglaló dobozok KÖZÉT nézte, ami
	 * belső margótól definíció szerint nem nő. Két hiba, ami történetesen
	 * egymást fedte el.
	 */
	/*
	 * A fajsúlynak egyeznie kell: a téma `.br-news .br-posts--grid { gap: 0 }`
	 * szabálya kétosztályos (0,2,0), az egyosztályos `.br-posts--grid` (0,1,0)
	 * ezért akkor sem viszi el, ha később jön. A téma 481–1024 között már ad
	 * 41px sorközt ugyanígy — 480 alatt viszont nem ad semmit, és ott folynak
	 * össze a kártyák.
	 */
	.br-news .br-posts--grid,
	.br-posts--grid {
		row-gap: 26px;
	}

	/*
	 * Vízszintes vonal a kártyák között: ugyanaz a jelrendszer, mint a
	 * kártyarácsok válaszfalai. A vonal fölött és alatt egyforma hely van
	 * (26px belső margó + 26px sorköz), tehát nem tapad egyik cikkhez sem.
	 */
	.br-post-card:not(:last-child) {
		padding-block-end: 26px;
		border-block-end: 1px solid var(--br-secondary);
	}
}

/* ═══ 12. A „miben vehet részt” négy kártya keskeny kijelzőn ══════════════
 *
 * Élessel összevetve mérve (390px, mindkét oldalon AZONOS betűméret — 12/18 a
 * felirat, 16/20 a megjegyzés):
 *
 *   „MÉLYINTERJÚS KUTATÁSBAN”   éles: 164px, 1 sor   lokál: 85px, 2 sor
 *   „(csoportos beszélgetés)”   éles: 192px          lokál: 170px
 *
 * Nem a betű nagy, hanem a HELY kevés: a feliratra a desktopról örökölt 22px-es
 * oldalmargó megy, plusz a kártya 10px-es belső margója. Két sorra tördelve a
 * jobb oldali cella magasabb lesz a balnál, a rács elveszti a szimmetriáját, és
 * alatta a második sor is elcsúszik.
 *
 * A megoldás nem a betű kicsinyítése (az eltérne az élestől), hanem a margó
 * visszavétele, hogy a felirat megkapja a hasáb teljes szélességét.
 */
@media (max-width: 767px) {
	.br-ways .br-card {
		padding-inline: 4px;
	}

	.br-ways .br-card__label {
		margin-inline: 0;
	}

	.br-ways .br-card__note {
		margin-inline: 0;
	}

	/*
	 * Egyforma sormagasság: a rács sorai a legmagasabb cellához igazodnak, a
	 * cellák tartalma pedig felülre kerül. Így a két ikon egy vonalon van, és a
	 * feliratok is — akkor is, ha az egyik megjegyzés két sorba fut.
	 */
	.br-ways .br-cards {
		align-items: start;
	}
}

/* ═══ 13. Mobil menü: az almenü mindig nyitva ═════════════════════════════
 *
 * A „Nyereményjáték” alá három lap tartozik (Nyertesek, Nyeremények,
 * Szabályzatok). Lecsukva ezek a panelben egyáltalán nem látszanak, tehát a
 * telefonos látogató a menüből az oldal felébe nem tud eljutni — a +/− gombot
 * pedig nem feltétlenül próbálja meg.
 *
 * A `display: none` a nyitó-gombra nem csak elrejti: kiveszi a tab-sorrendből
 * és az akadálymentességi fából is. Ezért nemcsak nem érdemes, hanem NEM IS
 * LEHET becsukni — se koppintással, se billentyűzettel.
 */
@media (max-width: 1024px) {
	/*
	 * A panelben az almenü mindig nyitva. A desktop kártya 6 képpontos
	 * eltolását és rejtett állapotát itt vissza kell venni, különben a
	 * mindig-látható alpontok feljebb csúsznának, illetve láthatatlanok
	 * maradnának.
	 */
	.br-mobile-nav .br-nav__sub,
	.br-mobile-nav .br-nav__item.is-open > .br-nav__sub {
		display: block;
		visibility: visible;
		opacity: 1;
		transform: none;
		transition: none;
	}

	.br-mobile-nav .br-nav__toggle,
	.br-mobile-nav .br-nav__toggle--adjacent {
		display: none;
	}

	/*
	 * A szülő sora így egyetlen kattintható hivatkozás marad — a gomb nélkül
	 * nem kell megosztani a sort, tehát a link a teljes szélességet megkapja.
	 */
	.br-mobile-nav .br-nav__item {
		display: block;
	}

	/* az alpontok behúzva, hogy a hierarchia látsszon; elválasztó nélkül */
	.br-mobile-nav .br-nav__sub .br-nav__item {
		border-block-end: 0;
	}

	.br-mobile-nav .br-nav__sub .br-nav__link {
		padding-block: 11px;
		padding-inline-start: 40px;
		font-size: 15px;
		opacity: 0.86;
	}
}

/* ═══ 14. A hőskép a teljes kijelzőszélességben ═══════════════════════════
 *
 * A kezdőlap konténere keskeny kijelzőn 16 (380px alatt 12) képpont oldalmargót
 * kap — ez a szövegnek jó, a nyitóképnek nem: ott csak fehér csík marad a kép
 * két oldalán.
 *
 * A kép NEM nyúlik: a `width: 100%` + `height: auto` páros megtartja az eredeti
 * oldalarányt (mérve: az oldalarány megegyezik a fájl natív arányával), a kép
 * egyszerűen nagyobb méretben jelenik meg.
 *
 * NEGATÍV MARGÓ NÉLKÜL. Az első kísérletem `margin-inline: -16px` volt, de a
 * negatív margó a szélességhez ADÓDIK: a konténer 390 helyett 422 képpont lett,
 * és a kép 16 képponttal kilógott mindkét oldalon. Nincs is rá szükség — a
 * `.br-container` amúgy is `width: 100%`, tehát a behúzás nullázása pontosan a
 * kijelző szélességét adja.
 */
/*
 * ── HÁROM SÁV, HÁROM VISELKEDÉS ──────────────────────────────────────────
 *
 * 1182 px FÖLÖTT   a hőskép a 1140-es rácsot tölti ki (a layout.css-ben).
 * 1025–1181 px     a rács alá csúszunk; itt a hőskép a TARTALOMMAL igazodik,
 *                  vagyis megkapja ugyanazt a 20 képpontos peremet, mint a
 *                  szöveg és a logó. Enélkül 1152 képpontnál 6 képpontos fehér
 *                  csík maradt a két oldalán (mérve) — az véletlennek látszik,
 *                  nem szándéknak.
 * 1024 px ALATT    teljes kijelzőszélesség, ahogy a megrendelő kérte: ott a
 *                  perem csak fehér csíkot hagyna a kép mellett.
 */
/*
 * A 1025–1181 sávra NINCS külön szabály — és ez tudatos visszalépés.
 *
 * Először itt is 20 képpont peremet adtam, hogy a hőskép a szöveggel
 * igazodjon. Kimérve viszont ez ROSSZABB lett: a hőskép a rács alatt hirtelen
 * 19 képponttal beljebb ugrott (1182-nél 21, 1181-nél 40), mert a behúzás
 * megváltozása töréspontot csinál. A 6 képpontos csík, amit orvosolni
 * akartam, ehhez képest nem hiba: az a konténer KÖZÉPRE igazító margója, ami
 * folyamatosan fogy (1152-nél 6, 1146-nál 3, 1140-nél 0).
 *
 * A hőskép tehát minden desktop szélességen a konténer-dobozt tölti ki, a doboz
 * pedig egyenletesen zsugorodik. Ugrás sehol nincs.
 */
@media (max-width: 1024px) {
	.br-front .br-hero .br-container {
		padding-inline: 0;
		max-width: none;
	}
}