[vinceguidry]

It's not noise, it's presentation markup. That's what HTML/CSS is for. To manage the presentation of information. It's not that hard. Learn a little responsive CSS and have the div go away if the browser's width drops below, say, 600px.

Visual presentation is a hard problem, has been ever since the tele-type days. You're always going to need some "noise". I'm not saying you have to go full-hog with design bling, but you should at least learn enough about responsive CSS so that your site is usable across the three main types of screen it will be displayed on.

[bct]

You don't need responsive CSS, all you need is max-width.

The (technically) ideal place to solve this is in your browser's user stylesheets (then you can have the page look however you like!), but that's a bad solution right now for obvious reasons (how many people even know that they exist?).

[vinceguidry]

User stylesheets will always suck, because the pages you're depending on for your stylesheets to work is a concretion, not an abstraction. You're just going to have constant problems with the user CSS conflicting with the creator's styling.

The right way to do this would involve an evolution in the community where you could easily get the content you need in JSON format or similar. Then you can create your own presentation, or, more likely, subscribe to a site/service that collects user-created presenters.

[bct]

> easily get the content you need in JSON format or similar

When user stylesheets were conceived this is what HTML was.

[vinceguidry]

JSON is a data format. HTML is a markup language. You don't store data as HTML, because it's not intended to store data, only presentational markup.

[bct]

> You don't store data as HTML

You do if your data is a document.

And after CSS was introduced, HTML was definitely not supposed to be presentational.

[vinceguidry]

> You do if your data is a document.

A document mixes information with presentation. It's not data. Because it mixes information with presentation, you have to re-prepare it for each medium you intend to display it on.

HTML is a poor document format. If you store your document as HTML, then you also have to store the CSS along with it or it won't be a complete document. Unless you want to include the styling in the HTML file, a kludge which violates the Single Responsibility Principle.

There are plenty of document formats out there that don't have this issue, like PDF or RTF.

If you want your document to look more like data, then what you do is factor out all the atomic bits of information into values that you can then input into a database. Then write code to present it. Works well for structured documents like orders, invoices, or reports, less so for unstructured information like blog posts. For these, mixing presentation with information is unavoidable, just adding bold-face to a word means you'll need to store presentation information in your data. The "semantic web" is intended to address this.

> And after CSS was introduced, HTML was definitely not supposed to be presentational.

Presentation involves more than just style. CSS handles the style of web content, HTML handles the structure.

[maxerickson]

I would still argue that making the browser aware of the screen it is using (or perhaps, aware of the screen real estate it currently occupies and the text size preference of the user) is a better solution than adding a div to every serious web page.

Also, I'm pretty sure that (at least for simple pages) styling the body element will work just as well.

[vinceguidry]

Why would that be any better? The only thing the page displaying in any browser needs to be aware of is how big the viewing window is, and the DPI. With those two pieces of information, you can have anything that runs in a browser present a useful interface.

That way content can handle all the edge cases that different screens can throw at them. And different browsers can handle things like text sizes the way they want to.

You don't want to have to make individual websites cater to individual screens or browsers. There's just too many of both. The interface between them needs to be a loose coupling.

[maxerickson]

A better way to say what I was getting at is that a web browser that finds itself with a silly window size might better serve the user by only using a portion of it for the viewport.

This way a page with no extra width styling still gets presented to the user in a sensible fashion. It's probably a looser coupling than insisting that every page anticipate and handle the screens it might be viewed on.

[vinceguidry]

The browser shouldn't be dictating how the web works. It's the creator's job to manage the complexity of presentation, you can't just push that responsibility onto your tech stack. The domain and expected use cases for web apps is just too broad for any browser to be making decisions like this.