Is het dumpen van HTML de enige manier om tot een semantisch web te komen?

Fred wees me op een artikel op FrankWatching, waarin Sven Bommezijn zijn gedachten eens laat gaan over een web zonder HTML.

Sven stelt dat de scheiding van content en vorm momenteel nog wat ontbreekt, althans, dat denk ik. Het is nog al een lang ding — an sich niets mis mee, zelf produceer ik ook geregeld enorme lappen tekst — zonder dat er een duidelijke stelling of conclusie uit lijkt te komen. Ik heb ook het idee dat hij bepaalde onderdelen van HTML niet kent; als ik zijn pleidooi goed begrijp, zoekt hij naar een oplossing die er al is.

Op een paar punten denk ik dat Sven er compleet naast zit; laat ik dat maar eens met wat quotes en antwoorden proberen duidelijk te maken.

Wie ingevoerd is in CMS, SEO, RSS, SOAP en REST en andere cryptische afkortingen kijkt naar het internet als een berg min of meer geordende informatie. De betekenis van die informatie is door computers bijna niet te vatten, maar voor de menselijke gebruiker erg relevant. Juist voor die menselijke gebruiker is het ook belangrijk dat die informatie op een verteerbare vorm wordt gepresenteerd. Alleen, die presentatie komt steeds meer los te staan van de inhoud, omdat het gedicteerd wordt door bijvoorbeeld corporate design guidelines, of gebruiksvriendelijkheid, overzichtelijkheid en technische mogelijkheden.

Tot zover ga ik nog met Sven mee. Een computer heeft inderdaad geen menselijk inzicht en zal dus nooit kunnen begrijpen waar bepaalde content over gaat. Althans, niet tot we “echte” AI hebben, en als dat er al komt duurt dat nog wel even.

Aan de andere kant ordenen we de informatie op basis van de inhoud. Zoekmachines zoeken naar woorden, eigenschappen van plaatjes, meta-informatie en verbanden tussen de informatie (bijv. links). Hypertext Links geven natuurlijk zelf al een bepaalde ordening aan.

Ik zie hyperlinks meer als pure verwijzing, zonder al te veel ordening. Het is een koppeling, een “zie ook:”. Zoekmachines kunnen eventueel aan de hoeveelheid links een waarde gaan hangen (“als 100 mensen naar een pagina linken, dan zal die wel interessanter zijn dan wanneer 1 persoon dat doet”), maar dan nog zegt dat an sich niets over relevantie. Ik kan in dit verhaal linken naar een plaatje van een sneeuwpop, maar die sneeuwpop heeft dan niet ineens automagisch iets met HTML te maken, of vice versa.

Maar niet alleen zoekmachines willen ‘pure’ content. De app en de widget winnen flink terrein, en willen ook gevoed worden door “pure” content. De opmaak is immers onderdeel van de betreffende applicatie. Ook het verschijnsel mashup wil graag van verschillende bronnen pure content combineren en op een nieuwe manier presenteren.

Ik zou niet zo zeer van “pure” content willen spreken, maar van “logisch geordende content”. Ik zie “pure content” meer als, pak hem beet, plain text, zonder enige vorm van ordening. Zoekmachines kunnen daar misschien wel iets mee, maar op het moment dat ik het ga structureren wordt er ineens veel meer mogelijk. Dat geldt nog sterker voor mashups.

Nee zeker niet, en ik maak me hier dan ook erg schuldig aan Jip-en-Janneke-taal. Maar kijkend naar de lingua franca van het internet, (X)HTML, dan valt toch op dat je heel wat in die HTML-code moet zetten om de pagina later te kunnen opmaken middels CSS. Denk aan alle DIV’s en SPAN’s en de overmaat aan stijlattributen die stiekem toch de HTML-code in sluipen. Een zoekmachine moet deze rompslomp wel doorploegen om tot de kern van de zaak te komen.

En dus is het aan degene die die markup maakt om daar niet al te veel overbodige rommel tussen te zetten. Ik denk dat deze zin een reden was voor Fred om me op het artikel te wijzen, aangezien ik het daar gisteren nog over had.

Ook is het ook nog eens zo dat je HTML vaak niet helemaal vrij kunt opmaken aan de hand van de informatie, omdat het anders moeilijk te stylen is. Denk aan tables, list menus en vooral ongepaste zaken als HR’s. HTML beschrijft eigenlijk de opmaak van een rapport van het CERN. Op informatieniveau is er geen onderscheid tussen ‘ordered lists’ en ‘unordered lists’, maar bijvoorbeeld een paragraph is weer heel ‘non-descript’. Een paragraph zou bijvoorbeeld een of meer kernwoorden moeten kunnen hebben. Makkelijk voor quickscans en zoekmachines. Begrippen als samenvatting, voetnoot, referentie zouden mooie toevoegingen zijn aan HTML. En ook de regels waarmee je HTML samenstelt met gebruikmaking van deze tags zouden wat beter gedefinieerd moeten worden.

Met deze paragraaf heb ik tamelijk veel moeite. Sven stelt dat je een hele bult onnodige, of in ieder geval onsemantische, HTML moet gebruiken om een document van (CSS) stijlen te kunnen voorzien.

Geen idee waar hij dat vandaan haalt, maar kloppen doet het niet.

Je kunt, vandaag de dag, best een document in HTML opzetten dat geen enkele “overbodige” rommel op het gebied van presentatie bevat, zeker als je eens kijkt wat HTML5 je te bieden heeft.

De reden dat je op zoveel pagina’s zoveel extra rommel tegenkomt, is dat er op die pagina’s allerlei zaken staan die eigenlijk niets met de content te maken hebben. Denk aan navigatie, en dan vooral “extra” navigatie die je — meestal — in sidebars tegenkomt. Denk aan advertenties. Denk aan lijstjes met “recente artikelen” en “recente reacties”.

