[notatoad]

content and presentation should be separate so that:

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

[mattmanser]

If you step back you'll realize these are all failures of HTML and the latency of networks that we have to work around, not requirements.

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.

[jwdunne]

I also have a few questions to ask which supports separation of content and presentation:

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.

[talmand]

I can attest to this. As a client-side developer I can go into detail of how much pain is involved in changing the skin on a site when the original developers did not structure their HTML well, including inline styles all over the place. Plus in many cases it seemed the developers had no idea how HTML actually works creating pages that will never validate causing all kinds of weird side issues from browser to browser.

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.