Selecteer een pagina


BRON: https://tweakers.net/reviews/2073/all/html5-en-css-3-de-pijlers-van-morgen.html

Geschiedenis van html

Tim Berners-LeeDe HyperText Markup Language is een creatie van Tim Berners-Lee, de Brit die de opmaaktaal in 1991 ontwikkelde om wetenschappelijke documenten van CERN op een samenhangende manier toegankelijk te maken. Daarnaast was Berners-Lee verantwoordelijk voor de eerste server: CERN httpd.

De basis van het op sgml gebaseerde html is de tag, waarmee opmaak, plaatjes, scripts, stylesheets en natuurlijk links in een document kunnen worden opgenomen. Van sommige tags zijn begin- en eindversies, zoals <h1>en</h1>

die het begin en einde van een koptekst aangeven. Andere tags zijn atomair, zoals
voor een regeleinde of voor een afbeelding.

De mogelijkheden van html werden al snel onderkend en er verschenen in de loop der jaren steeds betere browsers, waaronder de beroemde Mosaic- en Netscape-browsers. De evolutie van html is min of meer parallel gaan lopen aan de mogelijkheden van browsers.

Hoewel de IETF in 1993 een eerste draft-versie van html opstelde, heeft html nooit een officiële versie 1.0 gekend. In 1995 keurde de IETF de html 2.0-specificatie wel officieel goed. Door de groeiende populariteit van het world wide web werden er al snel nieuwe opmaakmogelijkheden aan de html-specificatie toegevoegd. Zo kwamen er tabellen, formulieren en image maps.

In 1996 nam het World Wide Web Consortium, oftewel het W3C, het stokje over van de IETF. Mede met inspraak vanuit de nog jonge internetindustrie kwam in januari 1997 html 3.2 tot stand. In deze versie werden diverse visuele opmaaktags van Netscape opgenomen, terwijl een aantal propriëtaire tags van onder andere Microsoft Internet Explorer overboord werden gegooid.

De W3C kwam in december 1997 met een eerste versie van de html 4-specificatie, gevolgd door enkele kleine revisies. Html 4 werd duidelijk beïnvloed door de ‘xml-hype’ onder webdevelopers uit die tijd en de daaruit volgende xhtml-standaard, al was het W3C geen uitgesproken voorstander van xhtml. Uiteindelijk werden drie variaties van html 4 geïntroduceerd: een relatief weinig toegepaste frameset-definitie, een strict-uitvoering die de standaard zou moeten worden en waarbij inmiddels uitgefaseerde tags taboe waren, en een lossere transitional-variant. Die laatste groeide uit tot de meest gebruikte variant, samen met xhtml 1.x.

De opkomst van css

Naast nieuwe tags in html 4, die onder andere meer mogelijkheden boden om complexe webformulieren te presenteren, bood de vernieuwde opmaaktaal ook meer opmaakmogelijkheden dankzij integratie met een andere belangrijke taal: css. Met cascading style sheets werd het aanmerkelijk eenvoudiger om de opmaak van een website te manipuleren, omdat het in css gedefinieerde ontwerp geheel kon worden losgekoppeld van de inhoud.

Css is dan ook mede ontstaan uit de onvrede onder webdesigners over het gebruik van html-tags voor het opmaken van webpagina’s. Documenten werden al snel onleesbaar door een opeenstapeling van html-code. Bovendien vereiste een redesign van een website dat alle html werd herzien, een omslachtige, tijdrovende en vooral erg foutgevoelige klus.

cssDe eerste versie van cascading style sheets, kortweg css 1, gaf ontwikkelaars voor het eerst de mogelijkheid om de opmaak van lettertypen te bepalen, evenals het bepalen van de positie van de elementen van een html-pagina. Een belangrijk en krachtig kenmerk van css-opmaakelementen was bovendien dat eigenschappen overerfbaar zijn, waarmee bedoeld wordt dat een dieper gelegen element automatisch de eigenschappen van een parent krijgt. Daardoor hoeft er minder code geschreven te worden.

Hoewel versie 1 van css al eind 1996 door de CSS Working Group van de W3C werd ontwikkeld, verliep de adoptie van deze opmaaktaal zeer langzaam. Internet Explorer 3 ondersteunde een rudimentaire vorm, maar pas met de komst van de Mac-versie van IE5 in 2000 werd de css 1-specificatie vrijwel geheel door een browser ondersteund.

Hoewel de ondersteuning voor cascading style sheets in de daaropvolgende jaren verbeterde, ontstonden er verschillende interpretaties tussen met name Internet Explorer en de browsers van Netscape. Css 2, al in mei 1998 voorzien van een W3C-recommendation, moest daar een einde aan maken, maar bij deze versie werden de nodige bugs en inconsistenties in de taal zelf ontdekt. Deze fouten werden grotendeels gecorrigeerd met css 2.1, de huidige officiële standaard van de W3C, die door vrijwel alle browsers wordt ondersteund.

Css 2.1, waar tot 2010 aan is gesleuteld, biedt een webdesigner vrij krachtige opmaakmogelijkheden. Zo zijn er meer manieren om elementen te positioneren, waaronder absolute en relatieve positionering en de z-indexering voor het aanpassen van de ‘diepte’ van objecten. Ook zijn er meer opmaakmogelijkheden voor lettertypen, zoals schaduwen. Tot slot bevat deze standaard verschillende media types. Hiermee kunnen afwijkende opmaken voor verschillende mediasoorten worden gegeven, bijvoorbeeld voor mobiele apparatuur of voor prints.

De opkomst van html5

html 5 logoBedrijven als Google wisten in de afgelopen zes jaar html 4 in combinatie met onder andere javascript, Flash en Java webapplicaties op de kaart te zetten. Marketingafdelingen bombardeerden deze combinatie al snel tot dynamic html, oftewel dhtml, maar een officiële standaard is dit niet.

Niet veel later raakte Ajax in zwang, een combinatie van xml, html, javascript en het opslaan en manipuleren van data via het document object model: een boomstructuur waarin alle elementen uit een html- of xml-pagina zijn ondergebracht.

Webgebruikers konden met de eerste webapplicaties al eenvoudige toepassingen binnen de browser draaien, maar populaire webapps als Gmail maakten dat gebruikers steeds meer functionaliteit en steeds meer mogelijkheden verwachtten. Mede door deze ontwikkeling – inmiddels ligt het modewoord ‘clouddiensten’ op ieders lippen – is de vraag naar nieuwe mogelijkheden in de html-opmaaktaal en daaraan gerelateerde standaarden toegenomen. Html5 moet daarvoor zorgen.

Html5 is niet nieuw; een eerste draft werd al in januari 2008 gepubliceerd, nadat de W3C had besloten om de ontwikkeling van xhtml 2.0 niet door te zetten. Als basis voor de eerste draft werd het werk van de al langer actieve Whatwg-werkgroep gebruikt. In deze groep hadden onder andere Apple, Opera en Mozilla zitting. Ook besloot de W3C dat de term ‘html5’ als officiële aanduiding voor de standaard zou gaan gelden.

Hoewel er jaren in relatieve stilte aan html5 werd gewerkt, haalde de standaard in 2007 de publiciteit toen Apple aankondigde dat de eerste iPhone geen Flash zou ondersteunen. Volgens Apple-voorman Steve Jobs zou html5 op termijn voldoende mogelijkheden bieden om Flash overbodig te maken. In 2010 herhaalde Jobs zijn woorden bij de introductie van de iPad, waarna ook de mainstream-pers op de in aanbouw zijnde webstandaard dook.

Een andere reden voor de groeiende belangstelling voor html5 is de toegenomen eensgezindheid onder browserbouwers om met eenduidige webstandaarden te komen. Microsoft, dat er jarenlang een op zijn minst eigenzinnige interpretatie van webstandaarden op nahield, besloot met Internet Explorer 8 een andere koers in te slaan. IE9 wordt door de softwaregigant zelfs gepromoot als een van de snelste en meest complete html5-browsers van dit moment.

Maar de concurrende browserbouwers zitten niet stil; Firefox heeft met versie 4 een browser gebouwd die een breed aantal html5-elementen kan verwerken. Google Chrome, gebaseerd op de opensource WebKit-engine, en het Noorse Opera geven elke nieuwe browserversie een steviger html5-fundament.

Vernieuwing

Een belangrijke verbetering in html5 is het uniform afhandelen van fouten door browsers. Hierdoor moet de gebruiker in elke browser, ook bij html-fouten, alle content te zien krijgen. In tegenstelling tot het fallback-mechanisme van html5 is in html 4 de foutafhandeling niet gedefinieerd, waardoor browsers onderling verschillende weergaves van sites met foutjes produceerden.

In html5 worden de meeste elementen gehandhaafd; zo komt er geen eind aan het discutabele maar wijdverbreide gebruik van tabellen voor opmaakdoeleinden. Na een lange discussie besloot de W3C om het toepassen van tabellen voor dergelijke doeleinden in feite te gedogen. Het belangrijkste praktische argument daarbij is dat nog talloze websites tabellen voor de opmaak gebruiken, in plaats van css-code. Om screen readers voor blinden en slechtzienden tegemoet te komen, zouden webdesigners echter wel role=”presentation” aan de tabel moeten meegeven, zo adviseert de W3C.

Het definiëren van een html5-document is eenvoudig: in principe volstaat het opgeven van een doctype om ervoor te zorgen dat een browser de pagina correct rendert. Het is dus niet strikt noodzakelijk om body- en header-tags te gebruiken, al is het voor de leesbaarheid wel aan te bevelen.

