[HTML] Discussie <div> .vs. <table>

'k Weet niet of de discussie lang zal blijven bestaan. Ik hoop eigenlijk van wel want ik vind ze eerlijk gezegd toch wel een interessante discussie.

Ik hou me momenteel als hobby vrij veel bezig met het ontwikkelen van websites. Om toch met de tijd mee te gaan ben ik een dik jaar geleden mij echt gaan toeleggen op symantiek, het juist gebruiken van de HTML tags enz. Maar binnenkort wil ik me meer professioneel toeleggen en begin ik met een zaakje in bijberoep. Wat ik nu heel vaak merk is dat grotere en kleinere webdev bureaus gewoon rustig blijven code met tables. Reden is vrij simpel, 't gaat gewoon een stuk sneller, 't werk 99% altijd binnen elke browser en de CSS bwa... dat valt allemaal goed mee.

'k Vraag me dan af, is het niet een beetje de taak van zo'n bureaus om nu juist het "juiste" voorbeeld te gaan geven, move-on.. de nieuwe mogelijkheden zijn er, waarom worden ze niet gebruikt, of gaat het hier echt om "als het maar werkt".

Dat is de vraag die me nu al een tijdje bezig houd, zeker omdat ik weet dat ik soms vaak redelijk wat tijd spendeer om sites cross-browser compatible te maken en dit vaak veel CSS gepruts met zich meebrengt.

Wat zijn de voor -en nadelen om als bedrijf toch te kiezen voor symantisch te coden en dus de tabel fase helemaal achter te laten en vinden eindgebruikers dit enigszins belangrijk, vermits ik weinig bedrijven ken die echt gaan kijken naar de code van hun webdevelopers.

Het probleem is dat het de markt is die hier voor een deel voor zorgt.

Mensen willen voor een dubbeltje op de eerste rang zitten en gaan dan gewoon voor de goedkoopste partij. Wat maakt het de klant uit of het in div's of tables is? Hij weet niet eens wat het is.

Enige wat ie weet is dat het eruit moet zien en moet werken zoals hij wil op alle computers.

De hele discussie is al heel vaak herhaald en er komt nooit echt een antwoord uit. Alle punten zijn uitgebreid besproken en de realiteit is dat het nu eenmaal niet is zoals het ideaal zou zijn.

Veel besproken punten:
- Door wie komt het
- Wie zou er iets aan moeten doen
- Wat zijn de nadelen
- Wat zijn de voordelen
- Microsoft is evil

Daar komt het een beetje op neer.

Persoonlijk denk ik dat je als developer vooral moet kijken naar de doelgroep van de te maken site en het beschikbare budget. Je kunt wel heel leuk alles volgens het boekje doen, maar als daarmee je marge eraan gaat zul je het als bedrijf niet zo lang volhouden.

TRRoads wijzigde dit bericht 11-09-2007 22:37 (29%)

Topic met dezelfde strekking: Semantische HTML, CSS en jij

Ik probeer zelf de laatste tijd zoveel mogelijk semantisch (niet symantisch) correct te doen, maar ik kan me best voorstellen dat bedrijven ervoor kiezen om dingen met tables op te lossen omdat het gewoon veel simpeler, hence sneller hence goedkoper is.

quote:

HyperioN. schreef op dinsdag 11 september 2007 @ 22:38:
maar ik kan me best voorstellen dat bedrijven ervoor kiezen om dingen met tables op te lossen omdat het gewoon veel simpeler, hence sneller hence goedkoper is.

Zoveel sneller zal dat wel niet zijn, althans als je tenminste kennis van zaken hebt.
Echter wat veel bedrijven niet weten is dat het onderhouden van dergelijke code vaak een hel is en juist meer tijd zal kosten.

quote:

imp4ct schreef op dinsdag 11 september 2007 @ 22:28:
Reden is vrij simpel, 't gaat gewoon een stuk sneller

Het ontwikkelen van een semantiek correcte website die is vormgegeven m.b.v. CSS vereist denk ik alleen meer kennis. Het hoeft niet beslist meer tijd en dus geld te kosten.

