[CSS] Zijn em's nog relevant?

[Patriot]

Ik gebruik in de praktijk eigenlijk altijd 'absolute' px-waardes als ik mijn websites vormgeef. Ik ben op zich al een hele tijd bekend met em's, maar vond het gebruik ervan altijd maar nodeloos ingewikkeld. Dit waren de problemen waar ik tegenaan liep:

[ul]
• Om bepaalde maten overeen te laten komen met de maten uit het aangeleverde design, moest ik hoofdrekenen om aan de em's te komen (als een van nature lui persoon zit deze extra moeite me uiteraard enorm dwars)
• Nesting van elementen die een bepaalde aangepaste font-size hebben is problematisch. Voor deze elementen moet je een aparte regel aanmaken om een sneeuwbaleffect te voorkomen.
• Het aanpassen van de font-size in een bepaald element is tamelijk problematisch. De overige maten worden ook aangepast, waardoor het element ineens relatief meer of minder ruimte inneemt in de layout. Als je pech hebt, gaat het om een element hoog in de hiërarchie. Dan hebben alle child-elementen er óók last van. De enige oplossing, is de overige maten herberekenen.
• Het is in de stylesheet bijna onmogelijk om te weten welke waarde in em's overeenkomt met een bepaald formaat op het scherm. Bij sommige elementen is het nog te doen, maar op andere elementen moet je bewust zijn van de plaats in de DOM en alle overige regels die van toepassing zijn op het element.


Voor zover ik begrijp, zijn em's in het leven geroepen omdat het "inzoomen" op websites in sommige browsers betekende dat de font-size groter werd gemaakt. Daar zit op zich wat in: De meeste mensen die deze functie gebruiken doen dat omdat ze de tekst niet of niet goed kunnen lezen. Door alleen de font-size te vergroten, zorg je ervoor dat zaken als margins hetzelfde formaat op het scherm houden. Dat wil in het ideale geval zeggen dat de tekst beter leesbaar is, maar dat de website nog op het scherm past zonder dat er scrollbars aan te pas hoeven te komen.

Het gaat echter natuurlijk niet lang goed als de overige maten hetzelfde blijven, het schopt de layout in de war. Tekst in kleine elementen waar de tekst bij de originele font-size net in paste loopt opeens buiten het element, en is daardoor soms niet of nauwelijks meer te lezen. Alleen als je em's gebruikt voorkom je dit, dan schaalt het element namelijk wel mee.

Echter, nu zie ik persoonlijk in de praktijk dat de meeste browsers gewoon werkelijk zoomen: Ik vermoed zelf dat dat komt omdat em's in de praktijk niet of nauwelijks gebruikt werden, dus de zoomfuncties die alleen de font-size aanpasten kwamen op de meeste gebruikers over als zijnde "buggy". Nu lijkt het er dus op dat er gewoon weer compleet gezoomd wordt, en dat ze de font-size met rust laten.

Mijn vraag naar aanleiding van dit alles luidt: Hoe zinvol is het nog om in deze tijd em's te gebruiken? Is het niet verstandiger om gewoon overal px voor te gebruiken en de browsers van de gebruikers uit te laten zoeken hoe groot dat uiteindelijk wordt weergegeven? Of vergis ik me, en zijn er nog veel situaties waarin het gebruiken van em's toch beter is?

[Caelorum]

Uiteraard zijn is EM nog wel relevant. Zodra je een element hebt met tekst erin en je wilt dat deze altijd "correct" meeschaalt met de grootte van de tekst kan je dus em gebruiken. 1 EM == font size. Ook voor bijvoorbeeld text indenting enz. is em toch wel de betere keuze IMO.
Mocht je overigens weg komen met CSS3 dan kan je de rem unit gebruiken. Die compound niet met elkaar. Anders alle tags een font-size van 1em geven, al is dat wel een lelijke hack.. Overigens alle gangbare browsers (opera, ff, chrome, IE, safari) nieuwer dan 1 januari 2012 snappen rem.

Overigens een goede reden is als je een site maakt voor een doelgroep waar accessibility hoog in het vaandel staat. Sommige waarmerken/keurmerken vereisen dit. De precieze redenatie erachter ontgaat me echter even.

Overigens denk ik dat de vraag verkeerd om is, waarom niet een relatieve unit gebruiken, maar een fixed size unit, voor digitale schermen? Tenzij je dingen op papier moet afdrukken, zou ik altijd gaan voor em ipv pixels.
Als het even kan moet je gewoon geen user defined font size (of zelfs font) gaan overrulen. Sommige users (bijv. slechtzienden) hebben een groot font ingesteld in hun browser, juist zodat ze alles kunnen lezen. Als je het dan ineens van 40px gaat zitten veranderen naar 12px, maak je hun leven erg lastig. Dan zullen ze ofwel de stylesheet moeten uitzetten of de hele site gaan zoomen en scrollen als een gek. (als ze niet al hebben weggeklikt tegen die tijd).

[ Voor 53% gewijzigd door Caelorum op 03-12-2013 00:08 ]

[R4gnax]

Patriot schreef op maandag 02 december 2013 @ 23:36:
[ul]
• Om bepaalde maten overeen te laten komen met de maten uit het aangeleverde design, moest ik hoofdrekenen om aan de em's te komen (als een van nature lui persoon zit deze extra moeite me uiteraard enorm dwars)
• Nesting van elementen die een bepaalde aangepaste font-size hebben is problematisch. Voor deze elementen moet je een aparte regel aanmaken om een sneeuwbaleffect te voorkomen.
• Het aanpassen van de font-size in een bepaald element is tamelijk problematisch. De overige maten worden ook aangepast, waardoor het element ineens relatief meer of minder ruimte inneemt in de layout. Als je pech hebt, gaat het om een element hoog in de hiërarchie. Dan hebben alle child-elementen er óók last van. De enige oplossing, is de overige maten herberekenen.
• Het is in de stylesheet bijna onmogelijk om te weten welke waarde in em's overeenkomt met een bepaald formaat op het scherm. Bij sommige elementen is het nog te doen, maar op andere elementen moet je bewust zijn van de plaats in de DOM en alle overige regels die van toepassing zijn op het element.

FYI; Het merendeel van, zo niet al, deze 'problemen' zijn te vermijden door je CSS op de juiste wijze in elkaar te steken en op de juiste plek je font-size te wijzigen. Schrijf je CSS components-gewijs en ga zo dicht mogelijk tegen het element aan zitten waar de font-size gewijzigd getoond moet worden.

Jouw probleem is waarschijnlijk niet de em maat, maar je CSS opzet.

[ Voor 5% gewijzigd door R4gnax op 03-12-2013 01:02 ]

[TimDJ]

Ik gebruik sinds kort rem met fallback naar px. Sowieso kun je je base font-size verkleinen zodat 1em overeenkomt met 10px.

Cascading Stylesheet:

body { font-size:62.5%; }
h1 { font-size: 2.4em; } /* =24px */
p  { font-size: 1.4em; } /* =14px */

zie http://snook.ca/archives/html_and_css/font-size-with-rem voor meer uitleg

[Patriot]

Caelorum schreef op maandag 02 december 2013 @ 23:57:
Uiteraard zijn is EM nog wel relevant. Zodra je een element hebt met tekst erin en je wilt dat deze altijd "correct" meeschaalt met de grootte van de tekst kan je dus em gebruiken. 1 EM == font size. Ook voor bijvoorbeeld text indenting enz. is em toch wel de betere keuze IMO.

