Eerste officiële besluit over volgende html-versie genomen

De W3C-werkgroep die zich bezighoudt met de verdere ontwikkeling van html heeft na een enquête besloten de voorstellen van de Whatwg over te nemen. De html-specificatie die gaat voortbouwen op die van de Whatwg, krijgt officieel de naam 'HTML 5'.

De Web Hypertext Application Technology Working Group die bestaat uit Apple, Opera en Mozilla diende half april het voorstel in bij de W3C-werkgroep om 'hun' HTML 5 als startpunt te gebruiken voor de verdere html-ontwikkeling. Verdere wensen waren dat de naam 'HTML 5' een officiële status zou krijgen en dat Ian Hickson van de Whatwg zou blijven werken aan de specificatie. Uit de uitslag van de enquête die de W3C-werkgroep hield, blijkt grote steun voor de drie voorstellen; slechts een enkeling van de 102 leden die meededen aan het referendum stemde tegen. Daarmee is het eerste besluit van de W3C-groep omtrent HTML 5 een feit. Ook Dave Hyatt van Apple is hierbij overigens benoemd als editor voor HTML 5. Hij werd door de Whatwg naar voren geschoven om Hickson te vergezellen toen de W3C-groep aangaf één editor te weinig te vinden. In de toekomst zal het team van editors mogelijk nog worden uitgebreid, volgens de W3C.

Reacties (52)

[terabyte]

Diegenen die niet volmondig JA hebben gezegd (of zelfs NEE) hebben in mijn ogen geen slechte redenen:

Voorbeeld:

Considerable work also went into HTML 4.01 Strict. WHAT WG's proposal seems to to ignore a lot of that and base much of its design on less rigorous specifications (HTML 4.01 Transitional, possibly even HTML 3.2). Adding presentational elements and attributes to HTML 5 would be a step backwards for authoring. HTML 5 should promote the modeling the logical structure and semantics of information, not its presentation. Presentation is the job of CSS.

Iemand anders schrijf het volgende.

I am greatly disturbed by the implications of the question, in light of the copyright claims on HTML5 and WF2 by a number of developers. we are supposed to be evolving HTML4x into something better, not something proprietary, which can then be implemented unilaterally, thereby pushing the HTML WG in the direction of previous revisions to HTML prior to HTML4x -- the agenda of implementors drove the development of the language so that it is open to misuse, and then -- when corrections are suggested -- insist that it is imperative that a vendor-neutral standards setting body preserve and protect clearly underformed and malformed markup.

Ook interessant, al weet ik niet of de soep zo heet gegeten wordt als dat het wordt opgediend.

Microsoft heeft overigens helemaal niet gereageerd op de stemmig, wat dat betekent voor de implementatie van HTML5 in IE weet ik niet...

edit: AniMatrix heeft ergens de volgende quote vandaan gehaald:

HTML 5 is being developed with IE compatibility in mind. Support for many features can be simulated using JavaScript.

Volgens mij hoort een browser de standaard de implementeren, en is het niet zo dat er een standaard wordt bedacht voor een browser. Maar wellicht interpreteer ik het verkeerd.

[crisp]

Die soep wordt inderdaad niet zo heet gegeten; WHATWG's WA1.0 is immers gebaseerd op HTML4.01, alleen stapt het af van SGML als basis voor de syntax (geen enkele browser heeft het ook zo geimplementeerd) en definieerd het parsingrules en error-correctie - een punt waar HTML4.01 laakt en hoogstnoodzakelijk is om tot interoperability te komen.

In feite is HTML 5 HTML 4.01 zoals het nu gebruikt wordt (en dat is soms anders dan wat de specificatie voorschrijft) en bouwt het daarop verder op een backwards-compatible manier.

Overigens zijn er helemaal geen directe plannen om presentationele elementen of attributen toe te voegen, HTML 5 gaat zelfs nog verder dan HTML 4.01 door bepaalde elementen en attributen van 'deprecated' naar 'unconforming' te degraderen.