Een andere reden dat veel documenten vol staan met allerlei extra rommel, is simpele gemakszucht of onkunde van de maker. Je hoeft niet een hele pagina uit 80 tabellen op te trekken, maar als je niet thuis bent in CSS dan is dat wel de enige manier om de presentatie die je voor ogen hebt daadwerkelijk te realiseren.

Dat ligt echter niet aan de eventuele tekortkomingen van HTML, CSS of zelfs maar de browsers.

Dat een paragraph “non-descript” is, is logisch: het is een paragraaf in een tekst; die staat of valt over het algemeen met de paragrafen ervoor en erna. En waarom zou er geen verschil zijn, op informatieniveau, tussen unordered en ordered lists? Wat voor informatie zou daar aan toegevoegd of afgehaald moeten worden?

RSS doet het eigenlijk veel beter, zij het heel beperkt. Daar is de content puur ingedeeld op basis van de inhoud zonder enige concessie aan de presentatie (behalve wellicht presentatievolgorde).

Dit vind ik een heel vreemde gedachte. In RSS is alle content in feite een grote lap platte tekst, zonder enige vorm van semantiek of duiding. Pas als je binnen die RSS gebruik gaat maken van HTML, komt dat onderscheid er. RSS ziet er misschien gestructureerder uit dan HTML, maar ook daarin kun je prima specificeren wie de auteur is, wanneer het artikel geplaatst is, enzovoorts.

Mijn pleidooi gaat dan ook over een pure markuptaal die aangeeft wat tekst betekent in een document. Headings horen daarbij, maar vooral allerlei geannoteerde tekst en plaatjes, en de verbanden tussen al de content onderdelen.

Goed idee. Laten we die headers gaan aanduiden met elementen als “header”. Weet je wat, ik wil koppen een beetje hierarchische informatie meegeven; laat ik H1 gebruiken voor een header van het hoogste niveau, H2 voor een sub-header, H3 voor iets dat daar weer onder valt, enzovoorts.

Verder wil ik bepaalde stukken tekst nadruk kunnen geven; laat ik dat “emphasis” noemen en daar een element EM voor gebruiken. Weet je wat? Ik wil sommige zinsnedes nog meer nadruk geven, een “strong emphasis” dus, oftewel STRONG.

Plaatjes konden in HTML al, maar ik wil dat iets kunnen uitbreiden: ik wil er een titel of bijschrift kunnen zetten. Weet je wat? Ik gebruik daar FIGURE voor.

Laat ik daar vooral niet stoppen: ik wil ook stukjes tekst in de zijlijn kunnen toelichten. Dat noem ik… ach, laat ik ASIDE gebruiken. En die voetnoten kan ik mooi in een FOOTER kwijt.

Ik kan nog wel even doorgaan, maar ik denk dat het punt wel duidelijk is: in HTML, en zeker in HTML5, kun je al redelijk wat betekenis aan onderdelen van je document geven. Is het perfect? Nee, maar in plaats van HTML weggooien en met iets heel nieuws komen, zonder te vertellen wat dat “iets heel nieuws” nou precies zou moeten zijn, lijkt het me handiger om voort te borduren op wat we nu hebben, waar mensen nu bekend mee zijn, en waar al gigantisch veel programmatuur voor bestaat.

De goed verstaander leest hier ’semantic web’.

Ah, Semantic Web, het wachten was op die term.

Nou kun je dat vandaag de dag best zelf realiseren. Bouw maar een pagina die uitsluitend bestaat uit Javascript en dat Javascript haalt vervolgens een XML bestand op met louter semantische structuren en gaat vervolgens je hele pagina opbouwen.

Gelukkig ziet Sven zelf ook al in dat dat onhaalbaar is. De goede verstaander haalt er bovendien uit dat je niet zomaar iets kunt verzinnen: er bestaat ook nog zoiets als “de rest van de wereld”, en tenzij jouw idee bijzonder goed is en/of jij een hele grote speler bent (neem een Google, Microsoft), de rest van de wereld niet meegaat.

Daarom zijn er ook commissies als de W3C en WHATWG, waarin mensen uit verschillende hoeken van het web proberen afspraken te maken over precies de zaken waar Sven ook al over denkt.

Is dat er dan niet allemaal al lang?

Ja.

HTML5 implementeert al heel wat meer semantiek dan de voorgaande versies. MicroFormats vullen dat aan. En als je met een zinnig voorstel komt en mensen er enthousiast voor kunt krijgen, kun je er vandaag nog je eigen toevoeging aan maken.

Laat ik maar eens een wilde stelling poneren: het Semantic Web bestaat allang.

Ja en nee. Om bij het voorbeeld van HTML te blijven is het zo dat ik een pagina in mijn browser open en dus informatie opvraag. Ik open dus een HTML-bestand en die gaat vervolgens op eigen houtje de bijbehorende opmaak regelen door het laden van CSS en script files. Vaak gelukkig aan de hand van wat ik voor browser heb, maar meestal levert dit een hutspotprak content en vorm op.

Hoe vaker ik deze paragraaf lees, hoe meer pijn in mijn hoofd ik ga krijgen.

