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

[imp4ct]

'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.

[Verwijderd]

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.

[ Voor 29% gewijzigd door Verwijderd op 11-09-2007 22:37 ]

[HyperioN]

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.

[Erkens]

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.

[remcotolsma]

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.

[Verwijderd]

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

[user109731]

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.

[ Voor 20% gewijzigd door user109731 op 11-09-2007 22:50 ]

[Verwijderd]

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.

[BikkelZ]

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

[ Voor 6% gewijzigd door BikkelZ op 11-09-2007 23:21 ]

[Wokkels]

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

[ Voor 7% gewijzigd door Wokkels op 11-09-2007 23:30 ]

[user109731]

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...

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.

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

[ Voor 4% gewijzigd door user109731 op 11-09-2007 23:58 ]

[BikkelZ]

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.

[Soultaker]

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".

[disjfa]

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.

[Soultaker]

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.

[Juup]

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.

[ Voor 11% gewijzigd door Juup op 12-09-2007 09:40 ]

[Cartman!]

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.

[Blaise]

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.

[BikkelZ]

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.

[ Voor 20% gewijzigd door BikkelZ op 12-09-2007 11:33 ]

[OkkE]

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.

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.

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...

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?

[crisp]

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'.

[BikkelZ]

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.

[BikkelZ]

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.

[Grijze Vos]

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

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

accessive

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

(verder wel een goed stukje.)

[ Voor 10% gewijzigd door Grijze Vos op 12-09-2007 14:04 ]

[Soultaker]

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:

<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.)

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.

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.

[BikkelZ]

Het correct toepassen van semantische HTML levert wel degelijk pluspunten op bij o.a. Google. Dat wit-op-wit, display:none en andere shittrucjes er uit gefilterd worden doet daar niets aan af. Ga er van uit dat Google je pagina ziet zoals een oude browser hem rendert. Alles wat meer in het oog springt doet dat min of meer ook bij Google.

[T-MOB]

Soultaker schreef op woensdag 12 september 2007 @ 15:10:
Hoe doe ik dit met CSS?

Ik geloof dat Steve Pugh daar een concept van on-line heeft...

[BikkelZ]

T-MOB schreef op woensdag 12 september 2007 @ 15:40:
[...]
Ik geloof dat Steve Pugh daar een concept van on-line heeft...

Maak #nav bvb eens rood en #content blauw voor de grap.

[disjfa]

De keuze tussen wil je een 100% hoogte en geeft dat inhoudelijk wat extras toevoegt.

Er zijn bij tabellen randvoorwaarden voor ontwerp, en vice versa met semantische html. Gebruik wat je wilt en gebruik wat werkt voor je.

[OkkE]

Soultaker schreef op woensdag 12 september 2007 @ 15:10:
[...]

Ok:

HTML:

<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.)

Zoiets?

Trouwens, ik vind dat het W3C zeker wel nuttig bezig is. Dat Microsoft het niet nodig vindt hun standaard te ondersteunen, waardoor we waarschijnlijk nooit bij CSS3 ondersteuning zullen belanden, vind ik erger.

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.

Semantiek heeft op de manier die je hier beschrijft, niets met rendering temaken. Dat Google display:none; negeert is goed. Maar het gaat er om, dat een H1 element belangrijker is als een H2 of H3. Dat een computer/applicatie weet dat alles binnen UL een lijst is. Dat iets binnen STRONG belangrijker (of iig de nadruk heeft) boven de omringende tekst.

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.

Semaniek is dus zeker niet zinloos. Dat jij net nut er niet van inziet, of de voordelen die het bied niet benut, wil niet zeggen dat ze er niet zijn. Voorbeeldje: een Screen Reader spreekt tekst binnen een STRONG element anders uit; legt er de nadruk op. Wat - mits goed gebruikt - heel handig kan zijn.

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.

Dat er nog geen browsers gebruikt worden die CSS3 ondersteunen (of uberhaupt zijn, die het ondersteunen...) is niet de fout van het W3C. Ik vind het goed dat ze een standaard bedenken, die in mijn ogen, beter is als table-tag-soup.

[BikkelZ]

Heb ik al die tijd ergens overheen gelezen of wat is nou het fantastische aan HTML5 en CSS3 in deze context? Of ben ik gewoon een cynisch mens?

[OkkE]

Het "fantastische" aan HTML5 en CSS3 is dat het nog meer semantiek toevoegd aan HTML en nog meer opmaak-mogelijkheden met zich mee brengt.

Opzich heeft dat niet veel met de orginele discussie te maken, maar wel als verlengde van de uitleg over waarom "divs" (wat ik liever semantisch bouwen noem) "beter" zijn/is als table-layout.

[Soultaker]

OkkE schreef op woensdag 12 september 2007 @ 15:51:
Zoiets?

Prachtig. Ik open good_example_short in Konqueror (mijn standaardbrowser) en hij doet het niet goed: als ik een venster kleiner maak en dan weer groter, gaat de footer niet omlaag.

Maar zelf als er een werkende mogelijkheid is:
- er zijn een heleboel mensen die serieus geprobeerd hebben dit op te lossen en die het niet lukte (deze auteur valt daar ook onder); waarom moet zoiets simpels zo moeilijk zijn?
- de CSS source is veel langer en ingewikkelder dan de table declaratie en dan nog werkt het niet
- de CSS source is veel minder intuïtief; ik schreef mijn table-voorbeeld zonder een browser erbij te hebben, maar ik betwijfel of je deze CSS code kunt schrijven zonder uitgebreid te testen op allerlei browsers (want het gaat om een hele subtiele mix van de juiste attributen met de juiste waarden in de juiste hiërarchie) en dan nog werkt het niet
- er is toch nog een browser-specifieke hack nodig (geldt niet voor de table) en dan nog werkt het niet

Semantiek heeft op de manier die je hier beschrijft, niets met rendering temaken. Dat Google display:none; negeert is goed. Maar het gaat er om, dat een H1 element belangrijker is als een H2 of H3. Dat een computer/applicatie weet dat alles binnen UL een lijst is. Dat iets binnen STRONG belangrijker (of iig de nadruk heeft) boven de omringende tekst.

Accoord, maar laten we de semantiek-discussie er dan even buiten houden. Ik ben het hier namelijk helemaal mee eens. (Een aantal uitspraken die je me toedicht staan ook lijnrecht tegenover wat ik probeerde over te brengen, dus daar is iets misgegaan in de communicatie.)

Dat er nog geen browsers gebruikt worden die CSS3 ondersteunen (of uberhaupt zijn, die het ondersteunen...) is niet de fout van het W3C. Ik vind het goed dat ze een standaard bedenken, die in mijn ogen, beter is als table-tag-soup.

Er zitten ook wel zinnige dingen in CSS, maar het is veel te beperkt. Het erge is dat allerlei bewezen technieken (die op zichzelf heel zinnig zijn; grid based lay-outs zijn gewoon logisch) opeens deprecated genoemd worden, terwijl ze ook zouden kunnen onderkennen dat CSS op een aantal punten niet voldoet. Verder hebben ze CSS wel zo complex gemaakt dat praktisch niemand (ook KHTML en Gecko voor lange tijd) het niet 100% goed konden doen. Dat is gewoon debiel.

[ Voor 12% gewijzigd door Soultaker op 12-09-2007 16:54 ]

[OkkE]

Soultaker schreef op woensdag 12 september 2007 @ 16:52:
[...] en dan nog werkt het niet [...]

Ik geef toe dat het voorbeeld van de footer altijd onderaan, lastig te maken is in CSS. Waarom dat niet makkelijker kan, is mij ook niet geheel duidelijk. Dit is zeker iets waar verbetering kan plaatsvinden.

Er zitten ook wel zinnige dingen in CSS, maar het is veel te beperkt. Het erge is dat allerlei bewezen technieken (die op zichzelf heel zinnig zijn; grid based lay-outs zijn gewoon logisch) opeens deprecated genoemd worden, terwijl ze ook zouden kunnen onderkennen dat CSS op een aantal punten niet voldoet. Verder hebben ze CSS wel zo complex gemaakt dat praktisch niemand (ook KHTML en Gecko voor lange tijd) het niet 100% goed konden doen. Dat is gewoon debiel.

CSS is zeker nog geen volgroeide techiek, waar nog een hoop aan verbeterd kan worden. En dat CSS complex is, is zeker waar. En dat browsers er zo lang over gedaan hebben om het goed te ondersteunen, ik denk dat het voor een deel ook prioriteiten stellen is: toen die browsers/engines ontwikkeld werden, werd CSS2.1 nog vrij weinig gebruikt.

---

We zijn trouwens best een eindje van de orginele discussie afgedwaald. Ik blijf er namelijk bij, dat het alleen maar voordelen heeft, wanneer je een website geheel met symantische HTML en CSS voor opmaak, maakt. Dat het soms (erg) lastig is, dat geef ik direct toe.