Copyright is nooit een issue geweest: http://lists.w3.org/Archi...ic-html/2007Apr/0429.html

If the group is agreeable to these proposals, Apple, Mozilla and
Opera will agree to arrange a non-exclusive copyright assignment to
the W3 Consortium for HTML5 specifications.

Verder is het belangrijk om te weten dat 1 van de voorzitters van deze W3 workgroup Chris Wilson van Microsoft is, en dat MS al heeft aangegeven zeker HTML 5 te gaan ondersteunen.

[Gustaaf437]

Eigenlijk de enige reden dat HTML5 ontworpen wordt is omdat Microsoft geen XHTML wel implementeren. Als Microsoft nu ook gewoon XHTML 1 in ieder geval goed geïmplementeerd had, zou XHTML 5 nooit in het leven geroepen worden. Zoals ook al gezegd wordt is HTML 5 in sommige gevallen meer achteruitgang, dan vooruitgang. Ik zal mijn website in ieder geval in XHTML + CSS 3 blijven ontwikkelen. Microsoft past zich vanzelf wel aan zolang hun marktaandeel blijft vallen. Het is gewoon zo dat er tegenwoordig net zo veel of misschien al meer websites zijn die niet compatible zijn met IE dan websites die alleen compatible zijn met IE. Dat is een enorme aardverschijving, want dat was 3 - 4 jaar geleden nog heel anders.

[Verwijderd]

XHTML en Microsoft zijn niet de oorzaak van het ontwikkelen van HTML5.

Veel webdevelopers vinden HTML te beperkt om complexe webpagina's mee op te bouwen. Niet wat betreft styling, daar hebben we CSS voor, maar wat betreft semantiek. Er komen nieuwe tags bij zodat het makkelijker wordt een hedendaagse website in HTML uit te drukken.

Eén van de belangrijkste punten is backwards compatibility. Het merendeel van de posters op de public-html mailinglist is het erover eens dat je niet met een schone lei kunt beginnen: er zijn miljoenen websites in incorrecte HTML geschreven, en dat zal zo blijven. HTML is er voor iedereen, niet alleen voor informatici. Er worden dan ook geen tot weinig elementen geschrapt; hooguit wordt sommige legacy deprecated verklaard. De websites uit 1995 zijn er nu eenmaal, die kun je niet uitsluiten.

Om problemen met backwards compatibility te voorkomen wil men HTML in het vervolg uitbreiden in plaats van veranderen. Dat betekent dat je HTML 4.01 zal kunnen parsen met een browser die HTML 16 implementeert. Maar ook dat voorstel is niet onomstreden.

Kortom, het "probleem" zit hem in de berg websites met brakke code, niet zozeer in het feit dat Internet Explorer een inferieure browser is.

[molf]

Backwards compatibility hoort wat mij betreft in de browser thuis en niet in de HTML specificatie. Net zoals dat overigens in het verleden gebeurd is. Een browser die HTML 16 implementeert kan dan nog prima HTML 4 parsen; dit hoeft niet te betekenen dat de specificatie van HTML 16 zelf compatible hoeft te zijn met HTML 4.

[Verwijderd]

In jouw voorbeeld moet een browser talloze engines aan boord hebben: één voor elke HTML-versie. Het voordeel van backwards compatibility is dat je met één engine alle HTML-versies kan bedienen.

Nu is dat misschien niet zo'n probleem, maar als we echt bij HTML 16 aanbeland zijn wel. Het is dan voor nieuwe browsers bijna onmogelijk alle websites te ondersteunen doordat ze 14 engines moeten maken.

[crisp]

Een browser die HTML 16 implementeerd moet wel weten hoe hij om moet gaan met HTML 4 documenten, maar zoals Weird Hobbes al aangeeft is versioning in die zin helemaal niet wenselijk...

[GigaDave56]

Het is dan voor nieuwe browsers bijna onmogelijk alle websites te ondersteunen doordat ze 14 engines moeten maken. (Weird Hobbes)