Allereerst: dat HTML-bestand doet helemaal NIKS. Niet op eigen houtje, niet op andermans houtje, HTML is gewoon een kwak content, met links naar CSS-bestanden (die de presentatie kunnen beinvloeden) en Javascript-bestanden (die interactie kunnen toevoegen, en soms ook nog een stukje presentatie meenemen.

Die bestanden worden door de browser opgehaald. En inderdaad, niet elke browser kan met alles even goed overweg — Internet Explorer, bijvoorbeeld, maar je kunt ook denken aan text-only browsers als Lynx, die de CSS- en Javascript-bestanden dan ook links laat liggen.

Die hutspotprak? Geen idee wat daarmee bedoeld wordt.

Eigenlijk zou je browser twee dingen moeten ophalen: de content en een presentatievoorschrift (CSS/Javascript to the limit zeg maar). Maar technisch gebeurt er natuurlijk iets heel anders: het voorschrift gaat als eerste aan de slag en peutert de content uit elkaar om het op de juiste manier weer te geven.

Laten we het nog iets verder uitkristalliseren: je browser zou allereerst het belangrijkste moeten ophalen: de content. Die zal over het algemeen in HTML gegoten zijn. Verder kan daar nog opmaak aanhangen, in het ideale geval volledig afgesplitst naar een CSS-bestand. Voor de interactie gebruiken we Javascript, wat ook weer naar een apart bestand gaat. Nog een stap verder: plaatjes zetten we ook in een apart bestand.

Bij het eventuele ophalen van die bestanden laten we de browser — al dan niet met enige invloed van de gebruiker — beslissen welke bestanden-ie wel en niet aankan, en welke bestanden er dus wel of niet moeten worden opgehaald.

Oh, wacht, dat is precies wat er vandaag de dag al gebeurt.

Helemaal geldt dit voor mashups: daar wordt content immers van meerdere bronnen opgehaald en met elkaar in verband gebracht. In de browser is dus eigenlijk het presentatievoorschrift de baas, maar we klikken op basis van een link die iets zegt over de content.

Tenzij ik me vergis, is een mashup een stukje programmatuur dat de functionaliteit van twee verschillende sites (of web-applicaties) combineert, en aan de hand daarvan zelf die gecombineerde content uitvoert.

Dat kan eventueel in de browser gebeuren, maar over het algemeen zal dat server-side gebeuren.

Wat dat met links te maken heeft, ontgaat me een beetje, tenzij Sven het hier niet over hyperlinks heeft.

Lastig dilemma. Ik denk dat we daarom de definitie van een hyperlink moeten verbreden. Een hyperlink geeft niet alleen de locatie van content aan maar ook hoe het bij voorkeur gepresenteerd moet worden.

Dat bestaat al. Aan een A-element, waarmee je hyperlinks maakt, kun je al een relatie hangen. En een beschrijving van het soort informatie waar de link naar wijst. En een taal waarin die content is geschreven.

Ook in LINK-elementen kun je dat soort metadata meegeven.

(Dat gebeurt nu eigenlijk ook: www.nu.nl vs. m.nu.nl zeg maar, maar dat is niet helemaal waar ik naar toe wil). Ik zou willen pleiten voor een protocol header waarin een link naar het presentatievoorschrift van voorkeur staat. De opvragende applicatie hoeft er natuurlijk niets mee te doen, met dat presentatievoorschrift, maar als deze dat wel doet dan kan hij ermee aan de slag. Het gaat er om dat content en presentatie los van elkaar staan, dus ik vind dat er in de content geen verwijzingen moeten zijn naar het presentatievoorschrift. De opgevraagde pagina bestaat uit pure content.

En wat gebeurt er dan als je die content “direct” opvraagt, zonder een link-met-presentatievoorschrift? Wat zijn de implicaties voor links naar “externe” content, dus als ik naar content op iemand anders’ site link? Moet ik daar wel invloed over hebben?

Het lijkt me veel logischer om “presentatievoorschriften” direct aan de content te koppelen — zoals het nu dus gebeurt — dan om die te laten afhangen van links naar die content.

Makkelijk voor mashups, maar ook voor dataspaces en zeker voor widgets, gadgets en apps. En bedenk eens wat dit voor de snelheid van browsers kan doen, want de content zonder alle opmaak kan wel eens een heel stuk lichter zijn. Presentatievoorschriften lenen zich immers heel goed voor cachen, dus die hoef je niet telkens opnieuw binnen te halen. Eerlijkheidshalve is het natuurlijk wel zo dat de eerste keer dat je een pagina met een bepaald presentatievoorschrift binnenhaalt, dat wel wat langer kan duren.

Hier haalt Sven volgens mij weer wat dingen door elkaar, en hij lijkt bepaalde eigenschappen van het huidige web niet te begrijpen.

CSS (en andere externe bestanden) zijn ook prima te cachen, dus na de eerste pageview op een site ben je al lichter aan het browsen. De enige overhead die je hebt, is wat er om die content heen staat; de navigatie en overige meuk die je steeds meer tegenkomt.

Het zou leuk zijn als je in HTML een soort van include kon gebruiken om die zaken ook naar een apart bestand af te splitsen. Je hoeft dan niet alle sidebars, extra headers, advertenties enzovoorts op te halen omdat je toevallig een tweede pagina wilt zien.

Nadeel van die methode is dat het extra requests naar de webserver oplevert, wat het opvragen van de totale pagina langzamer maakt; het voordeel dat je haalt uit het uit de content strippen van die extra code wordt zo weer teniet gedaan. Een ander nadeel is dat het weer allerlei interessante beveiligingsproblemen kan opleveren, die we vandaag de dag al met Javascript hebben.

Met een beetje werk en fantasie zou je overigens wel een splitsing kunnen maken, via Javascript en/of iframes, en dat wordt ook al gedaan. Vooral webapps staan bol van AJAX, wat niet veel anders is dan “na het laden van de pagina extra informatie ophalen om die pagina aan te vullen of te veranderen”.

Voor een site die vooral om content draait, levert dat in de meeste gevallen meer problemen op dan dat er opgelost worden. Het is ook niet zo vreemd dat je het bijna nergens tegenkomt.

Ik vind het model heel elegant en dat is een uitspraak die je misschien alleen van programmeurs zult horen. De meeste normale mensen kunnen niks met elegante data. Ontwikkelaars echter wel, die kunnen veel sneller schakelen tussen presentatiemethoden en veel makkelijker content aggregeren.

En die ontwikkelaars kunnen dat ook al, zolang de data maar gestructureerd wordt gehouden. Of die structuur nou HTML, XML, JSON of iets anders is, maakt dan per saldo niet eens zoveel uit. Elke zichzelf respecterende programmeertaal heeft tegenwoordig standaard-functionaliteit (of libraries) voor het werken met DOM, XML en HTML, en elke pagina waarvan de code klopt is dan te gebruiken als databron.

Ook kun je de vormgever en de author nog onafhankelijker van elkaar laten opereren. Dat is fijn voor beiden, want ten opzichte van elkaar zijn ze eigenlijk heel restrictief: de “dit zinnetje moet korter want ik heb geen ruimte” discussie wil je minimaliseren.

Die discussie verandert niets door het dumpen van HTML, want die discussie is inherent aan het medium. Een ontwerper zal er rekening mee moeten houden dat de content misschien anders is — of anders gezien wordt — dan in zijn Photoshop-mockup. Ontwerpen voor het web is nou eenmaal iets anders dan ontwerpen voor papier.

Dat is ook een groot voordeel, trouwens, want daarmee wordt informatie ineens geschikt voor een bredere groep gebruikers. In plaats van dat een slechtziende een andere versie van de content moet zoeken, kan hij simpelweg het lettertype in zijn browser groter zetten. Ja, dan zal er het nodige gaan schuiven, maar dat zal die slechtziende worst zijn.

Bovendien: veel van die verschuifproblemen zijn te ondervangen.

Het tweerichtingskarakter van het internet (Web 2.0 zo je wilt) is er ook mee gediend. Wil iemand bijdragen dan hoeft hij of zij zich alleen maar druk te maken over de inhoud van zijn/haar bijdrage. Laat het opmaken maar aan de machine over. Op die manier verzamel je veel beter hanteerbare content. Dit is niet het sterkste argument, geef ik toe, want dit gebeurt al in hoge mate, maar het toevoegen van geolocatie en sensorische informatie wordt wel steeds belangrijker dus ook de upstream mechanismen van het web verdienen heroverweging.

Waarom? Wat heeft het meesturen eventuele extra meta-informatie — want daarover heb je het als je over geolocatie en dergelijke begint — te maken met de uitvoer? Dat gebeurt op een heel ander niveau! De gebruiker hoeft helemaal niets op te maken of te coderen, dat doet de applicatie, tenzij de maker van de applicatie verdomde lui is.

Dit is niet zozeer “niet het sterkste argument”, dit is gewoon een non-argument.

Sommige uitgevers zullen nu hun billen bij elkaar knijpen, want als dit ooit een feit zou worden dan is herpubliceren van hun dure content nog gemakkelijker geworden. Ik ben van mening dat dit eigenlijk een achterhoede gevecht is van die uitgevers. Het zijn op dit moment toch al huilebalken, maar veel aan hun modellen veranderen willen ze niet en daar is Darwin vrij meedogenloos voor. Maar als doekje voor het bloeden: je zou best een presentatievoorschrift kunnen bedenken die als enige de content kan interpreteren door middel van encryptie. DRM zeg maar.

Whu-… Wat? DRM? En die dan gaan laten afhangen van wat er aan de kant van de consument gebeurt?

Allereerst: als je jezelf afhankelijk gaat maken van DRM heb je bij voorbaat al verloren.

Verder: als je al besluit dat je van DRM gebruik gaat maken, dan regel je dat op het moment dat de content nog verstuurd moet worden, niet op het moment dat de gebruiker het al in handen heeft. Server-side, dus.

Ik ben echt reuze benieuwd hoe Sven dat hele DRM-verhaal ongeveer voor zich ziet, want ik zie geen enkele manier om dat op een open web mogelijk te maken. Noch zie ik daar de noodzaak toe.

Anderzijds denk ik dat in de toekomst content wel eens heel goedkoop kan worden. Veel publiek zal meningen, nieuws en allerlei andere bijdragen leveren, vaak om niet.

Die toekomst is al een paar jaar aan de gang, hoor…

Ik vind natuurlijk dat journalisten werk doen van een andere orde, en daar zou zeker ook een prijs voor moeten zijn. Maar journalisten verzamelen informatie, onderzoeken, ordenen en aggregeren het. Misschien gaan we wel juist betalen om het te vinden, te verzamelen, te interpreteren en om het goed in verband te zien. (Of juist negeren en weigeren het te zien al naargelang je politieke voorkeur).

Dat is iets waar momenteel inderdaad heel druk over gedacht en gespeculeerd wordt. Allereerst de vraag of journalisten daadwerkelijk een toegevoegde waarde hebben (ik neig naar een voorzichtig “ja”) en bovenal hoe groot die waarde is en hoe dat allemaal betaald moet gaan worden.

Micropayments werden al jaren geleden aangedragen als De Toekomst, maar dat is nog niet echt van de grond gekomen. Mocht dat wel gaan gebeuren: HTTP is er sinds versie 1.1 al op voorbereid in de vorm van status header 402 (“Payment Required”).

Ondenkbaar? Abonnees van kabel TV zijn best bereid te betalen voor uitzending gemist-programma’s, ook als je het in een veel minder aantrekkelijke presentatievorm elders gratis kunt kijken. Knoop het in je oren!

[Citation needed]. Van TV weet ik verder vrij weinig af, maar voor zover ik weet worden mensen aangetrokken door drie dingen: Gemak, Beschikbaarheid en Prijs. Prijs speelt daar een belangrijke rol in, anders zouden er niet zo gigantisch veel films worden gedownload; dat is immers meer werk om naar een mindere kwaliteit te gaan zitten kijken.

Los daarvan: het staat volledig los van een discussie over het al dan niet vervangen (of aanvullen) van HTML. Of een presentatievorm al dan niet aantrekkelijk is hoeft absoluut niet af te hangen van het medium en de technologie erachter, dat is een zaak voor de ontwerpers en usability-mensen.

En toen moest ik ook nog iets concluderen

Svens artikel springt een beetje van de hak op de tak, wat het lastig maakt om het te begrijpen. Hij begint over HTML, maar betrekt daar wel allerlei zaken bij die er soms maar zijdelings mee te maken hebben, of die in ieder geval geen enkel verband houden met het al dan niet laten vallen van HTML.

Niet dat al die zaken onbelangrijk zijn, maar ze zijn ondergeschikt aan een veel grotere, en lastiger op te lossen kwestie: het doeltreffend ordenen en presenteren van informatie is moeilijk. Goede markup is moeilijk. Goede CSS is moeilijk. Consistentie in die drie vlakken is moeilijk.

Niets daarvan wordt opgelost door HTML te vervangen. Een hoop problemen die Sven in HTML ziet, zijn allang opgelost, althans in theorie. Semantische opmaak is vandaag al mogelijk, en het stelt je in staat om met een minimum aan overbodige opmaak toch een document met CSS van een gewenste stijl te voorzien. Het wachten is tot iedereen dat ook daadwerkelijk doet, en daar zit hem het probleem: de aanbieders.

Zolang grote partijen, maar ook “simpele thuisgebruikers”, het medium op een “verkeerde” manier gebruiken — door gebrek aan kennis of gemakzucht — komt dat semantische web er nooit voor de volle honderd procent. Dat hoeft niet eens een probleem te zijn, zolang content maar op andere manieren te verkrijgen is, en ook dat is al mogelijk, en gebeurt op grote schaal middels allerlei API’s.

HTML kan blijven!

Uw ervaringen en meningen worden zeer gewaardeerd.

Vorige post:

Volgende post:

Je kunt vanaf je eigen site pingbacken of een trackback sturen naar deze URL. Meer informatie over pingback en trackback vind je hier.

sven zegt:

Heel fijn dat je dit artikel aangegrepen hebt om er toch een fatsoenlijke discussie van te maken. Of ik het niet snap of wel, ik heb toch echt een vrij helder beeld op mijn netvlies.over wat ik bedoel. Maar okee, ik ben ook niet de uitvinder van het web.

Ten aanzien van de titel: die is gechargeerd, en ik ken mijn HTML best wel. Er is een rest van de wereld, en ik ga HTML niet eigenhandig uitbannen, het was meer bedoeld als een gedachtenexperiment. Sorry dat ik daarin niet duidelijk genoeg ben geweest, want ik wil geen hoofden uiteen doen spatten of iets dergelijks.

Er zijn twee aanleidingen waardoor ik toch deze uiteenzetting heb gemaakt.

Ten eerste, internet pagina’s worden niet alleen door browsers weergegeven maar volop gespiderd en doorzocht door zoekmachines om de gegevens te indexeren. Vaak zou je de inhoud van pagina’s ook willen weergeven met behulp van een app of verder aggregeren door mashups, of gebruiken in een Flash of Java object. Het is voor apps en mashups ontzettend handig als de informatie op de pagina ook als een wat “platte” XML of JSON feed, RSS feed of iets dergelijks beschikbaar is. Vaak is dat ook zo gelukkig, maar lang niet altijd. Ik vraag me -bij wijze van gedachten experiment- eens af hoe het zou zijn als we de HTML versie laten vallen en de “logisch geordende content” gebruiken. Is er een betere logische ordening denkbaar dan HTML? Ik denk dus van wel. En xHTML en nog meer HTML5 bieden daarvoor ook mogelijkheden, ben ik ook met je eens.

HTML is geevolueerd uit pagina opmaak in de browser, en geinspireerd door papierdruk. Ik heb indertijd ook nog Lynx gebruikt, en een van de aardige dingen was dat HTML zo eenvoudig was in die tijd. En vooral dat het ging om de inhoud en niet om de form. Maar ik ben een nerd, en ik snap best dat in tegenstelling tot mijzelf mensen griezelen van command line tools. Ook snap ik dat vorm een hoop toevoegt aan inhoud en dat HTML/CSS daardoor ook complexer geworden is. Maar mag ik me ook eens hardop afvragen of het wel de beste weg is om voort te borduren op HTML? Even afgezien van het feit dat ik echt wel snap dat je nu niet een totaal andere weg kunt inslaan: door een keer een what-if situatie te bedenken kom je soms tot verrassende inzichten.

De tweede aanleiding was dat als ik dan per se mijn eigen XML webservice wil gebruiken dat best kan volgens de eerder beschreven Javascript-only met AJAX methode, maar dat een zoekmachine niet veel doet met een javascript-only pagina. Daarnaast is dit supersloom, natuurlijk… Inderdaad moet je immers de content kunnen ophalen op een link en niet een berg Javascript.

Dat HTML niet op eigen houtje zijn opmaak regelt snap ik ook wel, maar in die HTML staat wel precies welke stylesheets daarvoor worden gebruikt. Dat is dus evengoed onderdeel van diezelfde HTML. Stylesheets zijn de “presentatievoorschriften” van vandaag in de browser. Al dan niet in combinatie met Javascripts. Maar nogmaals, ik wil me niet beperken tot alleen maar die browser.

Kijk bijvoorbeeld naar Adobe Flex. Dat vind ik eigenlijk ook een presentatievoorschrift. Moet ik mijn Adobe Flex object dan HTML laten parsen? Het kan wel, maar als je een Flex applicatie bouwt wil je het toch graag juist wat eenvoudiger hebben. REST ligt meer voor de hand. Waarom? Omdat computers REST eenvoudiger kunnen parsen en eenvoudiger kunnen bepalen welke samenhangende data er eventueel nog meer opgehaald moet worden om het geheel te presenteren.

Nog een voorbeeldje: Voor mobiele applicaties is er ooit zoiets bedacht als WML (ken je WAP nog?). Een ontzettend beperkte markup die verreweg inferieur was aan i-Mode cHTML. Maar voornamelijk omdat er geen styling in gedefinieerd was. In WML kon je niet een pagina maar een setje samenhangende pagina’s in een http-request naar je toe halen. Ik ben geen fan van WML en het is niet voor niets dood. Maar iemand heeft wel nagedacht over waarom HTML in die tijd NIET de beste oplossing was. Dat hing samen met bandbreedte en een zo kort mogelijk contact tussen client en server. WML was voor (inmiddels antieke) telefoons een efficientere oplossing dan HTML.

Ik wil hier best veel dieper ingaan op je analyse. Maar ik wil een misverstand opzij hebben want dat geeft er zo’n nare toon aan: Ik vraag me gewoon af of HTML echt wel de beste benadering zou zijn voor het web als je van te voren alle kennis en inzichten zou hebben van nu. En nu is het web veel meer dan alleen browsers, dus wil ik me daartoe ook niet beperken. Sorry als ik daarmee iemand voor zijn schenen schop.

Max zegt:

Oeh, da’s een lange reactie. =] Ik loop hem gewoon weer op volgorde door:

