Hoofdcategorieën

[RSS] Index » Nieuws » Pro » Internet » Voorstel voor HTML 5 ingediend bij W3C

Voorstel voor HTML 5 ingediend bij W3C

Door Olaf van Miltenburg, donderdag 12 april 2007 17:39
Bron: Ajaxian, submitter: Ramon, views: 21.127

Mozilla, Opera en Apple hebben de W3C voorgesteld HTML 5 als basis te nemen voor de verdere ontwikkeling van html. De drie bedrijven hebben in een werkgroep jarenlang aan de update van de html-specificatie gewerkt.

WHATWG logo groterDe Web Hypertext Application Technology Working Group is in 2004 ingesteld uit onvrede over de trage ontwikkeling van html. W3C moet die ontwikkeling in goede banen leiden en dacht dat te doen door xhtml voor te stellen als opvolger van html. Deze taal is vergelijkbaar met html, maar gebaseerd op xml. Xhtml kent een aantal grote nadelen; zo is de taal niet volledig backwards compatibel en wordt xhtml niet ondersteund door Internet Explorer. Een ander probleem volgt uit het feit dat de verwerking van xml stokt zodra er een fout in de syntaxis voorkomt. De meeste xhtml-pagina's die er zijn laten zich daarom als html-documenten verwerken door browsers. Ondanks dat dit misvormde html oplevert, kunnen browsers ermee overweg omdat ze html als tag-soup verwerken: ze proberen er het beste van te maken.

Op dit moment handelt iedere browser invalide html op eigen wijze af, maar daar moet HTML 5, ook wel Web Applications 1.0 genoemd, een einde aan maken door standaardregels op te leggen voor de verwerking van misvormde html. HTML 5 stapt mede daarom voor een deel af van de sgml-onderlaag van html. Daarnaast specificeert HTML 5 een aantal api's en opmaakelementen die in de praktijk al gebruikt worden en wordt nieuwe functionaliteit gedefinieerd, zoals de elementen 'canvas', 'article' en 'section'.

De Whatwg stelt concreet aan het W3C voor dat hun HTML 5 de basis vormt voor de verdere evolutie van html-afspraken, dat het consortium officieel de naam 'HTML 5' adopteert en dat Ian Hickson van de werkgroep bijdraagt aan de verdere uitwerking van de specificatie. Het wekt geen verwondering dat de drie bedrijven nu met hun voorstel komen: begin maart nodigde de W3C geïnteresseerden uit om toch aan de huidige html-specificatie verder te werken in de recent opgerichte html-werkgroep.

Volgende 20:07
Vorige 16:36

Categorieën

Gerelateerde artikelen

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 94 reacties zichtbaar940 Neutraal: 94 reacties zichtbaar94+1 Meerwaarde: 34 reacties zichtbaar34+2 Verplicht leesvoer: 13 reacties zichtbaar13
«  1  2  »

Door alex3305, donderdag 12 april 2007 17:44

Score: 1
Dit zou een goede ontwikkeling zijn ten behoeven van het programmeren of scripten in 'internettalen'.

Het grote nadeel is nu, als door het artikel al wordt aangegeven, dat XHTML niet goed verwerkt wordt door Internet Explorer. Als je die namelijk puur XHTML aanleverd, gaat deze een foutmelding geven, terwijl de pagina het wel goed doet in andere browsers.

Je zou kunnen zeggen dat je dan IE kunt buitensluiten, maar echter is dit geen reële oplossing. IE gebruikers stappen namelijk vaak niet over vanwege het gemak en veel mensen haken daardoor af en zullen je site niet bezoeken.

Het is dus goed dat er nu een goede standaard wordt opgesteld, en ik denk ook dat het W3C hier binnen niet al te lange tijd een positief besluit over moet maken!

Door bavanandel, donderdag 12 april 2007 18:04