Je hebt gelijk hoor, de hoofdreden dat ik deze discussie ben gestart is omdat ik benieuwd ben welke redenen er nou nog zijn om em's te gebruiken. Ik denk dat er nog maar weinig situaties (de situaties die je noemt zijn goede voorbeeld) zijn overgebleven.

Mocht je overigens weg komen met CSS3 dan kan je de rem unit gebruiken. Die compound niet met elkaar. Anders alle tags een font-size van 1em geven, al is dat wel een lelijke hack.. Overigens alle gangbare browsers (opera, ff, chrome, IE, safari) nieuwer dan 1 januari 2012 snappen rem.

Weet ik, maar het gaat mij om em's.

Overigens een goede reden is als je een site maakt voor een doelgroep waar accessibility hoog in het vaandel staat. Sommige waarmerken/keurmerken vereisen dit. De precieze redenatie erachter ontgaat me echter even.

Mijn belangrijkste "tegenargument" wat dit betreft is dat ik het idee heb dat het in de praktijk niet meer uitmaakt of je nou em's of px's gebruikt. Als je een website die volledig is gemaakt met px-waardes ombouwt naar eentje die em's gebruikt, verandert er bij de moderne browsers in de praktijk niets namelijk.

Overigens denk ik dat de vraag verkeerd om is, waarom niet een relatieve unit gebruiken, maar een fixed size unit, voor digitale schermen? Tenzij je dingen op papier moet afdrukken, zou ik altijd gaan voor em ipv pixels.

Nouja, hoe absoluut zijn px's? Uiteindelijk heeft de client het laatste woord, die gaat bepalen hoeveel pixels het in de praktijk op het scherm gaat zijn.

Als het even kan moet je gewoon geen user defined font size (of zelfs font) gaan overrulen. Sommige users (bijv. slechtzienden) hebben een groot font ingesteld in hun browser, juist zodat ze alles kunnen lezen. Als je het dan ineens van 40px gaat zitten veranderen naar 12px, maak je hun leven erg lastig. Dan zullen ze ofwel de stylesheet moeten uitzetten of de hele site gaan zoomen en scrollen als een gek. (als ze niet al hebben weggeklikt tegen die tijd).

Ok, daar zit wat in. Het is dus weliswaar niet langer relevant voor zoomacties (want zoomen doen clients in de praktijk niet meer met font-size), maar het is wel relevant om te gebruiken voor users die zelf de font-size aanpassen. Echter, als je voor die gebruikers steeds em's gebruikt, dan is het eindresultaat toch hetzelfde als wanneer de gebruiker ingezoomed zou zijn?

R4gnax schreef op dinsdag 03 december 2013 @ 01:00:
[...]


FYI; Het merendeel van, zo niet al, deze 'problemen' zijn te vermijden door je CSS op de juiste wijze in elkaar te steken en op de juiste plek je font-size te wijzigen. Schrijf je CSS components-gewijs en ga zo dicht mogelijk tegen het element aan zitten waar de font-size gewijzigd getoond moet worden.

Jouw probleem is waarschijnlijk niet de em maat, maar je CSS opzet.

Ok, dan de volgende voorbeelden:

Cascading Stylesheet:

body {
  font-size: 62.5%;
}

div#header {
  width: 1000px;
}

div#header img {
  width: 125px;
}

Vanuit mijn aangeleverde design heb ik de maten van de header en het logo. Om die verhoudingen hetzelfde te houden, moet ik deze maten toch omrekenen naar em's, of ligt dat aan mij? Dat was punt 1.

Cascading Stylesheet:

body {
  font-size: 62.5%;
}
li {
  font-size: 0.8em;
}

In dit voorbeeld wil ik dat list items een iets kleinere font-size krijgen. Hoe voorkom ik dan, zonder een aparte regel aan te maken voor geneste list items dat dieper geneste list items steeds kleiner worden? Dat was punt 2.

Cascading Stylesheet:

body {
  font-size: 62.5%;
}

div#tracker {
  font-size: 1.2em;
  width: 30em;
  height: 10em;
  padding: 0.5em;
}

Punt drie, was het wijzigen van de font-size die roet in het eten kon gooien voor andere maten. Hoe verander ik van dit element de font-size weer terug naar 1.0 zonder de overige maten te veranderen maar met behoud van de relatieve grootte van dit element t.o.v. andere elementen op de pagina?

Cascading Stylesheet:

body {
  font-size: 62.5%;
}

div.important {
  font-size: 2em;
}

div.funny {
  font-size: 0.5em;
}

Hoe zie ik hier, met behulp van uitsluitend de stylesheet, welke font-size t.o.v. de andere elementen op de pagina een div met de class funny heeft? Misschien is ie wel genest in een div met de class important. Er valt volgens mij niks interessants over te zeggen. Dat was punt 3.

Ik hoor graag hoe je de CSS aan moet pakken om deze problemen niet voor te laten komen.

[ Voor 27% gewijzigd door Patriot op 03-12-2013 12:23 ]

[_Thanatos_]

TimDJ schreef op dinsdag 03 december 2013 @ 04:11:
Ik gebruik sinds kort rem met fallback naar px. Sowieso kun je je base font-size verkleinen zodat 1em overeenkomt met 10px.

Cascading Stylesheet:

body { font-size:62.5%; }
h1 { font-size: 2.4em; } /* =24px */
p  { font-size: 1.4em; } /* =14px */

zie http://snook.ca/archives/html_and_css/font-size-with-rem voor meer uitleg

Dat werkt niet in IE9-10-11.

"font-size:62.5%" wordt afgerond naar 62% en komt daarbij met afronding uit op 9.93px (zie de inspector). Ga je daarmee dingen schalen, komen ze "onverklaarbaar" niet overeen met je design. Font's kunnen daardoor ook "net anders" zijn dan hoe je ze verwacht. Helemaal als je er ook plaatjes mee gaat schalen (wat ik altijd doe), komen ze blurry uit op LDPI-schermen zoals bijna alle desktops. Dit geldt óók voor SVG plaatjes die bedoeld zijn voor óf een specifieke afmeting bij LDPI, óf HDPI.

Mijn oplossing:

Cascading Stylesheet:

html { font-size: 125%; } //16px wordt 20px
body { font-size: 50%; } //20px wordt 10px

Zo is je "basis" feitelijk 1em=10px, tenzij je dus aan de font-size van een element gaat zitten. Maar de berekening is hoe dan ook altijd makkelijk, want 1em=font-size

[ Voor 11% gewijzigd door _Thanatos_ op 03-12-2013 13:19 ]

[Bosmonster]

Ok, daar zit wat in. Het is dus weliswaar niet langer relevant voor zoomacties (want zoomen doen clients in de praktijk niet meer met font-size), maar het is wel relevant om te gebruiken voor users die zelf de font-size aanpassen. Echter, als je voor die gebruikers steeds em's gebruikt, dan is het eindresultaat toch hetzelfde als wanneer de gebruiker ingezoomed zou zijn?

Oudere IE's zijn helaas niet zo schappelijk met dit soort zoomwerk. Je bent verantwoordelijk voor het juist schalen van de website, of de tekst, ook in oudere browsers, volgens de richtlijnen. Er staat niks over dat je em's moet gebruiken, dat is slechts het advies.

Als je niet van plan bent om je site te laten toetsen, dan zou ik me er ook niet druk over maken en kiezen voor de weg van de minste weerstand: px.