Gechargeerde titels? Niks mis mee, en mijn hoofd zit gelukkig nog redelijk in elkaar.

Wat betreft het externe gebruik: waarom houden we dat niet gewoon lekker in JSON/XML/whatever, naast de gewone HTML-versie? Vooral JSON is lastig te overtreffen wat betreft leesbaarheid en zuinigheid. Voor de gevallen waarin een API echt niet mogelijk is, is (valide) HTML een prima fall-back. Vooral omdat er op een pagina in 99% van de gevallen heel wat meer voorkomt dan alleen die content. HTML is dan handig omdat het ook die extra meuk ondersteunt.

Je afvragen of HTML de beste basis is om op voort te borduren… Dat lijkt me prima. Sterker nog, dat is vaker gebeurd. Het houdt je inderdaad wakker.

XML naar een browser… Kon dat ook niet met XSLT? Blijf je natuurlijk het zoekmachineprobleem houden, maar je bent van Javascript af. Overigens: hoe traag is dat daadwerkelijk, op een moderne browser?

Presentatievoorschriften buiten de browser… Ja, ik denk dat ik nu begrijp hoe je dat bedoelt. Dat kan, mits strikt optioneel, misschien handig zijn. An sich kan dat lijkt mij ook met CSS, hetzij inline (ieuw) of via een apart (klein, cachebaar) CSS-bestandje. Het is misschien bedoeld voor HTML, maar het is daarbuiten best te gebruiken.

Flex ken ik niet echt, maar als ik de overview skim lijkt me dat meer een ontwikkelomgeving. Tenzij ik dan iets belangrijks mis lijkt me dat niet echt een presentatievoorschrift, tenzij je alle programmatuur daaronder gaat laten vallen. Kan wel, natuurlijk… =]

Ik ben het met je eens dat andere formaten misschien efficienter zijn om data uit te wisselen; met name JSON zal een geweldig code-to-content ratio hebben. Toch: in geval van nood of nodig kan het met HTML, en dan kun je nog steeds kijken naar samenhangende data via META elementen.

WML, ach ja, WML. Grappig genoeg kon je daar juist wel een setje pagina’s in een document hebben; heette dat niet een stack of zo? Ik ben er destijds wel eens mee aan het stoeien geweest. HTML kan veel meer dan voor WML nodig was, en bovendien lang niet zo strict. Zo enorm groot waren de verschillen verder niet, dacht ik.

Misschien een idee om meer te gaan denken vanuit een “wat moet een eventuele opvolger allemaal kunnen”-vraag. Kijken naar wat er aan HTML ontbreekt of mis is, limiteert je dan toch al snel, denk ik. En hou er rekening mee dat je waarschijnlijk op minstens twee opvolgers uitkomt, eentje voor consumptie, en eentje voor hergebruik. Die twee scenario’s verschillen genoeg van elkaar om dat lastig te combineren, zonder dat je een van de twee tekort doet.

