HTML5, wat vinden wij ervan?

vrijdag 7 augustus 2009 19:55

Acties:

0 Henk 'm!

Topicstarter

HTML5

Het buzzwoord in de webdev wereld van nu moet toch wel HTML5 zijn, en er zijn ondertussen al vele blogposts geplaatst met meningen, tips & tricks etc...Maar is het zinnig om nu al HTML5 te gebruiken in plaats van HTML4.01 of XHTML1.0?

Korte geschiedenis

WHATWG is een community die het werk begon aan HTML5, waarna het in 2007 werd overgenomen door het W3C. Daarnaast werk(t)e het WHATWG actief aan Web Workers, Web Forms 2.0, Web Controls 1.0 en eerder genoemde HTML5 (destijds bekend onder Web Applications 1.0).

De eerste draft van HTML5 werd vervolgens gepubliceerd op 22 januari 2008. Er zal nog vele jaren aan de specificatie gewerkt worden, maar delen zullen klaar zijn en geïmplementeerd worden in browsers voordat de specificatie final is.

bron:Wikipedia

Misverstanden en gerelateerde verhitte discussies

Vrij recent werd de ontwikkeling aan XHTML2 stopgezet, en dit leverde nogal wat reactie en discussie op. Naar mijn mening wordt deze gebeurtenis, en een korte inleiding over HTML5, vrij goed weergegeven in dit artikel van smashing magazine.
Highlights: backwards compatible, zowel XHTML1.0 als HTML4.01 syntax wordt geaccepteerd, XHTML2.0 != verbeterde XHTML1.0.

Meer over XHTML2.0 vs (x)HTML5 in dit artikel.

HTML5: De voordelen

Er zijn nogal wat nieuwigheden, waarvan hier (een poging tot) een samenvatting. Een groot gedeelte van onderstaande text komt van dit artikel van SM.

Nieuwe structurele elementen:

<header>. Bevat een inleiding voor een paginasectie of een hele pagina.
<nav>. Bevat de primaire navigatie voor een pagina.
<section>. Bevat een sectie van je pagina.
<article>. Bevat content die onafhankelijk van de rest kan worden weergegeven.
<aside>. Bevat content die gerelateerd is aan je sectie. Denk aan gerelateerde posts, tagclouds, pullquotes etc.
<footer>. Spreekt voor zich. Je kan deze gebruiken zowel als globale footer voor je pagina, alsmede voor een footer van een artikel.

Meer hierover in bijvoorbeeld dit artikel van ALA. Voor nog meer nieuwe structurele elementen, zie dit artikel op IBM.com.

Nieuwe API's:

Denk hierbij aan Geolocation, drag&drop, video en audio.

HTML 5 introduces a number of APIs that help in creating Web applications. These can be used together with the new elements introduced for applications:
2D drawing API which can be used with the new canvas element.
API for playing of video and audio which can be used with the new video and audio elements.
An API that enables offline Web applications.
An API that allows a Web application to register itself for certain protocols or media types.
Editing API in combination with a new global contenteditable attribute.
Drag & drop API in combination with a draggable attribute.
API that exposes the history and allows pages to add to it to prevent breaking the back button.
Cross-document messaging.

bron: http://www.w3.org/TR/html5-diff/#apis

Gerelateerde posts:

Forms:

Voorheen bekend als Web Forms 2.0 (bedacht door het WhatWG). Denk hierbij aan autofocus en form validation. Meer hierover in een artikel op dev.opera door Anne van Kesteren.

Nieuw doctype:

Niet echt een voordeel, behalve dan dat het makkelijker te onthouden is.

HTML:

1	<!DOCTYPE html>

HTML5: De nadelen

Gebrekkige browserondersteuning in het algemeen.
De nieuwe structurele elementen kunnen niet zomaar gebruikt worden in IE. Deze heeft javascript nodig om deze nieuwe elementen te herkennen.
Onderlinge ruzie tussen browsermakers over o.a. codecs.
...

Wat kunnen we er nou op dit moment mee?

Dat is voor mij de vraag en de reden voor het openen van dit topic. Behalve dan het maken van playground sites, willen de meeste hier toch een zo breed mogelijk publiek (crossbrowser) bereiken. Gebruik je al nieuwe elementen/API's? Heb je al de naming convention overgenomen van HTML5, dus ipv <div id=navigation>, <div id="nav">? Laat het weten.

Een grote collectie van resources over HTML5 is ook te vinden op WHATWG.

Disclaimer: Ik ben geenszins een autoriteit op dit gebied, suggesties en verbeteringen zijn dan ook meer dan welkom .

vrijdag 7 augustus 2009 20:54

Acties:

0 Henk 'm!

Fuzzillogic

Cool

Als nadelen zou ik nog willen opsommen

Backwards compatiblititeit.
SGML-achtige ML ipv pure XML, en dus problemen om andere standaarden te combineren binnen HTML.
Vrijwel geheel negeren van GUI's voor webapps.
Versie-loze doctype.

Jaja, dat vereist wat uitleg.

Ad 1: na ruim een decennium hadden ze toch eindelijk écht wel eens opruiming mogen houden, en gewoon "from scratch" eens gekeken waar het met HTML naartoe zou moeten gaan. Wég met alle archaïsche drek!

Ad 2: Ik kan hier met mijn verstand niet bij. Hoe ze het in $DEITY's naam nog krampachtig vasthouden aan de oude, verwarrende SGML-achtige ML is mij in deze tijd van fraaie XML-tech zoals XPath, Atom en XSLT volslagen onduidelijk. Als gevolg krijgen we nu ook weer lelijke drek als custom "data"-attributen voor tabellen. Wtf is er mis met XML namespaces? Dat is ervoor gemaakt!
Dat er ook een XHTML5 is, voegt dan m.i. weinig toe. XHTML-support in de huidige browsers is maar al zo-zo. Kijk maar eens wat contentEditable ervan maakt...

Ad 3: Hier kan ik zo mogelijk nog minder goed bij dan punt 2. In een tijd waar webapps zoveel aandacht krijgen is de userinterface van die apps werkelijk abominabel vergelen met een normale desktop-app. De usability van veel GUI's van webapps zijn werkelijk om te janken. Slechte keyboard-support, non-native (en dus onbekende, vreemd reagerende) widgets, slechte toegankelijkheid, you name it.
Wat ik toch minimaal had verwacht was een spec zoals Mozilla's XUL, of wellicht gewoon XUL overnemen.