Een belangrijke nieuwe feature van html5 is de mogelijkheid om een document logischer op te bouwen. Hiervoor zijn een aantal nieuwe elementen toegevoegd, waaronder , , en . Deze semantische tags bevatten elementen die op vrijwel elke website voorkomen en beschrijven ruwweg de functie van de inhoud. Webontwikkelaars zullen het gebruik van deze nieuwe elementen vermoedelijk wel kunnen waarderen, omdat er een einde gemaakt kan worden aan het strooien met op het eerste gezicht gelijkwaardige div-elementen.

Ontwikkelaars zullen mogelijk wel even moeten wennen aan deze nieuwe elementen, omdat bijvoorbeeld de tag in principe overal in een document gebruikt kan worden. Verder moet de -tag anders geïnterpreteerd en ingezet worden dan de -tag.

De nieuwe elementen worden in Internet Explorer tot en met versie 8 echter niet standaard ‘herkend’ en er is een javascript-trucje nodig om ze in de dom beschikbaar te stellen, zodat de vormgeving met css afgehandeld kan worden. Webontwikkelaar Remy Sharp heeft zelfs een scriptje gemaakt dat de elementen in de dom van IE aanmaakt. Het was echter de Nederlander Sjoerd Visscher die al in 2008 als eerste met dit idee op de proppen kwam.

Krachtiger webformulieren

Met html5 heeft de developer voortaan de mogelijkheid om de -tag, die is bedoeld voor het leggen van hyperlinks, zogenaamde flow content te laten bevatten, zoals meerdere sectioning- en headingelementen. Hierdoor hoeft niet langer per element een link toegevoegd te worden. Verder krijgt deze tag, net als en , het nieuwe attribuut media. Hiermee kan worden aangegeven naar welk soort content wordt gelinkt. Dit attribuut kan gecombineerd worden met het attribuut rel, dat de relatie beschrijft met de bron, en hreflang, dat de taal van het doel beschrijft: .

Kalender in webformulier dankzij html 5In html5 worden webformulieren krachtiger dankzij nieuwe input types. Zo kan met input type=email bijvoorbeeld gecontroleerd worden of een e-mailadres geldig is en met input type=tel kan een invoerveld voor het invullen van telefoonnummers worden gegenereerd. Een bijzonder input-type is range, waarbij een begin- en eindwaarde meegegeven moet worden. Browsers presenteren dit inputtype veelal als een slider. Enkele browsers kunnen bovendien bij het ingeven van een datum inmiddels ook al een kalender tonen.

De nieuwe input-types worden helaas nog niet door alle browsers volledig ondersteund. Via de Html5 Inputs and attribute-testpagina kan gecontroleerd worden welke input-types in een bepaalde browser te gebruiken zijn.

Naast nieuwe input-types zijn er in html5 ook veel nieuwe form attributes opgenomen. Zo kan met autocomplete worden aangegeven dat een formulier of invoerveld een functie moet aanbieden voor het automatisch aanvullen van data. Een handig nieuw attribuut luistert naar de naam autofocus. Hierbij kan een invoerveld binnen een formulier direct ingevuld worden.

Met het placeholder-attribuut kan in een invoerveld alvast tekst geplaatst worden, bijvoorbeeld om een hint of een voorbeeld te geven. Ook een nuttig nieuw attribuut is required, dat aangeeft dat een formulier niet gesubmit kan worden als een bepaald veld leeg blijft. Een krachtig attribuut luistert naar de naam list. Deze maakt het in combinatie met het -inputelement mogelijk om een lijst voorkeuzemogelijkheden aan te bieden.

Door het toepassen van de attributen min, max en steppattern ten slotte kan de input van een formulier met regular expressions worden gevalideerd. De syntax is gelijk aan die van regular expressions in javascript.

Rich media in html5

Webbrowsers kunnen bepaalde content niet zelf weergeven en zijn daarvoor aangewezen op plug-ins. Bekende voorbeelden zijn Flash, Java en Silverlight. Html5 moet plug-ins deels overbodig gaan maken met de komst van de elementen audio en video.

WebM logoMet name over de komst van het video-element is veel te doen geweest, omdat er tussen de browserbouwers geen overeenstemming kon worden bereikt over de te gebruiken codecs. Google introduceerde het licentievrije WebM-formaat, gebaseerd op de VP8-codec, en kreeg daarbij steun van Mozilla en Opera. Microsoft en Apple houden echter vast aan de niet vrije maar breed toegepaste h.264-codec. Door deze onenigheid is er geen standaardformaat voor het video-element. Dat verhindert echter niet dat deze op websites wordt toegepast.

Een webontwikkelaar kan de tag diverse attributen meegeven om de weergave van een video te beïnvloeden. Zo laat het attribuut autoplay een filmpje direct starten en loop zorgt voor een automatische herstart. Om de gebruiker meer controle te geven over een video, kan met het controls-attribuut een aantal knoppen onder de video worden weergegeven. Standaard dienen browsers onder andere play-, pauze-, stop- en fullscreen-knoppen en volumeregeling te presenteren.

De meeste browsers kunnen met meerdere videocontainers overweg. Flv, het formaat voor Flash-video, wordt in combinatie met de Flash-plugin door veel html5-browsers ondersteund. Ook mp4-bestanden met mpeg4- en h.264-video’s zijn meestal welkom. Minder breed geaccepteerd is de ogg/ogv-container. Deze biedt video die met de vrij te gebruiken Theora-codec is gecomprimeerd, en werd in de eerste html5-specificatie nog als uitgangspunt genomen. Onder druk van Nokia en Apple werd deze container echter geen standaard. Verder is er dus WebM, het eveneens royaltyvrije videoformaat van Google.

Naast het video-element kan met behulp van html5 ook een audio-tag toegepast worden. Dit element kan de gebruiker een audiofragment laten horen, maar er kunnen ook streams mee worden afgespeeld. De codec-ondersteuning verschilt ook hier weer per browser. Zo weigeren Opera en Firefox mp3-bestanden af te spelen, wederom vanwege rechtenkwesties. IE9 en Safari weigeren op hun beurt weer Ogg Vorbis-materiaal. Het veiligst is het wav-formaat, maar dat is weer ongecomprimeerd en dus ruimteverslindend. Of aan de versnipperde ondersteuning een einde zal komen, is nog maar de vraag.

Svg en canvas

Behalve voor nieuwe audio- en video-opties in html5 heeft de W3C ook het groene licht gegeven voor de ondersteuning van het svg- of scalable vector graphics-formaat. Dit op xml gebaseerde open bestandsformaat beschrijft vectorafbeeldingen. Svg-objecten kunnen met javascript en css gemanipuleerd worden.

De meeste moderne browsers kunnen al svg-graphics weergeven en de grafische mogelijkheden van het formaat zijn vrij groot, zo laat bijvoorbeeld de website Svg-wow.org zien. Een voordeel van svg-graphics ten opzichte van bitmaps is dat afbeeldingen zonder kwaliteitsverlies kunnen worden vergroot. Het formaat leent zich vooral goed voor het manipuleren van tekst en lijntekeningen.

Een geheel nieuw element in html5 luistert naar de naam

Canvas-demo
Om het canvas te vullen, dient gebruik te worden gemaakt van javascript. Zo kunnen bitmaps in hoog tempo worden gerenderd, zeker als de browser hardwarematige versnelling via de gpu biedt. Ondanks de beperkingen van canvas zijn er krachtige toepassingen mee te bouwen, zoals bijvoorbeeld de webapplicatie Darkroom laat zien. Ook de website Canvasdemos toont de mogelijkheden van het nieuwe html5-element, waaronder een aantal eenvoudige games. Verder zijn er diverse javascript-bibliotheken beschikbaar die het maken van canvas-graphics vergemakkelijken. RGraph, een grafische bibliotheek voor het maken van grafieken, is daar een goed voorbeeld van.

Toegankelijkheid

et toegankelijk houden van een website voor visueel gehandicapten kan ontwerpers voor behoorlijke uitdagingen stellen. Blinden en slechtzienden maken vaak gebruik van zogenaamde screen readers, die tekstuele content op websites kunnen omzetten naar gesproken tekst. Deze readers kunnen echter niet altijd even goed overweg met met name dynamische content.

Toegankelijkheid logoHtml5 moet dergelijke software verder op weg helpen. Daarbij gebruikt de W3C de Aria-standaard, die met name geschikt zou zijn voor het toegankelijker maken van webapplicaties die gebruik maken van technieken als Ajax en javascript.

De belangrijkste verbetering is de toevoeging van het attribuut role. Dit attribuut moet aangeven hoe delen van een webpagina geïnterpreteerd moeten worden. Zo kan bijvoorbeeld een banner worden gemarkeerd met role=”banner”, terwijl een zoek-functie met role=”search” kan worden aangewezen. Dit gebruik wordt de landmark role genoemd.

Naast de landmark role is in de html5-specificatie ook de document structure role opgenomen, waarmee statische content in de documentstructuur kan worden aangegeven. Belangrijk is daarbij vooral het role-type document, waarmee het onderscheid tussen statische en dynamische delen van een pagina kan worden gemaakt.

Twee andere relevante attributen zijn aria-live en aria-atomic. Beide zijn nuttig bij het gebruik van dynamische webapplicaties op basis van bijvoorbeeld Ajax. Met deze parameters kan bijvoorbeeld worden aangeven dat een dynamische update prioriteit moet krijgen en dus direct door de software moet worden voorgelezen.