Score: 1
Het is dus goed dat er nu een goede standaard wordt opgesteld, en ik denk ook dat het W3C hier binnen niet al te lange tijd een positief besluit over moet maken!
En deed het W3C dat in het verleden al niet? (X)HTML en CSS 1/2/3 zijn ook webstandaarden, waar helaas verschillende browsers anders mee omspringen (met name IE lapt nogal wat aan z'n laars).

Zo'n nieuwe standaard is een leuk idee, maar je zit nog steeds met hetzelfde probleem dat browserbouwers er zich ook aan zullen gaan moeten houden, doen ze dat niet, dan ben je nog steeds op hetzelfde punt als waar we nu al zijn.

Door alex3305, donderdag 12 april 2007 18:14

Score: 1
Het voordeel nu is echter dat Mozilla, Opera en Apple (Safari, KHTML) samenwerken, waardus eerder een goede standaard voor ontwikkeld kan worden.

Dat Microsoft deze regels niet altijd naleefd weten we gewoon, hier kunnen we echter ook bar weinig aan doen IMHO.

EDIT:
Overigens moeten de CSS standaarden ook een keer goed nagekeken worden, niet alleen IE lapt hier veel aan zijn laars, maar ook Mozilla, Opera en Apple doen dit...

Door FuzzyLogic66, donderdag 12 april 2007 19:45

Score: 1
Nou, ik denk het niet. Want Opera, Apple en Mozilla hebben minder dan 30% van de markt, dus betekent het dat ruim 70% van de markt voor Microsoft is. En als Microsoft zich niets om de afspraken geeft, dan kun je het fluiten met die nieuwe afspraken.

Je kunt wel een nieuwe standaard maken, maar als vervolgens 70% van de markt je site daarom niet goed kan bekijken dan ga je het natuurlijk niet gebruiken...

Door dtech, donderdag 12 april 2007 20:35

Score: 0
Mozilla doet dit idd ook, maar dat moet opgelost zijn met Firefox 3. Apple (Safari) en Opera houden zich al een tijd verregaand aan de standaard, getuige de ACID2 test. Deze test vereis een bijna 100% naleving van de CSS2 standaard (inc foutafhandeling in ingewikkelde situaties). Opera slaagt sinds versie 9 voor de test, Safari slaagt al iets langer (op een scrollbalkje na geloof ik)

Door Not Pingu, donderdag 12 april 2007 21:53

Score: 0
En als Microsoft zich niets om de afspraken geeft, dan kun je het fluiten met die nieuwe afspraken.
Maar Microsoft heeft de laatste jaren veel meer oog voor standaarden en goede implementatie daarvan. Hun goede bedoelingen worden op het gebied van reeds in gebruik zijnde HTML smaken dan lang niet altijd waargemaakt (zie ook het lopende topic op GoT) maar een volgende HTML versie zou voor Microsoft een uitgelezen kans zijn om als het ware met een schone lei te beginnen zonder de backwards compatibility te verliezen.

Door humbug, zaterdag 14 april 2007 12:31

Score: 0
Alleen jammer dat Microsoft zich (nog?) niet heeft aangesloten bij dit initiatief. Elke poging om tot een goede webstandaard te komen lijkt te stranden op het feit dat Microsoft steeds de grote afwezige is bij het tot stand komen van de standaard. Ook nu dus weer.

Blijkbaar ziet Microsoft er niets in, of wordt Microsoft bewust buiten de ontwikkeling gehouden. In beide situaties kun je niet verwachten dat Microsoft HTML 5 gewoon zonder wijzigingen gaat invoeren.

Door tjerkw, donderdag 12 april 2007 20:12

Score: 2
Jij snapt het echt dus volkomen niet..

Ook wat er in het artikel staat klopt niet, ik citeer:


Xhtml kent een aantal grote nadelen; zo is de taal niet volledig backwards compatibel en wordt xhtml niet ondersteund door Internet Explorer


Dus een nadeel van XHTML is dat het niet wordt ondersteunt door Internet Explorer.... Sorry maar WTF!!
Dat is geen nadeel van XHTML, dat is een nadeel van Internet Explorer:
Internet Explorer ondersteunt XHTML niet, en niet andersom. XHTML is namelijk een specificatie waarin de browser-implementaties moeten voldoen...

Trouwens ik ben tegen HTML 5.0. XHTML is een zeer goede specificatie en heel duidelijk. Ook XML als basis geeft vele voordelen.. (bv XML Databases, XSL etc etfc)

Serieus de meeste mensen weten niet waar ze het over hebben

Door mrbartjens, donderdag 12 april 2007 21:29

Score: 1
Ja, dat is natuurlijk een nadeel van Internet Explorer, maar in de realiteit zitten we er mooi mee omdat nog steeds het overgrote deel van de mensen IE gebruikt. Dan moet je pragmatisch denken en niet religieus vasthouden aan een standaard die niet ondersteund wordt omdat je daarmee toch geen stap verder komt.

Wist je trouwens dat de WHATWG ook XHTML 5 ontwikkelt? Precies hetzelfde als HTML 5, maar dan met XML-syntax. Fijn, hè :7 Als je gaat beweren dat mensen niet weten waar ze het over hebben is het altijd handig je eerst even in te lezen.

Door tjerkw, vrijdag 13 april 2007 11:21

Score: 0
Ok ik kwam er iets later achter dat ze ook XML omarmen, maar dan nog: Waarom nog een standaard. XHTML 2.0 moet de toekomst worden.

Dit alles is niet echt goed voor het web.

Ik zeg: we moeten een offensief tegen MSIE beginnen. die MSIE 7.0 is ook zo brak als het maar kan.

Wat ik heb gehoord (op slashdot.org gelezen) is dat MSIE wordt gebruikt in veel MS applicaties als bijvoorbeeld Explorer. Als je daar bijvoorbeeld op een map klikt wordt er eigenlijk gewoon een DOM gegenereerd en rechts weergegeven in een MSIE engine.

Dus MSIE zit gewoon gebakken in de OS; MS KAN gewoon MSIE neit aanpassen omdat veel applicaties dan niet meer werken (Outlook, Verkenner, en ja volgens mij zelfs je bureaublad)

Door 2playgames, vrijdag 13 april 2007 22:57

Score: 0
vergeet het startmenu niet :+

Door Rvanlaak, maandag 16 april 2007 22:52

Score: 0
Uh.. Outlook maakt gebruik van de Word engine! Ik weet het, ik ben er ook niet blij mee

Door EvilB2k, donderdag 12 april 2007 21:31

Score: 0
Dat kan je ook van jou zeggen?

Je onderschat wellicht het aantal gebruikers dat IE nog steeds heeft. Niet iedereen gebruikt Firefox, Opera of Safari. Samen met IE sluit je tegelijkertijd een enorme groep potentiele visitors uit, wat niet echt handig is vanuit een 'bezoekers-aantal-technisch' oogpunt.

Door tjerkw, vrijdag 13 april 2007 11:13

Score: 0
Nee ik weet heel goed dat er veel gebruikers met IE zijn, maar er moet gewoon druk op MS worden uitgeoefend zodat ze ook voldoen aan de standaard.

Ik erger me nu gewoon dood aan MSIE.

Door Punkie, vrijdag 13 april 2007 10:02

Score: 0
Vandale:
stan·daard2 (bn.)
1 als regel, normaal => gewoon

Xhtml wordt niet ondersteunt door IE en is dus niet gewoon, de regel en is dus geen standaard. Hoe goed het verder ook mag zijn, het grote nadeel is een groot nadeel dat het niet de standaard is.

Dat html5 WEL ondersteunt zal worden in IE heeft een betere kans en dat zou tot gevolg hebben dat alle browsers WEL gelijkvormiger worden wat dan weer positief is voor de consumenten.

Door mae-t.net, vrijdag 13 april 2007 11:13

Score: 0
Even wat doorgeredeneerd op de betekenis van gewoon: dit betekent dat het door de meerderheid van browsers wordt ondersteund. (vergelijk Engels: common -> in common). Dat is met XHTML natuurlijk gewoon zo. IE is maar 1 browser, en de browsers die het wel ondersteunen zijn in de meerderheid. Dat ze niet het grootste marktaandeel hebben is een ander verhaal.

Door GJ-tje, vrijdag 13 april 2007 11:13

Score: 0
Trouwens ik ben tegen HTML 5.0. XHTML is een zeer goede specificatie en heel duidelijk. Ook XML als basis geeft vele voordelen.. (bv XML Databases, XSL etc etfc)
Niemand zal je dan ook verplichten om HTML5 te gaan gebruiken... ;)
Xhtml wordt niet ondersteunt door IE en is dus niet gewoon, de regel en is dus geen standaard. Hoe goed het verder ook mag zijn, het grote nadeel is een groot nadeel dat het niet de standaard is.
Wel een beetje raar, om te zeggen dat omdat IE het niet ondersteund, dat het dan geen 'standaard' meer is.

Dat is hetzelfde als een diesel auto hebben, iets anders tanken en verwachten dat je auto gewoon rijd... ;)
Dat html5 WEL ondersteunt zal worden in IE heeft een betere kans en dat zou tot gevolg hebben dat alle browsers WEL gelijkvormiger worden wat dan weer positief is voor de consumenten.
Voor zover ik weet, is HTML5 een soort mix tussen xHTML en HTML 4.1, maar ook hier kan ik er naast liggen, dus ik ga er eigenlijk vanuit dat het niet (goed) zal werken in IE.

Door tjerkw, vrijdag 13 april 2007 11:15

Score: 0
Een standaard op het gebied van de informatica is niet wat jij beweert dat het is. Ik doel op specificaties opgericht door bedrijven / instellingen om er zo voor te zorgen dat iedereen weet wat hij kan verwachten / moet doen.