Ik als leek zeg, nou en? De specificaties van die 14 engines is toch openbaar?

Of bedoel je dat niet altijd duidelijk is welke engine zich wanneer aan welke HTML standaard houdt?

[crisp]

14 verschillende HTML-specificaties is een serieuse hindernis voor iemand die een browser op de markt wil zetten en is dus onwenselijk bovenop het feit dat het UA's nodeloos complex maakt met het risico op interoperability issues.

Daarbij bestaat het risico dat grote delen van het web onbereikbaar worden als een vendor met een aanmerkelijk aandeel besluit om support voor oude specificaties te laten vallen wat maatschappelijk gezien ongewenst is.

Note dat backwards compatibility puur onderdeel is van de UA-requirements die voorgeschreven worden door de specificatie en niet van de author-requirements.

[Verwijderd]

Kortom, het "probleem" zit hem in de berg websites met brakke code, niet zozeer in het feit dat Internet Explorer een inferieure browser is.

Doordat IE zo fout-tolerant is, niet W3c compatibe is en doordat veel sites op alleen IE ontwikkeld en gecontroleerd worden onstaat brakke code.

[crisp]

XHTML1.x is gewoon HTML 4.01 in een XML-jasje. Het enige voordeel dat het biedt is de mogelijkheid het te mixen met andere XML-varianten zoals SVG en MathML - hoe vaak gebruik jij dat?

Verder heeft XHTML1.x dus gewoon dezelfde nadelen als HTML 4.01 en in 99% van de gevallen in de praktijk wordt XHTML ook gewoon als HTML geserveerd en behandeld.
XHTML met XHTML mimetype heeft daarbij een nog groter nadeel: draconische errorhandling.

[J.J.J. Bokma]

Yup dat laaste is een extreem nadeel: voor XML geld dat als het document niet well-formed is, de parser een fout moet geven en stoppen met parsen. Dat is nogal een stricte eis voor websites en je kan dus probleemloos XHTML sites vinden die niet well-formed zijn, en dus eigenlijk door een browser niet weergegeven zouden moeten worden. En dat vind mijn ma geen feest.

[Niemand_Anders]

xhtml bied nog een ander groot voordeel wat helemaal niets met techniek te maken heeft. Veel klanten willen zelf html gaan schrijven en dat willen ze op de website krijgen.

Vroeger waren we dan soms uren bezig dit html dan te corrigeren. Nu zeggen we gewoon dat het xhtml complient moet zijn. En dat is simpel te controleren. Verander (onder windows) de extentie van .htm(l) naar .xml en IE render het bestand in XML modus. Pas als IE alle html code toont accepteren wij pas de html.

En of ze het xhtml 3, html 5 of TagSoup 1.3 gaan noemen kan mij geen barst schelen. Zolang maar alle bekende browsers het gaan implementeren.

Verder mogen browsers wat mij betreft gewoon weer witte lege pagina's gaan tonen of een foutmelding waar het probleem zit ipv dat een browser op eigen houtje gaat proberen het te fixen. En die witte schermen worden uiteraard alleen getoont als via de doctype wordt aangegeven dat het html 5 betreft, ander gaat de browser naar html 4 compability (quirks) mode.

Alle nieuwe html 5 websites worden dan geforced om goede code te bevatten. En als iedereen goede code heeft, zullen meer browser met hetzelfde resultaat komen.

[crisp]

Voor HTML bestaan ook gewoon validators, en het voordeel van een validator is dat het verder gaat dan enkel een pure syntax-check, hij checked ook conformance met de specificatie. Note dat dat ook nog niet volledig is want een validator kan bijvoorbeeld niet zien of jij bepaalde elementen wel semantisch-correct gebruikt

Validation is geen 'means to an end' en draconische error-handling sluit teveel mensen uit van webauthoring. Als gespecificeerd is wat een UA moet doen met mallformed markup dan heb je in feite hetzelfde bereikt (uniforme handling van markup) maar op een veel vriendelijkere manier.

Er is in de praktijk helemaal niet zoveel vraag naar XML-like behavior, er loopt ook nog niemand echt warm voor XHTML2. Bovendien definieerd HTML 5 ook een XML-serialisatie die je kan gebruiken voor die gevallen dat het echt noodzakelijk is hoewel je ook steeds meer ziet dat er mogelijkheden gecreëerd worden om XML-applicaties te embedden in een HTML-applicatie.

[J.J.J. Bokma]

"Eigenlijk de enige reden dat HTML5 ontworpen wordt is omdat Microsoft geen XHTML wel implementeren. "

Wat mij betreft nee. En ik weet vrij zeker dat meer mensen het daar mee eens zijn.

XHTML werkt niet. Ga eens uitzoeken hoeveel XHTML sites:

(1) well-formed zijn
(2) valideren

En denk dan eens hard na wat er allemaal mis kan gaan als XHTML als een XML toepassing behandeld zou worden door browsers...

De meeste mensen die XHTML gebruiken snappen niet wat het is.

De mensen die het mijden als de pest hebben vaak nog vers in het geheugen hoe Netscape 3.x met HTML omging als er 1 foutje in zat.

[Verwijderd]

De meeste mensen die XHTML gebruiken snappen niet wat het is.

Behalve dat XHTML pagina's gewoon als text/html geserveerd worden (anders doet IE het niet) en dus als tagsoup behandeld worden heeft XHTML toch een enorm voordeel en dat is waarschijnlijk de rede dat mensen XHTML gebruiken. Ik werk veel met XML, een groot deel van mijn tools zijn daarop gebaseerd. Het parsen van XML is voor mij niet anders dan het parsen van XHTML en dat maakt mijn werk gewoon eenvoudiger. XHTML is gewoon logischer en consistenter <BR> v.s. <br /> .

En denk dan eens hard na wat er allemaal mis kan gaan als XHTML als een XML toepassing behandeld zou worden door browsers

Leuk dat je het zelf al aanhaalt, bedenk ook is wat de mogelijkheden zouden kunnen zijn.

Dat IE geen xhtml gaat ondersteunen vindt ik een gemiste kans voor IE, ik blijf in ieder geval gewoon (gevalideerde) xhtml gebruiken en ik ben de enige niet.

[crisp]

Als je al met een XML-based backend en met XML-tools werkt dan is er inderdaad iets voor te zeggen om te werken met een XML-serialisatie van je markup, maar voor hoeveel mensen geldt dat? De meeste authoring-programma's, tools en CMS'en zijn niet XML-based en er wordt nog veel aan hand-authoring gedaan en/of gewerkt met markup fragments.

Daarbij is er technisch gezien ook niet zoveel belemmering om XML-applicaties te mixen met HTML-applicaties (en dat zie je ook steeds meer gebeuren), en als alle UA's vanuit een HTML-document een unified DOM-tree kunnen renderen (dmv gespecificeerde errorcorrection) vervallen de meeste voordelen van XML ook.

Verder vind ik het persoonlijk niet logisch om een element dat per definitie geen content kan bevatten ook af te moeten sluiten

[7.01D]

Misschien is XHTML 5 dan iets voor jou. HTML 5 en XHTML 5 zijn feitelijk dezelfde taal, alleen met een andere schrijfwijze (vergelijk het met het Engelse 'behaviour' en het Amerikaanse 'behavior'). XHTML 5 moet zich echter houden aan de XML-schrijfwijze en zal in tegenstelling tot HTML 5 ook door een XML-parser geparst moeten worden.

Overigens raden de ontwikkelaars XHTML 5 enkel aan in de gevallen dat je het document ook werkelijk als XML-bestand wilt kunnen gebruiken.

[KoalaBear84]

Dan hoop ik heel erg dat Microsoft dit z.s.m. in hun Internet Explorer stopt. En als dat dan eenmaal zo is dat alle gerespecteerde webdesigners meteen alleen in HTML 5 doen. Zou een hoop problemen (en kopzorgen) oplossen

-- edit --
http://blog.whatwg.org/faq/

What about Microsoft and Internet Explorer?

HTML 5 is being developed with IE compatibility in mind. Support for many features can be simulated using JavaScript.

Nou... Geweldig, als ik dit lees denk ik in m'n achterhoofd al "O nee, het is toch niet waar he". Javascript, wat is dat nu weer voor stomme halve work-around. Ik begrijp het zelf niet helemaal wat ze daar nu weer mee bedoelen.

Iemand anders een idee?

[L0g0ff]

Alleen IE7 vind ik persoonlijk niet eens het grootste probleem. Ik vind het renderen in Outlook, Word, Hotmail, Gmail, Squirrelmail etc eigenlijk net zo belangrijk.

Dingen als CSS en Fonts komen veel te vaak niet lekker door omdat alle partijen hun eigen HTML (4) gedachten hebben hierover.

Maar ik snap idd niet waarom MS niet zich mengt in de ontwikkeling hiervan. Silverlight, Sharepoint, Frontpage .NET etc etc zijn toch allemaal applicaties die veel met het web te maken hebben dacht ik zo.

[killercow]

Maar ik snap idd niet waarom MS niet zich mengt in de ontwikkeling hiervan. Silverlight, Sharepoint, Frontpage .NET etc etc zijn toch allemaal applicaties die veel met het web te maken hebben dacht ik zo.

Omdat het niet de intentie van MS is om veel met het web te maken te hebben, maar om er voor te zorgen dat het web veel met hen te maken heeft.

[Brupje]

die programma's gebruiken toch ook de IE engine?

[Nickname55]

Ik vind het renderen in Outlook, Word, Hotmail, Gmail, Squirrelmail etc eigenlijk net zo belangrijk.

Ja, HTML in mail is erg belangrijk... voor spammers.

Ik snap het nog steeds niet waarom mensen HTML in mail willen. Degenen die hier het meeste gebruik(misbruik) van maken, zijn spammers. Men wil uitgebreide ondersteuning van HTML in mail programma's, lieft met Javascript en al, en tegelijkertijd loopt men te klagen over spam en spamfilters die spam doorlaten.

[apokalypse]

Nou... Geweldig, als ik dit lees denk ik in m'n achterhoofd al "O nee, het is toch niet waar he". Javascript, wat is dat nu weer voor stomme halve work-around. Ik begrijp het zelf niet helemaal wat ze daar nu weer mee bedoelen.

ik denk zoiets als dit:
http://dean.edwards.name/IE7/

maar mooi toch? javascript is meestal langzamer, en dus wordt dan IE langzamer => meer marktaandeel firefox & opera


maar mooi nieuws dit. Nu snel HTML5, want ik vind HTML4 echt lelijk (bv textarea en input....dotNet heeft niet voor niets webcontrols )

[TheekAzzaBreek]

Het betekent dat als MS het niet inbouwt, de ontwerper van de site de ondersteuning toe kan voegen. Vind ik eigenlijk wel een stoer plan.

[Verwijderd]

Tja, en dan zijn we weer terug bij af; kunnen we straks weer voor ieder browser(versie) een workaround inbouwen om een site fatsoenlijk te tonen.

Voordat je roept "dan gebruik je toch geen IE",... ja, ik als ontwerper/programmeur misschien niet, maar als ik momenteel naar de bezoekers van mijn sites kijk dan gebruiken die voor meer dan 70% IE.

[Ragger]

Mooi, duidelijkheid. De wazige status van XHTML is tamelijk irritant. Ik hoop dat we nu verder kunnen. Ik ben alleen benieuwd hoe lang zoiets gaat duren. Wanneer mag ik mijn sites ombouwen naar de nieuwe standaard?

edit: Interessante faq: http://blog.whatwg.org/faq/

[Verwijderd]

Goede ontwikkeling. Alleen dan nu de vraag wordt het goed ondersteund door browsers? En hoe snel?
Overigens vraag ik mij wel af wat er voor nieuwe mogelijkheden HTML 5 gaat bieden...

[Verwijderd]

Nieuwe HTML codes zijn vrij gemakkelijk te ondersteunen. De meeste tags 'doen' namelijk van zichzelf niet zo heel veel (forms uitgezonderd). De reden dat browsers zo crappy zijn is niet omdat ze HTML niet snappen, maar omdat de CSS support buggy is.

Hiermee wil ik niet beweren dat nieuwe HTML tags supporten een compleet triviaal iets is, maar vergelijken met goede CSS support is het in ieder geval vele malen simpeler te implementeren.

[Verwijderd]

Apple, Opera en Mozilla zitten in de werkgroep, zij zullen het dus zeker inbouwen in hun browsers en waarschijnlijk zo snel mogelijk omdat het er op hun vraag komt. De grootste speler (MS met zijn IE) is meestal wel traag met dit soort ontwikkelingen maar we zullen zien...

[Genoil]

Hier staat een nette opsomming van de verschillen tov HTML4:
http://wiki.whatwg.org/wiki/Changes_from_HTML4

[humbug]

Hoezo duidelijk? Een groepje bedrijven die samen nog geen 25% van de markt in handen hebben besluiten iets tot een "standaard" te benoemen zonder ook maar samen te willen werken met het bedrijf wat 75% van de markt in handen heeft.

Het is duidelijk dat er op deze wijze enkel standaarden komen die weer niet werken op de meest gebruikte browser. Maar ik denk niet dat je die vorm van duidelijkheid bedoeld.....

[rickmans]

Microsoft is ook aanwezig in de workinggroup, bij mijn weten ook in de chair zelfs.

[Xenan]

Dat zegt niets. Microsoft was ook aanwezig in de CCS werkgroepen.

[killercow]

TJah,

volkswagen, toyota en opel hebben bij elkaar ook 70% marktaandeel, wil dat zeggen dat mercedes en bmw niet over mogen stappen naar waterstof motors omdat zij niet toon-aangevend zijn?

[highking]

Dat is helaas geen vergelijk...
Zie het meer als een nieuw type wegdek, dat eerst door alle bandenfabrikanten ondersteund zal moeten worden, voor je erop kunt rijden...

Hmm, wat als de grootste bandenfabrikant dit wegdek nu niet zal ondersteunen? En daarmee bijvoorbeeld een groot deel van de nieuwe en bestaande auto's niet op dat wegdek kunnen rijden?
Zal dat nieuwe type wegdek erg populair worden dan?

Maar we hopen natuurlijk op het beste

[mae-t.net]

Standaarden zijn gelukkig vaak op inhoud gebaseerd, niet op wie het hardste kan schreeuwen.

[Mei]

True, maar het gebruik ervan wordt toch helaas deels bepaald door de hardste schreeuwer. Kijk maar eens wat je aan CSS niet kan gebruiken, doordat de grootste schreeuwer (Microsoft) het IE niet laat ondersteunen.

[crisp]

Ten eerst is Microsoft zelf wel degelijk actief in de W3 HTML WG, Microsoft's IE development manager Chris Wilson is zelfs mede-chairman en ten tweede heeft Microsoft al aangegeven HTML 5 te gaan ondersteunen.

Microsoft heeft enkel 1 groot probleem en dat is de gigantische technische achterstand van IE op andere browsers, en dus zal het tijd kosten om dat in te halen. De vraag is zelfs of ze daarvoor niet beter een nieuwe renderengine 'from scratch' zouden moeten bouwen...

[dmantione]

Je kunt nu al beginnen. Zonder garantie dat het hetzelfde blijft welliswaar, maar je zult versteld staan hoeveel van HTML5 nu al door de Gecko-, KHTML- en Operagebaseerde browsers ondersteund wordt.

[muksie]

HTML 5 is being developed with IE compatibility in mind. Support for many features can be simulated using JavaScript.