Nieuwe api’s
Naast nieuwe elementen en tags in de html5-specificatie zijn er door de W3C ook diverse ondersteunende application programming interfaces ontwikkeld, zoals de Geolocation-api. Met behulp van een aantal javascript-commando’s kunnen browsers hiermee gps-data gebruiken. De locatie van het device kan ook worden bepaald aan de hand van mac-adressen van naburige wifi- en bluetooth-apparatuur, rfid-tags of aan gsm-masten gekoppelde cell-id’s. De browser zou automatisch de nauwkeurigste locatiegegevens moeten selecteren.

GeolocationDe Geolocation-api, die grotendeels gebaseerd is op de Google Gears Geolocation-api, is met name nuttig voor ontwikkelaars van mobiele applicaties. Vrijwel alle mobiele platformen, waaronder iOS en Android, ondersteunen geolocatie via de browser. Uit privacy-overwegingen moet in de meeste browsers wel eerst expliciet toestemming door de gebruiker worden gegeven voordat de locatiegegevens toegankelijk worden.

Een andere nieuwe api draagt de naam drag-and-drop-api en moet het mogelijk maken om elementen binnen een webpagina te verplaatsen. Om dergelijke acties mogelijk te maken, moeten objecten met het attribuut draggable=”true” gemarkeerd worden en moet met javascript ook een doellocatie worden opgegeven. In principe kan ieder element op een webpagina versleept worden.

Om de reactiesnelheid van webapplicaties te verbeteren, is verder de Web Workers-api ontwikkeld. Een ontwikkelaar kan javascript-code hiermee in een aparte thread laten draaien, terwijl de gebruiker ongestoord kan doorwerken met bijvoorbeeld een webapplicatie, waarin uiteraard ook weer scripts kunnen worden opgenomen.

Web Workers zijn volgens de W3C vooral nuttig in de achtergrond scripts te draaien die geen interactie met de gebruikersinterface nodig hebben. Ontwikkelaars moeten echter oppassen dat ze niet te veel Workers activeren, omdat die de browser dan alsnog kunnen vertragen. Bovendien worden Web Workers door onder andere Internet Explorer en de Android-browser nog niet ondersteund.

Offline-gebruik
Html5 biedt bouwstenen om webapplicaties offline te gebruiken. Zo kan een gebruiker bijvoorbeeld een e-mailtje in zijn webmailclient opstellen, ook al is zijn 3g-verbinding toevallig even weggevallen. Een website moet echter wel aan enkele eisen voldoen om dit mogelijk te maken.

GmailEen eerste vereiste is de aanwezigheid van een zogeheten manifest op de webserver. In deze tekstfile moet worden opgesomd welke onderdelen door de client gecachet moeten worden, zoals de javascript-code, de stylesheets en de html-documenten. Ook kan worden aangegeven welke pagina’s juist niet gecachet mogen worden, zoals zoekmachineresultaten.

Naast de offline-modus voor het opslaan van statische elementen van een webpagina, biedt de Offline Web Applications-specificatie ook de mogelijkheid om data op te slaan in een lokale database. Deze kan met een op sql gebaseerde api worden benaderd.

De W3C wilde voor het lokaal opslaan van data de aloude cookies vervangen door de Web Sql Database-specificatie. Deze sql-variant kreeg de steun van Google, Opera en Apple, maar Mozilla zag meer in de indexed database api oftewel indexed db, een standaard die door Oracle is voorgesteld.

Inmiddels wordt er niet meer aan de Web Sql Database-standaard gewerkt, en de eenvoudiger indexed db lijkt de standaard te worden. Firefox en Chrome bevatten al implementaties van indexed db. Het is nog niet duidelijk wanneer Microsoft indexed db in Internet Explorer zal integreren, maar de softwarefabrikant heeft al wel zijn steun voor deze standaard uitgesproken.

Vernieuwingen in css 3
Hoewel css 2 een solide uitgangspunt is voor het opmaken van pagina’s, biedt css 3 geavanceerdere mogelijkheden. Belangrijk is wel dat css 3 wordt gezien als een modulair geheel dat nog verre van voltooid is, voornamelijk door de nog niet volwassen browserondersteuning. Voordat de belangrijkste vernieuwingen officieel worden, werken veel css 3-features al wel met prefixen, bijvoorbeeld ‘-moz-‘ voor Mozilla-browsers als Firefox. De website CanIUse geeft een goed overzicht van de stand van zaken .

Prefixes in css 3

Hoewel css 3 voorlopig nog werk in uitvoering is, kunnen de nieuwe features al wel bij het bouwen van websites worden ingezet. Een van de voordelen daarvan is dat het goed toepassen van css 3-property’s het aantal afbeeldingen en javascripts kan terugdringen, waardoor er minder ontwikkeltijd nodig is en de totale omvang van een pagina kleiner wordt. Bovendien kan het aantal http-requests verlaagd worden, zodat laadtijden korter worden.

Een voordeel dat daaruit voortvloeit is dat de ranking in zoekmachines verbeterd kan worden. Zo laat bijvoorbeeld Google tegenwoordig de laadsnelheid meewegen bij het beoordelen van een website. Bovendien zijn bijvoorbeeld koppen die met css-property’s zijn aangemaakt, leesbaar voor zoekmachines en daardoor te indexeren.

Als we naar de vernieuwingen in css 3 kijken, valt het op dat er veel mogelijk is met het element border-radius. Waar een kader met afgeronde hoeken vroeger met plaatjes moest worden gemaakt, kan het met dit nieuwe element eenvoudig worden gedefinieerd. Ook kan de ronding van elke van de vier hoeken apart worden opgegeven. Vrijwel alle nieuwe browsers, waaronder IE9, kunnen inmiddels met het border-radius-element overweg.

Een rand kan ook nog altijd door middel van een plaatje worden gemaakt en dat is met de property border-image eenvoudiger gemaakt. Afbeeldingen die voor een rand worden ingezet, kunnen in de css-code worden ‘afgesneden’ of geschaald. Helaas wisselt de implementatie van border-image van browser tot browser, zoals deze interactieve demo laat zien.

Meer opmaak-elementen
Liefhebbers van schaduwen achter tekst kunnen voortaan hun hart ophalen met het text-shadow-element. Dit leent zich in theorie vooral voor het opmaken van koppen, en er kunnen verschillende schaduw-effecten worden toegepast. Overigens kon text-shadow al in Safari 3 worden toegepast en was het al voorgesteld voor de css 2-specificatie. Schaduweffecten kunnen overigens ook met de box-shadow-property worden gemaakt, bijvoorbeeld om kaders meer op te laten vallen.

Lens Flare met behulp van text-shadow

Ook niet nieuw maar nu officieel onderdeel van css 3 is het gebruik van Web Fonts. Hiermee kan een webdesigner lettertypes gebruiken die niet door het besturingssysteem van de bezoeker worden ondersteund. In plaats van het propriëtaire Embedded Open Type-formaat, waar alleen Internet Explorer ondersteuning voor biedt, hebben alle browserbouwers inmiddels het Web Open Font Format omarmd.

Welkom is ook de komst van verbeterde afbreekmogelijkheden voor lopende tekst met de word-wrap-property. Het maakt het mogelijk dat lange woorden die niet binnen een blokelement passen, toch afgebroken kunnen worden. Zo kan bijvoorbeeld worden voorkomen dat lange links de opmaak van een pagina verstoren. Word-wrap wordt door alle browsers ondersteund.

Minstens zo krachtig is het gebruik van gradients, oftewel kleurverlopen. Deze kunnen in css 3 worden toegepast bij het maken van achtergronden, waarbij zowel lineaire als radiale kleurverlopen gedefinieerd kunnen worden. Helaas is de browserondersteuning nog verre van volledig en gebruiken Webkit- en Mozilla-browsers een verschillende syntax voor de gradient-feature. Tools die de benodigde css-code automatisch aanleveren, kunnen een webdesigner dan ook veel tijd besparen.

Nieuw is ten slotte ook de ondersteuning voor het toepassen van hsla-kleurwaarden. Hierbij kan in de css-opmaakcode een alfa-kanaal worden opgegeven om transparantie mogelijk te maken. Dit is overigens ook mogelijk met rgba, de tegenhanger van hsla.

Transforms en transitions
Naast gradients biedt de background-size-property meer mogelijkheden voor het manipuleren van achtergrondafbeeldingen. Zo kan met cover en contain de grootte van een afbeelding worden aangepast, terwijl met background-position een plaatje precies op de juiste plek kan worden gezet. Ook is het dankzij css 3 mogelijk om meerdere afbeeldingen in de achtergrond op te nemen.

Graphics en html-elementen kunnen in de 2d-ruimte gemanipuleerd worden door zogenaamde transforms toe te passen. Mogelijke transformaties zijn schalen, roteren, overhellen en verplaatsen en de respectievelijke funcies daarvoor zijn scale, rotate, skew en translate.

Transform-functie in css 3

Transforms kunnen direct bij het openen van een webpagina door de browser worden gerenderd of later met javascript worden uitgevoerd. De meeste browsers gebruiken het middelpunt van het te veranderen object als beginpunt, maar de implementatie kan opnieuw verschillen. Zo is in IE9 bijvoorbeeld nog een -ms-prefix nodig; de preview van IE10 ondersteunt deze functie wel.

Naast transforms kent css 3 ook de experimentele transitions, waarbij veranderingen in de css-eigenschappen van een object geanimeerd kunnen worden zonder dat er javascript nodig is. Zo kunnen kleurveranderingen dynamisch worden uitgevoerd en kunnen objecten bewegen, terwijl ook een achtergrondafbeelding gemanipuleerd kan worden. Een ontwikkelaar kan de timing van transition-animaties nauwgezet in de css-code bepalen.