Zo is je "basis" feitelijk 1em=10px, [etc..]

De 1em=10px methodes (op welke manier dan ook) hebben altijd een groot nadeel, namelijk dat je default fontgrootte ingesteld wordt op 10px, wat altijd veel te weinig is. Uiteindelijk ben je dus alles, per element aan het overschrijven, wat enorme nadelen heeft en je uiteindelijk juist in de nesten (pun intended) kan werken.

Deze methode stamt ook nog uit de tijd dat een 10px basisgrootte acceptabel was. Lang geleden dus.

Handiger is een base fontgrootte bepalen van je site (bijvoorbeeld 16px oid, afhankelijk van het design) en op basis daarvan de em-waardes te berekenen. Het grote voordeel is dat je alleen mutaties op de basis hoeft te definieren ipv alles. En dat je dus em's kunt gebruiken alsof het pixels zijn in 90% van de gevallen.

Nadeel is dat je wat aparte waardes krijgt voor je fontgroottes, maar een simpel lijstje of iets als sass of less, kan je daar bij helpen.

[ Voor 15% gewijzigd door Bosmonster op 03-12-2013 13:29 ]

[Patriot]

Bosmonster schreef op dinsdag 03 december 2013 @ 13:24:
[...]


Oudere IE's zijn helaas niet zo schappelijk met dit soort zoomwerk. Je bent verantwoordelijk voor het juist schalen van de website, of de tekst, ook in oudere browsers, volgens de richtlijnen. Er staat niks over dat je em's moet gebruiken, dat is slechts het advies.

Eens. Als die oudere browsers een significant deel van je doelgroep zijn, is het gebruik van em's dus relevant. Op deze manier zorg je ervoor dat die browers ook daadwerkelijk gaan zoomen, in plaats van het slechts verhogen van de font-size met alle problemen van dien.

Dit komt wel overeen met wat ik dacht, namelijk dat het vergroten d.m.v. het aanpassen van de font-size en het gebruik van em's in theorie goed kan werken, maar in de praktijk niet werkt omdat mensen zich er niet aan hebben gehouden. Daarom schalen de nieuwe browsers dus maar gewoon alles, omdat dat in de praktijk beter werkt (ook al worden de niet-relevante delen van de website dan onnodig vergroot).

Als je niet van plan bent om je site te laten toetsen, dan zou ik me er ook niet druk over maken en kiezen voor de weg van de minste weerstand: px.

Dat lijkt mij ook het meest verstandig. Het gebruik van em's is het mij in de praktijk de moeite niet waard, als het alleen gaat om de zoommogelijkheden van bezoekers met oude browsers. Ik zal het nog eens overwegen als deze een significant deel van m'n doelgroep omvatten.

[R4gnax]

Patriot schreef op dinsdag 03 december 2013 @ 12:10:
Ok, dan de volgende voorbeelden:

Cascading Stylesheet:

body {
  font-size: 62.5%;
}

div#header {
  width: 1000px;
}

div#header img {
  width: 125px;
}

Vanuit mijn aangeleverde design heb ik de maten van de header en het logo. Om die verhoudingen hetzelfde te houden, moet ik deze maten toch omrekenen naar em's, of ligt dat aan mij? Dat was punt 1.

Ik zie niet in hoe een breedte maat voor een block container header en een pixel based logo plaatje hier relevant is. Ik zie alleen wel dat je voor je CSS met IDs werkt ipv classes, dat je selectors overqualified maakt, dat je dankzij het gebruik van een descendant combinator vs een child combinator een veel breder en moeilijker te beteugelen selector opzet dan mogelijk nodig is, en dat je als right-hand key selector een niet nader gekwalificeerde tag selector gebruikt wat i.c.m. die descendant combinator behoorlijk duur is om te evalueren.

Patriot schreef op dinsdag 03 december 2013 @ 12:10:

Cascading Stylesheet:

body {
  font-size: 62.5%;
}
li {
  font-size: 0.8em;
}

In dit voorbeeld wil ik dat list items een iets kleinere font-size krijgen. Hoe voorkom ik dan, zonder een aparte regel aan te maken voor geneste list items dat dieper geneste list items steeds kleiner worden?

Dit soort stellingen valt een beetje in de categorie: "Kun je voor me een klein en precies gaatje in mijn muur maken met deze pneumatische hamer?"

In dit geval: door niet zulke domme arbitraire CSS te schrijven, maar je scope te vernauwen met juist gekozen CSS selectors. Bijv. een selector .list--fineprint die enkel op het hoogste niveau <ul>, <ol> of <dl> toegepast kan worden.

Patriot schreef op dinsdag 03 december 2013 @ 12:10:

Cascading Stylesheet:

body {
  font-size: 62.5%;
}

div#tracker {
  font-size: 1.2em;
  width: 30em;
  height: 10em;
  padding: 0.5em;
}

Punt drie, was het wijzigen van de font-size die roet in het eten kon gooien voor andere maten. Hoe verander ik van dit element de font-size weer terug naar 1.0 zonder de overige maten te veranderen maar met behoud van de relatieve grootte van dit element t.o.v. andere elementen op de pagina?

Waarom heeft dat element een breedte van 30em nodig? Waarom heeft dat element een hoogte van 10em nodig? Wat is dat voor element? Wat staat er voor content in? Had je de tekst grootte niet beter op die content aan kunnen passen? Was het misschien meer toepasselijk geweest om een procentuele breedte t.o.v. het parent element te gebruiken? Als het een container is met een 3:1 beeldverhouding, had je dan niet beter CSS kunnen schrijven die dat realiseert. (Wat overigens vrij simpel is als je het trucje eenmaal kent.)

Patriot schreef op dinsdag 03 december 2013 @ 12:10:

Cascading Stylesheet:

body {
  font-size: 62.5%;
}

div.important {
  font-size: 2em;
}

div.funny {
  font-size: 0.5em;
}

Hoe zie ik hier, met behulp van uitsluitend de stylesheet, welke font-size t.o.v. de andere elementen op de pagina een div met de class funny heeft? Misschien is ie wel genest in een div met de class important. Er valt volgens mij niks interessants over te zeggen. Dat was punt 3.

Waarom zou je dat uitsluitend met de stylesheet moeten zien? Waarom moet een element met de 'important' class tekst in het algemeen 2x zo groot maken, en een element met 'funny' juist 2x zo klein? Gaat het in die gevallen niet juist om het ratio tussen de grootte van de tekst in het element en de tekst er om heen? Zou je in dat geval niet juist willen dat dat ratio intact blijft? En als je dat niet zou willen; heb je dan je CSS selector niet gewoon te breed uitgezet?

Patriot schreef op dinsdag 03 december 2013 @ 12:10:
Ik hoor graag hoe je de CSS aan moet pakken om deze problemen niet voor te laten komen.

Door beter na te denken over het logisch opsplitsen van een design in zo klein mogelijke componenten die je makkelijk op verschillende plaatsen in verschillende soorten layout structuren kunt rangschikken.

Aan alles wat ik je hier zie schrijven merk ik enkel dat je vastgeroest zit in het denken in concrete maten, terwijl je juist veel meer moet denken in beeldverhoudingen, ritmes en hoe deze te vangen zijn in layout structuur vs content structuur. Maak die opdeling en je zult zien dat het ineens zo veel makkelijker wordt.

[ Voor 5% gewijzigd door R4gnax op 03-12-2013 21:45 ]

[Patriot]

R4gnax schreef op dinsdag 03 december 2013 @ 21:38:
[...]


