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.
@jan
Zou nog wel kunnen... of ik het wil proberen is een 2e...
Tabellen kosten meer html en dus wellicht voor sommige makkelijker controleerbaar...
Maar div's hebben veel meer mogenlijkheden en veel minder html...
Hetgeen het ook weer ingewikkelder kan maken natuurlijk...
"Bij een div layout heb je meer vrijheid (je kunt het over elkaar, veel meer posities, en zowel de ene div wel mee laten scrollen terwijl je de andere laat staan.)"
Als je bijv. een 'sticky footer' wilt, je content moet scrollen, én je content server-gegeneerd is of uit een database gehaald moet worden, ben je inderdaad aangewezen op div's-layout.
Maar met normale file-content kun je met een iframe op de contentplek hetzelfde bereiken met tabellayout. En voordat er nu weer allerlei mensen beginnen te schreeuwen: framesgebruik is zelfs in de officiële W3C-XHTML goedgekeurd: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">;.
[Het probleem van dan niet verder kunnen surfen omdat er door Google geen navmenu 'meegeleverd' wordt met het content-file, is met scripting heel simpel opgelost (wordt dan met/in moederpagina getoond).]
Verder, wat is vrijheid als je bedrijf niet rendeert omdat je medewerkers uren en uren zitten te klooien met een layout die ze met tabellen binnen 10 minuten hadden gemaakt? Want laten we wel wezen: 'liquid designs' zijn met tabellen veel makkelijker dan met div's. Net als designs met borders.
V.w.b. snelheid van downloaden: maak maar eens een layout in div's en in tabellen, en kijk wat het bestandsgrootteverschil is. Je zult zien dat het in relatieve zin al weinig of niets uitmaakt, en in absolute hoeveelheid bytes gaat dat echt helemaal nergens over. Zelfs niet met inbelverbindingen.
Dat wil niet zeggen dat je nu maar drievoudig geneste layouttabellen moet gebruiken. De meeste 'nestingen' zijn overbodig, omdat die tabellen goed vervangen kunnen worden door div-rechthoekjes. Maar dat is iets heel anders dan de kruistocht tegen elke vorm van layouttabellen die nu gaande is.
@wouter en Jonathan: wonders der logische redeneringen! Echte kandidaten voor de studie Informatica!
@Jonathan: Je weet een zeldzaam laag niveau te bereiken, ik had je hoger ingeschat. Valt me tegen.
@Frank: Geef eens een paar voorbeelden. Een theorie zonder onderbouwing gaat echt stand houden tegenover de dagelijkse praktijk. En met 'praktijk' doel ik dan vooral op het niet kunnen onderhouden van tabellen.
Daarnaast ben ik erg benieuwd naar het aantal jaren relevante werkervaring met html en css.
Jij hebt de klok horen luiden, maar weet niet waar de klepel hangt.
Waar zijn je voorbeelden om je verhaal sterk te maken nergens. Iedereen ontkracht het al jaren en jij gaat nu nog je best doen om iets wat belachelijk onoverzichtelijk - voor layouts- is de hemel in prijzen.
Hoe onoverzichtelijk is het om je layout op deze manier leesbaar te maken?
Dit is nog klein... en moet je nagaan dat overal code instaat.
Dit vind ik al een reden om het nooit MEER - jaja ook ik heb het gebruikt, zelfs frames - te gebruiken buiten dat het kutter is om een tabellenlayout crossbrowser te maken. Met divs is het vaak al een klotewerk.
Het komt overal alsof je weinig praktijk ervaring hebt (zowel met divs als met tabellen).
Als jij je sites goed en netjes met tabellen kan scripten nou heel mooi, maar dan zul je niet al te moeilijke websites maken. Zie link van Jannetje Koehoorn.
@jan
Zou nog wel kunnen... of ik het wil proberen is een 2e...
Hoi Lode,
de vraag was niet aan jou gericht maar aan de TS. Toch ben ik wel geïnteresseerd in je antwoord. Je hoeft het niet letterlijk na te bouwen. Ik wil alleen weten hoe je het aan zou pakken. En uiteraard ben ik ook benieuwd naar het antwoord van de TS.
Designs met borders zijn toch niet zo heel erg ingewikkeld?
.border {
border: #333333 1px solid;
}
Daar is weinig moeilijks aan, net zoals een liquid layout eigenlijk. Het geen dat de drempel is voor divs is het opnieuw aan moeten leren van het maken van een layout. Dit kost tijd, energie en kan soms veel te lang duren als alle terminalogie nog onduidelijk bij je is. Toch is het zeker de moeite waard. Alle redenen om het wel aan te leren zijn hierboven al (al is het soms wat kinderachtig) genoemd. Een goed voordeel van het opbouwen van je layout in tabellen nog niet.
Deze is in ieder geval al supersimpel, met tabellen: http://www.csszengarden.com/?cssfile=/202/202.css&page=0 . Zie mijn antwoord aan TJVB voor de manier waarop. En verder is het ook niet zo moeilijk. Gewoon diverse layouts maken, en dezelfde content laten inladen. Net als dat ze op CSSZenGarden doen. Alleen op een iets andere manier.
Verder zou ik het waarderen als je me gewoon met naam adresseert. Doe ik bij jou ook.
@Arjan:
Ik heb niet gezegd dat layouttabellen sneller zijn, dat je er meer mee kunt of dat ze efficiëntere code opleveren. Ik heb gesteld dat de kruistocht tegen tabellayout op moet houden, omdat het gelijkwaardig is aan div's-layout. Niet gelijk, wel gelijkwaardig.
De snelheid van pagina's worden steeds belangrijker (Meer grafische elementen, snellere verbindingen. Mensen zijn niet gewend om te wachten. Bij een kleine site merk je het niet, zoals al was gezegd, maar heb je wat heel groots dan merk je het wel degelijk): Met een tabellen opmaak heb je meer code die niet wordt gecashed. (all die td's en tr's, weer een table in een table wat ook nog eens slecht is voor de overzichtelijkheid van je code.)
Daarnaast heb je bijvoorbeeld je menu links staan, maar die moet naar rechts. Met divs verander je de float gewoon van links naar rechts en voila, menu staat rechts. (je hoeft helemaal niet meer in de HTML te zijn, om je hele layout om te gooien. Jij moet met je tabellen een nieuwe layout maken.)
Wat jij voor reactie geeft op Jan Koehoorn, is nogal simpel niet.. Je snapt blijkbaar de vraag niet. Maak met tabellen maar eens een standaard HTML die je met alléén het aanpassen van de CSS op net zulke diverse manieren weer kan geven als de HTML van CSSzenGarden. Dat lukt je niet, want je hebt niet de vrijheid als dat je met divs wel zou hebben.
Gelijkwaardig is voor mij:
- Even gemakkelijk om mee te werken : Niet het geval
- Even gemakkelijk om de layout om te gooien : Niet het geval
- Code niet groter dan met DIVS : Niet het geval
- Code net zo overzichtelijk: Niet het geval
[edit]
TS betekend niets minder dan TopicStarter. (er zijn hier meerdere Franken op het forum. Dus dit is wel zo duidelijk) Een vrij duidelijke en veel gebruikte term op het forum.
Ik ben wel benieuwd naar je ervaring inderdaad.. Ik ken de tijd nog dat Frames "het nieuwste/ beste waren" En ook de tijd daarna dat steeds met tabellen werd gewerkt. DIVS vind ik veel gemakkelijker. Je kan ook bijna alles gewoon hergebruiken (Je HTML) en even de CSS aanpassen en voila, op het oog een heel nieuwe site.
[/edit]
Er kan dus geconcludeerd worden dat de kruistocht tegen tabellen gestaakt kan worden, en dat div's-layout niet principieel beter is dan tabellayout.
Volgens w3schools:
HTML <div> tag
Definition and Usage
The <div> tag defines a division/section in a document.
Een <div> is dus niet meer dan een division of een section. Dat mag je vertalen naar afdeling en sectie. De ene sectie hoeft niks met de andere sectie te maken hebben, dat is het mooie van divs. Dat gaat je in een tabel nooit lukken, de hele zooi staat in 1 tabel en heeft dus per definitie een verband met elkaar. Zelfs als je geneste tabellen hebt, dat maakt de ellende alleen maar groter.
Server Side Includes, leuke uitdrukking, maar dat zegt 10x niks over de html en css die uiteindelijk in de browser terecht komt.
Ik moet er ook niet aan denken om met XSLT een XML te gaan parsen naar een tabel (of verzameling tabellen), dat is smeken om een gigantische bak werk. Daar krijg ik de handjes echt niet voor op elkaar, dat zullen de klanten echt niet accepteren/betalen.
Een pagina is geen tabel en zal het ook niet worden. In een pagina kun je tabellen hebben, dat is niks bijzonders, maar heeft op zich ook niks met opmaak te maken.