De recentste browsers kunnen transitions weergeven, wederom met uitzondering van IE9. Er wordt echter nog volop aan de implementatie van de transition-functie gewerkt, dus het is goed mogelijk dat het aantal eigenschappen dat geanimeerd kan worden in de toekomst nog zal veranderen.

Media query’s en kolommen
In css 2 was het al mogelijk om voor verschillende mediaformaten eigen stylesheets te definiëren, zodat een printerversie van een webpagina anders opgemaakt kan worden dan dezelfde site op het compacte scherm van een mobiele telefoon. Css 3 voegt daar nieuwe mogelijkheden aan toe met de zogenaamde media query’s.

Met media query’s kan onder andere worden vastgesteld wat de grootte van een browservenster is, terwijl ook bepaald kan worden of een pagina liggend of staand wordt getoond. Daarnaast kan gedecteerd worden hoeveel kleuren een bepaald apparaat kan weergeven. Vervolgens kan de pagina-opmaak aan deze eigenschappen worden aangepast.

Hoewel webontwikkelaars regelmatig javascript gebruiken om de grootte van een browservenster te bepalen, maken media query’s het mogelijk om dit met uitsluitend css-code te doen. Zo wordt het voor sitebouwers makkelijker om voor verschillende clients aparte versies van een website te bouwen. Bovendien ondersteunen de meeste recente browsers deze mogelijkheid en bestaat er voor oudere browsers een jQuery-plugin met een fallback-mechanisme in javascript.

Css 3 multi-columnMet css 3 is het aanzienlijk eenvoudiger om multi-column layouts te bouwen. Dit kan door de eigenschap column in de css-code op te nemen. De opmaak over meer kolommen kan op twee manieren worden bepaald: door het aantal gewenste kolommen op te geven of door een minimale breedte te definiëren. In het laatste geval wordt het aantal zichtbare kolommen bepaald door de breedte van het scherm.

Verder kunnen aan de column-property dezelfde eigenschappen worden meegegeven als bij het ‘box-model’ van css 2. Ook zijn er opmaakmogelijkheden om bijvoorbeeld ongewenste layout-effecten als een hoerenjong tegen te gaan.

Multi-column layouts zijn krachtig gereedschap waar heel wat ontwikkelaars bijzonder blij mee zullen zijn. Niet alleen worden ouderwetse tabellayouts of complexe css 2-trucs overbodig gemaakt; css 3-kolommen passen zich desgewenst ook automatisch aan. Bovendien kan met een beperkte hoeveelheid code voor een betere toegankelijkheid van de gepresenteerde informatie worden gezorgd.

Selectors en pseudoclasses
Een laatste vernieuwing in css 3 die aandacht verdient, is de introductie van een aantal nieuwe selectors. Met een selector kan in een stylesheet een groep elementen worden geselecteerd aan de hand van bepaalde eigenschappen.

css 3 logoDoor de toevoeging van een aanzienlijk aantal nieuwe selectors kan de opmaak van specifieke onderdelen van een website verder worden verfijnd. Zo is het bijvoorbeeld mogelijk om met een zoekpatroon alle hyperlinks waarin ‘youtube.com’ voorkomt, een andere opmaak te geven: a[href*=”youtube.com”].

Naast extra selectors zijn er in css 3 nieuwe pseudoclasses gedefinieerd. Ook pseudoclasses maken het mogelijk om elementen op bepaalde eigenschappen te selecteren in plaats van op basis van de documenthiërarchie. Bekend is de :hover-pseudoclass: hiermee kan de opmaak worden bepaald van elementen waar de muisaanwijzer boven wordt gehouden.

Nieuw is onder andere de pseudoclass :nth-child die bijvoorbeeld bij het opmaken van tabellen nuttig kan zijn. Ook pseudoclasses als :last-child en :last-of-type kunnen nuttig zijn bij het opmaken van lijsten en tabellen.

Voor het overzichtelijker maken van formulieren zijn de pseudoclasses :enabled, :disabled en :checked interessant. Zo kan een webdesigner in een complex webformulier beter visualiseren welke velden wel of niet ingevuld moeten of mogen worden. Nog krachtiger is de pseudoclass :not: deze selecteert alle elementen op een webpagina behalve de gespecificeerde.

Het voert te ver om alle mogelijke nieuwe selectors en pseudoclasses en de bijbehorende parameters hier door te nemen. Duidelijk is wel dat de nieuwe elementen webdesigners nog meer flexibiliteit geven in het opmaken van specifieke onderdelen van een webpagina. Bovendien ondersteunen vrijwel alle moderne browsers deze elementen, terwijl voor oudere IE-versies nog kan worden uitgeweken naar javascript-workarounds als Selectivizr.

Conclusie
Het beeld moge duidelijk zijn: html5 en css 3 brengen de webdesigner een groot aantal vernieuwingen en extra mogelijkheden om websites en webapplicaties gebruiksvriendelijker, multimedialer en krachtiger te maken. We kunnen bovendien vaststellen dat er bij de totstandkoming van de html5-specificatie een grote eensgezindheid onder de browserbouwers was om tot een gezamenlijke standaard te komen. Er bestaan nog steeds heel wat interpretatieverschillen – de audio- en videotags zijn daar goede voorbeelden van – maar het lijkt een kwestie van tijd tot ook deze verdwijnen.

Css 3 biedt de webdesigner veel nieuwe kansen. Met name het animeren van elementen en het in kolommen opmaken van teksten zijn welkom. Ook het zonder gebruik van javascript dynamisch aanpassen van de content aan de beeldschermgrootte en -oriëntatie is erg handig. De vele nieuwe mogelijkheden zullen weliswaar de nodige gewenning vergen, maar het lijkt erop dat ontwikkelaars meer werk in dezelfde hoeveelheid tijd zullen kunnen verzetten.

In aanvulling op css 3 en html5 hebben sitebouwers bovendien de beschikking over nieuwe api’s, waarvan met name mobiele internetters de vruchten zullen plukken. Zowel de geolocation-api als de mogelijkheid om offline te kunnen werken zullen zich zonder twijfel tot uiterst nuttige uitbreidingen ontpoppen.

We durven dan ook zonder meer te stellen dat html5 en css 3 zullen uitgroeien tot dominante webstandaarden. Sterker nog: de nieuwe standaarden zullen mogelijkheden bieden waar we nog niet eens aan hebben gedacht. Wie een paar jaar geleden voorspelde dat besturingssystemen ondergeschikt zullen raken aan webapplicaties, zou binnenkort wel eens definitief gelijk kunnen krijgen.

REVIEW EN REACTIES

Goed (lang) artikel trouwens, wist niet veel van de historie van HTML, zo leren we weer wat 🙂 Ik denk dat HTML5 de doorslag gaat geven voor de ondergang van Flash. Ben voor mezelf eens wat gaan testen en moet zeggen dat het behoorlijk goed werkt.

Wat overigens een handig progje is, is Wallaby (ontwikkeld door Adobe). Hier kun je je .FLA bestanden omzetten naar HTML5. http://labs.adobe.com/technologies/wallaby/
Werkte bij mij in Chrome en Safari (IE niet getest, FF loopt niet helemaal vlekkeloos).
+2g4wx3
@volkano • 24 juni 2011 10:25
een belangrijk historisch feit:

HTML werd ontwikkeld door Robert Cailliau en Sir Tim Berners-Lee.
vaak vergeet men de eerste naam te noemen.
Zou dat komen omdat het een belg is?

Met name heeft hij ook verzonnen “www” te gebruiken voor de webserver om de engelse en te franse te “pesten”. “double u double u double u”(engels) oftwel “double v double v double v”(frans)

alhoewel dat ook een urban legend kan zijn
+1GateKeaper
@g4wx3 • 24 juni 2011 11:15
Wat een uitvinder dan! Dat is nou net hetgeen dat ik vrijwel altijd weg laat!

Een enkele website retourneert dan helaas wel een foutmelding waardoor ik alsnog de www variant moet proberen.

Verbazingwekkend genoeg zijn er trouwens zelfs subdomeinen die enkel werken met www ervoor.
+2hostname
@volkano • 24 juni 2011 13:42
Ik zou niet naar w3schools linken, vanwege redenen verder uitgelegd op deze website: http://w3fools.com/

Nog een aantal handige linkjes die ik zelf ook gebruik:
http://diveintohtml5.org/: Tutorial-achtige introductie op een aantal grote topics van HTML5 zoals de

O, en overigens goed artikel! Hulde. Dit kan ik zo als HTML5/CSS3 intro aan devvers geven 🙂

[update] lees nu dat het pas in 2014 een echte standaard wordt (nieuws: W3C drukt last call-stempel op html 5) … tja
[Reactie gewijzigd door Marcelloz op 24 juni 2011 09:15]

+1Chris7 Tweakers Plus
@Marcelloz • 24 juni 2011 09:27
Zeer goed artikel, dit zal ik zoals Marcelloz als zegt aanbevelen aan mensen die ik ken en meer willen weten over HTML5 en CSS3.
Maar het zal denk ik nog wel even duren voordat er geen JavaScript-fallbacks meer nodig zijn om al je HTML5-elementen goed te laten werken. Vooral in bedrijven worden nog zeer verouderde IE-versies gebruikt, helaas. Ik hoop dan ook dat steeds meer mensen voor een ‘moderne’ browser zullen kiezen, zoals Firefox of Chrome.

