Frames were actually a good effort to solve the problem of web-site "chrome" (navigation bars, headers, etc), and were somewhat useful. But they proved to not be flexible enough for designers (rightly so), and thus we have the mess that we have now.
See http://www.w3.org/TR/css3-flexbox/ and http://dev.w3.org/csswg/css3-grid-align/
- the browsers can cache presentation instead of loading it every time
- presentation only has to be defined once, instead of every time it's used
- presentation can change based on factors like screen size
- accessibility features, like high-contrast themes, are not possible with tightly coupled presentation logic
if your presentation and content are so tightly coupled that it's easier to inline everything, you're doing it wrong.
For caching, why do I have to reload a whole page just to change the article part? The HTML 'it's a document' obsession and terrible DOM model that took so long to be updated.
Why don't I define a high level presentation document and then sub-documents? Network latency and the total bizarreness of CSS selector priority.
Screen size. Why can't you dock elements on a page like form based programming language for the last 10/15 years? HTML doesn't have the ability.
And as for accessibility? If accessibility is taking hints from markup about how to present the page, in reality the mark up is tightly coupled to presentation anyway. Accessibility is tightly coupling the markup to the presentation, what it really means is screen readers can format the content nicely without the need for a style sheet.
Have you ever worked on a project that used inline styles on almost ever paragraph or heading? If yes, you will instantly know much of a pain it is. If you've ever transferred said content to a totally different design you should be scarred by this experience.
Have you also tried adding a page to a website that uses a table-based layout (the prime example of presentational HTML)? When a modern design is fit onto one of these layouts, adding content becomes a really painful experience.
I can see first hand the benefits of good separation.
I have CSS selectors that go five to six levels deep because of tables contained in tables contained in tables with no classes or ids on any elements. Often times those tables in tables is totally unnecessary.
Div > span > table > tr > span > td > span > div
That's not the way to build a web page. My guess? They used Visual Studio for layout as if they were coding a desktop application.
Don't get me wrong, there is a lot to hate about HTML and CSS. But unless you're working on a 5-page website, separating those two is a blessing. Do you not remember the nightmare of FONT tags?
Yes, but that's simply a failure from having no ability to define abstractions.
Separating form/design/layout from content is one possible abstraction boundary, but it's just one arbitrary one, so it's kind of strange that they tried to bake it into the platform instead of making it easier to define whatever abstractions are meaningful for you.
Just explaining that what you consider a "strange" design choice is actually deliberate and carefully thought out, not defending it--for all I know, it might have been carefully reasoned out but the wrong conclusions reached--but the results stand for themselves: a platform that is now synonymous with "the Internet".
You can't think of any instance when you would want to access the content irrespective of the presentation?
Imagine if, instead of HTML and CSS, web pages were delivered as pre-rendered PNGs. Make a list of all the different things that would break. That's why presentation should be separated from content.
This is why SGML was big in the publishing industry before the web.
It's mostly achievable but there are clearly problem areas such as tables where sometimes the presentation is an integral part of the content.
Templating systems help with this a lot, but they don't completely get you around being able to add the class 'round' to everything you want to have rounded corners. That's really why you keep things separate, so you can minting a single point of change.
The problem was that doing so broke most of the web, or was not internalized by page creators. So we're stuck with the current situation (bad markup, crufty designs, etc.).
Imagine if the first HTML editors forced a schema check before save. I think we'd be in a much better place now if they did...
Web pages (unlike Android layout files) are complicated composites of multiple data sources that are generated on-the-fly, and are combined in complicated (but sometimes low-tech) ways like string manipulation. Under such circumstances, it is simply too hard to create perfect XML every time.
Oh fun, bad analogies time! How would you like it if your word processor refused to save a text document because it detected an incomplete sentence?
Now as it happens, C compilers have a syntax validator as part of them. Lots of HTML editors, past and present, have used HTML validators too...
That's actually fundamental design aspect of HTML which was partly responsible for it's popularity.
HTML itself has its warts, sure, but the fact that we end up constantly resorting to HTML and/or Javascript edits to do things that should be happening in CSS alone is, to me, a much worse problem.
Separation of presentation and content allows for information to be accessible by everyone, indexed/readable by machines, adaptable to different displays. It's also easier to maintain (content editors can't mess with layouts) and makes many performance improvements possible.
The HN site has no special reason to use tables, it's perfectly possible to render this layout using semantic, clean markup. CSS has come a long way since 1999.
I miss designing with tables... And I just don't do anymore because I was told not to, for maybe no good reasons.
Imagine a web page with a giant table, every other row of which contains another table, and where the entire page contains probably 20000 INPUT tags, half of which are potentially exposed to the user under one set of visibility rules or another.
Now if it wasn't a bulk payment interface for wiring money out to hundreds of clients, paying potentially up to 5000 invoices in a single run, it would be entirely insane. As it is, the insanity is mostly an issue of the fact we have to do a lot to handle the fact that we have to handle concurrency issues over application protocols like HTTP, which leads to fun stuff in the database.
[1] highly interactive web apps.
Sure, you can emulate this with "display: table;" but a) it's not backwards compatible and b) that's the same darn thing as just using a table!
display:table is not an emulation, it's exactly the same behavior as a table, exposed for use at will. You can use the flexbox model for the same effect: http://jsbin.com/ejeraq
Be very glad that you have good vision and Google engineers spend millions and decades on making some sense of tag soup.
I'll just say that 1) display:table-cell doesn't work in IE6/7 and 2) CSS's limitations make it annoying or impossible to achieve functionality that was easy with table layouts (eg mixing percentage widths with fixed widths, and vertical aligment).
Nope. The <table> element was originally defined as an all-purpose chainsaw for two-dimensional relationships. The browser crackmonkeys locked us into that in the late '90s, and we have to deal with it forever. We are stuck with the legacy of billions of old documents, and thousands of old HTML parsers.
The W3C is pissing into the wind by trying to rewrite history. They cannot simply wish away technical lock-in by putting a "TABLE elements are semantic" clause in a standard. That needs to be repealed, and the we-must-ignore-history children must be given a spanking and sent to their rooms.
What the W3C should do is define a "tabulartext" attribute:
<!-- A table of data to read -->
<table tabulartext>
<tr><th>Title</th> <th>Title</th></tr>
<tr><td>Data</td> <td>Data</td></tr>
</table>
<!-- Structural markup -->
<table>
<tr>
<td>{{left_sidebar}}</td>
<td>{{content}}</td>
<td>{{right_sidebar}}</td>
</tr>
</table>
The HTML table model allows authors to arrange data -- text, preformatted text, images, links, forms, form fields, other tables, etc. -- into rows and columns of cells. - HTML 4.01 specification, 1999
Tables were added in the HTML3 spec:
HTML 3.2 includes a widely deployed subset of the specification given in RFC 1942 and can be used to markup tabular material or for layout purposes. Note that the latter role typically causes problems when rending to speech or to text only user agents. - HTML3.2, 1997
The "for layout purposes" was a big mistake, they even acknowledged that it wasn't adequate. Fixed 2 years later, or 10 years ago. There is no reason to markup things as tables when you can have a much clearer document outline using the proper header and grouping elements.
HTML5 parsers have no problem keeping up with old tag soup, but that doesn't mean we should keep writing crap. Implying that sites built using only tables are accessible and machine readable is just.. asinine.
Even this site, which uses tables for layout when "you're not supposed to used tables for layout", is a good example of why HTML is so bad for creating web pages. There's no reason I should have to jump through all the hoops I do to display two div blocks side by side in a horizontal box. All other XML based layouts I've used (Android and Flex) are a piece of cake compared to messing with HTML, CSS, and JavaScript.