Hoofdcategorieën

[RSS] Index » Nieuws » Pro » Development » Internet » W3C schaart zich achter html 5-specificatie

W3C schaart zich achter html 5-specificatie

Door Pieter Molenaar, dinsdag 22 januari 2008 13:23, views: 14.398

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.

W3C (World Wide Web Consortium) logo nieuw zonder lettersDe 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.

Volgende 14:02
Vorige 12:48

Categorieën

Gerelateerde artikelen

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 100 reacties zichtbaar1000 Neutraal: 92 reacties zichtbaar92+1 Meerwaarde: 27 reacties zichtbaar27+2 Verplicht leesvoer: 2 reacties zichtbaar2
«  1  2  »

Door bramvp, dinsdag 22 januari 2008 17:39

Score: 0
Moeten niet eerst de browsers worden gëupdate om die nieuwigheden te gebruiken?

Door Franckey, dinsdag 22 januari 2008 23:28

Score: 0
Wat denk je zelf... Het feit dat er een waterstof motor is uitgevonden wil niet zeggen dat ik opeens water in m'n benzinetank kan gooien... :+

Door Markicks, dinsdag 22 januari 2008 13:32

Score: 0
Is ook niet een valid element. Als je center tags gebruikt, krijg je op z'n minst een waarschuwing dat je het anders op moet lossen. Via CSS dus, CSS is heerlijk! :D

Door YopY, dinsdag 22 januari 2008 14:49

Score: 0
...zolang het werkt. De CSS standaard is beter in termen van opmaak dan de oude manier van website opmaak, nu de goede ondersteuning en weergave van alle grote browsers nog.

Door HyperBart, dinsdag 22 januari 2008 15:07

Score: 0
Je bedoeld eigenlijk alleen Internet Explorer.

Mozilla volgt zoveel mogelijk de beste guidelines van alle consortia en raadgevers

MS veegt namelijk met IE zijn voeten aan die regels, wat ze op een bepaalde manier ook niet kwalijk genomen kan worden, ze waren tot enkele jaren terug de monopolie-houder van web-browsers, waarom zouden ze in hemelsnaam aan standaarden meedoen als zij net de standaard zelf zijn.

Met de toenemende populariteit van Opera en vooral Firefox is er een beweging ontstaan. Opera en Firefox zijn de betere browsers die sterk rekening houden met de web-standaarden.

Door Trias, dinsdag 22 januari 2008 16:04

Score: 1
"MS veegt namelijk met IE zijn voeten aan die regels, wat ze op een bepaalde manier ook niet kwalijk genomen kan worden, ze waren tot enkele jaren terug de monopolie-houder van web-browsers, waarom zouden ze in hemelsnaam aan standaarden meedoen als zij net de standaard zelf zijn."

Sorry, hoor, maar. IE veegde zijn voeten met standaarden lang voordat IE de dominante speler op de markt was. Vanaf het begin heeft MS alle mogelijke standaarden tegen gewerkt. Ook in de begin jaren toen Netscape nog een grote jongen was op de browser markt. Juist door af te wijken van de standaarden en iedere nieuwe computer met IE uit te rusten, heeft MS actief geporbeert de defacto standaard te worden en zo een monopoly op de browser markt te vergaren.

Dat kan (en moet) je MS wel degelijk kwalijk nemen, aangezien ze actief hun monopoly positie op de OS markt hebben (misbruikt) om te proberen een monopoly op de browser markt te vergaren. Dit alles over de ruggen van webdevelopers overal ter wereld. De schade (bv. door extra manuren werk voor webdevelopers)die MS hiermee aan de wereld economie heeft toegebracht is niet te schatten, maar loopt minimaal in de miljarden.

Door HyperBart, dinsdag 22 januari 2008 17:22

