HTML of XHTML voor de herintredende hobbyist

Eind jaren negentig heb ik via wat online tutorials basiskennis van HTML opgedaan en daarmee een paar eenvoudige websites gebouwd.
Nu wil ik weer wat tijd gaan steken in webdesign zodat ik iig m'n huidige website een make-over kan geven en in de toekomst misschien voor derden een site in elkaar kan zetten. Ik heb me ondertussen een beetje ingelezen over wat tegenwoordig wel en niet gewenst is qua markup e.d. maar over het gebruik van XHTML ipv HTML lijken de meningen verdeeld.
De laatste onderwerpen die ik op GOT kon vinden over het onderwerp stammen uit 2005. Ik vroeg me af of ik mezelf op dit moment beter XHTML of HTML aan kan leren?

Ik denk dat het verstandiger is om het bij HTML4.01 te houden, en te zien wat er met HTML5 gebeuren gaat.

Qua betekenis of gebruik verschilt het praktisch niet. De voornaamste verschillen zijn syntactisch.

Cheatah wijzigde dit bericht 07-01-2008 18:39 (32%)

Eens met Cheatah. Lees onder meer onderstaande artikelen. Heel veel verhalen over XHTML zijn mythes.

http://www.webdevout.net/articles/beware-of-xhtml
http://annevankesteren.nl/2004/08/xhtml

quote:

Cheatah schreef op maandag 07 januari 2008 @ 18:39:
De voornaamste verschillen zijn syntactisch.

Dat ben ik toch niet met je eens, of je moet puur doelen op XHTML als text/html waarvan we allemaal wel weten dat dat 'considered harmfull' is.

Nog een linkje dan maar: http://lachy.id.au/log/2005/12/xhtml-beginners

Hoewel de meeste mensen er niet mee eens zullen zijn
Zou ik gaan xhtml. Waarom?
De syntax is consistenter (al zijn er maar kleine verschillen), en dus makkelijker te leren.
Het moet dan wel als text/html verstuurd worden, waar sommige mensen zich nogal druk over kunnen maken

quote:

1. Authors write XHTML that makes assumptions that are only valid for
tag soup or HTML4 browsers, and not XHTML browsers, and send it as
text/html. (The common assumptions are listed below.)

2. Authors find everything works fine.

3. Time passes.

4. Author decides to send the same content as application/xhtml+xml,
because it is, after all, XHTML.

5. Author finds site breaks horribly. (See below for a list of
reasons why.)

6. Author blames XHTML.

bron: 'considered harmfull'
Sorry, ik weet dat het hier niet echt de plek is voor de discussie hier, maar als je dit denkt ben je toch echt dom imo.

quote:

e syntax is consistenter (al zijn er maar kleine verschillen)

In HTML kan je even consistent werken als in XHTML. Een HTML-beginner kan je gewoon leren dat tags altijd netjes gesloten moeten worden, tenzij het een leeg element betreft, om maar iets te noemen.

quote:

Het moet dan wel als text/html verstuurd worden

XHTML als HTML versturen is juist niet consistent.

Blaise wijzigde dit bericht 08-01-2008 00:06 (24%)

on a sidenote: XML-like syntax (o.a. de nutteloze 'self-closing-tag' syntax als in <br />) zal hoogstwaarschijnlijk in HTML5 gewoon conforming worden. Daar hoort imo echter nog wel een grote rode knipperende waarschuwing bij dat XML-like syntax van HTML nog geen XHTML maakt, en dat bepaalde dingen die in X(HT)ML wel werken in XHTML als text/html *niet* werken (denk aan <script /> of <img></img>) - daarom vind ik het zo belangrijk dat je mensen niet moet leren dat XHTML niets meer is dan HTML met XML-syntax.

XHTML als text/html biedt geen voordelen boven HTML omdat het door browsers gewoon als HTML behandeld wordt. De nadelen zitten 'm vooral in het feit dat mensen denken met een XML-taal bezig te zijn terwijl dat niet het geval is, en validators en browsers ze daar ook niet op (kunnen) wijzen met alle gevolgen van dien.

99% van de huidige XHTML-pagina's worden als text/html verstuurd en hadden dus net zo goed een HTML4.01 DTD kunnen hebben. De overgrote meerderheid van die pagina's zal niet goed werken als het als application/xml+xhtml geserveerd zou worden aan een XHTML-capable browser. So much voor het succes en het nut van XHTML...

Voor dagelijks gebruik is er werkelijk geen enkel verschil. Zolang het syntactisch correct is zal het de browser worst wezen, en zal het ook in de voorzienbare toekomst gewoon blijven werken.

De reden om HTML te gebruiken om te zien wat HTML5 doet lijkt me onzin, sowieso komt er een XHTML-versie van HTML5, en ik hoop nog steeds dat de klotskoppen van de WhatWG eens wakker worden en enige realiteitszin krijgen m.b.t. de problemen van webapps. Maar dat is een andere discussie

Blijft over wat je zelf fijner vindt. XHTML 1.0 is for all intends and purposes identiek aan HTML4, dus daar merk je eigenlijk niets van. Persoonlijk geef ik XHTML 1.x de voorkeur boven HTML4, want XML is nu eenmaal eenvoudiger en consistenter dan SGML. That's it.

[edit]
Wat veel en VEEL belangrijker is, is CSS. Richt al je aandacht op semantische HTML en goed, creatief gebruik van CSS. Let niet al te veel op IE7, en nog minder op IE6. Pas als je enig niveau hebt met CSS kun je eens naar de IE-drek kijken. Pas dan weet je ook wat de preciese problemen zijn met die meuk, en kun je eromheen werken.

Fuzzillogic wijzigde dit bericht 08-01-2008 00:20 (18%)

quote:

Fuzzillogic schreef op dinsdag 08 januari 2008 @ 00:11:
Voor dagelijks gebruik is er werkelijk geen enkel verschil. Zolang het syntactisch correct is zal het de browser worst wezen, en zal het ook in de voorzienbare toekomst gewoon blijven werken.

Tsja, simpelweg omdat het een voldongen feit is dat iedereen een aantal jaren terug meegegaan is met de XML-hype zonder zich echt in de technologie te verdiepen en er nu geen weg meer terug is... Zelfs RSS-parsers doen tegenwoordig aan error-correctie, wat is daar nog XML aan dan?

quote:

De reden om HTML te gebruiken om te zien wat HTML5 doet lijkt me onzin, sowieso komt er een XHTML-versie van HTML5, en ik hoop nog steeds dat de klotskoppen van de WhatWG eens wakker worden en enige realiteitszin krijgen m.b.t. de problemen van webapps. Maar dat is een andere discussie

Er komt een XML-serialisatie van HTML5 die als een XML-application kan worden geserveerd. Dat concept is verder echter nog niet uitgewerkt. De werknaam is wel XHTML5 (maar daar zijn de jongens van de XHTML2 WG niet echt blij mee), en de vraag is ook of dat uiteindelijk ook de XHTML namespace gaat gebruiken + bijbehorende mimetype of niet. Als het de opvolger wordt van XHTML1.x dan hoop ik in ieder geval dat ze XHTML1.1's directive gaan volgen mbt mimetype (SHOULD NOT be served as text/html) of zelfs stricter (MUST NOT be served as text/html).

webapps is een ander verhaal, maar zonder goede basis voor markup een brug te ver imo. WF2.0 en de uitbreidingen op HTML zijn denk ik echter al wel een stap in de goede richting, maar je moet ook niet teveel tegelijk willen (Microsoft moet het ook nog kunnen bijbenen ).

quote:

Blijft over wat je zelf fijner vindt. XHTML 1.0 is for all intends and purposes identiek aan HTML4, dus daar merk je eigenlijk niets van. Persoonlijk geef ik XHTML 1.x de voorkeur boven HTML4, want XML is nu eenmaal eenvoudiger dan SGML. That's it.

Er is geen enkele browser die HTML echt als een SGML-application behandeld (en door XHTML1.0's directive dat het verstuurd mag worden als text/html is dat ook onmogelijk geworden). En dat XML eenvoudiger is dan HTML is imo niet waar. Misschien op syntax-niveau (maar dat is ook puur perceptie), maar er ziten veel meer haken en ogen aan een XML-applicatie dan aan een HTML-applicatie, al is het alleen maar de 'vergevingsgezindheid' (error-correction) van de parser van laatstvoornoemde.

quote:

[edit]
Wat veel en VEEL belangrijker is, is CSS. Richt al je aandacht op semantische HTML en goed, creatief gebruik van CSS. Let niet al te veel op IE7, en nog minder op IE6. Pas als je enig niveau hebt met CSS kun je eens naar de IE-drek kijken. Pas dan weet je ook wat de preciese problemen zijn met die meuk, en kun je eromheen werken.

Daar kan ik het met je over eens zijn

crisp wijzigde dit bericht 08-01-2008 00:28 (7%)

- Kort door de bocht: HTML 4.01 Strict
- Iets genuanceerder: kies een strict doctype, maar gezien IE nix met echte XHTML kan (zoals crisp al zegt), heb je nix aan XHTML, iig niet de komende jaren (daar heb je wat pas aan als iedereen is overgestapt op een IE-versie die nog niet eens bestaat).
- Meer onderbouwing: Welk doctype moet ik kiezen? (incl. verwijzingen naar bovenstaande artikelen).

En idd, whatever strict doctype, goeie kennis van CSS is uiteindelijk belangrijker. (En ik zou Fuzzillogics punt eerder herschrijven tot: test eerst in Opera of Firefox, niet in IE. Corrigeer pas achteraf voor de vele IE-bugs.)

IE kan geen XHTML aan. Meer dan de helft van de websurfers gebruikt IE, dus gebruik geen XHTML.

Als je XHTML-code als text/html verstuurt, kun je problemen verwachten als je ooit switcht naar echte XHTML. Doe dat dus niet; XHTML != HTML

HTML5 kent twee serialisaties: HTML en XHTML. Bij HTML5 gaat het om het DOM, en niet om de serialisatie. Met het oog op HTML5 maakt het dus weinig uit of je HTML of XHTML schrijft.

quote:

IE kan geen XHTML aan

Geen FUD aub... IE rendert de boel met de tag-soup-parser, en zolang je IE de XHTML naar als text/html aanlevert is er niets aan de hand. Moderne browser kun je gewoon de XHTML aanleveren met application/xhtml+xml.

En als je valid XHTML maakt, dan is ook dat geen probleem om later te switchen naar application/xhtml+xml.

quote:

Fuzzillogic schreef op dinsdag 08 januari 2008 @ 12:10:
Geen FUD aub... IE rendert de boel met de tag-soup-parser, en zolang je IE de XHTML naar als text/html aanlevert is er niets aan de hand. Moderne browser kun je gewoon de XHTML aanleveren met application/xhtml+xml.

XHTML-code met MIME type text/html is HTML. IE kan MIME-type application/xhtml+xml niet aan.

quote:

En als je valid XHTML maakt, dan is ook dat geen probleem om later te switchen naar application/xhtml+xml.

Ja, dat is het wel. Dat probeer ik duidelijk te maken in het artikel waarnaar ik in mijn vorige post linkte.

quote:

Ja, dat is het wel. Dat probeer ik duidelijk te maken in het artikel waarnaar ik in mijn vorige post linkte.

Het probleem wat in dat artikel aangehaald wordt, ontstaat bij het vertrouwen op invalid code, zoals unencoded ampersands en ongesloten tags. De validator zal die eruit pikken, ongeacht het contenttype van de pagina. Sterker nog, het contenttype staat volledig los van de DTD waartegenaan gevalideerd wordt. Enige verschil is dat bij het correcte XHTML contenttype de browser well-formedness bepaalt.

Twee voordelen: het gaat nu tenminste mis als je iets fout doet, zodat je het gelijk ziet. Hoef je minder vaak te valideren als je nog niet op het niveau zit waarop je natuurgetrouw valide code schrijft. Net als bij een compiler dus. Tweede voordeel is dat de XML-parser gebruikt wordt, die veel sneller is dan de SGML-parser.

Voordeel van XHTML dat hier vgs mij nog niet aangehaald is, is de integratie met andere XML-werelden, zoals MathML en SVG. Dat kan met HTML natuurlijk ook, maar is, zoals verwacht, invalid. Met correcte namespaces en prefixes kun je XHTML+SVG well-formed en valid maken.

Maargoed, de bottom line is dus dat je alléén IE6 en lager je XHTML als text/html moet geven. ALLE andere non-fossiele browsers kunnen uitstekend met XHTML omgaan. En gezien IE6 een uitstervende soort is (good riddens btw), heeft het argument "XHTML moet als text/html en is dus HTML" nog nauwelijks waarde.

quote:

_Thanatos_ schreef op dinsdag 08 januari 2008 @ 12:24:
[...]

Het probleem wat in dat artikel aangehaald wordt, ontstaat bij het vertrouwen op invalid code, zoals unencoded ampersands en ongesloten tags. De validator zal die eruit pikken, ongeacht het contenttype van de pagina. Sterker nog, het contenttype staat volledig los van de DTD waartegenaan gevalideerd wordt. Enige verschil is dat bij het correcte XHTML contenttype de browser well-formedness bepaalt.

Het belangrijkste verschil is het ontbreken van implied elements (body, html, head, tbody etc.) en verschillen in de uitvoer van Javascript (document.write en dergelijke). XHTML wordt anders geparsed dan HTML, dat is het punt. Door XHTML als HTML te laten parsen, ga je voorbij aan die verschillen.

Op de wiki van WHATWG staat een lijst met verschillen in beide parsing modes.

Over IE: ook IE7 kan geen (echte) XHTML parsen.

quote:

Niels Sijm schreef op dinsdag 08 januari 2008 @ 12:14:
[...]

XHTML-code met MIME type text/html is HTML. IE kan MIME-type application/xhtml+xml niet aan.

Ja. Dat is toch precies wat ik zeg?

quote:

Ja, dat is het wel. Dat probeer ik duidelijk te maken in het artikel waarnaar ik in mijn vorige post linkte.

Nee dat is het niet. Ok, sommige zaken die XML-technisch gezien correct zijn, bijv <script src="bla" type="application/javascript" />, zullen in de tag-soup-mode met text/html problemen geven. Het betreft echter maar enkele elementen die je 'voluit' moet sluiten, om ook in text/html goed te laten gaan.

Ik verbaas me echt over de hoeveelheid FUD jegens XHTML hoor

nee, tegen html met xhtml syntax

quote:

Fuzzillogic schreef op dinsdag 08 januari 2008 @ 12:35:
[...]

Ik verbaas me echt over de hoeveelheid FUD jegens XHTML hoor

Niks geen FUD.

XHTML wordt door een andere parser gehaald dan HTML. XHTML-code met text/html gedraagt zich anders dan dezelfde XHTML-code met application/xhtml+xml. Dat kun je toch niet ontkennen?

quote:

mophor schreef op dinsdag 08 januari 2008 @ 12:40:
nee, tegen html met xhtml syntax

Fair enough, maar mijn punt is dat het gewoon geen enkel probleem is om XHTML te schrijven die valid XML is en die tevens probleemloos door alle tag-soup-parsers begrepen wordt. Althans, ik ben precies 0 keer tegen een probleem aangelopen.

quote:

Niels Sijm schreef op dinsdag 08 januari 2008 @ 12:44:
[...]

Niks geen FUD.

XHTML wordt door een andere parser gehaald dan HTML. XHTML-code met text/html gedraagt zich anders dan dezelfde XHTML-code met application/xhtml+xml. Dat kun je toch niet ontkennen?

Dus? Het gaat uiteindelijk om de DOM, en eventuele CSS-selectors. Dat je in HTML sommige tags kunt weglaten is leuk en aardig, maar dat is m.i. precies wat HTML zo inconsistent/onoverzichtelijk maakt.

Je kunt wel allerlei rare uitzonderingen en verschillen erbij gaan halen, maar het gaat erom wat in de praktijk een echt probleem is. Ik blijf erbij: het is FUD.

Fuzzillogic wijzigde dit bericht 08-01-2008 12:50 (47%)

Zelf tik ik al weer een tijdje xhtml ipv html. Dit word wel verstuurt als text/html. En ik moet zeggen dat ik nooit echt problemen heb ondervonden. De W3-validator geeft ook aan dat het valid code is.

Nou heb ik voor de gein eens een website gepakt en deze het html 4.01 strict doctype meegegeven. Dan krijg ik gelijk een berg fouten (oa, het kort afsluiten van dingen. <label> element in een form mag blijkbaar niet).
.
De vraag waar ik eigenlijk een ja/nee op wil is: Kan het kwaad om in xhtml verder te tikken?

De reden is eigenlijk gewoon omdat ik nu gewend ben om xhtml te tikken, en het me waarschijnlijk weer een hoop moeite gaat kosten om me aan te passen naar html 4.01.

quote:

Fuzzillogic schreef op dinsdag 08 januari 2008 @ 12:45:
[...]

Fair enough, maar mijn punt is dat het gewoon geen enkel probleem is om XHTML te schrijven die valid XML is en die tevens probleemloos door alle tag-soup-parsers begrepen wordt. Althans, ik ben precies 0 keer tegen een probleem aangelopen.

komt omdat je het waarschijnlijk ook behandeld als html, dus in js er vanuit gaat dat node.nodeName uppercase retourneert, dat de dom case insensitive is en niet namespace aware. En omdat de client al je eventuele fouten gewoon slikt. Met andere woorden: het is niet fout gegaan omdat je nog nooit met xhtml hebt gewerkt

mophor wijzigde dit bericht 08-01-2008 12:53 (4%)

Achja, ik heb niet eens meer zin om hierover te discussiëren. Microsoft heeft XHTML de nek omgedraaid. Het is nu weinig zinvol er nog toekomst in te zien, aangezien ze met IE7 weer een wanprestatie hebben geleverd. Je zit nog jarenlang met kutbrowsers, dus elke vernieuwing kan pas daarwerkelijk over een jaar of 3 serieus worden toegepast. In 2010 zitten we zéker nog met dit soort perikelen.

Maar goed, los daarvan, ik denk dat sowieso maar een verdomd klein percentage überhaupt echt HTML beheerst, want meestal gaan discussies over hetzelfde, terwijl iedereen elkaar maar achteraanloopt. Ik blijf erbij dat het het beste is om gewoon de W3C recommendations te lezen, proberen te begrijpen waar het allemaal om gaat. En dat is niet om dingen als syntax, zelfs niet over semantisch correct toegepaste elementen. Het gaat om standaarden en daaruit voortvloeiende compatibiliteit. En dat laatste is een lachtertje. En dat blijft het nog een hele tijd.

Kortom, richt je niet op zoiets smals als HTML, probeer jezelf te leren op een bepaalde manier naar de stof te kijken, dat werkt stukken beter dan luisteren naar de imiddels enorm uitgekauwde discussies over HTML vs. XHTML vs. HTML5 en over tables vs. divs vs. semantiek. Je hebt meer kans dat je naar een naprater luistert dan naar iemand die kennis en begrip heeft van het totale plaatje.

Het is net zoiets als programmeren. Leer niet PHP, leer niet C#, leer programmeren. Gestructureerd denken, logisch denken, abstract denken. Dat is bij HTML niet anders. De basis van HTML4.01 en XHTML is precies dezelfde. Vrijwel alle kennis die je op dat gebied kunt hebben is universeel. De verschillen zijn op dit moment in praktijk geneuzel in de marge. XHTML is wel extensible, maar nooit echt extended.

quote:

mophor schreef op dinsdag 08 januari 2008 @ 12:52:
[...]
Met andere woorden: het is niet fout gegaan omdat je nog nooit met xhtml hebt gewerkt

Mijn website is valid XHTML 1.1.

En verder eens met Cheetah Het is idd weer een discussie waar ik ook geen zin in heb, maar waar van de andere kant m'n vingers weer te erg gaan jeuken als ik mensen om (in mijn ogen) suffe of achterhaalde redenen XHTML zie afraden...

Fuzzillogic wijzigde dit bericht 08-01-2008 13:17 (33%)

Je kunt het beste gewoon HTML 4 blijven gebruiken, die hele heisa rondom XHTML heb ik nog nooit nodig gehad. Ik maak mijn collega's meestal helemaal gek door ook nog HOOFDLETTERTAGS te gebruiken, kreten als SELECTED en mijn <P>-tags lekker niet af te sluiten. Eerst lekker uit laten ranten over wat ik allemaal fout doe, en dan zonder verder iets te zeggen het door de validator heen halen en het resultaat daar van laten zien. Vervolgens nog even vragen wat ze eigenlijk precies met die XML wilden gaan doen, en voila, weer een XHTML-zeloot aan het denken gezet

quote:

Good Fella schreef op dinsdag 08 januari 2008 @ 12:49:
Nou heb ik voor de gein eens een website gepakt en deze het html 4.01 strict doctype meegegeven. Dan krijg ik gelijk een berg fouten (oa, het kort afsluiten van dingen. <label> element in een form mag blijkbaar niet).

Slightly OT: fieldset ...

On-topic: HTML 4.01 strict, de redenen zijn hier al genoemd...

quote:

BikkelZ schreef op dinsdag 08 januari 2008 @ 13:36:
kreten als SELECTED en mijn <P>-tags lekker niet af te sluiten.

Heel goed. Gestructureerde, heldere code is voor mietjes. Commentaar is voor idioten, en heldere namen voor variabelen en functies zijn ook alleen maar lastig, want veel typewerk.

Je hebt XHTML ook niet 'nodig', want er is momenteel geen verschil qua semantiek en mogelijkheden met HTML4. Maar je had inmiddels toch wel mogen weten dat gestructureerd werken een klein voordeeltje heeft, iets dat XML meer afdwingt dan het SGML-ish van HTML.

Dat dacht ik dus ook. Expres ongestructureerd gaan werken, waardoor je dus bijvoorbeeld niet kan weten wanneer die <p> in de DOM eindigt, werkt brakke websites alleen maar in de hand. Bovendien is het misschien maar een gevoel, maar als ik een website zie met in de source alles in uppercase, heb ik toch wel een gevoel van nostalgie, en niet een gevoel van bewondering.

Trouwens, het is niet zo dat je XHTML niet 'nodig' hebt. Je hebt XHTML nodig als je denkt dat je het nodig hebt, maar in any case kan het je zeker steunen bij het maken van well-formed code. Het helpt in elk geval in 1 klap van die achterlijke uppercase tags af.

On a sidenote, BikkelZ, spreek met je collega's een standaard af en houdt je daar gewoon aan. Dat is toch geen samenwerken wat jij doet. Je bent collega's, geen concurrenten. Op mijn werk hebben we een heel strak gedefinieerde standaard van hoe we wat in websites doen. Wij zeggen gewoon: XHTML 1.0 Strict; punt uit; geen discussie over mogelijk. Niet aan gewend? Wen er maar aan.

Dat lijkt me een mooie les voor dit topic: spreek met je collega's in elk geval af hoé je het doet, in plaats van de bakkelijen over wat er zo fout is aan de methode van die ander.

quote:

_Thanatos_ schreef op dinsdag 08 januari 2008 @ 14:14:On a sidenote, BikkelZ, spreek met je collega's een standaard af en houdt je daar gewoon aan. Dat is toch geen samenwerken wat jij doet. Je bent collega's, geen concurrenten. Op mijn werk hebben we een heel strak gedefinieerde standaard van hoe we wat in websites doen. Wij zeggen gewoon: XHTML 1.0 Strict; punt uit; geen discussie over mogelijk. Niet aan gewend? Wen er maar aan.

Tuurlijk, maar dan moeten de desbetreffende collega's ook maar geen HTML 4.01 Transitional DTD gebruiken

quote:

_Thanatos_ schreef op dinsdag 08 januari 2008 @ 14:14:
Dat lijkt me een mooie les voor dit topic: spreek met je collega's in elk geval af hoé je het doet, in plaats van de bakkelijen over wat er zo fout is aan de methode van die ander.

Inderdaad, daar loop ik ook altijd op te hameren. Niks zo irritant als een mensen die eerst vijf minuten je code gaan herformatteren voordat ze er iets zinnigs over willen zeggen
[/quote]

quote:

Fuzzillogic schreef op dinsdag 08 januari 2008 @ 14:03:
[...]

Heel goed. Gestructureerde, heldere code is voor mietjes.

Als jij mijn heldere gestructureerde en noest doortabte HTML 4.01 niet binnen één oogopslag kunt interpreteren wens ik je veel succes bij de rest van je carrière

quote:

Fuzzillogic schreef op dinsdag 08 januari 2008 @ 14:03:
[...]

Commentaar is voor idioten, en heldere namen voor variabelen en functies zijn ook alleen maar lastig, want veel typewerk.

Dit trek je dus ter plekke weer even uit je reet

BikkelZ wijzigde dit bericht 08-01-2008 14:33 (45%)

Ook ik ben een fel 4.x aanhanger. Redenen zie hierboven. Ik vrees wel dat mijn HTML enkele XHTML-neigingen heeft (ik sluit mijn P wel ;^) maar steeds binnen de HTML 4.x (wat mag in HTML4.x hoef je niet te gebruiken).

Dat HTML per definitie tagsoup of slechte coding oplevert zou ik wel willen tegenspreken!

Verder heb ik een bloedhekel aan XHTML-doctypes met een vreselijke tagsoup onder (blijkbaar genereert DW standaard dit soort doc-types).

Tot slot denk ik dat de TS een mooi en genuanceerd antwoord kan vinden in deze thread, joepie :^)

En toen was het 2010

Ik ben erg benieuwd hoe de GoTers tegenwoordig denken over XHTML vs. HTML4.1. vs. HTML5.
In eerste instantie vond ik XHTML cool, maar bovenstaande discussie + mijn research van vandaag lijken XHTML voorgoed (± 10 jaar) aan de kant te schuiven.

Aangezien ik XHTML wel fijn bouwen vind, leek me HTML5 een aardig idee om toch futureproof te blijven. Maar is dat nou inmiddels een goed alternatief voor HTML4.01? Zijn er GoTters die ervaring hebben met HTML5 experimentjes en waar lopen jullie tegenaan?
Wordt het al een beetje 'standard' gerenderd of is het weer ouderwets quircks omdat het nog niet goed ondersteund wordt?

Deze vragen vooral omdat ik binnenkort een website ga bouwen. Deze zal bestaan uit 3 delen: informatie, webshop, cms. Voornamelijk zal er dus tekst / afbeeldingen / formulieren weergegeven worden.
De formulieren moeten het mogelijk maken om
• in de webshop producten in een winkelwagen te plaatsen
• en in het cms uiteraard de mogelijkheid bieden om info + afbeeldingen te uploaden.

Ik ben erg benieuwd naar jullie ideeën. Bvd voor jullie reacties.

quote:

Barleone schreef op maandag 12 april 2010 @ 23:11:
[...]
In eerste instantie vond ik XHTML cool, maar bovenstaande discussie + mijn research van vandaag lijken XHTML voorgoed (± 10 jaar) aan de kant te schuiven.

W3C heeft hetzelfde gedaan iig

quote:

Aangezien ik XHTML wel fijn bouwen vind, leek me HTML5 een aardig idee om toch futureproof te blijven. Maar is dat nou inmiddels een goed alternatief voor HTML4.01?

HTML5 is (in tegenstelling tot XHTML1.x) geen alternatief voor HTML4.01 maar de opvolger daarvan.

quote:

Zijn er GoTters die ervaring hebben met HTML5 experimentjes

Ja, onze site heeft al een HTML5 doctype en gebruikt verschillende HTML5-features, maar nog met mate.

quote:

en waar lopen jullie tegenaan?

IE natuurlijk welke vaak nog scripted workarounds nodig heeft

quote:

Wordt het al een beetje 'standard' gerenderd of is het weer ouderwets quircks omdat het nog niet goed ondersteund wordt?

Een document met HTML5 doctype wordt in elke browser (IE included) in standards-compatibility mode gerendered.

quote:

[...]
Ik ben erg benieuwd naar jullie ideeën. Bvd voor jullie reacties.

Graag gedaan

Wat let je om XHTML5 te gebruiken? Maar om nu volledig over te gaan op (X)HTML5 lijkt me alles behalve future-proof. Niet in de laatste plaats omdat het nog niet eens een definitieve standaard is. Zeker voor professionele websites, toch een investering voor een paar jaar, zou ik gewoon XHTML 1.x Strict gebruiken. De video/audio-tag is op zich wel stabiel genoeg om te gebruiken, ook al valt het buiten XHTML 1.x - browser doen daar ook niet moeilijk over.

Ik zou hoe dan ook de XML-versie gebruiken. Ik blijf erbij dat de keuze voor HTML (4 of 5) onhandig is op de lange termijn. Dat de W3C als "default" voor de SGML-draak is gegaan heeft mijn waardering voor de W3C ongelooflijk laten dalen. Ik vind het onbegrijpelijk.

Fuzzillogic wijzigde dit bericht 12-04-2010 23:26 (22%)

HTML5 != SGML(!)

quote:

De video/audio-tag is op zich wel stabiel genoeg om te gebruiken

Opvallend dat je juist de twee elementen die geplaagd worden door het gebrek aan een standaard encoding en waarvan de implementatie dus nogal gefragmenteerd is tussen browsers (en ook nog de nodige andere issues hebben - afgezien van het gebrek aan ondersteuning in IE) noemt. In ieder geval hebben ze wat betreft dat laatste (geen ondersteuning in IE) wel wat gemeen met XHTML

Dat HTML5 geen definitieve standaard is is geen reden om de stabiele en breed ondersteunde delen ervan niet alvast te gaan gebruiken; CSS2.1 is ook nog geen definitieve standaard (heeft momenteel - weer, sinds 2009 - CR status) - ook maar niet gebruiken?

Je doet voorkomen alsof HTML5 gedoemt is te falen, heb je een alternatief (behalve old-fashioned faux-XHTML)?

Ok, "SGML-draak" is niet de juiste woordkeuze. "SGML-aftreksel-draak" dan.

En ja, ik hoop dat HTML5 een zeer kort leven beschoren is. Voor document-achtige content heeft het wel meerwaarde tov HTML4, maar voor webapps waar Google en Apple (vreemd genoeg) zo'n voorstander van zijn mist het qua markup bijna alles.

Zelf heb ik onlangs een upload-tool gemaakt voor ons CMS, waarbij gebruikers met drag&drop hun foto's en video's kunnen uploaden naar het CMS zonder zich daarbij druk te hoeven maken om conversie en resolutie. Ja, het zou toch ontzettend vanzelfsprekend moeten zijn dat dat kan, maar met je browser gaat je dat niet lukken, ook niet met HTML5. We hebben gekozen voor Java met WebStart. Het heeft feitelijk alle voordelen die vaak als "uniek" voor webapplicaties worden aangemerkt: altijd up-to-date, easy deployment, cross platform. Daarnaast heeft het alle voordelen van een normale, native applicatie: veel betere usability en features dan voorlopig met een webapp mogelijk zijn.

Nee, Java/WebStart is geen volledig alternatief voor HTML5 voor webapps. Maar in veel gevallen is HTML5 juist een slecht alternatief voor "echte" applicaties. Ik hoop dat meer ontwikkelaars zich voldoende gaan ergeren aan de ontoereikendheid van webtech voor apps, zodat ze naar alternatieven gaan zoeken. Misschien dat de W3C dan weer eens wakker wordt.

Ik snap niet helemaal waar je nou precies heen wilt met deze post. Je hebt meer commentaar op de insteek van het W3C als het gaat om de toekomst van HTML, en je noemt een vrij specifieke functionaliteit die je mist. Beiden hebben volgens mij bijzonder weinig te maken met de verschillen tussen HTML en XHTML.

quote:

crisp schreef op maandag 12 april 2010 @ 23:23:
HTML5 is (in tegenstelling tot XHTML1.x) geen alternatief voor HTML4.01 maar de opvolger daarvan.

In mijn case is het wel een alternatief. In die zin dat ik één van de twee kies voor development.

quote:

IE natuurlijk welke vaak nog scripted workarounds nodig heeft

Welke features ondersteund IE dan bijvoorbeeld niet?
Probeer enkele dingen te noemen waar ik zeker tegenaan zal lopen bij bijv. div-layouts / forms / fotoviewers.

quote:

Een document met HTML5 doctype wordt in elke browser (IE included) in standards-compatibility mode gerendered.

En dat is 4.01 of zo-goed-en-zo-kwaad-als-het-gaat HTML5?

quote:

Fuzzillogic schreef op maandag 12 april 2010 @ 23:23:
Wat let je om XHTML5 te gebruiken? Maar om nu volledig over te gaan op (X)HTML5 lijkt me alles behalve future-proof. Niet in de laatste plaats omdat het nog niet eens een definitieve standaard is. Zeker voor professionele websites, toch een investering voor een paar jaar, zou ik gewoon XHTML 1.x Strict gebruiken. De video/audio-tag is op zich wel stabiel genoeg om te gebruiken, ook al valt het buiten XHTML 1.x - browser doen daar ook niet moeilijk over.

Ik zou hoe dan ook de XML-versie gebruiken. Ik blijf erbij dat de keuze voor HTML (4 of 5) onhandig is op de lange termijn. Dat de W3C als "default" voor de SGML-draak is gegaan heeft mijn waardering voor de W3C ongelooflijk laten dalen. Ik vind het onbegrijpelijk.

* Barleone wrijft nog eens goed in zijn ogen. Gezien deze post uit de verre verre toekomst hoeven we niet bang te zijn voor 2012
<seriousmode>
Audio / video heb ik niet nodig uit HTML5. XHTML app/xml support van browser(s) is huilen. Dus dat let me.
</seriousmode>

quote:

Fuzzillogic schreef op dinsdag 13 april 2010 @ 00:27:
Ok, "SGML-draak" is niet de juiste woordkeuze. "SGML-aftreksel-draak" dan.

minus 'draak' dan imho, want juist het afhandelen van 'foute' markup wordt in HTML5 zonder uitzondering eenduidig beschreven. De foutafhandeling van XML-applicaties wordt normaliter juist 'draconical' genoemd aangezien het meestal gaat om kleine simpele foutjes die een UA best zou kunnen oplossen, maar in plaats daarvan wordt dan een voor de gebruiker onbegrijpelijke foutmelding getoond...

quote:

En ja, ik hoop dat HTML5 een zeer kort leven beschoren is. Voor document-achtige content heeft het wel meerwaarde tov HTML4, maar voor webapps waar Google en Apple (vreemd genoeg) zo'n voorstander van zijn mist het qua markup bijna alles.

XHTML2 had dat ook niet gebracht, of wel? En zoja, hoe dan? En hoe is dat niet mogelijk met HTML5?

quote:

Zelf heb ik onlangs een upload-tool gemaakt voor ons CMS, waarbij gebruikers met drag&drop hun foto's en video's kunnen uploaden naar het CMS zonder zich daarbij druk te hoeven maken om conversie en resolutie. Ja, het zou toch ontzettend vanzelfsprekend moeten zijn dat dat kan, maar met je browser gaat je dat niet lukken, ook niet met HTML5.

Ik vind het niet zo vanzelfsprekend. Jij verwacht dat een browser alvast bepaald in welk formaat een plaatje of video op de server wordt aangelevert?

quote:

We hebben gekozen voor Java met WebStart. Het heeft feitelijk alle voordelen die vaak als "uniek" voor webapplicaties worden aangemerkt: altijd up-to-date, easy deployment, cross platform. Daarnaast heeft het alle voordelen van een normale, native applicatie: veel betere usability en features dan voorlopig met een webapp mogelijk zijn.

Prima dat je kiest voor een framework dat uiteindelijk voldoet aan je eisen, echter hoeft dat niet te betekenen dat het voor iedereen zou voldoen.

quote:

Nee, Java/WebStart is geen volledig alternatief voor HTML5 voor webapps. Maar in veel gevallen is HTML5 juist een slecht alternatief voor "echte" applicaties. Ik hoop dat meer ontwikkelaars zich voldoende gaan ergeren aan de ontoereikendheid van webtech voor apps, zodat ze naar alternatieven gaan zoeken. Misschien dat de W3C dan weer eens wakker wordt.

Ik denk dat HTML5 juist een stap vooruit is en technologieën zoals Java of Flash of Silverlight minder belangrijk maakt. Dat wil niet zeggen dat het deze technologieën obsolete maakt, maar het brengt wel veel meer mogelijkheden met zich mee waarbij externe plugins niet meer nodig zijn. Eea staat nog in de kinderschoenen, maar HTML5 legt wel degelijk een fundering waarop verder gebouwd kan worden en waar veel mensen 'simpele zaken' makkelijker mee kunnen doen.

quote:

crisp schreef op dinsdag 13 april 2010 @ 01:25:
[...]
XHTML2 had dat ook niet gebracht, of wel? En zoja, hoe dan? En hoe is dat niet mogelijk met HTML5?

Inkopper: namespaces. XHTML2 kende modules. Dat er NU nog geen app-markup was, was suf, maar het was wel op een elegante manier toe te voegen. En niets stond je in de weg om Mozilla's XUL daar 'alvast' voor te gebruiken. In XML integreert dat veel mooier dan in HTML.

Neem SVG. Nou weet ik niet precies wat de huidige status is, maar nog maar kort geleden werd SVG alleen in XHTML-mode ondersteund door Firefox en Opera. Goh!

quote:

Barleone schreef op dinsdag 13 april 2010 @ 01:22:
* Barleone wrijft nog eens goed in zijn ogen. Gezien deze post uit de verre verre toekomst hoeven we niet bang te zijn voor 2012
<seriousmode>
Audio / video heb ik niet nodig uit HTML5. XHTML app/xml support van browser(s) is huilen. Dus dat let me.
</seriousmode>

Alle moderne browsers gaan uitstekend om met app/xml. Alleen IE niet. En ja, het is mooier op het als app/xml te serveren, maar dat is wegens IE nog een utopie. Het maakt ook niet uit. Gewoon text/html will do for now. Maar XHTML gebruiken biedt voordelen. Ons CMS maakt daar dankbaar gebruik van: je kunt opeens XSLT loslaten op je XHTML-code. Dat is ontzettend prettig.

quote:

Fuzzillogic schreef op dinsdag 13 april 2010 @ 01:38:
je kunt opeens XSLT loslaten op je XHTML-code. Dat is ontzettend prettig.

Waarom zou je XSLT loslaten op XHTML? Data staat doorgaans in XML, en dat kun je prima met XSLT naar HTML5 converteren.

Ik zeg: bekijk de boel gewoon een beetje pragmatisch. Mooi dat XHTML verzenden als text/html als HTML wordt geïnterpreteerd, dan doen alle browsers dat tenminste hetzelfde. Dat het eigenlijk niet hoort? Tja, jammer dan, het werkt toch? Het idee XHTML is toch mislukt, dus die discussie heeft hoe dan ook nog maar weinig zin.

En wat dat future proof maken van je site, is natuurlijk ook allemaal leuk en aardig, maar dat gaat natuurlijk ook maar in beperkte mate op. God weet hoe lang het duurt voordat IE op het niveau is van de rest en we weer verder kunnen innoveren. God weet wat iemand morgen voor briljants bedenkt dat overmorgen door alle browsers gewoon ondersteund wordt. Verder, als MS besluit om IE weer eens radicaal te gaan verbouwen, kan dat zomaar je site kapot maken, ondanks alle moeite die je hebt gestoken in het future proof zijn. Is al eens bijna gebeurd.

Daarbij, tegen de tijd dat mainstream browsers een site die vandaag de dag goed werkt echt zo gaan vernaggelen dat het niet meer te fixen is, mag ik toch hopen dat je inmiddels eens een kleine update hebt gedaan. We gebruiken toch ook geen framesets meer anno nu, al werken ze nog prima?

Moraal van het verhaal: gebruik gewoon dat wat nu werkt en waar je je het meest comfortabel bij voelt. XHTML heeft in elk geval 1 voordeel: als je het door een validator ragt, dwingt het je om well formed code te schrijven, en dat is altijd goed. HTML is wat dat betreft veel toleranter.

chelvensteijn wijzigde dit bericht 13-04-2010 04:10 (3%)

quote:

XHTML heeft in elk geval 1 voordeel: als je het door een validator ragt, dwingt het je om well formed code te schrijven, en dat is altijd goed.

Een validator geeft toch ook gewoon errors als het mallformed HTML zou zijn? Of praat je hier over een mening met betrekking tot een bepaalde syntax die jij prefereert? Dan krijg je net zulke discussies als over brace-style, bottomline is dat het dan om een persoonlijke voorkeur gaat en het niets te maken heeft met wel of niet well-formed zijn...

quote:

crisp schreef op dinsdag 13 april 2010 @ 09:16:
[...]

Een validator geeft toch ook gewoon errors als het mallformed HTML zou zijn?

Klopt natuurlijk, punt is dat raptor probeert te zeggen dat well-formed (X)HTML good practice is. Ik ben het daarmee eens al vraag ik mij af wat het doel is van well-formed (X)HTML, het zegt namelijk niks over de functionaliteit ervan. En dat is precies wat raptor ook probeert te zeggen, 'het werkt toch?'.

Als het gaat om html4 strict vs html5, dan zie ik momenteel weinig reden om juist nog html4 strict te gebruiken, tenzij je moet voldoen aan de eisen van stichting drempelvrij als je met een overheidsklus bezig bent ofzo.

De html5 doctype is lekker simpel en schopt alle browsers, zelfs IE6, in standardsmode. Maar het voordeel van html5 ten opzichte van html4 is dat een aantal dingen die je volgens html4 niet mocht gebruiken, nu wel gewoon valideren. Bijvoorbeeld het target-attribuut of custom attributen.

Dit gaat dan alleen om de doctype uiteraard. De rest van de html5 standaard is nog te in ontwikkeling en vaak slecht ondersteund dat ik me daar nog niet teveel aan zou wagen voor productie.

quote:

XHTML heeft in elk geval 1 voordeel: als je het door een validator ragt, dwingt het je om well formed code te schrijven, en dat is altijd goed.

Als het de standaard is die jou als frontend-specialist moet gaan dwingen well formed code te schrijven is er denk iets mis.

Bosmonster wijzigde dit bericht 13-04-2010 10:06 (17%)

quote:

.oisyn schreef op dinsdag 13 april 2010 @ 03:09:
[...]

Waarom zou je XSLT loslaten op XHTML? Data staat doorgaans in XML, en dat kun je prima met XSLT naar HTML5 converteren.

Onze "data" is dikwijls XHTML.

quote:

Bosmonster schreef op dinsdag 13 april 2010 @ 10:03:
De html5 doctype is lekker simpel en schopt alle browsers, zelfs IE6, in standardsmode.

HTML5 doctype is ook van de pot gerukt. Het weglaten van de version specifier is nogal megalomaan als je het mij vraag.

quote:

Maar het voordeel van html5 ten opzichte van html4 is dat een aantal dingen die je volgens html4 niet mocht gebruiken, nu wel gewoon valideren. Bijvoorbeeld het target-attribuut of custom attributen.

Custom attributen en tags... Waar heb ik dat eerder gezien, al jaaaaaaaaren geleden?... Ohja, XML namespaces! Werkt ook in XHTML! Wat handig! Hebben we helemaal geen "speciaal" x-attribuut or whatever voor nodig!

quote:

Als het de standaard is die jou als frontend-specialist moet gaan dwingen well formed code te schrijven is er denk iets mis.

Wat is er mis met het schrijven van correcte code? Als developer kan ik je vertellen dat een best wel handig is met debuggen...

quote:

Ohja, XML namespaces! Werkt ook in XHTML! Wat handig! Hebben we helemaal geen "speciaal" x-attribuut or whatever voor nodig!

Och, je zou 'data-' ook als een soort namespace kunnen zien, maar dan wat eenvoudiger en minder verbose dan het gebruik van XML namespaces

quote:

Fuzzillogic schreef op dinsdag 13 april 2010 @ 10:28:
[...]
Wat is er mis met het schrijven van correcte code? Als developer kan ik je vertellen dat een best wel handig is met debuggen...

Daar is niks mis mee, maar ik zou dat af laten hangen van de skill van de developer ipv de standaard.

Een goede developer kan net zo goed well formed html ontwikkelen in html als in xhtml.

quote:

Fuzzillogic schreef op dinsdag 13 april 2010 @ 00:27:

Zelf heb ik onlangs een upload-tool gemaakt voor ons CMS, waarbij gebruikers met drag&drop hun foto's en video's kunnen uploaden naar het CMS zonder zich daarbij druk te hoeven maken om conversie en resolutie. Ja, het zou toch ontzettend vanzelfsprekend moeten zijn dat dat kan, maar met je browser gaat je dat niet lukken, ook niet met HTML5.

Kan google wave dat niet? Of ligt dat eerder aan Chrome dan aan HTML?

quote:

Fuzzillogic schreef op dinsdag 13 april 2010 @ 10:28:
[...]

Onze "data" is dikwijls XHTML.

Tja, je kunt je afvragen in hoeverre dat nou fantastisch design is.

quote:

Tharulerz schreef op dinsdag 13 april 2010 @ 10:42:
[...]


Kan google wave dat niet? Of ligt dat eerder aan Chrome dan aan HTML?

Dat was idd een grap en grol die ze in speciaal daarvoor aan Chrome hebben toegevoegd. Andere browsers kunnen het niet.
Daarnaast willen we ook video kunnen uploaden zonder gedoe voor de gebruiker. En ik zie de browsers nog niet zo snel een AVCHD videootje transcoden. En as-is uploaden wil je die ook niet...

quote:

.oisyn schreef op dinsdag 13 april 2010 @ 11:17:
[...]

Tja, je kunt je afvragen in hoeverre dat nou fantastisch design is.

Het blijft altijd een afweging, maar het is iig wel fantastisch flexibel. Er is iig over nagedacht, kan ik je vertellen

Overigens: XHTML maakt het embedden van XHTML als data in een XML-document ook erg prettig en eenvoudig. En ja, dat gebeurt veelvuldig: Atom, het slimmere broertje van RSS, staat gewoon XHTML als content toe. Heel wat fraaier dan die XML-escaped HTML-meuk die men nu in RSS moet gooien. ePub, een welhaast defacto standaard voor e-boeken, gebruikt ook gewoon XHTML.

Fuzzillogic wijzigde dit bericht 13-04-2010 11:28 (40%)

quote:

Fuzzillogic schreef op dinsdag 13 april 2010 @ 11:21:
[...]

Dat was idd een grap en grol die ze in speciaal daarvoor aan Chrome hebben toegevoegd. Andere browsers kunnen het niet.
Daarnaast willen we ook video kunnen uploaden zonder gedoe voor de gebruiker. En ik zie de browsers nog niet zo snel een AVCHD videootje transcoden. En as-is uploaden wil je die ook niet...

Ik zou uberhaupt geen http gebruiken om "ff een videootje" te uploaden. Transcoded of niet, daarvoor moet je gewoon andere tools gebruiken. Dat het kán wil niet zeggen dat het dus ook de manier is om dat zo te regelen

quote:

Fuzzillogic schreef op dinsdag 13 april 2010 @ 11:21:
[...]

Het blijft altijd een afweging, maar het is iig wel fantastisch flexibel. Er is iig over nagedacht, kan ik je vertellen

Overigens: XHTML maakt het embedden van XHTML als data in een XML-document ook erg prettig en eenvoudig. En ja, dat gebeurt veelvuldig: Atom, het slimmere broertje van RSS, staat gewoon XHTML als content toe. Heel wat fraaier dan die XML-escaped HTML-meuk die men nu in RSS moet gooien. ePub, een welhaast defacto standaard voor e-boeken, gebruikt ook gewoon XHTML.

Data opslaan in een opmaaktaal flexibel? Lijkt me meer het tegenovergestelde.

En (opgemaakte) boeken in XHTML hiermee gaan vergelijken is natuurlijk nogal onzinnig. Je hebt het daar niet over data, maar over een opgemaakt formaat.

Bosmonster wijzigde dit bericht 13-04-2010 11:50 (3%)

En waarom zou de content (XHTML) niet de data kunnen zijn? Ik ga hier niet uit de doeken doen hoe ons systeem precies in elkaar zit, maar "ja hoor, dat kan" kunnen antwoorden op vragen van de klant is ook wat waard. Letterlijk en figuurlijk.

quote:

Bosmonster schreef op dinsdag 13 april 2010 @ 10:39:
[...]


Daar is niks mis mee, maar ik zou dat af laten hangen van de skill van de developer ipv de standaard.

Een goede developer kan net zo goed well formed html ontwikkelen in html als in xhtml.

Natuurlijk kan een goede developer dat. Maar een wat minder goede developer misschien niet, en die moet het toch ook leren. Ik bedoelde enkel te zeggen dat een validator een handig hulpmiddel kan zijn, niet dat het goed is om ervan afhankelijk te zijn.

quote:

raptor82 schreef op dinsdag 13 april 2010 @ 17:02:
[...]

Natuurlijk kan een goede developer dat. Maar een wat minder goede developer misschien niet, en die moet het toch ook leren. Ik bedoelde enkel te zeggen dat een validator een handig hulpmiddel kan zijn, niet dat het goed is om ervan afhankelijk te zijn.

validator != standaard

Een validator kan daar toch eventueel opmerkingen over maken? Ik ben het bosmonster eens dat zoiets niet per se vanuit de standaard geregeld moet worden.

Verder blijf ik erbij dat HTML5 geschikter is voor de herintredende hobbyist. XHTML zal voordelen hebben als je het gebruikt i.c.m. XML, maar ik zie niet in waarom een hobbyist zich dit op de hals moet halen als hij daardoor dingen als de audio/video-tag mist.

audio/video ontbreken in XHTML? Hoe kom je daar bij? Er is gewoon XHTML5, die wat mij betreft is wat HTML5 had moeten zijn.

Een standaard moet niet moeilijker zijn dan nodig. Een standaard moet het ook niet onduidelijker maken dan nodig. Maar juist well-formed X(HT)ML schrijven is toch eenvoudiger dan HTML. HTML is onduidelijker dan XML. <link> of <link />? </p> of niet? HTML: soms mag het, soms moet het, soms mag het niet. XHTML: het moet.

Html is niet onduidelijk hoor, tenminste als je zwart-wit denkt: Het mag of het mag niet.
Alle tags zonder inhoud zoals hr, br, link sluit je niet af, alle tags met inhoud moet je gewoon afsluiten.
Het is overigens gewoon mogelijk om XHTML documenten als HTML documenten te valideren, dus niets houdt je tegen behalve de browsersupport.

Sebazzz wijzigde dit bericht 13-04-2010 23:02 (26%)

quote:

Fuzzillogic schreef op dinsdag 13 april 2010 @ 19:45:
[...]
XHTML: het moet.

En dan moet je alsnog gaan nadenken wanneer je het toch als text/html moet versturen: <div /> kan dan weer niet, en <br></br> ook niet. Kortom: je hebt met precies dezelfde 'uitzonderingen' te maken...

Maar goed, this is getting old. Ga lekker je gang met XHTML5 dan hou ik het lekker bij HTML5

Juist, en <p> en <td> en <tr> enzo mag je *optioneel* afsluiten. <script /> met een src-attribuut moet je toch afsluiten, ook al mag er geen content meer zijn. Hoe precies ga je dat aan een leek uitleggen?

quote:

Fuzzillogic schreef op dinsdag 13 april 2010 @ 23:14:
Juist, en <p> en <td> en <tr> enzo mag je *optioneel* afsluiten. <script /> met een src-attribuut moet je toch afsluiten, ook al mag er geen content meer zijn. Hoe precies ga je dat aan een leek uitleggen?

Rule of thumb: als het content kan bevatten: altijd afsluiten met een losse close-tag (en dus ook in XHTML als het geserveerd moet worden als text/html).

Ik ben zelf geen voorstander van het weglaten van optionele end-tags, maar als je geautomatiseerd HTML minified dan is dat een leuke bytesaver <tbody> is overigens ook een leuke: hoe vaak gebruik jij die expliciet?

crisp wijzigde dit bericht 13-04-2010 23:19 (5%)

quote:

Fuzzillogic schreef op dinsdag 13 april 2010 @ 23:14:
Juist, en <p> en <td> en <tr> enzo mag je *optioneel* afsluiten. <script /> met een src-attribuut moet je toch afsluiten, ook al mag er geen content meer zijn. Hoe precies ga je dat aan een leek uitleggen?

De enige reden dat dat volgens jou 'verwarrend' is, is omdat jij van XML uitgaat. Bij alle tags heb je opentags en sluittags, maar er zijn een paar uitzonderingen en bij sommige tags is het optioneel. Dat is niet moeilijk, de uitzonderingen zijn op één hand te tellen en de optionele sluittags hoef je niet te kennen.

Jij maakt het moeilijk omdat je XML-regels toe gaat passen op iets dat geen XML is. Dat is een gebrek van jou, niet van de standaard!

Omdat ik maandag deze discussie afstofte wil ik jullie bij deze bedanken voor de discussie. Ik ga het houden bij HTML5 voor zover ik daarmee nergens tegenaan loop. In dat geval ga ik waarschijnlijk 4.01strict gebruiken.

offtopic:
Ben momenteel mijn hersens aan het pijnigen over wat CSS moeilijkheden.

quote:

crisp schreef op dinsdag 13 april 2010 @ 23:17:
Ik ben zelf geen voorstander van het weglaten van optionele end-tags, maar als je geautomatiseerd HTML minified dan is dat een leuke bytesaver <tbody> is overigens ook een leuke: hoe vaak gebruik jij die expliciet?

Toch, best zinloos met gzip aan

Naar mijn mening komt het gewoon neer op ... HTML5 heeft beperkte browser support. XHTML heeft beperkte browser support (specifieker IE uiteraard). Dus eigenlijk maakt het niets uit.

Je kan niet de mooie HTML5 features gebruiken zonder dat IE het niet meer snapt en hetzelfde met XHTML. Als je het bij de "traditionele" HTML mogelijkheden houdt dan is XHTML weinig anders dan een syntax variatie.

quote:

Fuzzillogic schreef op dinsdag 13 april 2010 @ 10:28:
[...]

Onze "data" is dikwijls XHTML.

Dat zou ik niet te vaak publiek gaan roepen

quote:

HTML5 doctype is ook van de pot gerukt. Het weglaten van de version specifier is nogal megalomaan als je het mij vraag.

Nee dat is een historische correctie. De wereld erkent nu het nut van standaarden en een enkele instantie die ze beheert, waardoor je geen incompatibilities meer hoeft te hebben als je simpelweg wat basisregels aan UA's voorschrijft over wat ze met hun onbekende tags doen en voor de rest je kop erbij houdt. Protocol versioning is een zwaktebod voor slecht design (ik laat hier de inkopper over 'data in xhtml' liggen).

quote:

Custom attributen en tags... Waar heb ik dat eerder gezien, al jaaaaaaaaren geleden?... Ohja, XML namespaces! Werkt ook in XHTML! Wat handig! Hebben we helemaal geen "speciaal" x-attribuut or whatever voor nodig!

Ja het werd ook zo hard gebruikt in XHTML he! Misschien dat er daarom nu een veel simpeler en toegankelijker variant op is gekomen?

quote:

Fuzzillogic schreef op dinsdag 13 april 2010 @ 12:37:
En waarom zou de content (XHTML) niet de data kunnen zijn? Ik ga hier niet uit de doeken doen hoe ons systeem precies in elkaar zit, maar "ja hoor, dat kan" kunnen antwoorden op vragen van de klant is ook wat waard. Letterlijk en figuurlijk.

Ik denk dat je het punt mist dat opslaan in een opmaaktaal juist zorgt dat je vaker "nee dat kan niet" moet zeggen. Leuk dat je vanuit XHTML snel naar PDF, TeX e.d. kunt (ik gok dat je het daarover hebt) maar dat kun je vanuit XML veel dynamischer genereren.... en XML is praktischer voor SOAP- en andere API's en open file formats.

quote:

Maar juist well-formed X(HT)ML schrijven is toch eenvoudiger dan HTML.

Jij hebt vast nooit problemen gehad met ongeldige of missende character entities doordat je weer ergens een CDATA block was vergeten.

curry684 wijzigde dit bericht 14-04-2010 04:44 (5%)

quote:

curry684 schreef op woensdag 14 april 2010 @ 04:41:
Ja het werd ook zo hard gebruikt in XHTML he! Misschien dat er daarom nu een veel simpeler en toegankelijker variant op is gekomen?

Dat komt natuurlijk alleen omdat bepaalde browsers er niet mee om kunnen gaan. Het is niet zo dat de wens om het te gebruiken niet aanwezig was.

Verder ben ik het volledig met je eens

quote:

curry684 schreef op woensdag 14 april 2010 @ 04:41:
[...]

Dat zou ik niet te vaak publiek gaan roepen

Aangezien je geen idee hebt waar het hier over gaat mag je denken wat je wilt, maar houd er rekening mee dat er genoeg dingen zijn die prima mogelijk zijn, maar waar jij niet aan gedacht hebt

quote:

Ja het werd ook zo hard gebruikt in XHTML he! Misschien dat er daarom nu een veel simpeler en toegankelijker variant op is gekomen?

Nogal duh he, als een browser met (te) hoge populariteit incapabel was om met namespaces om te gaan. Dat is geen hiaat van de specs, maar van die fabrikant.

quote:

Ik denk dat je het punt mist dat opslaan in een opmaaktaal juist zorgt dat je vaker "nee dat kan niet" moet zeggen. Leuk dat je vanuit XHTML snel naar PDF, TeX e.d. kunt (ik gok dat je het daarover hebt) maar dat kun je vanuit XML veel dynamischer genereren.... en XML is praktischer voor SOAP- en andere API's en open file formats.

En precies waarom zouden we een eigen XML-spec gaan opstellen als er voor documenten al een hele bruikbare spec is voor ons doel, compleet met heel veel tools en editors?

quote:

Jij hebt vast nooit problemen gehad met ongeldige of missende character entities doordat je weer ergens een CDATA block was vergeten.

Dat vergeet je 2x, daarna niet meer. Vervolgens weet je wel dat het *altijd* goed gaat.

Fuzzillogic wijzigde dit bericht 14-04-2010 10:26 (10%)

quote:

crisp schreef op dinsdag 13 april 2010 @ 23:17:
[...]
Ik ben zelf geen voorstander van het weglaten van optionele end-tags, maar als je geautomatiseerd HTML minified dan is dat een leuke bytesaver <tbody> is overigens ook een leuke: hoe vaak gebruik jij die expliciet?

Niet, browser support hè. En ik geloof dat als je tbody gebruikt je thead en tfooter ook moet gebruiken.

quote:

Sebazzz schreef op woensdag 14 april 2010 @ 10:30:
[...]
Niet, browser support hè.

Elke browser support <tbody> en maakt 'm voor HTML impliciet aan als je 'm weg hebt gelaten. Serveer je echter XHTML dan wordt <tbody> niet impliciet aangemaakt in de DOM; dit kan dus problemen geven als je mime-type negotiation gebruikt om sommige clients XHTML en anderen HTML te serveren.

quote:

En ik geloof dat als je tbody gebruikt je thead en tfooter ook moet gebruiken.

Nope, dat is niet verplicht

HTML5 kiest niet tussen HTML en XHTML, maar beschrijft enkel het DOMen kent twee serialisaties: HTML en XHTML. Het grote voordeel ten opzichte van HTML 4.01 en XHTML 1.0 is, dat er slechts één DOM is. De minieme maar relevante verschillen (wel/niet document.write, impliciete tbody) zijn dus verdwenen, waardoor het niet meer schadelijk is XHTML5 als text/html te versturen.

XHTML 1.0 is leuk, maar vraagt randvoorwaarden waar in de praktijk niet altijd aan gedaan kan worden. Draconische foutafhandeling en het ontbreken van een nette mogelijkheid tot het incrementeel laden van een pagina wegen voor mij erg zwaar. Mocht een webpagina kreupel zijn, dan wil ik dat een browser er het beste van probeert te maken. Het tonen van een Yellow Screen of Death is in niemands voordeel. Incrementeel laden is handig als je een brakke (Wifi-)verbinding hebt, of een trage server, of een brakke proxie, of, of, of… Om het web bruikbaar te houden, kun je niet verlangen dat webbouwers, browser-makers, ISP's, netwerkbeheerders en gebruikers al hun zaken op orde hebben.

Ik zie geen enkele reden waarom je met XHTML niet ook incrementeel zou kunnen laden. Ik vraag me eigenlijk af of dat niet al gebeurt tegenwoordig. Van een document dat je voor de helft binnen hebt kun je prima doen alsof alle openstaande tags gesloten worden. De DOM is dan niet anders dan van HTML. Een document kan dan hooguit niet valid zijn, dat kun je pas bepalen als het hele document ingeladen is. Maar de huidige browsers doen ook met XHTML sowieso niet moeilijk over invalidness.

Als devver wil ik duidelijkheid van een platform. Fouten die stiekem getolereerd worden zijn echt een groot drama. En nee, daar doe je de beginner ook geen plezier mee. Fouten tegen well-formdness zijn daarnaast wel heel simpel te fixen. M'n eigen site draait nu bijna 5 jaar op XHTML 1.1. Geen centje pijn.

Ik hoor telkens dezelfde nadelen van XHTML. In de praktijk heb ik daar geen enkel probleem mee gehad. Integendeel zelfs. Die nadelen wegen dan ook zeer zeker niet op tegen de voordelen.

Vergeet niet dat een platform niet zozeer "geschikt" moet zijn voor beginners en leken, maar voor professional developers. DAT zijn de mensen die er dagelijks mee werken en die veruit het meeste werk doen.

quote:

Ik hoor telkens dezelfde nadelen van XHTML. In de praktijk heb ik daar geen enkel probleem mee gehad. Integendeel zelfs. Die nadelen wegen dan ook zeer zeker niet op tegen de voordelen.

Ik hoor echter ook alleen elke keer hetzelfde "nadeel" van HTML, wat voor de meeste mensen ook helemaal geen nadeel is en derhalve zeker niet opweegt tegen die nadelen die er wel degelijk zijn met XHTML.

Verder dan wellformedness komt deze discussie eigenlijk zelden vanuit het "XHTML-kamp" en dat is jammer.

Bosmonster wijzigde dit bericht 14-04-2010 19:14 (12%)

quote:

Maar de huidige browsers doen ook met XHTML sowieso niet moeilijk over invalidness.

Net getest:

Firefox geeft nog steeds een YSOD
Safari geeft een error en een rendering tot aan het punt van de wellformedness error
Opera geeft ook een errorpage, met een optie om de pagina als HTML te renderen

Voor een bezoeker zal de manier waarop de error wordt gerapporteerd niet zoveel uitmaken; voor hem of haar is alleen duidelijk dat de site stuk is.

quote:

crisp schreef op woensdag 14 april 2010 @ 19:15:
[...]

Net getest:

Firefox geeft nog steeds een YSOD
Safari geeft een error en een rendering tot aan het punt van de wellformedness error
Opera geeft ook een errorpage, met een optie om de pagina als HTML te renderen

Voor een bezoeker zal de manier waarop de error wordt gerapporteerd niet zoveel uitmaken; voor hem of haar is alleen duidelijk dat de site stuk is.

Zeg er dan eventjes bij dat je het hebt over XHTML met het correcte mime-type, wat Fuzzillogic niet zal bedoelen

quote:

Wolfboy schreef op woensdag 14 april 2010 @ 19:34:
[...]
Zeg er dan eventjes bij dat je het hebt over XHTML met het correcte mime-type, wat Fuzzillogic niet zal bedoelen

Ik neem juist aan dat Fuzzillogic dat wel bedoelt, anders blijft er van de andere 'voordelen' van XHTML (extensibility mbv namespaces e.d.) ook weinig meer over

quote:

crisp schreef op woensdag 14 april 2010 @ 19:42:
[...]

Ik neem juist aan dat Fuzzillogic dat wel bedoelt, anders blijft er van de andere 'voordelen' van XHTML (extensibility mbv namespaces e.d.) ook weinig meer over

Waar, maar dan zeuren alle browsers (afaik dan) wel over wellformedness. En de meeste browsers zeuren naar mijn weten niet als je in een html pagina wat namespaces e.d. toevoegt. Of het allemaal goed functioneert... dat is weer een hele andere vraag.

quote:

crisp schreef op woensdag 14 april 2010 @ 19:42:
[...]

Ik neem juist aan dat Fuzzillogic dat wel bedoelt, anders blijft er van de andere 'voordelen' van XHTML (extensibility mbv namespaces e.d.) ook weinig meer over

Ik heb het idd over correct mime-type. Maar ik heb het ook over well-formed XML vs valid XHTML. Uiteraard moet het well-formed zijn. Maar well-formed-maar-invalid doen browsers niet moeilijk over. En aangezien je wel heel erg... nouja... moet zijn om niet in staat te zijn om well-formed XML te produceren acht ik dat niet als nadeel. (juist als voordeel zelfs)

Ik ben ook weer een beetje aan het hobbyen gegaan (gewoon uit interesse). Als ik het goed begrijp is het mogelijk om HTML5 te schrijven als XML serialisation en als HTML serialisation. Nu lijkt het er op dat de XML serialisation feitelijk een implementatie is van de XHTML1.0 standaard, wat dus zou betekenen dat de 'nieuwe' tags als nav, section, video en audio enz. niet werken. Een eenvoudige proef bevestigt dit tot dusver.

Is dit iets wat nog moet worden doorgevoerd in bijvoorbeeld de browsers of bestaat de XML serialisation alleen vanwege de backward compatibility met bestaande XHTML (wat ik me moeilijk kan voorstellen)?

quote:

LB06 schreef op dinsdag 25 mei 2010 @ 01:41:
Ik ben ook weer een beetje aan het hobbyen gegaan (gewoon uit interesse). Als ik het goed begrijp is het mogelijk om HTML5 te schrijven als XML serialisation en als HTML serialisation.

Serialization? Dat is het omzetten van een datastructuur of een object in een ander formaat zoals XML, of een BLOB.

quote:

Nu lijkt het er op dat de XML serialisation feitelijk een implementatie is van de XHTML1.0 standaard, wat dus zou betekenen dat de 'nieuwe' tags als nav, section, video en audio enz. niet werken. Een eenvoudige proef bevestigt dit tot dusver.

Als het goed is moet het XHTML5 worden. Heb je bij je test de XHTML met juiste doctype en mimetype verzonden? Of als je lokaal test, met de juiste extensie.

Sebazzz wijzigde dit bericht 25-05-2010 07:35 (7%)

En in de juiste browser, IE ondersteunt de html5 tags niet zonder hack.

Het gaat ook niet zozeer over het gebruiken van de complete html5 standaard, want die is nog niet definitief en goed ondersteund, maar om de doctype.

De doctype is <!DOCTYPE html>

Als ik middels mod-rewrite of de php-functie header("Content-type: application/xhtml+xml"); het xml mimetype meegeef, krijg ik een parse error (ongedefinieerde entiteit) in FF op de regel waarin ik mijn eerste html5-tag aanroep. Met het default mime-type text/html krijg ik vanzelfsprekend geen parse error.

edit:

Die ongedefinieerde entiteit ging over & nbsp; en niet over de tag <header>. De nieuwe HTML tags doen het dus wel gewoon als XML. Mea culpa.

HarmoniousVibe wijzigde dit bericht 25-05-2010 09:46 (19%)

Precies. En aangezien het topic over een hobbyist gaat zou ik zeggen, waarom moeilijk doen als het makkelijk kan

Laat die X-meuk lekker zitten, het voegt niks toe dan hoofdbrekens. Want het verschilt ook nog eens per browser hoe en wat je moet serveren door het ontbreken van xhtml ondersteuning in IE.

Bosmonster wijzigde dit bericht 25-05-2010 09:43 (25%)

Hey leuk, deze oude discussie weer

Ik vind het jammer dat ik niet dit kan schrijven in (X)HTML
code:

<div/>

Of kan dat wel in HTML5?

Was het zo moeilijk om de parser (en specs) daarvoor aan te passen?

quote:

apokalypse schreef op woensdag 26 mei 2010 @ 23:54:
Hey leuk, deze oude discussie weer

Ik vind het jammer dat ik niet dit kan schrijven in (X)HTML
code:

<div/>

Wat zou het nut ervan zijn?

quote:

Of kan dat wel in HTML5?

nee

quote:

Was het zo moeilijk om de parser (en specs) daarvoor aan te passen?

1 woord: backwardscompatibility

Dat lijkt me een suffe reden, je wilt immers dat de nieuwe standaard backwards compatbile is met oude content, andersom boeit niet zo heel erg (nieuwe features hoeven het niet in oude browsers te doen - anders konden ze <video> e.d. ook wel meteen droppen). In HTML5 lege div tags toelaten breekt dus helemaal niets.

.oisyn wijzigde dit bericht 27-05-2010 00:54 (10%)

quote:

.oisyn schreef op donderdag 27 mei 2010 @ 00:53:
Dat lijkt me een suffe reden, je wilt immers dat de nieuwe standaard backwards compatbile is met oude content, andersom boeit niet zo heel erg (nieuwe features hoeven het niet in oude browsers te doen - anders konden ze <video> e.d. ook wel meteen droppen). In HTML5 lege div tags toelaten breekt dus helemaal niets.

<video> heeft echter wel verplicht een closing tag en kan fallback content bevatten en is daarmee backwards compatible met gracefull degradation

Syntax als <div/> toestaan breekt echter wel in oude en hedendaagse browsers (waar we zeker nog een poos mee opgescheept zitten) en heeft verder weinig aantoonbaar nut. Als je 'compactere syntax' als nut zou zien dan moet je zeker niet voor XML-syntax gaan; dan biedt een SGML-like syntax namelijk juist veel meer mogelijkheden

quote:

crisp schreef op donderdag 27 mei 2010 @ 00:13:
Wat zou het nut ervan zijn?

Scheelt typen. En het is valide XML. Praktisch heeft het weinig toegevoegde waarde behalve flexibiliteit. Ook kan je wellicht consistenter werken. Lege containers zul je dan niet hoeven te maken.

quote:

crisp schreef op donderdag 27 mei 2010 @ 00:13:

1 woord: backwardscompatibility

Als het wel mag in HTML5, dan heeft dit niks met backwardscompatibility te maken? Dan zou <input type=number> ook niet mogen.

