.umb-block-grid__layout-container { position: relative; display: grid; grid-template-columns: repeat(var(--umb-block-grid--grid-columns, 1), minmax(0, 1fr)); grid-auto-flow: row; grid-auto-rows: minmax(50px, min-content); column-gap: var(--umb-block-grid--column-gap, 0); row-gap: var(--umb-block-grid--row-gap, 0); } .umb-block-grid__layout-item { position: relative; grid-column-end: span min(calc(var(--umb-block-grid--item-column-span, 1) * 3), var(--umb-block-grid--grid-columns)); grid-row: span var(--umb-block-grid--item-row-span, 1); } .umb-block-grid__area-container, .umb-block-grid__block--view::part(area-container) { position: relative; display: grid; grid-template-columns: repeat(var(--umb-block-grid--area-grid-columns, var(--umb-block-grid--grid-columns, 1)), minmax(0, 1fr)); grid-auto-flow: row; grid-auto-rows: minmax(50px, min-content); column-gap: var(--umb-block-grid--areas-column-gap, 0); row-gap: var(--umb-block-grid--areas-row-gap, 0); } .umb-block-grid__area { position: relative; height: 100%; display: flex; flex-direction: column; grid-column-end: span min(calc(var(--umb-block-grid--area-column-span, 1) * 3), var(--umb-block-grid--grid-columns)); grid-row: span var(--umb-block-grid--area-row-span, 1); } @media (min-width:1024px) { .umb-block-grid__layout-item { grid-column-end: span min(var(--umb-block-grid--item-column-span, 1), var(--umb-block-grid--grid-columns)); } .umb-block-grid__area { grid-column-end: span var(--umb-block-grid--area-column-span, 1); } } .umb-block-grid__area-container, .umb-block-grid__block--view::part(area-container) { max-width: var(--my-container-max-width); padding: var(--my-container-padding); margin-left: auto; margin-right: auto; /* 80px, niet de 40px van het basisthema. Live rekent met deze goot: bij 12 kolommen over 1600px levert 40px een kolom van 507px op waar live 480px heeft (idem 643/620 en 577/553). Alleen bij 80px komen alle drie exact uit. */ --umb-block-grid--areas-column-gap: 80px; --umb-block-grid--areas-row-gap: 40px; } /* Een genest blok zit al binnen een ingesprongen .section--wrapper; daar heeft live geen extra inspringing. Zonder deze reset telt de 40px hieronder een tweede keer mee en schuift de inhoud 40px op (/bribus-gen "Duurzame materialen": L273 i.p.v. L233). */ .wrapper.nested .umb-block-grid__area-container { padding: 0; } /* Kolomgoot in een area die niet de volle breedte heeft. -------------------------------------------------------------------------- De 80px hierboven hoort bij een container over de volle breedte. Zit een blok in een halve kolom, dan is de container nog maar 760px en is 11 x 80px = 880px al breder dan de container zelf: de kolomsporen klappen naar 0 en een area bestaat uit niets dan goot. Gemeten op /zakelijk/vastgoedbeleggers liep de kolom "Nieuwbouw" daardoor tot 1033 terwijl de container op 913 eindigt - 120px de afbeelding in. Live kent dit niet omdat het bootstrap-kolommen gebruikt: die liggen tegen elkaar aan met interne padding, dus de goot schaalt niet mee met het aantal sporen. Doorgerekend naar dit rastermodel (12t + 11g = containerbreedte) vraagt live een goot van 20px bij een container van 760px - een 6-span wordt dan 6x45 + 5x20 = 370, exact live's 153..523 en 543..913 - en 80px bij 1440px, waar een 5-span 553 wordt (live 233..786). Onderscheid op de span van de omliggende area, niet op nesting: geneste containers komen ook op 1440 en 1600px voor en die hebben de 80px juist wel nodig. Gemeten: de 760-container zit in een span-6 area, die van 1440 en 1600 in een span-12. */ .umb-block-grid__area:not([data-area-col-span="12"]) .umb-block-grid__area-container { --umb-block-grid--areas-column-gap: 20px; } /* Dezelfde 20px, maar nu op basis van de containerBREEDTE in plaats van de span. -------------------------------------------------------------------------- De regel hierboven vangt alleen smalle areas op. Een area over de volle breedte houdt 80px, en dat loopt stuk zodra het VENSTER smal wordt: de goot is een vast aantal pixels maal 11, dus die schaalt niet mee. Rekenwerk: de container krijgt 40px padding links en rechts, dus bij een venster van 950px is de contentbox 855px. Daar is 11 x 80px = 880px goot voor nodig - meer dan er is. Alle twaalf sporen klappen dan naar 0 en de span-12 area wordt 0 x 12 + 880 = 880px breed in een vak van 855px. Gemeten op /keukens bij 950px: gridTemplateColumns gaf twaalf keer 0px en de area stak 25px buiten zijn container. Het omslagpunt ligt bij een container van 960px, en dat is precies de "vanaf ongeveer 950px" die gemeld werd. De drempel staat op 1200px en niet op dat omslagpunt van 960: tussen 960 en 1200 stort er niets in, maar blijft er wel bijna niets over. Gemeten bij een container van 1085px: sporen van 10px bij 80px goot. Met deze regel worden dat 65px sporen, en de area vult exact de contentbox. Boven de 1200px verandert er niets en blijft de 80px staan die live's afstanden reproduceert. Container query, want het gaat om de breedte van de blockgrid-container en niet om die van het venster: hetzelfde blok kan genest voorkomen. .umb-block-grid heeft hiervoor al container-type: inline-size. */ @container (max-width: 1200px) { .umb-block-grid__area-container { --umb-block-grid--areas-column-gap: 20px; } } /* Bovenaan uitlijnen, niet centreren. De area is een flex-kolom, dus justify-content werkt hier op de verticale as. Met `center` zakt de inhoud van een kolom naar het midden van de rij, en omdat twee kolommen zelden even veel tekst hebben beginnen hun afbeeldingen dan op verschillende hoogte. Gemeten op /duurzaamheid/product-materiaal: de afbeeldingen stonden op T3025 en T3057, de koppen op T3089 en T3121. Live kent dit niet: daar zijn de kolommen bootstrap `col-lg-*` met display: block, dus altijd bovenaan. Gemeten op live staan beide afbeeldingen op T2853 en beide koppen op T2917. flex-start is daarvan de tegenhanger. */ .umb-block-grid__area { justify-content: flex-start; } /* Is er een uitlijning ingesteld op het blok (areas.cshtml vertaalt `verticalAlign` naar een Bootstrap-class), dan moet de area zijn eigen hoogte krijgen. De basisregel hierboven zet `height: 100%`, waardoor de area de hele rij vult en align-items niets te verdelen heeft: gemeten bleef de area op h820 staan terwijl live's kolom h541 is. */ .umb-block-grid__area-container.align-items-start > .umb-block-grid__area, .umb-block-grid__area-container.align-items-center > .umb-block-grid__area, .umb-block-grid__area-container.align-items-end > .umb-block-grid__area { height: auto; } /* Staat een area rechtstreeks in een bribus .row, dan is die row een Bootstrap-flexrij en geen grid: grid-column-end doet daar niets, dus vielen de kolommen onder elkaar op volle breedte. Live zet op diezelfde plek een col-lg-*, met flex: 0 0 auto en een breedte van span/12. Dat is hier nagebouwd op basis van data-area-col-span; areas binnen een echte .umb-block-grid__area-container blijven grid en worden niet geraakt. Voorkomende spans in deze site: 4, 5, 6, 7, 8 en 12. Gemeten /keukenportaal: "Uw voordelen" was L233 w1440 T1279 (onder de tekst), nu L993 w680 T1000 - gelijk aan live. Onder 992px stapelt Bootstrap ook op live. */ @media (min-width: 992px) { .row > .umb-block-grid__area { flex: 0 0 auto; } .row > .umb-block-grid__area[data-area-col-span="4"] { width: 33.333333%; } .row > .umb-block-grid__area[data-area-col-span="5"] { width: 41.666667%; } .row > .umb-block-grid__area[data-area-col-span="6"] { width: 50%; } .row > .umb-block-grid__area[data-area-col-span="7"] { width: 58.333333%; } .row > .umb-block-grid__area[data-area-col-span="8"] { width: 66.666667%; } .row > .umb-block-grid__area[data-area-col-span="12"] { width: 100%; } } /* Onder 992px stapelen, ook in een echte area-container. -------------------------------------------------------------------------- De regel hierboven regelt dit al voor areas in een .row: die krijgen hun breedte pas vanaf 992px, en stapelen daaronder net als Bootstrap. Areas in een .umb-block-grid__area-container hielden hun span juist op ELKE breedte, want de basisregel van Umbraco rekent met grid-column-end: span en kent daar geen breekpunt in. Live doet dat wel: daar staat op deze plek een col-lg-*, en die geldt alleen vanaf de lg-breakpoint van 992px. Daaronder wordt zo'n kolom volle breedte. Gemeten op de backup bij 855px: op /over-bribus zijn beide col-lg-6 kolommen 855px breed en staan ze onder elkaar (top 1454 en 1740), en op /werken-bij is de col-lg-8 met het sollicitatieformulier 855px. Lokaal bleef datzelfde formulier op 510px steken - het gemelde "niet volle breedte". grid-column: 1 / -1 laat de area alle sporen overspannen, ongeacht de span-variabelen die Umbraco inline meegeeft. Boven 992px verandert er niets. */ @media (max-width: 991.98px) { .umb-block-grid__area-container > .umb-block-grid__area { grid-column: 1 / -1; } } /* Een .section binnen een area herhaalt de sectiepadding niet. -------------------------------------------------------------------------- Het thema heeft hiervoor al een regel (theme.scss regel 7887): .container-fluid .row > * .section { padding: 0; } Die hangt aan de bootstrap-keten .container-fluid > .row > .col-*, en juist die is in de blockgrid vervangen door .umb-block-grid__area-container > .umb-block-grid__area. De regel matcht daardoor nergens meer, en elke geneste sectie telt zijn 40px boven en 80px onder een tweede keer mee. Gemeten op /duurzaamheid/product-materiaal: de geneste sectie werd h661 tegen h501 op live, en die 120px stapelde door de pagina heen op tot +300px totale hoogte (7065 om 6765). De koppen stonden horizontaal exact goed, maar zakten verticaal steeds verder weg: +40, +140, +180, +220. De classes op het element zijn aan beide kanten gelijk (section full-banner narrow-page); alleen de ouder verschilt. */ .umb-block-grid__area .section { padding: 0; } /* Hoort bij dezelfde regel in het thema: een container-fluid binnen zo'n geneste sectie verliest daar ook zijn zijpadding. */ .umb-block-grid__area .section .container-fluid { padding-left: 0; padding-right: 0; } .umb-block-grid__layout-item[data-content-element-type-alias="oneColumnSectionBlock"] .umb-block-grid__layout-container { --umb-block-grid--column-gap: 40px; --umb-block-grid--row-gap: 40px; } /* Contentbreedte volgt live: .section--wrapper is 1680px breed en de inhoud daarbinnen 1600px (1680 - 2x40px padding). De 1200px uit het basisthema klemde elke area-container 400px te smal; live kent de umb-block-grid-markup niet en haalt die breedte uit .section--wrapper zelf. Gemeten op 1905px docwidth: /keukens section.kitchens live 153..1753 w1600, lokaal was 353..1553 w1200. */ .umb-block-grid { container-type: inline-size; --my-container-max-width: 1680px; --my-container-padding: 0 40px; } /*.root-block-element { overflow: hidden; }*/ /* Deze regel wint van de variabele hierboven voor elke area-container binnen een layout-container, dus de padding moet hier mee. Anders wordt het 1680 zonder padding. */ @container (min-width: 720px) { .umb-block-grid__layout-container { --my-container-padding: 0 40px; } } .umb-block-grid__block--inline-create-button.--above.--at-root { left: unset !important; width: 100% !important; } /* Ruimte onder een header met kaarten. -------------------------------------------------------------------------- Live heeft hiervoor: .header.has-cards + .main .section:first-of-type { padding-top: 192px; background-color: var(--licht); } De kaarten in zo'n header krijgen bewust `margin-bottom: -180px` en steken dus in de sectie eronder. Die 192px is de tegenhanger daarvan; zonder die ruimte schuift de eerste sectie onder de kaarten door. De selector hangt aan de aangrenzende-broer-combinator, en juist die keten is in de blockgrid weg: de header zit nu in .wrapper > .umb-block-grid__layout-container > .umb-block-grid__layout-item, waardoor .header geen broer meer is van .main. De regel matcht daardoor nergens meer, en dan valt de sectie terug op de 40px van de basisregel .section - en ook de achtergrondkleur vervalt. Gemeten op /referenties (docwidth 1905): de kaarten lopen aan beide kanten tot T756, maar de referentie-items begonnen lokaal op T716 en op live op T868 - 40px overlap tegenover 112px lucht. De sectie had lokaal padding-top 40px en een transparante achtergrond, live 192px en var(--licht). Met deze regel matcht hij weer precies een element. */ .wrapper:has(.header.has-cards) + .main .section:first-of-type { padding-top: 192px; background-color: var(--licht); } /* Breedte van de in een full-banner. -------------------------------------------------------------------------- De afbeeldingen in deze banners gebruiken lazysizes met data-sizes="auto". Die berekent de `sizes` uit de GERENDERDE breedte van het element. De is hier een flex-item zonder eigen breedte, dus hij krimpt naar de afbeelding zelf - en de afbeelding krijgt zijn breedte weer via width:100% van diezelfde . Die kringloop klapt dicht op de placeholder- breedte, waarna lazysizes `sizes: 149px` berekent en consequent de kleinste variant (160w) kiest. Gemeten op de homepage bij een viewport van 810px: de wrapper is 715px breed, maar de afbeelding laadde als 160w en rendert op 149px. Het thema heeft hier al een regel voor (theme.css regel 1478): .section.image-position-right .wrapper--full-banner-image picture { width: 100%; display: flex; } Alleen zit `image-position-right` in de markup op .wrapper--full-banner en niet op .section, waardoor die selector nergens aanslaat. Dat geldt ook voor de oude site - daar viel het niet op omdat de -elementen daar hun srcset niet kregen en de browser terugviel op de volledige afbeelding uit (gemeten naturalWidth 2384). De upgrade maakt de srcset wel effectief, en daardoor werd de al bestaande foute `sizes` pas zichtbaar. Zelfde declaraties als de themaregel, maar zonder voorouder-eis. De markup varieert namelijk: bij image-position-right zit .wrapper--full-banner-image in een .wrapper--full-banner, bij image-position-left hangt hij rechtstreeks onder de .section. Alleen .wrapper--full-banner-image komt in beide voor, en die klasse hoort sowieso uitsluitend bij deze banners. */ .wrapper--full-banner-image picture { width: 100%; display: flex; }