XHTML vs HTML 4.01

[JayVee]

Hallo!

Overal wordt aangeraden om lekker XHTML 1.01 strict markup te schrijven.

Prima, ik zie het nut van semantische markup in en heb dan ook al onze (bedrijfje) sites in XHTML 1.1 geschreven.

Laatst kwam ik echter deze blog van Anne tegen waarin naar dit document verwezen wordt. Hier staat duidelijk dat je XHTML pagina's ook met een xhtml mime type moet versturen en waarom. (Annes blog is trouwens XHTML en wordt ook als xhtml verstuurd. Resultaat: Dikke fouten in IE6!)

Wat moet je nou doen? Voorbeelden volgen?
• A List Apart en Mezzoblue gebruiken XHTML maar versturen het als text/html!
• De W3C validator (!) verstuurt ook XHTML als text/html
• Eric Meyer gebruikt HTML 4.01 en HTML 4.0

Zoekmachines lijken XHTML weer mooier te vinden. Maar geldt dat ook voor HTML 4.01 strict?

Ik heb ook ergens gelezen dat je bij een "echt" XHTML document

code:

<?xml version="1.0"?>

moet gebruiken aangezien het xml is. Als je dat doet gebruikt IE echter quirks mode omdat hij geen DOCTYPE kan vinden in de eerste regel.

Ik weet het even niet meer. Jullie wel?

[ Voor 4% gewijzigd door JayVee op 25-09-2004 13:08 ]

[dxta]

code:

<?xml version="1.0"?>

Wordt alleen gebruikt in XML documenten, niet in XHTML documenten.
Verder is verstruren als text/html sowieso logisch, de markup wordt er beter door en het wordt niet fout gerekend door de validator.

[crisp]

Een xml-declaratie boven je document zetten is uit den boze; het wordt juist gedaan om IE in quirks-mode te dwingen, maar als je dat wilt (en dat wil je want IE in standards-mode is nog buggier dan IE in quirksmode) kan je beter een HTML-comment boven de DTD zetten.
GoT wordt trouwens ook XHTML 1.0 strict, maar verstuurd met text/html mimetype. Waarom? Om toch enerszijds een intentie aan te geven, maar anderszijds de IE-users niet voor hun neus te stoten. Daarbij kunnen we niet garanderen dat alle markup altijd volledig 100% valid is - we hebben teveel te maken met oude meuk in de database...

[We Are Borg]

crisp schreef op 25 september 2004 @ 13:15:
Een xml-declaratie boven je document zetten is uit den boze; het wordt juist gedaan om IE in quirks-mode te dwingen, maar als je dat wilt (en dat wil je want IE in standards-mode is nog buggier dan IE in quirksmode) kan je beter een HTML-comment boven de DTD zetten

Waarom kan je beter een HTML comment plaatsen i.p.v. die xml declaratie ? Het wordt allebei gedaan om IE in quircks-mode te dwingen begrijp ik uit je verhaal

[crisp]

We Are Borg schreef op 25 september 2004 @ 13:22:
[...]

Waarom kan je beter een HTML comment plaatsen i.p.v. die xml declaratie ? Het wordt allebei gedaan om IE in quircks-mode te dwingen begrijp ik uit je verhaal

Omdat het geen xml is

[Verwijderd]

Dxta schreef op 25 september 2004 @ 13:14:

code:

<?xml version="1.0"?>

Wordt alleen gebruikt in XML documenten, niet in XHTML documenten.

En aangezien een XHTML document ook een XML document in, kun je daar prima een XML declaration boven zetten. Die is overigens optioneel.

Verder is verstruren als text/html sowieso logisch, de markup wordt er beter door en het wordt niet fout gerekend door de validator.

Wat niet fout gerekend wordt door de validator is niet automatisch goed. Alleen dat "de markup wordt er beter door" begrijp ik niet. Er wordt uiteraard op gedoeld dat de documenten niet met de ideale content-type worden geserveerd: application/xhtml+xml, dus waarom zou met text/html de markup beter worden?

Overigens houd ik zelf IE wel in strict mode, voor zover mogelijk. En ik zorg dat het als text/html verstuurd wordt aangezien wij vaak niet volledige controle hebben over de content. En al is het meestal zo dat die wel well-formed is, wil ik niet dat de gebruiker een dikke foutmelding krijgt.

[crisp]

Met IE in strict mode beperk je je wel tot IE6; als je je dat kan veroorloven qua doelgroep is daar niets mis mee, maar ik ben ook al tegen zoveel gekke dingen aangelopen met IE6 in strict-mode dat ik het voorlopig nog niet aandurf. Van IE in quirksmode ken ik de beperkingen, de bugs en de work-arounds en dan werkt het meestal ook nog prima in IE5.5.

En ja, xhtml is een subset van xml met eigen regels, maar gevoelsmatig vind ik een xml-declaration toch fout; xhtml is immers meer dan alleen een data-container.

[ Voor 20% gewijzigd door crisp op 25-09-2004 13:38 ]

[Bluestorm]

crisp schreef op 25 september 2004 @ 13:15:
Een xml-declaratie boven je document zetten is uit den boze; het wordt juist gedaan om IE in quirks-mode te dwingen, maar als je dat wilt (en dat wil je want IE in standards-mode is nog buggier dan IE in quirksmode) kan je beter een HTML-comment boven de DTD zetten.

Nou ja... uit den boze... het klopt op zich wel.

An XML declaration is not required in all XML documents; however XHTML document authors are strongly encouraged to use XML declarations in all their documents. Such a declaration is required when the character encoding of the document is other than the default UTF-8 or UTF-16 and no encoding was determined by a higher-level protocol. Here is an example of an XHTML document. In this example, the XML declaration is included.