Ik zie niet in hoe een breedte maat voor een block container header en een pixel based logo plaatje hier relevant is. Ik zie alleen wel dat je voor je CSS met IDs werkt ipv classes, dat je selectors overqualified maakt, dat je dankzij het gebruik van een descendant combinator vs een child combinator een veel breder en moeilijker te beteugelen selector opzet dan mogelijk nodig is, en dat je als right-hand key selector een niet nader gekwalificeerde tag selector gebruikt wat i.c.m. die descendant combinator behoorlijk duur is om te evalueren.

Nouja, je omzeilt handig mijn punt, dat dan weer wel. Het stukje CSS erbij is irrelevant (verder, voor je gemoedsrust: Zo ziet mijn CSS er niet uit), het gaat erom dat de meeste designs die ik aangeleverd krijg bepaalde maten in pixels hebben en dat ik die steeds moet omrekenen als ik met em's aan de slag ga.

[...]

Dit soort stellingen valt een beetje in de categorie: "Kun je voor me een klein en precies gaatje in mijn muur maken met deze pneumatische hamer?"

In dit geval: door niet zulke domme arbitraire CSS te schrijven, maar je scope te vernauwen met juist gekozen CSS selectors. Bijv. een selector .list--fineprint die enkel op het hoogste niveau <ul>, <ol> of <dl> toegepast kan worden.

Maar volgens het design moeten alle lijstjes die aangepaste font-size krijgen. Mag dat niet dan? Verder is jouw oplossing niet anders dan een rule set waar je geneste li's een font-size van em's geeft natuurlijk. Je zit nog steeds met een extra rule set die je niet nodig had gehad als je geen em's had gebruikt.

[...]

Waarom heeft dat element een breedte van 30em nodig? Waarom heeft dat element een hoogte van 10em nodig? Wat is dat voor element? Wat staat er voor content in? Had je de tekst grootte niet beter op die content aan kunnen passen? Was het misschien meer toepasselijk geweest om een procentuele breedte t.o.v. het parent element te gebruiken? Als het een container is met een 3:1 beeldverhouding, had je dan niet beter CSS kunnen schrijven die dat realiseert. (Wat overigens vrij simpel is als je het trucje eenmaal kent.)

Je omzeilt mijn vraag door in te gaan op irrelevante eigenschappen van het voorbeeld. Het punt is: In een situatie waarin je em's gebruikt om bepaalde maten op te geven is het vervelend als je achteraf de font-size moet veranderen omdat je dan alle overige maten moet gaan herberekenen om te voorkomen dat het element ineens groter of kleiner is ten opzichte van andere elementen.

[...]

Waarom zou je dat uitsluitend met de stylesheet moeten zien?

Omdat als je bijvoorbeeld gebruik maakt van rem's of px's je dat voordeel wél hebt. Dan kun je aan de hand van je stylesheet zien wat de tekst in een element dat door zo'n selector beschreven wordt gaat doen. Dat is natuurlijk tijdens het ontwikkelen niet zo heel interessant, ik ga ervan uit dat je dan het e.e.a. wel in je hoofd hebt zitten, maar het is wel zo fijn om te weten op het moment dat je de stylesheet na een half jaar weer bezoekt om wat aanpassingen te doen.

Waarom moet een element met de 'important' class tekst in het algemeen 2x zo groot maken, en een element met 'funny' juist 2x zo klein? Gaat het in die gevallen niet juist om het ratio tussen de grootte van de tekst in het element en de tekst er om heen? Zou je in dat geval niet juist willen dat dat ratio intact blijft? En als je dat niet zou willen; heb je dan je CSS selector niet gewoon te breed uitgezet?

Ok, dat is een redelijke aanname, mijn voorbeeld is in die zin een beetje brak en de uitleg van mijn punt was misschien niet optimaal. Dit punt staat in mijn ogen hergebruik in de weg omdat een bepaald element opeens andere maten kan krijgen a.d.h.v. de context waarin het zich bevind.

Dat punt kwam uit iets wat ik in de praktijk heb meegemaakt bij onderhoud aan een website die ik zelf niet heb gemaakt: Een button (volledig met CSS gestyled) moest gekopieerd worden zodat hij op twee plaatsen in de pagina beschikbaar was. Dat had een simpele copy/paste-actie in de markup geweest kunnen zijn, maar in plaats daarvan moest de stylesheet aangepast worden omdat het formaat van de knop anders ineens niet meer overeen kwam met wat de klant wilde. Nu was het geen grote verandering, maar het is wel weer extra werk en dat vind ik gewoon zonde.

[...]

Door beter na te denken over het logisch opsplitsen van een design in zo klein mogelijke componenten die je makkelijk op verschillende plaatsen in verschillende soorten layout structuren kunt rangschikken.