Goed, je zou kunnen stellen dat GUI-widgets niet thuishoren in een document-ML. Dat zou dan prima op te lossen zijn door de GUI-widgets in een aparte XML-namespace te zetten. Maarja.

Ad 4: Vanwaar de arrogantie dat er na HTML5 geen nieuwe spec meer komt? Wat is er mis om DUIDELIJKHEID te verschaffen dat het om een HTML5-pagina gaat?

En nog wat bonuspunten: ik had *GRAAG* gezien dat er standaard bindings waren gekomen voor hogere programmeertalen zoals Java, of C#, of wat dan ook. Of tenminste support van Javascript 2 vereisen. Want echt waar, Javascript 1.x is gewoon een stinkende berg drek, vergeleken met de alternatieven.

En Canvas? Mijn $DEITY, wat een primitieve farce. Mensen raken bijna in extase als ze een bolletje kunnen tekenen met javascript! Kom nou toch, dat deed ik 25 jaar geleden al op m'n MSX. Canvas is een gimmick, niet meer dan dat. Een lachertje op computers en zelfs portables die al jaren zeer krachtige hardware aan boord hebben voor geweldige 3D-graphics.
Gelukkig is er dan nog SVG, welke min of meer ook in de specs lijken te komen. Zou uitstekend te intergreren zijn met XML namespaces. Tekenend ook dat de huidige browsers geen inline SVG aankunnen als deze niet in een XHTML, maar in HTML-document staat.

Jaja, compatibiliteit is zogenaamd belangrijk voor de grote, logge bedrijven. M'n reet. Als die bedrijven hun zaken op orde hebben hoeft het allemaal niet zo dramatisch te zijn. HTML5 lijkt vooral gericht te zijn om die bedrijven niet al te boos te maken.

Oftewel, naar mijn ongezouten mening is de WHATWG/W3C compleet het spoor bijster. Van echte innovatie en vooruitgang merk ik weinig.

[ Voor 7% gewijzigd door Fuzzillogic op 07-08-2009 21:06 ]

vrijdag 7 augustus 2009 20:58

Acties:

0 Henk 'm!

Manuel

Echt een hele mooie post moet ik zeggen, ik weet alleen niet of HTML nou echt 'zo veel verschillend' is van XHTML(1.1). De nieuwe tags zijn natuurlijk wel mooi meegenomen, maar dat is dan eerder voor blog-posts als ik het zo lees dan voor echte sites. Heb zojuist het voorbeeld op YouTube gezien maar ik zie er niet echt heel veel verschil in als ik eerlijk ben.

Misschien alleen de video tag dat er geen flash meer hoeft worden geladen en verder nog zoals jij hier ook vermeldt, de <nav> tag etc. (Btw ontbreekt hier geen <video>?

)

Ik wacht in ieder geval wel even totdat het uitkomt, kijken hoe het dan 'werkt' :-)

vrijdag 7 augustus 2009 21:06

Acties:

0 Henk 'm!

RobertMe

Gebrekkige browserondersteuning in het algemeen.

Hoe kun je dat nu al zeggen? Het is nog een draft, tuurlijk is er maar gebrekkige browser ondersteuning.

De nieuwe structurele elementen kunnen niet zomaar gebruikt worden in IE. Deze heeft javascript nodig om deze nieuwe elementen te herkennen.

Hiermee probeer je een work-around te maken voor een niet geheel bestaand probleem, want <header> etc. zijn ook nog geen officiële tags, en als je ze door de html validator haalt zal die ook errors geven. (ik weet ook niet of het in een of andere spec. staat dat een browser styles moet toepassen op niet bestaande/officiële tags)

De niet bestaande getElementsByClassName kun je in IE8 dan weer redelijk makkelijk omheen werken met prototyping en de selectors api:

JavaScript:

if(!Element.prototype.getElementsByClassName)
{
  if(document.querySelectorAll)
  {
    Element.prototype.getElementsByClassName = function(className)
    {
    return this.querySelectorAll('.' + className);
    }
  }
}

Maar dit werkt dan weer niet in IE lager dan acht omdat die geen prototyping op Element ondersteund en de selector api niet kent (waarbij er genoeg scripjes zijn die het gedrag van getElementsByClassName emuleren, maar dan is prototyping op Element weer een groot gemis)

vrijdag 7 augustus 2009 21:13

Acties:

0 Henk 'm!

CoolGamer

What is it? Dragons?

Ik denk niet dat het de boel gaat veranderen, in ieder geval niet de komende jaren. Mensen blijven waarschijnlijk voorlopig hangen bij oude browsers die nieuwe dingen niet ondersteunen.

Het zou een einde moeten maken aan de noodzaak van browser-extenties/addons voor veel voorkomende dingen zoals video en audio, maar dat is eigenlijk ook niks geworden (misschien wordt dat over een aantal jaren wat zodra de "consument" voor een codec heeft gekozen). Ik denk dat voorlopig Flash en Silverlight gewoon gemeengoed blijven voor dit soort dingen.

Webformulieren zijn inderdaad iets wat ik jammer vind dat ze daar niet meer gedaan hebben. Ze hebben wel een aantal soorten invoervelden toegevoegd, maar ik vind dat echter vrij beperkt.

Fuzzillogic schreef op vrijdag 07 augustus 2009 @ 20:54:
Ad 4: Vanwaar de arrogantie dat er na HTML5 geen nieuwe spec meer komt? Wat is er mis om DUIDELIJKHEID te verschaffen dat het om een HTML5-pagina gaat?

Volgens mij kan er gewoon een html6 komen, maar door deze keuze zal dan backwards-compatible moeten zijn of een ander doctype kiezen. Dit hebben ze gedaan zodat een browser altijd de laatste versie kan gebruiken. Als het goed is zou er geen verschil moeten zitten in een HTML4 en HTML5 pagina op toegevoegde features na. Zo hoeft een browser maar 1 html-versie te ondersteunen.