Score: 1
"MS veegt namelijk met IE zijn voeten aan die regels, wat ze op een bepaalde manier ook niet kwalijk genomen kan worden, ze waren tot enkele jaren terug de monopolie-houder van web-browsers, waarom zouden ze in hemelsnaam aan standaarden meedoen als zij net de standaard zelf zijn."
Sorry, hoor, maar. IE veegde zijn voeten met standaarden lang voordat IE de dominante speler op de markt was. Vanaf het begin heeft MS alle mogelijke standaarden tegen gewerkt. Ook in de begin jaren toen Netscape nog een grote jongen was op de browser markt. Juist door af te wijken van de standaarden en iedere nieuwe computer met IE uit te rusten, heeft MS actief geporbeert de defacto standaard te worden en zo een monopoly op de browser markt te vergaren.
Niet zo aggressief uit de hoek komen of je verontschuldigen hoor, ik neem het MS ook kwalijk.


Maarre, hoe zou je zelf zijn als bedrijf en schrik hebt voor weggeduwd te zijn, daarom dan ook: bepaalde manier....

Verder nog even: zegt de term Ironie jou iets ?

Als je de ironie er dan niet van inziet, vat het dan zo op:
bepaalde manier = heel gesloten, niet openstaan, concurrentie-vermijdend, evolutie en onafhankelijke standaarden tegenhouden om zo hun positie te behouden
Sorry, hoor, maar. IE veegde zijn voeten met standaarden lang voordat IE de dominante speler op de markt was. Vanaf het begin heeft MS alle mogelijke standaarden tegen gewerkt. Ook in de begin jaren toen Netscape nog een grote jongen was op de browser markt. Juist door af te wijken van de standaarden en iedere nieuwe computer met IE uit te rusten, heeft MS actief geporbeert de defacto standaard te worden en zo een monopoly op de browser markt te vergaren.
Dat zeg ik toch ook net ? :?

Je schrijft nu zo je post alsof ik iets verkeerd heb gezegd maar verkondigt eigenlijk net hetzelfde... :X


Verder moet ik ook nog even vermelden dat sinds IE7 het eigenlijk wel sterk verbeterd is, zie hiervoor: http://pro.tweakers.net/n...nieuwe-rendermethode.html
waarbij volgend stuk belangrijk is:
Zo kan een pagina die voldoet aan door IE8 ondersteunde standaarden middels de meta-tag door IE8 gerenderd worden, maar de developer kan er ook voor kiezen een andere IE-versie - of zelfs Firefox - als renderengine te gebruiken.

De keuze voor deze 'versiespecifieke rendering' komt voort uit de problemen die de introductie van Internet Explorer 7 veroorzaakte. Omdat veel webdevelopers rekening hielden met de eigenaardigheden van IE6, werden pagina's voor Internet Explorer en niet volgens W3C-standaarden geschreven. Internet Explorer 7 hield zich een stuk beter aan de W3C-standaarden, waardoor de workarounds die in IE6 een fatsoenlijke pagina opleverden, in de nieuwe browser juist voor extra problemen zorgden.

Aangezien Internet Explorer 8 de standaarden beter volgt dan zijn voorgangers, bestaat de vrees dat een groot aantal webpagina's opnieuw verkeerd gerenderd wordt met de overstap naar IE8. De nieuw geïntroduceerde meta-tag kan dit voorkomen, door aan te geven dat een browser een bepaalde rendering-methode op de pagina moet loslaten. Op deze manier zou zowel de backwards compatibility als het vermogen van pagina's met verschillende browsers te werken gewaarborgd moeten worden.

[Reactie gewijzigd door HyperBart]

Door RM-rf, dinsdag 22 januari 2008 13:35

