[xhtml] correct gebruiken

[bgever]

Beste tweakers, ik ben in verschillende topics bepaalde dingen tegen gekomen, waardoor bij mij de vraagtekens naar boven kwamen.
Zo kwam vaker de discussie over data/opmaak aan de praat.

Nu is mijn vraag, hoe zit het nu precies, want ik kom er helemaal niet meer wijs uit.
Zo is bijv. het P element beter om een alinea te beschrijven, i.p.v. het DIV element te gerbuiken. Maar wanneer moet je dan de grens tussen een P element en een DIV element gaat leggen? Tabellen zijn ervoor om data te bevatten en dienen niet als opmaak gebruikt te worden. Maar hoe wil je dan bijv. twee kolommen naast elkaar zetten, die dienen als opmaak?

Kortom, waar ligt de grens tussen data en opmaak. En welk element moet ik wanneer gebruiken. (neem bijv. het P voorbeeld)

Wordt dit ergens duidelijk uitgelegd (liefst op NL) of zou iemand het mij kunnen uitleggen. XHTML 2.0 zou een duidelijk verschil tussen data en opmaak moeten waarborgen, hoe zit dat, en is het dus al verstandig om op XHTML2 over te stappen?

Ik ben ten einde raad, maar wil toch wel graag correct XHTML 1.1 gebruiken, en anders XHTML2.

[ Voor 1% gewijzigd door bgever op 07-04-2003 17:12 . Reden: typo ]

[Verwijderd]

oikoyama schreef op 07 april 2003 @ 17:08:
Nu is mijn vraag, hoe zit het nu precies, want ik kom er helemaal niet meer wijs uit.
Zo is bijv. het P element beter om een alinea te beschrijven, i.p.v. het DIV element te gerbuiken. Maar wanneer moet je dan de grens tussen een P element en een DIV element gaat leggen?

DIVs gebruik je voor een conceptuele scheiding van stukken content. Een P is ook een scheiding van content, maar een meer specifieke, speciaal voor tekst.

Tabellen zijn ervoor om data te bevatten en dienen niet als opmaak gebruikt te worden. Maar hoe wil je dan bijv. twee kolommen naast elkaar zetten, die dienen als opmaak?

Met CSS.

Kortom, waar ligt de grens tussen data en opmaak. En welk element moet ik wanneer gebruiken. (neem bijv. het P voorbeeld)

De grens tussen data en opmaak is waar het overgaat van wat het is in hoe het wordt weergegeven. Die weergave kan zowel op het scherm, als op papier, als gegenereerde spraak, etc. zijn.
http://www.playgarden.com/w3c/TR/xhtml1/overview.html

[Verwijderd]

En op w3 staat gewoon per element waar ze voor gebruikt dienen te worden Voorbeeld: het P element

[bgever]

Nu heb ik bijvoorbeeld op mijn homepage (www.oikoyama.net) tabellen gebruikt om de pagina in te delen. Dit is nu correct XHTML volgens de W3C validiator. Maar is dit dan werkelijk correct? Of zou ik dan alles moeten gaan indelen met DIV's? En hoe moet ik dat dan doen, d.m.v. CSS het element op de juiste plek te plaatsen? Hiervoor zou ik bijv. "postition: absolute; left: 200px; top: 20px;" gebruiken, maar dit is geen CSS1. Wordt dit dan in alle bekende browsers goed weergegeven?
Dan zou ik dus ook bijv. de header DIV helemaal onderaan in het document kunnen zetten, maar d.m.v. CSS helemaal bovenaan op de visuele pagina kunnen zetten, als ik het goed begrijp.
Of heeft iemand misschien een voorbeeld van zijn of haar eigen site waar dat zo gedaan is?

* bgever begint een beetje anders over de W3C validiator te denken, als die wel zegt dat het correct XHTML1.1 is, maar in werkelijkheid niet zo is

[ Voor 3% gewijzigd door bgever op 07-04-2003 19:47 . Reden: typo ]

[Yoozer]

De W3C-validator checkt op een correcte syntax - niet op je content of je ontwerpkeuzes. DIV's worden gelijk neergezet en zijn efficienter op hun plaats te zetten terwijl een tabel pas wordt neergezet als hij helemaal is ingeladen. Kies jij voor tabellen, dan kan er ontwerptechnisch misschien naar gefronst worden, maar als de syntax correct is is er 'technisch' niks mis mee .

[ Voor 6% gewijzigd door Yoozer op 07-04-2003 20:56 ]

[bgever]

Maar dan nu mijn grote vraag: Is het dan verkeerd om het met tabellen te doen? Ik vind het gemakkelijker werken, en zelfs duidelijk. Als ik nl maar uit elke bron moet gaan raden hoe het er uiteindelijk uit ziet, is niet gemakkelijk om mee te werken.
Maar als het aan te raden is om met alleen maar DIV's te werken, dan ga ik dat natuurlijk doen. Dus wat is de beste keuze?

[Verwijderd]

* FreekWillem zat net over het zelfde thema na te denken.

Vind het werken met tabellen erg makkelijk. en houd er ook van dat hij de pagina ook in programma's zoals in dreamweaver nog goed te bekijken zijn.

want volgens mij gaat het hier op den duur heen, dat we weer alles moet intypen. nu maak ik een tabel aan, en doe ik hem handmatig corrigeren.

[Denker]

Tabellen zijn heel erg handig om mee te werken. Alleen uitkijken dat je geen foutjes maakt, dat geldt overigens sowieso voor HTML.
En met tabellen kun je heel veel dingen, die je met div-jes of andere dingen minder goed lukken (is mijn ervaring.....)

[tomato]

Vergeet even dat tot nu toe bijna altijd tabellen zijn gebruikt voor layout in websites en browser issues.

Bedenk nu waarom je tabellen zou gebruiken voor plaatsing van elementen, bijvoorbeeld het onderste deel van de GoT layout (topic/reply buttons, breadcrumbs en forumselector). Ik kan geen geldige reden verzinnen? De content van je tabel is dan namelijk helemaal geen data die de structuur van een tabel heeft. De colommen en rijen hebben geen enkele relatie en geen andere betekenis dan het positioneren van de elementen. Met andere worden, het onderste deel van de GoT layout is geen tabel (ja, als je in dit geval naar de HTML source kijkt wel).

Vanuit dat oogpunt is het dus erg lelijk om tabellen te gebruiken voor iets anders dan het aangeven van structuur en relaties in elementen.

Bedenk steeds wat je wilt bereiken: wil je structuur en betekenis aangeven, of wil je iets op een bepaalde manier weergeven? In het laatste geval doe je dit met CSS.

[Blaise]

Maar hoe wil je dan bijv. twee kolommen naast elkaar zetten, die dienen als opmaak?

Dat is structureren, niet opmaken.

[tomato]

Blaise schreef op 07 April 2003 @ 22:54:
[...]
Dat is structureren, niet opmaken.

Nou, in de meeste gevallen (waar men hier iig op doelt denk ik) niet

Je kunt bijvoorbeeld de GoT layout als 3-koloms zien (links wit, midden content, rechts wit). De meeste mensen zullen inzien dat dit geen goed voorbeeld is om met tabellen op te maken. Je geeft geen betekenis en geen zinvolle structuur aan de inhoud. Dat doe je dus met CSS.

Een voorbeeld waarbij een tabel imho wel op zijn plaats is, is het reactie formulier op GoT. Ik bedoel dan de smilies met hun shortcut characters. Eigenlijk zou je de images in een kolom en de character shortcuts in een andere kolom willen hebben. Als je dat vervolgens in de layout wilt krijgen zoals hier het geval is ga je met CSS verder, al weet ik niet of dat in dit geval goed mogelijk is (volgens mij moet je in ieder geval rows met columns verwisselen, wat imho nog wel te verdedigen is).

Stel dat er geen character shortcuts bij de smilies stonden. Dan wordt een typisch geval van een opsomming, een list dus. Een list met als list-items smilie images is met CSS ook prima neer te zetten zoals hier het geval is.

[Blaise]

Ik baseerde mijn post op de vraag van Oikoyama, die alleen twee kolommen naast elkaar wil, en niet om opmaakredenen maar vanwege de structuur.

[ Voor 13% gewijzigd door Blaise op 07-04-2003 23:17 ]

[tomato]

Blaise schreef op 07 April 2003 @ 23:15:
Ik baseerde mijn post op de vraag van Oikoyama, die alleen twee kolommen naast elkaar wil, en niet om opmaakredenen maar vanwege de structuur.

Volgens mij zit ie toch echt te doelen op een twee-kolommen opmaak, net zo iets als het 3-kolommen voorbeeld van GoT dat ik gaf.

[Blorgg]

Ik vind het eigenlijk gewoon onzin dat je tabellen niet voor opmaak zou mogen gebruiken. Tabellen zijn misschien wel statischer dan CSS (als je ze correct gebruikt tenminste), maar ze werken wel gewoon altijd. Dat kan van CSS nog niet gezegd worden, niet in IE in ieder geval. En dat is toch de browser die nog steeds het meest gebruikt wordt en waarin je site het zeker goed in dient te doen, tenzij je natuurlijk een hele selecte doelgroep bedient

Dus als je CSS wilt gebruiken omdat het 'netter' staat is prima, maar als je hiervoor tabellen gebruikt dan is dat net zo goed imo. Hadden ze die tabellen maar niet zo 'functioneel' moeten maken

[Blaise]

Volgens mij zit ie toch echt te doelen op een twee-kolommen opmaak, net zo iets als het 3-kolommen voorbeeld van GoT dat ik gaf.

GoT gebruikt 3 kolommen, met 2 kolommen lukt dat niet, daarom denk ik dat het om het structureren ging.

Als ik het goed heb gaat dit dus meer om de interpretatie van de beginpost.

[ Voor 55% gewijzigd door Blaise op 07-04-2003 23:33 . Reden: ophelderen ]

[bgever]

@Tomato:
Ik heb hier enkele voorbeelden, waarvan ik denk dat het slim of verstandig is om kolommen te gebruiken. Als dit niet het geval is, zou jij mij dan kunnen uitleggen waarom dan niet?

1) Neem de post-reply pagina. Je had zelf al de smilies als voorbeeld gegeven.
Nu zie je dat het lichtblauwe content gedeelte is opgedeeld in twee gedeeltes. Links het gedeelte waar de beschrijving over een onderdeel staat (bijv: "Bericht:" of "Smilies:") en aan de rechterkant staat dan het onderdeel, bijv. het invoerveld, of de smilies. Hier zo het dus bijv. slim zijn om tabellen te gebruiken, want anders ben je nog wel ff bezig om alles op de juiste plek te positioneren.

2) Neem mijn voorbeeld van de pagina in delen te splitten splitten. Heel simpel dan, drie delen langs elkaar. deel1: menu, deel2: content, deel3: help/info. Nu maak je dus een tabel, met 3 kolommen en één rij. In elke cel zet je dan de verschillende delen.

3) Stel, je wilt zoekresultaten opsommen (bedenk Google look). Alleen dan met een plaatje erlangs. Je maakt dan een tabel, met twee kolommen en één rij. In de linker cel zet je het plaatje, en in de rechter cel zet je de URL, info, cache link, etc.

Meerdere toepassingen om een tabel te gebruiken kan ik dan eigenlijk op dit moment niet bedenken, omdat het ook op te lossen is d.m.v. DIV's. Vat ik 'm nu een beetje, of zit ik op het verkeerde pad?

[SillyJW]

De computer is een dom ding.
Voor een computer is een css-opmaak logischer te doorgronden dan een tabel-opmaak.

Sterker nog, ik begrijp het zo ook beter. Ik kan niet zien aan een <td> in de source wat de betenis is van dat stukje tekst binnen de gehele pagina. Bij een juist gebruik van de correcte html-elementen wel. Als een computer van een stukje tekst beter de logische betekenis kan doorgronden lijkt het me logisch dat dit voordelen met zich meebrengt.

En volgens mij hebben julie het meer over positionering dan over opmaak.

[tomato]

oikoyama schreef op 07 april 2003 @ 23:34:
Ik heb hier enkele voorbeelden, waarvan ik denk dat het slim of verstandig is om kolommen te gebruiken.

Je bedoelt met tabellen neem ik aan

1) Neem de post-reply pagina. Je had zelf al de smilies als voorbeeld gegeven.
Nu zie je dat het lichtblauwe content gedeelte is opgedeeld in twee gedeeltes. Links het gedeelte waar de beschrijving over een onderdeel staat (bijv: "Bericht:" of "Smilies:") en aan de rechterkant staat dan het onderdeel, bijv. het invoerveld, of de smilies. Hier zo het dus bijv. slim zijn om tabellen te gebruiken, want anders ben je nog wel ff bezig om alles op de juiste plek te positioneren.

Ja, ik denk dat het gebruik van een tabel hiervoor redelijk te verdedigen is. Al is het ook heel aardig zonder op te lossen met CSS (vaste width en float:left voor de beschrijvingen). Dat heeft toch nog mijn voorkeur in dit geval, hoewel ik het met je eens ben dat het een vaar geval is. Misschien heeft iemand anders goede argumenten waarom het juist wel of juist niet met een tabel zou 'moeten'?

Als je het met een tabel positioneert krijg je problemen met de smilies, want van genestte tabellen krijg ik hoofdpijn (en het mag niet in XHTML strict).

2) Neem mijn voorbeeld van de pagina in delen te splitten splitten. Heel simpel dan, drie delen langs elkaar. deel1: menu, deel2: content, deel3: help/info. Nu maak je dus een tabel, met 3 kolommen en één rij. In elke cel zet je dan de verschillende delen.

Vind ik dus een slecht voorbeeld. De enige reden voor jou om de tabel te gebruiken is de positionering. Maar het is geen tabel, het zijn gewoon drie aparte onderdelen van je website. Verder hebben ze geen onderlinge relatie, er is ook geen structuur in te zien.
Plaats dit bijvoorbeeld in drie <div>'s die je vervolgens met CSS (float of positioning) naast elkaar zet. Beide CSS oplossingen (float en positioning) hebben nadelen (lees bijvoorbeeld waarom Wired voor positioning koos). Maar ik gaf al aan, ik ga uit van een wereld zonder browser-issues en CSS tekortkomingen. In de praktijk heb je dus met meer dingen rekening te houden.

3) Stel, je wilt zoekresultaten opsommen (bedenk Google look). Alleen dan met een plaatje erlangs. Je maakt dan een tabel, met twee kolommen en één rij. In de linker cel zet je het plaatje, en in de rechter cel zet je de URL, info, cache link, etc.

Dat is best een aardige voor een tabel. Het gaat immers duidelijk om een aantal data-sets met daarin dezelfde relaties. Het invullen in een tabel geeft een duidelijke en betekenisvolle ordening van de data. Ik zou echter wel voor meer kollommen kiezen, liefst voor ieder veld een. Ik hoop dat je met CSS dan wel het een en ander kan frutselen aan de positioning ervan.

[bgever]

@Tomato:
Die laatste post is duidelijker dan ooit, en ik ben dan ook helemaal opgehelderd, en overtuigd. Het koste me nogal wat moeite om door de bomen het bos te zien, maar uiteindelijk is het me dan toch gelukt (sorry voor de lange duur). Vooral dat artikel van Wired.com is zeker een goeie, daar heb ik nl veel van opgestoken. Ik begrijp nu het verschil tussen de content en het design. In princiepe zou je de html zo moeten maken, dat er totaal geen design in staat, en dat alles, maar dan ook alles eigenlijk door CSS op het scherm gezet moet worden. Tenminste, dat is eigenlijk de beste manier, en ook de eerste gedachte achter XHTML. In princiepe dient de HTML puur om de gegevens en data aan te geven, en de style-scheten maken er dan een aangenaam documentje van voor in de browser.
Vooral het verhaal van Wired.com over tabellen gaf de doorslag. Daarin begon ik me ineens te herkennen, en door het voorbeeld vatte ik het ineens. Toen pas snapte ik de werkelijke ged8te achter tabellen.
Echter een brandende vraag bleef me hangen, waarom geneste tabellen niet toegestaan zijn.

Ook gaf het artikel mij de aanmoediging om toch nog maar eens CSS(2) opnieuw door te nemen, en alle mogelijkheden er maar eens goed na te kijken, aangezien die je hele lay-out in princtiepe bepaald. Vooral het gedeelte over positioneren en floats moet ik goed doornemen.
Ook zie ik het grote voordeel van XHTML2 nu in, en in princiepe is XHMTL2 gewoon wat het had moeten zijn, alleen dan met extra XML. Over dat laatste ben ik ook zeer te spreken, want ik zie mij al met een XML parser van andere sites bijv. data plukken, doordat alles mooi aangegeven staat. En dankzij de style-sheets heb je geen last van wazige lay-out-meuk die tussen de code staat.
* bgever kan niet wachten totdat XHMTL2 aanbevolen wordt, en dat HTML verbannen wordt, omdat iedereen het verkeerd leert.

Zo, ik begin nu erg zin te krijgen om al mijn sites te gaan redesignen, en om te zetten naar goed XHTML. En dan denk je plots aan je CMS dat je voor je school aan't maken bent - dat geheel in brakke HTML4 is geschreven - wat je bijna voltooid hebt, en dan ben je blij dat je over een paar maandjes je diploma in handen hebt en alles achter je kan laten (grmbl, maar goed dat die IN leraar van ons niet veel van (X)HTML af weet )

Thnx, deed me goed.

[ Voor 2% gewijzigd door bgever op 08-04-2003 01:25 . Reden: typo's ]

[2]

Blorgg schreef op 07 April 2003 @ 23:28:
Ik vind het eigenlijk gewoon onzin dat je tabellen niet voor opmaak zou mogen gebruiken. Tabellen zijn misschien wel statischer dan CSS (als je ze correct gebruikt tenminste), maar ze werken wel gewoon altijd. Dat kan van CSS nog niet gezegd worden, niet in IE in ieder geval.

Volgens mij moet je het topic (vooral tomato's posts) nog maar eens doorlezen want je hebt het niet helemaal begrepen.

Het gaat er niet om wat werkt in welke browser, het gaat erom wat de bedoeling is van xml, xhtml en aanvankelijk ook van html - namelijk het "labellen" van data, oftewel met tags de verschillende (types) elementen in de data aangeven. Dan kun je wel gaan roepen dat je dat onzin vindt, en dat vind ik verder prima, maar theoretisch ben je dan verkeerd bezig.