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!