Score: 0
het was idd zeer simpel en 'begrijpelijk' (TBL ontwikkelde ooit HTML als een zeer toegankelijke en zeer leesbare en daardoor graag gebruikt 'markup-taal'... alhoewel de CENTER daar net wer niet bijzat, FONT, B en I wél: http://www.w3.org/History...xt/WWW/MarkUp/MarkUp.html) maar hierdoor ontstond een ongewenste vermenging van content en visuele formatting..
die juist erg verwarrende en bloated code tot resultaat had.
Het eerste doel van HTML is het om informatie-structuren te 'organiseren' in 'vaste verwerkbare brokken'.

Door visuele formatting en structuur-code te scheiden is je HTML veel flexibeler, meer geschikt voor verschillende output-media en heeft het onderhoud ook veel voordelen

je kunt overigens nog steeds gewoon de HTML4.01 transitional doctype blijven benutten, als je zo hangt aan die werkwijze met van die 'visuele format beschrijvende tags', al zijn ze al héél lang 'deprecatdd' dus worden streng afgeraden.

[Reactie gewijzigd door RM-rf]

Door darkjeric, dinsdag 22 januari 2008 13:32

Score: 0
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.

Door OddesE, dinsdag 22 januari 2008 13:39

Score: 0
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.

Door GoofyIdiot, dinsdag 22 januari 2008 13:40

Score: 0
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.

Door CyberSnooP, dinsdag 22 januari 2008 13:44

Score: 0
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

Door RM-rf, dinsdag 22 januari 2008 13:45

Score: 1
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.

Door OddesE, dinsdag 22 januari 2008 13:54

Score: 0
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.

Door Toolskyn, dinsdag 22 januari 2008 14:25

Score: 1
'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).

Door RM-rf, dinsdag 22 januari 2008 14:30

Score: 0
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]

Door J.J.J. Bokma, dinsdag 22 januari 2008 17:12

Score: 0
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.

Door zenlord, dinsdag 22 januari 2008 14:54

Score: 0
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...

Door GrimaceODespair, dinsdag 22 januari 2008 13:33

Score: 0
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.

Door :murb:, dinsdag 22 januari 2008 14:00

Score: 0
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.

Door Toolskyn, dinsdag 22 januari 2008 14:17

Score: 0
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.

Door Mei, dinsdag 22 januari 2008 14:53

Score: 1
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.

Door latka, dinsdag 22 januari 2008 17:23

Score: 0
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?

Door Jan Groothuijse, dinsdag 22 januari 2008 13:35

Score: 0
Dit klinkt beter dan ik het verwacht, wat longtime overdue gemissen die nu toch ingevult worden, waaronder standaard audio en video.

Door Zyppora, dinsdag 22 januari 2008 13:36

Score: 0
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).

Door jvdmeer, dinsdag 22 januari 2008 13:48

Score: 0
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.

Door lapalazala, dinsdag 22 januari 2008 14:17

Score: 0
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.

Door ritsjoena, dinsdag 22 januari 2008 14:27

Score: 1
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.

Door YopY, dinsdag 22 januari 2008 14:53

Score: 0
Dit betekent meer marktaandeel voor de commerciële formaten.
...indien die wel in de specificatie / standaard komen, kthx.

Door Jaap-Jan, dinsdag 22 januari 2008 14:55

Score: 0
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:
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]

Door Dreamvoid, dinsdag 22 januari 2008 14:33

Score: 1
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.

Door Jaap-Jan, dinsdag 22 januari 2008 15:12

Score: 1
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.

Door Marientjuh, dinsdag 22 januari 2008 13:36

Score: 0
Dit is naar mijn mening erg goed nieuws voor de web ontwikkelaars. Zoals deze specificatie eruit ziet lijkt het dat het de gaten gaat oplossen in de huidige html standaarden.

Van mij mag dit al gister ingevoerd zijn.

Door Fuzzillogic, dinsdag 22 januari 2008 14:29

Score: 0
Naar mijn mening is het een zwarte dag. Komende jaren zitten we nog steeds vast aan SGML-drek. En qua webapps slaan ze de plank echt compleet finaal totaal enorm mis, door geen XML te gebruiken, en geen broodnodige GUI-platform te maken.

Ik kan er niks anders van maken dan "BELACHELIJK".

Door Mei, dinsdag 22 januari 2008 14:56

Score: 0
GUI platform? HTML is een structuurtaal en dat heeft niks te maken met hoe de content gepresenteerd wordt, daar is CSS voor.

Maar je kan het ook anders zeggen: 'De beste stuurlui staan aan wal'. Als jij die features er zo graag had in gewild, had je mee moeten doen met de ontwikkeling. Kort door de bocht, maar die mogelijkheid was er.

Door Fuzzillogic, dinsdag 22 januari 2008 15:16

