[HTML] traditioneel gebruik "not done" waarom?

Geen idee, heb er zelf nooit problemen mee eigenlijk.

In de w3c specs zijn tabellen aangegeven voor het weergeven van data, niet voor de opbouw van een pagina.
Zo kun je volgens de specs bijvoorbeeld geen hoogte van een tabel aangeven. (Binnen IE werkt 't wel overigens)

Ofwel; Om inter-platform/cross-browser compatibility te garanderen kun je beter de w3c specs handhaven... Heb je met alle browsers een fatsoenlijk weer te geven site...

DSCX

Ik vind frames idd kut maar tabellen niks mis mee hoor

quote:

Op dinsdag 26 oktober 2004 16:15 schreef markiemark het volgende:
Het is bij iedereen die wel eens iets maakt duidelijk: frames en tabellen zijn not done. we moeten tegenwoordig divjes gebruiken maar waarom? met tabellen kan je toch ook prima sites maken? iemand nog andere voorbeelden?

Het is een denkfout dat je alles in DIVs zou moeten doen, dat is dezelfde fout die mensen eerder maakten toen ze allerlei layout zaken met frames probeerden bereiken, daarna met tabellen...

Wat je moet doen is semantisch correcte HTML gebruiken..

oftewel de markup gebruiken die de beste omschrijving is voor de daarin gevatte data:

dus lijsten in UL, OL of DL; kopteksten in H1, H2 etc, alinea's in P, adresgegevens in ADDRESS, zaken die benadrukt worden moeten in broodtekst in EMPH, links in A (en niet teveel met javascript-links wrken, ook geen hele brokken laten genereren door javascript, als dat niet nodig is), citaten in CITE of evt BLOCKQUOTE, programmeercode in CODE, preformateerde tekst in PRE ...etc.etc

kijk bijvoorbeeld eens hier:
http://www.brainstormsandraves.com/articles/semantics/structure
of zoek op semantics via google.

quote:

of kan iemand vertellen waarom deze vormen van HTML gebruik not done zijn?

Omdat je een techniek gebruikt op een wijze die zo niet bedoeld is:
HTML is niet bedoeld voor grafische weergave, om kleurrtjes aan je teksten mee te geven, lettertypes in te stellen en afbeedlingen in de achtergrond te zetten ..

Wat je ziet is dat mensen die er net mee beginnen vaak dat idee hebben, soms hierin ondersteund door wat ervaring in een visuele editor, waar ze met klik-en-sleep makkelijk zulke dingen kunnen instellen..
Binnen de korste keren lopen ze echter tegen problemen op die ze niet voorzien, verschillende personen zzien opeens op een andere computer, met misschien een andere browser, of zelfs enkel andere scherminstellingen, compleet andere versies van de opmaak die degene in de visuele editor had ingesteld en dacht te publiceren.

Zodra iemand tegen die problemen oploopt, moet hem duidelijk gemaakt worden dat zijn visie op HTML niet klopt, dat zijn fout in zijn denken en verwachtingen ligt..
En dat hij, wil hij de problemen voorkomen, zijn denkwijze over HTML en het gebruik van het WWW moet aanpassen.

[ Bericht 32% gewijzigd door RM-rf op 26-10-2004 16:32:21 ]

ik gebruik altijd tabellen

Ik heb niks tegen tabellen

1 voordeel van layout via tabellen: ze zien er in elke browser hetzelfde uit.

Met css zit je vaak te pielen, en terwijl je je precies aan de standaard houdt, maakt IE (en heel soms een andere browser) er een potje van. (Lees: horizontale scrollbalk, witruimte tussen div's, plaatjes die net iets verschuiven. Dan werkt 't in 3 browsers, maar in eentje weer niet)

quote:

Op dinsdag 26 oktober 2004 18:40 schreef kobold het volgende:
1 voordeel van layout via tabellen: ze zien er in elke browser hetzelfde uit.

Met css zit je vaak te pielen, en terwijl je je precies aan de standaard houdt, maakt IE (en heel soms een andere browser) er een potje van. (Lees: horizontale scrollbalk, witruimte tussen div's, plaatjes die net iets verschuiven. Dan werkt 't in 3 browsers, maar in eentje weer niet)

Dat ligt aan de beperktheid van je kennis, met CSS is juist alles te sturen, bv via padding, margin, display, float e.d.
eventuele afwijkingen van browsers of Quirks zijn makkelijk te omzeilen, meestal zonder dat je daarvoor je code moet wijzigen..

Anderszijds leveren tabellen meer problemen op, als je deze poogt toe te passen om layout-doeleinden te bereiken, zo wordt hoogte eigenlijk niet ondersteund (msie doet het soms wel, maar niet altijd dus, ook hierin kent msie weer uitzonderingen waar hoogte voor tabellen niet ondersteund wordt), en is het erg lastig, zoniet onmogelijk om goede positionering te bereiken, aangezien het table-model met col- en rowspan regelmatig voor ongewenste effecten zorgt en breedtes en hoogtes voor table-cellen lastig 'vast' in te stellen zijn.

Natuurlijk is het zo dat het soms handig kan lijken om aan het werken met teveel tables voor layout-doeleinden vast te blijven houden, ook al levert het veel meer en onoverzichtelijkere code op dan semantisch correcte HTML, en eenieder heeft ook volledig het recht om eraan vast te blijven houden..
enkel levert het je op de lange termijn meer problemen op en de enige winst is dat je vast kunt houden aan een werkwijze die een tijd terug (toen men nogrekening moest houden met browsers als nn4x of lager en msie3) best wel handig was, op de langere termijn levert het je enkel meer probemen en incompatibiliteit op.

Ik werk wel met tabellen om div's mooi naast elkaar te postioneren (dus kolommen te maken). In de tabel plaats ik dan een div. Is dat dan eigenlijk ook erg fout?

tabellen groeien mee met de inhoud. Strak uitlijnen is dus een crime. divjes geef je gewoon de positie op waar je ze op het scherm moeten komen. Je kan dus zelfs de ene div de ander laten overlappen.

Probeer dat maar eens met tabellen.

Overigens om tekst te positioneren gebruik je natuurlijk gewoon tabellen.

Frames zijn not done omdat ze simpelweg veel beperkingen met zich meebrengen. onder andere de indexering in zoekmachinens. immers wil je dat je mensen op je volledige site terecht komen, dus niet op alleen de index of alleen de content

quote:

Op dinsdag 26 oktober 2004 18:40 schreef kobold het volgende:
1 voordeel van layout via tabellen: ze zien er in elke browser hetzelfde uit.

Dat is op zich al een denkfout waar veel mensen vanuit gaan. Een pagina moet er om de een of andere reden in alle browsers exact hetzelfde uitzien.

Nieuwsflash: Dat gaat je niet lukken. Een pagina ziet er in Opera 7.60 bij een schermresolutie van 1600x1200 niet hetzelfde uit als in Lynx op 800x600, en ook niet als PocketIE op 170x220. Het gaat er niet om een pagina te maken die er overal hetzelfde uitziet, het gaat erom een pagina te maken die het overal gewoon doet. En daar is CSS uitermate geschikt voor, in tegenstelling tot tabellen.

Bovendien zijn er ook voordelen die veel praktischer van aard zijn:

Veel kleinere bestanden. Hoe groter de site, hoe meer bandbreedte dit bespaart.

Een table-based site vergt veel meer onderhoud. Als je wilt dat mensen je pagina's netjes uit kunnen printen, zul je printvriendelijke versies moeten maken, als je de layout wilt veranderen zul je een geheel nieuwe tabelstructuur op moeten zetten, als slechtzienden de tekstgrootte veranderen gaat je tabel zich ook raar gedragen, etc etc.

Tabellen zijn opzich niet zo'n ramp, als frames zijn, maar 1 groot verschil tussen layers&tabellen is wel, dat, en vooral merkbaar bij grotere pagina's, tabellen toch meer bytes innemen dan layers..

En als je erg veel last lijkt te hebben van dat het er in IE compleet anders uit ziet dan in Moz/Op, zet dan deze regel bovenaan je document:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

scheelt een hoop

probeer maar eens:

<html>
<head>
<style type='text/css'>
BODY {
background-color: black;
margin: 0
padding: 0
}
DIV {
background-color: red;
padding: 10px;
margin: 10px;
height: 100px;
width: 100px;
}
</style>
</head>
<body>
<div>Test</div>
</body>
</html>

En aanschouw het verschil met en zonder eerdergenoemde regel in IE

quote:

Op woensdag 27 oktober 2004 00:56 schreef markiemark het volgende:

[..]

kan ik je niet helemaal gelijk in geven want tabellen kan je ook opmaken met css..

Moet je tabellen eens gaan schalen naar een ander disign of voor een ander medium.

quote:

Op woensdag 27 oktober 2004 00:56 schreef markiemark het volgende:
kan ik je niet helemaal gelijk in geven want tabellen kan je ook opmaken met css..

Tabellen geven een pagina al een bepaalde layout, ongeacht of je het opmaakt met CSS of HTML4-attributen.

zie trouwens ook http://www.csszengarden.com, iets dat absoluut onmogelijk is als die pag in Table's is opgebouwd.

quote:

Op woensdag 27 oktober 2004 01:00 schreef daReaper het volgende:
Tabellen zijn opzich niet zo'n ramp, als frames zijn,

[..]

Frames zijn soms best oke te gebruiken.

quote:

Op woensdag 27 oktober 2004 01:00 schreef daReaper het volgende:
En als je erg veel last lijkt te hebben van dat het er in IE compleet anders uit ziet dan in Moz/Op, zet dan deze regel bovenaan je document: .......

Mja, dat is gewoon het verschil tussen quirks- en stricte modus. Alleen IE6 zal in stricte modus overgaan btw.

Verder snap ik niet echt wat de bedoeling van deze discussie is. Iedereen kan wel zijn mening vertellen over het gebruik van HTML, maar daar schieten we natuurlijk niks mee op

Als mensen nu eens inzien dat het gewoon veel beter is om je aan een standaard te houden (zowel kwa syntax als kwa semantiek), dan zou het internet al een stuk minder fucked-up zijn.

De eerste die nu nog zn bek open trekt over iets anders dan divs of tabellen tieft een week op.

quote:

Op woensdag 27 oktober 2004 01:00 schreef daReaper het volgende:
Tabellen zijn opzich niet zo'n ramp, als frames zijn, maar 1 groot verschil tussen layers&tabellen is wel, dat, en vooral merkbaar bij grotere pagina's, tabellen toch meer bytes innemen dan layers..

En als je erg veel last lijkt te hebben van dat het er in IE compleet anders uit ziet dan in Moz/Op, zet dan deze regel bovenaan je document:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

scheelt een hoop
[...]
En aanschouw het verschil met en zonder eerdergenoemde regel in IE

Pas op met het aanraden van zogenaamde 'wondermiddeltjes' als je enkel naar het resultaat kijkt en niet naar de reden waarom iets zou werken of niet...

met een doctype kun je aangeven dat je code valide zou moeten zijn volgens een bepaalde standaard-DTD. De door jouw genoemde doctype verwijst naar XHTML 1.0 Strict..
de onderliggende code moet dan eigenlijk ook strict zijn (wat bij de als voorbeeld genoemde code niet zo is, ik mis nl. een TITLE).

Is de code valide en staat er een doctype zullen msie6 en mozilla, opera en khtml-based browsers een strakke rendering navolgen, die extra strak is, in dit geval zal bv msie6 een boxmodel toepassen dat de CSS-standaard van W3C volgt en niet het boxmodel dat zij zelf hiervoor navolgden.

staat de doctype er niet, (of, bij msie, als er een comment-regel voor de doctype staat, wat wel mag, maar waar msie6 over struikelt) gaan deze browers over in een 'Quirks-mode';
wat betekent dat zoveel mogelijk de browser poogt compatible te zijn met vorige versies, en dus ook soms non-standard-gedrag van voorgaande browsers te simuleren..

Zo zal msie6 met valide xhtml en de bijbehorende doctype het niet meer toestaan dat de scrollbars gekleurd kunnen worden met proprietaire css
probleem is echter wel dat msie6 in non-quirksmode enorm veel bugs en slechte impletaties bevat, en het eigenlijk aan te raden is deze te vermijden (bv door wel vlide XHTML te maken maar voor de doctype een comment-regel te zetten, enkel msie spring dan in Quirks-mode, terwijl mozilla en de rest dat niet doen)..

Het probleem waaraan jij refereet, wat betreft het verschil in uitzien tussen Mozilla en msie is het boxmodel-probleem.
Dat komt omdat er een klein, maar veel invloed hebbend verschil is tussen hoe msie het boxmodel interpreteerd en dit volgens de standaard zou horen .
zie verder http://evolt.org/article/(...)/17/60369/index.html
tip nr. 6 gaat over het box model

[ Bericht 9% gewijzigd door RM-rf op 27-10-2004 12:41:43 ]

quote:

Op woensdag 27 oktober 2004 16:14 schreef markiemark het volgende:
ok ik ben weer ff serieus, sorry Slarioux..

maar wat ik me dan afvraag RM-rf, hoe zit het dan met het includen van php bestanden. ik heb nu een index pagina gemaakt met xhtml en php. in die pagina include ik een anders php bestand, deze is opzichzelf niet xhtml-strict. (geen html, head, title of body tags) maar wordt deze wel strict zodra hij geinclude is in de index pagina? de html in het geinclude bestand is wel xhtml (<br />)

het enige wat gevalideerd zal worden door de browser en wat de Quirk/non-quirksmode zal triggeren, is de output:
dus in theorie is er geen probleem.

de vraag is misschien wel of het qua backend voldoet:
je ziert dat veel backend systemen zelf ook vormen van validatie nodig hebben, om zo een betere beheer of bugtracking mogelijk te maken;
dan kan het zin hebben om ook de wijze van includen zo op te zetten dat jezelf werkdocumenten kunt valideren
enkel zal die waarschijnlijk niet als xhtml hoeven te valideren, met XSL kun je bv ook delen van html-documenten genereren, en dan is eerder noodzakelijk dat de XSL valideert.

Je kunt al je php bestanden natuurlijk domweg xml laten genereren aan de hand van een zelf geschreven "scheme" zodoende is de output van een "include bestand" helemaal geen xhtml, maar wel valide xml.

Belangrijke teksten plaatsen onder een

<div id="Layer1" style="position:absolute; left:29px; top:18px; width:43px; height:30px; z-index:1; visibility: hidden;">

En dat heeft met dit topic te maken, omdat....?

quote:

Op woensdag 27 oktober 2004 16:23 schreef RM-rf het volgende:
enkel zal die waarschijnlijk niet als xhtml hoeven te valideren, met XSL kun je bv ook delen van html-documenten genereren, en dan is eerder noodzakelijk dat de XSL valideert.

XSL valideren?
XSL opzich heeft volgens mij weinig met semantiek te maken, en kwa syntax moet het wel goed zijn, anders geeft de parser een dikke foutmelding, toch?