Edito: CSS will have to fork HTML to prevent HTML from forking himself

There’s has been recent discussion about the separation between content and presentation. The well known paradigm is simple: HTML is for content, for semantic information, and CSS is for presentation and layout.




If my humble observation is to be trusted, this paradigm didn’t survive the recent shift towards web application. Web Applications user-interfaces are described using HTML and CSS. HTML is not only used to define content because, if you keep yourself honest, the real content is stored in a JSON file, but to define the way this information should be formatted. 




If you think about it, modern layout languages all use some kind of markup. XAML, XUL, QML: They all define tags that are not based on the semantic of the information they contain, but instead in the way they process their content in order to display them. XAML has a <StackPanel> element, XUL a <vbox> element, and QML has QBoxLayout.




Yet, at some point, HTML took the “semantic” direction. This is kinda strange to me, as HTML at the time was kinda considered as the output of a handmade XSL and some webservice-generated XML, in the ideal world that never materialized, which means that even at the roots of the modern web, HTML was considered presentational. Nowadays, every formatting-related tags have been marked obsolete, like <center>, <marquee> or <font>. Some people even argue we shouldn’t use <b> or <i>. “Please use CSS for formatting” is the message.




There’s a fallacy out there. Layout is all about boxes and box trees. Browsers have a layout’s box tree and that tree doesn’t match the HTML tree anymore. The truth is that CSS cannot define nested boxes. If CSS was to define nested boxes, it would most likely have to provide some markup. Sure, there are markup-less alternatives to define layouts, like grid templates, but they fall short very quickly when it comes to consistency and usability. Layouts are rarely defined using one level of nesting, and the only alternative to markup is pointers and references, whose consistency cannot be checked ahead of time. Markup is the only simple and safe way people are used to that can define consistent trees.




So, there’s a real question to ask here: if HTML is for “semantic content only”, how do we build our box tree where we pour the content in? (a) Do we use pure CSS, with new templating technologies? If so, do we even need HTML to build web applications, except for rich-text-formatting à la RTF of content and description area of our apps, or could CSS+JS suffice? or (b) do we split HTML into two branches, like MathML: Content HTML and Presentational HTML? If so, should we just acknowledge that the split already occurred and label it better, and quite possibly, let different working groups or criterions handle issues related to the different personalities of HTML?




The direction the web is taking now is clearly the second one. Except that, over time, HTML is becoming more and more disconnected from what people really do with it. People use DIVs, DIVs, DIVs and yet another DIV, and HTML tags are basically just there for the default styling and behavior they come from in browser stylesheets. At the same time people working on HTML in committees want to define more closely the semantic of HTML to make it a better document language, other people are adding completely behavioural extensions to HTML like <canvas> or <audio>. There’s clearly a disconnect here that will have to be addressed.




If, like Hakon, we want CSS to shine in this post-webpage application era, we will either have to fork HTML and define our own layout boxes markup language, data binding and content integration, or just accept that there are two HTML now and that each one merits its own set of recommendation.


My opinion on this is that the initial CSS Regions proposal was to define the document itself in HTML in an iframe, and pour the content of the document inside another HTML document called the presenter. Nowadays, it seems to me the paradigm shifted to “put the document inline and use web components and shadow DOM to apply the presenter to the document directly”. Web Components is clearly a formatting and behavior extension to HTML, and does not make any sense in a content-only document. If we want to have that discussion, we’d better have it right now…


These two examples are, I think, the best illustration we have a language (HTML) that now works at two different levels and fails to correctly acknowledge this, while some people in the CSS Working Group fail to acknowledge that markup is necessary to define box trees and keep arguing for flat layout and templating technologies in the hope they will keep people distant from HTML for layout purposes like if we still were in the early days where books was the thing everyone wanted to do on the web - while at the same time the CSS OM is clearly so much inferior to the DOM in general it becomes unrealistic to even think a majority of developers will want to work with it for large-scale applications.


I think it’s time to have a discussion on this. Shall we provide layout markup in CSS, or shall we acknowledge that HTML is now used for both presentation and content purposes, and those two use cases need two different approaches?


Congrats, you just found the end of this message!

François