CSS niet genoeg: steunen op HTML of JS?

[Lapa]

Je bent zo te zien een purist als het gaat om cleane HTML. Lovenswaardig. Maar je wil wel layout problemen liever oplossen met javascript dan met een extra divje, terwijl dat weer helemaal tegen de pure scheiding van verantwoordelijkheden ingaat.

Ok, een extra divje hier en daar is ook schending van de pure HTML en als je daar te ver in door schiet krijg je een rommelig en slecht onderhoudbaar resultaat. Maar als je probleem iets is dat je kan oplossen met een extra container in HTML of met een stuk javascript, dan raad ik je toch echt aan om dat op te lossen met die HTML container.

Volgens mij was je ook al wel duidelijk dat de meeste mensen hier er zo over denken, maar ben je op zoek naar de argumentatie daarvoor.
Browsers worden steeds sneller en beter en zeker ook sneller in javascript. Toch wil je het jezelf en je browser zo makkelijk mogelijk maken. Als je probleem op te lossen is door een extra container, geef je de browser één extra DOM-node om te verwerken. Iets waar browsers bijzonder goed in zijn, het is immers de core-funtionaliteit. Als je datzelfde probleem met javascript oplost, zal dat zo goed als zeker meer dan twee of drie regels javascript zijn, waarschijnlijk eerder 5 of 10 of nog veel meer. En als je zegt het is één regel in jQuery of wat je favoriete library ook is, besef dan dat er achter die regel tientallen tot honderden regels in de library zitten. Dat is allemaal werk dat je browser moet verrichten. Javascript is best snel, maar HTML + CSS is in 99,9% v.d. gevallen sneller. (edit: en grote kans dat dat javascript alsnog extra DOM-nodes toevoegt, waardoor de browser dat werk alsnog ook moet verrichten)

Dan nog blijven er soms dingen over die je met javascript moet oplossen, maar elke keer als ik dat gedaan heb, heb ik er achteraf spijt van omdat het meer kans op bugs geeft en moeilijker onderhoudbaar is dan een HTML + CSS oplossing.
Als je uit mag gaan van moderne browsers (niks onder IE9) en dus allerlei CSS3 dingen kan gebruiken kan je echt bijna alles met CSS oplossen.

Maar dit breekt zodra er elementen bijkomen/verdwijnen/verwisslen, en dat is omdat de rule mijn manier van denken (select 'non-last' element) niet kan omvatten.

Voor jouw voorbeeld, wat dacht je van:
td:not(:last-child)
Dat doet volgens mij exact wat je wil.
https://jsfiddle.net/c2tnonyu/

[Richh]

jayvol09 schreef op vrijdag 8 september 2017 @ 09:36:
Dat is miscchien een optie als ik niet 100% clientside werk.

First of all: waarom doe je dit?

Omdat jij 100% clientside werkt, moet je op zoek naar een ongebruikelijke workaround. Het is niet verkeerd om serverside een class te hangen aan een tabel-element als die een specifieke styling wenst, sterker nog, het is zeer gewenst.

Ergens zit een webserver die je HTML aanbiedt. Die moet er gewoon voor zorgen dat jij er wat mee kan Dat is naar mijn smaak de beste oplossing voor je problemen. Oftewel, steunen op HTML.

Steunen op Javascript zorgt voor extra client load, en maakt je code voor anderen vaak een stuk lastiger om aan te passen. Daarbij heeft niet iedere client Javascript. Indien niet nodig, niet gebruiken, naar mijn idee.

[jayvol09]

Update: Fiddle voor mn selector voorbeeldje. Verander de subset van elementen A die voldoen aan: eerste element van A+A patroon. Zoals eerder bevestigd kan dit niet pijnloos, maar moet er server-side wat worden getweakt om de HTML aan de rule te laten conformeren. (Of dus clientside met JS).

https://jsfiddle.net/jayvl/fhjsx9cu/2/

[ Voor 4% gewijzigd door jayvol09 op 08-09-2017 10:41 ]

[CurlyMo]

jayvol09 schreef op vrijdag 8 september 2017 @ 10:40:
Zoals eerder bevestigd kan dit niet pijnloos, maar moet er server-side wat worden getweakt om de HTML aan de rule te laten conformeren. (Of dus clientside met JS).

Dat is toch geen enkel probleem en valt ook niet onder tweaken. Het is gewoon zoals het hoort. Je zorgt er in de scripting taal voor dat je elementen logisch te identificeren zijn via classes en IDs. In je opmaak taal (CSS) zorg je voor de juiste opmaak voor die specifieke elementen. Bijvoorbeeld:

HTML:

<dl class="example">
    <dt>name</dt>
    <dd class="eerste">def</dd>
    <dt>name</dt>
    <dd class="eerste">def</dd>
    <dd class="opvolgende">def</dd>
    <dd class="opvolgende">def</dd>
</dl>

In je CSS stijl je nu alleen de dd.opvolgende elementen.

[Ed Vertijsment]

Ik denk dat je op de feiten vooruitloopt en volgens mij is dat eerder ook al aangegeven.


Gebruik CSS.

Er zijn maar weinig dingen dit met CSS niet kunnen, ook qua gedrag en responsiveness. Makkelijk is het echter ook niet altijd en daarom kan het soms nodig zijn hulp te vragen. Maar direct voor alternatieve benaderingen zoeken lijkt me niet nodig, probeer eest het initiële probleem voor te leggen.

Ik begrijp dat je er niet van houd om je HTML aan te passen om het ontwerp goed te krijgen, good thing, zoals het hoort. Schrijf CSS om je HTML te stylen, schrijf geen HTML om je CSS te stylen.. Toch komt het voor dat je hier niet aan ontkomt, maar meestal is het niet nodig.


Gebruik pseudo selectors.

Probeer je eens te verdiepen in het gebruik van :before en :after. Bijna alle elementen ondersteunen het gebruik hiervan en het geeft je 2 extra targets per node om te stylen, dit neemt dus vaak de noodzaak weg voor een extra wrapper.


Pas HTML alleen aan als het echt niet anders kan.

Als het dan niet gaat om deze manier kun je terugvallen op het gebruik maken van extra "nood" tags. Voorbeelden voor het gebruik hiervan zijn bijvoorbeeld custom checkboxes. De kun je niet/beperkt stylen en ondersteunen geen :before en :after.


Wel of niet JavaScript gebruiken.

Het upgraden van deze tags kan je met JavaScript doen, wees je dan wel bewust van de performance hit en de afhankelijkheid op JavaScript voor styling, iets wat je liever niet hebt. Het bijvoorbeeld wel logisch zijn als je de functionaliteit van een widget upgrade (bijvoorbeeld een select met zoekvak) waarvoor logica en styling is vereist. Als je dan selects "upgrade" via JS weet je zeker dat er altijd een werkende versie getoond wordt, voor het vervangen is immers JavaScript al vereist.

Over het gebruik van tabellen voor styling kunnen we kort zijn. JUST. DON'T. DO. IT.. Tabellen hebben een hele andere semantische betekenis en het gebruik hiervan kan later grote problemen geven, met name met responsiveness.

Er zijn ook nog tools waarmee je styling in een JavaScript file opschrijft. Allemaal leuk en aardig maar die worden vaak ook weer omgezet naar CSS, zo niet afblijven.


Probeer "gedrag" in CSS te begrijpen.

CSS heeft best wel wat mogelijkheden om het gedrag te bepalen. Voorbeelden zijn de constraints van flexbox (vergeet ook flex-grow, en flex-shrink niet). Zebra striping kan makkelijk met :nth-child(odd) en :nth-child() kan ook formules opnemen. Als je helemaal modern wilt zijn (en ie11 niet hoeft te supporten) kan CSS grid ook nog interessant zijn.

CSS heeft naast dit alles ook nog support voor transities en keyframe animaties. Nogmaals, zelden is JavaScript nodig voor gedrag.


Overig.

Los van dit alles hem ik wat persoonlijke best practices, hoef je het niet mee eens te zijn maar kan wellicht helpen.

• Bouw alles als component.
• Bouw een template die componenten stapelt.
• Laat componenten niet buiten hun "scope" (border box), dus geen margins op de buitenste tags.
• Laat de template marges zetten en componenten uitlijnen
• Selecteer zoveel mogelijk op class name, het noodzakelijk gebruik van (+, >, :before, :after, nth-child()) kan wel.
• Selecteer NIET op tags, tags wilen nog wel eens wijzigen en breken dan de layout.
• Selecteer NIET op id, id's mogen maar een keer voorkomen, dit breekt modulariteit.
• Volg een methodiek: Atomic Design, BEM, OOCSS, SMACSS o.i.d.

[jayvol09]

CurlyMo schreef op vrijdag 8 september 2017 @ 10:48:
[...]

Dat is toch geen enkel probleem en valt ook niet onder tweaken. Het is gewoon zoals het hoort. Je zorgt er in de scripting taal voor dat je elementen logisch te identificeren zijn via classes en IDs. In je opmaak taal (CSS) zorg je voor de juiste opmaak voor die specifieke elementen. Bijvoorbeeld:

HTML:

<dl class="example">
    <dt>name</dt>
    <dd class="eerste">def</dd>
    <dt>name</dt>
    <dd class="eerste">def</dd>
    <dd class="opvolgende">def</dd>
    <dd class="opvolgende">def</dd>
</dl>

In je CSS stijl je nu alleen de dd.opvolgende elementen.

Ik heb nooit beweerd dat ik het niet kon stijlen op die manier. (zo doe ik het ook) . Alleen het is pijnlijk zonder backend templates of JS (in stap 2 van voorbeeld). Ik beweerde dat ik niet op een bepaalde manier kon selecteren. Als ik meer uitdrukkingskracht had dan waren die html 'class-shifting' templates niet nodig. Het kost me 1 regel code in jQuery VS een HTML preprocessor installeren en na elke HTML edit recompileren.

Excuus voor de invalide html. Ik haalde m'n d's en t's door elkaar.

[Verwijderd]

Je kunt ook <ul> tags gebruiken om de 'def's te groeperen en zo middels CSS eenvoudig een komma achter iedere <li> zetten, behalve de laatste.

Tevens, "Example" uit je fiddle hoort niet in de <dl> thuis.


https://jsfiddle.net/afo5myL6/

[ Voor 47% gewijzigd door Verwijderd op 08-09-2017 11:22 ]

[CurlyMo]

jayvol09 schreef op vrijdag 8 september 2017 @ 11:11:
[...]

De kern is dat je het ziet als tweaken terwijl ik dit gewoon regulier programmeren vind

[Ramon]

jayvol09 schreef op vrijdag 8 september 2017 @ 09:36:
[...]

Wat is voor jou dan een reden?

Dat is lastig te zeggen en hangt er vanaf wat je maakt en wat je voor elkaar wilt krijgen. Voor de simpele sites die ik heb gemaakt is html en css voor 99% genoeg en wordt JavaScript alleen gebruikt om interactiviteit toe te voegen. Aan de andere kant heb ik ook gewerkt aan enorm grote webapplicaties waar het gebruik van web components mbv bijvoorbeeld React of Riotjs een geschenk uit de hemel is.

[...]

Ja--als je dat weet. Stel je hebt 10 random images in een flexbox <figure>, hoeveel passen er op de eerste rij? Alles tussen 1 en 10 is mogelijk afhankelijk van scherm en content. Dus waar begint de nieuwe flex container? (en extra containers is weer html bloat).

Je had het over N, dat betekent voor mij dat je weet hoeveel je er wilt.

Het punt is dat er dingen zijn die gewoon niet kunnen in CSS (2017) zonder een 'kruk'. Als jij een guru bent die mijn voorbeeld kan oplossen, great! maar dat betekent alleen dat ik een beter voorbeeld had moeten bedenken.

Absoluut zijn er dingen die niet kunnen in CSS, zeker als je wat oudere browsers moet ondersteunen loop je vaak tegen grenzen aan. Ik ben geen guru maar heb wel al 23 jaar ervaring in het vak waarvan 12 jaar professioneel, en heb gewerkt aan sites waar 100.000 bezoekers per maand komen.

[...]

Mee eens!


[...]

Begrijp ik het verkeerd of zeg je dat abstractie niet nodig is? Ik ben benieuwd naar je reden. Ik geloof dat het mogelijk is om in JS sterkere abstracties te maken dan wat nu mogelijk is in SASS/SCSS, en die hebben al aardig bestaansrecht.

Hangt er wederom vanaf wat je wilt maken. Iets als CSS Modules React kan handig zijn om je code te scopen als je heel veel (css) code hebt die anders niet los van elkaar te houden is bijvoorbeeld.

[...]

Wat is niet waar? Ik denk dat er communicatiefout ergens is. Dynamisch kan veel dingen beteken merk ik. Ik gebruik classes. Het nare is dat in mijn voorbeeld ik moet 'reclassen' als ik de HTML list verander. Ik weet niet zo goed hoe ik het anders moet zeggen. Ik zal wel een fiddeltje posten.

Je stelde dat classes en id's mogelijk zijn als je een statische site hebt. In mijn boek is een statische site er eentje zonder server-side taal erachter en een dynamische er eentje mét server-side taal erachter.

En het is "reclassen" waar je het over hebt, dat is toch niet meer dan normaal. Als je een element hebt met class "price", en deze verandert van locatie (ook met JS), dan verandert die class ook mee, en dat kan je dan prima met JavaScript doen natuurlijk. Dat is de interactiviteit waar ik hierboven over spreek.

[...]

Dit is dus waar ik naar benieuwd ben! waarom vind je dat niet logisch. Ik vind een extra div veel afstotender dan een script, met oogpunt op de 'holy trinity'. Helemaal als css + js fixes naast elkaar leven in de code.

Omdat JavaScript veel langzamer is dan CSS of HTML. Dus wat je in HTML of CSS kan oplossen, los je daar in op, lukt dat niet, door bijvoorbeeld het willen supporten van oudere browsers of bepaalde on-the-fly berekeningen die je moet doen om je elementen goed te positioneren, dan gebruik je JavaScript.

[...]

Dat is miscchien een optie als ik niet 100% clientside werk.


[...]

Ik vond m'n 2 voorbeelden aardig concreet, jammer dat ik niet in hier direct code kan posten?


Ter verduidelijking: ik probeer juist zoveel mogelijk CSS te gebruiken, ik zou graag met rules alle grafische aspecten van een website manipuleren. Maar ik ben een control-junkie, en merk dat ik niet genoeg uitdrukkingsvermogen heb met de CSS layout systeem (ongeacht preprocessor taal). Dit is niet door een gebrek aan kennis: het is een algemeen bekende feit dat CSS geen perfecte layout model heeft en dat cascading rules daar bovenop nog beperkingen opleggen aan de taal.

In het voorbeeld in je fiddle kan je ook je html logischer opbouwen. Als ik het zo zie lijkt het een lijst van producten met prijzen. Het is vrij logisch om de prijzen een class "price" bijvoorbeeld mee te geven zodat je daar op kan stijlen. Als dan de volgorde van deze elementen met JavaScript veranderd dan blijft de styling toch intact?

Ik nam aan dat niemand dit betwist maar dat kan ook een leerzame discussie opleveren. Ik wist na dag 1 dat de holy trinity in theorie gescheiden moet blijven om efficient te werken (schaling, onderhoud, bot-vriendelijkheid), maar de realiteit is dat dit niet altijd kan.

Die holy trinity bestaat niet meer. Verdiep je maar eens in CSS Modules.

Tot dusver heb ik weinig gehoord over de titel: steunen op extra elementen of een scriptje toevoegen, wanneer doen jullie wat, en is dat traditie of zit daar een bewuste redenering achter.

Daar is geen antwoord op te geven want het verschilt per situatie. Bouw je een hyper-interactieve webapplicatie dan zal je sneller naar JavaScript grijpen dan als je een weblog bouwt.

[Verwijderd]

jayvol09 schreef op vrijdag 8 september 2017 @ 09:36:
Tot dusver heb ik weinig gehoord over de titel: steunen op extra elementen of een scriptje toevoegen, wanneer doen jullie wat, en is dat traditie of zit daar een bewuste redenering achter.

Bij deze: styling gebeurt middels CSS, dus classes, id's of extra elementen toevoegen waar nodig. De reden: je gaat geen hamer gebruiken om een schroef vast te draaien.

[Harrie_]

Ik heb dit hele topic gevolgd maar ik begrijp echt het probleem niet.
Wat ik eruit opmaak wil TS bijvoorbeeld het één na laatste element stylen, maar hij weet vooraf niet hoeveel elementen er gaan verschijnen. Misschien ben ik nu maar als je door je data heen loopt dan geef je toch gewoon het één na laatste element class="eennalaatste" mee, vervolgens die definen in je CSS en je probleem is toch opgelost?

[ Voor 4% gewijzigd door Harrie_ op 08-09-2017 12:28 ]

[Verwijderd]

"Een enkel goed argument dat ik gehoord heb is dat JS nog te langzaam is op mobile. Maar ja, 5G komt eraan en nu heeft chrome JS modules (caching enzo). Ben benieuwd naar jullie denkprocess."

5G maakt JS niet sneller. Caching ook niet. De traagheid van JS zit hem niet in het laden, het gaat bij mobile met name om de tijd om de JS te parsen/evalueren. Op een crappy low-end Android kan dat voor een grote lib oplopen tot enkele secondes omdat de CPU zo low powered is. Tevens zorgt renderen via JS voor repaints in de browser, wat ook geen goede performance aanpak is.

Ik ben ook voorstander van schone HTML maar je slaat hierin door. Classes en IDs hebben geen enkele semantische waarde voor de browser of een zoekmachine, je bent vrij om daar in te proppen wat je wil. Het is volstrekt normaal om in je HTML classes te hangen die dienen als styling hooks, daar zijn ze voor bedoeld.

[Tjolk]

Ach, schone HTML is wel supercool natuurlijk. Gewoon alles in de CSS pleuren. Geen JS nodig ook.
https://jsfiddle.net/zspwaqv1/3/

spoiler:

./vrijdag

[mcDavid]

jayvol09 schreef op vrijdag 8 september 2017 @ 11:11:
[...]

Het kost me 1 regel code in jQuery VS een HTML preprocessor installeren en na elke HTML edit recompileren.

Kun je iets meer vertellen over de toepassing dan?

Want ofwel je HTML wordt dynamisch gegenereerd en je hebt toch al een template engine of iets dergelijks, ofwel je HTML is statisch/hardcoded en je hebt er überhaupt volledige controle over.

[williammorren]

jayvol09 schreef op vrijdag 8 september 2017 @ 04:58:
Vrij zeker. Die dingen ken ik, maar geven geen 100% oplossing. Ik asserteer: voor een gegeven DOM is soms niet mogelijk een specifieke subset van elementen te selecteren zonder een class/ID. Voorbeeld:
Selecter elementen "A", maar alleen diegene die gevolgd worden door nog element A.

<dl>
<tt>name</tt>
<td>def</td>
<tt>name</tt>
*<td>def</td>
*<td>def</td>
<td>def</td>
<tt>name</tt>
<td>def</td>
<tt>name</tt>
*<td>def</td>
<td>def</td>
<tt>name</tt>
<tt>name</tt>
<td>def</td>
<tt>name</tt>
<td>def</td>
</dl>
Dus alles met een asterisk selecteren in bovenstaande lijst. Lukt me niet zonder een class/ID. Ik zeg niet dat CSS weinig kan selecteren, maar als je nu toch JS moet gebruiken, waarom niet alle styling meteen op een hoger niveau van abstractie doen?

Met een div element (wat valide is) opgelost

https://jsfiddle.net/h0uucdy0/

[Verwijderd]

williammorren schreef op vrijdag 8 september 2017 @ 14:40:
[...]Met een div element (wat valide is) opgelost

div in een dl mag niet... wel, denk ik.

[ Voor 5% gewijzigd door Verwijderd op 08-09-2017 18:34 ]

[jayvol09]

williammorren schreef op vrijdag 8 september 2017 @ 14:40:
[...]


Met een div element (wat valide is) opgelost

https://jsfiddle.net/h0uucdy0/

Je mis helaas de crux v/d draad. Ik had zelfs een regel in de fiddle: je mag alleen classes (=CSS) in de HTML gebruiken. Je div is er *puur* voor de styling, mag wel 'valide' zijn, maar is incorrect gebruik van HTML. Maargoed je bent dus een HTML kruk type, ook al doe je het misschien onbewust

Mijn voorbeeld was niet "iets dat onmogelijk is", maar ik wou een illustratie geven van "iets dat niet met puur CSS kan". Classes komen het dichtst bij een elegante oplossing, maar reclassen als de lijst veranderd betekent 1) veel onderhoud, of 2) templates, of 3) JS. Niet echt elegant, en ik kan waarschijnlijk betere voorbeelden vinden waar reclassen geen oplossing biedt. Er zijn hele lijsten op het internet met 'mistakes in CSS standard', dus ondanks mijn dubieuze voorbeelden is de onderliggende stelling moeilijk te betwisten.

Ik waardeer de interesse in deze discussie en hoop dat mensen zich niet teveel doodstaren op de voorbeelden, maar kritisch reflecteren op de meer abstracte/algemene veronderstellingen dat men niet alles daadwerkelijk gescheiden kan houden en dat er vaak een keuze is tussen 2 kwaden.

mcDavid schreef op vrijdag 8 september 2017 @ 13:22:
[...]

Kun je iets meer vertellen over de toepassing dan?

Want ofwel je HTML wordt dynamisch gegenereerd en je hebt toch al een template engine of iets dergelijks, ofwel je HTML is statisch/hardcoded en je hebt er überhaupt volledige controle over.

In mijn geval ben ik nog handmatig HTML editten. Dit project heeft geen server-side scripts. Maar ik probeer het express abstract te houden.

Ger schreef op vrijdag 8 september 2017 @ 13:10:
Ach, schone HTML is wel supercool natuurlijk. Gewoon alles in de CSS pleuren. Geen JS nodig ook.
https://jsfiddle.net/zspwaqv1/3/

spoiler:

./vrijdag

Hmm... schoon is niet hetzelfde als super minimalistisch. Schoon is alleen elementen hebben die de content beschrijven.

Harrie_ schreef op vrijdag 8 september 2017 @ 12:27:
Ik heb dit hele topic gevolgd maar ik begrijp echt het probleem niet.
Wat ik eruit opmaak wil TS bijvoorbeeld het één na laatste element stylen, maar hij weet vooraf niet hoeveel elementen er gaan verschijnen. Misschien ben ik nu maar als je door je data heen loopt dan geef je toch gewoon het één na laatste element class="eennalaatste" mee, vervolgens die definen in je CSS en je probleem is toch opgelost?

Er is ook geen probleem. Oplossingen voor mijn voorbeelden interesseren me ook niet zo (wel een beetje, maar het zijn illustraties, oplossen betekent niet dat het achterliggende idee incorrect was). Ik wil op het moment niets stylen maar een discussie hebben waar mensen nadenken over hoe ze dingen gescheiden houden en welke oplossingen ze gebruiken als dit niet meer lukt. Dat "loopen" wat je noemt kan met JS? Dan gebruik je dus niet puur CSS meer voor stylen? Of begrijp ik je suggestie verkeerd?

Verwijderd schreef op vrijdag 8 september 2017 @ 11:56:
[...]

Bij deze: styling gebeurt middels CSS, dus classes, id's of extra elementen toevoegen waar nodig. De reden: je gaat geen hamer gebruiken om een schroef vast te draaien.

Styling gebeurt dus middels CSS en HTML bij jou, tenzij je pseudo-elementen bedoelde.

[Ramon]

williammorren schreef op vrijdag 8 september 2017 @ 14:40:
[...]


Met een div element (wat valide is) opgelost

https://jsfiddle.net/h0uucdy0/

Om even de knuppel in het hoenderhok te gooien: Dat werkt inderdaad, maar is nou niet echt begrijpelijk. Als jij over een half jaar:

code:

dd:first-of-type:not(:only-of-type),
dd + dd:not(:last-of-type) {
  color: red;
}

In een lomp stuk CSS ziet staan van een grote site, weet jij dan nog wat er bedoelt wordt?

Ik zou het zelf alsvolgt oplossen: https://jsfiddle.net/mu22kyvd/1/

jayvol09 schreef op vrijdag 8 september 2017 @ 18:49:
[...]

Je mis helaas de crux v/d draad. Ik had zelfs een regel in de fiddle: je mag alleen classes (=CSS) in de HTML gebruiken. Je div is er *puur* voor de styling, mag wel 'valide' zijn, maar is incorrect gebruik van HTML. Maargoed je bent dus een HTML kruk type, ook al doe je het misschien onbewust

Alleen is er tijdens de praktijk niet zo'n regel "je mag alleen classes gebruiken". Er is ook geen regel dat elementen niet puur mogen worden toegevoegd om bepaalde styling mogelijk te maken. Use the best tool for the job. Klanten hebben vaak beperkt budget dus er is weinig tijd, een div hier en een class daar om de styling voor elkaar te krijgen is absoluut niets mis mee. En om dan iemand een "html kruk type" te noemen vind ik alleen maar arrogant overkomen.

Mijn voorbeeld was niet "iets dat onmogelijk is", maar ik wou een illustratie geven van "iets dat niet met puur CSS kan". Classes komen het dichtst bij een elegante oplossing, maar reclassen als de lijst veranderd betekent 1) veel onderhoud, of 2) templates, of 3) JS. Niet echt elegant, en ik kan waarschijnlijk betere voorbeelden vinden waar reclassen geen oplossing biedt. Er zijn hele lijsten op het internet met 'mistakes in CSS standard', dus ondanks mijn dubieuze voorbeelden is de onderliggende stelling moeilijk te betwisten.

Jij bent de enige hier die in de overtuiging is dat dingen "puur met CSS moeten kunnen", de rest geeft eigenlijk gewoon aan pragmatisch om te gaan met zulke issues. Webdevelopment gaat, naast schone code, mijns insziens vooral over onderhoudbaarheid. Als je een stukje code schrijft waar je een half jaar later niets meer van snapt, laat staan je collega's, dan heb je het niet goed gedaan.

Ik waardeer de interesse in deze discussie en hoop dat mensen zich niet teveel doodstaren op de voorbeelden, maar kritisch reflecteren op de meer abstracte/algemene veronderstellingen dat men niet alles daadwerkelijk gescheiden kan houden en dat er vaak een keuze is tussen 2 kwaden.

Voor de meeste mensen is dit niets nieuws hoor. Bij het starten van een project denk je na over hoe je dingen gaat aanpakken op basis van de requirements die je hebt ontvangen. Welke techniek je gaat gebruiken, hoe je dingen gaat indelen zijn allemaal dingen waar je van te voren over nadenkt. Het is niet alsof jij hier nu iets compleet onbekends aan komt dragen

[...]

In mijn geval ben ik nog handmatig HTML editten. Dit project heeft geen server-side scripts. Maar ik probeer het express abstract te houden.

In dat geval kom je toch al gauw uit bij client-side templates voor loops e.d. En ook daar is absoluut niets mis mee. Sommige mensen zweren daarbij (soms ook onterecht). Wederom, hangt van het project af.

[...]

Hmm... schoon is niet hetzelfde als super minimalistisch. Schoon is alleen elementen hebben die de content beschrijven.

Ik ben even benieuwd welke jij zou prefereren en waarom:

https://jsfiddle.net/4z22y0cs/2/

of

https://jsfiddle.net/oa162wnk/2/

[Verwijderd]

jayvol09 schreef op vrijdag 8 september 2017 @ 18:49:
Styling gebeurt dus middels CSS en HTML bij jou, tenzij je pseudo-elementen bedoelde.

Da's toch ook HTML en CSS? En ja.

jayvol09 schreef op vrijdag 8 september 2017 @ 18:49:
...maar is incorrect gebruik van HTML. Maargoed je bent dus een HTML kruk type, ook al doe je het misschien onbewust

Oh, is dat je insteek? Zoek het maar uit dan met je geneuzel...

[ Voor 39% gewijzigd door Verwijderd op 08-09-2017 19:38 ]

[lemnis]

In de ideale wereld zou alle logica geschreven zijn in javascript, alle styling in CSS en alle structuur in HTML. Maar zoals je zelfs ook al heb gemerkt hebt bestaat die wereld niet. Je zult altijd met een taal de tekortkomingen van een andere taal moeten opvangen.

CSS is naar mijn mening juist te uitgebreid, je kunt tegenwoordig hele logica's en markup schrijven binnen CSS. Bijvoorbeeld je kan logica's laten uitrekenen met `calc()` of een ordered list met CSS counters creeeren. Zou je deze functies niet mogen gebruiken, omdat ze volgens je eigen mening er niet thuis horen? Voor mij is het een pure afweging van de pro's en con's. Ik gebruik `calc()` regelmatig omdat het ook werkt als JS is uitgeschakeld, al vindt ik dat het eigenlijk daar thuis zou moeten horen.

Maar daar tegenover mis ik soms de mogelijkheid om gedeeltes van animaties te kunnen pauzeren in CSS. Wil ik dan teveel logica in CSS kwijt en moet het ik dat dus ook niet willen, misschien. Iedereen heeft misschien wensen die in de strijd gaan met z'n of haar mening.

Interessante voorbeelden wat css wel allemaal wel niet kan, zijn de presentaties van Lea Verou. Misschien tegenwoordig verouderd, maar nog steeds interessant. Hier zitten ook voorbeelden bij die naar mijn mening beter thuis horen in JS, maar die wel mogelijk zijn.

• http://lea.verou.me/css3-secrets/#intro
• http://lea.verou.me/more-css-secrets/#intro

Ikzelf heb tegenwoordig nooit meer problemenen dat ik veel in JS moet schrijven om styling op te lossen. Een modifier toevoegen of verwijderen aan het element waarvan de staat is gewijzigd is meestal alles wat nodig is om CSS de rest te laten doen. Vroeger moest ik misschien meer JS schrijven, maar gelukkig leer je met de jaren. (+ nieuwe mogelijkheden binnen CSS natuurlijk)

Ik zou graag van je andere voorbeelden willen zien waar je tegen aan loopt, zodat we beter kunnen uitleggen waarom je dat wel of niet zou moeten willen. Al begrijp ik wel dat dat moeilijk is.

[gitaarwerk]

Ik snap het probleem niet, evenals de discussie. jS kan vest een enhancement doen met styling, maar zou nooit noodzakelijk moeten zijn. Als je praat over websites zou ik niet zomaar grijpen naar react/jsx. Met CSS kun je enorm veel doen. Ik zou uberhaupt niet teveel moeite doen om alles helemaal te scheiden. Blujven eeuwenoude discussies. Zonder html geen css, zonder css weinig styling. Ze hebben elkaar nodig. Er zijn wel best practises in deze tijdgeest die iets beter maken of niet. Scss is een mooie tool, maar je moet niet teveel willen laten doen anders schrijf je ononderhoudbare code. Te stricte scheiden helpt je niet, en door allerlei loopholes te gaan maak je het jezelf en een gebruiker niet beter op. Soms kun je beetje heter een tikkeltje ranzigheid hebben, dan een ultieme sceiding en magische JS die je nu zelf begrijpt, maar volgende maand snapt niemand meer.

Bosmonster en ik werken samen aan sites met 300k+ bezoekers per dag, en het enige wat we willen is het simpeler en duidelijker maken. React doen we ook, maar niet voor de website ;-)

Gebruik de tool waarvoor hij het beste is, en houd in gedachten: je performance van rendering, netwerk, usability, snelheid van development, testbaarheid, backwards compatibility, seo, qmaintainability browser support. Alles ultiem goed en perfect? success :-) morgen is er al een nieuw framework die alles beter doet :-P

Verder sluit ik me aan bij lemnis )

[mcDavid]

jayvol09 schreef op vrijdag 8 september 2017 @ 18:49:
[...]

Je mis helaas de crux v/d draad. Ik had zelfs een regel in de fiddle: je mag alleen classes (=CSS) in de HTML gebruiken. Je div is er *puur* voor de styling, mag wel 'valide' zijn, maar is incorrect gebruik van HTML. Maargoed je bent dus een HTML kruk type, ook al doe je het misschien onbewust


[...]

In mijn geval ben ik nog handmatig HTML editten. Dit project heeft geen server-side scripts. Maar ik probeer het express abstract te houden.

Als ik jou was zou ik toch maar wat pragmatischer worden hierin. Het idee dat HTML puur een datastructuur moet zijn is al lang achterhaald. Het is een goed idee om zoveel mogelijk semantiek toe te passen, en de structuur een beetje overzichtelijk te houden, maar een divje meer of minder ligt écht niemand wakker van. Zeker als het alternatief is dat je moeilijke kunstgrepen moet gaan doen met css-selectors of zelfs JavaScript. Daar wordt je pagina zéker niet sneller van en ook niet beter toegankelijk. Als je zo'n situatie kunt vermijden door een doodsimpel elementje of een extra classname her en der toe te voegen, zou ik dat zeker niet laten.

Sowieso rendert je CSS een stuk sneller als je ieder element gewoon met één classname selecteert. Styling op nested tags is traag. Zeker als je ook nog ingewikkelde psuedo classes gaat gebruiken. Google maar eens op de BEM methode bijvoorbeeld.

[ Voor 15% gewijzigd door mcDavid op 09-09-2017 09:32 ]

[b2vjfvj75gjx7]

Ger schreef op vrijdag 8 september 2017 @ 13:10:
Ach, schone HTML is wel supercool natuurlijk. Gewoon alles in de CSS pleuren. Geen JS nodig ook.
https://jsfiddle.net/zspwaqv1/3/

spoiler:

./vrijdag

Schone HTML = Schone HTML

https://jsfiddle.net/uqo8uose/

Die twee DIV'jes van jou zijn verwerpelijk en abject - omdat het niet bijdraagt aan de schoonheid van de HTML.

- edit - Bij nader inzien; afbeeldingen zijn ook not-done, tegenwoordig.

https://jsfiddle.net/uqo8uose/1/

Hop, gewoon even Base64-encoden die Henk.

We willen schone code, geen zut.

[ Voor 17% gewijzigd door b2vjfvj75gjx7 op 09-09-2017 11:30 ]

[Harrie_]

Harrie_ schreef op vrijdag 8 september 2017 @ 12:27:
Ik heb dit hele topic gevolgd maar ik begrijp echt het probleem niet.
Wat ik eruit opmaak wil TS bijvoorbeeld het één na laatste element stylen, maar hij weet vooraf niet hoeveel elementen er gaan verschijnen. Misschien ben ik nu maar als je door je data heen loopt dan geef je toch gewoon het één na laatste element class="eennalaatste" mee [...]

jayvol09 schreef op vrijdag 8 september 2017 @ 18:49:
[...]
Er is ook geen probleem. Oplossingen voor mijn voorbeelden interesseren me ook niet zo (wel een beetje, maar het zijn illustraties, oplossen betekent niet dat het achterliggende idee incorrect was). Ik wil op het moment niets stylen maar een discussie hebben waar mensen nadenken over hoe ze dingen gescheiden houden en welke oplossingen ze gebruiken als dit niet meer lukt. Dat "loopen" wat je noemt kan met JS? Dan gebruik je dus niet puur CSS meer voor stylen? Of begrijp ik je suggestie verkeerd?
[...]

Ik wilde eigenlijk openen met "mijn mond valt hier letterlijk van open", maar ik doe toch maar deze:

In je OP geef je het volgende aan:
• Je bent "relatief nieuw in de webwereld" en je hebt "een-en-ander geleerd"
• Een aantal voorbeelden van zaken waar je tegenaanloopt, voorafgaand aan "Onmogelijk om"
• Je bent van plan bent om CSS achterwege te laten en alles met JS op te lossen
• 5G komt eraan dus de traagheid van JS valt reuze mee? (alsof de snelheid van je verbinding enig invloed heeft op clientside code)

Vervolgens vraag je naar de mensen hier om hun "denkproces". Iedereen probeert uit te leggen dat je conclusies niet helemaal kloppen. Dat je de zaken waarvan jij denkt dat ze niet met CSS op te lossen zijn wèl prima op te lossen zijn. Er worden voorbeelden gegeven en proof-of-concepts van allerlei wazige vragen die je stelt over hoe je dan styling toe zou moeten passen op het een-na-laatste item in de 3e kolom van een table binnen 2 divs en weet ik wat allemaal?

En dan stel jij

"Oplossingen voor mijn voorbeelden interesseren me ook niet zo (wel een beetje, maar het zijn illustraties, oplossen betekent niet dat het achterliggende idee incorrect was)"

Vervolgens nog gekke dingen naar @Verwijderd lopen roepen...
Ik vind dit hoogst onbeschoft naar iedereen hier die je probeert te helpen en die oplossingen voor je vreemde problemen aandraagt. Jij bent degene die er telkens dingen bij gaat verzinnen. Iedereen probeert je hier uit te leggen hoe het werkt, maar jij hebt een ander idee bij hoe het zou moeten werken en dan noem je mijn oplossing ook nog een 'suggestie'?

Er zijn altijd 1001 manieren om zaken op te lossen, maar iedereen hier is het er wel overeens dat je zaken gebruikt waarvoor ze bedoeld zijn. Dat betekent dat je je styling dus gewoon doet met CSS.

• Opmaak = HTML + CSS

Te maken met dynamiek?
• Als je te maken hebt met clientside dynamiek zoals popups, imagesliders, drag 'n drop, etc. dan wordt er al JS uitgevoerd. Je geeft dan vanuit JS classes + id's mee die in je CSS staan beschreven.
• Als je te maken hebt met serverside dynamiek zoals veranderende data en verschillende interpretatie van data dan heb wordt er al serverside code uitgevoerd. Welke taal dat ook moge zijn, die geeft aan de HTML output de classes + id's mee die in je CSS staan beschreven.
• Een combinatie van bovenstaande twee

Er zijn genoeg reacties in dit topic van mensen die uitleggen hoe het wel werkt. Maar jij weet het beter...
Gan dan gewoon je eigen JS framework bouwen om alles te stylen zonder dat er ook maar één regel CSS aan te past komt. Als je over een jaar aanpassingen wilt verrichten aan je CSS-loze code en je komt er niet uit, hoef je in ieder geval niet hier te komen vragen om hulp...

[jayvol09]

Ramon schreef op vrijdag 8 september 2017 @ 19:34:
[...]
Klanten hebben vaak beperkt budget dus er is weinig tijd, een div hier en een class daar om de styling voor elkaar te krijgen is absoluut niets mis mee. En om dan iemand een "html kruk type" te noemen vind ik alleen maar arrogant overkomen.

Als ik en een vriend naar een bar gaan, en ik zie dat zijn oog vooral op brunettes valt, is het arrogant om hem in een een brunette-type te noemen? Ik snap niet hoe een humoristische 'html kruk type' in de context van deze draad (waarin ik aangeef dat iedereen weleens naar een 'kruk' moet grijpen) zo bij mensen het verkeerde keelgat inschiet. Wat mij ook interesseert is dat mensen wellicht soms onbewust stylen met HTML.

Ik snap dat mensen dezelfde post met een andere toon kunnen lezen, en dat dit in grote mate bepaalt hoe het geïnterpreteerd wordt, maar mijn 'toon' is nooit anders dan nieuwsgierig of enthousiast geweest. Ik hoop dat dit de lucht een beetje klaart.

[...]
Jij bent de enige hier die in de overtuiging is dat dingen "puur met CSS moeten kunnen", de rest geeft eigenlijk gewoon aan pragmatisch om te gaan met zulke issues. Webdevelopment gaat, naast schone code, mijns insziens vooral over onderhoudbaarheid. Als je een stukje code schrijft waar je een half jaar later niets meer van snapt, laat staan je collega's, dan heb je het niet goed gedaan.

Volgens mij zijn we het eens hoor. Kijk eens naar de titel, ik ben zeker niet overtuigd dat dingen met puur CSS moeten , hoewel ik droom van de dag dat het wel kan . Ik was al overtuigd van de pragmatische denkwijze, maar door mijn langere ervaring met script talen ben ik geneigd om scripten als meer pragmatisch te zien. Er zijn een veel goeie reacties geweest waardoor ik nu meer begrip heb voor pragmatische HTML oplossingen. Maar ik ging er niet a priori vanuit dat mijn voorkeur objectief beter was!

[...]
Voor de meeste mensen is dit niets nieuws hoor. Bij het starten van een project denk je na over hoe je dingen gaat aanpakken op basis van de requirements die je hebt ontvangen. Welke techniek je gaat gebruiken, hoe je dingen gaat indelen zijn allemaal dingen waar je van te voren over nadenkt. Het is niet alsof jij hier nu iets compleet onbekends aan komt dragen

Mee eens, maar voor mij is de discussie nog nieuw . Mensen die lang in web dev werken zijn misschien gewend aan dingen die mensen beginnend in 2017 anders zien. Ik denk dat dit onderwerp regelmatig aan bod zal komen gezien hoe snel de web techniek ontwikkelt.

Ik ben even benieuwd welke jij zou prefereren en waarom:

https://jsfiddle.net/4z22y0cs/2/

of

https://jsfiddle.net/oa162wnk/2/

De tweede (met classes), omdat ik niet voorzie dat reclassen nodig zal zijn als ik de HTML content verander. De rules zijn robuuster t.o.v. hardcoded DOM posities (nth-child of +>~ operators).

Harrie_ schreef op zondag 10 september 2017 @ 00:01:
In je OP geef je het volgende aan:
• Je bent "relatief nieuw in de webwereld" en je hebt "een-en-ander geleerd"
• Een aantal voorbeelden van zaken waar je tegenaanloopt, voorafgaand aan "Onmogelijk om"
• Je bent van plan bent om CSS achterwege te laten en alles met JS op te lossen (Nope, nuanceer.)
• 5G komt eraan dus de traagheid van JS valt reuze mee? (alsof de snelheid van je verbinding enig invloed heeft op clientside code) (mijn aanname was dat libraries merkbaar groot zijn)

Comments in quote.

Iedereen probeert uit te leggen dat je conclusiespremissen niet helemaal kloppen. Dat je de zaken waarvan jij denkt dat ze niet met CSS op te lossen zijn wèl prima op te lossen zijn.

Mijn OP nam aan dat er dingen zijn die puur CSS niet kan oplossen. Noem a.u.b. 1 persoon in deze draad die het tegendeel beweert? Excuus: mijn voorbeeld was niet echt goed, en dat heeft misschien voor wat verwarring gezorgd. Ik probeerde (tevergeefs blijkt) nadruk op de achterliggende gedachte te leggen.

En dan stel jij

[TLDR: voorbeeld oplossingen zijn niet erg relevant voor de discussie]

Vervolgens nog gekke dingen naar @Verwijderd lopen roepen...
Ik vind dit hoogst onbeschoft naar iedereen hier die je probeert te helpen en die oplossingen voor je vreemde problemen aandraagt.

Bij het maken van een topic is er een optie: vraag of discussie. Ik clickte volgens mij op discussie. Ik waardeer de hulpzame stelling van sommige mensen (inclusief jou) zeker, maar ik wil niet dat mensen moeite doen voor niets, dat lijkt me het tegenovergestelde van onbeschoft!

En ik heb geen idee wat voor 'geks' ik heb geroepen richting Zaph. Volgens mij stikte hij ook in m'n keuze van het woord 'kruk' . Nogmaals: ik accepteer en hou (soms) van styling krukken! Ze bestaan. Men ontkomt er niet aan.

Iedereen probeert je hier uit te leggen hoe het werkt, maar jij hebt een ander idee bij hoe het zou moeten werken en dan noem je mijn oplossing ook nog een 'suggestie'?

Hmmm, nee iedereen draagt bij aan de discussie. Ik lees de meningen aandachtig, en sta nu meer open voor bepaalde dingen. Ik probeer geen stelling te verdedigen ofzo, tekst op internet kan helaas niet mijn stem overbrengen.

Wat is er mis met het woord "suggestie"?! Je kan ook te grote tenen hebben...

Er zijn altijd 1001 manieren om zaken op te lossen, maar iedereen hier is het er wel overeens dat je zaken gebruikt waarvoor ze bedoeld zijn. Dat betekent dat je je styling dus gewoon doet met CSS.

Mee eens, totdat CSS niet genoeg is. Gegegeven 1001 opties, welke zijn het populairst/best practice. Ik heb nu meer inzicht gekregen in deze opties dankzij sommige reacties. Ik vind het een interessant onderwerp, niet iedereen zal dat vinden.

Gan dan gewoon je eigen JS framework bouwen om alles te stylen zonder dat er ook maar één regel CSS aan te past komt. Als je over een jaar aanpassingen wilt verrichten aan je CSS-loze code en je komt er niet uit, hoef je in ieder geval niet hier te komen vragen om hulp...

Ik hoop dat het onderhand duidelijk is dat ik niet kwam voor 'conventionele' hulp, maar voor een vorm van sociale kennis die de ervaren mensen hier kunnen delen. En dat is aardig gelukt, mede met dank aan jouw bijdrage

[Harrie_]

mooi

[Verwijderd]

jayvol09 schreef op zondag 10 september 2017 @ 09:19:
Mijn OP nam aan dat er dingen zijn die puur CSS niet kan oplossen. Noem a.u.b. 1 persoon in deze draad die het tegendeel beweert?

Nou...er is minstens 1 die zegt dat je nooit JS nodig hoeft te hebben, en ik zelf heb gezegd dat het bijna nooit nodig is, al was dat alleen maar om een slag om de arm te hebben in het geval ik een heel uitzonderlijke situatie over het hoofd gezien had. Ik kan me niet herinneren dat ik het ooit nodig had, dus bij deze zeg ik ook 'nooit'. En dat impliceert dus dat er geen dingen zijn die niet met CSS (plus HTML) zijn op te lossen.

Ik denk dat je op een verkeerd spoor bent gezet door 'CSS = styling' te letterlijk te nemen. CSS gaat altijd samen met HTML om de presentatie van de website te bepalen, alleen zorgt HTML meer voor de fundering en CSS voor de aankleding. Je kunt geen schilderij ophangen zonder een muur te bouwen.

Het is dus niet alleen perfect valide om een extra DIV in te zetten - het is absurd om het niet te doen.

En ik heb geen idee wat voor 'geks' ik heb geroepen richting Zaph. Volgens mij stikte hij ook in m'n keuze van het woord 'kruk'

Check. In een discussie waar het sowieso al een beetje lijkt te schuren is het soms beter de humor even achterwege te laten...

[CodeCaster]

Ik begrijp niet helemaal waarom men hier de TS zo affakkelt. De vraag op zich is goed verwoord en doordacht, maar men blijft maar happen op de uitwerking van de voorbeelden.

Voor businesslogica die serverside bepaald wordt, dus op basis van kennis die de front-end niet heeft, is het logisch dat je met klassen werkt. Om verwijderde regels in een tabel donkerder te kleuren sla je geen kleurcode op in de database, maar je rendert de regel met een class="deleted-record", zodat de css daarna bepaalt hoe die regel eruit komt te zien.

TS claimt niet "styling op basis van klassen is fout", noch "styling dient enkel in css te gebeuren", waar men hier op lijkt te reageren.

De vraag van TS is: waar ligt die grens? Wanneer bepaal je in html, css of zelfs js hoe een element gestyled moet gaan worden? Is daar een standaard voor, best practices?

[jayvol09]

Verwijderd schreef op zondag 10 september 2017 @ 12:40:
[...]

Nou...er is minstens 1 die zegt dat je nooit JS nodig hoeft te hebben, en ik zelf heb gezegd dat het bijna nooit nodig is, al was dat alleen maar om een slag om de arm te hebben in het geval ik een heel uitzonderlijke situatie over het hoofd gezien had. Ik kan me niet herinneren dat ik het ooit nodig had, dus bij deze zeg ik ook 'nooit'. En dat impliceert dus dat er geen dingen zijn die niet met CSS (plus HTML) zijn op te lossen.

Dit vind ik een plausibele stelling. Maar is "nooit nodig" --in jouw ervaring-- hetzelfde als "nooit wenselijk"?
Ik ben overigens wel benieuwd of iemand een styling edge case weet waar JS echt voor nodig is. Kan er zelf ook zo snel geen bedenken.

Ik denk dat je op een verkeerd spoor bent gezet door 'CSS = styling' te letterlijk te nemen. CSS gaat altijd samen met HTML om de presentatie van de website te bepalen, alleen zorgt HTML meer voor de fundering en CSS voor de aankleding. Je kunt geen schilderij ophangen zonder een muur te bouwen.

Het is dus niet alleen perfect valide om een extra DIV in te zetten - het is absurd om het niet te doen.

Interessant, volgens mij is deze definitie van CSS kermerkend voor devs die langer in het vak bezig zijn. Aan de ene kant heb je gelijk: zonder elementen is er niets te stylen. Maar je kan in principe onderscheid maken tussen 'soorten' HTML. De puristen zeggen: de content elementen moeten muur genoeg zijn voor je schilderij, als je extra HTML nodig hebt is het niet semantische HTML en ben je aan het compenseren voor een imperfecte styling systeem (CSS). Tenminste zo begrijp ik de situatie, en ik denk dat de W3 op deze basis ontwikkelt voor HTML en CSS. Ik denk als het aan hun ligt bestaan divs en spans niet meer over 10 jaar.

Ik hanteer inderdaad de strictere definitie can CSS = styling, maar ik ben denk ik niet de enige(?). Alles wat met styling te maken heeft buiten CSS is een 'kruk' (of een ander politiek correcte woord ). Dit verschil heeft misschien bijgedragen aan de eerdere verwarring in deze draad. Mensen die m'n argumenten vaag vonden denken waarschijnlijk ook (onbewust?) in de termen van de bredere styling=CSS+HTML definitie.

[Verwijderd]

CodeCaster schreef op zondag 10 september 2017 @ 13:00:
De vraag van TS is: waar ligt die grens? Wanneer bepaal je in html, css of zelfs js hoe een element gestyled moet gaan worden? Is daar een standaard voor, best practices?

Lees de eerste post nog even goed door - sindsdien heeft hij het nodige genuanceerd, maar dat was toch wel een redelijke stemmingzetter. Met name opmerkingen als " Nu sta ik voor de keuze om deels CSS en deels JS te doen, of vol in te gaan op JS (+ JQuery, react, etc.) en dat gebrekkige CSS achterwege te laten." en "Onmogelijk om bepaalde elementen te selecteren in CSS zonder een class/ID eraan te hangen." zorgden voor de reacties die er gekomen zijn.

jayvol09 schreef op zondag 10 september 2017 @ 13:38:
[...]
Ik ben overigens wel benieuwd of iemand een styling edge case weet waar JS echt voor nodig is.

Ik heb eerlijk gezegd niet eens een duidelijk idee van wat je bedoelt - hoe style je met JS? Door element.style.??? waardes te geven? Da's dolle pret voor die enkeling die JS uitgeschakeld heeft, of als er een JS-fout optreedt waardoor je code niet verder uitgevoerd wordt.

Interessant, volgens mij is deze definitie van CSS kermerkend voor devs die langer in het vak bezig zijn.

Dat komt misschien omdat die aan de hand van ervaring hebben geleerd dat een theoretische benadering hardstikke leuk is maar je geen donder verder helpt met het opleveren van je website.

Als je klant per se dat schilderijtje daar wil hebben hangen, dan zal er toch echt een muur(tje) moeten komen zolang we geen anti-gravity spijkers tot onze beschikking hebben.

Alles wat met styling te maken heeft buiten CSS is een 'kruk' (of een ander politiek correcte woord ).

Nee, want je moet wel iets hebben om te stylen. Weer dat muurtje: je moet een muurtje hebben om het te kunnen verven. Je kunt de verf niet in de lucht laten hangen.

[jayvol09]

Verwijderd schreef op zondag 10 september 2017 @ 13:45:
Ik heb eerlijk gezegd niet eens een duidelijk idee van wat je bedoelt - hoe style je met JS? Door element.style.?

Ja bijvoorbeeld, toch?

Nee, want je moet wel iets hebben om te stylen. Weer dat muurtje: je moet een muurtje hebben om het te kunnen verven. Je kunt de verf niet in de lucht laten hangen.

Ja maar ik neem jouw metafoor en neem het stapje abstracter:
*content* is het muurtje (vaak een subset van de HTML), de schilderij is styling (CSS + hulptechnieken zoals non-content HTML).
Het feit dat de schilderij het muurtje nodig heeft (dependency) betekent niet dat het muurtje onderdeel is van wat men styling noemt.

[Verwijderd]

jayvol09 schreef op zondag 10 september 2017 @ 13:57:
[...]
Ja bijvoorbeeld, toch?

Ik zou niks anders kunnen bedenken. Maar hoe ga je dan om met het toevoegen van ondersteuning voor een andere resolutie? Dan moet je overal in je JS code gaan toevoegen. Of als de styling van de website een overhaul krijgt? Da's net als de oude manier van website bouwen zonder templates - overal in de PHP-code staan HTML-fragmentjes waardoor het niet meer te onderhouden is.

Het feit dat de schilderij het muurtje nodig heeft (dependency) betekent niet dat het muurtje onderdeel is van wat men styling noemt.

Dus? Het is nog steeds nodig, dus het maakt niet uit hoe je het noemt.

[jayvol09]

Verwijderd schreef op zondag 10 september 2017 @ 14:03:

Dus? Het is nog steeds nodig, dus het maakt niet uit hoe je het noemt.

Mee eens: muurtje is nodig. Muurtje is geen kruk. Mijn definitie van kruk was (o.a.) HTML dat niet behoort tot het muurtje.

[Verwijderd]

Meh. De spijker dan - hang dat ding maar eens op zonder hulpmiddelen. Lukt niet.

[jayvol09]

Verwijderd schreef op zondag 10 september 2017 @ 14:10:
Meh. De spijker dan - hang dat ding maar eens op zonder hulpmiddelen kruk. Lukt niet.

Ik kan stylen zonder non-content HTML, maar het werkt wellicht niet zo fijn, helemaal als ik JS ook uitsluit. Dan zit ik in de stricte definitie van CSS styler. Het resultaat zal wss wel matig zij n.

[Verwijderd]

Misschien wordt het tijd dat je een goed voorbeeld geeft, want je begint me kwijt te raken.

[jayvol09]

Goede voorbeelden zijn niet mijn sterke kant Ik zal ff nadenken hoe ik het beter kan verwoorden. Of misschien springt een andere lezer bij.

Je hebt zeg maar 'HTML voor bots' en extra HTML dat het mooi maakt voor mensen. In mijn eerdere voorbeeld dat opgelost werd door een div was dat divje zo'n extra voor mensen (m.a.w. puur styling gerelateerd), heeft niets met de 'informatie content' te maken.

[Verwijderd]

Eh...het eindresultaat is toch primair voor mensen bedoeld, en niet voor bots?

[ Voor 6% gewijzigd door Verwijderd op 10-09-2017 14:37 ]

[Verwijderd]

Voor bots kun je de css ook wel achterwege laten

Styling zou inderdaad zoveel mogelijk in css moeten worden opgelost, maar je ontkomt er niet aan dat het hand in hand gaat met html. Voornamelijk voor het bepalen van de layout, maar inderdaad ook voor het groeperen van dom elementen om styling in css mogelijk te maken a.d.h.v. bijv. context.


PS: Ik viel eerst ook over het woord kruk en snapte ook niet wat TS ermee bedoelde... Totdat ik net zelf aan 'html handles' moest denken. Ik vermoed dat TS hier de vertaling van bedoelde? Heb het nog nooit zo gebruikt horen worden in het Nederlands.

[ Voor 26% gewijzigd door Verwijderd op 10-09-2017 15:25 ]

[williammorren]

Ramon schreef op vrijdag 8 september 2017 @ 19:34:
[...]

Om even de knuppel in het hoenderhok te gooien: Dat werkt inderdaad, maar is nou niet echt begrijpelijk. Als jij over een half jaar:

code:

dd:first-of-type:not(:only-of-type),
dd + dd:not(:last-of-type) {
  color: red;
}

In een lomp stuk CSS ziet staan van een grote site, weet jij dan nog wat er bedoelt wordt?

Ik zou het zelf alsvolgt oplossen: https://jsfiddle.net/mu22kyvd/1/

De topic starter vroeg voor css zonder class of id. Daarom het voorbeeld.

[incaz]

jayvol09 schreef op zondag 10 september 2017 @ 09:19:
Wat mij ook interesseert is dat mensen wellicht soms onbewust stylen met HTML.

Maar het gebruiken van een extra div is niet hetzelfde als stylen met HTML. Dit allereerst omdat html simpelweg niet compleet is en gewoon niet alle mogelijke semantische betekenissen weer te geven. Het is een set van elementen waarvan men heeft geoordeeld dat het voor het meeste webpagina-gebruik min of meer de lading dekt, niet veel meer dan dat.

Div en span zijn er, zeker in combinatie met classes, juist voor om dat gat op te vullen, en een ordening te kunnen maken die voor jouzelf nuttig en zinvol is als de html-elementen niet toereikend zijn. Dat kan dus reuze semantisch zijn, zelfs als dat (nog) niet zo geinterpreteerd kan worden door automatische gegevensverwerkingstools.

Heel specifiek in het voorbeeld van de DL wordt de div gebruikt binnen de DL, omdat er sterke behoefte was om de dt en de dd's aan elkaar te kunnen verbinden en als geheel te kunnen behandelen.
Dat is dan ook exact de reden dat dat element door de W3G als valide is toegevoegd. De tekortkoming daar zit dan ook niet in CSS, maar veel meer in de structuur van het DL-element dat simpelweg het semantische concept niet ondersteund. Dat gat is nu met het toelaten van de div gedicht - en een div is daar niet de meest ideale benaming voor, maar een geheel nieuw element daarvoor uitvinden is ook niet ideaal.

En bedenk dat ditzelfde al vaker en eerder is gebeurd.
Toen men ooit bedacht had dat het handig was om headers en paragraphs gewoon onder elkaar te zetten (zonder hierarchie maar uitsluitend opeenvolgend) bleek algauw dat het toch handig is om ook een groeperend element te hebben dat verwijst naar het 'hoofdstuk' als geheel, de header en de onderliggende tekst samen.

Daarvoor werden vervolgens divs gebruikt, omdat dat precies het element was wat daarbij paste (blocklevel, maar nog geen expliciete semantische betekenis.) Een van de manieren waarop de html5-elementen zijn bepaald is doordat men simpel van heel veel sites heeft gekeken wat de meest voorkomende classnames waren, en die zijn toen als uitgangspunt gebruikt voor nieuwe elementen.

Oftewel: ik denk dat het gebruik van een div in dit specifieke voorbeeld behoorlijk semantisch correct is: precies op het niveau waar je dat element ook zou verwachten.

(En vervolgens zie je dat de problemen met de css ook verdwijnen doordat je :first-child, :nth-child en :last-child kunt gebruiken. Maar het samen in een element vangen van dt en dd is ook logisch als je bijvoorbeeld kolommen of print-pagina's maakt, waarbij je dan kunt zorgen dat je niet op de ene plek de term hebt en pas op de volgende pagina of in de volgende kolom de omschrijving, maar dat je die gewoon als geheel verplaatst. Dat geeft wel aan dat het daar niet alleen maar om een trucje voor styling gaat, maar ook om iets dat echt wel betekenis heeft.)

[jayvol09]

incaz schreef op woensdag 13 september 2017 @ 18:06:
Maar het gebruiken van een extra div is niet hetzelfde als stylen met HTML. Dit allereerst omdat html simpelweg niet compleet is en gewoon niet alle mogelijke semantische betekenissen weer te geven. Het is een set van elementen waarvan men heeft geoordeeld dat het voor het meeste webpagina-gebruik min of meer de lading dekt, niet veel meer dan dat.

Klopt. Niet elke div/span is er puur voor styling. Maar de elementen die wel puur styling zijn zijn meestal divs en spans (soms zie ik ook [i] en [b] gebruikt worden voor gekke dingen).

Heel specifiek in het voorbeeld van de DL wordt de div gebruikt binnen de DL, omdat er sterke behoefte was om de dt en de dd's aan elkaar te kunnen verbinden en als geheel te kunnen behandelen.
[...] De tekortkoming daar zit dan ook niet in CSS, maar veel meer in de structuur van het DL-element dat simpelweg het semantische concept niet ondersteund.
[...]
Oftewel: ik denk dat het gebruik van een div in dit specifieke voorbeeld behoorlijk semantisch correct is: precies op het niveau waar je dat element ook zou verwachten.

Hmm in dit specifieke geval ben ik het niet eens: de div is puur styling en voegt geen semantische betekenis toe. Dit omdat een dt en eventuele sibling dd's *impliciet* al bij elkaar horen, volgens de spec beschrijving van DL. Maar ik kan me voorstellen met andere lists (ol/ul) dat divs wel semantisch iets kunnen toevoegen. In dat geval heb je een bonus semantische relatie die je kan gebruiken voor styling.

En bedenk dat ditzelfde al vaker en eerder is gebeurd.
Toen men ooit bedacht had dat het handig was om headers en paragraphs gewoon onder elkaar te zetten (zonder hierarchie maar uitsluitend opeenvolgend) bleek algauw dat het toch handig is om ook een groeperend element te hebben dat verwijst naar het 'hoofdstuk' als geheel, de header en de onderliggende tekst samen.

Daarvoor werden vervolgens divs gebruikt, omdat dat precies het element was wat daarbij paste (blocklevel, maar nog geen expliciete semantische betekenis.) Een van de manieren waarop de html5-elementen zijn bepaald is doordat men simpel van heel veel sites heeft gekeken wat de meest voorkomende classnames waren, en die zijn toen als uitgangspunt gebruikt voor nieuwe elementen.

Zo begreep ik het ook. In het verleden waren divs belangrijker om bepaalde semantische connecties te maken. Trivia: Een interessant artikel (3-delige blog) dat ik vond beweert echter dat sommige elementen die divs vervangen niet goed onderbouwd zijn met onderzoek. https://www.webdesignerde...uctural-semantics-part-1/

([...] Maar het samen in een element vangen van dt en dd is ook logisch als je bijvoorbeeld kolommen of print-pagina's maakt, waarbij je dan kunt zorgen dat je niet op de ene plek de term hebt en pas op de volgende pagina of in de volgende kolom de omschrijving, maar dat je die gewoon als geheel verplaatst. Dat geeft wel aan dat het daar niet alleen maar om een trucje voor styling gaat, maar ook om iets dat echt wel betekenis heeft.)

Zo zie ik het niet. kolommen enzo zijn een style detail. Dus een div om wrap-gedrag aan te passen is wel degelijk een trucje voor styling.

[mcDavid]

jayvol09 schreef op zondag 10 september 2017 @ 14:34:
Goede voorbeelden zijn niet mijn sterke kant Ik zal ff nadenken hoe ik het beter kan verwoorden. Of misschien springt een andere lezer bij.

Je hebt zeg maar 'HTML voor bots' en extra HTML dat het mooi maakt voor mensen. In mijn eerdere voorbeeld dat opgelost werd door een div was dat divje zo'n extra voor mensen (m.a.w. puur styling gerelateerd), heeft niets met de 'informatie content' te maken.

Sorry maar deze manier van denken is echt fundamenteel verkeerd. En is denk ik ook de oorzaak van het "probleem" waar je tegenaan loopt.

HTML is een markup language. Gemaakt om content zo te structureren dat je deze, in de vorm van een website, weer kunt geven zoals jij dat wilt. Jij bent nu HTML aan het beschouwen als een tool om content te beschrijven voor een bot? Daar is het nooit voor bedoeld.

Natuurlijk helpt het voor de toegankelijkheid en vindbaarheid van je website als je HTML een beetje schoon en semantisch is. Maar schone/semantische HTML is nooit een doel op zich. Als je rare kunstgrepen aan het overwegen bent (zoals js gebruiken voor styling) heb je het doel van je werk als frontender (een mooie, snelle, toegankelijke website neerzetten) compleet uit het oog verloren.

Als je je druk maakt om de vindbaarheid van je website, kan ik je iig verklappen dat search engine bots tegenwoordig slim genoeg zijn om ook je CSS en JS in te laden, en je site onderandere beoordelen op snelheid. Dit soort kunstgrepen gaan je dus wat dat betreft ook niet helpen maar eerder tegenwerken.

Kortom denk nog eens goed na wat je nou probeert te bereiken, en waarom je dat probeert te bereiken. En als je daar over uit bent, gebruik dan de meest voor de hand liggende middelen, dat zijn namelijk meestal de beste.

[jayvol09]

mcDavid schreef op donderdag 14 september 2017 @ 08:55:
[...]


Sorry maar deze manier van denken is echt fundamenteel verkeerd. En is denk ik ook de oorzaak van het "probleem" waar je tegenaan loopt.

HTML is een markup language. Gemaakt om content zo te structureren dat je deze, in de vorm van een website, weer kunt geven zoals jij dat wilt. Jij bent nu HTML aan het beschouwen als een tool om content te beschrijven voor een bot? Daar is het nooit voor bedoeld.

Natuurlijk helpt het voor de toegankelijkheid en vindbaarheid van je website als je HTML een beetje schoon en semantisch is. Maar schone/semantische HTML is nooit een doel op zich. Als je rare kunstgrepen aan het overwegen bent (zoals js gebruiken voor styling) heb je het doel van je werk als frontender (een mooie, snelle, toegankelijke website neerzetten) compleet uit het oog verloren.

Als je je druk maakt om de vindbaarheid van je website, kan ik je iig verklappen dat search engine bots tegenwoordig slim genoeg zijn om ook je CSS en JS in te laden, en je site onderandere beoordelen op snelheid. Dit soort kunstgrepen gaan je dus wat dat betreft ook niet helpen maar eerder tegenwerken.

Ik zou zeggen fundamenteel anders. Maar niet fundamenteel verkeerd.
Aldus het naïve idealistische w3.org:

Authors must not use elements, attributes, or attribute values for purposes other than their appropriate intended semantic purpose, as doing so prevents software from correctly processing the page.

Ze erkennen gelukkig dat styling-hulp elementen in de praktijk voorkomen. Maar begrijp ik HTML verkeerd? Ik denk het niet, en ik ben niet de enige (enter next person die me gaat afvlammen ).

Bots/SEO was maar een voorbeeld om het concept over te brengen. Wat je zegt, *toegankelijk* is vooral een belangrijk doel denk ik. Daarom is mijn denkbeeldige target audience iemand die zonder scherm mijn website probeert te gebruiken. HTML is een taal om de benodigde informatie content te beschrijven, dus schoon is wel een doel op zich. Deze manier van denken, misschien niet door iedereen beoefend, hoort zoals ik het lees tot de (huidige/moderne) web fundamenten.

Natuurlijk maak ik in de praktijk afwegingen waardoor ik minder schone HTML krijg in ruil voor een site dat mooier oogt op een scherm, maar elke extra style div is een bewuste keuze. Als ik kan kiezen tussen 20 divs+bijbehorende rules of 1 regel JS, dan ben ik vaak geneigd JS te kiezen. Bij een keus tussen 1 div en 5 regels JS kies ik voor de div. Als ik kan kiezen tussen een lastige CSS 'kunstgreep' of een simple div: 50/50 (ik denk dat de meesten hier voor de style div zouden kiezen).

Maak ik het mezelf moeilijker dan vaak nodig is? Wellicht. Zijn mijn implementaties geen goede kopie van het photoshop concept? Waarschijnlijk. Kan ik moeilijker dev werk vinden? Jup. Maar ik denk dat het principe aanhouden van "content apart van styling" goed is, want frontend is (tegenwoordig?) niet alleen maar weergave. Zolang de web-standaard met deze principes blijft ontwikkelen zal m'n werk vanzelf makkelijker worden over de jaren.

[mcDavid]

Die target audience met screenreader heeft er écht geen last van als jij gewoon divs en classnames gebruikt zoals ze bedoeld zijn hoor.

[jayvol09]

mcDavid schreef op donderdag 14 september 2017 @ 10:21:
Die target audience met screenreader heeft er écht geen last van als jij gewoon divs en classnames gebruikt zoals ze bedoeld zijn hoor.

Mee eens. We zijn het echter oneens over wat "waar ze voor bedoeld zijn" precies betekent. Zoals ik het geleerd heb zijn ze niet voor *puur* styling bedoeld. Dit kan ik beargumenteren aan de hand van de huidige web-standaard.

[Verwijderd]

Is dit nu je bedoeling een puur theoretische discussie te hebben, of wil je gewoon praktisch aan de slag en loop je tegen uitdagingen aan? Het eerste heb ik namelijk helemaal geen zin in, dus dan kan ik dit draadje verder negeren.

[jayvol09]

Theoretisch

[perpixel]

Ik denk dat je het semantische html concept te ver door trekt. Het is heel belangrijk dat HTML goed semantisch geschreven wordt (je navigatie in een nav, je sections, je articles, maar ook strong en em ipv. i en b), maar het is in oorsprong een taal om structuur aan te geven. Hier kunnen gewoon extra divjes ofzo nodig zijn. De balans hierin is belangrijk.

Om dit te vermijden (op manieren zoals jij voorstelt) is een beetje als een trap toegankelijker willen maken voor rolstoelgebruikers, maar ipv een gewone ramp er een looping in plaatsen. Het is een stuk lastiger te maken/onderhouden en alle gebruikers hebben er eigenlijk meer last van dan voordeel.

Je punt over het "reclassen" is een nadeel van het statisch schrijven van je html. Niet een fout van CSS of HTML. Dit wordt normaal door je back-end taal gedaan op het moment dat je view gerenderd word. Wat jij nu voorstelt is een valide mogelijkheid, maar dan moet je wel begrijpen waarom je die keuze maakt.

Wat je dan gaat doen is zorgen dat React, Angular of een van de miljoen andere frameworks de HTML voor je genereert (met de juiste classes op de juiste plek), maar dus niet de styling. Je styling door JS laten doen is eigenlijk not-done en is niet stylen met JS, maar het dynamisch toevoegen van inline styles in je html.
De enige keren dat het zou kunnen is als de styling afhankelijk is van veranderende elementen (denk aan position obv. scrollpositie, maar deze situaties worden steeds schaarser met 3d transforms en nieuwe manieren van positioneren).
Verder zou je in je js wel classes kunnen toevoegen op het moment dat er een verandering is bijv. na een user input of een state-change. Aan deze class hang je dan styling met css welke over het uiterlijk gaat.

[Caelorum]

Een theoretische discussie kan je beter op de plek doen waar de beslissingen uiteindelijk ook genomen worden. Dat is, als je nog iets nuttigs uit die discussie wilt kunnen halen, we zijn het er namelijk, denk ik, allemaal mee eens dat je liever alle styling in CSS ziet en HTML alleen een semantische weergave van de informatie zou moeten bevatten, maar dat is nu eenmaal niet zo.

Overigens zou ik er ook niet vanuit gaan dat als de scheiding 100% ok is en je html alleen semantische informatie heeft dat iemand met een screenreader er dan perfect mee overweg kan. Dat is helaas niet het geval.

[jayvol09]

perpixel schreef op donderdag 14 september 2017 @ 11:45:
Je punt over het "reclassen" is een nadeel van het statisch schrijven van je html. Niet een fout van CSS of HTML. Dit wordt normaal door je back-end taal gedaan op het moment dat je view gerenderd word. Wat jij nu voorstelt is een valide mogelijkheid, maar dan moet je wel begrijpen waarom je die keuze maakt.

Dit begrijp ik, maar net als met HTML elementen ik maak ook onderscheid tussen semantische classen (e.g. "main_content" of "made_in_china") en style classen ("eerste/laatste/custom_paars/") . Als ik een element toevoeg in die DL dan moet ik waarschijnlijk reclassen ook al verandert er niets semantisch, dus die styling classes zouden eigenlijk vervangen moeten worden door betere CSS rules. Dit zou b.v. kunnen als CSS intuitieve parent/previous sibling operators had: "p+div" kennen we, selecteert een div die een p volgt, maar "p-div" selecteert een div die voorafgaat aan een p. De enige reden waarom dit niet bestaat is omdat het CSS langzamer zou maken. M.a.w. pure engineering optimalisatie ten koste van scheiding content/styling.

Je styling door JS laten doen is eigenlijk not-done en is niet stylen met JS, maar het dynamisch toevoegen van inline styles in je html.
De enige keren dat het zou kunnen is als de styling afhankelijk is van veranderende elementen (denk aan position obv. scrollpositie, maar deze situaties worden steeds schaarser met 3d transforms en nieuwe manieren van positioneren).
Verder zou je in je js wel classes kunnen toevoegen op het moment dat er een verandering is bijv. na een user input of een state-change. Aan deze class hang je dan styling met css welke over het uiterlijk gaat.

Goede inzichten. Wat ik ook aan dacht is scherm grootte. Stel je wilt een figuur op een hele specifieke manier schalen, dan zijn de default width, max-width, e.d. opties niet erg nuttig.

[Harrie_]

Verwijderd schreef op donderdag 14 september 2017 @ 10:57:
Is dit nu je bedoeling een puur theoretische discussie te hebben, of wil je gewoon praktisch aan de slag en loop je tegen uitdagingen aan? Het eerste heb ik namelijk helemaal geen zin in, dus dan kan ik dit draadje verder negeren.

jayvol09 schreef op donderdag 14 september 2017 @ 11:41:
Theoretisch

Same here, daar mag je in het vervolg wel iets duidelijker in zijn. Ik kwam er in mijn vorige post misschien ook wat hard ingevlogen maar in je OP geef je een aantal zaken aan 'waar je tegenaan loopt' en wek je de indruk dat je gewoon praktische hulp nodig hebt.

Als je je OP wat duidelijker neerzet en daarin goed kenbaar maakt dat dit een discussietopic is een geen 'hulptopic' dan lopen de gemoederen ook niet zo uit de hand

Just my 2 cents

[jayvol09]

Harrie_ schreef op donderdag 14 september 2017 @ 12:15:
[...]


[...]


Same here, daar mag je in het vervolg wel iets duidelijker in zijn. Ik kwam er in mijn vorige post misschien ook wat hard ingevlogen maar in je OP geef je een aantal zaken aan 'waar je tegenaan loopt' en wek je de indruk dat je gewoon praktische hulp nodig hebt.

Als je je OP wat duidelijker neerzet en daarin goed kenbaar maakt dat dit een discussietopic is een geen 'hulptopic' dan lopen de gemoederen ook niet zo uit de hand

Just my 2 cents

Zal ik doen in het vervolg. Water onder de brug. Zand erover. *stopt brandblusser weg*

[perpixel]

jayvol09 schreef op donderdag 14 september 2017 @ 12:15:
[...]

Dit begrijp ik, maar net als met HTML elementen ik maak ook onderscheid tussen semantische classen (e.g. "main_content" of "made_in_china") en style classen ("eerste/laatste/custom_paars/") . Als ik een element toevoeg in die DL dan moet ik waarschijnlijk reclassen ook al verandert er niets semantisch, dus die styling classes zouden eigenlijk vervangen moeten worden door betere CSS rules. Dit zou b.v. kunnen als CSS intuitieve parent/previous sibling operators had: "p+div" kennen we, selecteert een div die een p volgt, maar "p-div" selecteert een div die voorafgaat aan een p. De enige reden waarom dit niet bestaat is omdat het CSS langzamer zou maken. M.a.w. pure engineering optimalisatie ten koste van scheiding content/styling.


[...]

Goede inzichten. Wat ik ook aan dacht is scherm grootte. Stel je wilt een figuur op een hele specifieke manier schalen, dan zijn de default width, max-width, e.d. opties niet erg nuttig.

Nee de parent selector bestaat niet vanwege het originele ontwerp principe van CSS (cascading style sheets). Maar eigenlijk heb je het in deze situatie over de last-of-type in een lijstje. Dus zou ik de structuur aanpassen zodat hij bij je doel past.

Ik heb ook moeite met een situatie bedenken waar een parent styling afhankelijk is van zijn children. Ik denk dat daar een denkfout zit. Daarom is in deze een voorbeeld heel belangrijk. Dan kan er uitgelegd worden hoe je het op zou lossen zonder hier tegenaan te lopen.

[ Voor 9% gewijzigd door perpixel op 14-09-2017 12:35 ]

[Caelorum]

perpixel schreef op donderdag 14 september 2017 @ 12:31:
[...]
Ik heb ook moeite met een situatie bedenken waar een parent styling afhankelijk is van zijn children. Ik denk dat daar een denkfout zit. Daarom is in deze een voorbeeld heel belangrijk. Dan kan er uitgelegd worden hoe je het op zou lossen zonder hier tegenaan te lopen.

Menu's waarbij 4 niveau's diep de huidige pagina staat aangegeven in je html, maar je ook bij de bovenliggende niveau's (parent menu items) je iets wil tonen. Eigenlijk zou je op dat punt ook een class willen toevoegen, maar die luxe heb je niet altijd..

[incaz]

jayvol09 schreef op donderdag 14 september 2017 @ 07:14:
[...]
Hmm in dit specifieke geval ben ik het niet eens: de div is puur styling en voegt geen semantische betekenis toe. Dit omdat een dt en eventuele sibling dd's *impliciet* al bij elkaar horen, volgens de spec beschrijving van DL.

Is natuurlijk leuk en aardig dat dingen *impliciet* bij elkaar horen - als het niet expliciet is heb je er niet veel aan. Dat kun je de dom-tree verwijten, en de html-spec op zich... maar het concept van een overkoepelend element dat een term en de definitions bij elkaar groepeert is semantisch heel nuttig.

Zo zie ik het niet. kolommen enzo zijn een style detail. Dus een div om wrap-gedrag aan te passen is wel degelijk een trucje voor styling.

Dan begrijp je mijn punt verkeerd. Semantische elementen geven een structuur aan die samenhangt met de functie. Het gaat dan dus om wat voor ons mensen een bepaalde samenhang heeft.

En...styling was altijd al de visuele manier waarop we de semantische concepten steunen en overbrengen.

Ver voor we html-elementen hadden uitgevonden, hadden we al wel manieren ontwikkeld om hoofdstuktitels, paragrafen, lijsten en andere zaken van elkaar te onderscheiden, om de lezer te helpen met de structuur. Dat is uiteindelijk de functie - en daarom is het kijken naar de visuele eigenschappen vaak een manier om te leren over wat wij als mens belangrijke structuren vinden.

En dan kan de wens om bepaalde dingen samen te willen houden ipv op te breken bij kolomeindes of pagina-eindes, een goede indicatie zijn dat het daar dus gaat om een bepaald structureel element dat voor mensen belangrijk is.
Dat is geen styling-'trucje' - dat is precies waar het om gaat.

(Styling trucs... dat is als je <p> </p><p> </p><br><br><br> gebruikt om iets verticale ruimte te geven. Of, in bbcode, als ik een {list}{i}"Aangehaalde tekst"{/i}{/list} gebruik om een alternatieve blockquote te maken. Maar dat is niet aan de orde als je een extra element gebruikt om een dt en bijbehorende dd's te groeperen)

[perpixel]

Caelorum schreef op donderdag 14 september 2017 @ 12:57:
[...]

Menu's waarbij 4 niveau's diep de huidige pagina staat aangegeven in je html, maar je ook bij de bovenliggende niveau's (parent menu items) je iets wil tonen. Eigenlijk zou je op dat punt ook een class willen toevoegen, maar die luxe heb je niet altijd..

En die luxe heb je niet omdat "hetgene" dat de html genereert (willekeurig cms) het niet ondersteund en de projectmanager/designer het wel wil.

Is het dan een fout in de CSS spec of een ontbrekende functie in het systeem dat het menu genereert/afstemming met degene die dit wil hebben? In elk geval is de oplossing dit dan met JS toevoegen niet goed. Of je past de view renderer aan om dit wel te kunnen of past het ontwerp aan?

Toelichting: als ik het wel voor elkaar krijg met gewoon HTML/CSS typen, maar niet met een systeem erachter dat het genereert. Is het dan de fout van HTML/CSS of van het systeem dat het neer zet?

[ Voor 10% gewijzigd door perpixel op 14-09-2017 13:26 ]

[Verwijderd]

perpixel schreef op donderdag 14 september 2017 @ 13:25:
[...]
Is het dan de fout van HTML/CSS of van het systeem dat het neer zet?

Het is geen fout als het een server side gegenereert wordt en het andere client side geïnterpreteerd.

Met js classes toevoegen is een lapmiddel dat je bij voorkeur al in php of wat dan ook oplost. Maar als dit van een derde partij komt waar je geen invloed op hebt is het een oplossing.

Het is me trouwens maar 1 keer overkomen dat ik met css geen element kon beïnvloeden. Een geembede facebook wall die een bepaalde breedte had. Die werdt meegegeven door js van facebook. Bijzonder irritant.

[Harrie_]

Verwijderd schreef op donderdag 14 september 2017 @ 14:19:
[...]
Met js classes toevoegen is een lapmiddel dat je bij voorkeur al in php of wat dan ook oplost.
[...]

Dit.

[perpixel]

Verwijderd schreef op donderdag 14 september 2017 @ 14:19:
[...]


Het is geen fout als het een server side gegenereert wordt en het andere client side geïnterpreteerd.

Met js classes toevoegen is een lapmiddel dat je bij voorkeur al in php of wat dan ook oplost. Maar als dit van een derde partij komt waar je geen invloed op hebt is het een oplossing.

Het is me trouwens maar 1 keer overkomen dat ik met css geen element kon beïnvloeden. Een geembede facebook wall die een bepaalde breedte had. Die werdt meegegeven door js van facebook. Bijzonder irritant.

Ik denk dat we ongeveer hetzelfde zeggen, maar anders verwoorden. Het is de taak van de renderer geen "fout" of tekortkoming van html/css. Mocht het echt nodig zijn kan er wel een lapmiddel als JS gebruikt worden.

[jayvol09]

incaz schreef op donderdag 14 september 2017 @ 13:18:
[...]
Is natuurlijk leuk en aardig dat dingen *impliciet* bij elkaar horen - als het niet expliciet is heb je er niet veel aan.

Klopt. Het huidige CSS kan er niets mee.

Dan begrijp je mijn punt verkeerd. Semantische elementen geven een structuur aan die samenhangt met de functie. Het gaat dan dus om wat voor ons mensen een bepaalde samenhang heeft.

Volgens mij begreep ik je prima, maar hanteer jij een véél bredere definitie van "semantisch". Uit mijn vorige posts zal vast duidelijk zijn dat ik het stricter defineer. Een visuele samenhang is geen semantische connectie (er is hooguit een correlatie).

Zo breed als jij het maakt is alle html semantisch, dit strookt niet met abstracter gebruik in computer wetenschap en taalkunde, en ik weet vrij zeker dat dit niet past bij wat W3 het 'semantic web' noemt. Semantische elementen zijn per definitie vormloos, dus elementen puur voor vorm zijn niet semantisch.

En...styling was altijd al de visuele manier waarop we de semantische concepten steunen en overbrengen.

Het kernwoord in deze zin is "was". In het begin waren de twee concepten hevig verweven in HTML. De voornaamste bestaansreden van CSS was juist om te helpen bij het scheiden van fysieke concepten (styling) en semantische concepten die los staan van weergave e.d.. Zo waren er vroeger <font> elementen die nu zo goed als weg zijn, en italic en bold elementen worden sterk afgeraden. CSS zal waarschijnlijk nooit helemaal slagen in het compleet opvangen van styling, maar dit betekent niet dat de stukjes HTML die nog gebruikt worden puur voor weergave opeens semantisch zijn.

Ver voor we html-elementen hadden uitgevonden, hadden we al wel manieren ontwikkeld om hoofdstuktitels, paragrafen, lijsten en andere zaken van elkaar te onderscheiden, om de lezer te helpen met de structuur. Dat is uiteindelijk de functie - en daarom is het kijken naar de visuele eigenschappen vaak een manier om te leren over wat wij als mens belangrijke structuren vinden.

En dan kan de wens om bepaalde dingen samen te willen houden ipv op te breken bij kolomeindes of pagina-eindes, een goede indicatie zijn dat het daar dus gaat om een bepaald structureel element dat voor mensen belangrijk is.
Dat is geen styling-'trucje' - dat is precies waar het om gaat.

Je lijkt te beweren dat de oorsprong van informatie structureren ligt bij de ontwikkeling van visuele media. 1: dit is niet waar. 2: al zou het waar zijn volgt het niet logisch dat structureren inherent een visueel iets is. Data hoeft geen vorm te hebben. De moderne frontend is dus meer dan tekenaar op digitaal papier. Dus gezien mijn definitie van semantisch blijven alle puur stylische ingrepen (zoals dingen bij visueel elkaar houden) gewoon stylistische ingrepen.

perpixel schreef op donderdag 14 september 2017 @ 12:31:
Nee de parent selector bestaat niet vanwege het originele ontwerp principe van CSS (cascading style sheets). Maar eigenlijk heb je het in deze situatie over de last-of-type in een lijstje. Dus zou ik de structuur aanpassen zodat hij bij je doel past.

Dat zeg ik? Er is niets inherent aan 'cascading' waardoor het niet kan, maar de implementatie zoals het nu gedaan wordt bestaat uit 1 cascade iteratie. Een parent of prev. sibling zou 2+ iteraties nodig hebben (als ik het goed begrijp). Dat zou mogelijk zijn, maar te langzaam.

[ Voor 9% gewijzigd door jayvol09 op 15-09-2017 05:21 ]

[incaz]

jayvol09 schreef op vrijdag 15 september 2017 @ 05:18:
Zo breed als jij het maakt is alle html semantisch, dit strookt niet met abstracter gebruik in computer wetenschap en taalkunde, en ik weet vrij zeker dat dit niet past bij wat W3 het 'semantic web' noemt.

Het 'semantic web' is dan ook behoorlijk anders dan het simpelweg gebruiken van passende elementen. Wikipedia: Semantic Web

Waar ik het over heb is het Wikipedia: Semantic HTML
"the use of HTML markup to reinforce the semantics, or meaning, of the information in webpages and web applications rather than merely to define its presentation or look."

Mijn punt blijft: het toevoegen van een div om een term met de bijbehorende definities te groeperen tot 1 element is precies dat gaat over 'reinforcing the semantics or meaning of the information' en niet 'merely presentation or look'.

Semantische elementen zijn per definitie vormloos, dus elementen puur voor vorm zijn niet semantisch.

Semantische elementen zijn niet per definitie vormloos, waarom denk je dat?

[jayvol09]

incaz schreef op vrijdag 15 september 2017 @ 10:21:
[...]


Het 'semantic web' is dan ook behoorlijk anders dan het simpelweg gebruiken van passende elementen. Wikipedia: Semantic Web

Waar ik het over heb is het Wikipedia: Semantic HTML
"the use of HTML markup to reinforce the semantics, or meaning, of the information in webpages and web applications rather than merely to define its presentation or look."

Mijn punt blijft: het toevoegen van een div om een term met de bijbehorende definities te groeperen tot 1 element is precies dat gaat over 'reinforcing the semantics or meaning of the information' en niet 'merely presentation or look'.

Je punt lijkt nu iets verschoven t.o.v. eerder: ik ben het eens met hoe je het nu verwoord, namelijk dat een div semantische waarde kan hebben. In dat geval is het semantische HTML. Maar stel bijvoorbeeld een div dat alleen totaal ongerelateerde elementen dezelfde kleur geeft? Dat is niet semantische HTML, en ik kreeg de indruk dat jij vindt van wel. Zo'n element voegt niets toe aan "semantics, or meaning, of the information" maar valt puur onder "its presentation or look", om die quote maar te gebruiken.

[...]
Semantische elementen zijn niet per definitie vormloos, waarom denk je dat?

• Content informatie is abstract.
• Content informatie bestaat uit semantische elementen.
• ¬ semantische elementen zijn abstract

Er staat bijvoorbeeld nergens in de HTML spec hoe een <em> geïmplementeerd moet worden. Ik moet denken aan character encoding vs fonts. De Unicode code "0031" communiceert het getal 1, maar zegt niets over hoe dat getal eruit ziet. Het semantische character "0031" heeft dus geen inherente vorm, het is abstracte informatie.

[R4gnax]

jayvol09 schreef op vrijdag 15 september 2017 @ 05:18:

Een visuele samenhang is geen semantische connectie

Zegt wie?
Er zijn in het verleden een aantal hoog-van-de-toren blazende radicalen geweest die claimen dat 'semantische classes' op de semantiek van de content moet slaan. Maar ook je structuur zelf kan semantiek zijn.

Zeg bijv. dat je een 'simpel' knopje hebt, dat heeft een tekst en kan optioneel links of rechts een extra aanhangsel hebben waar bijv. een icoon in kan staan. Maar evt. ook een spinner, voor wanneer de knop geblokkeerd is omdat de user interface ergens mee bezig is.

Dat wordt dan zo iets:

HTML:

<button type="button" class="button">
  <span class="button__token" data-pos="left">
    <i class="icon" data-icon="check"></i>
  </span>
  <span class="button__token" data-pos="right">
    <i class="icon" data-icon="triangle-right"></i>
  </span>
  <span class="button__text">Save and continue</span>
</button>

Cascading Stylesheet:

.button {
  align-items : center;  
  background : #3191de;
  border : none;
  border-radius : 5px;
  color : #fff;
  cursor : pointer;
  display : inline-flex;
  height : 3em;
  overflow : hidden;
  padding : 0;
}

.button__token {
  align-items : center;
  background : #1a85da;
  display : none;
  height : 100%;
  justify-content : center;
  min-width : 1em;
  padding   : 0 1em;
}

.button__token[data-pos='left'] {
  display : flex;
  order : -1;
}

.button__token[data-pos='right'] {
  display : flex;
  order : 1;
}

.button__text {
  padding : 0 20px;
}

.button__token[data-pos='left'] ~ .button__text {
  padding-left : 10px;
}

.button__token[data-pos='right'] ~ .button__text {
  padding-right : 10px;
}


.icon {
  align-items : center;
  display : inline-flex;
  font-style : normal;
  font-weight : normal;
  height  : 1em;
  justify-content : center;
  width   : 1em;
}

.icon[data-icon='check']::after {
 content : '\2713';
}
.icon[data-icon='triangle-right']::after {
  content : '\25b6';
}

https://jsfiddle.net/wm5jqhwp/


(En ja; die iconen als <i> element is bewust. Het <i> element is in HTML5 geclassificeerd als een zinsnede met een afwijkende semantische betekenis ten opzichte van normaal taalgebruik. En dat is precies wat hier het geval is.)

[ Voor 5% gewijzigd door R4gnax op 25-09-2017 22:27 ]

[Bosmonster]

R4gnax schreef op maandag 25 september 2017 @ 22:24:
[...]

Wat is hier precies het voordeel van ten opzichte van gewoon een classname gebruiken? Want feitelijk is dit gewoon wat je doet, extra class-attributes introduceren, maar dan minder doorzichtig.

[R4gnax]

Bosmonster schreef op maandag 25 september 2017 @ 22:54:
[...]


Wat is hier precies het voordeel van ten opzichte van gewoon een classname gebruiken? Want feitelijk is dit gewoon wat je doet, extra class-attributes introduceren, maar dan minder doorzichtig.

Lees eens wat BEM is en waarom je het zou gebruiken. Deze button component volgt nl. grotendeels BEM syntax en semantiek, muv het gebruik van een aantal data-* attributen voor modifiers.

En waarom je het zo op zou zetten? Modulariteit.

Uiteraard is wat ik hier geef een heel simpel voorbeeld. In de praktijk heb je hier nog varianten bij die niet inline zijn maar de volle beschikbare breedte uitvullen (zodat ze bijv. altijd een kolom in een grid systeem uitvullen), varianten waarbij het label over meerdere lines kan lopen of afgekapt wordt met een ellipsis symbool, etc. etc.

Je hebt verschillende visuele smaakjes waarbij de zijhangsels al dan niet in een andere kleurstelling gezet zijn (maar kan ook gewoon doorlopend 'plat' zijn) en wat er dan precies in staat; maakt niet uit. Dat wordt weer door een ander component afgehandeld. In dit geval: icon, wat een font icon implementeert, maar zoals eerder gezegd: er kan bijv. ook een spinner instaan. Of een tellertje. Of ... etc. etc. Voor mijn part een kleine thumbnail met een mug-shot van een gebruiker wanneer het de knop is om naar de profielpagina te gaan v/d ingelogde gebruiker, oid.

En heb je een hyperlink die er voor design-redenen uit moet zien als een knop: ook geen probleem. Gewoon de button class er op zetten en werkt dan ook.

[ Voor 10% gewijzigd door R4gnax op 25-09-2017 23:07 ]

[Bosmonster]

Je voegt juist je eigen variant van subclasses toe, inclusief de extra specificity. Iets dat BEM juist probeert te voorkomen.

[CH4OS]

jayvol09 schreef op vrijdag 8 september 2017 @ 08:16:
Klopt. Maar dit breekt zodra er elementen bijkomen/verdwijnen/verwisslen, en dat is omdat de rule mijn manier van denken (select 'non-last' element) niet kan omvatten. Maar zo complex is het niet, een regex of een loop kan het wel aan op een manier dat niet breekt.

Je kan dan die elementen toch dáárna in de DOM zetten? En als dat niet logisch is, volgens mij is er een last child selector, zolang je die dan apart styled en in de CSS zet ná de andere styling, dan heeft de laatste altijd een aparte styling. Of je moet de selector preciezer maken. Hoe preciezer de selector, hoe meer prio het krijgt vanuit CSS. Dus het is wel degelijk mogelijk en er zijn meerdere manieren voor.

jayvol09 schreef op zondag 10 september 2017 @ 14:34:
Je hebt zeg maar 'HTML voor bots' en extra HTML dat het mooi maakt voor mensen. In mijn eerdere voorbeeld dat opgelost werd door een div was dat divje zo'n extra voor mensen (m.a.w. puur styling gerelateerd), heeft niets met de 'informatie content' te maken.

SEO-wise is het ook niet interessant om te hebben, zo'n andere HTML voor bots dan voor andere devices. Ik weet dat Google er zelfs penalties voor uitdeelt. Beste kun je daarom mobile first ontwikkelen, dan werkt het goed op zowel mobiele apparaten als desktops. Voordeel is dat searchbots / spiders dat ook begrijpen.

[ Voor 36% gewijzigd door CH4OS op 25-09-2017 23:37 ]

[Ramon]

Ik wilde hier al een tijdje nog op reageren maar durfde het topic niet omhoog te schoppen. Een theoretische discussie over HTML is onmogelijk, mijns inziens, omdat niemand theoretische websites maakt. Er zijn altijd wel dingetjes die ontworpen zijn maar die niet zo 1-2-3 in HTML of CSS te vangen zijn en iedereen heeft weer z'n eigen ideeën over wat de beste oplossing dan wel is. Daarom vind ik code en voorbeelden een goed idee!

Zo ben ik geen fan van BEM omdat het in die paar keer dat ik het heb gebruikt niet erg overzichtelijk was, de classnames te lang werden en ik te dom ben om lange classnames te onthouden.

Het voorbeeld van @R4gnax zou ik denk ik eerder alsvolgt doen:

HTML:

<button class="button button-triangle">Save and continue</button>

En dan natuurlijk de rest in CSS oplossen. Maar het ligt er puur aan denk ik hoe je het liefst werkt en ook hoe vaak/lang je met een project bezig bent. De oplossing van @R4gnax kan heel goed werken als je na verloop van tijd exact weet welke CSS er allemaal al is zodat je op gegeven moment geen CSS meer hoeft te schrijven bij het maken van een nieuwe feature.

Een en ander ligt natuurlijk óók nog aan de duur van het project waar je aan werkt. Ben je bezig met een project waar je 5 jaar met 8 collega's semi-fulltime aan werkt, dan kies je een andere oplossing dan als je met een project van 2 weken bezig bent in je eentje.

[jayvol09]

R4gnax schreef op maandag 25 september 2017 @ 22:24:
[...]


Zegt wie?
Er zijn in het verleden een aantal hoog-van-de-toren blazende radicalen geweest die claimen dat 'semantische classes' op de semantiek van de content moet slaan. Maar ook je structuur zelf kan semantiek zijn.

[...]

HTML:

<button type="button" class="button">
  <span class="button__token" data-pos="left">
    <i class="icon" data-icon="check"></i>
  </span>
  <span class="button__token" data-pos="right">
    <i class="icon" data-icon="triangle-right"></i>
  </span>
  <span class="button__text">Save and continue</span>
</button>

Dat ziet er aardig semantisch uit: ik zie geen styling html. Hooguit zou ik "data-pos" renamen naar iets dat los staat van display, zoals data-type="primary" en "secondary" i.p.v. left/right.

Het gebruik van <i> is debateerbaar. Het gebruik van attributen i.p.v. classes is debateerbaar. Maar volgens mij gaat dit niet tegen mijn eerdere stelling ("Een visuele samenhang is geen semantische connectie").

[Bosmonster]

Ramon schreef op dinsdag 26 september 2017 @ 00:19:

Zo ben ik geen fan van BEM omdat het in die paar keer dat ik het heb gebruikt niet erg overzichtelijk was, de classnames te lang werden en ik te dom ben om lange classnames te onthouden.

Het voorbeeld van @R4gnax zou ik denk ik eerder alsvolgt doen:

HTML:

<button class="button button-triangle">Save and continue</button>

Het hangt helemaal van je usecase af. Ik vond BEM ook altijd nodeloos verboos toen ik bij bureaus werkte en en tig sites per jaar ontwikkelde die meestal nauwelijks doorontwikkeld werden. En dat is prima natuurlijk, op dat moment maakte het ook niet zoveel uit.

Nu werk ik aan klantzijde met een enorme codebase en heel veel legacy en dan zie je ineens het nut van een systeem als BEM. Jouw voorbeeld heeft het probleem wat ik eerder ook al aangaf bijvoorbeeld: specificity en order relevance (de volgorde van je classes gaat er toe doen).

En trust me, in een grote codebase waar door heel veel developers continu ontwikkeld wordt heb je liever een beetje verbositeit dan die issues.

[ Voor 3% gewijzigd door Bosmonster op 26-09-2017 07:08 ]

[CH4OS]

jayvol09 schreef op dinsdag 26 september 2017 @ 05:15:
Het gebruik van <i> is debateerbaar. Het gebruik van attributen i.p.v. classes is debateerbaar. Maar volgens mij gaat dit niet tegen mijn eerdere stelling ("Een visuele samenhang is geen semantische connectie").

De i-tag wordt tegenwoordig meestal gebruikt icm bepaalde icoonfontjes. Sommigen hebben dat glashard op de i-tag staan icm een class, andere lettertypes zijn daar wat soepeler in. Is dus gewoon "goed" gebruik.

Misschien is het naar jouw mening niet (geheel) semantisch, maar daar wordt door velen anders over gedacht en naar gehandeld. Echt debateerbaar is het daardoor niet, aangezien in sommige gevallen de icon-fonts dan totaal niet werken.

[ Voor 18% gewijzigd door CH4OS op 26-09-2017 18:25 ]

[Compizfox]

jayvol09 schreef op zondag 10 september 2017 @ 14:34:
Je hebt zeg maar 'HTML voor bots' en extra HTML dat het mooi maakt voor mensen. In mijn eerdere voorbeeld dat opgelost werd door een div was dat divje zo'n extra voor mensen (m.a.w. puur styling gerelateerd), heeft niets met de 'informatie content' te maken.

Misschien begrijp ik je verkeerd maar ik denk niet dat dat de correcte opvatting is.

Je hebt niet "HTML voor bots en HTML dat het mooi maakt voor mensen". HTML zou eenduidig de content/structuur moeten definiëren, en dan wel op een semantische manier. Dat laatste zorgt er inderdaad voor dat het leesbaar is voor bots, maar dat is niet het enige doel. Semantische HTML is de enige "soort HTML" die je zou moeten nastreven. Het is dus niet dat je het moet beschouwen als "twee versies" (één voor bots en één voor mensen) oid.

Styling, m.a.w. om het mooi te maken, doe je met CSS. En ja, daar heb je her en der classes voor nodig in je HTML, maar daar is niets mis mee.

EDIT:

Ik heb wat verder gelezen en begrijp denk ik beter wat je bedoelt. Semantische HTML was je al mee bekend dus.

Als ik het goed begrijp zit het je dwars dat je in HTML soms semantiekloze elementen, zoals <div> en <span>, hebt. Sure, deze elementen hebben geen semantische betekenis op zichzelf, maar het is niet correct om te zeggen dat dit "styling in HTML" of "niet-schone HTML" is. Deze elementen gebruik je nog steeds om structuur aan je pagina te geven. En daar is niks mis mee, daar is HTML voor bedoeld! Zolang je de daadwerkelijke styling maar in de CSS laat

Ik heb trouwens zelf nog nooit het probleem gehad dat ik niet genoeg had aan CSS selectors. Er bestaan een hele hoop selectors tegenwoordig en het is vaker mogelijk dan je denkt om elementen 'slim' te selecteren in plaats van dat je ze een class/id te geeft. Als je gekke dingen wilt doen zoals het één-na-laatste element anders stylen daar heb je daar bijvoorbeeld gewoon de :nth-last-child() selector voor.

Ik snap dan ook nog steeds niet in welke gevallen je JS zou willen gebruik voor styling (gadverdamme ) en hoe/waarom.

[ Voor 37% gewijzigd door Compizfox op 27-09-2017 02:20 ]

[jayvol09]

CH4OS schreef op dinsdag 26 september 2017 @ 18:14:
[...]
De i-tag wordt tegenwoordig meestal gebruikt icm bepaalde icoonfontjes. Sommigen hebben dat glashard op de i-tag staan icm een class, andere lettertypes zijn daar wat soepeler in. Is dus gewoon "goed" gebruik.

Misschien is het naar jouw mening niet (geheel) semantisch, maar daar wordt door velen anders over gedacht en naar gehandeld. Echt debateerbaar is het daardoor niet, aangezien in sommige gevallen de icon-fonts dan totaal niet werken.

Het feit dat het zonder die tag vaak niet werkt is idd niet debateerbaar, dat maakt het geen juiste implementatie van <i>. Je kan spreken van een "de facto standard" dat parallel loopt met de officiele van W3. Als genoeg mensen tags ietsje anders gebruiken, maar wel logisch en consistent zijn, dan zie ik er niet veel kwaads in.

Ik geloof dat <i> populair werd door frameworks zoals bootstrap die het kozen om minder bandbreedte te gebruiken (1 character). But don't quote me on that.

Compizfox schreef op woensdag 27 september 2017 @ 01:49:
[...]

Misschien begrijp ik je verkeerd maar ik denk niet dat dat de correcte opvatting is.

Je begrijpt me verkeerd. Ik merk dat sommige mensen moeite met het dit concept hebben, het is ook niet geheel intuitief. Ik raad je aan om m'n eerdere posts voorzichtig te lezen, zonder vooroordelen over hoe je denkt dat het web de concepten 'styling' vs 'content' scheidt. Hint: in de praktijk is dit niet HTML vs CSS.

Je hebt niet "HTML voor bots en HTML dat het mooi maakt voor mensen". HTML zou eenduidig de content/structuur moeten definiëren, en dan wel op een semantische manier. Dat laatste zorgt er inderdaad voor dat het leesbaar is voor bots, maar dat is niet het enige doel. Semantische HTML is de enige "soort HTML" die je zou moeten nastreven. Het is dus niet dat je het moet beschouwen als "twee versies" (één voor bots en één voor mensen) oid.

Mee eens. Het was misschien onhandig verwoord, ik bedoelde meer:HTML dat voor bots interessant is, maar dus niet per se voor bots gemaakt is. Ik denk niet alleen aan dataminers en audioreaders, maar ook (hypothetisch) aan browsers die een slimme custom style op elke site kunnen toepassen.

[...]

Als ik het goed begrijp zit het je dwars dat je in HTML soms semantiekloze elementen, zoals <div> en <span>, hebt.

Bijna, maar nee. divs en spans zijn niet per definitie asemantisch. Elk element kan asemantisch zijn. Maar in de praktijk worden divs en spans het vaakst gebruikt voor extra styling manipulaties zonder semantische waarde. Dit is waar veel mensen hier me een beetje vreemd aankijken, omdat het zo abstract is. We kunnen ons nauwlijks een mooie website voorstellen waar we enkel semantische HTML hebben. Het is misschien niet belangrijk voor de gemiddelde dev. Maar puuristen, engineers en commitees voor web-standaard ontwikkelingen houden zich er wel mee bezig.

Sure, deze elementen hebben geen semantische betekenis op zichzelf, maar het is niet correct om te zeggen dat dit "styling in HTML" of "niet-schone HTML" is. Deze elementen gebruik je nog steeds om structuur aan je pagina te geven. En daar is niks mis mee, daar is HTML voor bedoeld!

Mee eens.

Zolang je de daadwerkelijke styling maar in de CSS laat

Praktisch onmogelijk. Zie mijn eerdere verwijzing naar css != styling. Vaak is CSS pakweg 80% v/d styling.

Ik heb trouwens zelf nog nooit het probleem gehad dat ik niet genoeg had aan CSS selectors. Er bestaan een hele hoop selectors tegenwoordig en het is vaker mogelijk dan je denkt om elementen 'slim' te selecteren in plaats van dat je ze een class/id te geeft. Als je gekke dingen wilt doen zoals het één-na-laatste element anders stylen daar heb je daar bijvoorbeeld gewoon de :nth-last-child() selector voor.

Ik snap dan ook nog steeds niet in welke gevallen je JS zou willen gebruik voor styling (gadverdamme ) en hoe/waarom.

Ik kan ook alles selecteren met classes/id, maar soms schaalt het gewoon zo lomp en word je html zo verboos. Als dan een enkele regel JS alles wat je wil kan selecteren op een schaalbare manier zonder classes/ids, tja dat lijkt op het oog beter --als je geen rekening houdt met daadwerkelijke performance/toegankelijkheid.

En wat als je een image wilt schalen op een niet-lineare manier voor een heleboel schermformaten? CSS is daar nog niet denk ik.

[ Voor 62% gewijzigd door jayvol09 op 27-09-2017 11:10 ]

[CH4OS]

jayvol09 schreef op woensdag 27 september 2017 @ 10:32:
Het feit dat het zonder die tag vaak niet werkt is idd niet debateerbaar, dat maakt het geen juiste implementatie van <i>. Je kan spreken van een "de facto standard" dat parallel loopt met de officiele van W3. Als genoeg mensen tags ietsje anders gebruiken, maar wel logisch en consistent zijn, dan zie ik er niet veel kwaads in.

Tja, al was het in jouw ogen wel iets kwaads, wat zou je dan er aan kunnen/willen doen? Als het blijkbaar gebruikelijk is (geworden) om de i-tag te gebruiken voor dit soort zaken? Wellicht niet (100%) semantisch, maar komt wel het dichtste bij denk ik, aangezien de font-tag 'not supported' is in HTML5, maar ook niet semantisch zou zijn als het wel zo was. Maar dat is een andere discussie. Meer info over het gebruik van de i-tag voor icons, kun je terugvinden op StackOverflow.

[ Voor 15% gewijzigd door CH4OS op 27-09-2017 11:04 ]

[Compizfox]

jayvol09 schreef op woensdag 27 september 2017 @ 10:32:
[...]
Je begrijpt me verkeerd. Ik merk dat sommige mensen moeite met het dit concept hebben, het is ook niet geheel intuitief. Ik raad je aan om m'n eerdere posts voorzichtig te lezen, zonder vooroordelen over hoe je denkt dat het web de concepten 'styling' vs 'content' scheidt. Hint: in de praktijk is dit niet HTML vs CSS.

Eh, sorry, hier ben ik je kwijt. Dat is het toch wel? Wat versta jij dan onder "styling"?

[...]
Bijna, maar nee. divs en spans zijn niet per definitie asemantisch.

Jawel, een <div> en een <span> zijn respectievelijk het generieke block en inline element. Generiek betekent hier dat er geen inherente semantische betekenis aan hangt, zoals bijvoorbeeld wel het geval is met <nav>, <p>, of <em>.

[...]
Praktisch onmogelijk. Zie mijn eerdere verwijzing naar css != styling. Vaak is CSS pakweg 80% v/d styling.

Als je styling nog ergens anders doet naast CSS, dan doe je het verkeerd.

Op welke dingen doel je dan met die andere 20%? Versta jij dan misschien iets anders onder styling dan ik? Om maar wat te noemen, in HTML elementen in <div>s wrappen zodat je ze met CSS kunt stylen, is zelf geen styling. Dat is structuur toevoegen aan je content. Noch is het geven van classes aan je elementen styling; dat zijn is slechts je verbindingsstuk tussen HTML en CSS (of JS).

[...]
Ik kan ook alles selecteren met classes/id, maar soms schaalt het gewoon zo lomp en word je html zo verboos. Als dan een enkele regel JS alles wat je wil kan selecteren op een schaalbare manier zonder classes/ids, tja dat lijkt op het oog beter --als je geen rekening houdt met daadwerkelijke performance/toegankelijkheid.

Ik kan me eerlijk gezegd nog steeds geen situatie inbeelden waar dat speelt.

Ik vind het ook opvallend dat je zo enorm geobsedeerd bent met semantische HTML (en daar is op zich niks mis mee!), maar dat je er geen problemen mee lijkt te hebben om zoiets smerigs te doen als styling in JS.

JS hoor je alleen te gebruiken als het niet anders kan; dat betekent dat je het alleen hoort te gebruiken om client-side business logic aan je pagina toe te voegen; interactiviteit dus. Maar als er een (even goed werkend) alternatief is dat met puur HTML/CSS kan, dan is dat altijd beter.

En wat als je een image wilt schalen op een niet-lineare manier voor een heleboel schermformaten? CSS is daar nog niet denk ik.

Wat bedoel je met "op een niet-lineaire manier"?

Als het je gaat om het goed schalen van een background-image (bijv. een header) op verschillende schermformaten, dan kan background-size: cover; heel handig zijn. En met transform kun je bijna alles wat ze zou kunnen willen met een image. Wil je compleet verschillende CSS rules afhankelijk van de viewport? Haal je hart op aan media queries.

[ Voor 3% gewijzigd door Compizfox op 27-09-2017 14:49 ]

[jayvol09]

Compizfox schreef op woensdag 27 september 2017 @ 14:41:
[...]

Eh, sorry, hier ben ik je kwijt. Dat is het toch wel? Wat versta jij dan onder "styling"?

[...]
Als je styling nog ergens anders doet naast CSS, dan doe je het verkeerd.
[...]
Op welke dingen doel je dan met die andere 20%? Versta jij dan misschien iets anders onder styling dan ik?

Ja, zo te zien heb je m'n vorige posts niet gelezen. Ik heb deze discussie (2 keer?) gehad, maar vooruit nog een keertje dan. De content informatie van een site is abstract en heeft geen specifieke vorm, de "structuur" bestaat uit relaties tussen elementen (via element type, parent/child relaties, en classes). Deze structuur bepaalt *niet* hoe iets er uit moet zien, het is een semantische structuur.

Styling is alles wat je doet om een website een consumeerbare vorm te geven voor mensen. In de praktijk is dit meestal de content op een beeldscherm renderen. Vaak kun je de structuur afleiden uit de visuele representatie, maar dit is geen vereiste, dus is 'visuele structuur' hooguit slechts *gecorreleerd* met de semantische structuur.

Om maar wat te noemen, in HTML elementen in <div>s wrappen zodat je ze met CSS kunt stylen, is zelf geen styling. Dat is structuur toevoegen aan je content.

Dat is dus styling HTML. Maar vergelijk: als je elementen in een semantische div wrapt kun je ze ook CSSen, en dát is dan geen styling HTML. Bij de een gebruik je HTML om iets visueel mooier te maken, bij de ander gebruik je HTML om meer informatie te communiceren, met als gratis bonus dat je CSS een extra handvat heeft.

Als jij aan de zijkant van je site een mooie regenboog wil maken met divs, gewoon voor de leuk, dan is dat styling en zijn die divs niet semantisch bezig. Als je twee plaatjes wil scheiden door er een blanke div tussen te gooien, dan is die div een styling element. Maar die twee plaatjes en div kunnen in een parent div zitten die wel semantisch is.

Noch is het geven van classes aan je elementen styling; dat zijn is slechts je verbindingsstuk tussen HTML en CSS (of JS).

Half mee eens. Je hebt semantische classes zoals "icon" en styling classes zoals "blue". Soms word er te snel gegrepen naar een makkelijke styling naam i.p.v. een content-logische naam.

Jawel, een <div> en een <span> zijn respectievelijk het generieke block en inline element. Generiek betekent hier dat er geen inherente semantische betekenis aan hangt, zoals bijvoorbeeld wel het geval is met <nav>, <p>, of <em>.

Nee, generiek betekent niet "geen betekenis" het betekent "een hele vage betekenis". Het is een opvangnet voor elementen die geen specifiekere optie in HTML hebben. Dat per se maakt dvis/spans niet 'void of meaning'. Maar je kan net zo goed stylen met een <p> of <h4>, dan zijn die ook niet semantisch. Bij conventie worden de 'minst schadelijke' elementen (divs/spans en kennelijk <i>) gebruikt voor styling.

Ik vind het ook opvallend dat je zo enorm geobsedeerd bent met semantische HTML (en daar is op zich niks mis mee!), maar dat je er geen problemen mee lijkt te hebben om zoiets smerigs te doen als styling in JS.

JS hoor je alleen te gebruiken als het niet anders kan; dat betekent dat je het alleen hoort te gebruiken om client-side business logic aan je pagina toe te voegen; interactiviteit dus. Maar als er een (even goed werkend) alternatief is dat met puur HTML/CSS kan, dan is dat altijd beter.

Nee hoor, zoals eerder aangegeven is m'n voorkeur slechts een klein beetje biased naar JS. Maar als ik "geen problemen" ermee zou hebben zou de topic titel er anders uit zien. Je zegt "altijd beter" maar dat is nogal ongenuanceerd en geeft de indruk dat je niet creatief over mogelijke scenarios denkt.

Wat bedoel je met "op een niet-lineaire manier"?

Als het je gaat om het goed schalen van een background-image (bijv. een header) op verschillende schermformaten, dan kan background-size: cover; heel handig zijn. En met transform kun je bijna alles wat ze zou kunnen willen met een image. Wil je compleet verschillende CSS rules afhankelijk van de viewport? Haal je hart op aan media queries.

Ja die opties ken ik. Linear is dus als m'n scherm 2x breder wordt dat een element ook visueel 2x breder wordt. Ditto voor hoogte. Niet-linear is dus alles behalve dat (misschien sinusoidaal ofzo).

[R4gnax]

perpixel schreef op donderdag 14 september 2017 @ 12:31:
Nee de parent selector bestaat niet vanwege het originele ontwerp principe van CSS (cascading style sheets).

CSS heeft geen manier om parent elementen te selecteren omdat dat tot oneindige evaluatie-cycles kan leiden. Het probleem is dat selectors die terug uit lopen zaken kunnen aanpassen waardoor ze zelf niet meer van toepassing zouden zijn. Het kan een grandfather paradox veroorzaken.

In de Selectors Level 4 specificatie bestaat er wel een manier om parent selectors te implementeren. Dit doe je middels de subject selector. Om bijv. alle geordende lijsten te selecteren die uit tenminste 4 items bestaan, gebruik je de selector "!ol > li:nth-child(4)".

Maar om voorgaand beschreven probleem te voorkomen wordt dit type selector alleen in het zgn. complete profile ondersteund: het selector-profiel / ondersteuningsniveau wat door de DOM querySelector en querySelectorAll methodes gebruikt wordt. Het wordt expliciet niet door het dynamic profile / fast profile ondersteund waar CSS gebruik van maakt.

jayvol09 schreef op donderdag 28 september 2017 @ 05:34:

Nee, generiek betekent niet "geen betekenis" het betekent "een hele vage betekenis". Het is een opvangnet voor elementen die geen specifiekere optie in HTML hebben. Dat per se maakt dvis/spans niet 'void of meaning'.

Het feit dat de HTML5 Technical Recommendation expliciet zegt dat div elementen geen semantische betekenis hebben, maakt dat echter wel:

De HTML5 Technical Recommendation schrijft in 4.4.13 Grouping Content - The div element:
The div element has no special meaning at all.

[Compizfox]

jayvol09 schreef op donderdag 28 september 2017 @ 05:34:
[...]

Dat is dus styling HTML. Maar vergelijk: als je elementen in een semantische div wrapt kun je ze ook CSSen, en dát is dan geen styling HTML. Bij de een gebruik je HTML om iets visueel mooier te maken, bij de ander gebruik je HTML om meer informatie te communiceren, met als gratis bonus dat je CSS een extra handvat heeft.

Als jij aan de zijkant van je site een mooie regenboog wil maken met divs, gewoon voor de leuk, dan is dat styling en zijn die divs niet semantisch bezig. Als je twee plaatjes wil scheiden door er een blanke div tussen te gooien, dan is die div een styling element. Maar die twee plaatjes en div kunnen in een parent div zitten die wel semantisch is.

OK, dat vermoedde ik al: jij hebt een andere definitie van "styling" dan ik. Wat mij betreft is dat geen "styling HTML"; "styling HTML" bestaat helemaal niet tenzij je het over deprecated tags en attributes zoals <font>, color, of align hebt. Dát is styling in HTML, en dat doen we tegenwoordig met CSS.

Je hebt gelijk dat je HTML kunt schrijven op zo'n manier dat het niet representatief is voor de content/structuur (en dat is natuurlijk niet goed), maar dat is alsnog geen styling in HTML. Misschien wel HTML voor styling, maar dat is iets anders; de styling zelf doe je alsnog met CSS.

[...]
Half mee eens. Je hebt semantische classes zoals "icon" en styling classes zoals "blue". Soms word er te snel gegrepen naar een makkelijke styling naam i.p.v. een content-logische naam.

OK, eens. Een class "blue" noemen is niet heel netjes.

[...]
Nee, generiek betekent niet "geen betekenis" het betekent "een hele vage betekenis". Het is een opvangnet voor elementen die geen specifiekere optie in HTML hebben. Dat per se maakt dvis/spans niet 'void of meaning'. Maar je kan net zo goed stylen met een <p> of <h4>, dan zijn die ook niet semantisch. Bij conventie worden de 'minst schadelijke' elementen (divs/spans en kennelijk <i>) gebruikt voor styling.

Wat @R4gnax zegt: deze tags hebben geen inherente semantische betekenis, per definitie. Daarom worden ze inderdaad zoals je correct uitlegt gebruikt als er geen specifiek element bestaat voor wat je nodig hebt.

[...]
Ja die opties ken ik. Linear is dus als m'n scherm 2x breder wordt dat een element ook visueel 2x breder wordt. Ditto voor hoogte. Niet-linear is dus alles behalve dat (misschien sinusoidaal ofzo).

OK, ik zou niet weten in welke situatie je dat nodig zou hebben, maar met transform en calc() moet je een heel eind kunnen komen. Zover ik kon vinden ondersteunt calc() geen trigonometrische functies, maar ik heb wel een voorbeeld gevonden van iemand die die d.m.v. Taylorreeksen benaderd heeft

[jayvol09]

R4gnax schreef op donderdag 28 september 2017 @ 22:52:

Het feit dat de HTML5 Technical Recommendation expliciet zegt dat div elementen geen semantische betekenis hebben, maakt dat echter wel:

"The div element has no special meaning at all." is in engels niet hetzelfde als "The div element has no meaning at all". In het laatste geval zou een div per definitie nooit semantisch kunnen zijn, ik denk dat je nergens een dev zal vinden die het daar mee eens is. Maar volgens mij twisten we over niets.

Compizfox schreef op donderdag 28 september 2017 @ 23:15:

Je hebt gelijk dat je HTML kunt schrijven op zo'n manier dat het niet representatief is voor de content/structuur (en dat is natuurlijk niet goed), maar dat is alsnog geen styling in HTML. Misschien wel HTML voor styling, maar dat is iets anders; de styling zelf doe je alsnog met CSS.

Opzich kan iedereen z'n eigen definitie van 'styling' gebruiken, zolang iedereen maar weet wat je bedoelt. Maar ik denk als jij een discussie van ingenieurs van de W3 of een presentatie van Tim Berners-Lee probeert te volgen, dat je mijn bredere definitie van styling moet nemen, daar is CSS slechts een deel van alle styling. Of als iemand een topic als deze opent

[incaz]

jayvol09 schreef op donderdag 28 september 2017 @ 05:34:
Nee hoor, zoals eerder aangegeven is m'n voorkeur slechts een klein beetje biased naar JS. Maar als ik "geen problemen" ermee zou hebben zou de topic titel er anders uit zien. Je zegt "altijd beter" maar dat is nogal ongenuanceerd en geeft de indruk dat je niet creatief over mogelijke scenarios denkt.

Wil ik toch even op inhaken: ja, waar het kan is CSS is altijd beter dan JS om een aantal redenen:
1. JS zet CSS-properties. Je bent dus hoe dan ook bezig met CSS, en zult je hoe dan ook moeten verdiepen in de eigenaardigheden daarvan
2. CSS geeft je een boel mogelijkheden tot automatische layout (bijvoorbeeld bij resizen window) die je niet zomaar krijgt bij JS. Denk hierbij aan mediaqueries die je anders met de hand moet berekenen, of pseudoclasses.
3. Je JS kan over het algemeen pas aan de gang on DOM_Ready. CSS kan redelijk meteen worden toegepast tijdens het opbouwen van de DOM. Dat geeft met JS dus een wachttijd voor de zaken gestyled kunnen worden.
4. Javascript-engines kappen ermee als ze een fout tegenkomen. HTML en CSS vangen fouten meestal op door dat specifieke deel te negeren, zonder dat de hele pagina onbruikbaar wordt. Wat samenhangt met
5. webcommunicatie is inherent onbetrouwbaar. Hoewel het meestal goed gaat, krijgen gebruikers toch met enige regelmaat incomplete bestanden. Cachebestanden raken corrupt. Beide zeker op mobieltjes.

Die laatste twee punten zijn niet alleen theoretisch, maar ook echt regelmatig in de praktijk aan de orde: met regelmaat geven gebruikers aan dat er iets niet werkt van de javascript. Falende CSS komt ook voor en ook dat wordt meestal gemeld, maar is echt veel minder vaak een probleem.

Wat mij betreft dus progressive enhancement: niet alleen vanuit een mooie ideologie maar ook omdat de werkelijkheid gewoon vaak genoeg dwars ligt en het erg fijn is als je dan nog een redelijke basis hebt, waardoor je de problemen misschien niet eens nodig hebt. (Voorbeeldje, als ik bij 'Mijn topics' kijk dan kijk ik daar vooral naar de bovenste... 10? Vaak nog minder. Als de rest van de pagina niet laadt, so be it.)

Die afweging kan wellicht anders zijn bij specieke webapps waarbij het juist wenselijk is dat het niet werkt als er ook maar iets niet volledig geladen is. (Al denk ik dat je dan misschien beter af bent in een native app?)

Nog een overweging waarbij ik de uitkomst niet weet: wat kost het minste rekenkracht. CPU-gebruik is zeker bij mobiele devices iets om rekening mee te houden. Alleen weet ik niet of CSS daarin structureel beter presteert, dat is meer iets om uit te zoeken. En als CSS daarin veel slechter presteert dan JS, kan dat een overweging zijn. Nou ben ik daar niet heel erg precies in (ik gebruik child selectors), maar er zijn sites waarbij je de hitte van de CPU gewoon voelt en dat gaat me te ver.

[R4gnax]

jayvol09 schreef op vrijdag 29 september 2017 @ 04:20:
"The div element has no special meaning at all." is in engels niet hetzelfde als "The div element has no meaning at all". In het laatste geval zou een div per definitie nooit semantisch kunnen zijn, ik denk dat je nergens een dev zal vinden die het daar mee eens is. Maar volgens mij twisten we over niets.

Nergens een dev die het daarmee eens is? Ik denk dat jij van een hele koude kermis thuis zou komen, vriend...
Ik ken er minstens 30 persoonlijk; alle mensen waarmee ik samen werk en heb gewerkt, en daarnaast een hele slee internetpersoonlijkheden die op het gebied van HTML en CSS gerenomeerde blogs houden.

[ Voor 9% gewijzigd door R4gnax op 29-09-2017 21:38 ]

[wannesdebacker]

jayvol09 schreef op donderdag 7 september 2017 @ 14:59:
Ik ben relatief nieuw in de webtech wereld en heb het een-en-ander geleerd over H/C/J. Maar nu merk ik dat er dingen zijn die gewoon niet mogelijk zijn in CSS qua layout, en dat vroeger vooral men greep naar HTML hacks zoals <table> of <div> wrappers om een layout werkend te krijgen. Ik heb al vrij snel een gevoel van afstoting gekregen: HTML moet schoon blijven.

Een andere optie in JS. Nu sta ik voor de keuze om deels CSS en deels JS te doen, of vol in te gaan op JS (+ JQuery, react, etc.) en dat gebrekkige CSS achterwege te laten. Wat doen jullie nu, en waarom?

Voorbeelden waar ik tegen aan loop:
- Onmogelijk om bepaalde elementen te selecteren in CSS zonder een class/ID eraan te hangen.
- Onmogelijk om bepaalde elementen responsief te schalen t.o.v. van andere elementen. Er is teveel logica nodig die niet kan worden beschreven met bestaande CSS.

Een enkel goed argument dat ik gehoord heb is dat JS nog te langzaam is op mobile. Maar ja, 5G komt eraan en nu heeft chrome JS modules (caching enzo). Ben benieuwd naar jullie denkprocess.

Beste ts

Leuk dat je je wil verdiepen in web-development. Je lijkt wel niet echt te snappen hoe het web werkt, maar dit is perfect oke als dummy. We zijn immers allemaal moeten beginnen.

Als ik je code echter bekijk zou ik eerst nog een cursus HTML en CSS doen, want dit is gewoon fout. Je lijkt niet helemaal te begrijpen wat het nut is van elke taal en wat er allemaal mogelijk is. Probeer niet te snel direct naar de libraries te springen.

Het is een extreem slecht idee om styling-logica in javascript te zetten. Je moet net zo weinig mogelijk in javascript doen. 90% van alles wat je ooit wil maken kan perfect zonder Javascript.

Bovendien zou ik als ik jou was gewoon eerst heel goed javascript leren schrijven voor te beginnen om je te 'specialiseren' in libraries zoals React of zelfs jQuery (jQuery kan wel springplank zijn).
Libraries veranderen immers constant en voor hetzelfde geld horen we volgend jaar niets meer van React (React is een goed idee, maar is nog niet klaar voor echt projecten in een productie-omgeving, JS-libraries = wilde westen (natuurlijk wordt dit al op grote schaal gebruikt binnen bedrijven maar dit lijkt me meer een keuze voor een hippe technologie tov een goed schaalbaar product waar je binnen een paar jaar geen spijt van de technologiekeuze hebt)).

Wat nadelen van alles in Javascript te willen doen.

- Gebruikers zonder JS (zoals ik) of binnen bedrijven waar JS wordt geblockt is zullen op je site niets zien (maakt niet uit dat het een minderheid is, je maakt nu eenmaal producten voor 100% van je gebruikers) en meer en meer mensen zetten hun JS uit.
- Trager, flashes of ugly content
- Single point of failure
- CSS is heel sterk in styling, en CSS en JS kunnen goed samenwerken (door het zetten van classes o.a.)
- ...

Ik zou zeggen: blijf je door-ontwikkelen als Web-developer, maar begin eerst met de basis. En durf ook raad van andere (ervaren) web-developers volgen. Neem zeker niet alles over wat je online (op stackoverflow bijvoorbeeld) aan, daar staat een hoop rommelcode op, zeker op web-vlak.

Als ik je commentaar lees ben je ook best arrogant tegen mensen die je proberen helpen, terwijl zij vaak heel goede punten bovenbrengen. Let hier wat op.

[Harrie_]

wannesdebacker schreef op dinsdag 3 oktober 2017 @ 13:57:
[...]
Wat nadelen van alles in Javascript te willen doen.
- Gebruikers zonder JS (zoals ik) of binnen bedrijven waar JS wordt geblockt is zullen op je site niets zien (maakt niet uit dat het een minderheid is, je maakt nu eenmaal producten voor 100% van je gebruikers) en meer en meer mensen zetten hun JS uit.

Eens met @wannesdebacker m.u.v. bovenstaande quote.

Anno 2017 hoort JS gewoon bij de standaard toolkit (HTML/CSS/JS). Het is inderdaad geen goed idee om 30 JS-libraries te gaan gebruiken maar om nou helemaal vrij te sturen van JS lijkt me ook niet echt de oplossing.

'Vroeger' was het inderdaad bij JS standaard-advies om hiermee op te passen omdat het weleens uit kon staan bij de client, maar dat is wel heel erg achterhaald. Als je tegenwoordig het web op wilt zonder JS dan blijven er nog maar weinig sites over die je normaal kunt viewen/gebruiken....

[Caelorum]

Harrie_ schreef op woensdag 4 oktober 2017 @ 13:32:
[...]
Eens met @wannesdebacker m.u.v. bovenstaande quote.

Anno 2017 hoort JS gewoon bij de standaard toolkit (HTML/CSS/JS). Het is inderdaad geen goed idee om 30 JS-libraries te gaan gebruiken maar om nou helemaal vrij te sturen van JS lijkt me ook niet echt de oplossing. [...]

Sturen op een javascriptloze pagina is zeker wel goed. Dat het niet gaat lukken is niet erg, maar zo min mogelijk javascript is gewoon common-sense. Vaak gaat het er ook gewoon beter van performen.

[Ramon]

@Caelorum Er zijn anders tegenwoordig hele volksstammen developers die React of gelijkwaardige javascript frameworks gebruiken en daarmee dus een afhankelijkheid van javascript introduceren. Waarmee ik maar wil zeggen dat de regels niet vast liggen en dat iedereen z'n eigen keuzes maakt op basis van zijn eigen variabelen en daarom is een theoretische discussie over html nogal nutteloos is wat mij betreft.

[Caelorum]

@Ramon nergens zeg ik niet doen, maar doe het zo min mogelijk. JavaScript engines zijn stukken sneller geworden, maar dan nog is niet js gebruiken sneller. Als jij een super fancy applicatie maakt in de browser dan leef je uit op react oid, maar als je een website maakt voor de bakker heb je het echt bijna niet nodig. En toch zie je ook bij die websites dat soms alles in elkaar is gehacked met js.

[Verwijderd]

ik heb dit topic gelezen en heb het gevoel dat ik terug moet komen op de topic start:

in html5 heb je sections, deze moet je 1 of meerdere classes geven.
in sections kan je het simpel houden (een sectie bestaat bijvoorbeeld uit een titel en een paragraaf en een lijst)

in CSS moet je selecteren om te stijlen:

Cascading Stylesheet:

section.class1.class2 p {
}

(dit selecteerd de paragraph uit section)

in js moet je selecteren om te triggerren:

JavaScript:

$.select('section.class.class2 p').on('load', function(){});

Dit kan natuurlijk ook op id basis. zonder id, of zonder class kom je er gewoon niet in een groot document. Geef het beestje een naam of id indien nodig.

als je dan met jezelf afspreekt dat sections classes gebruikt voor css en element classes voor js kom je een heel eind en gebruik het style attribuut van een element alleen via js. Wat jij wil (ts) is textnodes selecteren in een dom document. geeft het een tagname is de algemene regel om er css aan te hangen, z werkt het nu eenmaal.

[Verwijderd]

Ramon schreef op woensdag 4 oktober 2017 @ 21:36:
@Caelorum Er zijn anders tegenwoordig hele volksstammen developers die React of gelijkwaardige javascript frameworks gebruiken en daarmee dus een afhankelijkheid van javascript introduceren. Waarmee ik maar wil zeggen dat de regels niet vast liggen en dat iedereen z'n eigen keuzes maakt op basis van zijn eigen variabelen en daarom is een theoretische discussie over html nogal nutteloos is wat mij betreft.

Anno 2017 is js echt wel veilig, het enige wat kan gebeuren is dat de browser vast loopt of crashed. ja je kan er coins mee minen, maar of dat de reden moet zijn om anno 2017 javascript onafhankelijk te maken van browsen, elke moderne browser ondersteund het standaard. je moet er moeite voor doen om het uit te schakelen. je moet je goed afvragen wat je doelgroep is en daar kun je veel beter de moeite in stoppen dan de uitzonderingen < 3 %

[Harrie_]

Caelorum schreef op woensdag 4 oktober 2017 @ 21:25:
Sturen op een javascriptloze pagina is zeker wel goed. Dat het niet gaat lukken is niet erg, maar zo min mogelijk javascript is gewoon common-sense. Vaak gaat het er ook gewoon beter van performen.

Caelorum schreef op woensdag 4 oktober 2017 @ 21:45:
@Ramon nergens zeg ik niet doen, maar doe het zo min mogelijk. JavaScript engines zijn stukken sneller geworden, maar dan nog is niet js gebruiken sneller. Als jij een super fancy applicatie maakt in de browser dan leef je uit op react oid, maar als je een website maakt voor de bakker heb je het echt bijna niet nodig. En toch zie je ook bij die websites dat soms alles in elkaar is gehacked met js.

Daar heb je helemaal gelijk in. Ik was wellicht ook niet helemaal duidelijk maar met deze zinsnede

Harrie_ schreef op woensdag 4 oktober 2017 @ 13:32: Het is inderdaad geen goed idee om 30 JS-libraries te gaan gebruiken maar om nou helemaal vrij te sturen van JS lijkt me ook niet echt de oplossing.

impliciet te zeggen dat een pagina bestaat uit HTML + CSS en waar nodig / functionieel je dus JS kunt gebruiken. Bij een website voor de bakker is dat inderdaad wellicht 1 scriptje om een image scroller in de header te tonen...

[Harrie_]

Verwijderd schreef op woensdag 4 oktober 2017 @ 22:45:

in js moet je selecteren om te triggerren:

JavaScript:

$.select('section.class.class2 p').on('load', function(){});

No offense maar je begint met 'in JS' en vervolgens plak je er wat jQuery neer. Ik vind het persoonlijk erg vervelend dat die twee tegenwoordig door elkaar gebruikt worden en dat zoeken naar "howto ... in JS" steeds vaker jQuery-resultaten oplevert...

jQuery != JS

[Verwijderd]

Harrie_ schreef op donderdag 5 oktober 2017 @ 17:01:
[...]


No offense maar je begint met 'in JS' en vervolgens plak je er wat jQuery neer. Ik vind het persoonlijk erg vervelend dat die twee tegenwoordig door elkaar gebruikt worden en dat zoeken naar "howto ... in JS" steeds vaker jQuery-resultaten oplevert...

jQuery != JS

dit is ook geen jquery, maar priya see github.com/like-it/ en dat is trouwens eigen gemaakte code, vind ik persoonlijk mooier dat document.queryselectorall blah blah... geef het maar een naam, zou ik zeggen, nu is die ineens mooi gemaakt ?

[Verwijderd]

Verwijderd schreef op donderdag 5 oktober 2017 @ 19:51:
dit is ook geen jquery, maar priya see github.com/like-it/ en dat is trouwens eigen gemaakte code, vind ik persoonlijk mooier dat document.queryselectorall blah blah... geef het maar een naam, zou ik zeggen, nu is die ineens mooi gemaakt ?

Ik snap echt niet wat je hier probeert te zeggen...het is een beetje onsamenhangend.

[Verwijderd]

oh, dat gaat over dit :

JavaScript:

priya.prototype.select = function(selector){
   return document.querySelectorAll(selector);
}

[jayvol09]

Verwijderd schreef op woensdag 4 oktober 2017 @ 22:45:
...

in CSS moet je selecteren om te stijlen:
...
Dit kan natuurlijk ook op id basis. zonder id, of zonder class kom je er gewoon niet in een groot document. Geef het beestje een naam of id indien nodig.

...
Wat jij wil (ts) is textnodes selecteren in een dom document. geeft het een tagname is de algemene regel om er css aan te hangen, z werkt het nu eenmaal.

Klopt, ik ben gewend aan scripten waar een 'loop' over een brede selectie tot een specifieke selectie kan leiden. Ik ben ook gewend om GUIs programatisch te schrijven dus vandaar de aantrekking voor JS. Ik heb verder niets tegen tags, maar wat zou de wereld mooi zijn als ik rules met regexes kon maken.

[Harrie_]

jayvol09 schreef op vrijdag 6 oktober 2017 @ 04:04:
[...] maar wat zou de wereld mooi zijn als ik rules met regexes kon maken.

Moeten we die quote er weer ingooien over regexes?

Verwijderd schreef op donderdag 5 oktober 2017 @ 19:51:
dit is ook geen jquery, maar priya see github.com/like-it/ en dat is trouwens eigen gemaakte code, vind ik persoonlijk mooier dat document.queryselectorall blah blah... geef het maar een naam, zou ik zeggen, nu is die ineens mooi gemaakt ?

Verwijderd schreef op donderdag 5 oktober 2017 @ 21:19:
Ik snap echt niet wat je hier probeert te zeggen...het is een beetje onsamenhangend.

Verwijderd schreef op donderdag 5 oktober 2017 @ 23:00:
oh, dat gaat over dit :

JavaScript:

priya.prototype.select = function(selector){
   return document.querySelectorAll(selector);
}

Het wordt er niet heel veel duidelijker op. Maar als ik even je verhaal extrapoleer (los van het feit dat het hier gewoon ging over 'jQuery is niet hetzelfde als JS') dan bedoel je dus te zeggen dat je kennelijk gebruik maakt van een framework maar omdat je de JS syntax niet mooi vind gooi je er nog een keer jQuery overheen. Ik heb medelijden met de dev die in de toekomst aan jouw 'legacy-code' mag gaan sleutelen.

Misschien ook deze post teruglezen en de posts van @Caelorum voorafgaand

[ Voor 76% gewijzigd door Harrie_ op 06-10-2017 10:19 ]

[Caelorum]

@Harrie_ hij heeft een js framework gemaakt dat lijkt op jQuery zonder dat waar jQuery voor is gemaakt (werking over alle gangbare browsers gelijk)

[Harrie_]

@Caelorum Ik begrijp er niet zoveel van. Als ik die git-repo's van die link bekijk dan kom ik trouwens ook nergens JS tegen.

[Caelorum]

Harrie_ schreef op vrijdag 6 oktober 2017 @ 10:20:
@Caelorum Ik begrijp er niet zoveel van. Als ik die git-repo's van die link bekijk dan kom ik trouwens ook nergens JS tegen.

https://github.com/like-i.../Priya/Priya.prototype.js maar dit gaat wel erg offtopic zo

[incaz]

jayvol09 schreef op vrijdag 6 oktober 2017 @ 04:04:
Ik ben ook gewend om GUIs programatisch te schrijven dus vandaar de aantrekking voor JS. Ik heb verder niets tegen tags, maar wat zou de wereld mooi zijn als ik rules met regexes kon maken.

Ten eerste vind ik het wel wonderlijk dat je, na je vrij bevlogen pleidooi om echt absoluut geen onnodige dingen in de html te stoppen, nu uit zou gaan van wat makkelijk voor jou is en niet wat principieel de juistere methode is.

Daarnaast ben ik benieuwd welk probleem je met regexes denkt op te lossen, want die neiging heb ik in 15 jaar websites bouwen echt nog nooit gehad (en al helemaal niet nu je de data-* attributes hebt die zowel via css als via jquery makkelijk te benaderen zijn. JS misschien ook maar omdat we JQuery al hadden ben ik daar niet veel verder in gedoken.)