Score: 0
Jaja, GUI hoort niet thuis in een text markup-language. Forms dan wel? Punt is dat ze eventuele uitbreiding met een GUI ML nu eigenlijk haast onmogelijk hebben gemaakt.

En je tweede opmerking is natuurlijk wel weer heel suf.

Door Mei, dinsdag 22 januari 2008 16:20

Score: 0
Formulieren zijn puur functioneel. Mensen met tekstbrowsers kunnen ze bijvoorbeeld ook gebruiken. Een GUI is volledig gericht op het grafische gedeelte en hoort dus niet in een markuplanguage thuis.

En die tweee opmerking is niet heel suf. Als jij vind dat het niet goed is, dan had je mee moeten doen met de ontwikkeling. Dat het tegenvalt kan gebeuren, maar als je gaat zeuren dat het "BELACHELIJK" is, dan is zo'n opmerking als de mijne gerechtvaardigd.

Door Fuzzillogic, dinsdag 22 januari 2008 17:24

Score: 0
GUI is net zo goed functioneel, en heeft niks te maken met het uiterlijk. Als een GUI in een aparte namespace hoort (en dat hoort het), dan formulieren ook. Formulieren zijn immers geen tekst.

De W3C heeft bijzonder veel invloed op de ontwikkeling van het web (duh) en daarmee op het werk van alle webdevvers. M.i. negeren ze een hele grote groep webdevvers nu, die zich bezig houdt met het maken van web applicaties - dus met toolbars, tab panels, sliders etc etc. Dat vind ik toch echt belachelijk.

Door crisp, dinsdag 22 januari 2008 15:34

Score: 0
HTML5 is geen SGML-implementatie maar beschrijft, naast de XML-serialisatie, een eigen serialisatie die compatible is met hoe browsers hedentendage omgaan met HTML (ook niet als SGML implementatie - tevens ook de reden waarom XHTML(1.x) als text/html 'werkt').

Verder is XML op het web een mislukte hype want verkeerd toegepast en in 99% van de gevallen ook overbodig.

Door DiSiLLUSiON, woensdag 23 januari 2008 04:47

Score: 0
GUI Platform?

Probeer Mozilla XUL eens. Helaas is het proprietary technologie, dus verwacht niet dat het werkt in IE. Je kunt natuurlijk wel een parser schrijven die de XUL tags omzet naar tags die compatible zijn met Backbase, Ext-JS, Dijit of andersoortige JS widget libraries.

[Reactie gewijzigd door DiSiLLUSiON]

Door OddesE, dinsdag 22 januari 2008 13:43

Score: 0
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]

Door Maghiel, dinsdag 22 januari 2008 13:44

Score: 0
font tags vond ik juist zo handig, omdat ik daarmee duidelijk een aparte font stijl kan aangeven, die dan wel weer in css geregeld wordt.

Door Marientjuh, dinsdag 22 januari 2008 13:47

Score: 0
Dit is ook mogelijk met de span tags en die stylen met css

Door Maghiel, dinsdag 22 januari 2008 13:52

Score: 0
ja maar span gebruik ik liever om bijvoorbeeld afbeeldingen of slogans neer te zetten.
en font puur voor een stukje tekst.

[Reactie gewijzigd door Maghiel]

Door progster, dinsdag 22 januari 2008 14:02

Score: 0
dat slaagt nie op veel eerlijk gezegd, als je ze een ander class name of id geeft is dat toch ook opgelost?

Door Witchhammer, dinsdag 22 januari 2008 14:06

Score: 0
Het gaat er m.i. niet om wat 'fijner' is om te gebruiken, maar wat het correctst is om te gebruiken.
Het is vreemd om een font tag te gebruiken omdat de tag niets vertegenwoordigd behalve een sectie opgemaakte tekst. Opmaak is juist iets wat niet direct in de HTML structuur terug moet komen, daar is CSS voor.

Door darkjeric, dinsdag 22 januari 2008 13:53

Score: 0
Maar waar hij op doelt is dat het duidelijker lezen was dat het een font betrof (bv. om één woord in een div/span aan te passen). Nu moet je een tweede div/span openen binnen de al bestaande, wordt er niet gemakkelijker op imho.