@Marcelloz: Het is wel waar dat de standaard in 2014 pas definitief wordt, maar volgend jaar is HTML5 een ‘recommended specification’, als ik het goed heb begrepen, en dan wordt het echt interessant.

Gelukkig implementeren browsers steeds meer features van deze standaarden, ik hoop dat binnen een jaar of 3 voor een groot deel van de opmaak alleen nog pure HTML5 en CSS3 nodig is, en dat je geen rekening meer hoeft de houden met oude browsers.
+2EnsconcE
@Chris7 • 24 juni 2011 14:08
De oude browers worden vaak gebruikt omdat men webapplicaties gebruikt die voor verouderde browsers gemaakt zijn. Daarnaast zijn er een aantal webapps waarbij specifiek geprogrammeerd is voor een IE versie. De introductie procedure van zo’n webpakket is vaak gebrekkig geweest omdat men niet naar de toekomst heeft gekeken (of het vernieuwen van de browser werd aks een ondergeschikt belang gezien).

Men zal vele webapps opnieuw moeten maken wil men aansluiten bij de nieuwe standaarden, iets wat nu niet gebeurt. De introductie van HTML 5 zal ook die trigger niet zijn, de trigger is namelijk een commercieel belang. Het is dus eigenlijk aan bedrijven om over te gaan op nieuwe betere webapps waardoor ontwikkelaars wel mee moeten met de nieuwste trends.

Het is mooi dat er een nieuwe standaard is en tags introduceert die al bijna 2 decennia gewenst worden. Ik denk dat, met de introductie van HTML 5, HTML eindelijk een volwaardig stadium beleeft. Het nadeel blijft dat webapplicatie ontwikkelaars pas overgaan wanneer er vanuit de markt vraag naar is. M.a.w. we kijken nog wel een tijdje aan tegen organisaties die vastzitten aan een oude browser en dus webapps die eigenlijk houwtje touwtje gemaakt zijn.
+1Rinzwind
@EnsconcE • 25 juni 2011 11:16
Je zou verwachten dat MS IE6 als speciale app voor die specifieke paar gare intranetsites beschikbaar zou stellen aan bedrijven (alla virtuele app). Maar helaas. Je kon zelfs via www.spoon.net IE6 streamen. Maar dat mocht niet meer van MS. Ze hadden daar paar IE versies naast elkaar.

Maar serieus… als bedrijf nu nog IE6 als standaard hanteert op de desktop ben je niet goed wijs. En je wordt dus ook gedwongen gelukkig… als je XP eens een keer vaarwel wilt zeggen.
+1R4gnax
@Rinzwind • 26 juni 2011 13:40
Doen ze ook. Windows XP Mode in Windows 7 Pro en hoger bevat standaard een installatie van IE6.
+1LOTG
@Marcelloz • 24 juni 2011 09:23
Als het n-1 was, dan zou dat nog te behappen zijn, maar in het geval van internet explorer is dat in sommige gevallen nog steeds n-3, bijna n-4 als IE10 uit komt.

Het zou wel fijn zijn als IE 6 (en 7 mag ook al weer) volledig gedropt kon worden, maar bedrijven zien zich genoodzaakt om het lijk toch nog in leven te houden uit angst dat ze klanten mis lopen.

Ik hoop dat HTML 5 eindelijk een einde zal maken aan de rotzooi die je nu moet schrjven om een pagina er op alle browsers het zelfde te laten uit zien. Het zal nog wel even duren, want ik ben nog steeds browser prefixes aan het toevoegen omdat er dus nog geen final is van HTML 5.
+1Interfico
@LOTG • 24 juni 2011 10:16
Gelukkig laat Google IE7 ook al vallen. (Bezoek GMail voor de grap maar eens met IE7) Dit is een grote stimulans om iedereen vooruit te pushen.

Bron: http://www.computerworld….pport_for_Microsoft_s_IE7
[Reactie gewijzigd door Interfico op 24 juni 2011 10:18]

+1Xthemes.us
@Interfico • 24 juni 2011 13:25
Belangrijke kanttekening, dit geldt voor alle google sites met uitzondering van google.com. Deze houden ze nog backwards compatible tot ik geloof zelfs internet explorer 4.0;

Ben het wel met je eens dat we Google dankbaar mogen zijn voor het helpen pushen van moderne browsers, zowel door de eigen browser (Chrome) als het niet supporten van oudere versies op het merendeel van de eigen sites.
Als webdeveloper is het altijd moeilijk te verantwoorden waarom de <IE8 support zoveel tijd kost, het is dan wel makkelijk om 1 van de google sites erbij te halen als voorbeeld dat niet iedereen überhaupt de moeite nog neemt.

  • Xthemes.us moet de eerste klant nog vinden die de support voor eigen site echter niet wil.. wij Nederlanders lijken wat dat betreft nog wel erger dan de rest van de wereld in het gebruik van oude IE versies.

edit:
Lijkt->lijken
[Reactie gewijzigd door Xthemes.us op 25 juni 2011 19:37]

+1MueR
@Xthemes.us • 24 juni 2011 22:40
Tja, wij hebben dat opgelost door gewoon te stellen dat we n-1 ondersteunen, de rest alleen tegen meerprijs en op uurbasis. Nu zal het me weinig roesten als ik voor FF3.6 een bug moet fixen, terwijl die ondertussen toch ook n-2 is, daar is niet zo veel anders aan. IE7 daarentegen is wel creatief af en toe. IE6 weiger ik te ondersteunen, punt.
+1Radhe Tweakers Plus
@MueR • 25 juni 2011 10:19
IE6 weigeren te ondersteunen doe ik per standaard, tenzij er iemand is die er specifiek om vraagt, maar dat is wel een flinke kostenpost dan. Vooral bij overheid schijnt het heel moeilijk te zijn een stap vooruit te zetten. Stel je voor je moet investeren in nieuwe computers of een migratie doen… Dat is toch veel goedkoper dan ondersteuning voor IE6 erin houden? 😉

Ikzelf vind de stap om IE7 niet meer te ondersteunen op dit moment nog een beetje rigoreus. Eind dit jaar is denk het beste evaluatiepunt of dat je daar aankomend jaar nog aandacht aan moet besteden.

(Ik ben nog niet eens over naar IE9, laat staan dat ik nu al zit te denk aan IE10)
0jwvirtual
@MueR • 27 juni 2011 14:20
Ik ga al een stapje verder. Ik stel al voor om ook IE8 nog maar beperkt te ondersteunen. Wel de functionaliteit maar dan in de opmaak zoals die gebruikelijk was toen IE8 werd uitgebracht. Kaders met rechte hoeken in plaats van ronde. De meeste klanten gaan daarin mee en zien ook wel dat de meeste XP bakken tussen nu en een jaar voor de laatste keer uitgaan. En anders zijn er nog prima alternatieve browsers.
+2edeboeck
25 juni 2011 12:55
Vind het artikel vrij goed… ik volg de evolutie al een tijdje (o.a. via WebDesigner), maar ik blijf nog steeds met 1 groot “probleem” zitten t.o.v. CSS3: ik zie namelijk dezelfde situatie van het begin van IE6 terugkeren: een browsermaker (toen: MS) introduceert eigen extra functionaliteit daar waar de standaard tekort schiet.
Nu: browsermakers (Mozilla Foundation, Opera, MS, Google, …) introduceren eigen attributen om functionaliteit te bieden die nog niet in de standaard zit.

Waar MS gebrandmerkt werd o.w.v. het niet volgen van de standaarden, wordt diezelfde ontwikkeling nu toegejuicht. 😕
Als we zien dat we 5 momenteel attributen nodig hebben om min of meer zeker te zijn dat een transition gebeurt, dan is dat niet bepaald ideaal (onderhoud, grootte CSS-bestanden).
Ik pleit er dan ook voor dat de browsermakers er werk van maken om de standaarden degelijk te ondersteunen zonder eigen toevoegingen (ja, ik weet wel dat CSS3 nog geen échte standaard is op dit moment)
+1n8n
@edeboeck • 25 juni 2011 18:07
Dan is het zaak om alleen CSS met een recommended status te gebruiken voor projecten waar je later niet veel onderhoud aan voorziet te handhaven. Vooralsnog gebruik gebruik ik eerst de specifieke tags (-moz-, -webkit- met name) en zet daar achter dezelfde declaratie zonder deze tags. Als ondersteuning compleet is zal de prefix genegeerd worden omdat deze eerder gedefinieerd word. Is in deze wel handig dat de rendering in de toekomst hetzelfde blijft, dat maakt het soms wel een kwestie van extra uitzoekwerk
+1Tarabass
24 juni 2011 10:21
Prachtig artikel, geschreven door iemand die veel verstand van zaken heeft en toch objectief gebleven is. Leest lekker weg, pareltje dus 🙂

Als webdeveloper heb ik me natuurlijk al uitgebreid verdiept in HTML5 en CSS3. Vooral de validatie van formulieren en de mogelijkheden met CSS3 hebben in mijn ogen veel potentie. De opmaak daarentegen wekt bij nogal wat weerstand op. Headergroups, sections en articles. Ik zie alleen maar veel meer regels code, met maar heel weinig meerwaarde. Vooral ook omdat er in mijn ogen veel te veel ruimte is voor eigen interpretatie van de tags. Of je het nu linksom of rechtsom opbouwt, de browser rendert het gewoon goed terwijl er wel degelijk ‘fouten’ in de logica van het document kunnen zitten.

De implementatie van media queries en kolommen vind ik, voor met het mobiele internet in opkomt, geniaal en erg gebruiksvriendelijk. Zonder veel poespas en aparte stijlsheets is het mogelijk een website neer te zetten voor vele typen media. Een welkome toevoeging dus.

Waar ik, als professional, me wel een beetje zorgen over maak is de nummering van de standaard. Zover ik begrepen heb wordt HTML5 geen versie 5 meer en wordt het straks een versieloze HTML-standaard. Het is voor mij onbegrijpelijk waarom dit zo zou moeten zijn, omdat je op die manier niet weet of je aan de laatste eisen voldoet, en je dus elke regel code pas na validatie van externe tools kan beschouwen als één die voldoet aan de laatste standaard. Ik hoop dat ze hiervan afstappen, en toch weer kiezen voor een versienummering. Dit houdt het wel duidelijk en overzichtelijk, dat is te zien aan hoe je nu kan zeggen wat nieuw is in HTML5 en CSS3 en wat niet.
+2sab Tweakers Hero
@Tarabass • 24 juni 2011 11:15
De opmaak daarentegen wekt bij nogal wat weerstand op. Headergroups, sections en articles. Ik zie alleen maar veel meer regels code, met maar heel weinig meerwaarde
Au contraire, mon frère.
H1’s en H2’s etc zijn nu relatief aan de dichtstbovenliggende article/section/etc element. Hierdoor mag je dus een article-tag hebben, met daarin een H1, ongeacht of je al eerder een H1 in een ander punt in de hierarchie gebruikt hebt.
Dit is erg handig als je in een CMS met modules werkt, aangezien je je niet meer hoeft af te vragen of je voor deze sectie nu een H3 of een H2 moet gebruiken (afhankelijk van andere stukken van de site).

Tevens kunnen zoekmachines door het verschil in article en section beter bepalen wat daadwerkelijk content is (ten opzichte van betekennisloze divs), en wat bijv sidebars zijn. Geenstijl.nl maakt hier (imho) wel goed gebruik van. Wat dat aan gaat zijn ze ook een goed voorbeeld van het gebuik van mediaqueries en andere CSS3 gimicks – ongeacht van wat je van de content van de site zelf vindt natuurlijk.
[Reactie gewijzigd door sab op 24 juni 2011 11:29]

+1Tarabass
@sab • 24 juni 2011 11:48
Ik ben me heel erg bewust van de voordelen, en van de manier waar zoekmachines hiermee om kunnen gaan. Maar door de vele interpretaties die men erop nahoud vind ik de nieuwe tags niet ‘strak’ genoeg. Of je nou article of section doet, of je nou h’s zonder of met headergroup doet, het maakt weinig uit op het eerste oog. Ik zie pas de voordelen als het ook echt daadwerkelijk wat gaat uitmaken, en als het strakker wordt geregeld. Nu komt het erg chaotisch over, en kan iedereen het op een eigen manier interpreteren.

want waarom zou ik een headergroup plaatsen om een paar headertags bijvoorbeeld?
+1n8n
@Tarabass • 25 juni 2011 17:59
: sectie zegt het al, een deel en lijkt het meest op een div. Dit kan een deel van je website zijn of een deel van een artikel.
Daarnaast zijn er voor koppen en voetnoten aparte tags omdat deze veelvoorkomend zijn. en , header kan je ook gebruiken binnen een of , van footer weet ik dit niet zeker.
Dan zijn er nog en , voor navigatie-elementen en voor content die niet relevant is tot de inhoud van de pagina. Ook kan binnen een article gebruikt worden.
is ook vrij vanzelfsprekend, dit gebruik je voor een stuk content die op zichzelf staat binnen een pagina.

Resultaat kan zijn:

tags oid etc… voor bijvoorbeeld gerelateerde content

Lapje tekst maar zo kan een pagina er nu uit zien waarbij het voor zowel de lezer als zoekmachines zeer duidelijk is waar het om gaat. is daarbij handig als er meedere artikelen op dezelfde pagina staan.
+1ZpAz
@Tarabass • 24 juni 2011 10:26
Waar ik, als professional, me wel een beetje zorgen over maak is de nummering van de standaard. Zover ik begrepen heb wordt HTML5 geen versie 5 meer en wordt het straks een versieloze HTML-standaard.
Chrome en Firefox ‘pretenderen’ ook steeds meer versieloos te zijn. Misschien zorgt het er juist voor dat het allemaal juist sneller gaat. Er zal vast ergens een pagina zijn die ‘de laatste mogelijkheden’ toont oid 🙂
+1sab Tweakers Hero
@ZpAz • 24 juni 2011 11:16
Yups, zelf gebruik ik hier http://www.caniuse.com/ voor.
+1Anoniem: 80466
@sab • 24 juni 2011 21:23
Die site suggereert echter voor veel zaken volledige support ook als die er niet echt is.
+1crisp
karmakoningHtml

@Tarabass • 24 juni 2011 11:20
Het enige waar een versienummer goed voor zou kunnen zijn is voor validatie, maar dat nut is ook maar zeer beperkt aangezien het bijvoorbeeld anno nu weinig meer boeit dat een document 3 jaar geleden valideerde tegen de dan-geldende standaard. Waar het om gaat is dat browsers anno nu datzelfde document goed kunnen verwerken, wat doorgaans geen probleem is zolang de standaard maar backwards-compatible blijft. Validatie tegen de laatste standaard zou dan ook geen probleem mogen zijn.

Pas als backwards-compatibility gebroken wordt dan zou een versienummer soelaas kunnen bieden als hint naar de browser, maar dat is een zeer onwenselijke situatie; browservendors zitten niet te wachten op verschillende render-modi.
+1Tarabass
@crisp • 24 juni 2011 11:41
En bij die backwards-compatibility ziet nou juist het voordeel. Bedrijven zijn niet happig om telkens maar te moeten meegaan met de laatste browsers en os’en. Nu weten we allemaal dat css 2.1 en xhtml/html4 werken in oudere browsers als ie8 op xp. Door je aan die standaard te houden kan je (afgezien van wat kleine dingetjes) ervan uitgaan dat het werkt bij de klant. Als het versieloos gaat worden, moet je voor elke tag, elke property, elke techniek weten in welke browsers (en door ms vaak gekoppeld aan os, zie ie9) het werkt. Browsers ondersteunen dan ook niet meer een versie HTML, maar ondersteunen sommige tags en sommige properties. Het lijkt mij makkelijker te weten welke versie ondersteunt wordt, ipv van alle duizenden mogelijkheden te moeten onderzoeken of dit gaat werken.

En anno nu levert dit niet veel problemen op natuurlijk. Nu we net een nieuwe ‘versie’ ingaan is het vooral makkelijk te zeggen dat het onder HTML5 of CSS3 valt. Dat geeft ook een hoop aan. Maar hoe gaan we dat over 2/3 jaar zeggen? Er komen steeds nieuwe technieken, hoe gaan we die aanduiden en hoe weten we dan dat sommigen technieken deprecated zijn? Ik begrijp je punt, maar op langer termijn kan dit weleens de nieuwe braincracker zijn voor de webdevver..
+1crisp
karmakoningHtml

@Tarabass • 24 juni 2011 12:03
Browsers ondersteunen dan ook niet meer een versie HTML, maar ondersteunen sommige tags en sommige properties.
Maar dat is feitelijk nu ook al zo en is altijd al zo geweest. Er is zelfs geen enkele browser met volledige ondersteuning van HTML4. Crossbrowser support is en blijft een kwestie van kijken naar de grootst gemene deler qua ondersteuning van technologieën, en het toepassen van gracefull degradation en/of progressive enhancement. Dat is iets wat sowieso altijd zal spelen zolang je ook oudere browsers moet ondersteunen.
+1Antipater
@Tarabass • 24 juni 2011 12:19
De extra semantische tags van html5 zorgen juist voor heldere en meer beknopte markup. Ten eerste omdat, zoals sab.loempia.com al aangeeft voor headers, het veel eenvoudiger is om context-loze markup te maken. Ten tweede omdat een enorm deel van de semantische informatie die nu in css zit direct als html opgemaakt kan worden.

Vergelijk bijvoorbeeld: … … … …

met:

0n8n
@Antipater • 25 juni 2011 18:03
groot voordeel ja, ik kan me nog herinneren dat ik een commentaarregel achter een sluittag van een div zette omdat ik het overzicht anders verloor.

behoort nu tot het verleden
+1thioz
24 juni 2011 09:22
Ik denk ook dat het belangrijk is dat developers snel de nieuwe mogelijkheden gaan gebruiken zodat ook de browsermakers wel sneller moeten zijn met het implementeren van alle mogelijkheden.

In het verleden heeft juist het te lang ondersteunen van oude browsers als IE6 er in mijn ogen voor gezorgd dat de ontwikkeling wat stil bleef staan en men meer bezig was om workarounds te maken.
+1Reboot
@thioz • 24 juni 2011 10:08
De browsermakers trekken zich hier op zich weinig van aan, zeker internet explorer zal hier nog minder rekening mee houden dan bv mozilla.

