Ah yes. The old "x is hard. Writing x sometimes gets messy. I don't want to deal with all the intricacies and details of x. I know, I'll create an abstraction layer!"
Of course, in the best of all possible worlds, you'll end up with a perfect abstraction layer which is powerful enough to allow you to do everything you need, while hiding all of the the gory details. In the worst case, you end up with a leaky abstraction. Suddenly you need to know not only the underlying language, but also how the compiler works.
That's not to say that all abstraction layers are evil. C vs. machine code is an example of an abstraction that works well. You rarely need to dive down into the machine code and you can, to a large extent, be ignorant of how the compiler works and still be able to be a decent C programmer.
There's no doubt that developing for the web can be quite hairy and sometimes you wish you didn't have to deal with all of the compatibility issues etc. It's possible that the solution is something like Vaadin, which lets you develop web applications as if they were Java desktop applications. But I'm not convinced just yet.
I guess the real question is, what exactly is the problem with HTML? If the problem is that HTML isn't abstract enough, then yes, an abstraction layer would be the answer. But if the problem is something else then slapping an extra layer of complexity on top of HTML won't magically solve those problems.
I guess the real question is, what exactly is the problem with HTML?
HTML is ok, it's CSS that's got the problem. It's the difference between Microsoft Word and Publisher; CSS doesn't provide enough layout primitives to do common web layouts easily. Instead, you have to specifically structure your HTML for it and layer on the <div> tags and copious amounts of CSS code.
The problem is that, unlike Word vs. Publisher, we don't have a set medium that we're working toward (e.g. paper.) When CSS was created, it controlled and formatted all the things that browsers could present, which wasn't very darn much. Then we thought of more things for browsers to do, and had to make our CSS much more complicated to get the same effects.
To give an even older parallel, when HTML was created, it had formatting primitives that were just fine for the browsers that existed at the time. Then, as people wanted more from browsers, spacer gifs and other such aberrations were invented to allow us to achieve our complex ideals, until we invented CSS and things were simple again, for a time.
The point is, the web is an ever-changing medium. We create a language for easily expressing existing web designs, and then set our sights higher and bludgeon that design language into expressing new (and previously unachievable) designs—such as, say, multi-column text layout—until we create a new web design language and the process starts over. This isn't a problem with CSS; no matter what we create, it will never be enough. There's only so much you can do with ink on the boundaries of a page of paper; there'll never be a limit to new ways to lay out shapes and vectors in an infinitely scrollable, resizable, dynamic, animated and reactive space that can be variously interpreted by different clients.
That's not to say CSS isn't showing its age. It's just that this isn't shouldn't be considered a failing in the original design of CSS; rather, it should be seen as a sign of experience for web designers, that they now have newer, larger ideas that their smaller, brittler tools aren't up to expressing. Perhaps this is the best argument of all for separating content from presentation—if they're separate, we can replace CSS with something more robust (and then replace that with something even robust-er-er) without touching the content itself.
First, I agree wholeheartedly that the language we use is never powerful enough for us to express ourselves. I'd say that even goes for print... but whatever.
I spent a few hours reading old RFC's because of this whole thread.
It looks to me like rfc 1942 got popular, and the CSS folks never came to grips with that. CSS1 is pretty given the constraints of the day. I think about CSS in two terms (I don't think there's a standard for this, i just made them up) Formatting, setting fonts, colors and padding; and layout, i think old newspaper guys would call it paste up, where the big blocks go on the page.
They must have known, and i don't think they had a credible solution to layout problems. they weren't willing to make a full layout language, so tables won.
Here's a simple task you can't do in CSS2: Create a multi-line form where the labels are right-aligned to the fields, the fields all line up, and everything expands to fill the contents.
My bad, didn't check my facts, table-cell is in CSS2! Of course, in my defense, it doesn't matter which standard it's defined in if it isn't supported by IE. It isn't even supported in IE7 and we've just recently dropped support for IE6.
Designers have been trying to create grid-based layouts since the beginning of the graphical web. CSS was created after that, and its creators did not see fit to bestow on us the basic tools (flexible boxes) that could be used to create these layouts elegantly.
As a result HTML and CSS have always been coupled. Only by using both together, can engineers create the layouts designers want.
This most certainly is a failing of CSS. Sadly, it is also a failing of the web development community, who looked for progress from the one group of people who were completely incapable of delivering it.
CSS does support flexible grids (with power equivalent to HTML tables), it is just that IE has not supported it until IE8, which means it hasn't been used widely.
I fint it strange that people keep blaming the shortcomings of IE6+7 on the CSS standard.
CSS emulation of tables doesn't meet the requirement though.
The question was whether CSS supports the primitives required to do grid layouts without coupling the CSS to HTML, effectively requiring the two of them to be treated as object code.
If you're going to require that the markup contain divs that are ordered and nested just so, so that they can be styled to layout like a table, then you might as well just use a table. Either way you are coupling presentation to semantics.
CSS is obviously always coupled to HTML in the sense that CSS applies styling and layout to elements in HTML. If you don't have an element to delimit the chunk of content you want to style, you cant do it with CSS. The point is just that the markup HTML should be independent of any particular presentation.
You don't have to use divs, you can use semantic elements (P, whatever) if that is appropriate for the content.
You definitely might not just as well use a table. The trouble with tables for layout is that they have the wrong semantics, which means they makes the page less accessible.
I agree! But the main failing of the original design of CSS (which could resolve most of these arguments) is that they didn't include a way to do page layout in the way that tables work. Many years later, with CSS3, they've finally adding it. But it seems like an obvious layout deficiency given the previous use of tables for layout.
Page layout equivalent to tables was already included in CSS2 which was finalized more than a decade ago. It is just that browsers - specifically IE - were slow to support it.
CSS3 has some proposals for grid based layouts that is much more powerful that CSS2/tables.
Of course, in the best of all possible worlds, you'll end up with a perfect abstraction layer which is powerful enough to allow you to do everything you need, while hiding all of the the gory details. In the worst case, you end up with a leaky abstraction. Suddenly you need to know not only the underlying language, but also how the compiler works.
That's not to say that all abstraction layers are evil. C vs. machine code is an example of an abstraction that works well. You rarely need to dive down into the machine code and you can, to a large extent, be ignorant of how the compiler works and still be able to be a decent C programmer.
There's no doubt that developing for the web can be quite hairy and sometimes you wish you didn't have to deal with all of the compatibility issues etc. It's possible that the solution is something like Vaadin, which lets you develop web applications as if they were Java desktop applications. But I'm not convinced just yet.
I guess the real question is, what exactly is the problem with HTML? If the problem is that HTML isn't abstract enough, then yes, an abstraction layer would be the answer. But if the problem is something else then slapping an extra layer of complexity on top of HTML won't magically solve those problems.