Dat allemaal gezegd hebbende: niks mis met je afvragen of HTML de beste benadering is. Mijn enige punt met je gedachtenexperiment was dat het vooral een brain dump leek, en daardoor voor anderen lastig te volgen, en nog lastiger om op in te haken. Last van mijn schenen heb ik verder niet, gelukkig. =]

Sven zegt:

Mijn artikel op Frankwatching was misschien inderdaad meer een braindump dan ik besefte. Een blinde vlek mijnerzijds, denk ik. Gelukkig dat we nu wat meer inhoudelijk bezig zijn.

Ik wil graag op nog een paar punten reageren.

Als je kijkt naar leuke websites en mooie apps komt sinds een paar jaar eindelijk veel meer de nadruk te liggenop interactiviteit en niet alleen op mooie kleurtjes en plaatjes. Maar het gaat ongetwijfeld ook verder: Op websites wil ik ook kunnen swipen, ik wil bijv. coverflow effecten gebruiken om door informatie te scrollen, ik wil multitouch interfaces kunnen gebruiken, ik wil dingen geanimeerd hebben, zo mogelijk in 3D en met shadows, spiegeling en lighting effecten.

Dat is een beetje het beeld wat ik voor ogen heb als ik denk aan de toekomst van het web. En dit zijn dingen waar CSS toch niet of nauwelijks in voorziet. Vandaar dat ik nadenk over “presentatievoorschriften”. Het is een beetje nadenken wat ik van de kerstman wil, maar het kan geen kwaad om je af te vragen wat daar voor nodig zou zijn.

