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