I have a hypothesis about a different way to organize responsibilities within webpages. I think the split of "content" to HTML and "presentation" to CSS was a mistake. To me, those are both describing content. That is, the author's intent to emphasize a particular part of text, whether via <em> tags or CSS, is part of the content.
I think there was a missed opportunity to instead split page layout into its own technology. This would allow for complex layouts, up to and including constraint solving. The browser would calculate the layout, then load each of the content segments into the calculated layout. I imagine it something like ASP.NET master pages, where you can define a page structure with fixed placeholders that can be replaced with other content. Except, of course, this could only specify where on the screen a particular panel exists.
HTML and CSS could then live together in a single technology. I think you could even go a step farther and combine content, presentation, and scripting all into a single technology. Some operators within that technology would have the side-effect of manifesting things on the user's screen. Something based on s-expressions would probably work very well, with its ability to blend code and data into a single format.
I imagine I could probably do some kind of mock-up using iframes to at least demo the idea...
It was not a mistake. The theory being that HTML describes the structure, and CSS describes the presentation.
Do not forget, that there are other ways for the page to be rendered: e.g. in screen reader or for print.
We had "HTML and CSS living together" with FONT and BGCOLOR and friends. It was not nice. Sad to see people wanting to get it back. We are finally comming to realize that maybe rendering HTML on the server is not so bad after all, when will we realize, that maybe the idea of separating concerns was not so bad after all.
And most importantly, when we finally start to learn the technology before trying to "improve" it. It looks like HTML and CSS is somehow considered not worthy learning and understanding, something do be disgusted about. Hating CSS for me sound like the lame bragging "I do not read book" or as the as lame jokes about PHP.
You're grinding an axe that has little to do with what I said.
Your defined split of "structure" and "presentation" is orthogonal to my choice of "layout" and "content". Currently both HTML and CSS define layout and content. Layout being defined as the positioning and arrangement of panels within the viewport, and content being defined as the material displayed within those panels as the author intended. That emphasized part is important.
The issue with styling in HTML had nothing to do with the use of tags and everything to do with the fact that they could not be classed. So the chosen tags had to be duplicated in entirety for every instance, which was a maintenance nightmare. Later versions of CSS saw it become more powerful than the original HTML tags. (Aside: This makes it ironic that it seems to be becoming idiomatic to inline styles for HTML templating. Templating solves code duplication, so it no longer requires classing.)
But the HTML+CSS tools for layout are extremely primitive. There's lots of things to point at here. One simple one is that HTML often has superfluous structure that is required only for the CSS-defined layout to work. A more complex one is that it difficult for me to say I want the footer either at the bottom of the viewport or at the bottom of the content, whichever is lower.
I think there was a missed opportunity to instead split page layout into its own technology. This would allow for complex layouts, up to and including constraint solving. The browser would calculate the layout, then load each of the content segments into the calculated layout. I imagine it something like ASP.NET master pages, where you can define a page structure with fixed placeholders that can be replaced with other content. Except, of course, this could only specify where on the screen a particular panel exists.
HTML and CSS could then live together in a single technology. I think you could even go a step farther and combine content, presentation, and scripting all into a single technology. Some operators within that technology would have the side-effect of manifesting things on the user's screen. Something based on s-expressions would probably work very well, with its ability to blend code and data into a single format.
I imagine I could probably do some kind of mock-up using iframes to at least demo the idea...