W3C gaat HTML verder ontwikkelen naast XHTML

De directeur van het W3C, Sir Tim Berners-Lee, heeft op zijn weblog aangekondigd dat er een nieuwe werkgroep geïnstitueerd gaat worden die zich zal bezighouden met de ontwikkeling van een nieuwe HTML-specificatie. De afgelopen jaren, ongeveer sinds de vrijgave van versie 4.01 van de HTML-specificatie op kerstavond 1999, heeft de verantwoordelijke werkgroep niet veel meer uitgevoerd. De reden daarvoor was gelegen in het feit dat het W3C besloten had om zich voortaan te richten op XML-talen, waaronder een XML-versie van HTML: XHTML. Deze opvolger van HTML wordt tot op de dag van vandaag echter niet ondersteund door Internet Explorer, waardoor het - gezien het marktaandeel van die browser - niet interessant is om websites te ontwikkelen op basis van XHTML.

Ondanks dat XHTML door onder andere de browsers van Mozilla, Opera en Apple wel ondersteund wordt, betekent het ontbreken van support van Internet Explorer dat de ontwikkeling van webspecificaties zo goed als stilstond. Het W3C werd door sommige XHTML-tegenstanders dan ook verweten het contact met de realiteit in webdeveloperland te zijn kwijtgeraakt en te veel een ideale situatie na te streven. Onder meer dat zorgde er voor dat de Web Hypertext Application Technology Working Group in 2004 werd opgericht. In zijn korte bestaan heeft deze organisatie, die gesteund wordt door Mozilla, Opera en Apple, inmiddels drie drafts van specificaties opgesteld: Web Forms 2.0, Web Applications 1.0 en Web Controls 1.0.

Het W3C is nu echter tot inkeer gekomen: 'It is really important to have real developers on the ground involved with the development of HTML. It is also really important to have browser makers intimately involved and committed. And also all the other stakeholders, including users and user companies and makers of related products.' Volgens Berners-Lee is het, mede gezien het recente verleden, inderdaad beter om de HTML-specificaties en het gebruik van HTML in kleine stapjes te verbeteren, zodat men op termijn alsnog kan overgaan op XHTML. De nieuwe werkgroep zal zich onder meer bezighouden met het, op basis van Web Forms 2.0, verbeteren van de formulieren in HTML. Tegelijk met de nieuwe HTML-werkgroep zal de bestaande XHTML-werkgroep zijn werk blijven doen.

Reacties (75)

[mcdronkz]

Te belachelijk voor woorden dat er weinig kan worden ondernomen op het gebied van XHTML als IE het niet ondersteund.

[Skit3000]

En nu is het de vraag of Microsoft wel een nieuwere HTML specificatie gaat ondersteunen of dat ze gewoon bij 4.01 blijven

[crisp]

Laat ze eerst HTML4.01 maar eens fatsoenlijk ondersteunen want ook daar schort nog wel eea in IE

[SPee]

Precies.
Want als MS IE niet ontwikkelde (zoals het voorgaande jaren gedaan heeft), maakt het geen ene bal uit of er een nieuwe standaard komt van de HTML specificaties.
Dan kunnen ze beter met XHTML doorgaan (wat ze ook deden).

Jammer dat MS door de monopolie op de browsermarkt de vernieuwingen tegen heeft gewerkt. Nu er meer concurrentie is, gaat MS weer innovatief bezig zijn.

[oeLangOetan]

Er zijn voldoende methoden om XHTML in IE te laten werken. Volledige ondersteuning is er wel niet, idem voor Firefox 2 btw.

[Little Penguin]

Het is niet mogelijk om IE XHTML volgens de XHTML regel af te laten handelen, Fx daarentegen kent al sinds de pre-1.0 versies goede XHTML ondersteuning (die was namelijk al in Gecko aanwezig voor dat er uberhaupt over Mozilla 1.0 sprake was...)

Wel ff je feiten checken dus...

[oeLangOetan]

Niet volgens de regel idd, je moet via een omwegje je pagina als xml laten afhandelen en dan heb je een ondersteuning die idd minder is dan firefox maar zoals ik al zei is die ook niet compleet.

de reden waarom IE6 & 7 xhtml niet op de normale manier ondersteunen:
http://blogs.msdn.com/ie/archive/2005/09/15/467901.aspx