Ik vind het zelfs vreemd: aan de ene kant voegt men logische div/span toe met bv. <footer></footer>, maar aan de andere kant haalt men dan logische zaken zoals <font></font> weg, waardoor je toch weer meer abstracte div/span staan hebt...

Misschien hadden ze beter <font> gehouden, en gewoon de opmaakproperties buiten gegooid, zodat je alleen nog name="" of class="" of id="" kon toevoegen.

Door H004, dinsdag 22 januari 2008 14:03

Score: 0
Het verschil tussen <footer> en <font> is dat footer inhoud definieert, en font alleen opmaak definieert. Het eerste is semantisch gewenst, het tweede dient opgelost te worden met css. Om stukken tekst te selecteren en ervan de opmaak aan te passen heb je nu alleen wel semantiekloze elementen nodig, bv <span>. Een goede beslissing dus!

Door Zero Grav, dinsdag 22 januari 2008 14:06

Score: 1
Eigenlijk is het enorm logisch, font wijst op.. wat? Een verandering van het font. Ok, ja, maar wat maakt dat uit? Juist niets eigenlijk. Terwijl nav en footer eigenlijk gewoon verwijzen naar 2 elementen binnen de site, zonder ook maar te hinten dat het over opmaak gaat. Wat alleen maar logisch is als je al ziet dat we nu een head, title en body hebben.

De manier waarop ik het nu zie is dat het de bedeling is een span met bijvoorbeeld een class="nadruk" te zetten om tekst aan te duiden die zonder de css niet speciaal belangrijk is. Maar dat de em en strong tags dan gebruikt moeten worden om tekst aan te duiden die ook zonder de css belangrijk is en extra aangeduid dient te worden. Alleen spreken ze dan over het uitfaseren van de strong en em tags, wat ik dus onbegrijpelijk vind.

Edit: Ik begrijp trouwens niet wat je bedoelt met die slogan en afbeeldingen. Een slogan kan je beter in een paragraaf gooien (komt er beter uit als je de style wegneemt) en voor afbeeldingen heb je gewoon de image tag, centreren van afbeeldingen doe ik over het algemeen met een extra div.

[Reactie gewijzigd door Zero Grav]

Door Maghiel, dinsdag 22 januari 2008 14:08

Score: 0
ik vind het dus een stuk duidelijk om neer te zetten <font class="error"> ipv <span class="fontError"> ofzo.

Door Zero Grav, dinsdag 22 januari 2008 14:19

Score: 0
Ik zie wel welke kant je uit wilt, maar hier gaan we het toch niet over eens worden. :p
Wat je ook wel moet beseffen is dat de manier waarop jij een font element in html wilt introduceren het element exact hetzelfde maakt als een span.

Je noemt die span nu ook "fontError", maar uiteindelijk kan je ze evenzeer "error" noemen en dan is er amper verschil met de font tag, alleen is het - in mijn ogen - logischer.

Door DOT, dinsdag 22 januari 2008 14:20

Score: 0
Dan gebruik je dus <span class="error">. Waarom zou je jezelf dwingen om een error met een lettertype-verschil aan te duiden? Over een maand heb je misschien liever een kleurtje, een kader, of een achtergrond-afbeelding.

Door lapalazala, dinsdag 22 januari 2008 14:27

Score: 0
Precies! Ik geef toe dat ik meestal de b tag gebruik voor vette (lees: benadrukte) tekst, maar dat zou eigenlijk strong of em moeten zijn, waarna je in de CSS regelt hoe die nadruk dan gevisualiseerd moet worden.
Dat past precies binnen het straatje van meer semantiek en minder opmaak in je HTML, waar dus ook het uitfaseren van de font tag bij hoort.

Dus als het klopt dat ze em en strong willen uitfaseren, maken ze volgens mij een grote fout. Kiezen voor een van de twee zou misschien wel slim zijn, ik begrijp het semantische verschil in ieder geval niet.

Door DOT, dinsdag 22 januari 2008 14:42

Score: 0
Ik denk dat de redenatie daarachter is dat "strong", of "emphasized" nog niet zoveel zegt. Waarom is iets nou strong/emphasized? Maar ik zou voor de italics die ik net gebruikte eigenlijk geen specifiekere reden weten dan dat het in spreektaal de nadruk heeft. Daar zou een <strong> of een <em> dus voor moeten worden toegepast, en nergens anders! ;)

Door DOT, dinsdag 22 januari 2008 14:09

Score: 0
Een <font> geeft geen betekenis aan je document. Je kan zowel je navigatie (<nav>), alinea's (<p>) als je footer (<footer>) het lettertype sans-serif geven, maar je kan niet aan een bepaald lettertype zien wat voor een betekenis dat deel van het document heeft.

Dat is het principe van scheiden van betekenis (semantiek/markup) en uiterlijk (opmaak).

Want wat ga je doen met de volgende html...

<p>Ik vond <font class="movie">The Matrix</font> een coole film!</p>

...als je het uiterlijk van films wilt veranderen van Arial naar een andere achtergrondkleur? Op dat moment heeft het niets meer te maken met lettertypes, en moet je eigenlijk je markup veranderen naar een <span>. En je wilt juist je markup constant maken (want dat bouw je in in je framework), en je css variabel.

[Reactie gewijzigd door DOT]

Door YopY, dinsdag 22 januari 2008 14:56

Score: 0
Semantisch zou je denken dat in een <font>-tag een aanduiding komt van een lettertype (met evt kleur en dergelijke). In goed XHTML heb je daar <span> voor, maar daar kan ik me nog minder bij voorstellen. Ik zou liever een <text> tag oid willen hebben.

Door TeeDee, dinsdag 22 januari 2008 13:53

Score: 1
Het nut van XHTML is voor mij nog nooit echt duidelijk geweest. Persoonlijk maak ik praktisch alle websites / webapplicaties in HTML 4.01 strict. (Ook de muk uit Visual Studio :))

Wat betreft HTML 5 ben ik erg benieuwd naar de nieuwe elementen, welke de semantiek van een document nog verder uitwerken. Denk aan header, article, footer etc. Nu zie je dat dit vaak met het (in feite) nietszeggende DIV opgelost wordt.

Nu wordt natuurlijk de grote vraag of IE8 met de nieuwe, naast Trident, aanpassingen. ook mee gaat.

Laten we nu niet hopen dat de voorspellingen uitkomen.

Als alles meezit is binnenkort IE 6 geschiedenis en hoeven we alleen nog maar rekening te houden met IE 7 en/of IE8. Mocht IE8 de Trident engine ongewijzigd van IE7 gebruiken dan wordt het leven van webdevelopers een stuk makkelijker.
So if anything, I'd hazard a guess and say that IE8 will head back into ProprietaryLand - leaving Firefox to become more of a vehicle for independent web services, particularly those from Google. While IE7 and Firefox 2 were more alike than different (feature-wise they're practically identical!), with IE8 and FF3 we will likely see the two biggest browsers head off into different directions.

[Reactie gewijzigd door TeeDee]

Door Little Penguin, dinsdag 22 januari 2008 14:18

Score: 1
Het nut van XHTML is voor mij nog nooit echt duidelijk geweest.
Het nut van XHTML is dat het gebaseerd is op XML en dus via XML-namespaces gemixed kan worden met andere talen die op XHTML gebaseerd zijn (te denken is aan o.a. SVG en MathML).

Met HTML is zo'n mix niet mogelijk omdat SGML dat niet toestaat.

De makers van HTML5 weten dit ook en hebben daarom naast een HTML5 serialisatie ook een serialisatie van HTML5 naar XML gespecificeerd...

Door TeeDee, dinsdag 22 januari 2008 14:25

Score: 0
De definitie van XHTML ken ik wel, alleen voor mij is 't nooit duidelijk geweest. Als in: in mijn professionele loopbaan heb ik het in ieder geval nog nooit nodig gehad.
«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 14:02
Vorige 12:48
VNU Media logo Powered by True

© 1998 - 2008 Tweakers.net - Alle rechten voorbehouden

Uitgever van: