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.

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.

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.

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…

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.

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

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

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.