Het zou wel mooi zijn als het W3C dan ook kwam met een eigen officieel javascript bestand die zoveel mogelijk de tekortkomingen van IE met HTML5 oplost, zodat je gewoon met een enkele script-tag je HTML5 valide website compatible maken met IE, en niet dat er overal over het internet stukjes javascript zwerven die bepaalde tekortkomingen van IE oplossen. 't Zal er wel wat trager door worden op IE, maar dat zal Microsoft mogelijk stimuleren om zich aan de standaarden te houden.

[holygame]

Wat is versie 5 beter als die die we nu hebben?

[THEsmiley]

Gepost door AniMatrix - donderdag 10 mei 2007 21:44 Score: 2 (Gemodereerd)
Dan hoop ik heel erg dat Microsoft dit z.s.m. in hun Internet Explorer stopt. En als dat dan eenmaal zo is dat alle gerespecteerde webdesigners meteen alleen in HTML 5 doen. Zou een hoop problemen (en kopzorgen) oplossen

M$ is nog nooit W3C compliant geweest dus verwacht ik dat dus nu ook niet, het bespaard inderdaad kopzorgen maar ik ben bang dat dit niet gaat gebeuren want zo is het altijd gegaan helaas.
Het zou fijn zijn als IE niet als standaard wordt genomen voor ontwikkeling maar er eens naar de toekomst wordt gekeken en we het een keer over formaten ipv producten kunnen hebben, , dat ontbreekt nog een stuk.

[Tijger]

Eh, niemand is W3C compliant omdat de huidige HTML 'standaard' op sommige punten tegenstrijdig is.

[Xenan]

Dat valt wel mee. Noem eens concrete, real-world tegenstrijdigheden in de HTML 4.01 specificatie?

[crisp]

Ik zou het niet tegenstrijdig noemen, eerder vaag of onvolledig op bepaalde punten.

Ik ken overig wel wat voorbeelden van echte tegenstrijdigheden maar dat zijn over het algemeen geen real-wordl issues aangezien geen enkele browser HTML naar de letter van de specificatie (en dus als SGML-applicatie) heeft geimplementeerd

[deviltje]

De reden voor (x)html 5 is niet zo zeer websites.. Deze zullen wel onderdelen gaan gebruiken, maar een gewone informatieve website blijft het ook goed doen in html4.01

The World Wide Web's markup language has always been HTML. HTML was primarily designed as a language for semantically describing scientific documents, although its general design and adaptations over the years has enabled it to be used to describe a number of other types of documents.

The main area that has not been adequately addressed by HTML is a vague subject referred to as Web Applications. This specification attempts to rectify this, while at the same time updating the HTML specifications to address issues raised in the past few years.

dus vooral het toevoegen van tree's, menu's wysiwyg editor en betere formulier mogelijkheden zijn onderdeel van (x)html5

source

[Verwijderd]

Wat mij opvalt is dat ze idd menu en datagrid elementen hebben toegevoegd. Dat lijkt me handig, net als een draggable attribuut. Maar als je dat zo doet, waar is dan het tree element, of het dopzone attribuut? Ik vraag mij dus af: waar trek je de grens? Je kunt nooit alle applicaties afvangen met speciale elementen. Dat is de reden voor de WebControls in ASP.NET. Er zijn er een hoop, en anders maak je ze zelf (custom controls) en ze renderen uiteindelijk HTML dat zich gedraagt als {vul je gewenste interface element in}.

Wat op mij héél knullig overkomt is dat HTML5 ook een small element toevoegt. Ik dacht dat we er nu wel over uit wraen dat we vorm uit de HTML laten?

[crisp]

Ten eerste voegt HTML 5 geen small-element toe, die bestaat immers ook in HTML 4.01 en is zelfs in Strict niet deprecated, maar herdefinieren ze het element omdat het in sommige gevallen toch met zekere semantiek gebruikt wordt - namelijk als tegenhanger van strong/em om aan te geven dat iets juist minder nadruk heeft

[fevenhuis]

En een briljant eerste besluit is het inderdaad om de nieuwe HTML voortaan HTML te noemen.