[Verwijderd]

het is te belachelijk voor woorden dat een organisatie als W3C er zo'n beetje 8 jaar voor nodig heeft om tot het besef te komen dat het beter is te overleggen met ontwikkelaars van browsers om gezamenlijk tot standaarden te komen, iets wat de oorspronkelijke doelstelling was van W3C en daarvoor is W3C zelfs opgericht

voor microsoft komt daar nog veel meer bij kijken, die standaarden zijn weer een risico voor het besturingssysteem, van de laatste lekken bij xp hadden er een hoop te maken met aanvallen door java

[AntiChris]

W3C ís een organisatie van web-technologie-bouwers. Ja, ook Microsoft zit in het consortium.

Er wordt vaak gedaan alsof W3C een extern groepje mensen is wat niks met de industrie te maken heeft, maar het ís de industrie zelf!

[RuddyMysterious]

Het is een beetje zoals games maken voor linux. Er zit gewoon amper toekomst in. Met toekomst bedoel ik rooskleurige boekjaren met telkens lekker veel winst. :x

[mcdronkz]

Zoals jij het nu brengt zou er dan niet meer aan Linux gewerkt kunnen worden omdat gamefabrikanten weigeren om games te maken voor het Linux platform. Die vlieger gaat natuurlijk niet op.

[Verwijderd]

devilsprophet stelt dat het voor game-developers niet interessant is om naar het linux-platform te kijken, das wel een heel snelle generalisatie om dan te stellen dat het hele linux-platform dan overbodig wordt...

[Goofy]

In verband met boekhouden wil je de kleur rood en varianten toch liefst mijden .

[Parasietje]

Zo voel ik het ook. "Wij hebben een mooie standaard ontwikkeld, iedereen ondersteunt hem behalve een grote monopolist. Oh, dan passen we ons ook wel even aan."

mietjes...

[humbug]

Niet alleen de monopolist ondersteund de standaard niet. Ook 80% van de potentiele klanten van de bedrijven die de mooie standaard zouden moeten gebruiken hebben geen enkele interesse in die standaarden. Gebruik van die standaarden is dus meestal niet echt zinvol

[Dersan]

En waarom weigert Microsoft dan om XHTML te ondersteunen? Getuigt wel dit dat W3C geen rug heeft en toch maar mee gaat met de wil van Microsoft. Begrijpelijk, dat wel, maartoch...

[Little Penguin]

Wees blij dat Microsoft XHTML niet ondersteunt.

Wat? Ja, dat meen ik dus echt. Hoewel XHTML een mooie standaard is en dus door alle browsers ondersteund zou moeten worden is het beter dat MS XHTML helemaal niet ondersteund dan dat men het slechts half ondersteund.

Één van de leden van het IE development team heeft aangegeven XHTTML of helemaal goed of helemaal niet te willen ondersteunden - gezien de beschikbare resources betekent dat dat IE vooralsnog helemaal geen XHTML ondersteund.

btw: Ik hoop overigens wel dat een toekomstige versie van IE XHTML wel volledige zal gaan ondersteunen.

[i-chat]

tja zo kun je het ook zien,
maar jammer dat 't natuurlijk grote BULLSHIT is, MS heeft namelijk genoeg recources, maar steeds die liever in het verneuken van alle standaarden, zodat alleen ms maar geld kan verdienen, - AJAX kan blijkbaar wel maar zelfs fatsoenlijke css2 is dan ineens ONmogelijk best vreemd, want IK vraag me dan af hoe je die AJAX shit vorm wilt geven...


dus zo geweldig is 't niet.
en ik vraag me net als degene boven mij, af waar deze lomperik z'n antwoorden vandaan heeft...

[Little Penguin]

...AJAX kan blijkbaar wel maar zelfs fatsoenlijke css2 is dan ineens ONmogelijk best vreemd,...

Ik ben bang dat je vergeet dat AJAX gebaseerd is op het door MS bedachte 'XMLHttpRequest', geen wonder dus dat MSIE AJAX ondersteuning heeft...

Overigens vind ik het belangrijker dat MS eerst goed de W3C DOM en CSS1,2 en evt. 3 ondersteunt - de ondersteuning van XHTML hoeft wat mij betreft pas te gebeuren na een goede implementatie van CSS en het W3C DOM model en JavaScript 2 (zoals die nu vorm begint te krijgen in Fx).

Overigens hoeft MSIE dit allemaal niet te ondersteunen hoor, als het marktaandel van dit ding dan maar afneemt tot minder dan 5%

[killercow]

Die developper heeft dat gezet op slashdot, in een reactie op 10 geselecteerde vragen.

En in plaats van gewoon te vertellen dat zijn management er een rommerltje van gemaakt heeft, en niet genoeg resources uittrekt om de belangrijkste app op veel computers weer op orde te krijgen, heeft hij werkelijk elke vraag lomp/defensief of ontwijkend beantwoord.

Bij de vraag of er wellicht een IE versie kon komen welke linux en mac developpers konden gebruiken kreeg men het antwoord dat ze geen windows licenties gingen weggeven. (wie heeft er om windows licenties gevraagt?)

[reddog33hummer]

Het team ziet IE als onderdeel van windows. Daarom het antwoord, we gaan geen windows licenties weggeven.

[merethan]

correct reddog

lees de licentie maar. IE is niet gratis. IE draaien op WinE moet je dus een windows licentie voor hebben!

Maarja de hele n00bwereld zegt dat het gratis is omdat het vrij downloadbaar is. mag ook wel als je 400 voor een OS neerteld. (of 150 voor je OEM)

[mr._Anderson]

Dat is een manier om de instelling van het W3C te bekijken. Echter kan je ook zien dat het W3C het beste van de situatie wil maken dat binnen hun huidige mogelijkheden ligt.

Microsoft heeft een heel groot marktaandeel op de browsermarkt en daardoor heeft het bijvoorbeeld ook niet veel nut om css2 (3) te gebruiken in huidige website's.
Transparante png's waren ook niet goed in te zetten zonder filters omdat IE dit niet native ondersteunde.

Het is vervelend dat door de ontwikkel koers van Microsoft nieuwe technieken die het ontwikkelen op internet soms heel fijn en efficient maken niet gebruikt kunnen worden.

Het W3C kan wel meer van dit soort nieuwe technieken blijven verzinnen, maar wanneer meer dan 70% van de bezoekers (gemiddelde gok) IE gebruikt kan je dit als gezond internet-bedrijf niet gaan inzetten.

Ik zie op mijn werk dat er soms veel moeite gedaan moet worden om website's goed compatible te houden op verschillende browsers ( IE, FF, Opera, Mac FF).
Nu IE 6 en 7 ook weer verschillen de wereld in brengen wordt het alleen maar lastiger.

Wanneer het W3C dus een realistische standaard gaat (tracht te) ontwerpen en daarnaast verder blijft gaan met XHTML lijkt het me alleen maar positief, want wellicht dat Microsft met IE8 weer een betere koers in slaat? (of dat Firefox en Opera het meerdendeel van de markt gaan overnemen ).

[CrashOne]

Het probleem is alleen niet verholpen als IE8 nu in eens XHTML zou ondersteunen. Je blijft nog jaren achter volgt worden door oude browsers die alleen oude technologieën ondersteunen. We zijn nu ook nog steeds bezig om sites geschikt te houden voor IE5.

Echter moet er wel eens een omslag punten komen, des te eerder IE xhtml (en het liefste ook CSS3) ondersteund des te eerder dit omslag punt is.

[dtech]

Inderdaad, je moet ergens beginnen

* dtech is trouwens gestopt met het perfect ondersteunen van IE5(.5), IE6 is voor elk windows besturingssysteem van mensen die de afgelopen 10 jaar niet op mars geleefd hebben beschikbaar, en anders heb je FF etc. Zorg er wel voor dat het leesbaar is en makkelijke foutjes worden er met een condiotional commentje uitgehaald, maar daar blijft het bij. (Tekst en spraakbrowsers ondersteun ik altijd wel)

[Verwijderd]

Maar dat is dan ook weer een probleem vind ik: oude browsers tot in het oneindige blijven ondersteunen. Hoe kan je nu vooruit gaan als je toch met één been achterblijft? Vroeg of laat scheurt je balzak toch...

[robertpNL]

Hmmm. IE geen XHTML ondersteuning? Is dat wel zo?

Als ik een web project open in Visual Studio 2005, dan begint de aangemaakte start pagina (Default.aspx) als volgt:

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

<html xmlns="http://www.w3.org/1999/xhtml" >

[user109731]

Lees ook even de reacties hierboven. Er word hier bedoeld XHTML verstuurd met het juiste mimetype (application/xhtml+xml). Het voorbeeld van jou heeft wel XHTML syntax, maar het word nog steeds geparst als (malformed) HTML omdat het als text/html verstuurd word. En daardoor mis je o.a. de errorhandling van XHTML/XML, waardoor je nog weinig merkt van het feit dat je XHTML gebruikt.

[Verwijderd]

Tweakers.NET gefeliciteerd met de 45k nieuwspost trouwens.

IE6 heeft geen probleem met XHTML 1.1 documenten, en rendert ze op exact dezelfde manier als Firefox/Safari/Opera. Helemaal geen hacks nodig. Het enige waar wel op moet worden gelet is 'standaard' waarden, die verschillen namelijk per browser en als je ze dus niet definiëert, dan krijg je dus talloze problemen.

Voor pixel-layouts, dan is de enigste 'hack' die ik nodig heb de min-height, waarbij ik dan de <!--[if IE6]> methode gebruik, om dan te voorkomen dat toekomstige IE versies in de problemen komen, volledig per specificatie, dus geen CSS hacks waarbij je dubbel definieert en gebruik maakt van het feit dat de éné browser het anders leest/negeert dan de andere.

Puur XML+XSL heeft IE6 ook geen probleem mee, en rendert een 2MB XML database een heel stuk sneller dan FireFox en Safari, alleen Opera kan het bijbenen.

En misschien is het fout dat IE6 een text/html definitie nodig heeft voor een XHTML/XML bestand tegen de definitie in, maar kom op zeg als dat het einde van de wereld was, dan hadden FireFox/Safari/Opera/etc niet mee moeten gaan en het ook op die manier ondersteunen.

stylesheet.xsl:
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fo="http://www.w3.org/1999/XSL/Format" />
<xsl:output method="html" />

index.xml:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<?xml-stylesheet type="text/xsl" href="stylesheet.xsl" ?>

werkt dus perfect in IE6, net zoals de andere moderne browsers waar wij mee testen.

@dtech, geen probleem, mijn schrijfstijl is niet altijd overzichtelijk. De vele jaren in Amerika wonen, beginnen te tonen. Dat is ook één van de redenen dat ik tweakers.net gebruik, om de moedertaal niet te verliezen.

@ID-College, mijn dank

[dtech]

edit:

Je post niet goed genoeg gelezen

[ID-College]

In dat geval is het rendert en het is tegenwoordig (al een tijd ) enige ipv enigste

[Milt]

Naar mijn ervaring vreet IE prima XHTML. Het mag dan misschien officieel niet ondersteund zijn, er is maar weinig uit de XHTML standaard wat IE niet snapt. Er zijn enkele exotische tags die IE niet kent maar niks schokkends volgens mij.

[user109731]

Dat is XHTML syntax, verstuurd als text/html. Dat ziet IE dus als malformed HTML...
Echte XHTML verstuur je met een application/xhtml+xml header, en dat ondersteund IE niet (je krijgt een download schermpje)...

XHTML word geparst als XML: veel strengere errorhandling dus, maar niet als je het als text/html stuurt.

[dmantione]

Alleen als je het als text/html opstuurt en dan detecteert de browser het als HTML met fouten er in. Immers, XHTML is geen geldige SGML, en HTML is nu eenmaal een SGML-taal. Gevolg is dat hij in quirksmode springt en de webstandaarden daardoor nog minder naleeft.

HTML 4 strict is de beste methode om websites te maken die op alle browsers goed werken.

[dtech]

Volgens mij is dit niet het geval als je hem gewoon netjes een doctype mee geeft, weg quirksmode
De W3C validator vind het iig valide XHTML 1.1 strict als je hem met een text/html header en doctype verstuurt.
[edit]
Uit Een blogje van microsoft:
[quote]
I realized as I read through the comments to my last blog post that I forgot to mention one important item that was in my presentation. We have fixed the DOCTYPE switch so it will skip an XML prolog, so that valid XHTML can be handled in strict compliance mode rather than quirks mode.
[/quote]
Als je het <?xml deel weglaat handelt hij het dus via strict mode af.

[dmantione]

Juist ja. En dan is het geen correcte XHTML meer.

[Patriot]

Mijn code valideert XHTML 1.1 Strict zonder die XML tag.

[crisp]

IE 'vreet' alleen XHTML als je het voert als HTML (it's all in the mimetype). Enige nadeel is dat XHTML syntax invalid HTML syntax is en je dus vertrouwd op de ingebouwde error-correctie.

[Verwijderd]

Ik doe niet al teveel met html maar voor normale webpagina's zit er toch niet zoveel verschil tussen xhtml en html (strict)? Alleen wat syntax verschillen zoals <br/> ipv <br>.
Eventueel dat hier en daar wat geschrapt is en er wat andere dingen bij zitten.

Gewoon een streep door een van beide zetten lijkt mij het meest prettig voor developer en website bouwer.

[Little Penguin]

Gewoon een streep door een van beide zetten lijkt mij het meest prettig voor developer en website bouwer.

De vraag is dan alleen: Welke moet dat wegvallen?

HTML - omdat deze niet goed uitbreidbaar is en de bestaaande HTML documenten mogelijk een zooitje zijn?

XHTML - omdat deze niet door de browser met het grootste [in NL althans] marktaandeel ondersteund wordt?

HTML is op dit moment de lingua franca op het web, maar XHTML heeft in sommige situaties - bijvoorbeeld als je het wilt mixen met MathML - voordelen.

Hopenlijk gaat de volgende versie van IE XHTML wel goed ondersteunen...

[user109731]

Ik doe niet al teveel met html maar voor normale webpagina's zit er toch niet zoveel verschil tussen xhtml en html (strict)? Alleen wat syntax verschillen zoals <br/> ipv <br>.

Echte XHTML (XHTML verstuurd met de juiste header) word geparst als XML. Dat houd naast de syntax verschillen bijvoorbeeld ook in dat er direct gestopt moet worden met parsen als er een error word gevonden.

Dat vind ik zelf het grootste probleem van XHTML: die error handling (wil je dat in een simpele website?) en de header: 90% lijkt dat maar niet te snappen, en verstuurd 'XHTML' nog steeds als text/html...

[dtech]

Wat moet je anders? Beter zorgen dat je site er netjes uit ziet volgens de XHTML 1.1 syntaxis voor het HTML-gedeelte met het goede doctype, die je ook nog eens in de toekomst makkelijk zou kunnen omzetten, dan een site waarbij je een "openen opslaan annuleren" schermpje krijgt...

[Patriot]

Ik snap niet waarom je de error handling als probleem ziet. Het is naar mijn mening toch een uitkomst om kleine foutjes te voorkomen.

De header is ook niet per sé een probleem. Ik verstuur naar browsers die het ondersteunen gewoon de true XHTML header, dat is nog nooit een probleem geweest.

[crisp]

(X)HTML is een opmaak-taal en geen programmeer-taal. Meestal wordt het gebruikt voor machine-human interfaces en niet voor machine-machine interfaces, derhalve is draconische error-handling niet noodzakelijk en vaak niet eens gewenst. In veel gevallen heb je ook niet 100% controle over de content en/of wordt (X)HTML gegenereerd door non-XML authoring tools.

Error-correctie voor (X)HTML mallformedness is voor veel triviale zaken prima te beschrijven zonder dat dat ambiguiteiten opleverd en verhoogt daarmee de toegankelijkheid. Stel je voor dat je een boek niet open kan slaan omdat er op pagina 38 een spelfout staat...

[Verwijderd]

In de praktijk werkt het andersom.... De webdevelopers kijken alleen of de pagina in hun favorite browsers goed laad, en checken niet of de pagina correct is.

Gevolg: Pagina's die vol zitten met fouten, en vaak toevallig worden weergegeven zoals de bedoeling was.

Ik heb liever dat web developers eens moeten wennen om zorgvuldig en netjes te coderen, dan dat de browsers proberen van de puinhopen nog iets zinnigs te produceren...

[crisp]

Dat is dan een taak van IDE's en authoring tools, niet van een parser.

Wist je dat het ook puur toeval is dat XHTML nog goed wordt weergegeven als je het als text/html verstuurd? Dat is puur dankzij error-correctie en het feit dat browsers de NET SHORTTAG feature niet ondersteunen

[Belial_666]

Als tweaker weiger ik mensen met computer problemen te helpen als ze niet overstappen op Firefox.

Aangezien iedere Tweaker wel een inner cirlce heeft

alle beetjes helpen

[jurrie]

Zo'n Firefox ueber alles instelling is dan ook al om te huilen.

Verder heb ik als ontwikkelaar geen behoefte aan uitbreiding van HTML. Waarom zou MS wel uitbreidingen op HTML ondersteunen en niet XHTML. Dusver maak ik mijn zaakjes prima in XHTML Transitional op orde. Ik zou wel conform Strict willen werken, maar als de klant geen interne anchors of targets kan gebruiken breekt de hel los..

En nieuwe ontwikkelingen komen er echt wel langzaam maar zeker in. Al is het alleen al dat een site sneller / gebruikersvriendelijker werkt op de browsers en IE-users het, door het achter blijven van het beest, wat minder makkelijk hebben. Niet dat ze het doorhebben, want ignorance is bliss. Zolang het resultaat maar voldoet aan de wensen van de klant.

[Patriot]

Geen interne anchor's? Geen target's? Interne anchor's is een lachertje, en een beetje webdeveloper maakt binnen 5 minuten een javascriptje om target's te simuleren.

[Verwijderd]

een beetje webdeveloper maakt binnen 5 minuten een javascriptje om target's te simuleren

Als je dat doet kun je net zo goed je hele pagina door javascript laten uitpoepen en schijt hebben aan standaards...

Heel simpel, als je targets wilt, kun je GEEN strict gebruiken.

Je kunt JS <tr><td>Bla</th></table> uitspugen en toch valideert je pagina.... Kan inderdaad maar dan moet je het geen strict noemen....

[Little Penguin]

Heel simpel, als je targets wilt, kun je GEEN strict gebruiken.

Volgens XHTML 1 en HTML4 is het mogelijk om alle elementen met een ID als target te gebruiken.

Als een pagina dus <div id="target">...</div> bevat kun je dmv http://www.tweakers.net/#target naar dit deel van de pagina springen.

Ofwel: (X)HTML Strict is ook wanneer je targets wilt goed te gebruiken....

[Blaise]

IE zal altijd een zo groot marktaandeel hebben dat je het wel móet ondersteunen als webdeveloper, dus om die reden hoef je het niet te doen.

[b19a]

Stukje bij beetje snoep je zo van het marktaandeel van Internet Explorer. Dat zet Microsoft na een paar jaar eens aan het denken...

Niet dat dat veel goed brengt op het gebied van IE, maar toch.

[Verwijderd]

Ik weet niet of ik nu blij moet zijn of teleurgesteld.

Blij omdat ik een hekel heb aan XHTML dat me dwingt om lelijke code te schrijven omdat een of andere hondelul bedacht heeft dat tags niet meer met hoofdletters mogen en dat iedereen die zich daar niet aan houdt gestraft wordt doordat diens pagina's opeens niet meer geldig zijn.

Teleurgesteld omdat de achterliggende reden kennelijk is dat ze bij Microsoft zo incompetent zijn dat ze na al die jaren nog steeds geen fatsoenlijke ondersteuning hebben van XHTML, dat ondanks al zijn tekortkomingen toch steeds meer toegepast wordt op allerlei websites.

Dus ja... You're not the only one with mixed emotions.

[killercow]

Hoe is code met kleine letters in gods naam lelijk

Hoe is code met kleine letters voor argument namen lelijk dan code waarvan het ene argument groot en het andere argument klein is.

Hoe is code die " of ' om elke value verwacht in gods naam lelijker dan code die te pas en te onpas wel of geen quotes gebruikt.

En hoe is code waarvan je zonder specs de structuur kunt begrijpen lelijker dan code waarvan je van te voren moet weten dat br,img meta en nog wat van dat soort tags zelf sluitend zijn?

[dmantione]

Punt van de zaak is dat hoofdlettergevoeligheid niets met het verbeteren van de webtalen te maken heeft, het is gewoon de persoonlijke voorkeur van één of andere idoot die in de XML-werkgroep zat.

Onvrede bij webontwikkelaars daarover is dan ook volledig terecht.

[killercow]

En toch.

Een low level xml parser kan veel sneller z'n tags vinden, het scheelt hem namenlijk zowiezo een vertaal slag per uppercase char.

Dus waarom zouden we het niet doen,
kost het je echt moeite om gewoon niet de shift knop in te drukken?

[dmantione]

Zoek elk karakter in een tabel op en je bent 1 klokpuls per karakter kwijt aan de hoofdletterconversie.

Als je in bestaande tradities gaat wroeten, en zeggen dat ze dingen anders moeten doen zonder goede reden, dan mislukt dat. Ga je bestaande tradities beschrijven en uitbouwen, dan wordt je standaard snel omarmd.

Dat is naar mijn mening precies de fout die bij XHTML gemaakt wordt.

P.s. doe wat aan je spelling.

[Verwijderd]

Hoe is code met kleine letters in gods naam lelijk

Omdat het onderscheid tussen tags en inhoud daarmee veel minder duidelijk wordt.

Hoe is code met kleine letters voor argument namen lelijk dan code waarvan het ene argument groot en het andere argument klein is.

Dat is een kwestie van discipline van degene die de code schrijft.

Hoe is code die " of ' om elke value verwacht in gods naam lelijker dan code die te pas en te onpas wel of geen quotes gebruikt.

Idem.

En hoe is code waarvan je zonder specs de structuur kunt begrijpen lelijker dan code waarvan je van te voren moet weten dat br,img meta en nog wat van dat soort tags zelf sluitend zijn?

XML is ook niet begrijpelijk zonder er iets van af te weten, dus maak je maar geen illusies hoor... En onbedoeld maak je een goed punt: die onnodige extra slashes maken XHTML inderdaad een stuk lelijker.

Zo, ik heb al je punten weerlegd...

[SPee]

In een IDE worden de tags gekleurd en is dus duidelijk te onderscheiden van de inhoud.
Verder, hoeveel andere XML gebaseerde documenten hebben een tag die met een hoofdletter beginnen

En de discipline voor wel/geen hoofdletter, wel/geen quotes zit enkel bij de programmeur. Als ie wordt gedwongen om enkel klein te schrijven en gebruik te maken van qoutes, zit die diciplene er zo in.
IDE's kunnen trouwens ook helpen om dat alvast in te vullen voor jou.

Verder, die 'onnodige' eindslashes, maken het document extra leesbaarder. Je weet nu precies waar een bepaalde tag begint en waar hij eindigt. In de huidige HTML standaard, kun je 'loze' tags hebben, zonder een eindtag. Zoek die maar eens als het fout gaat.
Verder kun je ook beter de tags door een boomstructuur laten weergeven, wat wel netter is dan nu kan met HTML.

[roy-t]

Eigenlijk vind ik XHTML helemaal niet zo geweldig nuttig en vernieuwend: bron wc3.nl:

Er bestaat een belangrijke XML-applicatie dat een documentformaat is, namelijk XHTML van het W3C, de opvolger van HTML. XHTML beschikt over vaak dezelfde elementen als HTML. De syntaxis is iets gewijzigd om te kunnen voldoen aan de regels van XML. Een op XML gebaseerd document erft de syntaxis van XML en beperkt deze op bepaalde manieren (bijvoorbeeld bij XHTML mag <p>, maar <r>

Dus in je hele browser weer troep inbouwen om Html met een iets gewijzigde syntaxis in te bouwen, compleet met testen en render errors weg werken, vooral voor het in mijn ogen toch iets logger IE lijkt me dit een hele klus (IE is log omdat het naast browser ook vele functies in windows zelf heeft!) En de markt heeft dit eigenlijk ook helemaal niet nodig, er is toch php icm met (my/ms)sql voor gestructueerde inhoud, en gewoon html voor weergave hiervan icm php, en als het dan echt fancy moet is er Java en Flash. Dit vind ik al meer dan genoeg standaarden!

(als je me wegmod, mag ik dan ook weten waarom? het is een onderbouwde mening, geen flames een geen onzin...)

[Michali]

Het lijkt mij juist gemakkelijker (lees: sneller) voor een browser om XHTML te renderen. Dit omdat er geen vangnet voor foutieve HTML hoeft te zijn. Een error als het document niet well-formed is (en misschien ook als het niet valid is), is genoeg. Bij normale HTML moet het ook blijven werken als je document een zooitje is. Dit kost veel meer tijd om uit te vogelen.