Nouja, uit mijn laatste punt had je misschien kunnen halen dat ik juist het idee heb dat je dát voor jezelf lastiger maakt als je de eenheden gebruikt die hun lengtemaat specificeren relatief aan een andere lengtemaat (met andere woorden: em's) omdat de context waarin elementen zich bevinden ineens cruciaal is.

Aan alles wat ik je hier zie schrijven merk ik enkel dat je vastgeroest zit in het denken in concrete maten, terwijl je juist veel meer moet denken in beeldverhoudingen, ritmes en hoe deze te vangen zijn in layout structuur vs content structuur. Maak die opdeling en je zult zien dat het ineens zo veel makkelijker wordt.

Je begint over verhoudingen, maar juist daarvoor zijn em's een drama. Een simpele wijziging in markup of stylesheet kan namelijk die verhoudingen in de war schoppen. Een bepaalde verhouding tussen twee elementen is in de absolute eenheden die CSS kent vele malen makkelijker te beschrijven dan in de relatieve lengtematen, omdat de verhouding in waarde compleet anders kan zijn dan de verhouding in lengte. Als je een verhouding van 3:1 wilt dan kun je dat bijvoorbeeld uitdrukken als 30pt:10pt, aan de waardes zie je al dat het om een 3:1 verhouding gaat. Datzelfde kan niet met em's omdat je daarvoor de font-size moet weten, een 12em:0.5em kan ook 3:1 zijn als de font-sizes bijv. respectievelijk 25px en 200px waren.

[kaesve]

Als je een ontwerp aangeleverd krijgt waarin de pixelmaten vast staan, is de pixel-eenheid een logische keuze. Maar een ontwerp kan ook grotendeels gebaseerd zijn op de standaard regelhoogte. Zie bijvoorbeeld dit artikel. In zo'n ontwerp vind ik het prettig om die hierarchie/relatie ook weer te geven in mijn stijldefinities. Bovendien kun je door overal ems en rems en procenten te gebruiken makkelijker je hele website later een keer een stukje groter of kleiner maken. Dat maakt zoiets als 'fluid type' lekker makkelijk.

[incaz]

Patriot: helemaal mee eens. De meerwaarde van em's is op dit moment behoorlijk beperkt (al is het mogelijk toch iets relevanter dan gehoopt omdat px-grootte ook per browser (*#!$* IE ) nog voor verschillen kan zorgen) en de discussie is vaak meer een principiele dan een praktische. Waarbij concrete bezwaren (zoals inderdaad de overervingsproblemen, die best snel optreden en helemaal niet zo triviaal zijn om te omzeilen) vaak weggewuifd worden omdat je het verkeerde zou willen.

Maar persoonlijk ga ik liever uit van een pragmatische benadering dan van een principiele, bij webbouwen. En daarbij hoop ik snel de rems in te kunnen zetten, ems hebben toch vooral nut als je een relatieve grootte ten opzichte van de directe context nodig hebt, of bv een marge of padding aan wilt passen aan de daar geldende fontgrootte. (En zelfs dat heb ik vanwege renderingverschillen en moeilijkheden om bv een header en een paragraph recht onder elkaar uit te lijnen vanwege verschillen in fontsize al vaak weer vastgezet op px.)
Een hele website aan elkaar knopen met relatieve maten is vragen om problemen.

Oh ja, en ik zet ook wel eens een fontsize op 0 om whitespace te verbergen. Dat krijg je daarna dus noooooit meer gecorrigeerd met ems.

[R4gnax]

Patriot schreef op dinsdag 03 december 2013 @ 22:37:
Nouja, je omzeilt handig mijn punt, dat dan weer wel. Het stukje CSS erbij is irrelevant (verder, voor je gemoedsrust: Zo ziet mijn CSS er niet uit), het gaat erom dat de meeste designs die ik aangeleverd krijg bepaalde maten in pixels hebben en dat ik die steeds moet omrekenen als ik met em's aan de slag ga.

Als je die steeds moet omrekenen zonder dat er een logisch verband is tussen die pixel maten en de grootte van de tekst, dan ben je op de verkeerde plekken met em maten bezig. Daar ineens een rem unit gaan gebruiken gaat daar weinig tot niets aan verbeteren.

Patriot schreef op dinsdag 03 december 2013 @ 22:37:
Maar volgens het design moeten alle lijstjes die aangepaste font-size krijgen. Mag dat niet dan? Verder is jouw oplossing niet anders dan een rule set waar je geneste li's een font-size van em's geeft natuurlijk. Je zit nog steeds met een extra rule set die je niet nodig had gehad als je geen em's had gebruikt.

Nee; volgens het design is er een bepaald type lijst wat met grote regelmaat terugkomt. Dat wil niet zeggen dat ineens elk voorkomen van een <li> element daaraan moet conformeren. Als je die weg in zou slaan kun je je lol op als uiteindelijk blijkt dat er toch uitzonderingen zijn waar je list items 'normaal' wilt houden. Bijvoorbeeld in een table of contents, een navigatielijst met jump links, etc.

Daarmee vervalt dan ook gelijk dat bezwaar op extra rulesets; je kunt beter twee regels meer spenderen om een niet conflicterend iets op te bouwen dan achteraf de hele tijd allerlei te globaal opgezette selectors 'ongedaan' proberen te maken. Als je dat dan nog eens gaat combineren met specificity verschillen in selectors dan is het feest compleet en eindig je onherroepelijk met een compleet ononderhoudbare pleurisbende.

Patriot schreef op dinsdag 03 december 2013 @ 22:37:
Je omzeilt mijn vraag door in te gaan op irrelevante eigenschappen van het voorbeeld. Het punt is: In een situatie waarin je em's gebruikt om bepaalde maten op te geven is het vervelend als je achteraf de font-size moet veranderen omdat je dan alle overige maten moet gaan herberekenen om te voorkomen dat het element ineens groter of kleiner is ten opzichte van andere elementen.

Nogmaals; dan verander je de font-size op het verkeerde punt. Je font-size is gekoppeld aan het type content wat je aan het tonen bent. Als je meerdere typen content bij elkaar in een container groepeert, dan ga je dus niet je font-size op die gegroepeerde container hangen en dan weer allerhande special casing voor content maken die in die container kan hangen.

Ten eerste maak je daar mee ononderhoudbare en onnodige grote CSS aan, ten tweede limiteer je jezelf in flexibiliteit; je zet de typen content die samen gegroepeerd kunnen worden in een container op zo'n manier feitelijk 'op slot'. Voor elk nieuw soort content dat je er bij wilt plaatsen moet je immers nieuwe uitzonderingen coderen om de font-size wijziging op de container voor die specifieke content ongedaan te maken.

Het bovenstaande geldt natuurlijk niet alleen voor font-size, maar in principe voor elke property die overerft wordt: color, line-height, text-align, etc.

Patriot schreef op dinsdag 03 december 2013 @ 22:37:
Omdat als je bijvoorbeeld gebruik maakt van rem's of px's je dat voordeel wél hebt. Dan kun je aan de hand van je stylesheet zien wat de tekst in een element dat door zo'n selector beschreven wordt gaat doen. Dat is natuurlijk tijdens het ontwikkelen niet zo heel interessant, ik ga ervan uit dat je dan het e.e.a. wel in je hoofd hebt zitten, maar het is wel zo fijn om te weten op het moment dat je de stylesheet na een half jaar weer bezoekt om wat aanpassingen te doen.

Een font-size van 1.2em vertelt me dat een element om de een of andere reden de tekst groter maakt. Waarschijnlijk om er extra nadruk op te leggen; bijvoorbeeld omdat het een element met heading eigenschappen betreft. Het feit dat een element een font-size van 16px heeft zegt me daarentegen niets; daar moet ik eerst context bij hebben: is 20px klein, groot of normaal in verhouding tot andere elementen in de site?

Patriot schreef op dinsdag 03 december 2013 @ 22:37:
Ok, dat is een redelijke aanname, mijn voorbeeld is in die zin een beetje brak en de uitleg van mijn punt was misschien niet optimaal. Dit punt staat in mijn ogen hergebruik in de weg omdat een bepaald element opeens andere maten kan krijgen a.d.h.v. de context waarin het zich bevind.

Niet als je dus je indeling op orde hebt en je de juiste CSS properties op de juiste elementen aanpast.

Patriot schreef op dinsdag 03 december 2013 @ 22:37:
Dat punt kwam uit iets wat ik in de praktijk heb meegemaakt bij onderhoud aan een website die ik zelf niet heb gemaakt: Een button (volledig met CSS gestyled) moest gekopieerd worden zodat hij op twee plaatsen in de pagina beschikbaar was. Dat had een simpele copy/paste-actie in de markup geweest kunnen zijn, maar in plaats daarvan moest de stylesheet aangepast worden omdat het formaat van de knop anders ineens niet meer overeen kwam met wat de klant wilde. Nu was het geen grote verandering, maar het is wel weer extra werk en dat vind ik gewoon zonde.

En dat is wat je krijgt als je in bestaande prut moet gaan roeren die niet goed opgezet is; dan mag je een uphill battle gaan voeren tegen de bestaande implementatie die elke keer om dondert.

Patriot schreef op dinsdag 03 december 2013 @ 22:37:
Nouja, uit mijn laatste punt had je misschien kunnen halen dat ik juist het idee heb dat je dát voor jezelf lastiger maakt als je de eenheden gebruikt die hun lengtemaat specificeren relatief aan een andere lengtemaat (met andere woorden: em's) omdat de context waarin elementen zich bevinden ineens cruciaal is.

[...]

Je begint over verhoudingen, maar juist daarvoor zijn em's een drama. Een simpele wijziging in markup of stylesheet kan namelijk die verhoudingen in de war schoppen.

Alleen als je niet een net CSS raamwerk opzet en dat fout laat gaan. Als alle 'componenten' die andere componenten als inhoud kunnen accepteren zo opgezet zijn dat ze altijd gebruik maken van een zinnige basislijn, dan heb je dat probleem niet.

Omgekeerd; het op de juiste wijze gebruiken van de em maat opent juist de mogelijkheid om componenten mee te laten groeien wanneer dat wel gewenst is. Voorbeeld; een icoon uit een icon-font wil ik verticaal gecentreerd en links gedocked hebben staan (bijvoorbeeld voor in een grafisch mooi uitgewerkt type knop):

Cascading Stylesheet:

.icon {
  height : 1em;
  width  : 1em;
}
.icon--docked-left {
  margin-top : .-5em;
  position : absolute;
  top : 50%;
  left : 0;
}

.icon--size-s { font-size : 12px; }
.icon--size-m { font-size : 16px; }
.icon--size-l { font-size : 24px; }
}

Als je hier niet ems zou gebruiken zou je juist voor elke individuele maat van icoon een aparte uitlijning moeten gaan schrijven. Door van die schalende factor gebruik te maken juist niet. En geef je geen expliciete maat voor een icoon op; dan neemt een icoon de bestaande tekst grootte mee over en balanceert deze zichzelf nog steeds netjes.

Patriot schreef op dinsdag 03 december 2013 @ 22:37:
Een bepaalde verhouding tussen twee elementen is in de absolute eenheden die CSS kent vele malen makkelijker te beschrijven dan in de relatieve lengtematen, omdat de verhouding in waarde compleet anders kan zijn dan de verhouding in lengte. Als je een verhouding van 3:1 wilt dan kun je dat bijvoorbeeld uitdrukken als 30pt:10pt, aan de waardes zie je al dat het om een 3:1 verhouding gaat. Datzelfde kan niet met em's omdat je daarvoor de font-size moet weten, een 12em:0.5em kan ook 3:1 zijn als de font-sizes bijv. respectievelijk 25px en 200px waren.

Ik bedoelde eigenlijk de breedte:hoogte verhouding binnen een element. Misschien dat de term aspectratio duidelijker was geweest.

Bijvoorbeeld twee containers; één in een 3:1 verhouding en één in een 3:2 verhouding. Allebei 50% van de beschikbare breedte. Die twee containers gaan dan in de hoogte altijd onderling een 1:2 verhouding hebben. Daar komt geen em of pixel meer bij kijken; dat is intern allemaal percentage werk, wat best fijn werkt met (semi-)fluid designs.

Verder is je voorbeeld voor een em-ratio een gekunstelde situatie die nergens op slaat: wie gaat er nou in hemelsnaam een ratio opzetten in em maten die niet op dezelfde basis gevoet zijn? Daar hebben we een uitdrukking voor; dat is appels met peren vergelijken.

[Patriot]

R4gnax schreef op woensdag 04 december 2013 @ 21:46:
[...]


Als je die steeds moet omrekenen zonder dat er een logisch verband is tussen die pixel maten en de grootte van de tekst, dan ben je op de verkeerde plekken met em maten bezig. Daar ineens een rem unit gaan gebruiken gaat daar weinig tot niets aan verbeteren.

Dan vervang je at best de situatie omrekenen naar em's met de situatie verhouding ten opzichte van de font-size nameten en daarop je maten in em's baseren. Dat is van pixels naar em's omrekenen met een omweg, maar het blijft omrekenen.

[...]

Nee; volgens het design is er een bepaald type lijst wat met grote regelmaat terugkomt. Dat wil niet zeggen dat ineens elk voorkomen van een <li> element daaraan moet conformeren. Als je die weg in zou slaan kun je je lol op als uiteindelijk blijkt dat er toch uitzonderingen zijn waar je list items 'normaal' wilt houden. Bijvoorbeeld in een table of contents, een navigatielijst met jump links, etc.

Een class toevoegen als 'list-item' is in mijn ogen te redundant voor worden. Ook in een lokale context kan het logisch zijn om een style op een selector als 'li' te gooien (even buiten beschouwing gelaten dat dat niet de volledig selector is om in die context te komen).

Daarmee vervalt dan ook gelijk dat bezwaar op extra rulesets; je kunt beter twee regels meer spenderen om een niet conflicterend iets op te bouwen dan achteraf de hele tijd allerlei te globaal opgezette selectors 'ongedaan' proberen te maken. Als je dat dan nog eens gaat combineren met specificity verschillen in selectors dan is het feest compleet en eindig je onherroepelijk met een compleet ononderhoudbare pleurisbende.

Dat is niet waar. Ook een niet-globale style heeft hier last van. Iedere context waarin geneste li's voorkomen waarbij het niet logisch is om die li's een class toe te wijzen heeft dit probleem. Je kunt dan wel liberaal met classes gaan strooien maar dan ben je ook niet efficiënt bezig.


[quote[[...]

Nogmaals; dan verander je de font-size op het verkeerde punt. Je font-size is gekoppeld aan het type content wat je aan het tonen bent. Als je meerdere typen content bij elkaar in een container groepeert, dan ga je dus niet je font-size op die gegroepeerde container hangen en dan weer allerhande special casing voor content maken die in die container kan hangen.[/]

Dit probleem is hier niet aan gerelateerd. Als een bepaald uniek element in eerste instantie een bepaalde font-size heeft en andere daar aan gekoppelde maten, en de designer besluit dat de font-size omhoog moet en overige maten niet moet je de overige maten toch aanpassen omdat ze gekoppeld zijn aan de font-size.

Ten eerste maak je daar mee ononderhoudbare en onnodige grote CSS aan, ten tweede limiteer je jezelf in flexibiliteit; je zet de typen content die samen gegroepeerd kunnen worden in een container op zo'n manier feitelijk 'op slot'. Voor elk nieuw soort content dat je er bij wilt plaatsen moet je immers nieuwe uitzonderingen coderen om de font-size wijziging op de container voor die specifieke content ongedaan te maken.

Het bovenstaande geldt natuurlijk niet alleen voor font-size, maar in principe voor elke property die overerft wordt: color, line-height, text-align, etc.

Dat is absoluut waar, maar je neemt daarbij impliciet aan dat die altijd met elkaar in relatie staan. Dat is simpelweg niet zo.

[...]

Een font-size van 1.2em vertelt me dat een element om de een of andere reden de tekst groter maakt. Waarschijnlijk om er extra nadruk op te leggen; bijvoorbeeld omdat het een element met heading eigenschappen betreft. Het feit dat een element een font-size van 16px heeft zegt me daarentegen niets; daar moet ik eerst context bij hebben: is 20px klein, groot of normaal in verhouding tot andere elementen in de site?

Wat je zegt is op zich waar. De (voor mij aangenomen als zijnde) voordelen die pixels hebben op globale schaal heeft em op lokale schaal. In die zin is het zo dat beide zo zijn voor en nadelen hebben, afhankelijk van de context waarin je het bekijkt. Daarbij wil ik wel de kanttekening maken dat het bij het gebruiken van de absolute maateenheden over het algemeen makkelijker is om de lokale context in je achterhoofd te houden.

[...]

Niet als je dus je indeling op orde hebt en je de juiste CSS properties op de juiste elementen aanpast.

Dat is gewoon onwaar. Een element met een bepaalde ingestelde font-size kan andere maten krijgen als je em's gebruikt en deze in een andere context met een andere font-size gebruikt. Dat is niet het geval als je een absolute maateenheid gebruikt.

[...]

En dat is wat je krijgt als je in bestaande prut moet gaan roeren die niet goed opgezet is; dan mag je een uphill battle gaan voeren tegen de bestaande implementatie die elke keer om dondert.

Hoe had het geheel dan opgezet moeten worden? Het element moest gekopiëerd worden van context A naar context B, in context A was de font-size X en in context B was de font-size Y. In dat geval veranderen de maten van het element omdat de font-sizes van de context waarin het zich bevind verschillen. Hoe kun je daar dan aan ontkomen?

[...]

Alleen als je niet een net CSS raamwerk opzet en dat fout laat gaan. Als alle 'componenten' die andere componenten als inhoud kunnen accepteren zo opgezet zijn dat ze altijd gebruik maken van een zinnige basislijn, dan heb je dat probleem niet.

Het zou leuk zijn als ik altijd uit kan gaan van de ideale situatie, maar dat is in de praktijk niet zo. Ik heb het idee dat daar over het algemeen makkelijker mee om te gaan is als je de absolute maateenheden gebruikt dan wanneer je em's gebruikt.

Omgekeerd; het op de juiste wijze gebruiken van de em maat opent juist de mogelijkheid om componenten mee te laten groeien wanneer dat wel gewenst is. Voorbeeld; een icoon uit een icon-font wil ik verticaal gecentreerd en links gedocked hebben staan (bijvoorbeeld voor in een grafisch mooi uitgewerkt type knop):

Cascading Stylesheet:

.icon {
  height : 1em;
  width  : 1em;
}
.icon--docked-left {
  margin-top : .-5em;
  position : absolute;
  top : 50%;
  left : 0;
}

.icon--size-s { font-size : 12px; }
.icon--size-m { font-size : 16px; }
.icon--size-l { font-size : 24px; }
}

Als je hier niet ems zou gebruiken zou je juist voor elke individuele maat van icoon een aparte uitlijning moeten gaan schrijven. Door van die schalende factor gebruik te maken juist niet. En geef je geen expliciete maat voor een icoon op; dan neemt een icoon de bestaande tekst grootte mee over en balanceert deze zichzelf nog steeds netjes.

Mijn punt is niet om aan te tonen dat het gebruik van de relatieve maateenheden geen enkel voordeel biedt hoor. Ik heb alleen het idee dat die situaties waarin het wel handig is in de praktijk minder vaak voorkomen dan de situaties waarin dingen onnodig meeschalen en het daarom de moeite niet waard is.

[...]


Ik bedoelde eigenlijk de breedte:hoogte verhouding binnen een element. Misschien dat de term aspectratio duidelijker was geweest.

Bijvoorbeeld twee containers; één in een 3:1 verhouding en één in een 3:2 verhouding. Allebei 50% van de beschikbare breedte. Die twee containers gaan dan in de hoogte altijd onderling een 1:2 verhouding hebben. Daar komt geen em of pixel meer bij kijken; dat is intern allemaal percentage werk, wat best fijn werkt met (semi-)fluid designs.

Percentages zijn natuurlijk iets heel anders en zijn inderdaad ideaal om dergelijke verhoudingen te bepalen. Zoals je zelf wel zegt, komt daar geen px of em bij kijken dus ik vind het lastig om dit als pré van em's te zien.

Verder is je voorbeeld voor een em-ratio een gekunstelde situatie die nergens op slaat: wie gaat er nou in hemelsnaam een ratio opzetten in em maten die niet op dezelfde basis gevoet zijn? Daar hebben we een uitdrukking voor; dat is appels met peren vergelijken.

Als het gaat om de verhoudingen van het element zelf kán dat natuurlijk niet eens voorkomen. Maar als twee elementen zich op een bepaalde manier ten opzichte van elkaar moeten verhouden is het mogelijk dat het qua em's uitkomt op pak hem beet een 1:3 verhouding terwijl het in de praktijk om een 3:1 verhouding gaat.

[R4gnax]

Patriot schreef op donderdag 05 december 2013 @ 03:13:
Dat is gewoon onwaar. Een element met een bepaalde ingestelde font-size kan andere maten krijgen als je em's gebruikt en deze in een andere context met een andere font-size gebruikt. Dat is niet het geval als je een absolute maateenheid gebruikt.

[...]

Hoe had het geheel dan opgezet moeten worden? Het element moest gekopiëerd worden van context A naar context B, in context A was de font-size X en in context B was de font-size Y. In dat geval veranderen de maten van het element omdat de font-sizes van de context waarin het zich bevind verschillen. Hoe kun je daar dan aan ontkomen?

Nogmaals: door duidelijk op te delen in content containers en layout containers, waarbij je in de laatste categorie niet aan de font-size en andere properties die relatief overerfbaar zijn (zoals bijvoorbeeld line-height) tornt. Dan kun je altijd de content makkelijk verplaatsen en herrangschikken binnen de layout containers.

Een grid systeem en de daarbij horende grid kolommen zijn een mooi voorbeeld van layout containers. Een element dat een vast aspect ratio forceert zou ook een layout container kunnen zijn. En zelfs een simpele lijst die items horizontaal of verticaal rangschikt kan dat zijn.

Als je dit principe niet snapt of niet wilt toepassen, tja; dan gaan em maten inderdaad niet zo goed voor je werken, want dan krijg je inderdaad veel te snel met conflicten te maken. Het is alleen zo dat die conflicten iets zeggen over de problemen met je HTML/CSS architectuur opzet, en niet over de problemen met relatieve maten zoals em of percentages.

Verder ga ik er weinig woorden meer aan vuil maken.

[incaz]

R4gnax schreef op woensdag 04 december 2013 @ 21:46:

Daarmee vervalt dan ook gelijk dat bezwaar op extra rulesets; je kunt beter twee regels meer spenderen om een niet conflicterend iets op te bouwen dan achteraf de hele tijd allerlei te globaal opgezette selectors 'ongedaan' proberen te maken.

Het gaat natuurlijk niet om conflicterende rulesets maar om cascades. En cascading leek mij persoonlijk eigenlijk een beetje de basis van css (misschien een raar idee, maar ja, dat zat zo in mijn hoofd.)

Zelf werk ik dus zeker niet met elke context apart specificeren, waar mogelijk heb ik liever globalere selectors die ik override ('ongedaan maak'?) in een specifiekere omgeving.

Maar bovendien: zelfs als je het heel specifiek doet, heb je altijd dat je een element genest in zichzelf altijd matcht tenzij je met direct child selectors werkt.

Oftewel een .somelist li matcht ook een list-item binnen dat list-item. Wil je dat voorkomen terwijl je em's gebruikt dan moet je ofwel een extra class invoeren (wat natuurlijk geen optie is als je semantisch correcte maar kale html wilt kunnen verwerken, wat mij juist wel het uitgangspunt lijkt: zoveel mogelijk semantisch en alleen classes waar het wat toevoegt, waar je gelijkwaardige elementen van elkaar onderscheidt etc) of je moet altijd een extra inheritance-regel invoeren.

En het is, belangrijker nog, op geen enkele manier te verdedigen als zinnige manier. Het blijven doorrekenen met relatieve units is altijd een slecht idee, in elke programmeeromgeving, omdat bv afrondingsfouten zo snel doorwerken. Dus als je eerst 0,9 en daarna 1,0 nodig hebt van iets (een float ofzo) dan ga je nevernooit eerst die 0,9 berekenen en daarna weer vermenigvuldigen met 1,1111111111111111111
Dat is gewoon een manier die vraagt om problemen, en dat is binnen css niet anders dan daarbuiten.

Em's hebben best hun functie, waar je dingen daadwerkelijk wilt verbinden aan de fontgrootte daar op dat moment. Maar als enige maateenheid? Een volstrekt belachelijk idee, juist omdat het zo slecht samenwerkt met het cascading mechanisme van css, dat het zo makkelijk maakt om van globaal naar specifiek te werken.

[R4gnax]

incaz schreef op donderdag 05 december 2013 @ 19:25:
[...]


Het gaat natuurlijk niet om conflicterende rulesets maar om cascades. En cascading leek mij persoonlijk eigenlijk een beetje de basis van css (misschien een raar idee, maar ja, dat zat zo in mijn hoofd.)

Zelf werk ik dus zeker niet met elke context apart specificeren, waar mogelijk heb ik liever globalere selectors die ik override ('ongedaan maak'?) in een specifiekere omgeving.

Niks mis met de cascade om van generiek naar specifiek te gaan. Alleen andersom; van specifiek naar generiek (d.w.z. zaken 'ongedaan maken') is niet zo slim. Doordat je namelijk één regel te specifiek schrijft ga je namelijk noodgedwongen extra dependencies en interacties tussen regels aanmaken wanneer je zaken later weer 'ongedaan', c.q., generiek maakt. Dat is slecht voor onderhoud, performance en flexibiliteit.

incaz schreef op donderdag 05 december 2013 @ 19:25:
[...]

Maar bovendien: zelfs als je het heel specifiek doet, heb je altijd dat je een element genest in zichzelf altijd matcht tenzij je met direct child selectors werkt.

Wat je dus ook doet, aangezien rules met descendant combinators (die dingen heten trouwens combinators; onderdelen van selectors worden verbonden via combinators...) een flink stuk duurder zijn voor een browser om te matchen dan selectors met child combinators.

Daarnaast; zoals je zelf al aangeeft maken descendant combinators dankzij de losse koppeling die een indirect ancestor element oplevert, het uiteindelijke resultaat van de cascade van toegepaste rules een stuk onvoorspelbaarder. In de praktijk leidt dat al heel snel tot het schrijven van rules met steeds hogere specificity waarden om alles toch nog te proberen in goede banen te leiden. Dat werkt alleen averechts en maakt uiteindelijk compleet ononderhoudbare CSS die qua footprint enorm uit de band springt.

incaz schreef op donderdag 05 december 2013 @ 19:25:
Oftewel een .somelist li matcht ook een list-item binnen dat list-item. Wil je dat voorkomen terwijl je em's gebruikt dan moet je ofwel een extra class invoeren (wat natuurlijk geen optie is als je semantisch correcte maar kale html wilt kunnen verwerken, wat mij juist wel het uitgangspunt lijkt: zoveel mogelijk semantisch en alleen classes waar het wat toevoegt, waar je gelijkwaardige elementen van elkaar onderscheidt etc) of je moet altijd een extra inheritance-regel invoeren.

En dat is dus een fabeltje gebaseerd op een cargo cult voortgekomen uit "classitis" angstbeelden.

Classes hebben geen enkele semantische waarde; dus of ze er nu staan of niet maakt geen hout uit. En dankzij compressie via bijvoorbeeld GZIP maken vaak terugkomende classes in de HTML het eindresultaat ook niet noemenswaardig groter om over de lijn te sturen. (Heel veel met dezelfde poel generieke classes werken zoals voor grid indelingen, vertikale whitespace ritmes, etc. neigt de eindgrootte zelfs omlaag te drukken, juist omdat je heel veel recurring character sequences krijgt...)

Voor onderhoud en performance is het gewoon het best om je rules kort te houden met zo min mogelijk combinators en zo efficient mogelijke right-hand key selectors. Dat wil dus zeggen dat een regel als #header ul li absoluut een anti-patroon is.

Lees Our (CSS) Best Practices Are Killing US er eens op na. Jammer dat de videopresentatie ondertussen offline is, maar de slideshare slides an sich laten ook een aardig beeld zien.
[[ EDIT: Ah! Video gevonden ]]

incaz schreef op donderdag 05 december 2013 @ 19:25:
En het is, belangrijker nog, op geen enkele manier te verdedigen als zinnige manier. Het blijven doorrekenen met relatieve units is altijd een slecht idee, in elke programmeeromgeving, omdat bv afrondingsfouten zo snel doorwerken. Dus als je eerst 0,9 en daarna 1,0 nodig hebt van iets (een float ofzo) dan ga je nevernooit eerst die 0,9 berekenen en daarna weer vermenigvuldigen met 1,1111111111111111111
Dat is gewoon een manier die vraagt om problemen, en dat is binnen css niet anders dan daarbuiten.

Even daargelaten dat de accumulatie van dat soort afrondingsfouten in de regel zo klein is dat het hoogstens geneuzel in de subpixel marge op zou leveren; ik beargumenteer juist dat met een juist opgezette CSS architectuur de relatieve eenheden die je gebruikt, zo min mogelijk doorgerekend worden...

incaz schreef op donderdag 05 december 2013 @ 19:25:
Em's hebben best hun functie, waar je dingen daadwerkelijk wilt verbinden aan de fontgrootte daar op dat moment. Maar als enige maateenheid? Een volstrekt belachelijk idee, juist omdat het zo slecht samenwerkt met het cascading mechanisme van css, dat het zo makkelijk maakt om van globaal naar specifiek te werken.

Een waarheid als een koe. Ik zeg dan ook nergens dat je relatieve maten te pas en te onpas overal maar moet gebruiken. Ik zeg alleen dat het compleet idioot is om ze wholesale in te ruilen voor pixel maten met de valse belofte dat dat je code beter zou maken. (Want dat doet het namelijk niet; het is een enkeltje symptoom bestrijding.)

[incaz]

Hmm, ik heb het filmpje gekeken en ik geloof dat ik toch fundamenteel geen fan ben van oocss. Wat wel een zinnige uitspraak is: "and once it became it rule, it became something rigid that you have to do every time. And that very rarely works, in developing anything."

Dat hele em-gebeuren is volgens mij ook zo'n rule. Het is ooit bedacht met toen zinnige redenen, maar het is geevolueerd tot een soort lakmoesproef van 'zuiver in de leer zijn' - ook als er hele concrete nadelen zijn, en eigenlijk geen concrete use cases meer over zijn waarin em's een aanzienlijk voordeel hebben, toch rigide vast blijven houden aan een methode die (wat mij betreft) gewoon ook principieel nooit goed is geweest.

Em's hebben hun functie, maar ze zijn nooit geschikt als enige en uitsluitende maateenheid in webdesign.

Van het oocss ben ik geen fan, net als van het toevoegen van classes aan sommige dingen. Niet omdat ik last heb van classitis of een dwarszittende best practice, maar veel praktischer. Het betekent namelijk dat je je html moet veranderen. Dat is buitengewoon vervelend als het gaat om html die van een bron komt waar jij geen invloed hebt. Wat ik echt NIET wil is een parser gaan schrijven bovenop de bestaande om de markdown, bbcode of simple html (bv door users in een forum of de md-files van documentatie) nog eens extra te parsen om ze te voorzien van de door mij gewenste classes.

Vooral niet als dat de oplossing is voor een probleem dat je zelf creeert door een zeer kwetsbaar relatieve-unitssysteem te gebruiken, terwijl het probleem (grotendeels) is opgelost door op enkele plaatsen geen relatieve maar absolute units te gebruiken.

En dat lijkt me volkomen in lijn met de gedachte van het filmpje dat je toont: rigiditeit moet wijken voor een wat pragmatischere benadering als dat beter is.