[shadowmint]

Are you kidding?

HTML is a massive spec even before you step in and implement the HTML5 javascript APIs.

Then you also have to make sure that your rendering engine behaves in a sane way, supports all the obscure CSS rules from the spec and from webkit...

There's a reason Opera stopped playing this game; it's hard work.

[IgorPartola]

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.

[kyrias]

Because if the spec didn't, every engine would do things their own way and no website would work in more than one browser.

[IgorPartola]

We do need a spec, I'm not arguing against it. I am just tired of the fact that I can position elements via many conflicting methods:

- position: absolute/relative/fixed + top/left values

- float: left/right

- positive/negative margins

- float values of other elements

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!

[nradov]

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/

[IgorPartola]

From the spec:

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

[justincormack]

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.

[IgorPartola]

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

> Sort of thing Adobe might work on.

Are you being sarcastic?

[justincormack]

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

[saraid216]

Backwards compatibility, I think?

[ternaryoperator]

Not only do you have to implement the massive HTML spec, but you must implement incredibly forgiving error handling. Just about any crappy, illegal HTML must be processed without throwing an exception--and the browser has to render something from it.