Developers zoals ik ook, zijn nog altijd terughouden op het gebruik van nieuwe techniek, en kunnen helaas ook niet anders.
Zolang IE gebruikers niet updaten, en xp users al helemaal niet naar IE9 zullen we nog gedurende een 4-5 jaar genoodzaakt zijn om zo min mogelijk van deze techniek gebruik te maken
+2kitafe
@Reboot • 24 juni 2011 12:31
je kunt html 5 gewoon gebruiken in ie 6, 7 en 8. Het zal geen errors geven, en de pagina wordt gewoon zichtbaar.
Maar je zult met workarounds moeten werken zoals dat pre html 5 eigenlijk ook moest, alleen doe je het op een betere manier. je kunt modernizr gebruiken om er makkelijk achter te komen wat de huidige browser ondersteund. en zo op de juiste manier de pagina te laten zien.
+1ZpAz
@kitafe • 24 juni 2011 14:36
Tenzij je tags als e.d gebruikt, dan is het in IE niet te stijlen zonder Javascript.
+1Ook al Bezet
@ZpAz • 26 juni 2011 13:46
Tenzij je tags als e.d gebruikt, dan is het in IE niet te stijlen zonder Javascript.
Maar als je met een oude versie van IE rondsurft én zonder javascript dan vraag je eigenlijk ook wel om problemen.
0ajvdvegt
@Ook al Bezet • 28 juni 2011 15:54
Maar een oude versie van IE mét javascript is nog meer vragen om problemen! 🙂
+1Tarabass
@thioz • 24 juni 2011 10:31
Als professioneel bedrijf kan je het jezelf natuurlijk niet permitteren om nog niet ondersteunde standaarden te gaan gebruiken. Denk aan portalbouwers die duizenden uren steken in het ontwikkelen ervan. Mochten bepaalde zaken dan niet in de standaard opgenomen gaan worden, dan ben je nutteloos en vooral niet winstgevend bezig door alles weer terug te draaien of aan te passen aan de wel opgenomen standaarden. Veel bedrijven zullen om die reden gaan voor de zekerheid en afwachtend zijn, maar als webdevver begrijp ik je insteek. Ook ik lever nu al het liefst alles in HTML5 af, helaas ziet mijn werkgever dat (en begrijpelijk) (nog) niet zitten 🙂
+1Antipater
@Tarabass • 24 juni 2011 11:55
Hangt af van het soort werk wat je doet en welke features je wilt gebruiken. Als je in een competitieve markt zit, kan je jezelf ook in de vingers snijden door geen html5 te gebruiken, al hebben de werkgevers dat soms niet in de gaten.

Als je concurrent allerlei extra zaken weet aan te bieden en bijvoorbeeld een veel betere ervaring op mobiele computers (tablets & smartphones) voor elkaar weet te krijgen met html5, dan loop je achter op de concurrentie. Het perse willen ondersteunen van IE6 en ook wel IE7 kost ook extra budget, geld wat je anders aan de ontwikkeling van je product zelf had kunnen besteden.

Je kan nu al een hoop uit html5 gebruiken zonder gevaar te lopen dat dit tussentijds gewijzigd wordt. Met een aantal libraries die deze features ook beschikbaar stellen in browsers die ze niet ondersteunen zit je redelijk safe. Dan is de ervaring in IE7 en soms 8 misschien niet optimaal, maar je werk kan er meer toekomstbestendig van worden.
+1vor0nwe
@Tarabass • 24 juni 2011 12:57
Het mooie van HTML5 vind ik dat je het wel degelijk al kunt gebruiken. Er zijn al verscheidene JS-libraries, zoals WebShim, waarmee een groot deel van HTML5 al op IE7 werkt!

Daarbij geldt voor veel nieuwe functionaliteit dat oudere browsers het braaf negeren als ze het niet ondersteunen, of het er allemaal hooguit wat ‘kaler’ uitziet.
+1Werelds Tweakers Plus
@Tarabass • 24 juni 2011 20:24
Wij gebruiken anders wel al gewoon HTML5. Al onze klanten gebruiken zelf fatsoenlijke browsers, dus de backend zijn we inmiddels volledig HTML5/CSS3 aan het bouwen. Daarbij letten we wel op dat we geen delen van HTML5 gebruiken die niet elke browser ondersteunt; dingen zoals datepickers gebruiken we dus wel nog gewoon fijn JS voor (helaas is Opera nog steeds de enige die dat ondersteunt, en dan al sinds 9.0 :().

Voor de frontend gebruiken we de delen van HTML5 en CSS3 waarvoor we eenvoudig fallbacks kunnen maken. Met behulp van modernizr kom je al een heel eind en voor sommige dingen hebben we zelf simpelweg fallbacks gebouwd.

IE6 ondersteunen wij al niet meer, op elke site die we hebben afgeleverd in de afgelopen 3 jaar bleek het aantal IE6 bezoekers echt in de tientallen per jaar te liggen. Die krijgen gewoon netjes een melding dat ze eigenlijk toch eens moeten updaten.

IE7 gebruikers zijn ook veel sneller geneigd te updaten naar 8, dus IE7 is ook niet zo’n heel erg groot probleem; op die manier ben je in elk geval al vrij ver wat betreft algemene HTML en CSS ondersteuning, wat niet direct kan, kan in deze browsers sowieso wel via fallbacks waar je niets van merkt 🙂
+1za3redrum
24 juni 2011 09:28
Waarom worden underline tags niet meer ondersteund? Ik vond het best handig om zo nu en dan te gebruiken ipv. daar weer CSS voor aan te maken.
+1Terminal13
@za3redrum • 24 juni 2011 09:43
underline, strike en andere opmaak elementen (dus ook bold en italic ) moeten nou eenmaal met de CSS gedaan worden, het is immers opmaak. De reden dat en nog wel “geldig” zijn, is omdat ze nu een andere functie hebben gekregen en geen opmaak meer mogen hebben. Het is zelfs zo dat H1-6 ook geen standaard opmaak meer mogen hebben van de browsers. De reden is dat HTML en CSS nu volledig gescheiden zijn.
+2crisp
karmakoningHtml @Terminal13 • 24 juni 2011 10:13
De reden dat en nog wel “geldig” zijn, is omdat ze nu een andere functie hebben gekregen en geen opmaak meer mogen hebben. Het is zelfs zo dat H1-6 ook geen standaard opmaak meer mogen hebben van de browsers. Dat is zeker niet waar. De HTML5 specificatie heeft zelfs een hele (non-normative) sectie over (standaard) presentatie: quote: http://www.w3.org/TR/html5/rendering.html User agents are not required to present HTML documents in any particular way. However, this section provides a set of suggestions for rendering HTML documents that, if followed, are likely to lead to a user experience that closely resembles the experience intended by the documents’ authors. Onder het kopje The CSS user agent style sheet and presentational hints vind je de ‘verwachte’ standaard opmaak van bepaalde elementen, waar gewoon een font-weight: bold krijgt, een font-style: italic en de heading-elementen aflopende font-sizes en ook font-weight: bold. +1Tielenaar @Terminal13 • 24 juni 2011 10:30 Je kan het scheiden noemen, maar overzichtelijk is anders. Ik verwacht dat je straks via CMS editors als CKeditor die html5 compliant willen zijn hele lange onleesbare code krijgt. Dan krijg je Titel in plaats van Titel
Inline CSS kan je heel moelijk verbannen naar een losse stylesheet, puur door het massale gebruik van contenteditable CMS systemen.
Ik blijf de komende jaren gewoon lekker stug gebruiken in ieder geval 🙂
+1eekhoorn13 Tweakers Hero
@Tielenaar • 24 juni 2011 10:44
Het idee is dat (emphasis) en kennelijk ook aangeven dat iets nadruk moet krijgen. Hoe die nadruk gegeven wordt, dat mag je dan weer in CSS bepalen en zoals crisp zegt, waarschijnlijk is dat in veel browsers standaard dik gedrukt.
In mijn ogen is die scheiding juist overzichtelijker; op je huidige site wil je de tekst misschien met dik gedrukte letters nadruk geven, in een toekomstige layout is het misschien mooier/netter om ze italic te maken. Of misschien nog wel dikker gedrukt. Het blijft dan in alle gevallen wel de nadruk krijgen die je met aangeeft! Voor een CMS editor zou dat geen probleem moeten zijn; je definieert 1 keer in je CSS dat in bold is en dan kun je die tag gewoon in je editor blijven gebruiken (of misschien beter: ). Ik mag hopen dat zulke editors geen in-line css gaan gebruiken; dan wordt het inderdaad onoverzichtelijker én schiet je het doel van CSS voorbij geloof ik.
+1n8n
@eekhoorn13 • 25 juni 2011 17:37
vergeet niet dat tekst die je wilt benadrukken met een span geen extra semantieke waarde krijgt. Hetzelfde gaat steeds meer gelden voor die dat eigenlijk niet meer heeft maar naar ik vermoed (nog) wel zal krijgen van zoekmachines
[Reactie gewijzigd door n8n op 25 juni 2011 17:40]
+1Antipater
@Tielenaar • 24 juni 2011 12:05
Dat inline-css van CMS systemen is ook dan ook rampzalig. Op zich heb je gelijk, alles direct op de pagina is overzichtelijker, want je hebt alle informatie bij elkaar. Dat is prima als je iets heel simpels hebt, weinig eisen stelt of nooit veranderd. Maar stel dat je honderden of duizenden artikelen hebt en er wordt besloten dat underline echt lelijk is en eruit moet. Als je dit in css had gedaan, dan was je in 1 min. klaar. Nu moet je echter al die pagina’s door, waarschijnlijk met een of ander foutgevoelig scriptje, om de presentatie in je content eruit te slopen. Dit is niet te doen, je zit in de praktijk dan gewoon vast aan de presentatie die je ooit hebt bedacht. Een ander nadeel is dat het afdwingen van de presentatie puur een kwestie van menselijke discipline is, en zoals iedereen weet werkt dat op een gegeven moment niet echt lekker.
0MrMonkE
@Tielenaar • 25 juni 2011 11:34
Als je even snel een stukje HTML uit code wilt poepen zeker. 😉
+1Chris7 Tweakers Plus
@Terminal13 • 24 juni 2011 10:46
Een heel aantal elementen, zoals , hebben nu een nieuwe, semantische betekenis gekregen. Zoals de W3C verklaart:
The i element represents a span of text offset from its surrounding content without conveying any extra emphasis or importance, and for which the conventional typographic presentation is italic text; for example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.
Zo zijn ook veel andere elementen zoals en veranderd van betekenis, en hangt er aan die elementen geen standaard-opmaak meer. In de praktijk behandelen veel browsers ze echter nog als de HTML 4 tags.
De reden dat dit is gedaan is dat opmaak nu strikt wordt gescheiden van HTML. Alle opmaak moet in HTML5 in CSS gebeuren.
+1Tom
@za3redrum • 24 juni 2011 20:59
Los van de technische reden (zie reacties hierboven) is het visueel niet aan te raden omdat veel mensen het zullen verwarren met een link.
+1johnkeates
24 juni 2011 10:11
Dit is dan wel weer echt tweakers-waardig!
Nu zit ik me wel af te vragen of ik de enige ben die xhtml 1.0 strict met de hand doet…
+1crisp
karmakoningHtml @johnkeates • 24 juni 2011 11:28
Er zijn maar weinig redenen om te kiezen voor XHTML, zeker niet als je dat vervolgens gewoon als text/html aan browsers serveert. Een reden zou kunnen zijn dat je markup wilt mixen met andere XML-applicaties (waarvoor een xhtml-mimetype dan weer vereist is) of als het als input moet kunnen dienen voor andere consumers dan browsers in een XML-omgeving. Als dat laatste een doel is dan zou ik geen hand-authoring gebruiken maar XML-tools om syntactische correctheid te waarborgen. In HTML5 is XHTML-syntax ook gewoon mogelijk.
+1johnkeates
@crisp • 24 juni 2011 17:23
application/xhtml+xml is ook weer niet zo moeilijk om mee te geven bij een HTTP request… maar dan nog, xhtml heeft voor mij als voordeel dat je niet weer een losse standaard kan gaan gebruiken. Je codeert gewoon overzichtelijk en alles wat je wil maken werkt ook gewoon. Met HTML5 kan dat nu nog niet. Verder heb je XML compatibiliteit, wat het parsen ook wat eenvoudiger maakt als je het door een willekeurige XML parser haalt… Ik snap dan ook niet waarom alles opeens weer ‘los’ moet, want XHTML is echt niet minder leesbaar voor mensen, en de minder sterke regels van HTML5 gaan het internet niet opeens makkelijker of mooier maken, niet in de ogen van de consument, en ook niet voor ontwikkelaars. (Of de desbetreffende ontwikkelaar moet zo weinig kennis van zaken hebben… maar laten we daar maar niet over beginnen ;))
+2crisp
karmakoningHtml @johnkeates • 24 juni 2011 22:34
application/xhtml+xml is ook weer niet zo moeilijk om mee te geven bij een HTTP request…
Als Internet Explorer (< 9) je niet interesseert kan je dat doen ja, maar er is wel een reden dat dat op het web nauwelijks gebeurt…
maar dan nog, xhtml heeft voor mij als voordeel dat je niet weer een losse standaard kan gaan gebruiken.
Wat versta je onder een ‘losse standaard’? Het feit dat incorrecte syntax in HTML zoveel mogelijk wordt ‘gecorrigeerd’ en waar je (of je bezoekers) in XHTML (dus met xhtml-mimetype) met een parse-error wordt geconfronteerd?
Je codeert gewoon overzichtelijk en alles wat je wil maken werkt ook gewoon. Met HTML5 kan dat nu nog niet.
Geef eens een concreet voorbeeld dan waarom dat in HTML(5) niet kan?
Verder heb je XML compatibiliteit,
XML compatibiliteit is wel precies de reden dat XHTML er is (en HTML5 ook een XML-serialisatie kent), maar als dat geen noodzaak is is er eigenlijk imho verder geen reden om voor een XML-variant te kiezen.
wat het parsen ook wat eenvoudiger maakt als je het door een willekeurige XML parser haalt…
want er zijn geen HTLM parsers?
en de minder sterke regels van HTML5 gaan het internet niet opeens makkelijker of mooier maken
De regels van HTML5 (of HTML4 for that matter, qua syntaxregels is er weinig verschil) zijn niet minder strict (of ‘sterk’); ze zijn gewoon iets anders. Foute syntax is en blijft natuurlijk foute syntax; het is puur de foutafhandeling die verschilt, en die van XHTML zou ik niet als ‘sterk’ willen omschrijven maar eerder als ‘draconisch’. Vooral als je 3rd party content (in de vorm van widgets bijvoorbeeld) wilt kunnen includen, of geen volledige XML-based backend hebt voor het verwerken van externe input waarmee je wellformedness kan afdwingen, heeft de gewone HTML-serialisatie wel degelijk voordelen. In de praktijk is een XHTML doctype wel veel voorkomend, maar 99% van die pagina’s worden gewoon als text/html geserveerd en 95% daarvan valideert niet en/of zou met een xhtml-mimetype een YSOD opleveren en/of gebruiken zaken (bijvoorbeeld banners of widgets) die niet werken als het door de browser als een XML-applicatie zou worden behandeld (document.write bijvoorbeeld). Dat natuurlijk plus het feit dat IE < 9 het niet eens ondersteund 😛
(Of de desbetreffende ontwikkelaar moet zo weinig kennis van zaken hebben… maar laten we daar maar niet over beginnen ;))
Het is meer zo dat je als ontwikkelaar wel verdomd veel kennis van zaken moet hebben voordat je aan XHTML begint 😉 XHTML is not for Beginners (2005)
[Reactie gewijzigd door crisp op 24 juni 2011 22:39] +1Tielenaar
@johnkeates • 24 juni 2011 10:58
Ik ook hoor 🙂
Dit kan je alleen allemaal weer vergeten als je html5 gaat gebruiken. html5 is veel toleranter dan xhtml1 strict, maar je kan wel dezelfde stijl aanhouden. Voor mij ligt het er per project maar net aan wat ik ga inzetten. Als het een grafisch hoogstaande website wordt met voornamelijk bezoekers die fatsoenlijk hun browsers updaten, dan ben ik all for html5.
Gaat het om een saai ogende web applicatie die in verouderde netwerken moet gaan draaien, dan heeft een oudere standaard natuurlijk de voorkeur. Het liefst zo xhtml strict mogelijk, zodat het een beetje compatibel is met andere software die de data ook nodig heeft.
+1johnkeates
@Tielenaar • 24 juni 2011 17:19
Ik kan prima XHTML 1.0 STRICT gebruiken en een compleet dynamische site maken hoor… goed ontwerp en gebruik van javascript en css is echt niet verboden in XHTML. Dingen grafisch ontwerpen is niet opeens ‘moeilijk’ als je strict gaat werken, maar je krijgt wel schonere code.
+1Greatsword
24 juni 2011 10:15
Op dit moment erger ik me al genoeg aan allerlei ongewenste banners, flash reclames, geluidjes etc, Als ik dit artikel zo lees, ziet het er naar uit dat dit soort advertisement alleen maar krachtiger en opvallender kan worden. Hoe kijken jullie hier tegen aan?
+1Tarabass
@Greatsword • 24 juni 2011 10:27
Er veranderd in principe weinig aan de mogelijkheden die er zijn qua design en reklame, behalve dan dat het op een andere manier mogelijk is. als er dan toch reklame moet zijn heb ik liever dat dit op een andere manier dan flash wordt aangeboden. De reklame zal er blijven, de manier waarop het gepresenteerd gaat worden zal alleen maar lichter worden voor browser en systeem 🙂
+1sab Tweakers Hero
@Greatsword • 24 juni 2011 11:09
Het merendeel van de genoemde features worden al een jaar of langer ondersteund in de meeste browsers (je weet wel wie ik Niet bedoel), maar vooralsnog blijven bannermakers gewoon bij flash. Wat ik overigens geen enkel probleem vind; dankzij plugins als noflash kan je zeggen dat flash standaard een extra klik nodig heeft om geladen te worden. Aangezien 80% van flash banners is, en 19% videoplayers, is het mij (en mijn CPU) die extra klik wel waard.
0Zunflappie
@Greatsword • 26 juni 2011 15:45
Alle reclame verplicht laten plaatsen in -tags.
En dan in je eigen stijlblad een display: none; op spam :+
+1FlowinG Tweakers Plus
24 juni 2011 09:50
IE9 kan zelfs nog helemaal niet met transforms overweg, maar de preview van IE10 ondersteunt deze functie wel.
IE9 ondersteunt wel transforms, uiteraard met de prefix -ms. Met andere woorden -ms-tranform:rotate(45deg) werkt gewoon in IE9. @crisp: het artikel spreekt over 2d transformaties en die link verwijst ook naar 2d transformaties. Sterker nog: de rotate3d() functie werkt nog maar heel beperkt. Alleen op webkit als ik het goed heb… ‘t Is in ieder geval niet “helemaal niet” 🙂 Edit2: volgende keer eerst refreshen voordat ik opsla 8)7
[Reactie gewijzigd door FlowinG op 24 juni 2011 10:30] +1crisp
karmakoningHtml