HTML of XHTML voor de herintredende hobbyist

[crisp]

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

[Fuzzillogic]

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?

[crisp]

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?

[ Voor 5% gewijzigd door crisp op 13-04-2010 23:19 ]

[Patriot]

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!

[Barleone]

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.

[Wolfboy]

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.

[curry684]

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

Onze "data" is dikwijls XHTML.

Dat zou ik niet te vaak publiek gaan roepen

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).

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?

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.

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.

[ Voor 5% gewijzigd door curry684 op 14-04-2010 04:44 ]

[Wolfboy]

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

[Fuzzillogic]

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

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.

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?

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.

[ Voor 10% gewijzigd door Fuzzillogic op 14-04-2010 10:26 ]

[Sebazzz]

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.

[crisp]

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.

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

Nope, dat is niet verplicht

[Anoniem: 175386]

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.

[Fuzzillogic]

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.

[Bosmonster]

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.

[ Voor 12% gewijzigd door Bosmonster op 14-04-2010 19:14 ]

[crisp]

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.

[Wolfboy]

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

[crisp]

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

[Wolfboy]

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.

[Fuzzillogic]

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)

[HarmoniousVibe]

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)?

[Sebazzz]

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.

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.

[ Voor 7% gewijzigd door Sebazzz op 25-05-2010 07:35 ]

[Bosmonster]

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.

[HarmoniousVibe]

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.

[ Voor 19% gewijzigd door HarmoniousVibe op 25-05-2010 09:46 ]

[Bosmonster]

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.

[ Voor 25% gewijzigd door Bosmonster op 25-05-2010 09:43 ]

[apokalypse]

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?

[crisp]

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?

Of kan dat wel in HTML5?

nee

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

1 woord: backwardscompatibility

[.oisyn]

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.

[ Voor 10% gewijzigd door .oisyn op 27-05-2010 00:54 ]

[crisp]

.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

[apokalypse]

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.

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.

[ Voor 14% gewijzigd door apokalypse op 27-05-2010 12:55 ]

[Bosmonster]

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.

[crisp]

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:

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>.

[apokalypse]

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

[Bosmonster]

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

[ Voor 35% gewijzigd door Bosmonster op 27-05-2010 13:57 ]

[Fuzzillogic]

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.

[Gomez12]

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

[Sebazzz]

@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.

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.

[Bosmonster]

HTML of XHTML, dit is gewoon een prutsfout idd.

[crisp]

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...Nty=1&Ntk=ART&CC=&Ntt=%00

[ Voor 24% gewijzigd door crisp op 08-06-2010 09:45 ]

[Niemand_Anders]

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.

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..

[mithras]

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.

[.oisyn]

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.

[Bosmonster]

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

[ Voor 10% gewijzigd door Bosmonster op 08-06-2010 13:57 ]

[.oisyn]

Wikipedia: Backward compatibility

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

[ Voor 69% gewijzigd door .oisyn op 08-06-2010 14:06 ]

[Bosmonster]

.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

[Caelorum]

Gomez12 schreef op dinsdag 08 juni 2010 @ 01:44:
[...]
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.

Kan je dat niet oplossen met wat CData'tjes hier en daar?

[Sebazzz]

Caelorum schreef op dinsdag 08 juni 2010 @ 16:22:
[...]

Kan je dat niet oplossen met wat CData'tjes hier en daar?

Ik geloof het wel ja, dan hoef je <>&" en ' ook niet te escapen: Wikipedia: CDATA

[ Voor 11% gewijzigd door Sebazzz op 08-06-2010 16:40 ]

[curry684]

Caelorum schreef op dinsdag 08 juni 2010 @ 16:22:
[...]

Kan je dat niet oplossen met wat CData'tjes hier en daar?

Alleen al de manier waarop je het formuleert zegt eigenlijk genoeg over waarom je niet tegen dit soort dingen aan wil lopen. "Wat dingetjes hier en daar toevoegen" vloekt lichtelijk met een overdreven systematisch zeikerig systeem.

[.oisyn]

Sebazzz schreef op dinsdag 08 juni 2010 @ 16:40:
[...]

Ik geloof het wel ja, dan hoef je <>&" en ' ook niet te escapen: Wikipedia: CDATA

Totdat je per ongeluk een "]]>" in je data hebt staan.

[Sebazzz]

.oisyn schreef op dinsdag 08 juni 2010 @ 17:04:
[...]


Totdat je per ongeluk een "]]>" in je data hebt staan.

Klopt, het beste is dan ook om te escapen.

[Fuzzillogic]

curry684 schreef op dinsdag 08 juni 2010 @ 16:46:
[...]

Alleen al de manier waarop je het formuleert zegt eigenlijk genoeg over waarom je niet tegen dit soort dingen aan wil lopen. "Wat dingetjes hier en daar toevoegen" vloekt lichtelijk met een overdreven systematisch zeikerig systeem.