(http://www.w3.org/TR/xhtml1/)

of het handig is, is natuurlijk een andere vraag.

[Verwijderd]

Er zijn methoden om CSS zo toe te passen dat het uiteindelijk weinig uitmaakt of je document strict wordt genomen of niet. Zo moet je bijvoorbeeld voorkomen dat je èn een breedte, èn een padding in de breedterichting tegelijk opgeeft.

of het handig is, is natuurlijk een andere vraag.

Als je zorgt dat de webserver de nodige informatie meestuurt kun je die XML declaratie gerust achterwege laten. Hetzelfde geldt voor de (volkomen achterlijke want niet correct gebruikte) meta http-equiv tag die aangeeft welk content-type en charset gebruikt (hadden moeten) worden.

[crisp]

van dezelfde pagina:

Be aware that processing instructions are rendered on some user agents. Also, some user agents interpret the XML declaration to mean that the document is unrecognized XML rather than HTML, and therefore may not render the document as expected. For compatibility with these types of legacy browsers, you may want to avoid using processing instructions and XML declarations. Remember, however, that when the XML declaration is not included in a document, the document can only use the default character encodings UTF-8 or UTF-16.

dus ja...

[Verwijderd]

Overal wordt aangeraden om lekker XHTML 1.01 strict markup te schrijven.

Echt waar?

(Annes blog is trouwens XHTML en wordt ook als xhtml verstuurd. Resultaat: Dikke fouten in IE6!)

IE krijg text/html, lijkt me eerder dat het aan m'n CSS ligt.

Wat moet je nou doen?

HTML.

[Clay]

'application/xhtml+xml' SHOULD be used for serving XHTML documents to XHTML user agents. Authors who wish to support both XHTML and HTML user agents MAY utilize content negotiation by serving HTML documents as 'text/html' and XHTML documents as 'application/xhtml+xml'. Also note that it is not necessary for XHTML documents served as 'application/xhtml+xml' to follow the HTML Compatibility Guidelines.

^{http://www.w3.org/TR/xhtm...es/#application-xhtml-xml}

Om compatible te blijven MAG je dus text/html gebruiken. Wat dan wel weer suf is is dat de specs elkaar ook wel eens tegespreken. Hier staat b.v. dat het voor xhtml1.1 ook mag:
http://www.w3.org/TR/xhtml-media-types/#summary

En hier dat het weer niet mag:
http://www.w3.org/MarkUp/2004/xhtml-faq#mime11

Er zijn nog meer pagina's verstopt op die w3 site hierover die ik even niet kan vinden, maargoed.

Wat Anne en anderen proberen te zeggen is dat het schrijven van semantisch correcte markup niet pas bij XHTML begonnen is. In HTML4 (en eigenlijk alles daarvoor) had je het ook al moeten doen. DAN is het ook ineens een feit dat markup in HTML korter is dan XHTML, en dat het beter de specs kan volgen zonder een "should" niet op te (kunnen) volgen.

Een hoger getal is niet per definitie beter, dus ik zou geen 1.1 gebruiken omdat die bestaat. Ik vind het alleen wel een beetje onzin om heel XHTML af te zweren omdat je het inderdaad niet zonder meer als application/xhtml+xml kan versturen. Volgens de specs hoeft het ook niet. Het zou wel moeten, maar interpreteer dat niet stricter dan het is. Anders had er wel must gestaan, zoals bij 1.1.

[-Lars-]

Als je geen gebruikt maakt van de extra's die XHTML kan bieden, lijkt mij het het beste voorlopig HTML te gebruiken. Dit omdat het beter en breder ondersteund is door meer webbrowsers en omdat het ook voorlopig nog wel overal ondersteund zal blijven. Ook in HTML kun je letten op semantiek en CSS op een correcte manier gebruiken.

Zelf gebruik ik echter - tegen mijn advies in - XHTML. Voornamelijk omdat het veel cooler lijkt om bleeding edge te zijn en omdat ik al was overgestapt op XHTML als voordat ik van de nadelen hoorde en niet alles weer wilde downgraden. Onderdelen van de site waarvan ik zeker weet dat het geldige XHTML is, serveer ik als application/xhtml+xml, onderdelen waar ik nog geen echte controle op heb (m'n forumpje) serveer ik voorlopig als text/html, om er zeker van te zijn dat de bezoeker het kan zien. Voor MSIE serveer ik gewoon alles als text/html, omdat IE-ers ook nog wat willen zien. Uiteindleijk gaat het er toch om dat de de site bij de bezoeker in beeld komt.

Ik snap waarom bij XHTML als application/xhtml+xml niet wordt weergegeven als er een fout in zit - om zo goed gecode pagina's af te dwingen en correcte werking te garanderen - , toch denk ik dat dit iets is waarom velen nooit zullen overstappen op XHTML als application/xhtml+xml. Gewoon omdat ze niets geven om de syntactische fouten, zolang het maar werkt in IE (voor de veel mensen de enige browser die er bestaat).

[BtM909]

Clay schreef op 25 september 2004 @ 14:13:
[...]
Een hoger getal is niet per definitie beter, dus ik zou geen 1.1 gebruiken omdat die bestaat. Ik vind het alleen wel een beetje onzin om heel XHTML af te zweren omdat je het inderdaad niet zonder meer als application/xhtml+xml kan versturen. Volgens de specs hoeft het ook niet. Het zou wel moeten, maar interpreteer dat niet stricter dan het is. Anders had er wel must gestaan, zoals bij 1.1.

Je had het niet beter kunnen omschrijven

Daarnaast zou je natuurlijk eventueel met accept-header kunnen kijken of bepaalde browser xhtml+xml ondersteunen en dan je header aanpassen. Dacht dat een aantal blogs dat ook op die manier toepasten..

[Genoil]

BtM909 schreef op 25 september 2004 @ 15:21:
[...]

Daarnaast zou je natuurlijk eventueel met accept-header kunnen kijken of bepaalde browser xhtml+xml ondersteunen en dan je header aanpassen

hier heb ik een php5 scriptje voor, dat icm een willekeurige xsl sheet zou moeten werken:

PHP:

<?php
    
    $x = (stristr($_SERVER["HTTP_ACCEPT"],"application/xhtml+xml")) ? true : false;

    $oa = array();
    $oa['method'] = $x ? "xml" : "html";
    $oa['version'] = $x ? "1.0" : "4.01";
    $oa['media-type'] = $x ? "application/xhtml+xml" : "text/html";
    $oa['encoding'] = "UTF-8";
    $oa['doctype-public'] = $x ? "//W3C//DTD XHTML 1.0 Strict//EN": 
 "//W3C//DTD HTML 4.01 Strict//EN" ;
    $oa['doctype-system'] = $x ? "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd": 
"http://www.w3.org/TR/html4/strict.dtd";
    $oa['omit-xml-declaration'] = $x ? "no" : "yes";
    $oa['indent'] = "yes";
            
    $xmldoc = new DomDocument();
    $xmldoc->load($_GET['xml']);

    $xsltdoc = new DomDocument();
    $xsltdoc->load($_GET['xsl']);
    
    $xpath = new Domxpath($xsltdoc);
    $result = $xpath->query("//xsl:output");
    
    if($result->length == 0) {
        $result2 = $xpath->query("//xsl:stylesheet");
        $stylesheet = $result2->item(0);
        $output = $xsltdoc->createElementNS("http://www.w3.org/1999/XSL/Transform",
"xsl:output");
        
        $stylesheet->insertBefore($output,$stylesheet->firstChild);
        foreach($oa as $name => $value) 
            $output->setAttribute($name, $value);
    }
    else 
        foreach($result as $output) 
            foreach($oa as $name => $value) 
                $output->setAttribute($name, $value);

    $xsltproc= new Xsltprocessor();
    $xsl = $xsltproc->importStylesheet($xsltdoc);
    $xsltproc->setParameter("", "outputmethod", $oa['method']);
    
    header("content-type:".$oa['media-type'].";charset=".$oa['encoding']);      
    print $xsltproc->transformToXml($xmldoc);
?>

ik had het al eens eerder gepost, maarja deze discussie lijkt ook tweewekelijks terug te keren .

[JayVee]

Verwijderd schreef op 25 september 2004 @ 14:02:
[...]
Echt waar?

Ik zat nog te twijfelen of ik "Bijna overal" moest schrijven. Maar goed, bijna overal raden ze aan XHTML te schrijven. Maar of ze daarmee echt XHTML bedoelen of semantisch HTML... dat valt niet altijd te redeneren.

IE krijg text/html, lijkt me eerder dat het aan m'n CSS ligt.

Oh, hmkay! Test je uit principe niet met IE?

HTML.

Zeg jij!


Om mijn zicht op dit moment even samen te vatten:
Gebruik XHTML als je bleeding edge wilt gebruiken (en uitstralen), maar verstuur het nou maar gewoon als text/html voor de betere compatibiliteit.

Als je de standaard op 100% wilt naleven kan je dus beter HTML 4.01 strict gebruiken.

Is dus meer een principe kwestie dan echt technisch te argumenteren.

[Verwijderd]

-Larz- schreef op 25 september 2004 @ 15:16:
Ik snap waarom bij XHTML als application/xhtml+xml niet wordt weergegeven als er een fout in zit - om zo goed gecode pagina's af te dwingen en correcte werking te garanderen - , toch denk ik dat dit iets is waarom velen nooit zullen overstappen op XHTML als application/xhtml+xml. Gewoon omdat ze niets geven om de syntactische fouten, zolang het maar werkt in IE (voor de veel mensen de enige browser die er bestaat).

Waarom je een XML error krijgt is vrij simpel te verklaren, de browser gebruikt niet de normale HTML parser, maar de ingebouwde XML parser en zodra er een fout in het document zit hoort de parser het renderen meteen af te breken, gebeurt zelfs in IE.

Puur als toevoeging btw.
http://weblogs.mozillazin...hives/2004_01.html#004754

[-Lars-]

Als je XHTML ziet als verbetering en uiteindelijke vervanging van HTML, dan zullen velen in de problemen raken omdat ze gewoonweg geen aandacht aan de code zelf schenken. Daar is niets mis mee, want sommige mensen interesseren zich gewoon niet voor semantisch en syntactisch gezien correcte code.
Voorlopig blijft HTML gewoon bestaan en is het algemeen geaccepteerd, maar op den duur zal vernieuwing toch zijn tol eisen en dan zullen mensen wel moeten overstappen op XHTML om van alle nieuwe extratjes gebruik te kunnen maken. (Die zijn er nu nog niet echt voor de huis-tuin-keuken-MSN-CU2-websitebouwer, maar ik denk dat er vast nog wel een toepassing van het Extensible te bedenken is.)

Ik hoop dat ik het goed heb en er dus geen HTML 5 in de maak is?

[coubertin119]

offtopic:
Er is weldegelijk een HTML 5 in de maak door whatwg.org.

[Verwijderd]

Dat hele xhtml gedoe is sowieso zinloos. Ik bedoel, wat schiet je er nou mee op?

[-Lars-]

quote: http://www.w3schools.com/xhtml/xhtml_why.asp

Why XHTML?

We have reached a point where many pages on the WWW contain "bad" HTML.

The following HTML code will work fine if you view it in a browser, even if it does not follow the HTML rules:

HTML:

<html>
<head>
<title>This is bad HTML</title>
<body>
<h1>Bad HTML
</body>

XML is a markup language where everything has to be marked up correctly, which results in "well-formed" documents.

XML was designed to describe data and HTML was designed to display data.

Today's market consists of different browser technologies, some browsers run internet on computers, and some browsers run internet on mobile phones and hand helds. The last-mentioned do not have the resources or power to interpret a "bad" markup language.

Therefore - by combining HTML and XML, and their strengths, we got a markup language that is useful now and in the future - XHTML.

XHTML pages can be read by all XML enabled devices AND while waiting for the rest of the world to upgrade to XML supported browsers, XHTML gives you the opportunity to write "well-formed" documents now, that work in all browsers and that are backward browser compatible !!!

Zoals al eerder gezegd in dit topic: semantiek en het gebruik van CSS hebben niets te maken met de verschillen tussen HTML en XHTML. Ook wordt je site er niet sneller van.

[Verwijderd]

Het lijkt me verstandig om ook gewoon in html je tags af te sluiten.
En ik ga geen mobieltje kopen die geen 'normale' html-pagina's kan weergeven.

[MarkvE]

Verwijderd schreef op 26 september 2004 @ 21:17:
Het lijkt me verstandig om ook gewoon in html je tags af te sluiten.
En ik ga geen mobieltje kopen die geen 'normale' html-pagina's kan weergeven.

Maar dat is dus het hele punt. Zolang je gebruikers niet verplicht de regels (volgens een bepaalde structuur, met een idee daarachter) te volgen, krijg je één grote teringbende waaruit het hedendaagse web voor 90% uit bestaat.

Dat is dan ook het voornaamste verschil tussen HTML en XHTML; XHTML verplicht de auteur zich conform de regels zijn website te ontwerpen, HTML accepteert ook minder valide code omdat deze minder strikte regels hanteert. En zo ontstaat er dus het conflict tussen de hedendaagse webstandaarden en de "HTML-ers" die zich van geen kwaad bewust zijn.

[ Voor 4% gewijzigd door MarkvE op 26-09-2004 22:29 ]

[Verwijderd]

MarkvE schreef op 26 september 2004 @ 22:28:
[...]
Maar dat is dus het hele punt. Zolang je gebruikers niet verplicht de regels (volgens een bepaalde structuur, met een idee daarachter) te volgen, krijg je één grote teringbende waaruit het hedendaagse web voor 90% uit bestaat.

Waar bestaat die verplichting dan uit? Volgens mij mag iedere gebruiker gewoon doorHTML-en, hoor.
Volgens mij is die bende vooral zo ontstaan, omdat er vroeger geen goede manier was om de boel een beetje leuk op te maken.

Dat is dan ook het voornaamste verschil tussen HTML en XHTML; XHTML verplicht de auteur zich conform de regels zijn website te ontwerpen, HTML accepteert ook minder valide code omdat deze minder strikte regels hanteert. En zo ontstaat er dus het conflict tussen de hedendaagse webstandaarden en de "HTML-ers" die zich van geen kwaad bewust zijn.

Met XHTML kan ik net zo goed invalid code maken, hoor, en die wordt dan toch weergegeven door elke browser.
Je moet altijd een website volgens de regels ontwerpen, ongeacht of het HTML of XHTML is.
Maar je hebt gelijk, ik ben me nog steeds van geen kwaad bewust, vandaar dit conflict

[Verwijderd]

-Larz- schreef op 26 september 2004 @ 21:14:
[...]

Zoals al eerder gezegd in dit topic: semantiek en het gebruik van CSS hebben niets te maken met de verschillen tussen HTML en XHTML. Ook wordt je site er niet sneller van.

Je site wordt er zeker wel sneller van. xhtml vereist namelijk door zijn strikte opmaak minder rekenkracht. Het is daarom ook geschikt voor verschillende pda browsers.

[JeromeB]

Verwijderd schreef op 26 september 2004 @ 23:07:
[...]


Je site wordt er zeker wel sneller van. xhtml vereist namelijk door zijn strikte opmaak minder rekenkracht. Het is daarom ook geschikt voor verschillende pda browsers.

Dat is een afweging die je kunt maken:

Bij een HTML bestand kun je veel tags bijvoorbeeld weglaten (de structuur blijft dan nog wel intact, omdat de elementen wel degelijk aanwezig zijn). Hierdoor kost het minder tijd om bijvoorbeeld een bestand te downloaden.

Bij XHTML is dat niet (of iig in mindere mate) mogelijk. Een XML-parser is echter over het algemeen wel sneller (zegt men) dan een SGML-parser bij het parsen van een document.

[Verwijderd]

Verwijderd schreef op 26 september 2004 @ 23:07:
[...]
Je site wordt er zeker wel sneller van. xhtml vereist namelijk door zijn strikte opmaak minder rekenkracht. Het is daarom ook geschikt voor verschillende pda browsers.

XHTML zorgt niet voor de opmaak, dat doet CSS.

En dat een XML-parser sneller is, dat kan wel zo zijn, maar ik geloof niet dat daar de bottle-neck voor de snelheid van weergave in een browser is. Dat zijn toch meer de layout-gerelateerde dingen, denk ik.

[MarkvE]

Verwijderd schreef op 26 september 2004 @ 22:52:
[...]

Waar bestaat die verplichting dan uit? Volgens mij mag iedere gebruiker gewoon doorHTML-en, hoor.
Volgens mij is die bende vooral zo ontstaan, omdat er vroeger geen goede manier was om de boel een beetje leuk op te maken.

In XHTML wordt je bijvoorbeeld verplicht om tags altijd af te sluiten en je elementen lowercase te schrijven. Anders valideert je code niet en is het geen correcte XHTML. Bij HTML maken deze twee (voorbeelden) niks uit, je hoeft de tags niet af te sluiten en je mag je code zelfs in BrEeZaH-stijl schrijven, het maakt niks uit.

Naar mijn mening is wat dat betreft HTML geen goede taal, te weinig regels (structuur) waardoor websites die hierop gebasseerd zijn (en meestal gemaakt zijn door mensen zijn gemaakt die niet bekend zijn met standaarden) er een grote warboel van maken. Met natuurlijk de uitzonderingen daar gelaten die er nog wel een gestructureerd geheel van maken.

Met XHTML kan ik net zo goed invalid code maken, hoor, en die wordt dan toch weergegeven door elke browser.
Je moet altijd een website volgens de regels ontwerpen, ongeacht of het HTML of XHTML is.
Maar je hebt gelijk, ik ben me nog steeds van geen kwaad bewust, vandaar dit conflict

Wat ik probeer duidelijk te maken is dat HTML slordigheden (en dus fouten) in de hand werkt, omdat het geen structuur vereist. Ofwel er zit een verschil tussen valide HTML en valide XHTML. HTML is nog valide als je vele dingen achterwege laat die je in XHTML niet achterwege mag laten wil het valideren. En met dit gegevens strookt HTML in tegen de modernere opvattingen over het ontwerpen van websites.

[ Voor 9% gewijzigd door MarkvE op 27-09-2004 10:53 ]

[BtM909]

MarkvE schreef op 27 september 2004 @ 10:49:
[...]
Naar mijn mening is wat dat betreft HTML geen goede taal, te weinig regels (structuur) waardoor websites die hierop gebasseerd zijn (en meestal gemaakt zijn door mensen zijn gemaakt die niet bekend zijn met standaarden) er een grote warboel van maken. Met natuurlijk de uitzonderingen daar gelaten die er nog wel een gestructureerd geheel van maken.

Wat wellicht ook mede heeft bijgedragen aan de populariteit. Iedere jan-met de korte achternaam kan een website in elkaar knallen.

Wat ik probeer duidelijk te maken is dat HTML slordigheden (en dus fouten) in de hand werkt, omdat het geen structuur vereist.

Ben ik niet mee eens. De fout zit grotendeels bij de gebruiker. Probleem (of juist uitdaging ) is dat browsers in de 'nabije' toekomst veel minder vergeeflijk zijn. Voordeel daarvan is dat je meteen kaf van koren scheid.

[Not Pingu]

JeromeB schreef op 26 september 2004 @ 23:44:

Bij een HTML bestand kun je veel tags bijvoorbeeld weglaten (de structuur blijft dan nog wel intact, omdat de elementen wel degelijk aanwezig zijn). Hierdoor kost het minder tijd om bijvoorbeeld een bestand te downloaden.

Bij XHTML is dat niet (of iig in mindere mate) mogelijk. Een XML-parser is echter over het algemeen wel sneller (zegt men) dan een SGML-parser bij het parsen van een document.

In HTML is het weglaten van tags ook niet 'goed' hoor. Het is alleen zo dat browsers (vooral IE) een stuk minder streng zijn en slechte documenten toch proberen weer te geven. Dit leidt echter vaak tot een weergave die niet is zoals de ontwerper hem bedoeld had.

Het enige verschil tussen HTML en XHTML is dat XHTML parsers veel strenger zijn. Dat maakt het parsen van een document dus ook veel sneller omdat de parser bij twijfel niet probeert uit te vogelen wat de maker nou zou kunnen bedoelen.

[Verwijderd]

MarkvE schreef op 27 september 2004 @ 10:49:
[...]
In XHTML wordt je bijvoorbeeld verplicht om tags altijd af te sluiten en je elementen lowercase te schrijven. Anders valideert je code niet en is het geen correcte XHTML. Bij HTML maken deze twee (voorbeelden) niks uit, je hoeft de tags niet af te sluiten en je mag je code zelfs in BrEeZaH-stijl schrijven, het maakt niks uit.

Naar mijn mening is wat dat betreft HTML geen goede taal, te weinig regels (structuur) waardoor websites die hierop gebasseerd zijn (en meestal gemaakt zijn door mensen zijn gemaakt die niet bekend zijn met standaarden) er een grote warboel van maken. Met natuurlijk de uitzonderingen daar gelaten die er nog wel een gestructureerd geheel van maken.

Wat maakt het uit? De website die er een grote warboel van maken, die heb ik niet gemaakt, ik bekijk ze alleen. Soms bekijk ik de bron wel eens en denk ik: Tsjonge, tsjonge, wat maken ze er toch een warboel van, maar verder zal het me eerder gezegd een worst wezen.

Het lijkt me handig, dat als je html bewerkt in een tekst-editor dat je een beetje netjes aan de slag gaat: geen overbodige tags gebruiken, indenten, tags afsluiten, etc.

Wat ik probeer duidelijk te maken is dat HTML slordigheden (en dus fouten) in de hand werkt, omdat het geen structuur vereist. Ofwel er zit een verschil tussen valide HTML en valide XHTML. HTML is nog valide als je vele dingen achterwege laat die je in XHTML niet achterwege mag laten wil het valideren. En met dit gegevens strookt HTML in tegen de modernere opvattingen over het ontwerpen van websites.

Als je HTML met een tekst-editor bewerkt, dan lijkt me een beetje structuur wel handig.
Ik weet niet echt wat je bedoelt met de modernere opvattingen over het ontwerpen van websites. Het lijkt me dat je bedoelt, dat je tegenwoordig veel meer css gebruikt dan vroeger, maar dat hoeft zeker niet hand in hand te gaan met het gebruik van XHMTL.

[Verwijderd]

Gunp01nt schreef op 27 september 2004 @ 11:02:
[...]
Het enige verschil tussen HTML en XHTML is dat XHTML parsers veel strenger zijn. Dat maakt het parsen van een document dus ook veel sneller omdat de parser bij twijfel niet probeert uit te vogelen wat de maker nou zou kunnen bedoelen.

Dat hoor ik nou wel steeds, maar is dit ooit onderzocht? Zijn hier harde getallen over te vinden?
En zo ja, stel nou dat een XML parser veel sneller is dan een HTML parser, bijvoorbeeld 2* zo snel, dan heb ik nog steeds ernstige twijfels of de pagina sneller wordt weergegeven (zeker niet 2* zo snel).

[BtM909]

Verwijderd schreef op 27 september 2004 @ 11:08:
[...]

Dat hoor ik nou wel steeds, maar is dit ooit onderzocht? Zijn hier harde getallen over te vinden?
En zo ja, stel nou dat een XML parser veel sneller is dan een HTML parser, bijvoorbeeld 2* zo snel, dan heb ik nog steeds ernstige twijfels of de pagina sneller wordt weergegeven (zeker niet 2* zo snel).

Wat denk je dat een parser doet

[creative8500]

JayVee: in je openingspost stel je dat XHTML mogelijk beter geïndexeerd wordt dan HTML. Niets is minder waar: mijn 'website' is XHTML, en wordt daarom niet geïndexeerd door Google ("unrecognized format"). _{Of noem je text/html ook XHTML?}

[JayVee]

Een parser maakt een boom van het document. Daarna moet je die gaan renderen (CSS erbij betrekken). Ik denk dat daar echt wel meer tijd in gaat zitten dan bij het parsen.

Trouwens, in HTML hoef je niet elke tag te sluiten. <input> of <style> bijvoorbeeld. In XHTML moet je die wel altijd sluiten, bijv. <input />.

<edit>

creative8500 schreef op 27 september 2004 @ 11:14:
JayVee: in je openingspost stel je dat XHTML mogelijk beter geïndexeerd wordt dan HTML. Niets is minder waar: mijn 'website' is XHTML, en wordt daarom niet geïndexeerd door Google ("unrecognized format"). _{Of noem je text/html ook XHTML?}

Nou, zo staat het in dat topic. Zal waarschijnlijk text/html zijn. Maar dan zou ik niet weten waarom XHTML beter werkt dan (mooie) HTML 4.01.
</edit>

[ Voor 54% gewijzigd door JayVee op 27-09-2004 11:18 ]

[Not Pingu]

JayVee schreef op 27 september 2004 @ 11:16:
Een parser maakt een boom van het document. Daarna moet je die gaan renderen (CSS erbij betrekken). Ik denk dat daar echt wel meer tijd in gaat zitten dan bij het parsen.

Mwa. Een HTML parser moet bij twijfel zelf gaan uitvogelen wat een user nou bedoelde. Dat is wel een groot verschil met XHTML waar de parser idd alleen maar de boomstructuur hoeft te genereren voor de renderer.
Zeker bij lijvige documenten kan dat veel schelen omdat de parser bij twijfel waarschijnlijk het document nog een aantal keer naloopt om te kijken wat de beste interpretatie is. Als iemand bijv. zijn table tags steevast niet afsluit, zal de parser dat moeten doen omdat de renderer (neem ik aan) alleen uit de voeten kan met correcte HTML. Dus moet de parser gaan uitzoeken en gokken of die <p> die na de laatste cel komt nou nog in de tabel hoorde of niet. etc.

Trouwens, in HTML hoef je niet elke tag te sluiten. <input> of <style> bijvoorbeeld. In XHTML moet je die wel altijd sluiten, bijv. <input />.

Als ik een style tag niet afsluit wordt alles wat daaronder ligt opgevat als child van de style tag. M.a.w. je hele document wordt niet weergegeven

[Verwijderd]

BtM909 schreef op 27 september 2004 @ 11:10:
[...]

Wat denk je dat een parser doet

Een boomstructuur maken? (tenminste in 'normale' browsers)
Wat denk jij dat een parser doet?

[creative8500]

Verwijderd schreef op 27 september 2004 @ 11:43:
[...]

Een boomstructuur maken? (tenminste in 'normale' browsers)
Wat denk jij dat een parser doet?

Een parser is een tokenizer, geen DOM.

[Verwijderd]

creative8500 schreef op 27 september 2004 @ 11:46:
[...]

Een parser is een tokenizer, geen DOM.

Goed, ik heb eigenlijk niet zo goed een idee wat een tokenizer is (ga nou niet zeggen dat het een parser is ), maar maakt het uit?
Is een HTML tokenizer langzamer dan een XHTML tokenizer?

Ik denk trouwens niet dat een XHTML pagina beter wordt geindexeerd dan een HTML pagina, eerder slechter.

[ Voor 14% gewijzigd door Verwijderd op 27-09-2004 11:51 ]

[Verwijderd]

Verwijderd schreef op 27 september 2004 @ 11:50:
Is een HTML tokenizer langzamer dan een XHTML tokenizer?

Volgens David Hyatt niet:

[..]
In addition there are technical hurdles to the use of XML. Every modern browser, including Mozilla and Safari, is much worse at XHTML than at HTML. People tend to foolishly gloss over the transition from one to the other, thinking that code you write for one will "just work" when you switch to XHTML. That simply isn't true. If you look at XHTML in both Mozilla and Safari and compare it to HTML, you'll see that it's slower, non-incremental, and generally buggier than HTML.

An example of a feature that won't "just work" when moved from HTML to XHTML is editing. The serialization model is totally different for XHTML, and HTML elements that have to be written out when you get the raw markup must know to do so using XML-style syntax in XHTML documents. Editing must be able to serialize namespaces, and ideally even preserve the namespace prefixes that were used at various points in the document as well as the use of default namespaces as set up by the author. Right off the bat I've outlined a challenging editing feature that only exists in the XHTML world. There are many more examples of these kinds of problems.

link: (Mozillazine lijkt dood, dus maar even een google cache)

[ Voor 6% gewijzigd door Verwijderd op 27-09-2004 14:15 ]

[JeromeB]

Gunp01nt schreef op 27 september 2004 @ 11:02:
[...]


In HTML is het weglaten van tags ook niet 'goed' hoor. Het is alleen zo dat browsers (vooral IE) een stuk minder streng zijn en slechte documenten toch proberen weer te geven. Dit leidt echter vaak tot een weergave die niet is zoals de ontwerper hem bedoeld had.

Het weglaten van tags is niet hetzelfde als het weglaten van elementen. Het weglaten van bepaalde tags mag zeker weten wel.

Dat het uiteindelijk kan leiden tot een weergave die niet zo is als de ontwerper wenst is gewoon onzin. De ontwerper heeft dan niet voldoende kennis om een document te structureren.

Lees de specificaties er eens op na:
- http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.1
- http://www.w3.org/TR/html401/struct/global.html

[-Lars-]

Verwijderd schreef op 26 september 2004 @ 23:07:
[...]

Je site wordt er zeker wel sneller van. xhtml vereist namelijk door zijn strikte opmaak minder rekenkracht. Het is daarom ook geschikt voor verschillende pda browsers.

Wat ik bedoelde is omdat je in XHTML tags moet afsluiten en je -door de strictheid- netter en dus meestal ook meer moet coden, je bestandsgrootte groter wordt. Daardoor duurt het langer voordat het bestand is gedownload.

Dat in door de strictheid de browser sneller kan uitvogelen hoe de boel in elkaar zit, daar zit wat in . Hoewel het blijkbaar nog niet zo is (zie bovenstaande post), lijkt mij dat dit vroeg of laat inderdaad gaat kloppen voor browsers. Als de browser een fout stukje XHTML vindt, stopt hij immers meteen, i.p.v. te kijken of er nog wat te repareren aan de code.

[Verwijderd]

Je site wordt er zeker wel sneller van. xhtml vereist namelijk door zijn strikte opmaak minder rekenkracht. Het is daarom ook geschikt voor verschillende pda browsers.

In welke browser is XHTML momenteel sneller? De XML parsers die nu door Opera, Safari en Mozilla gebruikt worden geven een pagina altijd langzamer weer omdat ze eerst de gehele pagina inladen.

[Verwijderd]

Wat ik bedoelde is omdat je in XHTML tags moet afsluiten en je -door de strictheid- netter en dus meestal ook meer moet coden,

IMO is HTML veel netter en makkelijker, zie site in m'n sig voor een simpel voorbeeld.

je bestandsgrootte groter wordt. Daardoor duurt het langer voordat het bestand is gedownload.

Waar vergelijk je XHTML nu mee en hoeveel maakt het uit?

Dat in door de strictheid de browser sneller kan uitvogelen hoe de boel in elkaar zit, daar zit wat in .

Fout, zie vorige comment. Hoewel het theoretisch wel mogelijk is by the way.

Hoewel het blijkbaar nog niet zo is (zie bovenstaande post), lijkt mij dat dit vroeg of laat inderdaad gaat kloppen voor browsers. Als de browser een fout stukje XHTML vindt, stopt hij immers meteen, i.p.v. te kijken of er nog wat te repareren aan de code.

Voor huidige browsers klopt dit niet, zie vorige post (van mij).

[-Lars-]

-Larz- schreef op 27 september 2004 @ 16:08:
[...]
Dat in door de strictheid de browser sneller kan uitvogelen hoe de boel in elkaar zit, daar zit wat in . Hoewel het blijkbaar nog niet zo is (zie bovenstaande post), lijkt mij dat dit vroeg of laat inderdaad gaat kloppen voor browsers. Als de browser een fout stukje XHTML vindt, stopt hij immers meteen, i.p.v. te kijken of er nog wat te repareren aan de code.

Ik zeg ook niet dat dat al het geval is, sterker nog, het punt wat jij aanhaalt zei ik ook al

Ik vergelijk XHTML met HTML, doordat je in XHTML alle tags moet afsluiten, krijg je extra tekens. Zover ik weet zorgen extra tekens altijd voor extra bestandsgrootte, ergo extra downloadtijd. Op kleine sites zal het inderdaad niet zoveel uitmaken, maar een heleboel kleine beetjes extra zal waarschijnlijk zorgen voor een groot stukje extra.

[drm]

crisp:
En ja, xhtml is een subset van xml met eigen regels, maar gevoelsmatig vind ik een xml-declaration toch fout; xhtml is immers meer dan alleen een data-container.

Even afgezien van de praktische consequenties (waarin ik het met je eens ben), slaat het argument dat het "meer dan een datacontainer" is de plank imo volledig mis. Elk XML bestand is meer dan een datacontainer; althans, dat zou het moeten zijn, simpelweg omdat het bestand anders zijn betekenis verliest. Het feit dat XHTML volledig gespecificeerd is, doet nog niets af aan het feit dat het een poging is om de eigenschappen HTML in een XML jasje te steken. Je zou XHTML kunnen zien als een afgeleide van een XML "klasse", waarbij XHTML alles overerft van XML, maar meer toevoegt in de vorm van specificaties, en dan wel specificaties over de betekenis van de elementen.

Verder zou het bestaansrecht van XHTML imo verdwijnen als het niet gezien mag worden als XML. En ik heb een vermoeden dat w3 dat met me eens is, gezien de reden dat ze uberhaupt met XHTML begonnen zijn.

_{en als je stiekem toch alleen de praktische kant ervan bedoelde, dan heb ik niks gezegd}

[Grijze Vos]

creative8500 schreef op 27 september 2004 @ 11:46:
[...]

Een parser is een tokenizer, geen DOM.

een tokenizer is een deel van een parser, maar een parser maakt wel degelijk een boom.

Waar denk je dat de term 'parse tree' vandaan komt?

[ Voor 46% gewijzigd door Grijze Vos op 28-09-2004 18:34 ]

[drm]

Grijze Vos:
een tokenizer is een deel van een parser, maar een parser maakt wel degelijk een boom.

offtopic:
creative8500 is in de war met een lexical analyzer, dunkt me.

[JayVee]

Hey, ik heb over exact deze discussie een topic op mamboserver.com lopen:
Hiero

Wat denken jullie ervan? Klopt alles wat ik zeg? Wat is jullie mening?

[Verwijderd]

gaan we nou discussieren over andere fora

magoe, een cms kan best met xhtml werken imho, een kleine functie kan er voor zorgen dat je html serveert, behalve eventueel voor browsers die wel xhtml ondersteunen.

Zo hoef je "later" niet een ontzettende swap te maken en behoud je aan de serverkant wel de voordelen van xhtml

[JayVee]

Ik wil die hele discussie daar niet over copy-pasten hiernaartoe. Het gaat voornamelijk over mambo maar de argumenten zijn natuurlijk op de complete XHTML vs HTML discussie toepasbaar.

Mijn mening: Waarom zou je XHTML gebruiken als het toch niet goed ondersteund wordt? Als je het als text/html verstuurt heb je niets aan de voordelen van XHTML, dus waarom moeilijk doen?

[Verwijderd]

op de server, binnen een cms kan je wel degelijk voordelen van een xml (lees xhtml) omgeving hebben, voorwaarde is dan wel dat je content gegarandeerd xhtml moet zijn, maar daar ga ik voor het gemak maar even vanuit.

als je wilt kan je deze xhtml meteen doorsturen naar clients als firefox ea, voor browsers die geen xhtml ondersteunen, maak je er even HTML van.

[crisp]

Alleen als een CMS echt 100% XML-based is kan je wellformedness van je output garanderen. Als je die garantie niet hebt is XHTML een bad choice. Tel daarbij op dat voor een webinterface XHTML over het algemeen geen praktische voordelen bied, maar wel nadelen en je conclusie moge duidelijk zijn...

[Dennis]

Een grote website die ik ontwikkel is ook volledig xhtml, maar voor het CMS vind ik het toch lastig om dat te realiseren. Zeker als je met tekst gaat werken die door de gebruiker (die doorgaans weinig verstand van html heeft) wordt geschreven dan kun je natuurlijk wel een xhtml document type gebruiken maar of die dan ook valideert is maar de vraag .

Misschien dat ik op termijn nog gedeeltelijk xhtml ga gebruiken in mijn CMS maar voorlopig vind ik het prima werken met het huidige systeem.

[alienfruit]

Ik maak gewoon de backend in XHTML, en de IE6 gebruiker krijgt gewoon mooi een waarschuwing. Browser zoals firefox, safari en opera krijgen de voorkeur

[We Are Borg]

Ik denk dat dit topic wel een goede plek is om een vraag te stellen waar ik al lang een antwoord op zoek:

Waarom gebruikt de W3C XHTML met text/html, terwijl ze het zelf niet aanraden? Het mag wel, maar liever niet toch niet doen zo. Je kan dan beter terugstappen naar HTML 4.01. Maar zelf doen ze dat vervolgens niet

[JayVee]

Check mijn startpost! Ik vind het inderdaad ook heel raar!

[Verwijderd]

Ze zijn gewoon incompetent.

[Verwijderd]

Stuur eens een HTTP request naar www.w3.org met in de Accept header de content-type application/xhtml+xml en kijk naar het resultaat. Juist. Keurig in application/xhtml+xml met utf-8 charset.
(of gebruik gewoon even Firefox en kijk naar de page properties natuurlijk)

Internet Explorer stuurt niet de juiste Accept header, en krijgt dus text/html. Dat mag gewoon. Liever niet, maar je browser vraagt erom.

[Dennis]

Verwijderd schreef op zondag 10 april 2005 @ 22:47:
Stuur eens een HTTP request naar www.w3.org met in de Accept header de content-type application/xhtml+xml en kijk naar het resultaat. Juist. Keurig in application/xhtml+xml met utf-8 charset.
(of gebruik gewoon even Firefox en kijk naar de page properties natuurlijk)

Internet Explorer stuurt niet de juiste Accept header, en krijgt dus text/html. Dat mag gewoon. Liever niet, maar je browser vraagt erom.

Overigens is de meta-header dan alsnog text/html.

[crisp]

HTTP-headers gaan altijd boven meta-headers...

[ Voor 11% gewijzigd door crisp op 10-04-2005 23:26 ]

[Dennis]

crisp schreef op zondag 10 april 2005 @ 23:26:
HTTP-headers gaan altijd boven meta-headers...

Dat geloof ik meteen. Ik vind wel dat het vreemd staat .

[We Are Borg]

Verwijderd schreef op zondag 10 april 2005 @ 22:47:
Stuur eens een HTTP request naar www.w3.org met in de Accept header de content-type application/xhtml+xml en kijk naar het resultaat. Juist. Keurig in application/xhtml+xml met utf-8 charset.
(of gebruik gewoon even Firefox en kijk naar de page properties natuurlijk)

Internet Explorer stuurt niet de juiste Accept header, en krijgt dus text/html. Dat mag gewoon. Liever niet, maar je browser vraagt erom.

Hmm, het verschil tussen de validator en de main site was me nog niet opgevallen

[Verwijderd]

HTTP-headers gaan altijd boven meta-headers...

En van HTTP-EQUIV 'content-type' onzin wordt alleen de 'charset' parameter gebruikt in een text/html omgeving.

[JayVee]

Verwijderd schreef op zondag 10 april 2005 @ 22:47:
Stuur eens een HTTP request naar www.w3.org met in de Accept header de content-type application/xhtml+xml en kijk naar het resultaat. Juist. Keurig in application/xhtml+xml met utf-8 charset.
(of gebruik gewoon even Firefox en kijk naar de page properties natuurlijk)

Ik gebruik uiteraard FireFox. Ik zie net dat www.w3.org inderdaad netjes application/xhtml+xml verstuurt. Maar validator.w3.org (zoals in de startpost vermeldt) niet:

code:

Response Headers - http://validator.w3.org/

Date: Mon, 11 Apr 2005 08:04:11 GMT
Server: Apache/1.3.27 (Unix)
Last-Modified: Wed, 09 Feb 2005 21:38:49 GMT
Keep-Alive: timeout=4, max=10
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8