Why is it so massive? Why does it need to specify in grave detail the difference between <span>, <label>, <code>, etc.? How about a spec like this:
- There are two types of elements: block and inline. You can declare a name of an element with a particular type using perhaps XML namespaces, or just a JSON object.
- Inline elements can be floated left/right along other inline elements.
- Block elements may be positioned absolutely inside their parent elements or relatively to their current position. You cannot float them.
- Width/height may be specified as a pixel width, percentage width of parent, percentage of available space, or percentage of screen size. Additionally, you may specify the box model: whether to include borders, margins, padding, etc.
- CSS rules about typography, margins, borders, padding, etc. shall apply. This way, you can include your own basic rules and build on top of them.
I had the misfortune to do a bit of hacking with GTK+ and at first thought "what an archaic way to lay out elements?!" Then it came to me that HTML + CSS is not advanced, it is cluttered. There are many ways to position an element on the page, and they will conflict. Additionally, things like opacity affecting z-index, having a parent element have a size to give the child element a percentage size, etc. lead to a ton of hacks. It's time we have a better, cleaner tool than the browser if we are going to build serious apps on this platform.
Yet cannot do simple things like tell a block element to take up all available height.
The spec focuses on various types of data that could be represented. For example we have a <code> tag. This is done in an attempt to be semantic. However, it fails at being comprehensive, and ends up falling back on things like <code class="python"> instead of <python>. The distinction between <code>, <var>, <span>, <label>, and other inline elements is completely arbitrary and which elements get to be first class citizens is also arbitrary. Giving up and saying that there are only <inline> and <block> elements would simplify things a whole lot. If you can then "subclass" a <block> to create a <p> element or subclass an <inline> element to make a <lable>, go for it!
You have basically described XSL FO. In retrospect that's obviously what we should have used for web page layout instead of HTML, but now it's too late.
http://www.w3.org/TR/xsl/
> Unlike the case of HTML, element names in XML have no intrinsic presentation semantics. Absent a stylesheet, a processor could not possibly know how to render the content of an XML document other than as an undifferentiated string of characters. XSL provides a comprehensive model and a vocabulary for writing such stylesheets using XML syntax.
So the big issue with XSL is that it's verbose as hell. I remember using XSL Transforms to do some really simple things, and getting it right was horrible. Debugging it was worse. Given a piece of code that uses HTML + CSS vs XSL, I'd pick HTML + CSS any day simply because it's more readable.
However, yes the core of it seems much better thought out than CSS.
> but now it's too late.
Is it? Is it possible to have some XSL FO to HTML5 + CSS compiler?
Not "a cleaner tool than the browser" a cleaner layout spec. Plus you will have to build a CSS compatibility layer on top. Hard but worthwhile. Sort of thing Adobe might work on.
> Not "a cleaner tool than the browser" a cleaner layout spec.
Yes, agreed. Though the next thing that we might want to tackle is the whole concept of a web page. Seems like storing application state in a URL is a terrible thing, yet it is so convenient for some use cases. This might mess with the idea of a "browser" more since you wouldn't be "browsing" applications, you'd be running them.
> Plus you will have to build a CSS compatibility layer on top. Hard but worthwhile.
Yes, definitely. I can't imagine anything like this taking off without a compatibility layer. However, I think, the compatibility layer could be just HTML, this new CSS replacement, some JavaScript, and a server-side compiler.
Actually I wasn't entirely, they have a lot of experience on print rendering (PostScript, InDesign), and seem to have HTML interest now but are not really attached to CSS per se. Suspect however they are not...
- There are two types of elements: block and inline. You can declare a name of an element with a particular type using perhaps XML namespaces, or just a JSON object.
- Inline elements can be floated left/right along other inline elements.
- Block elements may be positioned absolutely inside their parent elements or relatively to their current position. You cannot float them.
- Width/height may be specified as a pixel width, percentage width of parent, percentage of available space, or percentage of screen size. Additionally, you may specify the box model: whether to include borders, margins, padding, etc.
- CSS rules about typography, margins, borders, padding, etc. shall apply. This way, you can include your own basic rules and build on top of them.
I had the misfortune to do a bit of hacking with GTK+ and at first thought "what an archaic way to lay out elements?!" Then it came to me that HTML + CSS is not advanced, it is cluttered. There are many ways to position an element on the page, and they will conflict. Additionally, things like opacity affecting z-index, having a parent element have a size to give the child element a percentage size, etc. lead to a ton of hacks. It's time we have a better, cleaner tool than the browser if we are going to build serious apps on this platform.