Niks overdreven. XML is juist bijzonder clean als je het mij vraagt. Heerlijk in duidelijkheid en eenvoud. Ik vind het dan ook zeer dubieus als een ICT'er gaat klagen als een systeem niet voldoende "vergevingsgezind" is...

[mcdronkz]

Loont het nou nog om je te verdiepen in alle ins en outs van XHTML, terwijl HTML5 op dit moment de toekomst lijkt te hebben?

[mcDavid]

mcdronkz schreef op woensdag 09 juni 2010 @ 21:43:
Loont het nou nog om je te verdiepen in alle ins en outs van XHTML, terwijl HTML5 op dit moment de toekomst lijkt te hebben?

XHTML5 valt ook onder die noemer. Dus wat dat betreft ja. Alleen heeft XHTML niet meer mogelijkheden ofzo boven HTML, en ziet het er ook niet naar uit dat dat nog gaat komen. Dus als je de HTML-syntax gewend bent, gewoon lekker daarbij blijven.

[Fuzzillogic]

mcdronkz schreef op woensdag 09 juni 2010 @ 21:43:
Loont het nou nog om je te verdiepen in alle ins en outs van XHTML, terwijl HTML5 op dit moment de toekomst lijkt te hebben?

Er valt weinig te verdiepen. XHTML1.0 is gewoon HTML4 in een XML-jasje. Net zo is XHTML5 een XML-versie van HTML5. Alle browsers die HTML5 ondersteunen snappen ook XHTML5. Mijn gok is dat XHTML5 sneller is, simpelweg omdat het veel eenvoudiger te parsen is dan HTML. Of je daar als gebruiker iets van merkt betwijfel ik.

Wij gebruiken XSLT voor onze templating. De keuze voor XHTML(5) is daarmee eigenlijk een no-brainer. Deden ze dat bij Wehkamp ook maar, de site werkt nog steeds niet

[edit] De webmaster maar es gemaild. Althans, dat denk ik. Nog geen bounce terug, dus wie weet.

[edit2] Nou kijk aan: "Hartelijk dank voor uw e-mail. Dit is een automatisch verzonden ontvangstbevestiging."

[ Voor 12% gewijzigd door Fuzzillogic op 09-06-2010 23:00 ]

[Sebazzz]

Is het niet zo dat omdat XHTML5 XML is, het hele document binnen moet zijn voordat je kan beginnen met parsen?

[Anoniem: 26306]

Sebazzz schreef op woensdag 09 juni 2010 @ 22:51:
Is het niet zo dat omdat XHTML5 XML is, het hele document binnen moet zijn voordat je kan beginnen met parsen?

Nee, waarom? Hoe denk je dat SAX parsers werken?

[Sebazzz]

Gewoon ergens gehoord, van een XHTML tegenstander dan wel

[Anoniem: 26306]

Van iemand die er blijkbaar niets van begrijpt ja. Het is natuurlijk mogelijk om te beginnen met parsen zodra de eerste bytes binnen zijn.

Wat die figuur waarschijnlijk bedoelt is dat je pas weet of een document well-formed is als het helemaal binnen is. Dat wel ja, maar daar hoef je natuurlijk niet op te wachten. Als een document well-formed is zal de parser namelijk nergens over struikelen.

[mcdronkz]

Fuzzillogic schreef op woensdag 09 juni 2010 @ 22:48:
[...]

Er valt weinig te verdiepen. XHTML1.0 is gewoon HTML4 in een XML-jasje. Net zo is XHTML5 een XML-versie van HTML5. Alle browsers die HTML5 ondersteunen snappen ook XHTML5. Mijn gok is dat XHTML5 sneller is, simpelweg omdat het veel eenvoudiger te parsen is dan HTML. Of je daar als gebruiker iets van merkt betwijfel ik.

Als ik naar de verschillen kijk, lijkt het me wel iets om in detail naar te kijken.

Ik ben nu bezig met dit boek (vrij beschikbaar), daar komt volgens mij XHTML5 niet aan de orde. Is het een goede volgorde om eerst dat boek eens door te werken, en daarna te kijken naar de meerwaarde van XHTML5?

[Fuzzillogic]

mcdronkz schreef op woensdag 09 juni 2010 @ 23:03:
[...]


Als ik naar de verschillen kijk, lijkt het me wel iets om in detail naar te kijken.

De verschillen slaan vooral op de syntax van XML/XHTML. Qua semantiek is eigenlijk geen verschil tussen HTML en XHTML.

Ik ben nu bezig met dit boek (vrij beschikbaar), daar komt volgens mij XHTML5 niet aan de orde. Is het een goede volgorde om eerst dat boek eens door te werken, en daarna te kijken naar de meerwaarde van XHTML5?

Ik zou me daar niet druk over maken. Persoonlijk vind ik XHTML gewoon cleaner en de logische keuze, maar praktisch gezien zijn de verschillen dermate klein dat het eigenlijk onboeiend is. Zolang je maar geen HTML gaat serveren terwijl je claimt dat het XHTML is, is er weinig aan de hand. Als je nu begint bent met HTML(5) dan lijkt het me onwaarschijnlijk dat je binnenkort al problemen krijgt dat je code opeens XHTML MOET zijn. Tegen de tijd dat dat wel een zaak is zul je zien dat het een fluitje van een cent is.

Het geblaat in dit topic is vooral van principiële aard

[mcDavid]

Fuzzillogic schreef op woensdag 09 juni 2010 @ 22:48:
[...]

Er valt weinig te verdiepen. XHTML1.0 is gewoon HTML4 in een XML-jasje. Net zo is XHTML5 een XML-versie van HTML5. Alle browsers die HTML5 ondersteunen snappen ook XHTML5. Mijn gok is dat XHTML5 sneller is, simpelweg omdat het veel eenvoudiger te parsen is dan HTML. Of je daar als gebruiker iets van merkt betwijfel ik.

Die potentie heeft het inderdaad, maar zolang je het als "text/html" verstuurt, wordt het gewoon als HTML gerenderd. En zolang IE bestaat, kun je het niet als "application/xml" versturen.

Enige voordeel is dan nog de striktere syntax, die misschien wat snelheidswinst oplevert omdat er minder foutcorrectie hoeft plaats te vinden. Maar niemand weerhoudt je ervan om je HTML-tags ook gewoon netjes af te sluiten.

[Bosmonster]

Fuzzillogic schreef op woensdag 09 juni 2010 @ 23:21:
[...]
Zolang je maar geen HTML gaat serveren terwijl je claimt dat het XHTML is, is er weinig aan de hand.

En toch doe je dit standaard voor 60% van de browsers vandaag de dag.

Het geblaat in dit topic is vooral van principiële aard

Dan heb je veel van de argumenten niet begrepen. De keuze van HTML(5) is voor de meeste hier geen principiele keuze, maar een praktische.

[Fuzzillogic]

mcDavid schreef op donderdag 10 juni 2010 @ 01:11:
[...]

Maar niemand weerhoudt je ervan om je HTML-tags ook gewoon netjes af te sluiten.

Jawel. De HTML specs. Lang niet elke tag mag je afsluiten.

Bosmonster schreef op donderdag 10 juni 2010 @ 08:40:
[...]
En toch doe je dit standaard voor 60% van de browsers vandaag de dag.

Sja dat krijg je ervan als je "tolerant" bent voor fouten. Dan gaan veel mensen er automatisch een puinhoop van maken, al dan niet bewust.

Dan heb je veel van de argumenten niet begrepen. De keuze van HTML(5) is voor de meeste hier geen principiele keuze, maar een praktische.

Ik heb het heel goed begrepen. Ik zeg toch ook dat het vooral geneuzel in de marge is en dat je vooral moet doen wat je het handigst vindt. Ik geef enkel wat argumenten waarom ik vind dat XHTML beter is.

[Bosmonster]

Fuzzillogic schreef op donderdag 10 juni 2010 @ 08:56:
[...]

Sja dat krijg je ervan als je "tolerant" bent voor fouten. Dan gaan veel mensen er automatisch een puinhoop van maken, al dan niet bewust.

We hebben het over XHTML. Jij zegt dat je dat goed moet doen, terwijl je dat vandaag de dag simpelweg niet KAN. Je bent dus zelf degene die tolerant bent/moet zijn voor fouten, aangezien je XHTML door het merendeel van de browsers fout geinterpreteerd wordt.

Derhalve snap ik niet wat je met bovenstaande bedoelt.

Ik heb het heel goed begrepen. Ik zeg toch ook dat het vooral geneuzel in de marge is en dat je vooral moet doen wat je het handigst vindt. Ik geef enkel wat argumenten waarom ik vind dat XHTML beter is.

Als je zegt dat het principieel is en geneuzel in de marge heb je het nog steeds niet begrepen. Goed onderbouwde praktische bezwaren zijn niet principieel en zijn geen geneuzel in de marge. Wat wel geneuzel in de marge is, is het argument over het afsluiten van tags en "netheid".

Ik heb het gevoel dat je de echte argumenten een beetje naast je neerlegt en blijft hameren op je eigen argumenten. En die komen, voor wat ik gezien heb, nog niet verder dan "dat jij dat netter vindt".

[ Voor 8% gewijzigd door Bosmonster op 10-06-2010 10:20 ]

[Fuzzillogic]

Bosmonster schreef op donderdag 10 juni 2010 @ 10:17:
[...]


We hebben het over XHTML. Jij zegt dat je dat goed moet doen, terwijl je dat vandaag de dag simpelweg niet KAN. Je bent dus zelf degene die tolerant bent/moet zijn voor fouten, aangezien je XHTML door het merendeel van de browsers fout geinterpreteerd wordt.

Derhalve snap ik niet wat je met bovenstaande bedoelt.

