Zoals beloofd, een nieuwe draad over de vraag of tabellen principieel beter zijn dan div's, voor layout.
De volgende argumenten laten zien dat dat niet het geval is:
1. Er is een veel betere manier om layout en content te scheiden.
Div's-layout (niet te verwarren met CSS-layout want tabellen zijn ook te stijlen met CSS) is ontworpen om layout en content te scheiden, zodat men slechts één of hooguit een paar bestanden hoefde te veranderen als de site een nieuwe layout behoefde. Daarmee voorzag het in een grote behoefte, want 30 of meer pagina's op dezelfde manier verbouwen was een zeer geestdodende taak.
Echter, daar is inmiddels een nog veel mooiere methode voor ontwikkeld: server-side includes (SSI's). Met SSI's kunnen niet alleen navigatiemenu's maar ook content-files geïncludeerd worden. In gewoon Nederlands betekent dit dat men één moederpagina aanmaakt, inclusief navigatiemenu, waar telkens andere inhoud in geladen wordt. Voor de layout van zo'n moederpagina is het niet nodig om div's te gebruiken. Dan kan ook met tabellen.
Het is een illusie - zeker ingeval van geneste div's - om te denken dat met slechts het veranderen van het externe stijlblad met div's-layout elke andere layout voor de hele site bereikt kan worden. Daar zitten grote beperkingen aan.
En wat als men halverwege de 30 te maken geïntegreerde div's-pagina's (de 'oude' manier) iets wil toevoegen? Dan moet men alsnog 15 pagina's gaan aanpassen, terwijl men een div's-layout heeft...
Deze moeilijkheden gelden niet als men het systeem van server-side content includes gebruikt. De moederpagina waarvan meestal net zo goed uit een tabellayout mag bestaan.
2. De vraag of tabellen bedoeld zijn voor layout is irrelevant.
Waar het om gaat is of een methode gelijkwaardige resultaten oplevert, en of hij webmastervriendelijk is. Tabellen en div's leveren niet precies dezelfde resultaten op. In sommige gevallen kan een layout alleen met div's gemaakt worden, als men een overzichtelijke, intuïtieve code wil houden. Maar het omgekeerde geldt evenzeer.
Bovendien bestonden tabellen al ruim vóórdat div's ontworpen werden, en heeft men jarenlang layouts gemaakt met tabellen zonder dat er een haan naar kraaide.
Tot slot van dit argument zijn er twee soorten tabellen: de normale tabellen, ook geschikt voor vele layouts, en de tabellen speciaal geschikt voor tabulaire data. De laatste kenmerken zich door het opgebouwd zijn uit o.a. <thead>, <tbody>, <tfooter> en <caption>.
3. Pagina's met een tabellayout worden niet significant langzamer gedownload en gerenderd dan pagina's met div's-layout.
Verhalen over dat oude computers vastliepen op pagina's met geneste tabellen kunnen genegeerd worden, omdat er toen nog geen div's bestonden, en er geen enkele reden is om te geloven dat die computers niet net zo zeer vastgelopen zouden zijn op geneste div's.
4. Zoekmachines indexeren pagina's met tabellayout net zo goed als met div's-layout.
Voor zoekmachines zijn tabellen tabellen. Of die nu voor layout of tabulaire data gebruikt worden, de inhoud wordt net zo goed geïndexeerd en gevolgd.
5. Voor screenreaders is een veel mooiere oplossing dan div's-layout.
Een bijkomend voordeel van div's-layout t.o.v. tabellayout was dat de site sneller te lezen was met screenreaders. Echter, met de volgende methode zullen de blinden nóg gelukkiger zijn:
* Neem in de summary van de layouttabel de volgende tekst op: "Deze tabel is een layouttabel. Voor screenreaders is een aparte introductie- en navigatiepagina gemaakt. Het adres is (de URL)."
* Op die navigatiepagina, die alleen platte tekst bevat, schrijf je hoe de site is opgebouwd als dat nodig is, en geef je directe links naar de content-files, die ook weinig meer dan platte tekst hoeven te bevatten.
Er kan dus geconcludeerd worden dat de kruistocht tegen tabellen gestaakt kan worden, en dat div's-layout niet principieel beter is dan tabellayout.
Precies, en dat soort kansloze en door niemand gebruikte code ontlokt dus alleen maar een dikke flame.
Dat iemand een mening heeft en deze graag wil verkondigen, ik heb daar zelf ook wel eens last van..., dat is leuk en aardig, maar kom wel met echte argumenten en echte voorbeelden van dagelijkse praktijk.
Kortom, ik zit nog steeds te wachten op échte voorbeelden. Komen die niet, dan weet ik genoeg, mijn kennis is dan nog steeds helemaal up-to-date.
Dat er geen reacties zouden komen in de trend van "Je hebt helemaal gelijk, en we zullen nooit meer zo achterlijk doen tegen iemand die iets over een tabel vraagt", dat had ik wel verwacht. Maar dat er zó stompzinnig gereageerd zou worden, dat had geloof ik niemand verwacht.
Ik herhaal (nog) één keer wat ik al geschreven heb, en dan stop ik met deze discussie. Enkele woorden doe ik dikgedrukt, want jullie kunnen het klaarblijkelijk anders niet goed lezen:
<repeat>
Er zijn twee principiële manieren om een layout te maken die je later makkelijk kunt veranderen: (a) geïntegreerde pagina's die bestaan uit div's + één extern stijlblad, en (b) een parentfile waarin steeds andere content wordt geladen.
In beide methodes hoef je in principe maar één bestand (hooguit een paar) te veranderen om een site van 200 pagina's in één keer een nieuwe look te geven. Maar wat als je iets aan de layout wilt toevoegen, of er iets van wilt verwijderen? Juist. Dat gaat niet met methode a. In ieder geval niet iets toevoegen. Zengarden of geen zengarden. En dat gaat wel met methode b. Verder is het verschuiven van div's (methode a) aan beperkingen onderhevig. Je kunt niet willekeurig elke andere layout maken met slechts het veranderen van een extern stijlblad.
</repeat>
De rest is een kwestie van logisch redeneren en/of redelijk zijn. Ik ga dat echt niet allemaal voorkauwen, want jullie durven de stukken van tegenstanders toch niet normaal door te lezen, dus dat zou ik dan voor niets doen.
Verdiep je nog maar eens in Divs en CSS. Je kan een div positioneren waar je wil, zelfs BUITEN de zichtbare Lay-Out. Iets toevoegen kan met DIVS net zo gemakkelijk (lees mijn reactie nu eens, dan had je dat ook geweten)
Logisch redenerend heb je met divs meer vrijheid, en ook meer mogelijkheden voor je layout. Hou jij het maar lekker bij je tabellen, als je daar gelukkig van wordt. Jij vind het prettiger, omdat je divs blijkbaar niet snapt (zie wederom mijn vorige reactie op jou) Dan moet je dat lekker blijven doen, maar probeer anderen die het WEL op de manier volgens de standaarden proberen te leren, en de mensen die hen dat op de standaard manier proberen te leren, dan met rust te laten en niet te overtuigen van jou "foute" (andere/ alternatieve, niet voldoen aan de standaard) methode.
Mwahahaha, ik krijg zin om weer zo'n puberale reactie te geven, mara laat ik nu even zakelijk blijven.
Ten eerste: waarom zouden wij naar je luisteren? Je WEIGERT zelf naar ons te luisteren, en dan zeg je ook nog eens dat wij NIET willen LUISTEREN! Omgekeerde wereld noemen kleine kinderen dat.
Ten tweede: heb je onze reacties niet gelezen? Al jouw opmerkingen zijn al ontkracht. Over de beperkingen van het veranderen van de layout zonder de DIV structuur te veranderen: wees nou niet zo stronteigenwijs en kijk even naar CSS Zen Garden. Dat zijn allemaal andere layouts, met precies dezelfde DIV/HTML structuur.
Ten derde: ik vind je vreselijk kinderachtig. Nu ga je vast zeggen dat mensen naar mijn eerste reacties moet kijken, hoe kinderachtig ik wel niet ben, maar jij bent kinderachtig op een andere manier.
Ten vierde: kijk eens naar een grote website, of die DIV's of tabellen gebruiken: Microsoft.com: DIV's!!! En meneertje meent dat die mensen bij Microsoft domme lullen zijn, die niet weten hoe HTML werkt? Of is meneer een MS-hater? Kijk dan naar Apple.com, DIV's!!! Of is meneer zo'n Linux-type? Ubuntu.com, DIV's!!! Heb je nog wat te zeggen verder?
Nu ik zo veel zin krijg om je uit te schelden, druk ik snel op [Plaats bericht] voor ik het echt ga doen...
Frank, je kunt wel in herhaling blijven vallen, maar voorlopig heb ik nog geen enkel live voorbeeld gezien van jouw geweldige idee. Jouw idee kan echt wel helemaal geweldig zijn, maar voorlopig wil bij mij het kwartje niet vallen. Het sluit ook totaal niet aan bij mijn ervaring in het bouwen en onderhouden van websites. (5 jaar ervaring, top 10 bedrijven van NL en tegenwoordig zelfstandig)
Zengarden toont bv. aan dat content en layout uitstekend zijn te scheiden dankzij div's. Dé eis aan een layout, is dat je niks aan de html-code mag veranderen om toch een (compleet) andere layout te maken. Dat is iets wat je met tabellen echt niet gaat lukken.
Geef nu eens echt een paar goede voorbeelden van populaire websites die zijn gebouwd zoals jij dat hier beschrijft. Desnoods bouw je zelf een site, wie weet wordt het een succes en kun je ons ook overtuigen van jouw goede idee.
Succes!
Ps. Die screenreader kun je beter vergeten, dat was toch echt een misser ;)
Mijn persoonlijke ervaring van de nadelen van tables zijn dat je
1) uiteindelijk tegen het rekenwerk aanloopt. Het aantal velden moet in iedere regel gelijk zijn, of je moet bezig met colspan en rowspan. Wil je inhoud gaan toevoegen, en zit je met een redelijk grote en complexe pagina (ik denk aan de voorpagina van bijvoorbeeld Yahoo) dan levert dit je waarschijnlijk net zoveel hoofdpijn als CSS hacks & margin, padding en 100% horror.
2) Krijg je een probleem, zoals dat de velden niet op de plek vallen waar jij ze verwacht, dan is dat lastig op te lossen. Je moet of gaan gokken, of je hele tabel opnieuw doorrekenen.
CSS en divs is ook niet pure glorie, en ook hier loop je tegen het probleem aan dat het lastig kan zijn om een div op de goeie plek te krijgen en dat fouten moeilijk naar een oorzaak te herleiden zijn. Maar dit is niet een reden om tabellen te gaan gebruiken op zich, aangezien die aan hetzelfde probleem lijden. Voordeel van CSS & divs is dan weer dat je met een tooltje als CSSEdit (Mac) of eventueel Firebug kan uitproberen om hem goed te krijgen, zonder te hoeven schuiven met de inhoud van je bestanden.
Over het punt of tabellen bedoelt zijn voor layout of niet relevant is (ik wil hier toch even op in gaan, mede omdat zo weinig zich hier aan gewaagd hebben) is ook betwistbaar. Ik ken een aantal bedrijven die (succesvol) webrichtlijnen als uitgangspunt hebben en daarmee ook hun klanten lekker maken. In zo'n situatie maakt het wel degelijk uit of je de tabel voor data of voor layout gebruikt, want doe je dit verkeert dan voldoet je site niet aan de richtlijnen en geef je de klant niet wat je hebt beloofd.
Ander punt is dat wanneer je de tags gebruikt waar ze voor bedoelt zijn (p voor paragrafen, h# voor titels) alternatieve browsers zoals Lynx, of 'nieuwe' browsers zoals Safari 3 met webclips deze semantiek kunnen uitbuiten voor nieuwe functies. Safari 3 zal bijvoorbeeld een div automatisch als 'container' voor een webclip gaan zien, terwijl een tabel niet automatisch gepakt wordt. Het loont dus om met de mainstream opvatting mee te gaan om zo voordeel te halen uit de functies die anderen bieden voor deze mainstream regels.
Nu we het over Lynx hebben gehad, Lynx is een handige simulator van een zoekmachine-spider of een screenreader, omdat het geen CSS of Javascript ondersteunt. Je krijgt dus de layout te zien zoals hij zonder opmaak zou verschijnen. Hier zie ik weer een pluspuntje voor de divs tegenover de tabellen. Navigatie wil je immers altijd bovenaan hebben, omdat dit de links zijn die mensen het meest gebruiken, de items waar het meeste behoefte aan is. In mijn HTML zal ik dus altijd eerste de site-titel neerzetten, en dan de navigatie. Dan komt er de inhoud, en dan uiteindelijk onderaan de minder belangrijke content zoals bijvoorbeeld een lijst met relevante artikelen, of een lijst met nieuwe topics. Met tabellen is de plaats waar de inhoud wordt weergegeven afhankelijk van de plek waar je de inhoud in de HTML neerzet. Met divs en CSS ben je hierin veel vrijer en zou je de navigatie zonder problemen rechts kunnen plaatsen en de inhoud links, terwijl je met tabellen dan de td voor de inhoud boven de td voor het menu moet plaatsen.
Waarom is de plek van de inhoud binnen je HTML van belang? Terug naar Lynx. Lynx geeft de HTML weer zoals die is, zonder opmaak. Tabellen worden onder elkaar gezet. Je merkt al, voordat ik bij mijn navigatie kom moet ik nu eerst de hele inhoud voorbij scrollen. Zoekmachines werken hetzelfde, en lezen ook een pagina van boven naar beneden. Omdat veel mensen zo hun pagina's opbouwen, is Google bijvoorbeeld geöptimaliseerd voor menu's bovenaan, en hij zal deze ook apart weergeven, of van hoger belang (= betere pagerank) vinden.
Om nog even verder te gaan met de screenreaders, en de oplossing die je aandraagt: Persoonlijk ben ik iemand van de 'progressive enhancement', wat kortaf betekent dat je een basispagina serveert en deze met Javascript en CSS van extra's voorziet. Zo krijgt iedere bezoeker een oplossing die bij hem past. Wat jij doet is eigenlijk precies anders om. Jij schotelt ze meteen het beste voor - een pagina compleet met flitsende layout - en biedt ze een alternatief voor wanneer ze er niets mee kunnen. Een beetje vergelijkbaar met de situaties van vroeger. "Gebruik je geen Internet Explorer, klik dan hier voor een lelijke variant". Je onderkent niet alleen de kracht van de andere browser (Lynx bijvoorbeeld, wat HTML zelfstandig buitengewoon prettig kan weergeven) maar beledigt ook de bezoeker. "Jij bent minderwaardig, jij moet hier heen". Zo zeg je het niet, maar zo komt het wel over. En dat terwijl het technisch niet nodig is.
Verder wil ik iedereen toch oproepen om niet met argumenten te komen als "zoek een hobby" of "ben je wel lekker". Hiermee ondermijn je eigenlijk zijn redeneervermogen en maak je hem dus in weze belachelijk. Dat komt niet alleen over als arrogant, maar naar mijn idee (althans, wanneer dat soort argumenten tegen mij gebruikt worden) ben je dan blijkbaar te zwak om zelf de persoon te overtuigen van jouw ideeën. En dan is de vraag, ligt dat aan jouw overtuigingskracht, of heb je jezelf in een discussie gemengd waar je eigenlijk te weinig vanaf weet, en dus blijkbaar de verkeerde houding inneemt (namelijk dat jij het allemaal wel weet) en daarmee dus zelf de fout in gaat. Zou je in een debat met het argument "ben je ziek of zo" komen, dan heb je eigenlijk al in 1 klap verloren.
Daarbij vraag ik me dan weer af waarom deze site een cookie aanmaakt met je gebruikslevel EN een cookie met je gehashte wachtwoord... Maar goed beetje offtopic...