Okee, nog wat puntjes dan:

Hyperlinks: Hyperlinks ZIJN niet meer dan een verwijzing, maar bijvoorbeeld hyperlinks binnen een website (menu’s) geven wel degelijk iets aan over de structuur van die website. Hyperlinks geven naast klikgemak op een erg vrijblijvende manier verbanden aan tussen informatie. Het zou voor het bepalen van relevantie van informatie door computers best wat handiger zijn als de computer (zoekmachine) wat meer informatie had over het waarom van een hyperlink.

Een nieuwe markuptaal ipv. HTML: Dat HTML een hoop tags bevat die heel voor de hand liggen om een document mee op te maken is natuurlijk helemaal waar. En waarom zou je meer nodig hebben? Misschien heb je dat niet, ik heb het wel eens. HTML is vooral een opmaaktaal. Maar het is geen markup geoptimaliseerd om de structuur en meta informatie van de content aan te geven. Ben ik eigenlijk al op ingegaan. HTML naast JSON/XML: lijkt me de realiteit van vandaag. Daar wil ik ook niets aan afdoen.

Hutspotprak: Ook dit is volstrekt gechargeerd, want er zijn goede frontenders die heel clean opmaak van plain HTML kunnen scheiden. Maar doorgaans hebben de CSS en de HTML een hele sterke band, al is het maar vanwege de ids en de classes. Je kunt lang niet altijd een willekeurige HTML met een willekeurige CSS combineren en verwachten dat dat goed komt. De browser combineert ze ook tot een DOM. Als je nou een DOM zou hebben die de opmaak beschrijft waarin je vervolgens content kunt hangen (zoals de ballen in een kerstboom) aan de hand van meta informatie, is misschien een eigentijdsere benadering dan een content DOM opzetten die je van stijlattributen voorziet. Let wel: dit is what-if denken, denk er eens over na. We hoeven niet meteen alles weg te gooien wat we hebben…

Over tweerichtingsverkeer: ik heb zelf vaker de behoefte om behalve het obligate NAW-achtige formulier ook informatie te submitten die complexer georganiseerd is. Bijvoorbeeld lijstjes of hierarchische structuren van gegevens. Zou het niet aardig zijn als we meer JSON/XML in forms-requests zouden gebruiken? Nogmaals: ik weet dat dit middels AJAX al kan, maar ALS je nadenkt over een opvolger van HTML staat dit wel op mijn wensenlijstje…

DRM en gratis content: Even een wat minder dromerige stelling: Nieuws is NIET gratis. We betalen er alleen niet voor, of in het gunstigste geval klikken we op een advertentie. De mensen die bij het ANP werken moeten hun kroost ook te eten geven en dat geldt voor een hoop persbureaus. Deze activiteiten zijn zelden winstgevend maar worden betaald uit allerlei aanpalende activiteiten, zoals reclame (web) entertainment (tv en dus indirect ook weer reclame) of mensen die nog wel voor hun krant betalen. Ik vind dat we daar op een of andere manier ook voorzieningen moeten hebben op het web of in de browser. Inderdaad is er een HTTP response code “payment required” maar die voorkomt kopieren en herpubliceren niet. BetaalTV lukt tot op zekere hoogte wel, kunnen we tenminste nadenken over hoe zoiets voor het web eruit zou moeten zien. Nu kun je als consument nog kiezen of je iets wilt tegen betaling. Er zijn een hele hoop domme mensen die alles willen oplossen met restricties op internetverkeer, en die zijn wel aardig aan het winnen. Let wel: ik ben geen hugger van DRM, maar als hier geen oplossingen voor komen staat ons vrije internetters een somberder toekomst te wachten…

Schiet maar weer…

Max zegt:

Animaties en dergelijke? Kijk eens hier en hier… Momenteel kunnen we nog lang niet van “cross-browser” spreken, maar dat komt vanzelf, en andere eye-candy ook. Coverflow in je browser is vandaag al mogelijk.

Navigatie-links zijn en blijven gewoon platte, recht-op-en-neer links. De plaatsing en presentatie ervan maken het tot “navigatie-links”, althans voor de bezoeker. In HTML5 is dat beter geregeld met NAV en MENU-elementen, waarmee je daadwerkelijk aangeeft dat een link onderdeel van de navigatie is.

Met betrekking tot het hutspotprak-verhaal en de noodzaak van classes en ID’s: ik ben bang dat dat in veel gevallen toch echt niet nodig is. Het zou nog minder nodig zijn als een bepaalde veelgebruikte browser de geavanceerde CSS-selectors zou ondersteunen. Nog los daarvan kunnen classes een semantische waarde hebben, bijvoorbeeld voor MicroFormats, en IDs geven je ook haken voor Javascript en formulieren (labels!). Het draait niet alleen om haakjes voor CSS.

Tweerichtingsverkeer: Ja, ik denk dat het soms handig zou zijn als je ergens een dot JSON o.i.d. kon neergooien; ik denk ook dat dat voor de gemiddelde bezoeker veel te hoog gegrepen is. Met kunstgrepen als Markdown of wiki-markup kom je al een eind om toch iets van structuur aan plain text mee te geven, maar meer dan kunstgrepen zijn het niet. Ingewikkelder datastructuren passen nou eenmaal niet echt in een lap plain text, niet als het door Jan-met-de-pet moet worden kunnen ingevuld.