Dat is een standaard. Dus nee niet wat normaal is. (meestal wordt een standaard door veel bedrijven omarmt.. maarja Micro$oft is weer het buitenbeentje)

Door GJ-tje, vrijdag 13 april 2007 12:13

Score: 0
Een standaard op het gebied van de informatica is niet wat jij beweert dat het is. Ik doel op specificaties opgericht door bedrijven / instellingen om er zo voor te zorgen dat iedereen weet wat hij kan verwachten / moet doen.
Dus omdat Microsoft niet meedoet met de (x)HTML 'standaard', is (x)HTML geen standaard, want zij hebben geen afspraken hieromtrent gemaakt? :?

Dat is mijns inziens ook wel te voorbarig.
Volgens Wikipedia is een standaard (ook) een synoniem voor norm, klopt ook wel, want hoe een standaard / norm 'gemaakt' word maakt natuurlijk niet uit, of het door een instelling is, of door bedrijven, of een combinatie hiervan.

Belangrijkste punt blijft gewoon, dat als er een 'standaard' is (voor zover je hierover kan spreken bij (x)HTML) kan je die toch wel implementeren... ;)

Je kan dus ook als je wil je eigen HTML 'standaard' maken, door zelf een DTD (Doc Type Definition) aan te maken... ;)

Door 2playgames, vrijdag 13 april 2007 23:01

Score: 0
maar zoals tjerkw zegt, het gaat hier over een informatica-standaard. dit is een vastgelegde specificatie van hoe, in dit geval een webpagina, beschreven moet worden. net als een protocol dus

Door denkster, zaterdag 14 april 2007 13:45

Score: 0
Vandale:
stan·daard2 (bn.)
1 als regel, normaal => gewoon

Xhtml wordt niet ondersteund door IE en is dus niet gewoon,
Taal en lezen is niet je sterkste kant, hoop ik? Er staan meer betekenissen in Van Dale. Bij die andere betekenissen is er tenminste één belangrijker in dit verband. Zo werkt een woordenboek, snap je?

Door omixium, vrijdag 13 april 2007 10:16

Score: 0
Ja joepie.. weer een nieuwe standaard waar slechts een deel van de markt zich aan gaat houden.

Wij zijn hier eindelijk zover dat we alle website via XHTML en CSS er hetzelfde kunnen laten uitzien in zowel IE, FF en Opera en ook Valid zijn. Ik hoef geen nieuwe standaard!

Ik hoop wel gewoon dat de huidige vorm van XHTML-parsing blijft bestaan.

Door GJ-tje, vrijdag 13 april 2007 14:55

Score: 0
Ja joepie.. weer een nieuwe standaard waar slechts een deel van de markt zich aan gaat houden.

Wij zijn hier eindelijk zover dat we alle website via XHTML en CSS er hetzelfde kunnen laten uitzien in zowel IE, FF en Opera en ook Valid zijn. Ik hoef geen nieuwe standaard!

Ik hoop wel gewoon dat de huidige vorm van XHTML-parsing blijft bestaan.
Dit heet technologische vooruitgang en is doodnormaal.
Mede door dingen als dit, word het steeds makkelijker om een website in verschillende browsers toch hetzelfde eruit te laten zien mogelijk.

Of werk je nog liever op een 286? ;)

Door Daenney, donderdag 12 april 2007 17:46

Score: 1
Klinkt goed, vooral het standardiseren van het afhandelen van niet valide code is iets waar ik al jaren zit op te wachten,. dan ziet een bogus pagina er tenminste overal bogus uit en niet bogus in FF etc en wel correct in IE, zoiets zou webdevvers ook een stuk bewuster moeten maken.
Als iedereen nu nog eens eenzelfde implementatie van CSS3 zou willen bouwen ben ik helemaal blij.
Verder vind ik XHTML opzich wel prettig, de koppeling met XML stelt je wel in staat veel te doen met dynamische generatie en weergave van feeds e.d en bij XHTML was tenminste duidelijk wat wel en niet mocht, HTML4.01 is een grote soep waar iedereen tussendoor ook nog even zijn eigen tags uitvond of nieuwe arguments bij bestaande tags die de rest van de browsers dan weer niet snapten...
Het W3C moet hier wel even mee gaan opschieten, dan kan iedereen tenminste even opgelucht ademhalen en verder is het gewoon belangrijk dat HTML met de tijd mee evolueert.
Dat IE moeite heeft met XHTML vind ik meer een fout van Microsoft dan van het W3C, MS mag ook eens wat meer tijd in hun browser steken.

Door Little Penguin, donderdag 12 april 2007 18:02

Score: 1
De WHATWG probeert wel te voorkomen dat iedereen zijn eigen tags gaat uitvinden - niet helemaal gelukt als je naar 'canvas' kijkt, maar goed.

Het doel van de WHATWG is juist het opstellen van specificaites die daarna door de browser-fabrikanten geimplementeerd kunnen worden, waarbij backwards compatibiliteit erg belangrijk is - iets dat in de XHTML standaard nooit aanwezig geweest is.

Vanwege de non-support van MS voor XHTML is die backwards compatibiliteit (of beter het ontbreken ervan) het grote struikelblok van XHTML - verder had het idd alleen maar voordelen, omdat XHTML een stuk strakker gespecificeerd was.

Waaruit maar weer blijkt dat het slechts is als een partij een monopolie heeft, de innovatie is er namelijk door afgeremt!!!

Door Blaise, donderdag 12 april 2007 23:36

Score: 1
Ook Apple heeft aangegeven XHTML2 niet te willen steunen:
We declined to participate in the HTML2 Working Group because we think XHTML2 is not an appropriate technology for the web.

Door Kevin.van.Dijk, vrijdag 13 april 2007 14:12

Score: 0
@Blaise: Heb je hier toevallig een link van naar de pagina waar dit staat? Lijkt me wel interessant om te lezen waarom ze geen XHTML2 willen ondersteunen namelijk.
edit:
hmm, ik had natuurlijk ook Google kunnen gebruiken :+
http://www.digital-web.co...nd_the_future_of_the_web/

Door JeroenB, donderdag 12 april 2007 17:56

Score: 2
Regels opstellen voor de verwerking van malformed html is toch eigenlijk een vorm van symptomen bestrijden? Ik bedoel, het probleem is dat de html door veel producenten malformed wordt aangeleverd, niet dat de regels over hoe het moet worden afgehandeld niet bestaan.

Ik begrijp best dat de realiteit nou eenmaal is dat mensen malformed html aanleveren, maar daar is dit ook geen oplossing voor: waarschijnlijk gaan ze bij MS (of ergens anders) die regels dan weer met verschillende nuances of prioriteiten implementeren, waardoor je weer terug bij af bent.

En wat gaan we dan doen? Een standaard verzinnen om te definieren hoe het incorrect toepassen van regels bij incorrecte html moet worden afgehandeld? Dat is een gebed zonder einde.

Door Little Penguin, donderdag 12 april 2007 17:59

Score: 1
Aangezien het web nu eenmaal veel non-standaard HTML sites heeft - met brakke HTML code, is het nu eenmaal noodzakelijk om lenient op te gaan met het parsen van de HTML van die sites.

Door duidelijk te definieren hoe een user-agent deze rommel moet parsen ziet het er in elk geval overal hetzelfde uit.

Dat wil niet zeggen dat je er een rommeltje van moet maken, maar je kunt nu eenmaal niet alle bestaande sites naar een 100% valid SGML/XML parsing model dwingen - helaas...

Door Lukse, donderdag 12 april 2007 18:10

Score: 2
maar je kunt nu eenmaal niet alle bestaande sites naar een 100% valid SGML/XML parsing model dwingen - helaas...
Waarom niet? Valid (X)HTML afdwingen vind ik wel kunnen. Als ik in PHP, ASP, JAVA, ... geen valid code schrijf, werkt mijn programma ook niet. Waarom zou hetzelfde niet voor een website mogen gelden?

Door alex3305, donderdag 12 april 2007 18:20

Score: 1
Iedereen (die een webbrowser) schrijft zou zich dus aan deze regels moeten houden. Gecko (Mozilla), KHTML/Webcore (Apple), Presto (Opera) en alle opensource browsers zullen zich hieraan willen houden. Alleen zal de marktleider, Microsoft, hier niet aan mee werken met hun Internet Explorer.

Microsoft kijkt te veel naar de consument en dat zouden ze niet moeten doen, daarmee bedoel ik dat ze proberen ALLE sites voor iedereen toegankelijk te maken. Echter zouden ze beter moeten kijken naar de ontwikkelaars van websites. Deze maken wel het internet 'mogelijk' en met brakke code (lees: te veel verschillende render mogelijkheden), krijgen deze ook steeds minder zin in het maken van sites.

Door berend_engelbrecht, donderdag 12 april 2007 18:32

Score: 0
De reden is heel simpel:
Xhtml kent een aantal grote nadelen; zo is de taal niet volledig backwards compatibel en wordt xhtml niet ondersteund door Internet Explorer.
Je kan niet de regels veranderen en dan prompt verordonneren dat iedereen zich aan de nieuwe regels houdt. Een webpagina van 10 jaar oud moet leesbaar blijven, net zo als je kan verwachten dat je een boek dat slechts 10 jaar oud is uit de kast kan pakken en zonder problemen kan lezen.

Het feit dat er een versie van de standaard is ingevoerd die niet backward compatible is was een heel domme en ondeskundige move van de W3C destijds, waar we nu de wrange vruchten van plukken. We hebben hier met documenten van doen en daarvoor horen de principes van documentaire duurzaamheid te gelden: een nieuwe versie van een reader hoort altijd zonder problemen documenten die voor een vorige versie gemaakt zijn kunnen lezen, in principe tot in de eeuwigheid. Jammer voor mensen die alles "mooier" willen maken, maar zo werkt het dus niet. En voor als je eeuwig wat lang vindt: begin dan in elk geval maar eens met een periode van 80 jaar te hanteren, dat is heel gebruikelijk in de archiefwereld.

Door JanDM, donderdag 12 april 2007 18:43

Score: 2
Waarom niet? Valid (X)HTML afdwingen vind ik wel kunnen. Als ik in PHP, ASP, JAVA, ... geen valid code schrijf, werkt mijn programma ook niet. Waarom zou hetzelfde niet voor een website mogen gelden?
Er is wel verschil tussen een programmeertaal en een markup-taal. Een foutje in een programmeertaal door de compiler laten rechtzetten kan ernstige gevolgen hebben, maar html word enkel geparst en direct weergegeven, daar is error correctie prima mogelijk :)

Omdat er ergens een klein foutje zit (entity vergeten te encoden bijvoorbeeld) zou je een website uren onbereikbaar kunnen maken. Of stel dat er op een blog iemand iets malformed html kan zetten dan is dat hele artikel niet meer te lezen, dat wil je niet. Dan kun je denk ik beter goed definieren wat er in dat geval moet gebeuren dan domweg de toegang tot alles ontzeggen.

Door Roland Witvoet, donderdag 12 april 2007 18:45

Score: 2
Vanuit browser-oogpunt wil je dat eigenlijk wel doen, om daarmee developers te dwingen iets te maken dat aan de standaard voldoet, zodat iedere browser er mee overweg kan., maar de eerste browser die sites met brakke html niet laat zien, maar de bezoeker confronteert met een "deze pagina kan niet worden weergegeven"-melding, raakt zijn gebruikers kwijt.

Er is nu eenmaal veel slechte html op het web te vinden en daar zul je mee om moeten gaan.
En door dat allemaal op dezelfde manier te doen, voorkom je dat je gebruikers weglopen naar een browser die de 'rotzooi' beter weergeeft.
Blijft de vraag hoe je gaat zorgen dat devellopers nette html gaan schrijven ipv dat ze de error-handling als valide html gaan gebruiken. Als je sluittags kunt weglaten omdat het toch wel acceptabel afgehandeld wordt, moet je dan nog wel sluittags gebruiken?

Door Little Penguin, donderdag 12 april 2007 19:20

Score: 1
Waarom niet? Valid (X)HTML afdwingen vind ik wel kunnen. Als ik in PHP, ASP, JAVA, ... geen valid code schrijf, werkt mijn programma ook niet. Waarom zou hetzelfde niet voor een website mogen gelden?
Het probleem is dat je dat afdwingen vanuit de browser moet doen - zoals al aangegeven is, is dat geen optie - zie eerdere reacties.

Het enige dat wel zou kunnen helpen om XHTML (dus ook "XHTML 5") een duwtje te geven is dat browsers die XHTML strict renderen dit sneller doen dan HTML-tagsoup.

Ik weet niet in hoeverre dit technisch mogelijk is, maar door de pagina seconden sneller te renderen als XHTML zou kunnen helpen om XHTML populairder te maken.

Ik weet echter niet in hoeverre het parsen van XHTML efficienter is dan het parsen van HTML - het verschil is waarschijnlijk te klein.

Door arendjr, donderdag 12 april 2007 19:22

Score: 2
@berend_engelbrecht:
Volgens mij heb je niet helemaal begrepen wat backward compatibiliteit hier inhoudt.
Dat XHTML niet backward compatible is met HTML betekent dat een geldige HTML-pagina niet automatisch ook een geldige XHTML-pagina is. Maar dat wil natuurlijk helemaal niet zeggen dat een browser die XHTML ondersteunt geen HTML-pagina's meer zou kunnen ondersteunen. Het een hoeft het ander niet uit te sluiten. Want natuurlijk kan een browser die XHTML ondersteunt (zoals Mozilla of Opera) gewoon pagina's in normaal HTML van 10 jaar geleden weergeven.

Door 7.01D, donderdag 12 april 2007 20:55

Score: 1
@berend_engelbrecht
Het feit dat er een versie van de standaard is ingevoerd die niet backward compatible is was een heel domme en ondeskundige move van de W3C destijds, waar we nu de wrange vruchten van plukken
Daarom hebben ze de naam ook veranderd naar XHTML, om aan te geven dat het niet zomaar een nieuwe versie van dezelfde taal is.

Door Milt, donderdag 12 april 2007 21:31

Score: 1
@berend_engelbrecht:
Het feit dat XHTML er is en browser het correct gaan ondersteunen wil niet zeggen dat oude en brakke HTML pagina's ineens niet meer weergegeven kunnen worden. Dankzij DOCTYPE declaraties en content types kan een goed geimplementeerde browser het verschil zien tussen XHTML en HTML dus kan hij beide goed weergeven (of in ieder geval in het geval van HTML het beste ervan maken).

Door JeromeB, vrijdag 13 april 2007 01:43

Score: 0
arendjr, zo 'natuurlijk' vind ik dat eigenlijk niet. Het is misschien natuurlijk dat bekende browsers zoals Mozilla en Opera zowel XHTML als HTML ondersteunen, maar dat geld niet voor alle applicaties. Beide formaten worden namelijk op verschillende wijzes geparst. HTML wordt geparst door een SGML-parser. XHTML wordt geparst door een XML-parser. Dat kan nog wel eens een probleem worden met minder bekende browser of tools die wel over een XML-parser beschikken, maar niet over een SGML-parser.

Door JeromeB, vrijdag 13 april 2007 02:23

Score: 0
Little Penguin, dat vind ik eigenlijk nogal krom. Waarom zou een browser XHTML moeten pushen ten nadele HTML? Het is dan net alsof je XHTML door de strot van webdevelopers wil drukken. Ik zou dit geen goede ontwikkeling vinden. Ik heb als webdeveloper helemaal geen interesse in XHTML. HTML voldoet prima en is iets flexibeler (mbt tags en error-afhandeling) dan XHTML.

Door KoKro, vrijdag 13 april 2007 22:11

Score: 0
Probleem van die error correctie is dat die ook niet gestandaardiseerd is en dus onvoorspelbaar resultaat geeft. Dat kan net zo funest zijn als een pagina helemaal niet rendert.

Als je een website goed opzet, dan zorg je voor een goede test en productieomgeving. Door een eenduidige standaard is het mogelijk om correctheid te bewijzen en dan pas over te gaan naar productie.

Voor dynamische pagina's zijn voldoende tools aanwezig om correcte output te blijven genereren.

Volgens mij is het toch echt gewenst dat een pagina volgens een vastgestelde opmaak overal dezelfde, vooraf gedefinieerde, uitvoer produceert.

Door 2playgames, vrijdag 13 april 2007 23:08

Score: 0
oplossing: laat de browsers een dikke vette balk bovenaan zetten (zoals nu de balk van een geblokte popup) met het bericht: "Deze pagina is niet geldig opgemaakt. Het weergegeven resultaat is wellicht niet wat de auteur bedoeld heeft" (of iets dergelijks). Developers worden dan gemotiveerd om correcte HTML te schrijven, maar gebruikers kunnen de pagina nog steeds bekijken.

Oh, en belangrijk detail: Niet alle oude pagina's zouden meteen kapot gaan. Alleen pagina's met een HTML 5 DTD zouden volgens deze regels behandeld worden ;)

Door denkster, zaterdag 14 april 2007 14:02

Score: 0
Iedereen (die een webbrowser) schrijft zou zich dus aan deze regels moeten houden.
Helemaal mee eens. Geldt voor schrijvers van browsers, websites, automobilisten, monopolisten...
Feit is dat regels toch vaak, bewust of onbewust, worden overtreden. Daar moeten we een houding tegenover stellen, maatregelen nemen. Waarom? omdat de consumenten de dupe worden. Zij worden geconfronteerd met onvindbaarheid of onleesbaarheid van informatie, idiote foutmeldingen, blanco pagina's, crashes, malware brakke browser, enzovoort, terwijl ze daar vrijwel niets aan kunnen doen, bij gebrek aan kennis en macht.
Dus met:
kijkt te veel naar de consument
ben ik het helemaal oneens.
Laten we iets bedenken waardoor de narigheid van het gebrek aan standaards en het overtreden van regels bij de producent van de narigheid komt te liggen.
Als eerste afspraak stel ik voor: als een gebruiker een pagina probeert openen die niet valide is voor die browser krijgt de server van de pagina een technische foutmelding en de gebruiker een excuus en een advies.
De bouwers van invalide websites zullen snel overspoeld raken met meldingen, dat zal ze leren.
Valide websites bouwen kan namelijk best, zie Rabobank (f.y.i.: ik heb daar geen belangen)

Door _JGC_, donderdag 12 april 2007 19:17

Score: 1
Ik zie het op mijn werk echt heel vaak gebeuren: "Oh shit, het werkt niet helemaal 100% met XHTML, als ik nou gewoon de doctype weghaal en IE in quirksmode zet werkt het wel"
En vervolgens heb je een rotzooisite vol met tabellen omdat ze niet weten hoe het in IE6 goed te krijgen is. Vooral sites met 100% hoogte is in IE6 een ramp als je IE6 in standards compliance mode zet (ja het kan, vraag niet hoe :X)

HTML5 is leuk en aardig allemaal, maar zolang webdevvers allemaal nog gewoon terugvallen op een oudere standaard als het even tegenzit, heeft het forceren van goede code geen zin. Verder heb je ook nog zoiets als een doelgroep van je website. Als je doelgroep IE6 en IE7 is (grote kans, je kunt het niet maken om deze twee browsers uit te sluiten), is HTML 5.0 dus al waardeloos omdat die browsers het toch niet snappen.

Door priem, donderdag 12 april 2007 18:02

Score: 2
Als Google nou eens in hun pagerank algoritme iets opneemt zodat (X)HTML fouten je pagina doen zakken ...

Door XplodingForce, donderdag 12 april 2007 18:10

Score: 2
Google is gericht op het laten zien van de beste resultaten. Een site die brak gecode is, kan best goede informatie bevatten en dus een goed resultaat zijn.

Dit zal google dus echt niet doen, aangezien dan de zoekresultaten ernstig verslechteren.

Door Luxx, donderdag 12 april 2007 18:20

Score: 1
Google is gericht op het toegankelijk maken van informatie, een site met valide html is beter toegankelijk, en levert de informatie 'beter' aan de gebruiker. Kortom, ergens is het wel logisch om daar iets mee te doen.

Helaas is het in de praktijk zo dat een slechte pagina vaak (in IE) alsnog goed gerenderd wordt, en dús is het ergens wel logisch dat Google hier niets in ziet.

Door JanDM, donderdag 12 april 2007 18:52

Score: 1
Google is gericht op het toegankelijk maken van informatie, een site met valide html is beter toegankelijk, en levert de informatie 'beter' aan de gebruiker. Kortom, ergens is het wel logisch om daar iets mee te doen.
Beter toegankelijk voor de parser misschien, maar een validerende xhtml pagina kan minder toegankelijk zijn dan een html pagina met enkele kleine foutjes. De relevantie van de content (en daar gaat het om) is al helemaal niet omgekeerd evenredig met het aantal fouten in de html.
Helaas is het in de praktijk zo dat een slechte pagina vaak (in IE) alsnog goed gerenderd wordt, en dús is het ergens wel logisch dat Google hier niets in ziet.
Jammer, maar ansich niets mis mee, als die error correctie maar gedefinieerd is, zodat het in alle browsers hetzelfde werkt :)

Door Jogai, donderdag 12 april 2007 18:11

Score: 0
Dat is een super idee!! Wedden dat dan de kwaliteit omhoog gaat!

Door alex3305, donderdag 12 april 2007 18:15

Score: 0
De kwaliteit van (X)HTML misschien wel, maar niet de kwaliteit van de informatie.

Als ik dus een pagina goed code over rental cars, maar slechte informatie heb dan kom ik hoger te staan dan sites die goede informatie hebben over rental cars, maar slechte code.

Dat is denk ik dus niet the way to do it!

Door huubi182, donderdag 12 april 2007 18:26

Score: 0
wat een onzinplan over google. Mensen mogen best brakke code gebruiken om sites te maken. Het gaat erom dat standaarden duidelijk zijn, niet dat de gebruiker alles goed moet doen. Standaarden zijn handig, niet heilig. Google moet hier helemaal met z'n poten afblijven, dan gaat google voor ons bepalen wat een 'goede' site is.

Door Nijn, donderdag 12 april 2007 18:48

Score: 2
Goeie!
Dan maak ik morgen een ad-farm met alle mogelijke onderwerpen in 100% correct (x)html.
Ben ik toch al minimaal 50% van de (echte) pagina`s kwijt omdat er een fout in zit. (Lees: Geschreven zijn om te werken in IE)

Door Green.Velvet|IA, donderdag 12 april 2007 18:20

Score: 1
Xhtml kent een aantal grote nadelen; zo is de taal niet volledig backwards compatibel en wordt xhtml niet ondersteund door Internet Explorer.
Ow... dus... we hebben een standaard... MS weigert hem te volgen of implementeren... dus beginnen we aan maar aan een nieuwe versie...

Door SirBlade, donderdag 12 april 2007 18:41

Score: 0
Het zou makkelijker zijn om aan MS te vragen hoe de volgende standaard er uit moet zien en die dan door de rest van de browser-maker te laten implementeren. Maar dat is natuurlijk op z'n minst niet politiek-correct en voor velen heiligschennis.

Door ytsmabeer, donderdag 12 april 2007 18:46

Score: 0
Microsoft wacht eerst af wat anderen als standaard willen zodat ze precies het tegenovergestelde kunnen doen.

Door Roland Witvoet, donderdag 12 april 2007 18:54

Score: 2
Een groot probleem daarbij is dat Microsoft zijn Internet Explorer erg graag integreert met het windows OS. Dan kunnen ze met betrekkelijk weinig werk hele krachtige dingen doen, door gebruik te maken van ActiveX, VBA en .Net, maar behalve dat dat veel beveiligingsgaten oplevert omdat dat diep in het OS integreert, kun je geen browser meer maken zonder gelijk half Windows te moeten emuleren.
En dat zie ik nog niet zo snel gebeuren op Linux, Mac en andere non-windows-systemen (zoals settop boxen en de b.v. de PS3 in de woonkamer, mobiele telefoons, etc.) Als het aan Microsoft ligt, kun je straks geen fatsoenlijke webbrowser meer bouwen zonder Windows OS.
En er zijn diverse redenen waarom je dat geen goede ontwikkeling is, als was het maar dat mijn telefoon geen windowsXP kan draaien.

Door Roland Witvoet, donderdag 12 april 2007 18:45

Score: 2
Het is kiezen tussen een standaard die niet werkt op internet explorer en dus vrijwel kansloos is, of een die nog wel iets laat zien op internet explorer.

Door GeertAki, vrijdag 13 april 2007 09:19

Score: 0
Mijn eigen website die met volledig geldige xhtml 1.1 en css is opgemaakt, wordt nogthans ook in IE6 en IE7 goed weergegeven. Of hij deze rendert met html-rendering weet ik niet, maar 't k heb er toch geen problemen mee.

Meer zelfs, ik ben voorstander van xhtml tov html, net omdat het stricter is. Ik vind foute code afhandelen zowieso al niet de taak van een browser. Ik heb liever dat ze eerst de standaarden volledig werkend implementeren alvorens ze zich gaan bezig houden met onnodige zaken. Wat mij betreft moet foutieve broncode gewoon genegeerd worden, zodat de andere code van die pagina wel nog getoond wordt. Als dat het enige regeltje is, dan is het voor iedereen duidelijk en kan je bij het plaatsen van een artikel ervoor zorgen dat het wel compliant is, zodat als iemand dan toch foutieve code kan posten je site niet om zeep helpt, omdat enkel zijn/haar post niet getoond wordt.

Google kan bij het zoeken naar informatie dan dezelfde regel toepassen, want als je de site bezoekt, krijg je het toch niet te zien.

Dat niet backwards compatible zijn is eigenlijk enkel een probleem als je site vroeger in html was en je die nu naar xhtml wil omzetten, omdat je dan ook alle image-tags e.d. van een sluittag moet voorzien en je sluittags correct genest moeten staan. Als je tevreden bent met je site in HTML moet je deze echter niet naar XHTML gaan omzetten, dus ik vind het een relatief zwak argument, die backwards compatibiliteit.

En dat IE xhtml niet ondersteunt is ook geen nadeel, want zaken die in html 5 nieuw zijn tov versie 4 zullen ook niet in IE ondersteund worden...

< sarcastic-mode>
Trouwens MS kennende zullen ze naast xhtml2 en html5 wel met een eigen formaat komen dat ze dan via een speed-procedure willen gestandardiseerd krijgen, maar dat het zodanig opgesteld is dat Firefox, Opera en apple het nooit volledig kunnen implementeren omdat het zich een stuk baseert op closed source binnaire drm-componenten.
< /sarcastic-mode>

Door Nijn, donderdag 12 april 2007 18:50

Score: 2
Dat is nou precies de strategie van MS. Ze wachten af tot er een standaard komt, om vervolgens een aantal punten aan te passen. Aangezien zij de marktleider zijn gaan veel mensen niet eens de moeite nemen om hun site correct te maken, als ie maar werkt in IE. Dus, Mozilla geeft foutmeldingen op een site die met IE prima werkt. Wat doet de consument? Precies...

Door slincher, donderdag 12 april 2007 18:49

Score: 0
Er moet eigenlijk een keep-alive HTTP protocol komen dat veranderingen doorgeeft waardoor je active sites kan krijgen, dus niet met PHP+AJAX maar dat je echt met een instandhoudende connectie werkt. Dat zou waanzinnig veel verbetering op het internet kunnen betekenen. Een daarbij passende Markup Language moet dan uiteraard ook worden gemaakt.

Overigens wel relaxt dat W3C een standaard hanteerd en een eigen check-systeem heeft!

Door Roland Witvoet, donderdag 12 april 2007 19:03

Score: 1
Dat kan al hoor, als je voor lief neemt dat je browser-ikoontje blijft draaien (en terecht, want de pagina is nooit klaar met laden). Je kunt bijvoorbeeld gewoon javascript blijven sturen en zo de pagina blijven updaten.
En als er geen verandering is, geeft een revisit van een pagina door aan je browser dat hij de site in zijn cache moet gebruiken, dus elke 5 seconden refreshen hoeft nauwelijks dataverkeer tot gevolg te hebben.

Maar een probleem dat optreedt als je van alle pagina's streams zou gaan maken, is dat de server dan heel erg veel connecties moet gaan bijhouden en het beschikbaar aantal poorten is gewoon beperkt (al zul je eerder door je geheugen heen zijn)

Maar ik heb het idee dat jij een oplossing zoekt voor een heel specifiek probleem, ik kan me weinig toepassingen voorstellen waarbij iets dergelijks nuttig is.

Door flowerp, donderdag 12 april 2007 21:02

Score: 0
Maar ik heb het idee dat jij een oplossing zoekt voor een heel specifiek probleem, ik kan me weinig toepassingen voorstellen waarbij iets dergelijks nuttig is.
Ik heb het idee dat jij niet zo veel verstand van developpen hebt.

Wat we tegenwoordig steeds meer doen is applicaties remote draaien via het web. Vele "web sites' zijn eigenlijk "web applicaties".

HTML en HTTP zijn oorspronkelijk bedoeld voor simpele information browsing sites. Niet voor statefull & rich applications. Als programmeur moet je je dus nu in zeer veel bochten wringen om web applicaties te realiseren. Solide frameworks als Java EE en ASP.NET (among others) helpen wel een eind om de pijn te verzachten, maar feit blijft dat zelfs antieke frameworks/widget sets als MFC en Motif een 10x zo rijk programmeermodel hebben als de huidige web frameworks kunnen bieden.

Door daank, donderdag 12 april 2007 20:00

Score: 0
Auch, lekker als er 1000 concurrent connections zijn met een website.. wil alleen al niet weten wat dit dan server-side doet.. :o

Door Larsie, donderdag 12 april 2007 22:07

Score: 0
Dat is dus een probleem voor de 'programmeur'. (zodra we zo'n standaard hebben)
Net alsof je een normaal programma niet zou schrijven omdat er mogelijk teveel mensen gebruik van gaan maken...

Door Bob_, donderdag 12 april 2007 18:50

Score: 0
Gelukkig geven ze het goede voorbeeld:
http://validator.w3.org/c...tically%29&doctype=Inline
|:(

Door JanDM, donderdag 12 april 2007 18:57

Score: 0
Je gebruikt een xhtml/html4 validator om een html5 pagina te valideren? Misschien dat die pagina zelf al de daarin beschreven regels volgt? Dat is wel zo leuk :)

@Bob_: waarom zou je het niet mogen gebruiken als er nog geen implementatie is?

Door Bob_, donderdag 12 april 2007 19:07

Score: 0
HTML 5 is een draft die door nog geen enkele browser wordt ondersteund. Dus nee het is geen html5.

Het blijkt HTML 4.01 strict te zijn maar dan moet er _wel_ een doctype gespecificeerd zijn.

Door dmantione, vrijdag 13 april 2007 12:46

Score: 0
Apple, Opera en Mozilla zijn al lang bezig met het implementeren van HTML5. Ook KDE is er mee begonnen. Probeer maar eens hoeveel HTML5 je huidige browser al slikt, je zult versteld staan, mits het een beetje recente browser is en het niet om IE of Links gaat.

Door Jeroen vd Meer, donderdag 12 april 2007 19:05

Score: 1
Ze geven zeker het goede voorbeeld. Het enige wat de WHATWG "verkeerd" heeft gedaan in dit document is dat ze niet een DOCTYPE hebben gebruikt die in één van de voorgaande HTML specificaties is verplicht. Dit is met opzet gedaan omdat de WHATWG tegen het gebruik van een DOCTYPE is. Een DOCTYPE stamt immers af uit de afkomst van HTML, namelijk SGML. De WHATWG heeft echter de conclusie getrokken dat HTML niet meer als SGML applicatie gezien kan worden omdat HTML een eigen leven is gaan leiden. Dit is voor hen dus de reden om zoveel mogelijk afstand te doen van een DOCTYPE. De enige reden om niet helemaal afstand ervan te doen is voor backward compatibility.

Voor de rest is de pagina echter valide HTML 4.01. Dit kan je checken door de validator in te stellen met een HTML 4.01 Strict DOCTYPE:
http://validator.w3.org/c...TML+4.01+Strict&verbose=1

Door _Thanatos_, donderdag 12 april 2007 20:02

Score: 0
Maar leggen ze dan ook uit hoe je dan moet zien of je te maken hebt met HTML2, HTML3, HTML4, XHTML of HTML5?

Door Jeroen vd Meer, donderdag 12 april 2007 20:36

Score: 0
Het is niet echt relevant welke versie van HTML gebruikt wordt. Elke versie van HTML is immers backward compatible. Dus als enkel de laatste versie van HTML wordt ondersteunt, dan ondersteun je dus in feite alle versies van HTML.

Bij XHTML wordt er gekeken naar het internet media type. XHTML en HTML zijn twee verschillende talen en hebben daarom hun eigen internet media type waaraan je kan zien welke taal voor de opbouw wordt gebruikt. Wordt XHTML verstuurd met het media type van HTML, dan wordt er gedaan alsof de pagina is opgebouwd in HTML 4.01.

Door _Thanatos_, zaterdag 14 april 2007 17:11

Score: 0
Dus je kunt niet meer aangeven hoe een document gevalideerd moet worden, nog hoe het geparst dient te worden. Dat legt toch wel een beperking op, omdat browsers wel degelijk hun rendering kunnen aanpassen aan de versie van het documenttype. Immers, de regels die specifieren hoe e.e.a. gerenderd dient te worden, kunnen verschillen per HTML-versie.

Maar validatie ook; als je een HTML4 document moet maken, moet je daar niet HTML5 dingen in gaan stoppen. Doe je dat wel, dan werken er dingen niet, terwijl de validator het allemaal prima vindt. Wat is er dan fout? Zoek het maar uit... en dat probleem wordt erger bij meer nieuwere versies van HTML.

Door KimG, donderdag 12 april 2007 19:06

Score: 0
Ik hoor hier alleen maar slechte commentaar? Ik vind de nieuwe specificaties best wel goed, vergeet niet dat heel veel websites gemaakt zijn door de "hobby man / vrouw" met zijn PC waar een voor geïnstalleerde frontpage editor of dergelijke op zat en ze nu pas verder kijken dan de wysiwyg omgeving door dat men het boek "html voor dummies" gekocht heeft of dergelijke ... XHTML is voor veel "dummies" al onmiddellijk een grote stap omdat ze vaak amper weten wat nog maar een <meta> tag is of laat staan een <object> ... ik vind HTML 5 duidelijker, omdat er meer specifieke tags bestaan zoals <video></video>, <audio></audio>, <code></code>, <dialog> ... etc, waar ik wel akkoord mee ben is dat er eindelijks gewerkt gaat moeten worden aan CSS

Door g4wx3, donderdag 12 april 2007 19:40

Score: 0
Ik had juist liever gehad, dat alles was omvat in <object>
MEt een javascripte, zou het dan makkelijker zijn geweest, om te swichten tussen audio/video/flash/afbeelding.

BTW: Ik had ook graag de toevoeging gehad aan de audio, om een visual toe te voegen.

Door 2playgames, vrijdag 13 april 2007 23:21

Score: 0
je kunt altijd de inhoud in een div zetten, en daar de innerHtml van aanpassen ;)

maar iid, <object> is beter. dan kun je ook makkelijker "onbekende" objecten zoals b.v. een flash animatie of java applet invoegen

Door markg85, donderdag 12 april 2007 19:21

Score: 0
op zich een geweldig idee en zou nog best kunnen slagen ook.. MITS Internet Explorer meedoet!!

ik ben geen IE or MS fan, maarja.. zo`n 70% van de internetters gebruikt helaas IE.. dus die moet dan toch maar mee doen om het tot een succes te maken.

Door dmantione, vrijdag 13 april 2007 13:03

Score: 0
Nee, juist niet.

De reden waarom XHTML geflopt is, is dat als je van de voordelen van XHTML gebruik wilt maken, dat wil zeggen dat je XHTML 2 gebruikt, je Internet Explorer kwijt bent. 70% van de bezoekers kwijt is onaanvaardbaar.

Bij HTML is dat altijd keurig opgelost; de invoering van CSS betekende bijvoorbeeld niet dat de oude Netscapebrowsers niet meer werken, de site zag er alleen wat minder uit op die browsers. Dat was voor de meeste webontwikkelaars prima aanvaardbaar.

HTML5 is ontwikkeld met dit inzicht in gedachten; als Tweakers bijvoorbeeld besluit om het venstertje waar je je reactie intypt WYSIWIG te maken met behulp van HTML5, dan zullen Mozilla en Opera het WYSIWYG-invulvakje tonen (ja, dat kan nu al, de ondersteuning is er al), terwijl IE en Links (of Lynx) een ouderwets tekstinvulscherm tonen.

Door dit ontwerp kan je verwachten dat HTML5 snel door websites in gebruik genomen zal worden.

Door g4wx3, donderdag 12 april 2007 19:38

Score: 0
Met alle internettalen die er momenteel zijn, kan je volgens mij wel al genoeg mooie dingen maken.

Echter, de onderlinge browsercompatibiliteit zit altijd tegen. Om een volwaardige applicatie voor alle browser toegankelijk te maken, moet je altijd extra tijd aan je project besteden.

Eén van de dingen, die ik ook niet goed kan volgen, is de verdwijning van target=blank. Ik heb altijd geleerd, dat je voor links, best geen javascript gebruikt, en nu dwingen ze je zelfs..

Ben nu bezig aan een HTA, die automatisch zichzelf update adhv javascript. De online versie is verbonden aan een database. Dit om maar te zeggen, dat met JS, PHP, MySQL, HTML, CSS, je al zeer geinige dingen kunt maken.

Door 7.01D, donderdag 12 april 2007 21:11

Score: 0
Het idee achter het verdwijnen van het target-attribuut is dat de bezoeker van een site zelf prima kan beslissen of hij/zij een link in een nieuwe venster/tab wil openen.

Onder HTML5 komen er waarschijnlijk andere popup-achtige mogelijkheden, waarbij echter geen nieuw document geopend wordt, maar meer een een dialogue box. Voor de overige (gewone) links is het dus aan de bezoeker. En terecht denk ik.

Volgens mij biedt HTML5 een aantal prachtige nieuwe mogelijkheden. Vind het alleen wel jammer dat een aantal XHTML-verplichtingen weer zullen verdwijnen, zoals het sluiten van alle tags en de schrijfwijze van attributen.
Hopelijk valt de ontwikkeling van XHTML nu niet helemaal stil, maar kunnen we straks gewoon kiezen welke taal we gebruiken voor een bepaald project.

Door Superdeboer, donderdag 12 april 2007 23:20

Score: 0
Dan heb je de insteek van de WHATWG en van de nieuwe HTML WG niet helemaal goed begrepen. De working draft van Web Applications 1.0 voorziet in twee serialisaties onder één specificatie. Dat wil zeggen, een XML-syntax én een klassieke HTML-syntax.

XHTML 1.0 is een één-op-één herformulering van HTML 4.01 in XML-syntax. Ook de klassieke HTML-syntax van HTML5 zal dus zo'n XML-equivalent krijgen, zo staat in het charter van de HTML WG te lezen.

Het is natuurlijk de vraag hoe op dit punt de discussie binnen de werkgroep gaat verlopen, maar zoals een en ander nu in de working draft van de WHATWG vermeld staat, móet je onder de nieuwe specificatie je XHTML-documenten met application/xml of application/xhtml+xml MIME-type versturen, waar je XHTML 1.0 als text/html mág versturen als je aan de juiste voorwaarden voldoet.

Naast de twee serialisaties binnen de HTML5 specificatie gaat de XHTML2 WG zich bezighouden met datgene wat de HTML WG de afgelopen jaren heeft gedaan. XHTML2 is dus niet per definititie dood, maar het W3C ziet wel in dat dat niet de mainstream wordt. Goed leesvoer over deze koerswijzigingen is dit stukje tekst van het W3C.
«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 20:07
Vorige 16:36
VNU Media logo Powered by True

© 1998 - 2008 Tweakers.net - Alle rechten voorbehouden

Uitgever van: