W3C schaart zich achter html 5-specificatie

De Html Working Group heeft de eerste draft van html 5 gepubliceerd. Het World Wide Web Consortium heeft zich achter de voorstellen geschaard, zodat ontwikkelaars er nu mee aan de slag kunnen.

De laatste officiële specificatie van html, versie 4.01, stamt alweer uit 1999 en sinds die tijd heeft het World Wide Web Consortium xml en css ontwikkeld. De syntax van html is echter niet ingrijpend veranderd. Met html 5, waarvan de ontwikkeling in 2004 werd geïnitieerd door Apple, Opera en de Mozilla Foundation, komt daar nu verandering in.

De html 5-specificatie zorgt voor eenvoudiger en leesbaarder html-code, onder meer vanwege een striktere scheiding tussen presentatie- en semantische elementen. Html 4-elementen zoals center, font en strike komen niet in de html 5-specificatie voor, omdat deze presentatiefunctionaliteit beter door css afgehandeld kan worden, terwijl de frame is verwijderd omdat dit element vaak op een ongewenste manier wordt toegepast. Html 5-documenten kunnen ook in xml worden opgemaakt.

De kladversie van html 5 bevat een flink aantal nieuwe attributen en nieuwe elementen voor een duidelijkere structuur. Zo geeft de nav-tag aan dat een element voor navigatie bestemd is, terwijl het footer-element een onderschrift bevat. Nieuw zijn ook de time- en meter-elementen die typeren hoe bepaalde informatie toegepast kan worden.

Aan html 5 zijn ook api's toegevoegd voor het afspelen van audio en video met de nieuwe video en audio-elementen en een drag-and-drop-api met het nieuwe draggable-attribuut. De ondersteuning van audio en video is overigens nog een heikel punt: op 7 december werd bekend dat de patentvrije Ogg Vorbis audio- en Ogg Theora-videoformaten onder druk van Apple en Nokia uit de html 5-specificatie verwijderd zijn.

Een voorwaarde voor applicaties die html 5 willen ondersteunen is wel dat alle bestaande webpagina's met html 4-code weergeven moeten kunnen worden. De html 5-specificatie van de W3C is pas definitief als er twee html 5-implementaties op de markt zijn.

Reacties (100)

[Rhino]

Uit het stuk spreekt toch enig misverstand over de status van een Working Draft binnen het W3C.

