This is a failing of CSS, specifically. CSS has extremely limited tools for building a page layout.
See http://www.w3.org/TR/css3-flexbox/ and http://dev.w3.org/csswg/css3-grid-align/
See http://www.w3.org/TR/css3-flexbox/ and http://dev.w3.org/csswg/css3-grid-align/
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".
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.
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.
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.
- 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.