Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door Dimitri Reijerman

Redacteur

Html5 en css 3: de pijlers van morgen

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.

Reacties (77)

Wijzig sortering
Voor degenen die geinteresseerd zijn in een referentie van gebruikte HTML5 elementen:
http://www.w3schools.com/html5/html5_reference.asp

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).
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
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.
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:
Het is fijn dat HTML5 en CSS3 in een stroomversnelling zijn geraakt door een kleine browser-oorlog en dat deze combi hopelijk snel een echte standaard wordt. Dit is met name belangrijk voor gebruik in enterprise applicaties \ grote bedrijven. Daar wil de IT nogal eens achterblijven en een n-1 approach gebruiken waardoor je altijd nog voor oude browsers moet ontwikkelen. Een definitieve klap op de standaard + stabiele browsers zijn dan fijn al zal het dan nog jaren duren voordat je het echt overal kan gaan neerzetten.
Goed dat het dus gebeurd, alleen plukken we de echte vruchten pas over een paar jaar denk ik.

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]

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.
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.
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.
Doen ze ook. Windows XP Mode in Windows 7 Pro en hoger bevat standaard een installatie van IE6.
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.
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]

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]

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.
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)
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.
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)
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
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.
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]

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?
<section>: 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. <header> en <footer>, header kan je ook gebruiken binnen een <section> of <article>, van footer weet ik dit niet zeker.
Dan zijn er nog <nav> en <aside>, <nav> voor navigatie-elementen en <aside> voor content die niet relevant is tot de inhoud van de pagina. Ook <aside> kan binnen een article gebruikt worden.
<article> is ook vrij vanzelfsprekend, dit gebruik je voor een stuk content die op zichzelf staat binnen een pagina.

Resultaat kan zijn:
<body/>
<header/>

<nav/>

</section #content/>

<article>

<header>
<headergroup>
<h1>kop</h1>
<h2>subkop</h2>
</headergroup>
</header>

<section .intro>
<p/>
</section>

<section .kern>
<p/>
</section>

<section .slot>
<p/>
</section>

<aside>tags oid</aside>

</article>

<aside>
<header> etc...
voor bijvoorbeeld gerelateerde content
</aside>

<footer/>

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. <article> is daarbij handig als er meedere artikelen op dezelfde pagina staan.
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 :)
Yups, zelf gebruik ik hier http://www.caniuse.com/ voor.
Die site suggereert echter voor veel zaken volledige support ook als die er niet echt is.
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.
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..
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.
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:
<div class="nav"> ... </div>
<div class="header"> ... </div>
<div class="section"> ... </div>
<div class="footer"> ... </div>
met:
<nav></nav>
<header></header>
<section></section>
<footer></footer>
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.

<!-- einde #content --> behoort nu tot het verleden
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.
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
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.
Tenzij je tags als <section> e.d gebruikt, dan is het in IE niet te stijlen zonder Javascript.
Tenzij je tags als <section> 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.
Maar een oude versie van IE mét javascript is nog meer vragen om problemen! :)
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 :)
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.
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.
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 :)
Waarom worden underline tags niet meer ondersteund? Ik vond het best handig om zo nu en dan <u> te gebruiken ipv. daar weer CSS voor aan te maken.
underline, strike en andere opmaak elementen (dus ook bold <b> en italic <i>) moeten nou eenmaal met de CSS gedaan worden, het is immers opmaak.

De reden dat <strong> en <em> 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.
De reden dat <strong> en <em> 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:
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 <strong> gewoon een font-weight: bold krijgt, <em> een font-style: italic en de heading-elementen aflopende font-sizes en ook font-weight: bold.
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 <span style="font-weight: bold">Titel</span> in plaats van <strong>Titel</strong>
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 <b> gebruiken in ieder geval :)
Het idee is dat <em> (emphasis) en kennelijk ook <strong> 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 <em> aangeeft!

Voor een CMS editor zou dat geen probleem moeten zijn; je definieert 1 keer in je CSS dat <strong> in bold is en dan kun je die tag gewoon in je editor blijven gebruiken (of misschien beter: <span class="bold">). 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.
vergeet niet dat tekst die je wilt benadrukken met een span geen extra semantieke waarde krijgt. Hetzelfde gaat steeds meer gelden voor <b> 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]

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.
Als je even snel een stukje HTML uit code wilt poepen <b> zeker</b>. ;)
Een heel aantal elementen, zoals <i>, 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 <b> en <small> 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.
Los van de technische reden (zie reacties hierboven) is het visueel niet aan te raden omdat veel mensen het zullen verwarren met een link.
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...
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.
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 ;))
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 :P
(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]

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.
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.
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?
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 :)
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.
Alle reclame verplicht laten plaatsen in <spam>-tags.
En dan in je eigen stijlblad een display: none; op spam

:+
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]

IE9 ondersteunt alleen nog maar 2D transforms, geen 3D
3d transforms gaan alleen op voor webkit.
Sodeju, 17 pagina's aan info..

Wel erg leuk om te lezen.
Jaren terug wel dingetjes gedaan met HTML en CSS en PHP, maar poeh, wat is er veel veranderd.

Er is steeds meer mogelijk... Als ik naar mezelf kijk vraag ik me af of het makkelijker of lastiger geworden is :P

Wel hulde voor wie het artikelen geschreven heeft!!

Op dit item kan niet meer gereageerd worden.


OnePlus 7 Pro (8GB intern) Nintendo Switch Lite LG OLED C9 Google Pixel 3a XL FIFA 19 Samsung Galaxy S10 Sony PlayStation 5 Televisies

'14 '15 '16 '17 2018

Tweakers vormt samen met Tweakers Elect, Hardware Info, Autotrack, Nationale Vacaturebank, Intermediair en Independer de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2019 Hosting door True