Merendeel? Alleen IE slaat de plank mis. Als een browser in zijn headers expliciet aangeeft application/xhtml+xml te ondersteunen, dan werkt dat ook prima, maar dan moet je wel tenminste well-formed code aanleveren.

Als je zegt dat het principieel is en geneuzel in de marge heb je het nog steeds niet begrepen.

Potato/potato. Dat is net zo'n principieel geneuzel in de marge.

Ik heb het gevoel dat je de echte argumenten een beetje naast je neerlegt.

Ja, precies, omdat ik die "echte" argumenten zwak vind. Ze zijn vaak gestoeld op het gedrag van archaïsche browsers als IE. Maar zelfs dan is XHTML prima bruikbaar, mits je rekening houdt met wat quirks. Firefox die over de zeik gaat met <iframe />, zoals ik net merk. Triest dat je er tegenwoordig nog rekening mee moet houden, maar het resultaat blijft valid XHTML. Dat heeft echt zo zijn voordelen; XPath en XSLT zijn mooie hulpmiddelen, die wel XML vereisen.

[Bosmonster]

Fuzzillogic schreef op donderdag 10 juni 2010 @ 10:49:
[...]
Merendeel? Alleen IE slaat de plank mis.

IE blijft nog steeds het merendeel.

Potato/potato. Dat is net zo'n principieel geneuzel in de marge.

Als jij praktische argumenten en bezwaren geneuzel vindt, dan valt daar verder weinig over te discussieren idd.

Ja, precies, omdat ik die "echte" argumenten zwak vind. Ze zijn vaak gestoeld op het gedrag van archaïsche browsers als IE. Maar zelfs dan is XHTML prima bruikbaar, mits je rekening houdt met wat quirks. Firefox die over de zeik gaat met <iframe />, zoals ik net merk.

Als jij dit soort problemen geen bezwaar vindt is dat ook prima. Aan het topic te zien ben jij echter een van de weinigen

[mcdronkz]

Ik heb me een beetje ingelezen, en volgens mij is het voordeel van XHTML zeer beperkt. XHTML 1.0 mag je met het MIME-type 'text/html' over het net versturen. Zo biedt XHTML 1.0 - correct me if I'm wrong - werkelijk geen voordeel, omdat dan nog steeds niets duidelijk is over de well-formedness van het document. Je kunt dan nog steeds aankloten, en de browser het lekker laten uitzoeken. XHTML 1.1 mag je alleen als 'application/xhtml+xml' over het web sturen, maar dan sluit je het meerendeel van de browsers uit, simpelweg geen optie.

Wat is dan een overtuigende reden om tóch XHTML te serveren?

edit: Ja, je kunt natuurlijk m.b.v. content negotiation bepalen wat je aan een browser serveert, maar ik kan me niet voorstellen dat de voordelen daarvan tegen de nadelen opwegen.

[ Voor 14% gewijzigd door mcdronkz op 10-06-2010 12:53 ]

[NMe]

Fuzzillogic schreef op donderdag 10 juni 2010 @ 10:49:
[...]

Merendeel? Alleen IE slaat de plank mis. Als een browser in zijn headers expliciet aangeeft application/xhtml+xml te ondersteunen, dan werkt dat ook prima, maar dan moet je wel tenminste well-formed code aanleveren.

Heb jij al eens een klant verteld dat je je website niet in IE kan laten werken omdat je dan XHTML niet goed toe kan passen? Als webdeveloper heb je de plicht om je sites zo goed mogelijk te laten werken in zoveel mogelijk mainstream browsers. Met goed geserveerde XHTML is dat vrijwel onmogelijk. Makkelijke keuze dan.

[Fuzzillogic]

Allemachtig. Is enige ideologie bij ICT'ers dan zo ver te zoeken? Kijkt er niemand verder dan vandaag? Natuurlijk zorgen we ervoor dat onze sites nu in IE werken, en ja dan gaat de well-formed-maar-brakker-renderer-patched XHTML dus "gewoon" als text/html de deur uit. Duh.

Met de komst van de HTML5-compatible browsers zal het (mag ik hopen) geen probleem meer zijn om gewoon XHTML5 te versturen, met een XML-content type. Technisch en ideologisch gezien vind ik XML gewoon een stuk fijner. En tegen de tijd dat de browsers er eindelijk ook eens klaar voor zijn hebben wij alles al klaar om pure, nette XHTML te serveren.

Dus ja, XHTML is beter/flexibeler, nee hard-core XHTML is nu nog geen optie, maar je kunt je er al op voorbereiden (XHTML genereren die ook door HTML-parsers gesnapt wordt) ook al heeft het *nu* weinig voordelen boven HTML.

[NMe]

Het heeft géén voordelen boven HTML. Als het ooit een keer goed door browsers ondersteund wordt, ja. Dan wel. Nu niet. We developen nu, niet morgen.

HTML5 is nog niet af maar wordt wel goed ondersteund, en zelfs in IE8 kun je het gebruiken. IE9 wordt zelfs een HTML5-voorvechter. XHTML is het ondergeschoven kindje en zal dat ook blijven.

Verder kun je je HTML5 ook gewoon well-formed schrijven, da's echt niet iets waar XHTML een patent op heeft ofzo.

XHTML was een leuk idee, maar meteen ook een dat min of meer achterhaald is. Best hoor dat je het daar niet mee eens bent, maar ga dan niet anderen verwijten dat ze niet vooruit kijken. HTML5 is de toekomst, zeker nu Apple, Microsoft én Google het zo omarmen.

[Bosmonster]

Fuzzillogic schreef op donderdag 10 juni 2010 @ 14:41:
Kijkt er niemand verder dan vandaag?

Dat is apart dat je dat zegt, aangezien het juist de XHTML-ontwikkeling is die is stopgezet. Het is een gepasseerd station.

Het was even een hype onder ontwikkelaars toen XML helemaal de bom was en alles dat begon met een X automatisch goed was.

Dus ja.. ik kijk verder dan vandaag en gisteren. En dat is een van de redenen dat ik liever geen XHTML gebruik, maar mijn voorkeur uitgaat naar de standaard van morgen: HTML5.

[ Voor 70% gewijzigd door Bosmonster op 10-06-2010 15:08 ]

[mcdronkz]

W3C lijkt trouwens zelf het verkeerde voorbeeld te geven. Wanneer ik deze pagina open, wordt 'ie als 'text/html' gestuurd, terwijl de HTML-code me weet te vertellen dat het volgens de XHTML 1.1 standaard geschreven zou moeten zijn. Of zie ik iets over het hoofd?

[Sebazzz]

Het zijn statische pagina's, en de server gaat niet kijken of het doctype XHTML is. En anders vallen IE gebruikers ook buiten de boot, die kunnen de specificatie dan niet bekijken.

Ahhh

[Gomez12]

Fuzzillogic schreef op donderdag 10 juni 2010 @ 14:41:
Allemachtig. Is enige ideologie bij ICT'ers dan zo ver te zoeken? Kijkt er niemand verder dan vandaag?

Grappig, ik zat me net af te vragen of jij wel enig realistisch besef had... Of dat het enkel maar theoretisch geneuzel was. ( niet bedoeld als flame, lees de rest van de post )

Natuurlijk zorgen we ervoor dat onze sites nu in IE werken, en ja dan gaat de well-formed-maar-brakker-renderer-patched XHTML dus "gewoon" als text/html de deur uit. Duh.

Dus feitelijk presenteer je geen html en ook geen xhtml aan IE?
Je produceert gewoon een tag-soup en hoopt dat IE er wijs uit kan worden, dat is zo ongeveer het grootste probleem met xhtml. Of je zou momenteel 2 ontwikkeltrajecten hebben ( html voor IE en xhtml voor de rest ) of je presenteert enkel maar een tag-soup.

En tegen de tijd dat de browsers er eindelijk ook eens klaar voor zijn hebben wij alles al klaar om pure, nette XHTML te serveren.

En tot die tijd serveer je gewoon een allegaartje aan het grootste gedeelte van de webusers...
Je bent misschien klaar voor de toekomst, maar nu produceer je "rommel" volgens geen enkele standaard.

Dus ja, XHTML is beter/flexibeler, nee hard-core XHTML is nu nog geen optie, maar je kunt je er al op voorbereiden (XHTML genereren die ook door HTML-parsers gesnapt wordt) ook al heeft het *nu* weinig voordelen boven HTML.

Tja, als ICT'er ben ik dan iets rechtlijniger, of ik produceer html of ik produceer xhtml.

Zolang IE geen xhtml accepteert vind ik het een mooi ideaal maar praktisch niet uitvoerbaar. Als IE het al zou gaan accepteren dan komen er weer additionele problemen om de hoek kijken ( zoals copy/paste fixes etc ).
Oftewel, ik snap je theoretische punt maar praktisch vind ik het niet.

[Fuzzillogic]

Uit mijn templates komt valid XHTML rollen, zoals ik al zei. Die XHTML is wel zodanig dat HTML-parsers van IE e.d. er geen probleem van maakt. En we serveren het als text/html, om geen gezeik te krijgen van dat stuk antiek. Werkt prima, "dankzij" de tolerantie van de browsers.

Mijn voorkeur zou echter gaan naar valid XHTML1.1 voor nu, en op termijn XHTML5. XHTML1.1 is een no-go helaas, maar XHTML5 zal toch echt wel ondersteund worden, mag ik hopen.

Dat is toch niet zo moeilijk te begrijpen?!

[ Voor 4% gewijzigd door Fuzzillogic op 10-06-2010 21:22 ]

[Bosmonster]

Fuzzillogic schreef op donderdag 10 juni 2010 @ 21:19:


Dat is toch niet zo moeilijk te begrijpen?!

Het is toch ook niet moeilijk te begrijpen dat mensen het niks vinden?

Feit is dat die X niks toevoegt als je geen XSLT gebruikt. Jij vind die combinatie blijkbaar prettig werken en dat is prima, maar accepteer dan ook dat het merendeel van de developers die combinatie niet prettig vindt.

[ Voor 32% gewijzigd door Bosmonster op 10-06-2010 21:40 ]

[NMe]

Fuzzillogic schreef op donderdag 10 juni 2010 @ 21:19:
Uit mijn templates komt valid XHTML rollen, zoals ik al zei. Die XHTML is wel zodanig dat HTML-parsers van IE e.d. er geen probleem van maakt. En we serveren het als text/html, om geen gezeik te krijgen van dat stuk antiek. Werkt prima, "dankzij" de tolerantie van de browsers.

En stiekem lever je dan spul dat volgens geen enkele standaard correct is. Netjes.

[mcdronkz]

NMe schreef op donderdag 10 juni 2010 @ 22:16:
[...]

En stiekem lever je dan spul dat volgens geen enkele standaard correct is. Netjes.

Niet dat je er iets mee opschiet, maar omdat XHTML 1.0 een soort van overgangsstandaard is, mag je het volgens de standaard gewoon als text/html aanbieden. Als je de code zelf dan ook nog eens volgens de standaard schrijft, doe je volgens mij niets 'verkeerd'. IE6/7/8 en de rest van de browsers zouden dat moeten begrijpen.

[NMe]

mcdronkz schreef op donderdag 10 juni 2010 @ 23:08:
[...]

Niet dat je er iets mee opschiet, maar omdat XHTML 1.0 een soort van overgangsstandaard is, mag je het volgens de standaard gewoon als text/html aanbieden. Als je de code zelf dan ook nog eens volgens de standaard schrijft, doe je volgens mij niets 'verkeerd'. IE6/7/8 en de rest van de browsers zouden dat moeten begrijpen.

Ze begrijpen het, maar dat komt omdat ze spul dat ze niet begrijpen gewoon overslaan. Je doet er alle voordelen van XHTML een beetje mee teniet als je het niet ook als XHTML serveert, en dat kán gewoon niet als je IE niet achter wil stellen. Kiezen voor HTML5 en zelfs voor HTML4 boven XHTML is dus vrij makkelijk.

[mcDavid]

Uiteindelijk komt het maar op één ding neer in deze discussie: namelijk welke syntax je zelf het makkelijkst vindt om te typen. Voor de rest werkt het allebei even goed en kun je er het zelfde mee.

Dat gedoe over standaarden en correctheid is eigenlijk ook overrated. Uiteindelijk gaat het erom dat je site er in iedere browser goed uit ziet, en naleven van standaarden is een middel om dat te bereiken, geen doel opzich.

[Nutral]

Als je geen XHTML met application/xml en dus ook de xpath en andere xhtml speciale features gebruikt dan heeft het toch totaal geen nut om XHTML te gebruiken ?

In plaats van het leuke Xje ervoor kun je gewoon HTML4 strict pakken en er klaar mee zijn. Dat W3C validator zegt dat de xhtml valid is betekent niet dat je het daarom perfect voor het goede doel gebruikt.

[BtM909]

Fuzzillogic schreef op donderdag 10 juni 2010 @ 21:19:
Uit mijn templates komt valid XHTML rollen, zoals ik al zei. Die XHTML is wel zodanig dat HTML-parsers van IE e.d. er geen probleem van maakt. En we serveren het als text/html, om geen gezeik te krijgen van dat stuk antiek. Werkt prima, "dankzij" de tolerantie van de browsers.

Mijn voorkeur zou echter gaan naar valid XHTML1.1 voor nu, en op termijn XHTML5. XHTML1.1 is een no-go helaas, maar XHTML5 zal toch echt wel ondersteund worden, mag ik hopen.

Dat is toch niet zo moeilijk te begrijpen?!

Ik wil niet nog iemand zijn die dingen op je afvuurt, maar leg eens uit wat voor jou de voordelen van XHTML zijn

[Ram0n]

Daar ben ik ook benieuwd naar, want volgens mij werk je dan meer vanuit een ideologie dan vanuit een praktisch standpunt. XHTML is in theorie leuk, maar (zoals al vaker hier helderder uitgelegd dan ik zou kunnen) in de praktijk gewoon te problematisch.

[Hiroj]

Ik heb slechts de eerste pagina gelezen.
Maar ik zou TS aanraden om gewoon voor HTML4 te gaan. Het verschilt weinig van XHTML en net zo makkelijk aan te leren.

En inderdaad, zoals vele al hebben gezegd. Focus je voornamelijk op CSS.
CSS is erg belangrijk (ook in de toekomst) voor het opmaken van je website. CSS is bovendien ook erg makkelijk te leren.

[Bosmonster]

BtM909 schreef op vrijdag 11 juni 2010 @ 14:11:
[...]

Ik wil niet nog iemand zijn die dingen op je afvuurt, maar leg eens uit wat voor jou de voordelen van XHTML zijn

Volgens mij is deze zelfde vraag (en discussie) inmiddels al heel wat keer op en neer gegaan in dit topic.

[Anoniem: 147126]

mcDavid schreef op vrijdag 11 juni 2010 @ 00:27:
Uiteindelijk komt het maar op één ding neer in deze discussie: namelijk welke syntax je zelf het makkelijkst vindt om te typen. Voor de rest werkt het allebei even goed en kun je er het zelfde mee.

Een van de 'features' van XHTML boven HTML is in-line SVG/mathml. Straks met HTML5 is het ook
mogelijk maar voor nu heb je daar XHTML voor nodig. (testcase: www.cdejonge.com/stip.xhtml).

[Nutral]

Probleem is alleen dat je er pratisch niet superveel aan hebt. Er zijn erg veel mensen die bewust XHTML gebruiken omdat ze denken dat de beste taal is terwijl het in de meeste gevallen net zo goed HTML 4.0 had kunnen zijn.

[BtM909]

Bosmonster schreef op vrijdag 11 juni 2010 @ 14:43:
[...]


Volgens mij is deze zelfde vraag (en discussie) inmiddels al heel wat keer op en neer gegaan in dit topic.

Klopt, maar dat was vrij algemeen... Sure er zijn toepassingen waar je eerst niet onder XHTML uitkwam, maar ik wilde weten of Fuzzillogic nu al gebruik maakte van specifieke XHTML modules.

[Fuzzillogic]

BtM909 schreef op maandag 14 juni 2010 @ 16:44:
[...]

maar ik wilde weten of Fuzzillogic nu al gebruik maakte van specifieke XHTML modules.

Wegens de huidige batch aan brakke browsers die gewoon slecht met well-formed XML om kunnen gaan heb je er client-side inderdaad erg weinig aan. Zolang browsers te stupide zijn om met iets basics als namespaces om te gaan wordt het nut van XML ernstig ondermijnd.

[Bosmonster]

Maar toch wil je het perse blijven gebruiken? Je moet toch werken met de middelen die je hebt, en momenteel zijn er betere middelen.

[crisp]

Fuzzillogic schreef op maandag 14 juni 2010 @ 19:16:
[...]

Wegens de huidige batch aan brakke browsers die gewoon slecht met well-formed XML om kunnen gaan heb je er client-side inderdaad erg weinig aan. Zolang browsers te stupide zijn om met iets basics als namespaces om te gaan wordt het nut van XML ernstig ondermijnd.

Namespaces in XML zijn ook gewoon een verschrikking (en ook een punt waar X(HT)ML-parsers weer complexer zijn dan HTML-parsers ) en zeker in een markup-taal wil je je daar liever niet mee bezig hoeven houden

[ Voor 7% gewijzigd door crisp op 15-06-2010 00:07 ]

[johnkeates]

Ik gebruik XHTML 1.0 Strict om het het, zoals het zegt, strict is. Ik hou van strict, geen gekloot met grijze gebieden over wat wel 'mag' en wat 'niet mag', geen gezeur met tags die misschien wel maar misschien ook niet bruikbaar blijven, maar gewoon goede code of slechte code. Met HTML4 heb je het probleem dat je zelf mag uitzoeken of je upper case, lower case, shorttag, valid SGML wil gebruiken. Als je het niet doet krijg je een of ander raar resultaat, verschillend per browser, en als je het wel doet ook. Moet je weer browser-specifics gaan hacken, schiet je ook niks mee op (het is 2010, geen 1980).

Als je XHTML neemt kan je dat lekker (mits well-formed) manipuleren met script/programmeertaal naar keuze en heb je geen gezeur met code die zich niet aan bekende regels houdt. De regels voor XHTML 1.0 zijn gewoon duidelijker dan voor HTML4, en daar ontkom je niet aan als je low-level moet bouwen voor een library die high-level gebruikt mag worden. Bekende regels kan je mee werken, onbekende niet.

Dan heb je nog het renderer probleem, maar dat heeft met browsers te maken en niets met talen op zich.

Als je met business-ogen naar programmeren kijkt zul je nooit iets te maken hebben met 'goede code' of 'kwaliteit', maar alleen maar bang for the buck. En laat dat nou precies het probleem zijn dat HTML4 renderers ons nu laten zien: allemaal hun eigen manier, en allemaal net-niet-helemaal goed.

Als iedereen de regels naleeft werkt het gewoon, doet iemand dat niet, dan valt die buiten de boot, behalve als die iets als geld, macht of positie heeft. Microsoft had dat ooit met IE, en is daarom alle bekende regels gaan mollen, heeft zelf hier en daar closed-platform 'hacks' bedacht (ActiveX anyone?) en nu zitten we met de gebakken peren.

Als je een 'developer' bent die alleen maar geld wil verdienen: neem jQuery, plak het met HTML4 en CSS1 vast in Dreamweaver en lever je spul op. Klant tevreden, jij een zak met geld.

Als je een *Developer* bent die ook echt dingen ontwikkelt, dan denk je meer in open termen, standaarden en regels die je deelt om samen met andere mensen een geheel te maken zonder daar zelf perse wat mee te moeten verdienen. Misschien dat je uiteindelijk zo veel kennis hebt van die termen, standaarden, regels en richtlijnen dat je daardoor sneller en efficienter kan werken, en dat je daar door meer geld kan verdienen door taken uit te voren met een hogere snelheid dan anderen en daarmee meer werk verzetten in dezelfde tijd waardoor er meer te verdienen is, is alleen maar mooi meegenomen.


typo's e.d. niet gecheckt, fanboy disclaimer: geen OSS evangelist en geen closed source hater, geen anti-massa en geen anti-watdanook. wel pro open web standaarden die nageleefd worden

[Bosmonster]

Leuk dat je ook even komt kijken, maar lees het topic even door, want 80% van je post (en dat is een milde schatting) is onzin.

edit: ik pas, na nog een keer lezen, mijn milde schatting even aan naar 100%. Geen woord van wat je zegt is waar of heeft enige onderbouwing.

[ Voor 50% gewijzigd door Bosmonster op 15-06-2010 00:46 ]

[Spinal]

met Bosmonster.

johnkeates schreef op dinsdag 15 juni 2010 @ 00:31:
Ik gebruik XHTML 1.0 Strict om het het, zoals het zegt, strict is. Ik hou van strict, geen gekloot met grijze gebieden over wat wel 'mag' en wat 'niet mag', geen gezeur met tags die misschien wel maar misschien ook niet bruikbaar blijven, maar gewoon goede code of slechte code. Met HTML4 heb je het probleem dat je zelf mag uitzoeken of je upper case, lower case, shorttag, valid SGML wil gebruiken. Als je het niet doet krijg je een of ander raar resultaat, verschillend per browser, en als je het wel doet ook. Moet je weer browser-specifics gaan hacken, schiet je ook niks mee op (het is 2010, geen 1980).

Huh? Noem mij één browser die een verschil maakt tussen bijv. <p> en <P> of die onder HTML een probleem maakt van <br />

[Bosmonster]

Het grootste probleem is dat johnkeates blijkbar niet op de hoogte is van het feit dat ook html4 bestaat in een STRICT variant, of van het bestaan van html5.

[Anoniem: 147126]

HTML 5 'bestaat' nog niet. Tenminste niet in het wild. De grootste browsers ondersteunen het nog niet.

[Bosmonster]

Anoniem: 147126 schreef op dinsdag 15 juni 2010 @ 09:46:
HTML 5 'bestaat' nog niet. Tenminste niet in het wild. De grootste browsers ondersteunen het nog niet.

Na dit hele topic gaan vallen over het woordje "bestaat" wordt wel een beetje vervelend... Je weet best wat ik bedoel. De html5 doctype is backwards compatible. Html5-specifieke features gebruiken is uiteraard een heel ander verhaal vooralsnog en een vrije keuze afhankelijk van je wensen en eisen (bijvoorbeeld of je video op een iPhone of iPad wil laten werken, etc).

[ Voor 12% gewijzigd door Bosmonster op 15-06-2010 09:56 ]

[Hiroj]

Het heeft geen zin om constant in discussie te gaan over wat nou beter moet zijn.
Als TS het liefst "modern" wilt programmeren in HTML raad ik hem W3Schools.com aan.
Duidelijk, simpel en effectief.

Na afloop zul je zelf ook merken, het maakt geen bal uit hoe je werkt. Test je website gewoon in meerdere browsers in een test omgeving. En doe net als mij: lak hebben aan browsers die niet mee willen gaan in de tijd

[mcdronkz]

Oei, je hebt wel in de gaten hoe je jezelf moet diskwalificeren in een topic als dit .

[Gotech86]

Hiroj schreef op vrijdag 11 juni 2010 @ 14:40:
Ik heb slechts de eerste pagina gelezen.
Maar ik zou TS aanraden om gewoon voor HTML4 te gaan. Het verschilt weinig van XHTML en net zo makkelijk aan te leren.

En inderdaad, zoals vele al hebben gezegd. Focus je voornamelijk op CSS.
CSS is erg belangrijk (ook in de toekomst) voor het opmaken van je website. CSS is bovendien ook erg makkelijk te leren.

Dit topic is nu bijna 2 jaar oud, zou de TS niet al zijn keuze hebben gemaakt ?

[moozzuzz]

Gotech86 schreef op donderdag 17 juni 2010 @ 17:03:
Dit topic is nu bijna 2 jaar oud, zou de TS niet al zijn keuze hebben gemaakt ?

Het is altijd een goed excuus om nog es te drammen over XHTML neen? ;^)