[BikkelZ]

OkkE schreef op woensdag 12 september 2007 @ 17:08:
CSS is zeker nog geen volgroeide techiek, waar nog een hoop aan verbeterd kan worden. En dat CSS complex is, is zeker waar. En dat browsers er zo lang over gedaan hebben om het goed te ondersteunen, ik denk dat het voor een deel ook prioriteiten stellen is: toen die browsers/engines ontwikkeld werden, werd CSS2.1 nog vrij weinig gebruikt.

OkkE schreef op woensdag 12 september 2007 @ 16:34:
Het "fantastische" aan HTML5 en CSS3 is dat het nog meer semantiek toevoegd aan HTML en nog meer opmaak-mogelijkheden met zich mee brengt.

Opzich heeft dat niet veel met de orginele discussie te maken, maar wel als verlengde van de uitleg over waarom "divs" (wat ik liever semantisch bouwen noem) "beter" zijn/is als table-layout.

Nou ik heb niet het gevoel dat HTML5 en CSS3 heel snel geimplementeerd worden. En HTML5 en CSS3 zijn geenszins de structurele verbeteringen waar we sinds 1995 op zitten te wachten (!!!!!!). En je weet hoe lang het geduurd heeft voordat HTML4 en CSS1,5 een beetje wijd verbreid geadopteerd waren door browsers en webdesigners.

Ik hoef niet nog eens vijf jaar van mijn leven te verspillen met wachten op de volgende standaard die dan misschien weer incrementeel iets minder hard zuigt. En als ik tot die tijd een of twee tabelletjes moet gebruiken om een bepaalde layout mogelijk te maken en het verder netjes houd, schaam ik me helemaal nergens om. Ik ben niet degene die zich moet schamen IMHO

[ Voor 7% gewijzigd door BikkelZ op 12-09-2007 17:30 ]

[frickY]

Het is helemaal geen kwestie van kennis, maar voornamelijk van ondersteuning.
Niet voor alle toepassingen die je met tabellen kunt bereiken zijn nette XHTML+CSS oplossingen die in alle a-grade browsers correct ondersteunt worden. Je bent nu eenmaal meer tijd kwijt omdat je werk dubbel moet gaan zitten doen, om elke browser het juiste resultaat te laten weergeven.

Bedrijven kiezen nog vaak voor tables omdat dit in 99% van de gevallen goedkoper is.
Onderhoud is misschien wel omslachtiger, maar dat wordt toch gefactureerd.

[moozzuzz]

Even opmerken dat "tabellensoep" niet gelijk staat aan "niet-werken met CSS". Persoonlijk pleit ik voor de meest pragmatische oplossing (hier reeds aangegeven) :

• Kies altijd divs zolang je kan werken zonder hacks.
• Kies tabellen als het een typische tabellen layout is of wanneer het een div-soup dreigt te worden

Overigens moeten designers (als in grafici) maar eens rekening houden met de mogelijkheden van HTML en CSS. Het is immers een ander medium dan print (ook al gezegd hier). Vaak willen zij er een online videogame van maken lijkt het wel :^P...

Tot slot: In principe kan je veel oplossen met cond. statements. Een groot voordeel van div-layout is dat je relatief goede controle hebt op de "print"-versie van je project. Met tabellen lijkt me dat minder evident, maar ik moet toegeven... nooit gelet op print-versies toen ik tables gebruikte :^)

OkkE schreef op woensdag 12 september 2007 @ 17:08:
.... alleen maar voordelen heeft .... Dat het soms (erg) lastig is, dat geef ik direct toe.

Dat het erg lastig kan zijn is meteen een zeer sterk nadeel lijkt me of je moet blind zijn voor nadelen.

[ Voor 14% gewijzigd door moozzuzz op 12-09-2007 18:16 ]

[Soultaker]