DRM: Ik snap dat het journaille ook moet eten, maar mijn punt was juist dat kopieëren en herpubliceren op internet nagenoeg onmogelijk te voorkomen zijn. Moeilijker maken, misschien, maar bits en bytes zijn altijd te kopieëren. Vandaar ook mijn standpunt dat DRM per definitie geen echte slagingskans heeft.

Herpubliceren is trouwens juist een voordeel in mijn optiek; mits het netjes en met bronvermelding gebeurt, krijg je meer exposure. Een artikel integraal copypasten is weer een ander verhaal. Toch is dat meer een kwestie van attitude dan van techniek, denk ik. Vrees ik.

Sites achter een paywall kunnen werken, zo lang zo’n site daadwerkelijk unieke content biedt. Als ik op twee plaatsen hetzelfde kan lezen, en één van die plaatsen vraagt geld, dan haal ik het dus op de andere plaats. Toch lijkt de Wall Street Journal het redelijk te doen. Het gaat er maar net om of je product ook daadwerkelijk als waardevol wordt gezien. TV is wat dat betreft (vanuit de publisher gezien) een makkelijker, want technisch gezien beperkter, medium.

Overigens: het gaat me er absoluut niet om om maar blindelings te roepen “je zit ernaast!”, ik hoop dat dat intussen duidelijk is. =] Wat mij betreft is het een interessante discussie / brainstorm, en hoop ik dat er meer mensen op inspringen.

Sven zegt:

@Max Ik weet dat eyecandy volop beschikbaar is. Leuk dat het werkt op Safari en het verdient navolging! Maar elders is het toch flink prutsen in Javascript of Flash om een en ander werkend te krijgen. Niet echt standaard HTML/CSS. Laten we hopen dat het ooit komt (als standaard). Intussen is overal wel een of andere oplossing voor, maar mijn punt is dat het lang niet altijd optimaal is om voort te bouwen op bestaande technieken. (Zeker niet met de veelgebruikte browser, hehe)

We komen inderdaad ergens. Geavanceerder selectors in CSS ben ik heel erg mee eens. Daar is echt wel wat te halen, en daarmee kun je inderdaad een veel betere scheiding tussen vorm en content bewerkstelligen. En classes die een semantische betekenis hebben: graag!

Als je kijkt wat Backbase doet op het gebied van forms, dan zie ik wel degelijk dat complexere datastructuren in je request meer dan handig zijn. Voor jan met die pet is een platte pagina genoeg omdat ie niet beter weet. Maar jan wist ooit ook niet waarom hij een computer nodig had…

Ik leef ook in de overtuiging dat DRM ten alle tijde een zwaktebod is. Ik noemde het niet voor niets een doekje voor het bloeden. In het verleden (Sony!) is genoeg gebleken dat DRM moeilijk houdbaar is. Het alternatief (het afsluiten van internet in Frankrijk bij vermoede illegale downloads, het feit dat ik dubbeltjes moet betalen op mijn lege CD’s, de eeuwige drang tot het afsluiten van sites) vind ik eigenlijk veel vervelender. DRM om het zo lastig mogelijk te maken is wat je zou kunnen doen.

Ik hou wel van een stevige discussie. En ik heb hier weer wat geleerd. Af en toe een beetje aan de boom schudden is echt niet verkeerd.

Max zegt:

Het verstandaardiseren van wat er nu in de laboratoria van WebKit en Gecko gebeurt, mja, dat zal inderdaad nog wel even duren. Jammer, maar het is niet anders.

Ik heb even bij Backbase gekeken; dat is al oud, trouwens! Ik herinner me ineens dat ik dat jaren geleden al eens gezien had. Destijds was het allemaal gruwelijk cutting-edge enzo, tegenwoordig zit het in elk framework wel ergens ingebakken. Maar… wat gebeurt er bij de forms wat volgens jou aan complexe datastructuren die de gebruiker invoert?

En of het “zo lastig mogelijk maken” echt een houdbare strategie is? Denk ik niet. Omarmen, zo snel mogelijk, en op basis daarvan je business model bijwerken of omgooien. Het landschap is veranderd, dat draai je niet meer terug.

maarten zegt:

Wat ik nog niet gehoord heb is dat HTML nogal laagdrempelig is vergeleken met XML CSS Javascript of wat dan ook. Je hebt heel snel een content en een beetje layout gemaakt… bij die andere moet je daar eerst op studeren.

Max zegt:

Als je het goed wil doen zul je je in HTML net zo goed moeten verdiepen, lijkt me. Dat was ook mijn punt: het is moeilijke materie. Je zult hoe dan ook moeten nadenken over structuur en logica en noem maar op.

Het enige voordeel van HTML is dat je daar nog met vrij veel ongein wegkomt, omdat browsers behoorlijk vergevingsgezind kunnen zijn. Voor “n00bs” (en dan bedoel ik die term niet neerbuigend) is dat prettig, want inderdaad laagdrempelig. Voor het web an sich is het iets minder, want je komt daardoor om in de tag soup. =]

Fred Zelders zegt:

Max, geweldig dank voor het uiteen rafelen van de gedachtenspinsels van Sven en het in hapklare brokken daar op reflecteren. Geweldig! Een en ander is me nu een stuk duidelijker geworden.

Wat ik hier bevestigd zie is wat ik altijd al vond: Verzin niet meteen weer iets nieuws, iets anders, zonder dat je alle mogelijkheden van de dingen die al bedacht zijn (geldt voor van alles en dus ook voor HTML, XML, CSS, Javascript, etc. denk ook aan RSS en OPML) hebt doorgrond. De mensen die zoiets bedacht hebben zijn ook niet van gisteren en hebben NATUURLIJK verder gekeken dan de neus van menig een lang is. Er wordt al genoeg verspild in deze wereld.

Laat maar horen


Vorige post:

Volgende post: