[jacquesm]

CSS happened in 1996, the first couple of years of the web we had no CSS, all styling was done with inline attributes up to that point.

The frustrating bit is that CSS was supposed to separate content/structure and markup, but now we have pages without content but with markup where the content is loaded after the fact. This really overshot the mark.

[TeMPOraL]

Also note tat the separation of content and structure is mostly nonexistent as it's currently practiced. People like to talk about it as a Golden Rule, a holy virtue, and then proceed to write even worse code than they did with tables. Generally, if you find yourself writing a tangled mess of divs in order to support CSS tricks, you're not really separating content from the structure. HTML5 semantic tags helped a little, but I still rarely see them used live.

(I'm not really convinced that separation of form and content is a feasible goal anyway - some elements of form are also content at the same time - but it's still a good goal to have.)

> now we have pages without content but with markup where the content is loaded after the fact

This is absolutely ridiculous and it, combined with the idea of routing everything through the cloud in IoT / home automation applications, makes me wonder what happened to some good old-fashioned engineering sanity. It's like people are trying to create wasteful and insecure systems on purpose. ("And what would that purpose be," - the cynic in me asks - "maybe monetizing people's data?").

[spion]

Have you considered that there may be an actual reason why people write a tangled mess of divs. Could it be because the entire model is crappy and people don't know what to do to make it show things the way they (or their client) want(s)?

[talmand]

In my experience, as a front-end developer, the usual reason I need a mess of divs and spans is to support a design that's not a good idea for a web page to begin with.

[spion]

What is a web page, and why would a particular design not be a good idea for it?

If a web page is not a good idea, then what other technology should be used to achieve that design, as well as remain equally easy to distribute?

This mindset is precisely why native mobile applications continue to exist on the market, and why articles like this one fail to convince me. Nobody (except perhaps Facebook with React) tries to really fix the web to meet the demands its been given. Instead everyone insists that the demands should change to meet the original vision and limitations of the web.

Regarding the HTML/CSS interplay, flexbox gives me some new hope that reconciliation is possible (getting both semantic markup and powerful / precise styling).

[talmand]

It's easy to find designs that are bad ideas for web pages. The most obvious culprit is a design that's excellent for a magazine layout. Such designs typically don't take into account the document flow nor the idea that different people open their browsers to different resolutions and browser window sizes. Heck, some won't even take into account different browsers with different capabilities. I think I understand where you're going with the "what is a web page?" bit, but it doesn't necessarily apply. Especially since a web page can be whatever anyone wants within the limitations of a browser, but that doesn't mean a design works based on some person's idea of what they think a web page is. In most cases a design is limited by the browser, not necessarily by the code of the page.

I have no idea what you mean by your second sentence.

And then, are you referring to my mindset or some other mindset? Because I fail to see how you can know my mindset on the matter. If it's the other, I would agree. Except I would say that "fixing" something in terms of making it do something it wasn't intended in the first place may possibly create more problems than we are attempting to fix. I would suggest attempting new things to see if they work, which there are some doing just that. I would point out that flexbox is an example of this.

I'm excited with flexbox and have started pushing to make use of it more often, when warranted. It's hard to switch current code to it, but I think it's worth it. But, in the end, someone will eventually start complaining about its limitations and that it needs to be "fixed". Then we'll be back where we started, it's inevitable.

[spion]

My second sentence was the entire point. If a web page is not a good idea because it can't support certain designs, then what would you suggest instead (that also has the other properties of the web such as easy distribution and is ubiquitous)?

I was referring to the whole mindset of "the web was not meant to do that". Well, yeah, it wasn't. But its already doing that, so we have to do something to make it properly rise up to the challenge.

[TeMPOraL]

> This mindset is precisely why native mobile applications continue to exist on the market

And long live them because there is little about the mobile experience that's more infuriating than a web app that should have been made as native. The assumption of being always on-line is baked too deep into the web stack; I have yet to see a well-made web app that could not be made significantly better UX-wise by simply going native.

[spion]

The UX problem isn't a matter of being online, but of not having a proper mechanism to express application UIs and styles (rather than document UIs and styles).

There are many PhoneGap applications there, and they don't make any "onlineness" assumptions. Their UI does however still suck and does not behave as expected.