Het W3C werkt met zgn. Working Groups (WG's) die zijn samengesteld uit vertegenwoordigers (werknemers) van W3C member organisations (betalende leden). Een WG werkt vrijwel geheel onafhankelijk van het W3C (afgezien van ondersteuning) aan een nieuwe (versie van een) standaard, op basis van een 'Member Submission'

Gedurende de loop van een WG (meestal ongeveer 2 jaar), wordt meerdere malen om commentaar van mensen buiten de WG gevraagd. Dit gebeurt via het proces van het publiceren van Working Drafts (WD), waar de brede gemeenschap commentaar op kan leveren. De WG gaat vervolgens met dit commentaar aan de slag, en produceert een volgende Working Drafts.

Meestal worden twee WD's gepubliceerd, waarna de WG de laatste versie indient als Candidate Recommendation (mits het W3C acht dat de standaard voldoende is ontwikkeld om ook daadwerkelijk gesteund te worden). Dit is het zgn. 'Rec Track'... waarin de Advisory Committee (officiele afgevaardigden van de member organisations) beoordeelt of zij de standaard 'endorsen'. Dit gebeurt dmv van stemming.

Als er geen bezwaren zijn, en het AC + de directie van het W3C (Tim BL) gaat akkoord, wordt de standaard een 'Recommendation'.

Kortom: het publiceren van een Working Draft betekent helemaal niet dat het W3C er achter staat... het is slechts een mogelijkheid voor de community om op een relatief 'vast' document commentaar te leveren.

(Zit zelf in de OWL WG, en we hebben ook net een FPWD (first published working draft) online gezet... )

[tjerkw]

Jammer, html 5 is nog steeds verouderd. XHTML 2.0 met XFORMS is veel modulairder en veel beter. Ooit eens naar XForms gekeken? Dat is echt werkeleijk krachtig.

In de toekomst zullen servers alleen pure xml serveren in hun eigen formaat. Aan zo'n xml document is dan een XSLT stylesheet gebonden die door de client gerenderd wordt.

90% van de mensen weet niet wat je allemaal met XML kunt. XHTML SVG MathML XSL zijn complementaire technologien die het web echt naar een nieuwe level brengen. En dan heb ik het nog niets eens over de semantische web en de communicatie tussen comptuers.

Momenteel draai ik al mijn XSL transformaties server-side. Ik zou ze liever client-side laten draaien omdat deze transformaties nogal duur zijn. En kom nou niet aan met smarty of een andere template taal, deze zijn inferieur aan xslt.

[Little Penguin]

In de toekomst zullen servers alleen pure xml serveren in hun eigen formaat. Aan zo'n xml document is dan een XSLT stylesheet gebonden die door de client gerenderd wordt.

Als je met 'in de toekomst' over 10 jaar of meer bedoelt, dan zou je gelijk kunnen hebben. In de nabije toekomst zie ik het echter niet gebeuren.

Wat wel mogelijk is, dat is dat er door applicaties XML gegenereerd wordt, die op de server omgezet wordt naar HTML of welke gewenste taal dan ook - bijvoorbeeld HTML en sommige content naar SVG (waarbij de SVG weer via een plugin gerenderd wordt in verouderde browsers).

90% van de mensen weet niet wat je allemaal met XML kunt. XHTML SVG MathML XSL zijn complementaire technologien die het web echt naar een nieuwe level brengen.

Zodra meer dan 90% van de gebruikers een browser gebruikt die moderne standaarden, zoals de XML-based talen, ondersteunt dan zal men ook doorkrijgen wat het voordeel van XML is. Hoewel mijns inziens de hoofdmoot ten allen tijde XHTML moet blijven, is er inderdaad voordeel te behalen bij het goed toepassen van op XML gebaseerde talen.

Op dit moment zullen we het echter moeten doen met het maximaal haalbare en dat is
(nog even) voortborduren op HTML5 met de HTML5 serialisatie en binnen deze beperkingen een evolutie te laten plaatsvinden. Ik zal echter de laatste zijn die het in onbruik raken van archaïsche producten als IE zal betreuren ...

En dan heb ik het nog niets eens over de semantische web en de communicatie tussen comptuers.

Het semantische web is met HTML evengoed te bereiken als met XHTML, de manier waarop we het gaan realiseren zal misschien niet hetzelfde zijn, maar het idee 'dat XML/XHTML beter is voor het semantische web' dat is grote onzin.

Voor communicatie tussen computers is XHTML inderdaad beter dan HTML, omdat de foutafhandeling van XHTML (lees: XML) veel beter is dan van HTML (lees: geen foutafhandeling bij HTML).

Momenteel draai ik al mijn XSL transformaties server-side. Ik zou ze liever client-side laten draaien omdat deze transformaties nogal duur zijn.

Precies wat ik dus al aangaf aan het begin van mijn reactie, ik zie het uitvoeren van de XSLT transformaties dus wel op de server gebeuren de komende paar jaar, maar dus niet op de client.

Overigens is het uitvoeren van de XSL transformaties op client niveau ook gelijk weer het teniet doen van het semantische voordeel van XHTML, omdat je dan namelijk de informatie die noodzakelijk is voor het sem.web in de XSL stopt en zoekmachines, zoals Google, deze dus niet zien. Dat betekent dat dit soort systemen dus ook weer de XSL erbij moeten pakken en of dat op korte en middellange termijn te gebeuren staat dat waag ik ten zeerste te betwijfelen...

[tjerkw]

Op dit moment zullen we het echter moeten doen met het maximaal haalbare en dat is
(nog even) voortborduren op HTML5 met de HTML5 serialisatie en binnen deze beperkingen een evolutie te laten plaatsvinden. Ik zal echter de laatste zijn die het in onbruik raken van archaïsche producten als IE zal betreuren ...

Precies we kunnen nog niet de geavanceerdere tecehnieken gebruiken omdat +/- 90% van de gebruiekrs een ancient browser gebruikt.

Overigens is het uitvoeren van de XSL transformaties op client niveau ook gelijk weer het teniet doen van het semantische voordeel van XHTML, omdat je dan namelijk de informatie die noodzakelijk is voor het sem.web in de XSL stopt en zoekmachines, zoals Google, deze dus niet zien. Dat betekent dat dit soort systemen dus ook weer de XSL erbij moeten pakken en of dat op korte en middellange termijn te gebeuren staat dat waag ik ten zeerste te betwijfelen...

XHTML zelf heeft nog relatief weinig semantiek. De echte pure XML die nog door de transformatie moet heeft de echte semantiek.
En het sementieke web zal vooral op RDF en OWL moeten draaien. Maar daar geloof ik zelf niet echt in.


Overigens XLink XHTML SVG en MathML zijn mischien relatief nieuw, maar zeker wel van deze tijd. Het blok aan ons been zijn oude browsers als MSIE 6.0 en zelfs de slechte MSIE7.0.

Firefox heeft SVG al geimplementeerd. en MathML kan worden ondersteund met een simpele extensie.
Met XML Namespaces kun je in 1 document verschillende typen data mengen. Dat is pas echt krachtig.
Of wat dacht je van XUL omzetten mbv XSL naar SVG waardoor je een retestrakke applicatie krijgt.

[crisp]

Er is technisch geen reden waarom XML-applicaties niet zouden kunnen samenwerken met een HTML5-applicatie.

Het grote voordeel van (X)HTML zit in het feit dat het semantiek toevoegd aan de content, iets dat 'vanilla' XML niet kan doen. Daardoor is clientside XSL transformatie ook weinig zinvol omdat je dan de voordelen mist van een echte 'markup' taal en puur afhankelijk bent van de capaciteiten van een bepaalde client.

Heb je overigens ook naar WebForms gekeken? Dat maakt namelijk onderdeel uit van HTML5

[joho]

De ondersteuning van audio en video is overigens nog een heikel punt: op 7 december werd bekend dat de patentvrije Ogg Vorbis audio- en Ogg Theora-videoformaten onder druk van Apple en Nokia uit de html 5-specificatie verwijderd zijn.

Deze toevoegingen juist lijken mij juist het belangrijkste in de nieuwe specificatie. Zoveel mogelijk propriëtare (troep) elementen weghalen als mogelijk. Dan blijft het web op alle mogelijke omgevingen werken.
Het overvloedig aanwezig zijn van formaten als flash, quicktime, en windows media, maken het voor fabrikanten van apparaatjes zoals telefoons, mediaplayers, onmogelijk een vrije keuze uit te oefenen. Ze moeten nog steeds achter de chips aanlopen waarvoor deze plug-ins beschikbaar zijn. Er zou zoveel meer concurentie mogelijk zijn als ze vrij kunnen kiezen.
Flash is er alleen voor de Intel x86 instructieset. Quicktime alleen voor Intel x86 en mischien nog voor Motorola 68k, en Microsoft Media alleen voor platforms waarvoor Microsoft OSe en bestaan (desktop: Intel x86; embedded: WindowsCE, wat ARM varianten).

[MadEgg]

Flash draait anders ook prima op mijn Nokia N95, en dat is geen x86. Niet helemaal waar dus. Maar inderdaad wel jammer dat ze dat geschrapt hebben.

[_Thanatos_]

Van de W3C draft:

<!doctype html>

That's it? Hoe weet de browser dan aan welke versie hij zich moet houden?
Geen DTD om tegenaan te valideren? Geen namespace die je kan declareren om andere namespaces (SVG, Canvas, MathML) te importeren?

Dat begint lekker...

[Reactie gewijzigd door _Thanatos_ op 26 juli 2024 21:47]

[Little Penguin]

<!DOCTYPE html> indiceert het gebruik van HTML 5, verder werden doctypes eigenlijk niet gebruikt*. Het valideren tegenover de DTD is nog nooit door één browser geimplementeerd, als dat wel zo geweest zou zijn zou het schrijven van een browser een stuk eenvoudiger zijn geweest...

Het mixen van HTML5 met SVG of MathML (of welke XML based taal dan ook) vereist een XML serialisatie met namespaces, ook hiervoor is geen DTD nodig. Wat canvas in deze mix zoekt is mij overigens een raadsel, canvas wordt namelijk dmv scripting gevuld...

*: Het enige wat met de DTD gedaan werd is het selecteren van render-mode, waarbij bepaalde DTDs ervoor zorgen dat er in standards of almost standards mode gerenderd wordt.

<!DOCTYPE html> wordt door alle browsers als 'standards mode' gezien en is daarom meer dan voldoende...

[Fuzzillogic]

En impliceert dat *alle* komende versies van HTML volledig backwards compatible moeten blijven met HTML5. Een slechte zaak.

[crisp]

Dat is juist een goede zaak. Als HTML6 niet backwards compatible zou zijn met HTML5 dan moeten browsers dus weer een nieuwe rendermode gaan ondersteunen en loop je het risico dat op den duur 'oude' versies HTML niet meer ondersteund gaan worden en daarmee dus legacy content verloren gaat.

HTML6 zou bijvoorbeeld wel bepaalde zaken kunnen 'deprecaten' in die zin dat het niet meer author-conformant is, maar UA's zullen toch altijd oude zaken moeten blijven ondersteunen en derhalve zou elke opvolger van HTML5 die ook moeten blijven beschrijven.

[Fuzzillogic]

Dat betekent ook dat we alle restanten uit HTML4 transitional tot in het einde der tijden zouden moeten meesleuren. Wat een onzin.

Bovendien is het natuurlijk wel heel erg simpel om HTML4-content, mits er gebruikt is van semantische HTML, om te zetten naar de ML die op een gegeven moment hip is. En met XML zou dat alleen nog maar beter gaan. Dus kunnen we het beste zo snel mogelijk die overgang maken, ipv nog meer meuk het web op te gooien in een ancient en formaat.

[crisp]

Dat betekent ook dat we alle restanten uit HTML4 transitional tot in het einde der tijden zouden moeten meesleuren. Wat een onzin.

Dat is geen onzin; als nergens gespecificeerd is wat de betekenis is van bepaalde (in onbruik geraakte) elementen en hoe die behandeld zouden moeten worden dan zijn al onze electronische documenten in no-time waardeloos en verloren voor de toekomst.

Dat is juist het hele probleem van onze huidige samenleving: niets is meer blijvend, alles is proprietary, volatile of geplaagd door patenten. Over 100 jaar is er niets meer van ons over omdat het niet meer afspeelbaar is (er waren geen publieke standaarden en de bedrijven die de proprietary standaarden beheerden bestaan niet meer), de opslag-media zijn niet meer leesbaar (enerszijds door gebrek aan standaarden, anderszijds door het toepassen van goedkope maar minder kwalitatieve middelen), of het mag niet zomaar geëncodeerd worden omdat bedrijf X een vaag patent heeft.

Wat jij voorsteld is het weggooien van alle huidige documenten op het web; dat gaat zelfs nog verder dan de problemen die we nu in de toekomst tegemoet kunnen zien...

[Fuzzillogic]

Dat is geen onzin; als nergens gespecificeerd is wat de betekenis is van bepaalde (in onbruik geraakte) elementen en hoe die behandeld zouden moeten worden dan zijn al onze electronische documenten in no-time waardeloos en verloren voor de toekomst.

Dat is onzin. Alsof de huidige HTML4 specificaties ooit nog verloren zullen gaan. Bovendien is de betekenis van <h1>, <strong>, <table> toch ook voor een mens nog wel perfect duidelijk, zeker in context van de tekst zelf. Ander voorbeeld: je hoeft geen kennis te hebben van ODF om een OpenOffice tekstdocument te kunnen begrijpen.

We hebben het hier niet meer over een binair Word-formaat uit de oudheid, maar een plain-text-leesbaar documentformaat. Met de huidige openheid en gigantische opslagmogelijkheden is het volstrekt ondenkbaar dat dit soort zaken verloren zouden kunnen gaan. Tenzij de aarde ontploft ofzo, maarja, alsof er dan iemand zich nog druk maakt om HTML5.

[crisp]

<h1> is al een voorbeeld van een tag die zo op het eerste oog al niet duidelijk is, en verder ga jij er blijkbaar van uit dat taal ook niet veranderd. Je moet nu sowieso al kennis van de Engelse taal hebben om de betekenis van tags enigszins te kunnen begrijpen, maar zelfs dan dekken tagnames niet altijd de lading.

Een in onbruik geraakte specificatie kan later wel eens verdomd moeilijk terug te vinden zijn. Wij konden ook pas hieroglyphen ontcijferen na het vinden van de Rosetta steen...

[Little Penguin]

Om af te komen van HTML4 (en voorliggende zaken) - dus zowel in de browserimplementatie als ook in de websites - zullen we over moeten stappen naar een compleet andere markup-taal.

In dat geval zou er dus bijvoorbeeld eenzelfde stap genomen kunnen en moeten worden zoals bij XHTML2, maar dat betekent ook dat alle browserfabrikanten (of in elk geval de fabrikanten van browsers die het meest gebruikt worden, op dit moment zijn dat dus Firefox, Internet Explorer, Safari en Opera) hieraan mee moeten werken. Een totale revolutie zorgt dan in elk geval voor een betere taal voor zowel voor het uitlezen (door o.a. browsers) en voor het aanmaken (o.a. webdesigners en webprogrammeurs).

Helaas is het zo dat op dit moment tenminste 1 fabrikant niet erg cooperatief is was. Zolang meer dan 90% van de gebruikers die modernere ML nog niet uit kan lezen zal er dus ook niks in aangemaakt worden...

Verder is het idee inderdaad 'transitional', maar in de praktijk blijkt dat gewoon haast niet te realiseren - maar misschien dat "HTML6" wel een stuk beter opgemaakt kan worden en inderdaad een serie legacy zaken opzij kan zetten. (Te denken is aan een MIME switch waarbij er een versie bij het XHTML doctype komt: application/xhtml;version=6 bijvoorbeeld)

[Little Penguin]

In de praktijk is dat dus al zo, HTML 5 is backwards compatible met 4.0, 3.2, 2.0 (etc). Browsers gaan hier zo-wie-zo al vanuit.

Als je nu een HTML 3.0 document op het net zet, dan zal deze ook niet goed gerenderd worden, zelfs al voeg je een doctype toe.

Nu heb je wel degelijk een punt, want er moet wel degelijk een manier komen om af te kunnen wijken van het HTML keurslijf. Helaas is de meest voor de hand liggende mogelijkheid (XML) op dit moment niet mogelijk omdat hiervoor nog onvoldoende support is in de browser (qua marktaandeel van XML compliant browsers dus). Als je namelijk overstapt op XML serialisatie dan kun je via namespaces weer een soort van versioning en modularisatie afdwingen....

[_Thanatos_]

In de praktijk is dat dus al zo, HTML 5 is backwards compatible met 4.0, 3.2, 2.0 (etc).

Html 4-elementen zoals center, font en strike komen niet in de html 5-specificatie voor

Dus of de submitter heeft het mis, óf jij hebt het mis, óf de browsers doen het hartstikke fout. Ik denk dat laatste geval, en dat is waar het probleem zit: de browser slikt teveel dingen die gewoon knetterhard FOUT zijn. Zoals target in XHTML 1.1 gewoon werkt, maar niet zou mogen werken, en zoals <center> wrs in HTML5 werkt, maar niks zou moeten doen.

[Little Penguin]

Dus of de submitter heeft het mis, óf jij hebt het mis, óf de browsers doen het hartstikke fout. Ik denk dat laatste geval, en dat is waar het probleem zit:

De browser doet het, volgens HTML5, niet per definitie fout: Bij de specificatie van HTML5 is uitgegaan van maximale backwards compatibility, zodat een browser die HTML5 kan renderen ook 4.0, 3.2, etc. kan renderen. Om dit te bewerkstelligen is de HTML5 specificatie opgesplits in een deel wat alleen van toepassing is voor makers van browsers (en aanverwante producten) en een deel dat alleen van toepassing is op webdesigners en software die websites genereert.
Zie ook: http://www.w3.org/TR/2008...122/#backwards-compatible

Volgens HTML5 moet een compliant user agent dus ook alle oude zaken ondersteunen van eerdere versie van HTML - dat maakt het echter geen valide markup voor de maker van de webpage, in de praktijk is het echter niet te verbieden. Eigenlijk is het toch toestaan een knieval voor de manier waarop men tegenwoordig omgaat met het maken van een website, dit gebeurt nog al eens houtje-touwtje heden ten dage
Zie ook: http://www.w3.org/TR/html5/#syntax

[Verwijderd]

Maar kan het door een gewone XML parser? Dat vind ik persoonlijk essentieel.

[Little Penguin]

Als je van de XML serialisatie gebruik maakt, dan kun je HTML5 gewoon gebruiken, het heet dan overigens XHTML 5.

Overigens moet je dan juist geen doctype opgeven, want anders gaat het mis qua validatie t.o.v. de niet aanwezige DTD. Ook zul je waarschjinlijk UTF-8 moeten gebruiken omdat je de bekende HTML entities (&euml; &euro; etc) niet kunt gebruiken. De enige entities die aanwezig zijn dat zijn &amp; &gt; en &lt; - wat dat betreft is de opmerking van _Thanatos_ dus ook niet correct...

[Reactie gewijzigd door Little Penguin op 26 juli 2024 21:47]

[_Thanatos_]

Ook zul je waarschjinlijk UTF-8 moeten gebruiken omdat je de bekende HTML entities (&euml; &euro; etc) niet kunt gebruiken.

Dat komt juist doordat je geen doctype gebruikt, en het HTML5 doctype definieren helpt ook niet, omdat die geen DTD importeert waar entities-declaraties in thuis horen.

[_Thanatos_]

Nee, want het is SGML. Je xml parser stikt al op regel 1: hij kan de doctype definitie nergens vinden. regel 3: <head> is niet gedefinieerd. regel 8: &amp; is niet gedefinieerd. En ga zo maar door.

Handig hoor, dat SGML.

[crisp]

HTML5 is juist geen SGML-implementatie, maar heeft - naast de XML-serialisatie - een eigen syntax.

[_Thanatos_]

Wat is er XML aan het niet sluiten van tags, het mixen van lower/uppercase, en de afwezigheid van elke vorm van validatie? Mag jij me gaan uitleggen hoe ik m'n standards-conformerende XML parser zover krijg dat die dat allemaal snapt.

[Zyppora]

De ondersteuning van audio en video is overigens nog een heikel punt: op 7 december werd bekend dat de patentvrije Ogg Vorbis audio- en Ogg Theora-videoformaten onder druk van Apple en Nokia uit de html 5-specificatie verwijderd zijn.

Als die dingen patentvrij zijn, dan kan dat toch gewoon ge-implementeerd worden? Hebben Apple en Nokia daar zoveel over te zeggen? Het is niet zo dat het de enige door HTML5 ondersteunde formaten zijn, en het feit dat ze vrij zijn, betekent dat Apple en Nokia ze zo kunnen toevoegen op hun producten. Beetje onzin dat ze hiervoor gezwicht zijn.

Verder zie ik deze specificatie tegemoet. Het is mooi dat 'deprecated' elementen zoals font en center verdwijnen, daarentegen zijn nav en footer eigenlijk gewoon span/div elementen met een speciale CSS saus (maar als je echt puur wilt blijven, doe je italic ook met CSS).

[Dreamvoid]

Hoe het met Theora zit weet ik niet, maar de 'patentvrijheid' van Ogg is nogal dubieus. Xiph.org beweert dat het patentvrij is maar weigert hun juridisch onderzoek hiernaar openbaar te maken. Hierdoor zijn grote partijen erg huiverig om het te ondersteunen, er kan immers zo maar een patenthouder opstaan en miljarden gaan eisen.

Verder is het handiger om nog even drie jaar te wachten, dan lopen de laatste patenten op MP3 (een ISO standaard) af en is dat ook gratis.

[Jaap-Jan]

Ook bij andere codecs kunnen er na een tijdje patenthouders aankloppen, daar heeft Theora niet het alleenrecht op. Voor elk formaat kan na een tijdje een 'submarine patent opduiken.

Sterker nog, in het verleden heeft MPEG 4 al onder vuur gelegen door mogelijke inbraak op patenten van AT&T: nieuws: AT&T beweert patent op mpeg4 te hebben.

Op de site van Xiph.org, die ook een statement hebben gemaakt na de verwijdering van Ogg uit de HTML5 specificaties, staan ook nog een tweetal recente zaken met betrekking tot patentconflicten: http://xiph.org/press/2007/w3c/. Nou mag de bron niet geheel neutraal zijn, maar je kunt moeilijk ontkennen dat MPEG-4 op dit moment meer patentproblemen heeft dan Ogg Theora+Vorbis.

[ritsjoena]

Als die dingen patentvrij zijn, dan kan dat toch gewoon ge-implementeerd worden? Hebben Apple en Nokia daar zoveel over te zeggen? Het is niet zo dat het de enige door HTML5 ondersteunde formaten zijn, en het feit dat ze vrij zijn, betekent dat Apple en Nokia ze zo kunnen toevoegen op hun producten. Beetje onzin dat ze hiervoor gezwicht zijn.

Het betekent dat ze niet meer geïmplementeerd moeten worden. Dat betekent dat web-makers er niet meer vanuit kunnen gaan dat deze formaten ondersteund worden. Dat betekent dat (niet nadenkende) webmakers eerder voor andere formaten zullen kiezen, zoals bv die van Apple. Zeker als ze hun pagina's maken m.b.v. "helpende" software.

Dit betekent meer marktaandeel voor de commerciële formaten.

[YopY]

Dit betekent meer marktaandeel voor de commerciële formaten.

...indien die wel in de specificatie / standaard komen, kthx.

[Jaap-Jan]

Het betekent dat ze niet meer geïmplementeerd moeten worden.

Dat hoefden browsermakers toch al niet. Het implementeren daarvan was voor browserbouwers toch al niet verplicht, het viel onder 'should', dus geen 'must'.

En inderdaad, Apple heeft er wel belang bij dat deze strofe geschrapt werd, ze hebben namelijk zelf meeontwikkeld aan MPEG-4, in de vorm van een tweetal codecs:

quote: http://www.apple.com/quicktime/technologies/mpeg4/

Apple has developed two of its own ISO-compliant video codecs, MPEG-4 part 2 (a.k.a. MPEG-4 simple profile) and MPEG-4 part 10 (a.k.a. H.264) providing the highest quality results across a wide spectrum of data rates — from narrowband to broadband and beyond. T

Die laatste is iedereen wel bekend als H.264/AVC, een codec waarvan ook door HD-DVD en Blu-Ray gebruik van kan worden gemaakt.

[Reactie gewijzigd door Jaap-Jan op 26 juli 2024 21:47]

[jvdmeer]

Het heeft natuurlijk voordelen voor m.n. zoekmachines als <nav> en <footer> apart gemarkeerd worden.
Zo zou een zoekmachine bijv. standaard de footer kunnen negeren bij het indexeren.

[Verwijderd]

Waarom zou je dat willen? Een footer is de plek waar vaak informatie staat als:

Deze website is een initiatief van [link naar organisatie]
of
Powered by [link naar bedrijf]

Dat soort links zijn natuurlijk heel belangrijk voor de google-indexering van zowel de betreffende website als de organisatie die er achter zit.

[darkjeric]

Of ik dit een goede ontwikkeling vind weet ik niet...Het is natuurlijk positief dat ze HTML weer wat up-to-date brengen, maar waar is de XHTML gebleven die ze 3-4 jaar geleden nog liepen te verkondigen?

Ik vond bv. XHTML 1.1 Strict al een redelijk uniforme standaard, die door de meeste browsers al goed is geïmplementeerd. Ik weet niet hoelang het nu zal duren voor HTML5 ook goed wordt gerendered, en je mag er zeker van zijn dat Microsoft weer wat draaitjes geeft en er z'n eigen code inploft.

[RM-rf]

XHTML wordt door een groot deel van de momenteel in gebruik zijnde browser (t/m msie7) helemaal niet goed gerenderd, domweg omdat ze het als text/html renderen en niet als application/xml+xhtml....
Overigens is dat meestal nauwelijks een probleem omdat de betreffende xhtml-documenten ook eigenlijk gewoon niets meer zijn dan gewone statische html-documenten die geen enkele meerwaarde hebben om als xml-gevaldieert te worden...

dat is ook de reden dat HTML5 ontwikkeld werd, omdat de richting naar XML een doodlopende weg was voor het WWW, er weinig meerwaarde aan was en de implementatie van de eventuele mogelijkheden wél een enorme extra functionaliteit (parsing/validatie) van browser vroeg die soms zelfs contra-productief en niet gewenst was.

[OddesE]

Sorry, maar als websites standaard XHTML compliant output zouden genereren (die dan dus ook XML compliant zou zijn), dan zou dat mijns insziens wel degelijk een zeer grote meerwaarde leveren, want je zou dezelfde output die nu voor mensen bedoeld is dan ook kunnen gebruiken voor applicaties.

Doordat de meeste sites echter 'tagsoup' genereren is het bijna ondoenlijk dit te verwerken in een programma, zonder zelf een halve browser te bouwen. Zou het niet fantastich zijn als je in je programma gewoon zoiets kon doen:

String url = "http://tweakers.net/nieuws"
Document doc = Document.fetch(url);
Fragment[] fragments = doc.select("/html/body/news/article");
Print("Vandaag " + fragments.length + " nieuwsberichten op Tweakers!");

(syntax hierboven verzonnen)

Nu krijg je, als je zoiets probeert te schrijven altijd parse fouten omdat men zich niet aan de standaard houd en dus 'gewone' XML parsers niet met het document overweg kunnen.

[Toolskyn]

'als'

Veel mensen hebben geen idee wat het idee achter html/xhtml is. xhtml wordt dan vaak gezien als html waarbij <br> <br /> is geworden. Ik denk dat html nu net een van de belangrijke dingen is waardoor het web zo groot is geworden. Het is immers niet zo moeilijk een html pagina te maken en je krijgt niet gelijk een groot lelijk foutscherm als je iets net even verkeerd doet.

Want dat is wel de realiteit als je een echte pure xml versie van html hebt, dan krijg je gewoon een fout als je iets verkeerd doet, en dan wordt je eigenlijke inhoud simpelweg niet vertoont.

Er is natuurlijk genoeg te zeggen voor het gebruik van xhtml, verwerken van xml is namelijk duidelijk makkelijker dan het verwerken van html, maar ik denk niet dat het internet op dit moment al volwassen genoeg is om volledig op xml over te stappen. Misschien dat het in de toekomst wel gebeurd (er is in ieder geval rekening mee gehouden in de html5 specificatie door een xml versie aan te bieden).

[RM-rf]

Zou het niet fantastich zijn als je in je programma gewoon zoiets kon doen:

waarom moet 'jij' dat doen, 'in je programma' ... is het idee achter automatisering niet dat je die handeling liever aan je computer overlaat...
en met een goede grond, jouw pseudocode snapt 95% van de mensen die nieuwssites bezoeken al niet en zal deze nooit kunnen toepassen.

Bovendien biedt XHTML daartoe helemaal geen mogelijkheid, XML zelf ook niet, tenzij je custom DTDs gaat gebruiken als bv RSS

Maar bv het toevoegen van een RSS-feed, kunnen ze wél.. omdat ze daaraan niks hoeven te doen. En juist die functionaliteit biedt tweakers.net ook gewoon.
het zou echter geen enkele meerwaarde hebben om de functionaliteiten van RSS of RDF in HTML toe te passen, het zijn volledig andere functionaliteiten

[Reactie gewijzigd door RM-rf op 26 juli 2024 21:47]

[J.J.J. Bokma]

Dat kan gewoon, heb je geen halve browser voor nodig. Ik doe regelmatig dat soort dingen in Perl. Je moet wel ff uitzoeken in welk element datgene wat je wilt hebben rondhangt. Soms heeft dat element een id, en is het simpel. Anders krijg je iets als: het 3e div element dat een kind is van een div element met id body (bijvoorbeeld). XML hoeft dat niet eenvoudiger te maken.

[zenlord]

Ik maak mijn websites op in XHTML 1.1, maar ik moet ze laten renderen als text/html omdat ik anders op geen enkele standards-compliant-methode flashcontent kan toevoegen omdat de object- en embed-tags door verschillende browsers verkeerd worden geïnterpreteerd.

SWFobject is javascript om flashcontent op een correcte manier te gebruiken, doch werkt niet als je je pagina als application/xml+xhtml laat renderen.

Als de nieuwe video / audio / canvas / embed -tags wel goed overweg kunnen met flash- (en misschien ook andere content), dan zal ik met veel plezier application/xml+xhtml gebruiken.

Hopelijk wordt de standaard snel door FF en/of Opera ondersteund. Dat is denk ik de beste manier om IE8 te dwingen om ook HTML5 te gaan ondersteunen...

[CyberSnooP]

Een van de aantrekkelijkheden van XHTML was de XML syntax zodat je door gebruik van namespaces bijvoorbeeld SVG, SMIL en XHTML in een bestand kunt verwerken of dat je er met een simpele XML parser mee kon werken. Gelukkig wordt de HTML5 specificatie omschreven als:

Defines a single language called HTML 5 which can be written in a "custom" HTML syntax and in XML syntax

Oftewel, de taal HTML5 kan ook worden gebruikt in een XHTML-achtige vorm. Net zoals XHTML 1.1 inhoudelijk sterk gebaseerd was op HTML4

[OddesE]

Ach.. XHTML was meer een cleanup project om de tagsoup wat op te schonen... Echt iets nieuws toevoegen (tags e.d.) deed het niet.

Ik verwacht dat alle nieuwe elementen en attributen zometeen in XHTML te gebruiken zijn door de juiste module te includen. XHTML is immers modulair, zodat je hier en daar stukjes kunt pakken en zo je eigen Doctype maken.

[Verwijderd]

nieuws: Eerste officiële besluit over volgende html-versie genomen

Verder werd XHTML niet echt opgenomen / geaccepteerd door de it wereld omdat deze te weinig compatible zou zijn met oudere HTML versies. Dit is dus wel goed geregeld in HTML5.

[OddesE]

daarentegen zijn nav en footer eigenlijk gewoon span/div elementen met een speciale CSS saus

Waarom? 'footer' of 'nav' zijn toch begrippen en hebben dus een semantische betekenis? Als mens weet je wat er gemiddeld in een 'footer' te vinden is. Ik vond het eerder juist raar dat ze zoveel elementen weghaalden en bijna geen nieuwe toevoegden. Als je alles opmaakt met DIV's dan heeft je document bijna geen semantische betekenis meer. Als je dit:

<footer>Copyright 2008 by MyCompany</footer>

vergelijkt met

<div class="footer">Copyright 2008 by MyCompany</div>

Dan bevat het eerste voorbeeld toch veel meer (semantische) betekenis dan het tweede? Tenzij iedereen dezelfde classnames zou hanteren, maar daar is het Doctype nou juist voor bedoeld.

Nee, ik vind dit juist een hele vooruitgang.

[Reactie gewijzigd door OddesE op 26 juli 2024 21:47]

[H004]

Heel erg goed nieuws zelfs!

Bijvoorbeeld omdat de inhoud van een document nu veel beter gedefinieerd kan worden voor zoekmachines etc. Je kan nu o.a. ook discussies/reacties op een article aangeven, duidelijker menu's definiëren, footers en headers aangeven etc.

Daarnaast is de scheiding tussen opmaak en inhoud nu nog sterker gemaakt, door heel veel inline-stylingelementen te verwijderen.

Ook forms zijn een flink stuk verbeterd. Waarvoor men nu altijd js-oplossingen voor maakt kunnen nu met html gedefinieerd worden. En ook de inputvelden zijn eens tuk uitgebreider geworden, met o.a. maand, dag, jaar, datum, url etc.! En de invloed van je user agent wordt een stuk groter op de behavior van bepaalde form-elementen, bv een personal calender op een datum-field etc, contactpersonen uit je mailclient etc.

Van mij mag dit al gister ingevoerd zijn.

Van mij ook!

[aaiding]

Het verwijderen van frames om de reden dat "dit element vaak op een ongewenste manier wordt toegepast" is toch een slechte reden?

Volgens W3C:

HTML frames allow authors to present documents in multiple views, which may be independent windows or subwindows. Multiple views offer designers a way to keep certain information visible, while other views are scrolled or replaced. For example, within the same window, one frame might display a static banner, a second a navigation menu, and a third the main document that can be scrolled through or replaced by navigating in the second frame.

Bijvoorbeeld in 'n webapplicatie staat het menu in een apart frame, omdat het een paar seconden duurt voordat deze is opgebouwd.
Voordelen:
- Scheelt bandbreedte & webserver rekenkracht (slechts 1x opbouwen)
- Menu blijft altijd zichtbaar

Waarom zou je dan met Javascript & css gaan klooien om hetzelfde te bereiken?
(Met Javascript & css kan je semantisch gezien overigens ook al niet zoveel)

[Little Penguin]

Het FRAME element zal alleen in de documentatie naar de webdesigner verwijderd worden, een HTML5 compliant browser moet nog steeds frames ondersteunen.

Overigens zal een webapplicatie nooit echt semantisch te lezen zijn omdat er altijd wel zaken in zitten die lastig in een semantisch leesbare structuur te vangen zijn...

[H004]

Daarvoor kan je dan nu toch iframe's gebruiken?

[GrimaceODespair]

Beetje jammer dat de kans om die Ogg-vorbis erin te krijgen nu weer verkeken is.

Verder zit ik eigenlijk eerder te wachten op meer css-standaardisatie dan nog een nieuwe html-standaard.

[:murb:]

Vraag is of het thuis hoort in een hyperdocument standaard, maar ik vind de argumentatie hier voor vermelding van de open audio codecs wel een goede. Ook voor afbeeldingsformaten als GIF/JPEG is nu een brede support.

[Toolskyn]

Het lijkt me wel, zoals je zelf ook al zei is de mogelijkheid om afbeeldingen toe te voegen ook al in de eerdere HTML versies opgenomen (terwijl je daar natuurlijk eigenlijk dingen als embed en object voor zou moeten gebruiken), dus opzich zou het geen slecht idee zijn om ook iets dergelijks toe te voegen voor video en geluid, dan is de kring in ieder geval helemaal rond (beeld (img), geluid (audio), beeld+geluid (video)). Het is in ieder geval duidelijk dat video en audio in het huidige internet niet meer weg te denken zijn.

[Mei]

Ondersteuning voor mediatypes heeft niks met HTML te maken, maar met de aanwezigde mediaspelers/codecs op de computer van de client. De API in HTML zorgt er alleen voor dat het toevoegen van audio en video overzichtelijker enz. kan gebeuren. Het speelt zelf niks af. Wil jij ogg kunnen afspelen, dan moet je een mediaspeler hebben die ogg kan afspelen en een browserplugin voor jouw browser heeft.

[latka]

Ongeveer, behalve dat het voorstel er om ging een aantal standaard formaten voor te schrijven voor audio en video en deze _wel_ in de browser moeten zitten om HTML5 te ondersteunen. Als je een JPG in je pagina hebt wordt toch ook niet photoshop ge-embed?