Ik gebruik zelf ook altijd css voor allerlei dingen; het feit dat je een class kunt toekennen en dan een gemeenschappelijk set attributen hebt is al erg handig (in de jaren '90 moest je overal dezelfde tags copy pasten als je bijvoorbeeld op verschillende plekken een bepaald font wilde gebruiken) en dat je binnen een stylesheet kunt erven (cascaden ) is ook handig.

Dus ik vind css ook wel handig, maar het model is beperkt en steekt slecht in elkaar, waardoor webdesigners niet goed weten hoe ze iets moeten doen in css en browsermakers niet goed weten hoe ze het moeten implementeren.

[Duroth]

CSS is zeker nog geen volgroeide techiek, waar nog een hoop aan verbeterd kan worden. En dat CSS complex is, is zeker waar.

En dan alsnog voorstander zijn van CSS, dat is een beetje krom. Windows Vista is in de ogen van velen ook nog 'geen volgroeid OS', en dat is voor veel van die mensen een reden om bij XP te blijven. Ik dat opzicht zou het juist een wijze keuze zijn voorlopig nog de 'geteste methode' van tabellen te gebruiken.

Persoonlijk gebruik ik vaak tables en DIV's in combinatie met elkaar. Tables zijn erg praktisch om de globale indeling op te zetten (headertje boven, footertje onder, menuutje links en content in het midden), en is CSS de perfecte manier om de opmaak van de losse elementen, en daarmee de pagina/site in zijn geheel, te bepalen.

In deze zienswijze word dus duidelijk een onderscheid gemaakt tussen indeling (een hele simpele, in dit voorbeeld, maar het volstaat) en opmaak. Wanneer men een pagina wilt printen, zijn menu's vaak ongewenst, en veel sites hanteren een simpel scriptje om middels een pop-up een pagina te openen die geschikt is voor print. Het argument dat 'semantische' HTML d.m.v. divs voor dit doel effectiever zou zijn, gaat dus nauwelijks op. Websites zijn gewoon (nog) niet bedoeld om te printen, dus de gebruikte workarounds zullen in deze gevallen toch vaak de voorkeur genieten.

Verder is het ontwerpen van een website, zoals al vaker aangekaart is in dit forum, niet alleen afhankelijk van de mogelijkheden van CSS, maar ook de interpretatie hiervan. Ook in mijn ogen heeft een div-je met CSS opmaak veel voordelen, maar totdat browsers deze ook naar alle tevredenheid ondersteunen, zal men andere mogelijkheden toe moeten passen. Tenslotte is het onmogelijk een stenen huis te bouwen met slechts spijkers en een zaag, ook al is een stenen huis heel wat steviger dan het houten huis waar je nu voor zult moeten gaan.

Als laatste vind ik het argument 'omdat het daar niet voor bedoeld is' één van de slechtste argumenten die je in deze discussie naar voren kunt brengen. Om maar een simpel voorbeeld te noemen; computers zijn nooit bedoeld om te gamen. Toch zullen er hier onder de tweakers heel wat fervente PC- / console-gamers zijn. Voel je je dan schuldig, door een PC op zo'n manier te 'misbruiken'? Speel je elke avond nog trouw een spelletje mens-erger-je-niet met je ouders onder het genot van een kopje thee?

Als er niet ooit, ergens, iemand was geweest die iets gebruikte op een manier waar het niet voor bedoeld was, had er nooit zoiets als een technologische vooruitgang bestaan. Ontwikkeling betekent nieuwe oplossingen vinden voor bestaande problemen, ook al gebruik je oude methoden/instrumenten op een compleet andere manier. Zolang je je doel bereikt, kan het argument 'omdat het er niet voor bedoeld is' IMO absoluut niet gebruikt worden ter rechtvaardiging.

Sorry voor de lange post, maar het semantiek-regime dat sommige mensen erop nahouden, staat me gewoon niet zo aan

[Verwijderd]

Duroth schreef op woensdag 12 september 2007 @ 21:03:
Websites zijn gewoon (nog) niet bedoeld om te printen, dus de gebruikte workarounds zullen in deze gevallen toch vaak de voorkeur genieten.

CSS is dan juist een zegen. Als je je website logisch opbouwt, heb je in tien minuten een print-stylesheet geschreve. De workarounds omvatten doorgaans aparte PHP-scripts. Ook die zijn in tien minuten gemaakt, maar al het onderhoud moet je dubbel doen. Met CSS pak je het probleem generieker aan: je verandert de presentatie in plaats van de data.

Als laatste vind ik het argument 'omdat het daar niet voor bedoeld is' één van de slechtste argumenten die je in deze discussie naar voren kunt brengen.[...]

Daar ben ik het mee eens. Dat argument wordt ook zelden gebruikt. De meeste mensen brengen ingewikkeld onderhoud en ontoegankelijkheid aan als argumenten tegen het gebruik van tabellen voor layout-doeleinden.

[Soultaker]

Verwijderd schreef op woensdag 12 september 2007 @ 22:30:
CSS is dan juist een zegen. Als je je website logisch opbouwt, heb je in tien minuten een print-stylesheet geschreven. De workarounds omvatten doorgaans aparte PHP-scripts. Ook die zijn in tien minuten gemaakt, maar al het onderhoud moet je dubbel doen. Met CSS pak je het probleem generieker aan: je verandert de presentatie in plaats van de data.

Het punt is dat je met CSS dus niet de goede lay-out kunt maken. Dan moet je dus concessies doen aan je primaire medium alleen om te kunnen printen. Dat vind ik moeilijk te verteren, zeker als PHP standaard gebruikt wordt en je zoals je zelf ook zegt daarmee hetzelfde effect kunt bereiken, zónder in je mogelijkheden beperkt te worden.

Verder ervaar ik zelf het dubbele onderhoud niet zo; vaak bouw je een pagina min of meer op uit een template gecombineerd met wat dingen uit een database, en kun je gewoon bepaalde delen weglaten uit je pagina (navigatie bv) als je een print-variable meegeeft. Net zoals je vaak bepaalde dingen weglaat als iemand niet ingelogd is bijvoorbeeld. Het nadeel blijft natuurlijk dat je een aparte print link nodig hebt. Maar overigens kun je vaak ook wel een print-css gebruiken in combinaties met een table-layout. (Verder valt er ook wel wat voor te zeggen om een aparte link te hebben; als een pagina er geprint heel anders uitziet is dat ook weer verwarrend voor de gebruiker.)

Dat argument wordt ook zelden gebruikt. De meeste mensen brengen ingewikkeld onderhoud en ontoegankelijkheid aan als argumenten tegen het gebruik van tabellen voor layout-doeleinden.

Overigens grappig dat zowel Jaaap als ik een voorbeeld gegeven van iets wat makkelijk met tables kan maar niet met css, en hoewel er genoeg proponenten van css verklaard hebben dat alles best wel kan met css, heeft nog niemand uitgelegd hóé dan. Kan ik daaruit concluderen dat er consensus bestaat over de gebrekkigheid van css?

[Duroth]

Edit: Grr, de heer Soultaker was me voor... En heeft me meteen gelijk maar de woorden uit mijn mond genomen

Verwijderd schreef op woensdag 12 september 2007 @ 22:30:
CSS is dan juist een zegen. Als je je website logisch opbouwt, heb je in tien minuten een print-stylesheet geschreve. De workarounds omvatten doorgaans aparte PHP-scripts. Ook die zijn in tien minuten gemaakt, maar al het onderhoud moet je dubbel doen. Met CSS pak je het probleem generieker aan: je verandert de presentatie in plaats van de data.

Helaas helpt CSS niet tegen hetgene dat mensen het meest irriteert bij het printen van een website: De menu's die aan de linkerkant staan, het grote opzichtige logo erboven, en eventueel een kleiner menu onder in de footer. Om deze redenen gebruikt men workarounds, niet om het feit dat de tekstkleur op de website wit is, en deze op papier er in het zwart veel beter uitziet. Pas als CSS ook aan kan geven welke elementen niet geprint mogen worden, kan dit argument standhouden (en alle elementen visibility: hidden meegeven is evengoed een workaround uiteraard )

Daar ben ik het mee eens. Dat argument wordt ook zelden gebruikt. De meeste mensen brengen ingewikkeld onderhoud en ontoegankelijkheid aan als argumenten tegen het gebruik van tabellen voor layout-doeleinden.

Helaas komt het argument maar veel te vaak voorbij. Ook op GoT betrap ik men er nog wel eens op. Dat tables vaak moeilijker te onderhouden zijn is ook niet altijd van toepassing, aangezien div's, zeker als ze absoluut of relatief gepositioneerd zijn, een complete handleiding vereisen om aan een derde partij aan te geven waar wat nu precies voor staat. En de kwestie ontoegankelijkheid gaat ook niet altijd meer op, zeker niet als de website ontworpen is voor een specifieke doelgroep. Dat ook slechtzienden makkelijk toegang krijgen tot de informatie is heel leuk (om maar een voorbeeld te noemen), maar een fotograaf die zijn werk in een online portfolio zet, zal er zeer weinig boodschap aan hebben.

Om de conclusie van mijn vorige post nog maar even samen te vatten: CSS is in sommige gevallen inderdaad een verbetering, maar in sommige gevallen heb je er niks aan. Gebruik gewoon wat in de situatie het efficiëntst is, zonder je zorgen te maken om de semantiek. wat 'correct' is en wat niet is altijd een mening, wat 'werkt' en wat niet, daar kunnen mensen wat mee.

[Verwijderd]

Duroth schreef op woensdag 12 september 2007 @ 22:51:
Pas als CSS ook aan kan geven welke elementen niet geprint mogen worden, kan dit argument standhouden (en alle elementen visibility: hidden meegeven is evengoed een workaround uiteraard )

Waarom is "visibility: hidden" een workaround? Ik geef zelf altijd een "display: none", maar het idee is hetzelfde. Waar zijn beide properties anders voor gemaakt? Je wilt de presentatie aanpassen, dus gebruik je CSS.

Steeds meer komt de ware aard van het HTML (en daarmee het www) naar boven: het is nooit bedoeld om gedetailleerd te worden vormgegeven. Het kan wel, maar vanwege zijn platformonafhankelijke aard zal je altijd beperkingen blijven houden. CSS lost een deel op, maar niet alles. Ik ben me erbij aan het neerleggen dat een grafische presentatie van HTML altijd een benadering zal zijn. Ben ik even blij dat ik me vooral focus op de techniek erachter; die heb je veel meer in de hand .

[crisp]

Duroth schreef op woensdag 12 september 2007 @ 22:51:

Helaas helpt CSS niet tegen hetgene dat mensen het meest irriteert bij het printen van een website: De menu's die aan de linkerkant staan, het grote opzichtige logo erboven, en eventueel een kleiner menu onder in de footer. Om deze redenen gebruikt men workarounds, niet om het feit dat de tekstkleur op de website wit is, en deze op papier er in het zwart veel beter uitziet. Pas als CSS ook aan kan geven welke elementen niet geprint mogen worden, kan dit argument standhouden (en alle elementen visibility: hidden meegeven is evengoed een workaround uiteraard )

Nog nooit van media-stylesheets gehoord?

Pak eens een willekeurig nieuwsartikel op onze frontpage en doe voor de gein eens een print preview?

Dat is de powerrr van CSS

[crisp]

Even meer ontopic

Soultaker schreef op woensdag 12 september 2007 @ 22:50:
[...]
Overigens grappig dat zowel Jaaap als ik een voorbeeld gegeven van iets wat makkelijk met tables kan maar niet met css, en hoewel er genoeg proponenten van css verklaard hebben dat alles best wel kan met css, heeft nog niemand uitgelegd hóé dan. Kan ik daaruit concluderen dat er consensus bestaat over de gebrekkigheid van cssZ

Ik wil het geen gebrekkigheid noemen maar immaturity, zowel van implementaties als van de specificaties. Er staat zoals gezegd echter wel veel op stapel, kijk anders eens op http://www.w3.org/Style/CSS/current-work - gridlayouts worden daarin ook voorzien als een uitbreiding op multi-column layouts. Dat soort dingen kosten echter tijd, en het kost nog meer tijd voordat er goede implementaties zijn en bugs en tekortkomingen kunnen worden geconstateerd en gerepareerd in revisies. Who's to blame? Well, misschien moeten we allemaal wel een beetje de hand in eigen boezem steken...

Bottom line is dat het gebruik van tables voor layout blijven goedpraten de situatie ook niet helpt, op die manier blijf je in cirkeltjes rennen. Persoonlijk vind ik het geen schande als je voor een basis opzet eens een table gebruikt omdat dat crossbrowser eenvoudiger is (of zelfs de enige mogelijkheid, hoewel ik dan toch eerder in conclaaf zou gaan met de designer), maar op het moment dat je vervalt in geneste tabellen en spacer.gifjes (omdat het table-layout model nu eenmaal per definitie niet pixelprecies is en er ook mbt table-rendering verschillen zijn tussen browsers (!)) zou je jezelf toch wel achter de oren moeten gaan krabben.

Front-end webdevelopment is mijn werk en daarmee ook mijn passie - als het dat niet zou zijn had ik wel een ander beroep gekozen - dus ik ben niet vies van wat experimenteren en kennis opdoen in mijn eigen tijd. Dat CSS ingewikkeld of complex is vind ik dus geen erg sterk argument; het is te leren en het is verdulleme je vak notabene!. Dat het onhandig is in gebruik ligt ook voor een groot deel aan de implementaties (nou ja, voornamelijk die van 1 vendor ), maar ook daar kan je jezelf de truukjes en workarounds voor aanleren.

[BikkelZ]

http://www.w3.org/TR/2007/WD-css3-layout-20070809/

Een voorstel van augustus dit jaar. Wanneer zou dit gemeengoed worden?


(toen ik refereerde naar die hele spannende dingen in CSS3 had iemand dit best mogen aandragen trouwens....).

[OkkE]

Duroth schreef op woensdag 12 september 2007 @ 21:03:
En dan alsnog voorstander zijn van CSS, dat is een beetje krom. [...]

Dus omdat een techniek nog niet 100% voldoet, moeten we het daarom maar niet gebruiken? Ik geef toe dat CSS nog niet 100% goed is, maar ik zie persoonlijk meer voordelen aan semantisch webdesign (en dat is meer als alleen werken met CSS) in vergelijking met het (overvloedig) gebruik van tabellen.

Duroth schreef op woensdag 12 september 2007 @ 21:03:
[...] Wanneer men een pagina wilt printen, zijn menu's vaak ongewenst, en veel sites hanteren een simpel scriptje om middels een pop-up een pagina te openen die geschikt is voor print. Het argument dat 'semantische' HTML d.m.v. divs voor dit doel effectiever zou zijn, gaat dus nauwelijks op. [...]

Het gebruik van semantische HTML heeft als één van de voordelen, dat je geen apart print-script hoeft te maken. Je hoeft geen aparte versie voor print te maken (die je ook weer moet aanpassen indien er iets aan de pagina veranderd wordt). Daarnaast heeft semantische HTML nog veel meer voordelen; spiders hebben een beter idee wat met bepaalde content bedoelt wordt, door minder tabel-, tr- en td-elementen wordt je keyword density hoger, met een screen reader een tabel-website bekijken is gewoon geen pretje, etc..

Duroth schreef op woensdag 12 september 2007 @ 21:03:
[...] maar totdat browsers deze ook naar alle tevredenheid ondersteunen, zal men andere mogelijkheden toe moeten passen.

Zoals ik al eerder aan heb gegeven, ben ik nog maar weinig ontwerpen tegen gekomen die ik niet kon bouwen met HTML en CSS. Kan zijn omdat ik geluk heb met onze ontwerper, die (ongeveer) weet wat wel en niet kan, ik weet het niet.

Duroth schreef op woensdag 12 september 2007 @ 21:03:
[...] Als laatste vind ik het argument 'omdat het daar niet voor bedoeld is' één van de slechtste argumenten die je in deze discussie naar voren kunt brengen.

Ik geloof niet dat ik dit argument zelf ooit gebruikt heb, in deze discussie. Maar het is in mijn ogen wél een (goed) argument, namelijk om de volgende reden: elk element (op DIV en SPAN na) heeft een betekenis. Tabellen zijn bedoeld voor tabulaire data. Nu is het niet echt een heel zwaar wegend argument, maar computers zullen dus denken dat je website tabulaire data is, waarbij over het algemeen verbanden bestaan. Zoals ik zei; niet echt sterk, maar zeker ook niet helemaal onzin.

Duroth schreef op woensdag 12 september 2007 @ 21:03:
[...] Zolang je je doel bereikt, kan het argument 'omdat het er niet voor bedoeld is' IMO absoluut niet gebruikt worden ter rechtvaardiging. [...]

Ben ik opzich wel met je eens, maar alleen als er geen beter alternatief beschikbaar is. En dat is denk ik het punt, hier verschillen de meningen, maar ik denk dat er een beter alternatief is, boven het gebruik van tabellen voor opmaak.

Duroth schreef op woensdag 12 september 2007 @ 21:03:
[...] ^{Sorry voor de lange post, maar het semantiek-regime dat sommige mensen erop nahouden, staat me gewoon niet zo aan}

Mij staat de houding "tabellen zijn prima voor opmaak" me niet zo aan, dat vind ik een beetje de Microsoft houding, NOFI.

Soultaker schreef op woensdag 12 september 2007 @ 22:50:
Het punt is dat je met CSS dus niet de goede lay-out kunt maken. Dan moet je dus concessies doen aan je primaire medium alleen om te kunnen printen. [...]

Ik heb eigenlijk nooit concessies hoeven doen aan een layout om hem printbaar te maken...

Soultaker schreef op woensdag 12 september 2007 @ 22:50:
[...] Kan ik daaruit concluderen dat er consensus bestaat over de gebrekkigheid van css?

Ik denk dat we het er wel over eens zijn, dat bepaalde layouts niet (of iedergeval niet zonder hacks) te maken zijn met CSS. En om in dat geval een tabel te gebruiken, kan dan best een oplossing zijn.

Ik wil ook niet zeggen dat er helemaal nooit meer een tabel voor layout gebruikt mag worden. Wel vind ik dat je tabellen voor layout [i]het liefst zo min mogelijk[i] moet gebruiken, en eigenlijk liever helemaal niet. Wat ik vooral wil bereiken is dat iedereen die het idee heeft "tabellen zijn prima voor layout" toch eens gaat nadenken over de voordelen van semantisch webdesign.

Duroth schreef op woensdag 12 september 2007 @ 22:51:
[...] Pas als CSS ook aan kan geven welke elementen niet geprint mogen worden, kan dit argument standhouden (en alle elementen visibility: hidden meegeven is evengoed een workaround uiteraard )

Ik heb anders al meerdere malen content verborgen dmv 'display:none;' in een print-stylesheet. Dus tenzij we beide iets anders bedoelen, is het wel mogelijk om content te verbergen bij het printen.

Duroth schreef op woensdag 12 september 2007 @ 22:51:
Helaas komt het argument maar veel te vaak voorbij. Ook op GoT betrap ik men er nog wel eens op. Dat tables vaak moeilijker te onderhouden zijn is ook niet altijd van toepassing, aangezien div's, zeker als ze absoluut of relatief gepositioneerd zijn, een complete handleiding vereisen om aan een derde partij aan te geven waar wat nu precies voor staat. En de kwestie ontoegankelijkheid gaat ook niet altijd meer op, zeker niet als de website ontworpen is voor een specifieke doelgroep. Dat ook slechtzienden makkelijk toegang krijgen tot de informatie is heel leuk (om maar een voorbeeld te noemen), maar een fotograaf die zijn werk in een online portfolio zet, zal er zeer weinig boodschap aan hebben.

Tabellen zijn lastiger te onderhouden als een website met CSS, wanneer (delen van de) website gerestyled/gerepositioneerd moeten worden. Over het algemeen kun je sneller een DIV op een andere plaats zetten als een tabel-cel.

Verder vind ik niet dat CSS lastiger is, en daar al zeker geen handleiding voor nodig is. Indien een derde partij een handleiding nodig heeft om een DIV/CSS based website te onderhouden, is er imho of a) te weinig kennis in huis bij die partij, of b) de website niet goed genoeg opgezet. Als ik een website maak in DIVs en alle divs IDs als "text1", "text2", etc.. mee geef, ja dan is het lastig. Maar het id "nieuws_blok_homepage" geeft duidelijk aan wat het is.

Duroth schreef op woensdag 12 september 2007 @ 22:51:
Om de conclusie van mijn vorige post nog maar even samen te vatten: CSS is in sommige gevallen inderdaad een verbetering, maar in sommige gevallen heb je er niks aan. Gebruik gewoon wat in de situatie het efficiëntst is, zonder je zorgen te maken om de semantiek. wat 'correct' is en wat niet is altijd een mening, wat 'werkt' en wat niet, daar kunnen mensen wat mee.

Ben ik niet met je eens. Ik vind dat je je wel druk moet maken om semantiek. Dat je uiteindelijk besluit dat een tabel te gebruiken vind ik niet zo erg, als je die keuze maar wel overwogen gemaakt hebt. En dan hangt het vooral van kennis, browser-ondersteuning en tijd/geld af, of er gekozen wordt voor een tabel, denk ik.

[Mei]

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

Meuh. Zeker als je complexere layouts maakt, dan is CSS gebruik in mijn ogen sneller, maar dat kan ook zijn omdat ik alleen de eerste 3 jaar met tables heb gewerkt en nu alweer dik 3 jaar met CSS in de weer ben. Het moment waar je écht merkt wat de meest praktische kracht van CSS is, is als je je ingewikkelde layout moet veranderen. Dan ga je als tabledesigner zo ongelooflijk hard op je bek. Het makkelijke aan CSS is dat je alleen code hebt voor de dingen die je daadwerkelijk gebruikt, dus geen loze cellen, rijen, enz. Gewoon per onderdeel een <div> ofzo. Wil je die ergens anders hebben? Smijt hem gewoon daar neer. In de praktijk heb ik nauwelijks problemen met browsers en als ik die al heb, dan is het 99% van de keren Internet Explorer die de boel gruwelijk verneukt, maar die devvers in Redmond zijn gewoon zo kanzloß dat ze zelfs nog bruikbare bugs produceren, waardoor je de IE quirks ook weer makkelijk in toom kan krijgen.

Bottom line: tables envangelisten hebben 9 van de 10 keer niet verder gekeken dan hun neus lang is en vervloeken CSS al voordat ze de moeite hebben genomen zich erin te verdiepen.

[KatirZan]

CSS gebruik is ook sneller, zeker als je met een complexe layout werkt, voornamelijk met veel verschillende type soorten.

Ik ben zelf iemand die veel met de basis werkt, dus div's EN tables. Deze mix ik ook graag, maar gebruik daarnaast ook een deel CSS. De projecten waar ik mee bezig geweest ben werken (voor alsnog) onder alle browser typen en ben eigenlijk nog maar weinig echt relevante bugs tegen gekomen.

Het werken met tables en div's in combinatie is dat het kwa broncode allemaal overzichtelijk blijft en dat je bepaalde zaken in 1 bestand houdt. Het werken met CSS vergt wat meer tijd in het begin, maar als je eenmaal een layout op "papier" hebt staan is de rest "a piece of cake".

Tja, met tables en div's ben je dan uiteindelijk (bij grote sites) stukken langer bezig. Daarentegen werken de CSS's je weer tegen als je "eventjes snel een website op moet zetten" .

Beide hebben zijn voordelen en nadelen, het is maar net waar je zelf vind dat je het lekkerste mee werkt. Ik ben dan zelf wel van mening dat je met CSS een flink verder kan komen dan de standaard tables of div's....ondanks dat ik alle 3 vaak gebruik....

[Verwijderd]

Ik vind juist dat div's wel snel en gemakkelijk zijn. Gewoon divje hier divje daar! Bij tables moet je kolommen en rijen samenvoegen etc. Misschien wel makkelijk met dreamweaver, maar anders een gigantisch gedoe..

[Verwijderd]

Verwijderd schreef op vrijdag 14 september 2007 @ 22:41:
Ik vind juist dat div's wel snel en gemakkelijk zijn. Gewoon divje hier divje daar! Bij tables moet je kolommen en rijen samenvoegen etc. Misschien wel makkelijk met dreamweaver, maar anders een gigantisch gedoe..

Dat is ook zo, div'jes zijn enorm handig, het lastige komt pas als jouw geweldig gemaakte design perfect werkt in alle browsers behalve IE5, 5.5, 6 en 7 en 90% van de beoogte doelgroep nu net gebruik maakt van deze browser.

Dat kan je echt bizar veel tijd kosten om work-arounds te bedenken voor obscure bugs en het schrijven van verschillende CSS files voor iedere browser.

En het is niet alleen IE, ook de CSS zelf heeft zaken die open staan voor verschillende interpretaties en dus ook anders geimplementeerd worden.

Ikzelf heb laatst nog voor een hobby site een mooi ontwerp gemaakt, helemaal correct HTML/CSS met divjes en alles erop en eraan, zelfs in een tekst browser is de site nog goed te gebruiken enzo. Maar helaas onder Safari zit er een afwijking in die ik er niet uit krijg. (Na een paar uur maar opgegeven, mijn doelgroep gebruikt toch geen Mac)

De nieuwste CSS technieken zijn geweldig, helaas kun je ze niet gebruiken omdat er geen browsers zijn die ze ondersteunen.

Het is ook erg afhankelijk van het design, sommige designers weten niets af van websites en ontwerpen zomaar wat, dan kan je als front-end ontwikkelaar helemaal gek worden terwijl een stemmetje in je achterhoofd zegt: "Met tables was je eergister al klaar geweest"

[Erkens]

Verwijderd schreef op vrijdag 14 september 2007 @ 23:00:
...terwijl een stemmetje in je achterhoofd zegt: "Met tables was je eergister al klaar geweest"

Wellicht is dat ook zo, maar als het goed is moet er nog een stemmetje zijn die zegt dat je dan wel langer bezig bent als er later wat moet veranderen
Maar ook dan zeg ik dat het eerder ligt aan gebrek aan kennis en vooral ervaring dat je sneller zou zijn met een tabel.

[Boelie-Boelie]

Verwijderd schreef op vrijdag 14 september 2007 @ 23:00:
Dat kan je echt bizar veel tijd kosten om work-arounds te bedenken voor obscure bugs en het schrijven van verschillende CSS files voor iedere browser.

En het is niet alleen IE, ook de CSS zelf heeft zaken die open staan voor verschillende interpretaties en dus ook anders geimplementeerd worden.

Over CSS-bugs: IE5/Mac is door MS allang afgeschreven, het aandeel IE5.x/Win-gebruikers is inmiddels gedaald tot 1%, dus dan heb je alleen rekening te houden met IE6 (en IE7). CSS 2.1 wordt al jaren veelvuldig gebruikt (ben benieuwd welke zaken daarin volgens jou verschillend geïnterpreteerd worden, er vanuitgaande dat je in standards mode werkt, zoals het hoort), CSS-bugs in IE zijn zéér goed gedocumenteerd (zie PIE) dus je moet wel erg je best doen om obscure bugs tegen te komen, en je hebt echt geen volledig herschreven CSS-bestanden nodig voor crossbrowsercompatibiliteit; meestal voldoen enkele regeltjes voor IE. M.a.w., had je drie jaar geleden misschien nog een punt wat betreft de vele CSS-bugs i.c.m. de verschillende browsers, tegenwoordig zijn er behalve IE6 en IE7 geen slechte browsers meer in gebruik. Hun bugs en bijbehorende workarounds zijn goed gedocumenteerd, dus als het je nog bizar veel tijd kost, doe je waarschijnlijk iets verkeerd.

Volgens mij vergeten sommige tabellenvoorstanders ook, dat veel mensen die nu volgens webstandaarden werken, vroeger ook veel ervaring hebben opgedaan met tabellen. Dat maakt dat het vergelijken van werkwijze niet slechts is gebaseerd op het wel of niet meegaan in de hype, maar op kennis en ervaring.

Ook grappig die opmerking 'het is toch billable', op de opmerking dat onderhoud van tabellen meer tijd kost. Idd de klant betaalt vaak toch wel. Maar wat dan als je in dezelfde tijd die je besteedt aan het onderhoud van één tabellensite eigenlijk tijd hebt voor een groter aantal klanten, of meer tijd voor bestaande klanten? Als je je beperkt tot eenmalige opdrachtjes, dan maken tabellen voor jou als bouwer idd nix uit, maar voor langdurige klantrelaties (waar onderhoud een groot onderdeel van is) snij je uiteindelijk jezelf in de vingers als je vast blijft houden aan volledige tabellenlayouts.

[Soultaker]

Erkens schreef op vrijdag 14 september 2007 @ 23:19:
Wellicht is dat ook zo, maar als het goed is moet er nog een stemmetje zijn die zegt dat je dan wel langer bezig bent als er later wat moet veranderen

Ik betwijfel of dat in het algemeen wel waar is. Hoe ingewikkelder je lay-out is, hoe lastiger het is om dingen te veranderen. Ik heb het idee dat de mate waarin een wijziging ingewikkeld is, vooral een combinatie is van hoe ingewikkeld het zou zijn om die lay-out from scratch te maken, en de mate waarin hij overeenkomt met wat je al had. Wat het tweede punt betreft kan zowel een bestaande table-layout als een css-layout je tijd besparen, maar wat het eerste punt betreft begint css al met een achterstand simpelweg omdat we geconstateerd hebben dat het veel moeilijk is om een css-layout te maken.

Maar ook dan zeg ik dat het eerder ligt aan gebrek aan kennis en vooral ervaring dat je sneller zou zijn met een tabel.

Je kunt wel alle problemen met css op ``gebrek aan kennis en ervaring'' schuiven, maar het begint er sterk op te lijken dat voor bepaalde problemen niemand genoeg kennis en ervaring heeft. (Dat blijkt ook uit het feit dat bijna geen enkele browser css goed geïmplementeerd heeft, zie dingen als de Acid2 test die jarenlang in geen enkele browser goed gerenderd werd, en nu door de ruime meerderheid - Internet Explorer en Gecko - nog steeds niet.) Je kunt dan wel claimen dat het aan de gebruikers ligt, maar ik begin dan sterk te vermoeden dat css gewoon geen geschikte tool voor de job is.

Wat mij betreft gebruiken verstandige webdesigners (ook die met kennis en ervaring) dus een combinatie van css, waar dat zinnig is en werkt, maar voor grid layouts gewoon tabellen in plaats van allerlei intricate hacks te combineren om met css hetzelfde voor elkaar te krijgen.

Ik vind sowieso het argument ``het is een gebrek aan kennis'' geen hout snijden zolang ook de proponenten van css een eenvoudig praktijkvoorbeeld zoals ik eerder gaf niet met css kunnen oplossen.

[ Voor 6% gewijzigd door Soultaker op 15-09-2007 18:07 ]

[Erkens]

Tables zijn ook niet heilig, browsers interpeteren ze ook allemaal anders. Neem alleen al de borders en padding

Overigens is het gewoon zo dat het vaak een gebrek aan kennis is als men zonder nadenken direct een table gaat gebruiken. En natuurlijk zijn er layouts te verzinnen wat met de huidige stand van zaken mbt CSS en browsers nog niet goed mogelijk zijn, dan is er ook weinig op tegen om een simpele tabel te gebruiken. Echter je moet je er wel van bewust zijn waarom je een tabel gebruikt. Dat is wat ik bedoel met "gebrek aan kennis/ervaring".

Maar als iemand zegt dat CSS geen geschikte tool is alleen omdat er weinig browsers zijn die een of andere niets zeggende test goed kunnen afleggen, dan heeft die persoon totaal geen volledig beeld van wat wel of niet mogelijk is, daarnaast zijn dat soort personen moeilijk te overtuigen van de voor en nadelen van het niet gebruiken van tables omdat ze zelf voor ogen hebben dat CSS "waardeloos" is. Gebrek aan kennis en ervaring dus.

[ Voor 28% gewijzigd door Erkens op 15-09-2007 19:04 ]

[crisp]

Soultaker schreef op zaterdag 15 september 2007 @ 18:04:
[...]

(Dat blijkt ook uit het feit dat bijna geen enkele browser css goed geïmplementeerd heeft, zie dingen als de Acid2 test die jarenlang in geen enkele browser goed gerenderd werd, en nu door de ruime meerderheid - Internet Explorer en Gecko - nog steeds niet.)

Gran Paradiso rendered de Acid2 test wel goed (al een tijdje, dat er nog geen produktieversie van Firefox is met deze engine versie doet er niet echt toe imo)), wat dus het totaal aan renderengines dat de Acid2 test goed rendered op 4 (Webkit, KHTML, Presto en Gecko) brengt tegenover 1 engine die 'm niet goed rendered (Trident), nog maar een kleine minderheid dus (marktaandeel daargelaten)

Ik denk dat er toch wel genoeg bewijs is dat CSS2.1 implementabel is.

[ Voor 4% gewijzigd door crisp op 15-09-2007 20:53 ]

[Blue-eagle]

Wat een topic zeg De vooroordelen vliegen over en weer. De meeste ervaren webdevelopers die nu de moderne manier van web-ontwikkeling gebruiken hebben allemaal het table-met-spacer-gifjes tijdperk meegemaakt. Als deze mensen claimen sneller, effectiever en makkelijker te werken en hiernaast nog vele andere voordelen ervaren van het semantisch coden, dan zou ik me toch afvragen of jij niet gewoon enorm koppig bent om niet semantisch te coden.

Ik werk nu al (pas?) 7 jaar als webdeveloper, grotendeels frontend (html) en ik ken het tabel tijdperk erg goed. Het was een regelrechte ramp blijkt achteraf. HTML van websites uit die tijd is lastig te onderhouden, het is moeilijk leesbaar voor iemand die de site niet kent (10 geneste tabellen, ieder weer een tabje verder naar rechts) en op een drukke site scheelt het ook nog eens enorm in het dataverkeer.

De leercurve is wat lastig misschien, er zijn een paar dingen niet mogelijk zonder iets meer werk te verrichten maar over het algemeen merk ik dat ik veel effectiever werk, mijn collega's mijn code prima begrijpen (het is semantisch, dus per definitie beter leesbaar) en beter te onderhouden (middels CSS). Je kan iedere willekeurige pagina extreem makkelijk klaarmaken voor diverse media (scherm, print, smartphones, textreaders) en als je er een klein beetje bedreven in bent maak je net zo makkelijk een site die in IE5.5 t/m IE7, FF, Opera en Safari perfect werkt.

Daarnaast zijn HTML en CSS nog in de groei, over een jaartje of 2 zul je zien dat ook Microsoft meegaat in de ontwikkelingen, ze kunnen moeilijk achter blijven. Wellicht dat ze straks via Windows Update features gaan toevoegen.

Hoe dan ook...

Een ontwikkelaar die zich met webdesign en ontwikkeling bezig houdt maar nog steeds niet semantisch werkt is gewoon niet professioneel. No offense intended..

Zie het als een automonteur die je auto niet controleert volgens de richtlijnen die de APK aangeeft, maar zijn eigen lijstje er op nahoudt. Kom je de auto ophalen, zitten er ineens 16 wielen onder, omdat je met 4 wielen en een lekke band weleens een ongeluk zou kunnen krijgen.

Werk volgens de standaarden, dan ben je beter voorbereid op de toekomst. Of doe het niet, heb ik meer potentiële klanten

[Dutch_guy]

"Werk volgens de standaarden, dan ben je beter voorbereid op de toekomst. Of doe het niet, heb ik meer potentiële klanten"

Ik heb nog nooit een klant meegemaakt die om div's vroeg hoor...

[Erkens]

Dutch_guy schreef op zondag 16 september 2007 @ 12:08:
"Werk volgens de standaarden, dan ben je beter voorbereid op de toekomst. Of doe het niet, heb ik meer potentiële klanten"

Ik heb nog nooit een klant meegemaakt die om div's vroeg hoor...

Ehm, normaal gesproken vragen klanten helemaal niet om een specifieke techniek
Je moet altijd de beste techinieken gebruiken die tot het gewenste resultaat leiden: een website die makkelijk te onderhouden is en goed vindbaar is met searchengines als google.

Overigens is het gebruiken van div's ipv tables ook niet goed, een div is niks meer als een loos element wat verder geen betekenis heeft.

[Dutch_guy]

Word hierboven anders wel gesuggereerd hoor. Ik verzin dat niet zelf.

Ik word een beetje moe van deze discussie, die altijd weer eens een keer voorbij komt. Doe gewoon je ding zoals jij het wil doen.

Wat maakt het uit hoe een ander dit doet ? Voor mij telt maar 1 ding en dat is een tevreden klant en hoe ik dat voor elkaar krijg maakt echt niets uit, en zeker voor een ander niet.

[ Voor 71% gewijzigd door Dutch_guy op 16-09-2007 12:52 ]

[Erkens]

Dutch_guy schreef op zondag 16 september 2007 @ 12:50:
Wat maakt het uit hoe een ander dit doet ? Voor mij telt maar 1 ding en dat is een tevreden klant en hoe ik dat voor elkaar krijg maakt echt niets uit, en zeker voor een ander niet.

Natuurlijk maakt dat uit, als je altijd op ouderwetse manieren blijft werken zul je nooit vooruitgang krijgen. Verder is het niet handig om stront eigenwijs op je "eigen" manier te blijven werken terwijl je weet dat dit "fout" is, vooral niet tegenover je collega developers. En al helemaal niet tegenover je eventuele opvolgers die met de rommel blijven zitten.

Een klant is vaak snel tevreden, maar zou die ook tevreden zijn als hij wist dat je hem oude troep zit te verkopen?

[BikkelZ]

Blue-eagle schreef op zaterdag 15 september 2007 @ 22:59:
De meeste ervaren webdevelopers die nu de moderne manier van web-ontwikkeling gebruiken hebben allemaal het table-met-spacer-gifjes tijdperk meegemaakt. (....) Ik werk nu al (pas?) 7 jaar als webdeveloper, grotendeels frontend (html) en ik ken het tabel tijdperk erg goed. Het was een regelrechte ramp blijkt achteraf. HTML van websites uit die tijd is lastig te onderhouden, het is moeilijk leesbaar voor iemand die de site niet kent (10 geneste tabellen, ieder weer een tabje verder naar rechts) en op een drukke site scheelt het ook nog eens enorm in het dataverkeer.

Het is niet de keuze tussen CSS of font tags met tables. Het is CSS + DIVs voor layout of CSS + DIVs + strikt waar nodig TABLEs. Ik begrijp dat je nu nog gillend wakker wordt 's nachts van je laatste 'kun je dit even aanpassen' in OSCommerce opdracht, maar er is nog een tussenweg

[Blue-eagle]

Dutch_guy schreef op zondag 16 september 2007 @ 12:08:
"Werk volgens de standaarden, dan ben je beter voorbereid op de toekomst. Of doe het niet, heb ik meer potentiële klanten"

Ik heb nog nooit een klant meegemaakt die om div's vroeg hoor...

Ik wel

Maargoed, de meeste doen dat niet. Dan nog is het voor -jezelf- een goed idee om wel gewoon volgens de laatste technieken te werken.

BikkelZ schreef op zondag 16 september 2007 @ 20:28:
[...]


Het is niet de keuze tussen CSS of font tags met tables. Het is CSS + DIVs voor layout of CSS + DIVs + strikt waar nodig TABLEs. Ik begrijp dat je nu nog gillend wakker wordt 's nachts van je laatste 'kun je dit even aanpassen' in OSCommerce opdracht, maar er is nog een tussenweg

Je weet precies wat ik bedoel Gewoonweg "semantisch" werken. Volgens mij gaf Crisp het ook al aan, in een uitzonderlijke situatie is het helemaal geen ramp om een tabel te gebruiken waar het niet semantisch correct is, als je dat enkele uren scheelt in ontwikkel tijd.

Het punt is simpelweg.. in het jaar 2007 nog steeds tabellen voor layout gebruiken is niet juist, hoe je het ook probeert uit te leggen. Alle claims -tegen- het gebruik van semantisch werken komen neer op onkunde of een gebrek aan kennis (niet kunnen vs. nog niet kunnen).

En juist als je dan een klant krijgt die met 16 pagina's aan documentatie komt waar ze zelfs eisen dat je een bepaalde doctype gebruikt (en daarop valideert!), je houdt aan WCAG standaarden en weet ik veel wat allemaal nog meer...

... dan haal je net iets makkelijker een opdracht van ~4000 uur binnen. (Project nog in offerte fase, meerdere candidaten, kan de naam van de klant wel over PM vertellen.)

[Pkunk]

offtopic:
Ik vraag me af wat een zoekmachine van een tabel-pagina met daarin 'correcte html' maakt.. Een tabel met daarin netjes <h1> <ul> etc... waar ze horen.

[BikkelZ]

Ja Google indexeert dat prima, veel van de meest interessante pagina's op het internet hebben nog een TABLE layout. UL, H1 en dat soort kreten blijven gewoon interessant voor zoekmachines.

Blue-eagle schreef op maandag 17 september 2007 @ 08:55:
En juist als je dan een klant krijgt die met 16 pagina's aan documentatie komt waar ze zelfs eisen dat je een bepaalde doctype gebruikt (en daarop valideert!), je houdt aan WCAG standaarden en weet ik veel wat allemaal nog meer...

... dan haal je net iets makkelijker een opdracht van ~4000 uur binnen. (Project nog in offerte fase, meerdere candidaten, kan de naam van de klant wel over PM vertellen.)

Ja hoho, als een klant eist dat er semantisch en volgens standaarden gewerkt wordt ben ik de laatste die gaat lopen protesteren. Maar dan moeten ze wel accepteren dat niet iedere layout zomaar haalbaar is. Het is soms het een of het ander.

Als een klant een typische tabel layout eist van me die met CSS gebrekkig of niet in te vullen is, dan gebruik ik misschien een tabelletje om dat te bereiken. Iemand die met spacer.gif of met een soort Droste-table layout aan komt kakken gaat nog enige uren de nabrandende aanwezigheid van mijn voet onder zijn reet voelen.

[ Voor 7% gewijzigd door BikkelZ op 17-09-2007 09:21 ]

[Dutch_guy]

Erkens schreef op zondag 16 september 2007 @ 14:44:
[...]

Natuurlijk maakt dat uit, als je altijd op ouderwetse manieren blijft werken zul je nooit vooruitgang krijgen. Verder is het niet handig om stront eigenwijs op je "eigen" manier te blijven werken terwijl je weet dat dit "fout" is, vooral niet tegenover je collega developers. En al helemaal niet tegenover je eventuele opvolgers die met de rommel blijven zitten.

Een klant is vaak snel tevreden, maar zou die ook tevreden zijn als hij wist dat je hem oude troep zit te verkopen?

Mail jij even naar nu.nl en naar marktplaats.nl en vertel ze dat ze met oude troep werken.

Nu.nl gebruikt nog tabellen en marktplaats.nl nog frames...

Oei, oei wat een schande zeg...

Wil niet zeggen dat ik alles in tabellen doe, maar als het daarmee sneller gaat, dan doe ik dat gewoon.

[disjfa]

Dutch_guy schreef op maandag 17 september 2007 @ 09:59:
[...]
Wil niet zeggen dat ik alles in tabellen doe, maar als het daarmee sneller gaat, dan doe ik dat gewoon.

Het gaat hier over richtlijnen en waar webdevvers naar moeten streven. Niet "maar zij doen het ook" gezever. Tuurlijk zijn er zat devvers die nog rotzooi uitpoepen. Tuurlijk zijn er nog zat klanten die een onmogenlijk design willen.

Maar dat zegt niet dat de devvers alleen maar met oude meuk moet werken.

[crisp]

Dutch_guy schreef op maandag 17 september 2007 @ 09:59:
[...]


Mail jij even naar nu.nl en naar marktplaats.nl en vertel ze dat ze met oude troep werken.

Nu.nl gebruikt nog tabellen en marktplaats.nl nog frames...

Oei, oei wat een schande zeg...

Die sites zijn daardoor ook minder goed toegankelijk voor bijvoorbeeld blinden en slechtzienden, dus ja: eigenlijk is dat een schande

[Erkens]

Dutch_guy schreef op maandag 17 september 2007 @ 09:59:
Nu.nl gebruikt nog tabellen en marktplaats.nl nog frames...

Oei, oei wat een schande zeg...

Hier vergeet je alleen even dat dit sites zijn die al een behoorlijke tijd bestaan en refactoren kost erg veel geld vandaar dat het waarschijnlijk ook niet gedaan wordt. Hier op t.net heeft het ook heel lang geduurd voordat het "beter" was, bij een compleet nieuw design. (ook hier zie je dat onderhoud veel tijd kost met tables )

Wat ik dus ook vooral bedoel zijn nieuwe sites, daar kan je eigenlijk niet meer mee aankomen met de oudere technieken.

Wil niet zeggen dat ik alles in tabellen doe, maar als het daarmee sneller gaat, dan doe ik dat gewoon.

sneller is niet altijd beter, blijkbaar ben jij gewoon een persoon die geen eer van zijn werk wilt, je staat blijkbaar niet voor 100% achter je product.

[Dutch_guy]

Dat is echt flauwekul wat je nu roept. Ik ga altijd voor 100% tevredenheid bij mijn klanten. De klant maakt het echt niets uit hoe de achterkant eruitziet. Jammer dat de discussie nu zo een kant op gaat...

[disjfa]

Dat is het verschil van wat klanten willen en wat de norm is. Dat omdat klanten niet weten dat er een norm is mensen die aan hun laast lappen is nog altijd niet de manier.

Mijn klanten willen ook altijd rotzooi. Als ik ze dan uitleg wat een webpagina is dan gaat er vaak een berg verbeterd worden vanuit de planning en het idee achter de site. Klanten opvoeden noemen we dat. En dat er uiteindelijk soms troep in de site zit gebeurt natuurlijk altijd.

[Blue-eagle]

Dutch_guy schreef op maandag 17 september 2007 @ 09:59:
[...]


Mail jij even naar nu.nl en naar marktplaats.nl en vertel ze dat ze met oude troep werken.

Nu.nl gebruikt nog tabellen en marktplaats.nl nog frames...

Oei, oei wat een schande zeg...

Dus omdat jij toevallig onder de indruk bent van websites die het helemaal verkeerd doen (in het geval van Marktplaats om een heel andere reden) vind jij het goed om slecht werk te leveren?

Wat een enorm foute manier van redeneren zeg.

Wil niet zeggen dat ik alles in tabellen doe, maar als het daarmee sneller gaat, dan doe ik dat gewoon.

Laat ik het simpel samenvatten: met die instelling zou je bij mijn werkgever geen baan krijgen Tabellen zijn in extreme gevallen (nadat je de ontwerper al in z'n gezicht hebt gemept voor zijn rot ontwerp) een noodoplossing, maar nooit een oplossing.

* Blue-eagle moppert iets over het gilde wat toch wel een goed idee lijkt, ineens...

[OkkE]

Dutch_guy schreef op zondag 16 september 2007 @ 12:50:
Word hierboven anders wel gesuggereerd hoor. Ik verzin dat niet zelf.

Ik word een beetje moe van deze discussie, die altijd weer eens een keer voorbij komt. Doe gewoon je ding zoals jij het wil doen.

Wat maakt het uit hoe een ander dit doet ? Voor mij telt maar 1 ding en dat is een tevreden klant en hoe ik dat voor elkaar krijg maakt echt niets uit, en zeker voor een ander niet.

Ik wordt een beetje moe van mensen die niet (willen) inzien dat er een betere manier is als tabellen. Tot op zekere hoogte vind ik dat je inderdaad moet doen wat je wil, maar front-end webdesign is mijn werk, en daarnaast ook (een van de) mijn passie. Waarbij ik het jammer vind als mede 'webdesigners' eigenwijs zijn, en met tabellen bezig blijven -- en dan bedoel ik niet de mensen die zo af en toe één tabel gebruiken omdat het veel sneller/makkelijker is, maar de table-tag-soup-people.

Voor mij tellen er twee dingen; een tevreden klant én het gevoel dat ik een goede website heb opgeleverd. Als ik een huis laat bouwen ben ik ook blij wanneer het staat, hoe het ook gebouwd is - hier heb ik geen verstand van. Als ik later vraag of mijn kozijn vervangen kan worden, en ik krijg te horen dat dan de hele voorgevel opnieuw moet, ben ik niet blij.

[Dutchmega]

Het ligt nogal aan de situatie maar een aantal redenen waarom ik nette XHTML/CSS maak:

- Layouts maken in XHTML/CSS gaat sneller (vrij weinig verschillen in browsers als je XHTML Strict gebruikt)
- Minder dataverkeer (en kleiner hoopje XHTML om te onderhouden)
- Makkelijk andere layout toevoegen (ook printversie etc)

De meeste mensen die niet XHTML/CSS willen gebruiken vinden het teveel werk, snappen het niet of vinden het te moeilijk...

[Pkunk]

Misschien is dit niet helemaal de goede richting van deze discussie, maar ik vraag me toch af in wat voor mate correcte semantiek invloed heeft op zoekmachines. Als je 2 precies dezelfde sites hebt waarbij de 1 is opgebouwd uit tables en de andere nette html/css of er dan echt merkbaar verschil in zit. Volgens mij is het voornamelijk hoeveel er naar je site word verwezen en hoevaak je je content wijzigd. Ik gebruik het namelijk vaak als argument tegen tabellen.

[Erkens]

Dutch_guy schreef op maandag 17 september 2007 @ 10:39:
Dat is echt flauwekul wat je nu roept. Ik ga altijd voor 100% tevredenheid bij mijn klanten. De klant maakt het echt niets uit hoe de achterkant eruitziet. Jammer dat de discussie nu zo een kant op gaat...

Zouden die klanten ook tevreden zijn als ze wisten dat je oude technieken gebruikt zoals tabellen terwijl er "nieuwere" betere technieken zijn, vooral met het oog op de onderhoudbaarheid?

overigens wel jammer dat jij dat "Jammer dat het nu zo gaat" erbij zet, juist _dat_ haalt het topic omlaag

[Dutch_guy]

In 9 van de 10 gevallen onderhoud de klant zelf de website middels een CMS. Dan kan je ook niet voorkomen dat men tabellen gebruikt.

[OkkE]

Timlog schreef op maandag 17 september 2007 @ 11:15:
Misschien is dit niet helemaal de goede richting van deze discussie, maar ik vraag me toch af in wat voor mate correcte semantiek invloed heeft op zoekmachines. Als je 2 precies dezelfde sites hebt waarbij de 1 is opgebouwd uit tables en de andere nette html/css of er dan echt merkbaar verschil in zit. Volgens mij is het voornamelijk hoeveel er naar je site word verwezen en hoevaak je je content wijzigd. Ik gebruik het namelijk vaak als argument tegen tabellen.

Er is eens een onderzoek naar gedaan. Zover ik weet was dit in het voordeel van semantische HTML, maar ik kan het helaas nergens terug vinden.

Volgens mij is het wel zo, dat wanneer je binnen je tabel-layout toch de H1 t/m H6, ULs, etc gebruikt, en geen 6 lagen diep geneste tabellen gebruikt, het verschil niet zo heel groot is. Maar belangrijk feit blijft natuurlijk, dat het niet alleen voor SEO is, het semantisch bouwen. Er zitten meer voordelen aan.

[OkkE]

Dutch_guy schreef op maandag 17 september 2007 @ 11:37:
In 9 van de 10 gevallen onderhoud de klant zelf de website middels een CMS. Dan kan je ook niet voorkomen dat men tabellen gebruikt.

Dat hangt van je CMS af, van de content die de klant toevoegd, en hoe goed je de klant hebt "opgevoed".

Wij gebruiken een CMS waarbij men per paragraaf toevoegd, waarbij men kan aangeven hoeveel kolommen deze heeft. Nogsteeds krijgen ze wel een complete editor, maar we leggen mensen uit dat ze niet rechtstreeks van andere websites of Word documenten moeten knippen-plakken, en dat tabellen bedoeld zijn voor tabulaire data. In praktijk blijkt dat onze klanten (voornamelijk MKB) zich hier goed aan weet te houden.

Natuurlijk kan je ook kiezen voor een WYSIWYM editor (let op de M), die correcte HTML afleverd.

Daarnaast is het ook nog eens zo; ook al gebruikt de klant wel tabellen waar betere alternatievern zijn: dat is het "maar hun doen het ook" argument. Dat vind ik een slecht argument. Je moet er alles aan proberen te doen om de website zo netjes en goed mogelijk te maken, dat de klant het daarna verziekt is niet altijd tegen te gaan, maar voor mij zeker geen reden om dan zelf ook maar "te prutsen".

^{* Prutsen klinkt misschien iets te negatief, maar als je stug (veelvuldig) gebruik maakt van tabellen, waar prima alternatieven voor zijn, dan ben je imho gewoon een prutser.}

[disjfa]

Dutch_guy schreef op maandag 17 september 2007 @ 11:37:
In 9 van de 10 gevallen onderhoud de klant zelf de website middels een CMS. Dan kan je ook niet voorkomen dat men tabellen gebruikt.

En dat geeft weer een reden om niet semantisch te devven.

Leuk dat je telkens excuses zoekt om "niet normaal" te devven. En leuk dat jij dat handig vind. Maar die heeft echt niets meer met deze discussie te maken.

[Dutch_guy]

Ik had juist begrepen dat er geen verschil was in ranking.

Hoe dan ook. Ik ben ook de slechtste niet.

Ik ben nu bezig met een nieuwe website en zal die deze keer geheel volgens de "nieuwe technieken" opbouwen, i.p.v. deels met tabellen.

En nee, ik zoek geen excuses zoals hierboven wordt gesuggereerd, dat slaat nergens op. Je kan het ook overdrijven en helemaal doorslaan.

[ Voor 21% gewijzigd door Dutch_guy op 17-09-2007 11:59 ]

[Erkens]

Dutch_guy schreef op maandag 17 september 2007 @ 11:37:
In 9 van de 10 gevallen onderhoud de klant zelf de website middels een CMS. Dan kan je ook niet voorkomen dat men tabellen gebruikt.

Ah, jij hebt ideale klanten die nooit een feature X erbij willen ofzo? Afgezien het feit dat een CMS niks te maken heeft met de html pagina opzich, alleen maar (zoals de naam al doet vermoeden) met de content.

[imp4ct]

Dutch_guy schreef op maandag 17 september 2007 @ 11:37:
In 9 van de 10 gevallen onderhoud de klant zelf de website middels een CMS. Dan kan je ook niet voorkomen dat men tabellen gebruikt.

Ik vind deze opmerking ook een beetje raar. Een CMS zorgt ervoor dat de klant z'n site kan onderhouden, maar dit dan binnen het kader van een CMS. 'k Ken weinig klanten die in hun CMS zelf nog vlug even zelf een HTML pagina gaan maken, 't kan natuurlijk vermits vele WYSIWYG editors in CMS-en HTML feature toelaten, maar gho.. ergens.. ik denk dat 99% van alle klanten dit nooit gaan gebruiken, gewoon omdat ze er geen verstand van hebben en er zich niet aan wagen.

Trouwens, 'k ben zo'n webdevver die liever zoveel mogelijk afschermt van de gebruiker. 'k Probeer de gebruiker altijd die ene stap voor te zijn, steek je als devver meer tijd in, maar helpt je eens zoveel in the end.

[We Are Borg]

Dutch_guy schreef op maandag 17 september 2007 @ 10:39:
Dat is echt flauwekul wat je nu roept. Ik ga altijd voor 100% tevredenheid bij mijn klanten. De klant maakt het echt niets uit hoe de achterkant eruitziet.

Die achterkant kan wel relevant zijn als het op andere dingen aankomt: onderhoudbaarheid, toegankelijkheid, indexering, etc. Allemaal punten die bij semantische markup als pluspunten naar voren komen. Dan weet die klant van jou niet dat die 'achterkant' brak is, maar dit zijn wel de directe gevolgen.

Imo is het ook professionaliteit van de webdevver die er gewoon voor zorgt dat hij correct werk levert, ook aan de spreekwoordelijke 'achterkant' zoals jij het noemt

[BtM909]

\[Disc.] Tabellen vs. semantisch design (anno 2009)* kan daar verder