¸.·´¯`·.¸.·´¯`·.¸><(((º>¸.·´¯`·.¸><(((º>¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸<º)))><¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸

vrijdag 7 augustus 2009 21:21

Acties:

0 Henk 'm!

Verwijderd

Ik vind de nieuwe structurele elementen weinig toevoegen aan de "taal" zelf.
Je kan met een div id precies hetzelfde bereiken, imo.

En een verbetering van XHTML had meer zoden aan de dijk gezet.

vrijdag 7 augustus 2009 21:31

Acties:

0 Henk 'm!

Fuzzillogic

Cool

Verwijderd schreef op vrijdag 07 augustus 2009 @ 21:21:
Ik vind de nieuwe structurele elementen weinig toevoegen aan de "taal" zelf.
Je kan met een div id precies hetzelfde bereiken, imo.

En een verbetering van XHTML had meer zoden aan de dijk gezet.

Qua layoutmogelijkheden met CSS is er idd geen verschil. De extra tags voegen wel semantische waarde toe, en dat is voor toegankelijkheid en zoekmachines goed. Het gebeurt me nu veel te vaak dat ik met zoekmachines hits krijg op pagina's die een deel van de zoektermen in de content bevatten, maar een (te groot) ander deel van de zoektermen in de sidebars, welke dus dikwijls weinig relatie hebben met de content van betreffende pagina. Oftewel, je hebt dus niets aan dat zoekresultaat.

De vraag is of de nieuwe tags daar echt iets aan zullen gaan doen, aangezien SEO veel te vaak van groter belang is dan het verschaffen van nuttige content, en nuttige zoekresultaten.

Aan de andere kant geeft het SE's wel meer mogelijheid om misbruik op te sporen en te bestraffen.

[ Voor 4% gewijzigd door Fuzzillogic op 07-08-2009 21:35 ]

vrijdag 7 augustus 2009 21:44

Acties:

0 Henk 'm!

Kiphaas7

Topicstarter

RobertMe schreef op vrijdag 07 augustus 2009 @ 21:06:
[...]

Hoe kun je dat nu al zeggen? Het is nog een draft, tuurlijk is er maar gebrekkige browser ondersteuning.

Omdat ik het over het hier en nu heb. De vraag is immers of het nu al te gebruiken is...

Manueltje22 schreef op vrijdag 07 augustus 2009 @ 20:58:
Echt een hele mooie post moet ik zeggen, ik weet alleen niet of HTML nou echt 'zo veel verschillend' is van XHTML(1.1). De nieuwe tags zijn natuurlijk wel mooi meegenomen, maar dat is dan eerder voor blog-posts als ik het zo lees dan voor echte sites. Heb zojuist het voorbeeld op YouTube gezien maar ik zie er niet echt heel veel verschil in als ik eerlijk ben.

Je moet juist die elementen in de wat bredere zin opvatten: section kan je bijvoorbeeld opvatten als het "main" gedeelte van de site, met daarin de subsecties als articles. Het voordeel van deze nieuwe tags in tegenstelling tot divs met id's is dat computers direct begrijpen om welk gedeelte het gaat. Er is namelijk nogal een oerwoud aan naming conventions met divjes: <div id="navigation">, <div id="navigatie">, <div id="hoofdmenu"> etc....

Manueltje22 schreef op vrijdag 07 augustus 2009 @ 20:58:
Misschien alleen de video tag dat er geen flash meer hoeft worden geladen en verder nog zoals jij hier ook vermeldt, de <nav> tag etc. (Btw ontbreekt hier geen <video>? )

Kijk eens bij het kopje "Nieuwe API's....

Manueltje22 schreef op vrijdag 07 augustus 2009 @ 20:58:
Ik wacht in ieder geval wel even totdat het uitkomt, kijken hoe het dan 'werkt' :-)

Dan kan je officieel wachten tot 2022

.

[ Voor 5% gewijzigd door Kiphaas7 op 07-08-2009 21:45 ]

vrijdag 7 augustus 2009 21:45

Acties:

0 Henk 'm!

Sebazzz

3dp

Verwijderd schreef op vrijdag 07 augustus 2009 @ 21:21:
Ik vind de nieuwe structurele elementen weinig toevoegen aan de "taal" zelf.
Je kan met een div id precies hetzelfde bereiken, imo.

Een div heeft geen semantische waarde.

[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]

vrijdag 7 augustus 2009 22:11

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

Html5

Wat het grootste voordeel van HTML5 imo is is het feit dat het afgestapt is van de SGML basis - aangezien ook geen enkele browser HTML ooit zo geimplementeerd heeft - en de parsing en treebuilding tot in de details heeft beschreven, daarbij rekening houdend met de huidige behaviour van hedendaagse browsers. Dit maakt dat we op dat vlak eindelijk interoperability gaan krijgen

Fuzzillogic schreef op vrijdag 07 augustus 2009 @ 20:54:
[...]

Tsja, ik ga de discussie over het nut van backwards compatibility, de nadelen van een op XML gebaseerde taal en alle andere utopische gedachten hier niet meer aan. De feiten dat XHTML1.x jammerlijk gefaald heeft op het web, dat XHTML2 nooit van de grond is gekomen (iig niet in de browser wereld) en nu wordt gestaakt, en dat HTML5 steeds meer adoptie krijgt spreken voor zich...

Kiphaas7 schreef op vrijdag 07 augustus 2009 @ 21:44:
[...]

Dan kan je officieel wachten tot 2022 .

Dat zal wel meevallen; delen van HTML5 worden nu al ondersteund door browsers en het zal de komende jaren steeds meer gemeengoed worden. De snelle adoptie is ook te danken aan het feit dat er juist /niet/ gekozen is voor een compleet nieuwe taal

RobertMe schreef op vrijdag 07 augustus 2009 @ 21:06:
[...]
Hiermee probeer je een work-around te maken voor een niet geheel bestaand probleem, want <header> etc. zijn ook nog geen officiële tags, en als je ze door de html validator haalt zal die ook errors geven. (ik weet ook niet of het in een of andere spec. staat dat een browser styles moet toepassen op niet bestaande/officiële tags)

Je weet dat er een HTML5 validator bestaat?

HTML5 beschrijft wel wat er gedaan moet worden met 'onbekende' tags. Eea is zo opgezet dat uitbreiding van de vocabulaire geen wijziging in het parsing-algorithme zou mogen inhouden.

[ Voor 21% gewijzigd door crisp op 07-08-2009 22:17 ]

Intentionally left blank

vrijdag 7 augustus 2009 22:17

Acties:

0 Henk 'm!

Kiphaas7

Topicstarter

crisp schreef op vrijdag 07 augustus 2009 @ 22:11:
Dat zal wel meevallen; delen van HTML5 worden nu al ondersteund door browsers en het zal de komende jaren steeds meer gemeengoed worden. De snelle adoptie is ook te danken aan het feit dat er juist /niet/ gekozen is voor een compleet nieuwe taal

Het was dan ook sarcastisch, in het kopje korte geschiedenis van de OP heb ik deels hetzelfde gezegd.

zaterdag 8 augustus 2009 08:01

Acties:

0 Henk 'm!

Zakkenwasser

Goede ontwikkelingen, ik kan niet wachten tot HTML 5 volledige ondersteuning heeft van alle browsers.

Het probleem echter met dit soort ontwikkelingen is dat er teveel browsers zijn die van elkaar verschillen en daardoor met nieuwe technieken algauw achterlopen.
Waarschijnlijk kan hier niet op ingespeeld worden met het ontwikkelen van een browser met behulp van updats die je dan kan downloaden.

Waarom MS nooit updates heeft gemaakt voor IE6 die op de dag van vandaag door een selecte groep word gebruikt, kan ik ook niet bevatten.
Heeft waarschijnlijk met prioriteiten te maken.

Zolang er browsers zullen zijn die HTML 5 nog niet volledig ondersteunen, blijf ik met mijn javascript vrije websites maken die XHTML STRICT zullen zijn.

PSP 1000 @ 6.60 Pro C2 [+256GB]
PSVita @ Henkaku Enso [+256GB]
3DS @ Luma (B9S) [+160GB]
Nintendo Switch 3.0.1 [+256GB]

zaterdag 8 augustus 2009 10:12

Acties:

0 Henk 'm!

Verwijderd

Je kan <video> op dit moment al wel gebruiken met Video for Everybody!

zaterdag 8 augustus 2009 10:30

Acties:

0 Henk 'm!

Johnny

ondergewaardeerde internetguru

Het meest interessante aan HTML5 vind ik de nieuwe mogelijkheiden voor formulieren, de nieuwe datatypes en ook de mogelijkheid om aante geven of een veld verplicht is of niet.

code:

<input type="number">
<input type="search">
<input type="url">
<input type="email">
<input type="date" required="required">

Tot nu toe is Opera 10 de enige browser die dit een gedeeltelijk ondersteund (en Safari een heel klein beetje), maar andere browsers laten gewoon een tekstveld zien dus je kunt het al gewoon gebruiken. Zelf ben ik al sinds vorig jaar mijn websites in HTML5 aan het bouwen.

Sommige browsers ondersteunen bepaalde elementen nog niet waardoor het toepassen van een stijl op een <article> op deze manier niet werkt:

code:

1
2
3

<article id="myId">
test
</article>

Maar daar is makkelijk omheen te werken door dit te doen:

code:

<article>
<div  id="myId">
test
</div>
</article>

Op deze manier kan je een bestaande website makkelijk voorzien van semantiek door gewoon de doctype aan te passen langzaam aan tags en attributen aan je code toe te voegen.

Waar ik zelf vooral op zit te wachten is op ondersteuning van <datalist> met een externe bron gegevens op te halen, waarmee je een autocomplete kan bouwen. Dat kan ook al met diverse Javascript oplossingen, maar daarbij moet je steeds in JavaScript velden registreren terwijl je in HTML5 het veld zelf de datalist aanroept wat wel zo handig is als je invoervelden dynamisch worden aangemaakt.

Aan de inhoud van de bovenstaande tekst kunnen geen rechten worden ontleend, tenzij dit expliciet in dit bericht is verwoord.

zaterdag 8 augustus 2009 17:12

Acties:

0 Henk 'm!

Kiphaas7

Topicstarter

Johnny schreef op zaterdag 08 augustus 2009 @ 10:30:
Het meest interessante aan HTML5 vind ik de nieuwe mogelijkheiden voor formulieren, de nieuwe datatypes en ook de mogelijkheid om aante geven of een veld verplicht is of niet.
code:
1
2
3
4
5
<input type="number">
<input type="search">
<input type="url">
<input type="email">
<input type="date" required="required">
Tot nu toe is Opera 10 de enige browser die dit een gedeeltelijk ondersteund (en Safari een heel klein beetje), maar andere browsers laten gewoon een tekstveld zien dus je kunt het al gewoon gebruiken. Zelf ben ik al sinds vorig jaar mijn websites in HTML5 aan het bouwen.

Opera 9.5+ toch?

Johnny schreef op zaterdag 08 augustus 2009 @ 10:30:
Sommige browsers ondersteunen bepaalde elementen nog niet waardoor het toepassen van een stijl op een <article> op deze manier niet werkt:

Iets specifieker: alleen Internet Explorer.

Johnny schreef op zaterdag 08 augustus 2009 @ 10:30:
Maar daar is makkelijk omheen te werken door dit te doen:
code:
1
2
3
4
5
<article>
<div  id="myId">
test
</div>
</article>
Op deze manier kan je een bestaande website makkelijk voorzien van semantiek door gewoon de doctype aan te passen langzaam aan tags en attributen aan je code toe te voegen.

mwah, dus je voegt de tags alleen maar toe voor de semantiek? Ik weet eerlijk gezegd niet wat minder erg is, een extra (nutteloze voor alle browsers behalve IE) div toevoegen of een paar regels javascript om IE die tags te laten herkennen...

zondag 9 augustus 2009 14:04

Acties:

0 Henk 'm!

alienfruit

the alien you never expected

Ach ja, het probleem is een beetje dat voor de nieuwe HTML5 animatie mogelijkheden via de transforms in CSS3 en <canvas />. Er eigenlijk een te grote drempel is voor de gemiddelde webdesigners. Het is een stuk lastiger mee te animeren dan bijv. Flash. Ik denk dat het mooi zou zijn als er zo'n soort IDE of tool komt voor de HTML5 dingen. Verder natuurlijk wel een leuke ontwikkeling.

maandag 10 augustus 2009 11:19

Acties:

0 Henk 'm!

IntToStr

Ik ben bij een nieuw projectje nu wel begonnen met langzaam richting html5 te gaan. Dit in de hoop dat er in het komende jaar door de browsers een flinke slag wordt gemaakt met de implementatie van html5... Op dit moment gebruik ik nog niet de nieuwe tags, want deze worden naar mijn zin gewoon nog niet genoeg ondersteund.

Er zitten een hoop nieuwe leuke dingen in en css3 is ook mooi, maar zoals met alles in deze business kun je het eigenlijk pas gebruiken als alle browsers het implementeren. En zolang voornamelijk oude IE versies 'populair' blijven zal dit wel weer veel te lang gaan duren...

(Las vandaag nog iets over Orange in de UK, waar medewerkers een boete krijgen als ze firefox installeren ipv het verplichte gebruik van IE6 en de vele overheidsinstellingen waar ze misschien in de loop van 2010 toch gaan overstappen naar IE7... Lang leve de vooruitgang.)

maandag 10 augustus 2009 12:07

Acties:

0 Henk 'm!

Arnold

IntToStr schreef op maandag 10 augustus 2009 @ 11:19:
(Las vandaag nog iets over Orange in de UK, waar medewerkers een boete krijgen als ze firefox installeren ipv het verplichte gebruik van IE6 en de vele overheidsinstellingen waar ze misschien in de loop van 2010 toch gaan overstappen naar IE7... Lang leve de vooruitgang.)

De voornaamste reden is Windows XP. Door de te lange levensduur van Windows XP met daarbij het blijven ondersteunen van Internet Explorer 6 door Microsoft zijn bedrijven niet "genoodzaakt" hun infrastructuur te moderniseren. Intranet-applicaties welke ontwikkeld zijn rond de lancering van Windows XP, of nog zelfs enige jaren daarna, hebben vaak een lange levensduur gekregen, zonder daarbij te kijken naar de levensduur van Internet Explorer 6 zelf.

Daartegenover staat de enorme progressie van de laatste jaren op webgebied en de nieuwe browser-oorlog die hieruit is ontstaan bij de alternatieve partijen als Mozilla, Opera en Webkit. De laatste 3 jaar zijn de mogelijkheden voor webontwikkelaars enorm gegroeid. Ook het besef dat er standaarden zijn is door de browser-oorlog voor "leken" duidelijk geworden. Niet direct de standaarden, maar wel dat de webbrowsers verschillend handelen.

Microsoft kan hier echter niet in meegaan omdat ze te maken hebben met een gebruikersgroep die dit financieel en/of qua planning nog niet kan verwerken. Hierdoor moeten ze ondersteuning blijven bieden aan Internet Explorer 6 en Internet Explorer 7 nu Internet Explorer 8 al uit is, welke zelfs voor 99% IE7 kan emuleren. Microsoft zou eigenlijk Internet Explorer 7 ondersteuning moeten stoppen en in plaats daarvan extra ondersteuning moeten geven een de "Internet Explorer 7 Emulatie mode" in Internet Explorer 8.
Windows 7 bied gelukkig Windows XP emulatie mode, waardoor het mogelijk wordt via het Domain af te dwingen bepaalde applicaties via Emulatie mode te draaien (Intranet + Internet Explorer 6 iemand?).
Als deze modus ook wordt ondersteund in Internet Explorer "Future" zou het de levensduur van Intranet applicaties verlengen, waar de normale websites wel de laatste final standaarden kunnen gebruiken.

HTML5 en CSS3 zijn nog lang niet klaar. Microsoft is goed te begrijpen dit nog niet te willen verwerken. Hun gebruikers (bedrijven) zijn zo talrijk dat als er iets veranderd aan de specificatie dit zal betekenen dat er nog jaren gebruikers (bedrijven) zijn die dit verkeerd getoond zullen krijgen. Als een bedrijf nu een intranet op de HTML5 draft implementatie van Microsoft zal baseren en dit blijkt over, zeg, twee jaar compleet omgegooid te zijn zullen de support contracten met Microsoft flink onder de loep worden genomen en Microsoft hier flink gezichtsverlies door krijgen.

maandag 10 augustus 2009 13:45

Acties:

0 Henk 'm!

IntToStr

In principe mee eens. Het zou alleen leuk zijn als ook oudere versies van IE een update zouden krijgen zodat ze in combinatie met een nieuw doctype, zoals die van html5, wel moderne technieken aan zouden gaan kunnen. Desnoods een extra instructie in de html opnemen om oude versies van IE in bijv. IE8 modus te kunnen laten draaien qua engine. Voor bestaande intranetsites kan dan gewoon de oude ellende worden gebruikt.

Dit is waarschijnlijk alleen wishful thinking, dus voorlopig zal er wel weinig veranderen. Blijft toch jammer dat er in een relatief nieuw werkgebied, waarin nog constant wordt vernieuwd, men nu al zo vastzit aan oude rommel dat dit de vooruitgang zwaar in de weg zit.

maandag 10 augustus 2009 14:49

Acties:

0 Henk 'm!

RobertMe

alienfruit schreef op zondag 09 augustus 2009 @ 14:04:
Ach ja, het probleem is een beetje dat voor de nieuwe HTML5 animatie mogelijkheden via de transforms in CSS3 en <canvas />. Er eigenlijk een te grote drempel is voor de gemiddelde webdesigners. Het is een stuk lastiger mee te animeren dan bijv. Flash. Ik denk dat het mooi zou zijn als er zo'n soort IDE of tool komt voor de HTML5 dingen. Verder natuurlijk wel een leuke ontwikkeling.

Waarvoor is SVG dan weer bedoeld? Daarin kun je ook animeren e.d., maar daarvoor is de ondersteuning ook zeer ver te zoeken, volgensmij heeft alleen Opera al ondersteuning voor verschillende versies van SVG, alle andere browsers doen er helemaal niks mee, of hebben maar beperkte ondersteuning.

Canvas is toch meer 3D etc, eventueel wat tekenen zelf (heb eens een voorbeeld gezien van paint in je browser met canvas), maar voor plaatjes (met animaties) kun je toch beter SVG gebruiken? Ik denk dat 9 van de 10 sites die nu flash gebruiken, ook af kunnen zonder flash, en dan helemaal (ziet er leuk uit, maar werkt wel zwaar irritant), of met SVG als vervanging (wel het mooie kunnen maken, maar nergens last van hebben).
Denk bijv. aan image slideshows, als je daar met flash gaat werken zorgt alleen maar voor problemen (ligt altijd over de hele pagina, kunt niet bookmarken, etc), dit zijn dingen die ook met html+css+js kunnen, of misschien iets met SVG als het er echt leuk uit moet zien (maar dan moet er natuurlijk wel goede ondersteuning van SVG zijn in de verscheidene browsers)

Denk ook dat MS niet veel zin heeft in de vernieuwingen op browser gebied om Silverlight te pushen zodat toch iedereen bij MS moet blijven (al is het maar het windows platform, omdat Silverlight dus ook al in de andere browsers werkt)

maandag 10 augustus 2009 15:59

Acties:

0 Henk 'm!

rhodium

RobertMe schreef op maandag 10 augustus 2009 @ 14:49:
[...]

Waarvoor is SVG dan weer bedoeld?

Zover mij kennis gaat dan is het bedoeld voor grafieken en basis animaties om grafieken realtime te kunnen presenteren. Het werkt wel redelijk en met een plugin voor IE6 of update is het beschikbaar op alle browsers. Nadeel was dat je het grafiek niet lekker kon opslaan. Grafiek kopieeren en plakken in een word doc liet te wensen over.

dinsdag 11 augustus 2009 01:50

Acties:

0 Henk 'm!

Fuzzillogic

Cool

RobertMe schreef op maandag 10 augustus 2009 @ 14:49:
[...]

Waarvoor is SVG dan weer bedoeld? Daarin kun je ook animeren e.d., maar daarvoor is de ondersteuning ook zeer ver te zoeken, volgensmij heeft alleen Opera al ondersteuning voor verschillende versies van SVG, alle andere browsers doen er helemaal niks mee, of hebben maar beperkte ondersteuning.

Ook firefox en webkit hebben support voor SVG. Hoe compleet die is weet ik niet.

Canvas is toch meer 3D etc,

Canvas is vooralsnog geen 3D, maar enkel een zielig hoopje 2D. Als je het qua features en snelheid vergelijkt met al zoiets als Java2D dan komt bij mij toch het woordje "pathetic" opborrelen eigenlijk. Komt nog bij dat het dus compleet losstaat van SVG, terwijl het gezien het 2D-karakter toch met elkaar te maken lijkt te hebben, nietwaar?

rhodium schreef op maandag 10 augustus 2009 @ 15:59:
[...]
Zover mij kennis gaat dan is het bedoeld voor grafieken en basis animaties om grafieken realtime te kunnen presenteren. Het werkt wel redelijk en met een plugin voor IE6 of update is het beschikbaar op alle browsers. Nadeel was dat je het grafiek niet lekker kon opslaan. Grafiek kopieeren en plakken in een word doc liet te wensen over.

SVG is aardig uitgebreid. Ga maar eens kijken bijv in de gallery van Inkscape. Dat is allemaal SVG, en kun je gewoon bekijken in je browser. (Opera tenminste) Daarnaast kan SVG interessante zaken doen met matrices, die voor een compleet nieuwe set aan designmogelijkheden zorgt. Op de site van Opera staan wel voorbeelden.

SVG is in HTML5 dus inline te gebruiken. Momenteel alleen in XHTML, wat m.i. ook de enige logische weg is. De combinatie CSS + SVG zou misschien ook wel eens zeer interessant kunnen zijn, maar daarvoor ken ik de mogelijkheden van SVG niet goed genoeg. Ik kan me voorstellen dat je ipv zo'n archaïsche, statische bitmap (die bitmaps worden dikwijls met vectorgraphics gemaakt.. dus waaromdan nog die tussenstap naar bitmaps?) een compacte, perfect meeschalende SVG voor backgrounds gebruikt.

Maargoed, SVG is dus niet specifiek iets van HTML5. Ze waren alleen deze keer slim genoeg om een bestaande, goed ondersteunde standaard te gebruiken binnen HTML5. Jammer dat ze XForms weer vergeten zijn...

dinsdag 11 augustus 2009 02:02

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

Html5

Jammer dat ze XForms weer vergeten zijn..

vziw overlapte dat grotendeels met Web Forms 2.0 wat nu wel in de HTML 5 draft is opgenomen...

Intentionally left blank

dinsdag 11 augustus 2009 09:07

Acties:

0 Henk 'm!

IStealYourGun

Доверяй, но проверяй

@Fuzzillogic voor alle duidelijkheid de HTML van scratch bestaat, deze heeft de naam XHTML 2.0 gekregen en is nog in ontwikkeling.

Edit: Hier een mooie link naar een PDF versie van de draft: http://www.whatwg.org/spe...current-work/html5-a4.pdf

[ Voor 32% gewijzigd door IStealYourGun op 11-08-2009 09:28 ]

dinsdag 11 augustus 2009 09:40

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

Html5

IStealYourGun schreef op dinsdag 11 augustus 2009 @ 09:07:
@Fuzzillogic voor alle duidelijkheid de HTML van scratch bestaat, deze heeft de naam XHTML 2.0 gekregen en is nog in ontwikkeling.

niet meer dus

Intentionally left blank

dinsdag 11 augustus 2009 10:16

Acties:

0 Henk 'm!

Clay

cookie erbij?

Canvas en SVG zijn twee totaal verschillende dingen. SVG is een xml based formaat voor 2D vectoren met wat script om de boel te manipuleren (interactie, manipulatie van de dom). Canvas is een pixelbuffer, en geniet door de afwezigheid van een dom en alle bijbehorende overhead een gigantisch performance voordeel, maar je moet wel alles zelf doen ja. De beperkingen daarvan zitten alleen in je eigen hoofd, niet in canvas

op chrome experiments staan mooie dingen

Instagram | Flickr | "Let my music become battle cries" - Frédéric Chopin

dinsdag 11 augustus 2009 11:59

Acties:

0 Henk 'm!

Fuzzillogic

Cool

crisp schreef op dinsdag 11 augustus 2009 @ 02:02:
[...]

vziw overlapte dat grotendeels met Web Forms 2.0 wat nu wel in de HTML 5 draft is opgenomen...

Wat ik er zo van zie is XForms toch nog een stuk flexibeler eigenlijk. Het gaat er ook om welke data er uiteindelijk naar de server wordt gestuurd. Bij HTML5 lijkt dat dus nog steeds de basale key-value-pairs te zijn, terwijl XForms een nette gestructureerde zelf te definiëren XML oplevert.

Al met al is HTML5 een prima naam. Maar ik zie HTML4 nog steeds als een leuke proof-of-concept of prototype. Experiment geslaagd hoor, maar er zijn ook wat design flaws aan het licht gekomen, of andere zaken die door voortschrijdend inzicht vervangen/verbeterd kunnen worden. En er zijn genoeg zaken die reeds bestaan, en die prima opgenomen hadden kunnen worden in de nieuwe spec. XML dus primair, maar ook XSLT, dat veel/alle browser nu toch al ondersteunen op hun eigen manier, XForms dus, en dom lvl3 load en save als gestandaardiseerde versie van het proof-of-concept/prototytpe-experimentje genaamd "AJAX", MathML, ...

Die compatibiliteit van HTML5 met HTML4 is mij iig een doorn in het oog. Ik had liever een NewHTML ofzo gezien. Ja, in het Engels spreek je het uit als "New Age Tee Em El". Pun intended, maar dan bedoeld als HTML voor een nieuw tijdperk, niet het zweverige geitenwollensoktype

. Ik snap niet waarom ze zo strak aan de compatibiliteit vastgehouden hebben.

dinsdag 11 augustus 2009 13:58

Acties:

0 Henk 'm!

BtM909

Watch out Guys...

Ik snap niet waarom ze zo strak aan de compatibiliteit vastgehouden hebben.

Omdat het erom ging dat browsers zo snel mogelijk support voor HTML5 konden inbouwen

Ace of Base vs Charli XCX - All That She Boom Claps (RMT) | Clean Bandit vs Galantis - I'd Rather Be You (RMT)
You've moved up on my notch-list. You have 1 notch
I have a black belt in Kung Flu.

maandag 17 augustus 2009 01:26

Acties:

0 Henk 'm!

Verwijderd

BtM909 schreef op dinsdag 11 augustus 2009 @ 13:58:
[...]

Omdat het erom ging dat browsers zo snel mogelijk support voor HTML5 konden inbouwen

Dat is leuk meegenomen, maar een voorwaarde die nogal op de achtergrond speelt.

Regeren is vooruitzien. Een nieuwe markup language ontwikkelen ook. Wat je over honderd jaar niet wilt, is een web met websites geschreven in twintig totaal verschillende markup languages. Want dat betekent dat een browser al die talen moet ondersteunen. Dat lukt nog wel voor HTML 4 (met al zijn quirks modes) en HTML 5 of XHTML 2. Maar tien jaar later krijg je dikkeShitML 1, vijf jaar daarna dikkeShitML 1.5, tien jaar later marsAlienML 0.99… Probeer daar maar eens een browser voor te schrijven. Oude browsers evolueren mee en kunnen ondersteuning bieden (executables van 100MB met 1GB aan libs), maar nieuwe browsers komen niet meer van de grond.

Na jarenlang gehannes wil het W3C (gepusht door het WHATWG en de HTML-WG) af van versies. Dat kan, met progressive enhancement, MITS versies backwards compatible zijn. Want oudere browsers, die <semanticChristmasTreeBlinkWithNicePseudoColors> niet snappen, zullen de tag negeren maar toch de tekst weergeven. Net als nu met bijvoorbeeld Lynx. De volgende versie wordt dus HTML 5; de versie daarna blijft HTML 5. Als het gaat zoals men wil, komt er geen HTML 6. HTML 5 blijft evolueren. Bepaalde HTML-aanvullingen zullen na verloop van tijd stabiel worden verklaard, dat natuurlijk wel, maar deze veranderingen zullen geen versienummer krijgen.

Het hele idee achter dit model is dat je documenten van nu over honderd jaar nog kunt lezen. Een grote verscheidenheid aan mensen met kennis over en visie op het web zien backwards compatibility als the way to go. Of ze gelijk hebben is de vraag, maar ik ben het met ze eens dat het met de kennis van nu de beste manier is om het web door te laten groeien met behoud van hedendaagse websites.

maandag 17 augustus 2009 01:56

Acties:

0 Henk 'm!

Fuzzillogic

Cool

Crisp kwam een tijd geleden ook met zo'n argument, en imo is het een slecht argument. Compatibiliteit zal een probleem blijven, maar wel een kleine. Het gaat om documenten met een eenvoudige structuur, die (mist de structuur juist toegepast is) nu al eenvoudig is om te zetten naar andere ML's.

HTML is human readable, en dat zullen volgende versies ook zijn. Dat maakt dat het gewoon nooit een probleem zal zijn om er een parser voor te maken, from scratch, zonder enige documentatie. Maar waarom zou je? Die parsers zijn er nu plenty, waarvan er velen open source zijn, en waarvan de broncode massaal in "the cloud" aanwezig is. Die zullen dus ook niet verdwijnen in de nabije toekomst.

Er zijn trouwens al genoeg voorbeelden waar oude talen prima door hedendaagse software worden ondersteund: Opera ondersteunt WML. Vrijwel elke mediaspeler ondersteunt MPEG1 - wat overigens verre van human readable is. Ook Gopher zal vast nog wel ondersteund worden, al was het maar om de software daarvoor in een emulator/VM te draaien. Dat is ook al heel normaal: DOSbox, WindowsXP-mode in Win7, Wii VirtualConsole etc. De huidige HTML, of een hele nieuwe specificatie daarvan, zal dus altijd leesbaar blijven.

Mijn conclusie is dan ook dat compatibiliteit helemaal niet zo belangrijk is voor de lange termijn. Ik wil NU met een fijn systeem werken. Het is allemaal goed gedocumenteerd, software is in de cloud, dus over 50 jaar zal dat ongetwijfeld ook geen enkel probleem zijn.

Regeren is vooruitzien, maar men moet niet gaan beweren koning van de tijd te zijn.

En nu ga ik toch even speculeren, maar het zou me niets verbazen als er over 30 jaar een AI is, voor wie het interpreteren en converteren van dit soort oude formaten easy peasy is.

[ Voor 3% gewijzigd door Fuzzillogic op 17-08-2009 01:59 ]

maandag 17 augustus 2009 10:06

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

Html5

Fuzzillogic schreef op maandag 17 augustus 2009 @ 01:56:
[...]

HTML is human readable, en dat zullen volgende versies ook zijn.

human readable als in: het is niet een binary formaat? Hoe leesbaar is het nog als je geen Engels kent? En zelfs als je al Engels kent, hoe natuurlijk is het om bijvoorbeeld <em> te herkennen als nadruk?

[...] Dat maakt dat het gewoon nooit een probleem zal zijn om er een parser voor te maken, from scratch, zonder enige documentatie. Maar waarom zou je? Die parsers zijn er nu plenty, waarvan er velen open source zijn, en waarvan de broncode massaal in "the cloud" aanwezig is. Die zullen dus ook niet verdwijnen in de nabije toekomst.

Er zijn trouwens al genoeg voorbeelden waar oude talen prima door hedendaagse software worden ondersteund: Opera ondersteunt WML. Vrijwel elke mediaspeler ondersteunt MPEG1 - wat overigens verre van human readable is. Ook Gopher zal vast nog wel ondersteund worden, al was het maar om de software daarvoor in een emulator/VM te draaien. Dat is ook al heel normaal: DOSbox, WindowsXP-mode in Win7, Wii VirtualConsole etc. De huidige HTML, of een hele nieuwe specificatie daarvan, zal dus altijd leesbaar blijven.

Mijn conclusie is dan ook dat compatibiliteit helemaal niet zo belangrijk is voor de lange termijn. Ik wil NU met een fijn systeem werken. Het is allemaal goed gedocumenteerd, software is in de cloud, dus over 50 jaar zal dat ongetwijfeld ook geen enkel probleem zijn.

Regeren is vooruitzien, maar men moet niet gaan beweren koning van de tijd te zijn.

En nu ga ik toch even speculeren, maar het zou me niets verbazen als er over 30 jaar een AI is, voor wie het interpreteren en converteren van dit soort oude formaten easy peasy is.

Ik vind de rest van je betoog behoorlijk gewaagd. Jij meent voorspellingen te kunnen doen over een langere periode vooruit dan dat het digitale tijdperk nu oud is? Eerlijk gezegd vind ik het vertrouwen op het aanwezig zijn van 'de cloud' met al z'n content meerdere decennia vanaf nu bijzonder kortzichtig alsniet gewoonweg een heel gevaarlijke aanname. Assumptions are the mother of all f*ck-ups

Intentionally left blank

maandag 17 augustus 2009 12:59

Acties:

0 Henk 'm!

Fuzzillogic

Cool

crisp schreef op maandag 17 augustus 2009 @ 10:06:
[...]

human readable als in: het is niet een binary formaat? Hoe leesbaar is het nog als je geen Engels kent? En zelfs als je al Engels kent, hoe natuurlijk is het om bijvoorbeeld <em> te herkennen als nadruk?

Dat is ook wel heel erg vergezocht. Alsof er niemand in de buurt is met kennis van Engels? En dat <em> de ingesloten tekst zal benadrukken zal met een paar voorkomens van de <em>-tag ook wel duidelijk worden, dat het dan dan wel zal zijn geweest.

Ik vind de rest van je betoog behoorlijk gewaagd. Jij meent voorspellingen te kunnen doen over een langere periode vooruit dan dat het digitale tijdperk nu oud is? Eerlijk gezegd vind ik het vertrouwen op het aanwezig zijn van 'de cloud' met al z'n content meerdere decennia vanaf nu bijzonder kortzichtig alsniet gewoonweg een heel gevaarlijke aanname. Assumptions are the mother of all f*ck-ups

Face it, opslagruimte is inmiddels zo ruim beschikbaar dat er eigenlijk niks meer weggegooid hoeft te worden. Daarnaast zullen er vele kopieën van de betreffende specificaties rondzwerven. Dus de kans dat het de komende 100 jaar verloren gaan acht ik gering.

Ik vind deze aannames minder vergezocht dan de aanname dat de mensheid over 100 jaar moeite zou kunnen hebben met een dan lang vervlogen, maar eenvoudige specificatie als HTML4. Dat we moeten voorkomen dat HTML4/5 ooit in onbruik zou raken omdat er een nieuw incompatibele standaard komt vind ik dan ook maar quatsch. En om dat als reden aan te voeren om géén nieuwe, echt bijdetijdse opvolger van HTML4 te maken net zo.

maandag 17 augustus 2009 13:57

Acties:

0 Henk 'm!

alienfruit

the alien you never expected

Ach zo lang de standaard goed beschreven is maakt een binary formaat niet uit. Alleen als de partij van het formaat vertikt om degelijke documentatie openbaar te maken dan kan een XML variant een stuk makkelijker zijn om uit te vogelen.

maandag 28 september 2009 11:31

Acties:

0 Henk 'm!

Icelus

Quirksmode-blog:

The HTML5 drag and drop disaster
After spending about a day and a half in testing I am forced to conclude that the HTML5 drag and drop module is not just a disaster, it’s a fucking disaster.

The module should be removed from the HTML5 specification straight away, and conforming browsers should disable it at their earliest opportunity pending a complete rewrite from the ground up. Web developers MUST NOT (in the sense of RFC 2119) use HTML 5 drag and drop. They should use old-school scripts instead.

Before we continue I’d like to say that in general I thoroughly approve of the HTML5 specification. Exactly because the spec has such an overall quality I was so surprised (and, frankly, a bit confused and hurt) to find drag and drop a steaming pile of bovine manure.

In fact, it’s so outrageously bad that I’ve gone on strike. I refuse to do any more research on drag and drop. Go do it yourself. Or don’t bother. Whatever. I don’t care.
What follows is a rant laced with profanity. No apologies. Drag and drop deserves no better.

[…]

Developer Accused Of Unreadable Code Refuses To Comment

maandag 28 september 2009 11:41

Acties:

0 Henk 'm!

BtM909

Watch out Guys...

Sure ipv melden aan de WhatWG group gewoon ranten en niet constructief bijdragen...

De mailinglist en Ian e.d. zijn ook totaal niet voor rede vatbaar

Ace of Base vs Charli XCX - All That She Boom Claps (RMT) | Clean Bandit vs Galantis - I'd Rather Be You (RMT)
You've moved up on my notch-list. You have 1 notch
I have a black belt in Kung Flu.

Onderwerpen

HTML5

Korte geschiedenis

Misverstanden en gerelateerde verhitte discussies

HTML5: De voordelen

Nieuwe structurele elementen:

Nieuwe API's:

Forms:

Nieuw doctype:

HTML5: De nadelen

Wat kunnen we er nou op dit moment mee?