Tabellen is misschien een beetje eenvoudiger, maar als je CSS helemaal door hebt is dat ook heel eenvoudig.

En zoals Erkens ook vermeld is een website waarbij opmaak en content gescheiden is veel beter te onderhouden.

Volgens mij zijn tables vooral sneller en simpeler waarvoor ze bedoelt zijn, tabellen

Inderdaad, ik snap ook niet dat mensen nog steeds argumenten voor tabellen aan kunnen dragen. Voor een webdesigner die weet waar hij/zij mee bezig is, is het maken van een website voor alle browsers geen groot probleem: 1 stylesheet en soms nog een speciale voor IE. Na verloop van tijd weet je wel zo ongeveer wat daarin komt...

Tabellen geven net zo goed browserproblemen, zijn een nachtmerrie om te onderhouden en in dit geval gewoon 100% verkeerd... De discussie <table> vs. <div> is IMHO gewoon onzin dus, semantische HTML is the only way to go. Je moet wel met hele goede argumenten komen om een foute manier (tables misbruiken) goed te praten. Ik ben ze nog niet tegengekomen.

JanDM wijzigde dit bericht 11-09-2007 22:50 (20%)

Ik ben zelf ook met een website bezig. Misschien lichtelijk offtopic maar wat is netter/beter in het geval van CSS. Een aparte stylesheet voor elke browser of het zo proberen te maken dat 1 stylesheet voldoende is. Vooral dat laatste wat ik wil proberen is soms erg moeilijk en vooral erg tijdrovend, met name IE6, IE7 is gelukkig al heel wat beter.

Waarom ik in eerste instantie voor 1 CSS bestand wil gaan is dat ik straks geen 2 of meer hoef te onderhouden als ik layout wijzigingen wil maken.

Overigens zijn tabellen imho net zo lastig te maken dan wel lastiger voor een layout om in verschillende browsers te laten werken. Maar ja de mensen pro tabellen-layout (mochten die er nog zijn) hebben misschien veel ervaring om een site zo te ontwikkelen en komen weinig lastige obstakels tegen om het in orde te maken.

quote:

JanDM schreef op dinsdag 11 september 2007 @ 22:46:
Tabellen geven net zo goed browserproblemen, zijn een nachtmerrie om te onderhouden en in dit geval gewoon 100% verkeerd... De discussie <table> vs. <div> is IMHO gewoon onzin dus, semantische HTML is the only way to go. Je moet wel met hele goede argumenten komen om een foute manier (tables misbruiken) goed te praten. Ik ben ze nog niet tegengekomen.

Zelfs correct weergegeven zuigt CSS + DIVs nog steeds. Er is ook niks semantisch aan een DIV. Ontsnap ik aan de semantiekpolizei door een DIV in een DIV te nestelen waarin ik een aantal DIVs nestel die weer een paar DIVs bevatten? En dat ik ze dan met kreten als display:table-row alsnog ombouw tot elementen die mijn pagina vormgeven op de manier zoals ik dat wil?

Oh nee, iemand is vergeten om die optie in te bouwen in de browser die 85% van de Nederlanders gebruikt

BikkelZ wijzigde dit bericht 11-09-2007 23:21 (6%)

quote:

BikkelZ schreef op dinsdag 11 september 2007 @ 23:19:
[...]


Zelfs correct weergegeven zuigt CSS + DIVs nog steeds. Er is ook niks semantisch aan een DIV. Ontsnap ik aan de semantiekpolizei door een DIV in een DIV te nestelen waarin ik een aantal DIVs nestel die weer een paar DIVs bevatten? En dat ik ze dan met kreten als display:table-row alsnog ombouw tot elementen die mijn pagina vormgeven op de manier zoals ik dat wil?

Oh nee, iemand is vergeten om die optie in te bouwen in de browser die 85% van de Nederlanders gebruikt

Nee, dat is (natuurlijk en gelukkig maar) niet waar! Een table is niet bedoeld voor opmaak, maar om tabulaire elementen in weer te geven.
Een div is (evenals een span) bedoeld om structuur aan een document te geven, waarbij je als ontwikkelaar de vrijheid krijgt om daar zelf een opmaak dmv. CSS aan te hangen. Daar kan je dus mits goed gebruikt wel degelijk een semantiek in aanbrengen, waarbij dat bij een table niet kan, omdat daarvan semantisch is vastgelegd dat daar tabulaire data in hoort te staan.

zie ook:

quote: http://www.w3.org/TR/html4/struct/global.html#h-7.5.4

The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents. These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content. Thus, authors may use these elements in conjunction with style sheets, the lang attribute, etc., to tailor HTML to their own needs and tastes.

edit:
Overigens zal ik de eerste zijn om te zeggen dat mijn eigen sites (puur en alleen voor de hobby) ook semantisch vast niet altijd perfect in elkaar steken, maar dat wil niet zeggen dat ik de theorie niet kan verdedigen natuurlijk

Wokkels wijzigde dit bericht 11-09-2007 23:30 (7%)

quote:

BikkelZ schreef op dinsdag 11 september 2007 @ 23:19:
[...]
Zelfs correct weergegeven zuigt CSS + DIVs nog steeds. Er is ook niks semantisch aan een DIV. Ontsnap ik aan de semantiekpolizei door een DIV in een DIV te nestelen waarin ik een aantal DIVs nestel die weer een paar DIVs bevatten?

Smurf language is idd het andere uiterste. Maar ik had het over semantische html...

quote:

En dat ik ze dan met kreten als display:table-row alsnog ombouw tot elementen die mijn pagina vormgeven op de manier zoals ik dat wil?

Je wijzigt de stijl, en dat is toch netjes met CSS geregeld dan? <table> echter heeft semantische betekenis: tabulaire data. display:table-row heeft dat niet.

quote:

Oh nee, iemand is vergeten om die optie in te bouwen in de browser die 85% van de Nederlanders gebruikt

Zeg nu zelf, hoevaak heb je display:table-row echt nodig? Maar goed, misschien dat het voor antieke browsers heel soms een optie kan zijn, maar dan kan binnen die tabel nog prima semantische html gebruikt worden toch? edit: HTML en CSS zuigen dus niet, maar de implementatie ervan (of het gebrek daaraan) in een bepaalde browser

JanDM wijzigde dit bericht 11-09-2007 23:58 (4%)

In principe wil je visuele opmaak altijd van je inhoud scheiden, maar dat hoeft nog niet te betekenen dat je alle middelen kwijt moet raken om containers zich aan te laten passen aan elkaar in plaats van de directe omgeving. Het web is geen pixelperfecte omgeving met een vaste grootte waarbij bij een overschot aan lettertjes er gewoon een pagina 2 ontstaat.

Dat mensen nog steeds overwegen om tables te gebruiken terwijl we al tien jaar iets hebben wat wel specifiek op opmaak gericht is, zegt misschien toch wel wat over de bruikbaarheid van HTML + CSS zoals het er nu ligt. Maar goed, ik ben ook niet meer de jongen die het mooi hoeft te maken, zolang de scripts maar werken dan klaagt er verder niemand.

Ik ben ondertussen allang blij dat dat xhtml verhaal langzaam een zachte dood sterft.

quote:

JanDM schreef op dinsdag 11 september 2007 @ 23:54:
edit: HTML en CSS zuigen dus niet, maar de implementatie ervan (of het gebrek daaraan) in een bepaalde browser

Kun jij dan een tutorial grid layout met CSS verzorgen? En ik bedoel dit serieus: ik werk al een tijdje met HTML en CSS (niet professioneel) maar ik weet echt niet hoe ik het equivalent van een table handig met CSS kan bouwen.

Het is sowieso diep triest dat het met CSS niet veel makkelijker is om een aantal dingen te doen die met klassieke HTML-elementen die helemaal nooit voor lay-out bedoeld waren heel simpel konden, en waar een grote behoefte aan is. Dat je nu nog moet teruggrijpen naar tables en spacer images is wat mij betreft een bewijs dat CSS fundamenteel gewoon wel "zuigt".

quote:

Soultaker schreef op woensdag 12 september 2007 @ 09:20:
[...]
Kun jij dan een tutorial grid layout met CSS verzorgen? En ik bedoel dit serieus: ik werk al een tijdje met HTML en CSS (niet professioneel) maar ik weet echt niet hoe ik het equivalent van een table handig met CSS kan bouwen.

Weet je wat je moet gebruiken als je iets wilt bouwen wat lijkt op een tabel. Klinkt als een tabel. Moet werken als een tabel.

Geen geklooi met elementen die niet bij horen.... maar een tabel

De opmaak kan je dan afhandelen in de css. Zoals het hoort. Maar een tabel is gewoon een tabel.

Ik wil geen tabel, ik wil een grid based lay-out. En het probleem is dus dat als ik mijn HTML puur semantisch opmaak het ontzettend moeilijk of vaak onmogelijk is om met CSS de gewenste lay-out te krijgen, terwijl het met de "ouderwetse" table-gebaseerde lay-out makkelijk genoeg is en in praktisch alle browsers werkt.

Ik loop altijd tegen hetzelfde probleem aan. Je zit in strict mode en wil 2 kolommen: eentje van 100px en eentje van "de rest van de ruimte". Waarom is dit zo pijnlijk moeilijk (in IE, waar je left en right niet tegelijk kan gebruiken)?

Edit: Slecht voorbeeld, beter voorbeeld: rijen ipv kolommen.

Jaaap wijzigde dit bericht 12-09-2007 09:40 (11%)

Weer een semantiek discussie...
Het argument dat je sneller klaar bent met een table layout vind ik bullshit. Ik ben 10x sneller met semantisch coden dan met tables. Het is een kwestie van gewenning en kennis.

Mensen die stug bij tabellen (of frames) blijven hangen die zie ik dan ook meer als amateur, no offence maar het is 2007 inmiddels.

Sommige layouts zijn inderdaad lastig met CSS. Vooral 100% height gevallen en typische "tabel-" en "frameslayouts". 100% hoogte en verticaal positioneren met CSS is een bitch. Al helemaal met al die verschillen tussen browsers. Het is vaak wel mogelijk met CSS, maar dan moet je maar net de trucjes kennen. Ik kan me heel goed voorstellen dat je dan uit pure wanhoop maar een tabel gebruikt.

Gelukkig zijn er ook een hele hoop gevallen waarbij juist geen tabel gebruiken veel sneller en makkelijker is.

quote:

Cartman! schreef op woensdag 12 september 2007 @ 11:13:
Weer een semantiek discussie...
Het argument dat je sneller klaar bent met een table layout vind ik bullshit. Ik ben 10x sneller met semantisch coden dan met tables. Het is een kwestie van gewenning en kennis.

Mensen die stug bij tabellen (of frames) blijven hangen die zie ik dan ook meer als amateur, no offence maar het is 2007 inmiddels.

DIVs + CSS stribbelt nogal tegen of doet het helemaal niet bij bepaalde layouts die in vrijwel iedere GUI en met TABLEs prima te doen zijn. Het is ook niet zo gek dat bij HTML layout en inhoud door elkaar gegooid worden, wil je iets doen via CSS zul je toch al gauw een semantisch gezien overbodig SPAN of DIV element moeten toevoegen.

Des te meer ik er over nadenk des te meer ik tot de conclusie kom dat HTML + CSS zeer ernstig te kort schiet op zowel grafisch vlak als op semantisch vlak doordat het zo'n halfbakken constructie is.

Wat voor alle partijen een uitkomst zou zijn is dat de inhoud verder losgemaakt wordt van de presentatie, door middel van een template + css en aan de andere kant de losse brokken informatie (de kale infotabellen, ul li menuutjes, etcetera). Hier wordt een webprogrammeur blijer van (exit Smarty, enter sanity), een webdesigner kan nooit meer iets stuk maken en er staat nooit meer iets wat met opmaak te maken heeft in je semantisch vormgegeven document. Zelfs javascript clicks kun je via de template afvangen.

BikkelZ wijzigde dit bericht 12-09-2007 11:33 (20%)

quote:

BikkelZ schreef op woensdag 12 september 2007 @ 11:27:
DIVs + CSS stribbelt nogal tegen of doet het helemaal niet bij bepaalde layouts die in vrijwel iedere GUI en met TABLEs prima te doen zijn.

Sommge layouts zijn lastiger te maken dmv CSS als wanneer Tabellen gebruikt zouden worden, maar ik ben nog nooit een layout tegen gekomen die niet opgebouwd kon worden dmv CSS.

quote:

Het is ook niet zo gek dat bij HTML layout en inhoud door elkaar gegooid worden, wil je iets doen via CSS zul je toch al gauw een semantisch gezien overbodig SPAN of DIV element moeten toevoegen.

Soms is een extra span- of div-element nodig ja. Maar daar zie ik het probleem niet van; semanitsche HTML wil vooral zeggen dat je de elementen gebruikt waar ze voor bedoeld zijn. Een div-element is dus een divider: je deelt iets op. Semantische HTML heeft als nut o.a. dat machines beter kunnen achterhalen wat de functie van iets is, een span of div heeft verder geen betekenis, dus geen punt om die te gebruiken wanneer je zonder de layout niet kunt bouwen.

quote:

Des te meer ik er over nadenk des te meer ik tot de conclusie kom dat HTML + CSS zeer ernstig te kort schiet op zowel grafisch vlak als op semantisch vlak doordat het zo'n halfbakken constructie is.

Hier ben ik het wel mee eens. Er missen nog aardig wat elementen en technieken, maar daar gaan HTML5 en CSS3 verandering in brengen. Al zal het nog lang duren voor we dat echt kunnen gebruiken...

quote:

Wat voor alle partijen een uitkomst zou zijn is dat de inhoud verder losgemaakt wordt van de presentatie, door middel van een template + css en aan de andere kant de losse brokken informatie (de kale infotabellen, ul li menuutjes, etcetera). Hier wordt een webprogrammeur blijer van (exit Smarty, enter sanity), een webdesigner kan nooit meer iets stuk maken en er staat nooit meer iets wat met opmaak te maken heeft in je semantisch vormgegeven document. Zelfs javascript clicks kun je via de template afvangen.

Is dit niet eigenlijk wat XML en XSLT is?

Er spelen hier een aantal issues die maken dat tabellen nog steeds zo populair zijn:

- designs die niet helemaal aansluiten op de mogelijkheden en onmogelijkheden die de webtechnologie ons biedt. Veel designers vergeten dat ze voor het web designen en niet voor print, dan krijg je dus inderdaad van die designs die zonder een enorme truukendoos (of een tabel) lastig te implementeren zijn.

- beperkingen vanuit implementaties; IE's beroerde CSS support is denk ik wel een voorbeeld dat verder geen uitleg meer behoeft.

- beperkingen vanuit de technologie zelf; dat is gedeeltelijk een kip-ei verhaal - zolang de marktleider op browsergebied zelf weinig tot niets doet aan z'n gebrekkige implementatie is de incentive ook niet zo groot om de technologie naar een hoger niveau te brengen. Er is simpelweg geen markt voor omdat er toch geen support is. Of dat ook direct een reden is waarom de standaardisering vanuit W3C ook zo langzaam gaat op deze vlakken weet ik niet...
Grid-based layouttechnieken zijn een onderdeel van CSS3, maar dat lijkt allemaal maar moeizaam van de grond te komen.

Verder onderschrijf ik ook grotendeels dat eea vaak ook te maken heeft met beperkte kennis van front-end designers. Met voldoende CSS kennis en ervaring is CSS-based layout helemaal niet zoveel lastiger dan een tabel en uiteindelijk bij onderhoud of layout-wijzigingen levert het veel winst op.
Wel moet ik opmerken dat CSS-based layouts fragieler zijn: een verkeerde nesting of niet afgesloten tag in content vanuit je CMS zal sneller je layout doen 'breken'.

Nee XSLT is weer net te veel naar de andere over slaan. Eigenlijk trek je gewoon alle DIV, SPAN, TABLE (in de zin van vormgeving) en andere tags die puur voor vormgeving gebruikt worden uit je document, en bepaal je een 'raster' waar je dat normaal in je document zou doen, met mogelijkheden tot het hebben van verschillende soorten layouts eventueel. Dus in dat deel voor een stuk terug naar 3.2, en verder drie stappen vooruit.

Maar ik kan wel een hordenparcours bedenken voor je als je daar behoefte aan hebt. Iets met veel uitvullen, % met px gemixt, headers en footers die stijf boven en onderaan moeten staan, kolommen die altijd even lang moeten zijn, 100% hoog tenzij een van de kolommen meer tekst bevat dan die kan bevatten, dat soort ellende. Individueel te fixen, in combinatie wordt het lastiger.

Ik zou trouwens misschien zelf wel iets kunnen doen met JavaScript op dat vlak overigens.....de trend is toch dat er steeds meer naar de client verschoven wordt.

quote:

JanDM schreef op dinsdag 11 september 2007 @ 23:54:
[...]

Smurf language is idd het andere uiterste. Maar ik had het over semantische html...

quote:

accessive

Wanneer gaan bloggers eens gebruik maken van een thesaurus. Hij bedoelt vast 'excessive'.

(verder wel een goed stukje.)

Grijze Vos wijzigde dit bericht 12-09-2007 14:04 (10%)

quote:

OkkE schreef op woensdag 12 september 2007 @ 11:42:
Sommge layouts zijn lastiger te maken dmv CSS als wanneer Tabellen gebruikt zouden worden, maar ik ben nog nooit een layout tegen gekomen die niet opgebouwd kon worden dmv CSS.

Ok:
HTML:

1 2 3 4 5 6 7 8 9

<html> <head><title>Foo</title></head> <body> <table height="100%"> <tr height="100%"><td valign="top">Content</td></tr> <tr height="50"><td>Footer</td></tr> </table> </body> </html>

Hoe doe ik dit met CSS? Ik weet dat er officieel geen "height" attribuut is, maar browsers ondersteunen die wel, en terecht, want hij is nuttig. Als de W3C in plaats van drie CSS standaarden verzinnen die praktisch geen browser volledig kan ondersteunen de "height" attribuut had toegevoegd, waren ze zinniger bezig geweest.

Maar als CSS zo geweldig is, hoe doe je dit dan in CSS? (En ja, het is een subtiele vraag, maar ik wil dus dat de footer de content niet overlapt, dat ik een scrollbar krijg als content+footer niet past, en als er niet gescrolled wordt de footer onderaan staat.)

quote:

Semantische HTML heeft als nut o.a. dat machines beter kunnen achterhalen wat de functie van iets is, een span of div heeft verder geen betekenis, dus geen punt om die te gebruiken wanneer je zonder de layout niet kunt bouwen.

Google is juist succesvol omdat ze alle metadata negeren en uitgaan van welke informatie daadwerkelijk gerenderd wordt. Als jij <h1 style="display:none">Nep Titel Hier</h1> neerzet heb je mooie semantische HTML maar zal een publieke zoekmachine die titel juist willen negeren. In klassieke HTML zonder CSS flauwekul kon je ook wel dit soort trucs verzinnen (met font-tags) maar dan was een <h1>-element tenminste een echte heading.

Voor het daadwerkelijke WWW (buiten de belevingswereld van de waanzinnigen die in het semantische web geloven) is semantische HTML dus zinloos. Het enige wat belangrijk is aan HTML is dat je pagina's handig kan aanpassen aan je medium (audio, printer, verschillende beeldresoluties, enzovoorts) niet dat een machine er betekenis aan kan toekennen.

quote:

Er missen nog aardig wat elementen en technieken, maar daar gaan HTML5 en CSS3 verandering in brengen. Al zal het nog lang duren voor we dat echt kunnen gebruiken...

Dat is dus bezopen. Ze zijn dus 10 jaar bezig met een standaard voor lay-out die oude "amateuristische" technieken moet vervangen, en ze zijn feitelijk nog nergens, want niemand gebruikt een HTML5/CSS3 compatible browser.