edit: ik had de reactie hierboven moeten lezen
Maar dit is geen backwardscompatibility. Dit is forward compatibility, je wilt immers dat HTML4 browsers HTML5 kunnen lezen zonder te breken.

apokalypse wijzigde dit bericht 27-05-2010 12:55 (14%)

quote:

apokalypse schreef op donderdag 27 mei 2010 @ 12:53:
[...]

Dit is forward compatibility, je wilt immers dat HTML4 browsers HTML5 kunnen lezen zonder te breken.

Je beschrijft hier juist backward compatibility.

quote:

apokalypse schreef op donderdag 27 mei 2010 @ 12:53:
[...]

edit: ik had de reactie hierboven moeten lezen
Maar dit is geen backwardscompatibility. Dit is forward compatibility, je wilt immers dat HTML4 browsers HTML5 kunnen lezen zonder te breken.

Ligt er aan vanaf welke kant (de browser of de HTML5 specificatie) je het bekijkt natuurlijk Maar het gaat er inderdaad om dat HTML4 browsers er niet meteen over struikelen wat de adoptie van HTML5 natuurlijk bevordert.

Maar volgens mij kan <div/> wel in XHTML5 (met juiste mimetype). In HTML5 heeft de / voor de > echter geen betekenis en is ook alleen maar conforming gemaakt na veel aandringen van XHTML-puristen; grappig detail is dat toen deze opmerking in de draft is geplaatst:

quote:

This character has no effect except to appease the markup gods. As this character is therefore just a symbol of faith, atheists should omit it.

Inmiddels is het concept 'self-closing tag' wel opgenomen in de tokenisatie, maar is conformance in de HTML-serialisatie beperkt tot de bekende 'empty' elementen zoals <br> en <img>.

quote:

Bosmonster schreef op donderdag 27 mei 2010 @ 13:07:
[...]
Je beschrijft hier juist backward compatibility.

• backward compatibility: HTML5 browsers kunnen HTML4 lezen zonder te breken.
• forward compatibility: HTML4 browsers kunnen HTML5 lezen zonder te breken.

Of heet tegenwoordig alles backward compatibility

quote:

apokalypse schreef op donderdag 27 mei 2010 @ 13:28:
[...]

• backward compatibility: HTML5 browsers kunnen HTML4 lezen zonder te breken.
• forward compatibility: HTML4 browsers kunnen HTML5 lezen zonder te breken.

Of heet tegenwoordig alles backward compatibility

Het gaat erom vanuit welk perspectief je het bekijkt... Je ontwikkelt nu een standaard die ook nog werkt onder oudere software en die dus backward compatible is.

laten we maar weer on topic

Bosmonster wijzigde dit bericht 27-05-2010 13:57 (35%)

Wehehe. Momenteel werkt wehkamp.nl niet in Opera, omdat de prutsers wat unescaped ampersands in de code hebben staan, terwijl ze de pagina wel als application/xhtml+xml aanleveren (waarvoor hulde overigens). Sja, de XML-parser van Opera geeft dan de vinger. Nou hoor ik de HTML-fans al roepen "zie je wel!", waarop ik terugroep: als de browsers zich aan de specs hadden gehouden dan hadden de devvers binnen 1 seconde hun fout ingezien en was de site nu wél welformed XHTML, ipv de borked soep die het nu is.

quote:

Fuzzillogic schreef op dinsdag 08 juni 2010 @ 01:27:
Wehehe. Momenteel werkt wehkamp.nl niet in Opera, omdat de prutsers wat unescaped ampersands in de code hebben staan, terwijl ze de pagina wel als application/xhtml+xml aanleveren (waarvoor hulde overigens). Sja, de XML-parser van Opera geeft dan de vinger. Nou hoor ik de HTML-fans al roepen "zie je wel!", waarop ik terugroep: als de browsers zich aan de specs hadden gehouden dan hadden de devvers binnen 1 seconde hun fout ingezien en was de site nu wél welformed XHTML, ipv de borked soep die het nu is.

Ik gok zomaar dat een wehkamp.nl niet enkel door devvers in elkaar gezet wordt.

En daar zit ook gelijk het grote manco van xhtml, het is niet vergevingsgezind. Een devver kan een perfecte valide xhtml pagina maken en de eerste de beste marketingmedewerker heeft binnen 1 seconde een borkende pagina veroorzaakt.

Pure xhtml volgens de regeltjes vereist een totaal andere mindset dan er nu op het web is.
Pure xhtml betekent dat je elke rss-feed elke keer opnieuw gaat valideren omdat hij anders je pagina kan laten borken, elke copy-paste vanuit Word laat je pagina weer borken.

Het huidige web is meer gebouwd rond de gedachte : as good as it gets ipv de gedachte van 100% perfectie

@Fuzzillogic: Firefox geeft inderdaad ook een Yellow Screen of Death.

@Gomez: Er is geen reden waarom een marketingmedewerker direct aan de HTML hoort te zitten. Alleen iemand met technische kennis hoort dat te doen.

quote:

Pure xhtml betekent dat je elke rss-feed elke keer opnieuw gaat valideren omdat hij anders je pagina kan laten borken, elke copy-paste vanuit Word laat je pagina weer borken.

Dat geldt alleen als je je RSS feed embed in de pagina zelf, maar ik geloof niet dat er veel browsers zijn die dat ondersteunen.

HTML of XHTML, dit is gewoon een prutsfout idd.

Als je al (echt) XHTML wilt gebruiken dan moet je hele tool-chain XML-based zijn om dit soort fouten te voorkomen. Blijkbaar is dat bij Wehkamp niet het geval en dus is XHTML dan een verkeerde keuze

Overigens is dit ook een issue bij wehkamp: http://www.wehkamp.nl/Zoe...k=ART&CC=&Ntt=%00

crisp wijzigde dit bericht 08-06-2010 09:45 (24%)

quote:

Sebazzz schreef op dinsdag 08 juni 2010 @ 07:48:
@Gomez: Er is geen reden waarom een marketingmedewerker direct aan de HTML hoort te zitten. Alleen iemand met technische kennis hoort dat te doen.

Ik ken persoonlijke geen enkele WYSIWYG XHTML editor welke goed overweg kan met een copy&paste aktie vanuit word. Of welke een tekst als 'Up & down' netjes omzetten naar 'Up &_amp; down'. (zonder underscore uiteraard) of welke diakritische omzetten naar de juiste escape code rekening houden met de gebruikte encoding. Overigens is dat probleem ook in HTML aanwezig, alleen gaat geen browser op z'n bek als het een keer niet gebeurt.

quote:

Dat geldt alleen als je je RSS feed embed in de pagina zelf, maar ik geloof niet dat er veel browsers zijn die dat ondersteunen.

Dat is toch gewoon web 2.0? Websites halen hun content van verschillende bronnen (youtube, flickr, etc) en tonen dat als een geheel aan de bezoeker.

XHTML is theoretisch ideaal alleen in de praktijk niet haalbaar. En geloof mij. In het geval van Wehkamp wil jij als developer niet continue de content verbeteren. Ons platform is XHTML based, maar wordt door de output renderer omgezet naar HTML. En onze websites werken perfect in alle browsers sinds 2001 (IE 5.5 en hoger).

Ofwel XHTML is in de praktijk alleen te gebruiken als (of andere) developers verantwoordelijk zijn voor de content op de website. In alle andere gevallen in HTML gewoon de betere keuze in de praktijk en jouw website moet werken in de praktijk, niet in een laboratorium..

quote:

Niemand_Anders schreef op dinsdag 08 juni 2010 @ 11:57:
[...]

Ik ken persoonlijke geen enkele WYSIWYG XHTML editor welke goed overweg kan met een copy&paste aktie vanuit word.

Dat is ook precies de reden van een Word-importer bij bijvoorbeeld TinyMCE. Word produceert zulke slechte rommel dat een directe copy/paste inderdaad je (x)html verneukt. De enige oplossing is om een aparte invoer te faciliteren; er altijd vanuit gaan dat een "normale" copy/paste zo grondig moet worden opgeschoond kan namelijk ook verkeerde gevolgen hebben.

quote:

Bosmonster schreef op donderdag 27 mei 2010 @ 13:55:
[...]


Het gaat erom vanuit welk perspectief je het bekijkt... Je ontwikkelt nu een standaard die ook nog werkt onder oudere software en die dus backward compatible is.

laten we maar weer on topic

Geen van beide termen zijn van toepassing als je bekijkt vanuit de HTML5 standaard. Een backwards compatible standaard is eentje waarbij een vorige versie niet hoeft worden aangepast om te blijven werken. Een forward compatible standaard is eentje waarbij er rekening is gehouden met toekomstige aanpassingen van de standaard. Als je het bekijkt vanuit HTML4, dan is geen support voor <div/> in HTML5 een manier om HTML4 en bijbehorende browsers forward compatible te houden. Maar daat heeft weer niets te maken met forward-compatibiliteit van HTML5.

Backward-compatibiliteit is sowieso fout, vanuit welke hoe je het ook benadert. HTML5 en bijbehorende browsers blijven sowieso backward-compatible, of je nou <div/> ondersteunt of niet (oude code breekt niet). Als je het benadert van oudere browser of HTML4, dan betekent dat dat ze compatible zijn met HTML van voor versie 4.

Ergo, we hebben het over de forward compatibiliteit van HTML4.

En hoe noem je het dan dat bijvoorbeeld de html5 doctype werkt (alsin standardsmode triggered) onder alle oude browsers? Die doctype is toch gewoon backwards compatible

Bosmonster wijzigde dit bericht 08-06-2010 13:57 (10%)

Wikipedia: Backward compatibility

quote:

In other contexts, a product or a technology is said to be backward compatible when it is able to fully take the place of an older product, by inter-operating with products that were designed for the older product.

Dus, ja, dat heet idd backward compatible. Maar het ging over de <div/> feature he, die duidelijk in die zin niet backward compatible zou zijn

.edit: en toen lulde ik mezelf klem

.oisyn wijzigde dit bericht 08-06-2010 14:06 (69%)

quote:

.oisyn schreef op dinsdag 08 juni 2010 @ 14:03:
Wikipedia: Backward compatibility

.edit: en toen lulde ik mezelf klem

Dan hou ik er ook over op, voordat ik mezelf ook alsnog klem lul