Webtopia: weg met HTML!

sledgehammerTechnisch verandert er vandaag de dag een hoop in de manier waarop we het internet bekijken. Behalve het klassieke surfen zijn er ook mobiel surfen en een hoop desktop- en mobiele applicaties waarmee we informatie tot ons nemen. Daarnaast is de informatiesnelweg steeds meer tweerichtingsverkeer aan het worden. Tijd om te overwegen of we nog wel op dezelfde manier onze informatie moeten publiceren via HTML en CSS. Een pleidooi voor een ideaal internet.

Waarom scheiding van content en vorm?

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.

headbodyAan 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.

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.

Dat is toch helemaal niets nieuws?

jipenjannekeNee 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.

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.

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

foodMijn 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. De goed verstaander leest hier ‘semantic web’.

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.

Ja, zou ik best willen, maar voor zoekmachines is je pagina volstrekt onbruikbaar geworden, want Google gaat je Javascript echt niet zitten ‘reverse engineeren’. En sloom dat die handel wordt! Je moet een hele hoop bytes versjouwen voordat je een eenvoudige pagina kunt opmaken en Javascript zelf is ook niet zo snel.

Is dat er dan niet allemaal al lang?

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.cssisawesome

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

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

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.

En wat schieten we ermee op?

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.

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.

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.

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.

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

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!

Het is wel eens leuk om dingen op zijn kop te zetten in gedachten, maar voordat ik nu alle RFC-makers over me heen krijg: meer dan als gedachtenexperiment is dit niet bedoeld…

Interessant?

Lees dan ook onze andere artikelen over , , , , , , , .

Reacties

  1. Deze hypothese raakt kant nog wal, zelfs al is het bedoelt als gedachtenexperiment. Het lijkt of je alles wat je weet van markup, styling en scripts in willekeurige volgorde hebt opgesomd. Ergens zeg je dat het een pleidooi is, maar je voorstel komt niet uit de verf.
    Het semantische web, zelfs al is het Tim Berners Lee’s stokpaardje, is bovendien niet meer dan een hypewoord met een valse belofte. Lees dit artikel en ik denk dat je het met me eens zult zijn:
    http://www.shirky.com/writings/semantic_syllogism.html
     

  2. @tinus interessant artikel wat je noemt, ik moet het nog wat uitgebreider bestuderen. Ik ben het er ook best mee eens dat je van een computer nooit moet verwachten dat die tekst kan interpreteren zoals een mens dat doet.
    Ik wil best ingaan markup, maar dan wordt het een lang artikel. Ik pleit voor markup die de inhoud van een document beschrijft zonder iets over de opmaak te zeggen. In plaats daarvan moet de relatie tussen en de relevantie van de onderdelen van het document beschreven worden. Het voordeel is veel meer vrijheid in het presenteren, maar zeker ook veel mogelijkheden om tekst te laten raten en interpreteren door bv zoekmachines.
    Het semantische web is denk ik een soort utopia, maar je kunt wel een heel stuk dichterbij komen en dat gebeurt in de praktijk ook.
    Zeg maar als je behoefte hebt aan een wat meer uitgewerkte versie van mijn ideeen hieromtrent.

  3. Je wilt content zonder markup? Gebruik dan stiekem toch HTML maar zonder de tags die in de verste verte verwijzen naar opmaak. Maak je vervolgens een metadocument welke opmaak en content bij elkaar brengt: voila.
    (Dus, content.html, opmaak.css en een index.php met css verwijzing en include van de content…)
     

  4. Ik ben na de vierde alinea afgehaakt. :-(

  5. Hoe vaker ik dit artikel probeer te lezen, hoe minder ik begrijp van het punt dat Sven probeert te maken. Als er al een punt is, behalve “weg met HTML”. Ik ga er nog wat over nadenken, maar ik ben bang dat mijn hoofd ontploft.

  6. Mijn enige afdronk is scheiding van content en presentatie, duidelijk. Op zich kan dit artikel een mooie basis voor een gedachtenexperiment van dit principe maar tot nu toe lees ik weinig nieuws en al helemaal geen oplossing.

  7. Skip de voorlaatste reactie niet te vlug!
    De post van Max Roeleveld “Is het dumpen van HTML de enige manier om tot een semantisch web te komen? verschaft veel inzicht en geeft verdieping in de materie die Sven hier aan snijdt. Verder geeft Sven daar een reactie waarin hij zijn statement verduidelijkt.

  8. Dit is inderdaad een zwak punt van HTML zoals we het nu kennen.Maar daar HTML 5 eindelijk verandering in brengen.
    “Vaak gelukkig aan de hand van wat ik voor browser heb, maar meestal levert dit een hutspotprak content en vorm op.”
    Dat is niet de schuld van de content maar van de browser!Vooral dat bij elkaar geraapt zooitje random code genaamd Internet Explorer is koning pagina verzieken.
    Als ik alles met JavaScript zou gaan doen, doe ik niet alleen de zoekmachine breken.Maar maak ik me zelf afhankelijk van een optionele techniek, want de meeste mobieltjes ondersteunen niet tot nauwelijks Javascript.
    En screenreaders? Mensen met een visuele beperking.Als je JavaScript op een andere plek om de pagina iets laat weergeven (wat er nog niet was) kan die screenreader niet zien dat er iets is veranderd.
     
    HTML staat Voor Hyper Text Markup Language.Het is nooit bedoeld als precentatie vorm (daar is CSS voor bedoel)d. Het is een vormloos document om informatie in op te slaan.
    Dat vele websites de structuur missen die nog is om het op een andere te kunnen weergeven.Zoals een inhoudsopgaven op basis van de headers, is omdat de maker het zelf verkeerd gedaan.
    Daarom word ik altijd kost en kost misselijk als ik zie wat voor een troep Joomla uit loopt te schijten. Het is niet moeilijk om het goed te zoen.
    Headers zijn bedoeld voor de inhoud, maar worden te vaak misbruikt om een navigatie aandacht te geven. Dat hoord niet, en daar zijn gewoon niet voor bedoeld.
    Het mooie van HTML is, is dat het een open vorm is.Je kan het gewoon met een text-editor openen en je kan het zien, je hebt geen binary viewer nodig of iets om het te bekijken.
     
    Het punt is: Als je de HTML goed en juist is samengesteld, heeft het zelfs zonder enige vorm van eigen CSS nog een leesbare betekenis.
    Kijk is maar is http://www.webrichtlijnen.nl en dan kan je zien als je voldoende de moeite neemt dat het wel kan.
    Want zelfs zonder HTML krijg je geen vorm, als mensen niet de moeite nemen om het een betekenis te geven… :)

  9. Zo, oke :) sorry voor de spelfouten..,

Plaats een reactie

Je e-mailadres wordt niet gepubliceerd. Verplichte velden zijn met een * aangegeven.

Verschijnt je reactie niet, dan is deze mogelijk in de spam terechtgekomen. Mail ons dan even!