I've been thinking about adding a mobile version to Scribophile lately but reading about the craziness of media queries and browser support is kind of scaring me away.
I think the core of the problem is that CSS was designed to style documents (because the web long ago was more or less a collection of text documents), but as the web evolved, it became necessary to use CSS for styling UIs--an entirely different beast from documents.
This twisting has led to the state we're in now, where CSS creates the problem it tried to solve: updating a style on a medium-complexity web site requires digging through a minefield of complex and interconnected CSS. Yes things like SASS or LESS can help but they're not an ultimate solution, nor are they a web standard, so tying your horse to one of those carts can limit you in the future.
Maybe in CSS5 they can add proper object-oriented syntax and element queries to help increase modularity and reuse and decrease cascading and media query complexity.
A "document" is one of the many possible "ui"s for the underlying model of information that gets displayed. I must be missing some nuance in the distinction you're trying to draw between a "document" vs a "ui." Are you talking about static vs. dynamic content?
CSS was made to style and place text on a page, not position buttons or define interactions or transitions or platform delineation or any of the other crazy things a view controller does in a compiled language.
Its an add-on to a markup language also built mostly only to display text.
A more constructive angle to this debate would be to compare HTML/CSS to other declarative UI frameworks such as those in QT and iOS and discuss what features need to be added or removed to make HTML/CSS more maintainable and less painful.
We all know the history of HTML and we're aware of the path it's evolution has taken.
Are you arguing that it's inherently unfixable and needs to be scrapped? I think you'd have a tough time arguing that point so why not move the debate forward instead of playing the curmudgeon?
Even then, if you plan things correctly and involve javascript for changes on the fly, it works quite well at positioning elements on the page, show results of interaction, performing transitions, and many of the other crazy things a view controller does.
It largely refers to the complexity of the layout. HTML and CSS were made for styling pages of text with headings, images, perhaps a table here or there. But now people want to make application UIs with fluid layouts with them.
Also, transclusion never really took off, so traditional web pages are different to an app's page state, which might be initialized from computation by composed modules on the backend and a series of asynchronous updates in frontend.
CSS has the cascade and @import and background-image links for example, but historically the document was typically one text file and some pictures; an app's UI is combined from many source files and subordinate resources. CSS works pretty well for declaratively styling a monolithic document, but it is not entirely satisfactory for styling the UI of complex app such as Facebook.
I think the core of the problem is that CSS was designed to style documents (because the web long ago was more or less a collection of text documents), but as the web evolved, it became necessary to use CSS for styling UIs--an entirely different beast from documents.
This twisting has led to the state we're in now, where CSS creates the problem it tried to solve: updating a style on a medium-complexity web site requires digging through a minefield of complex and interconnected CSS. Yes things like SASS or LESS can help but they're not an ultimate solution, nor are they a web standard, so tying your horse to one of those carts can limit you in the future.
Maybe in CSS5 they can add proper object-oriented syntax and element queries to help increase modularity and reuse and decrease cascading and media query complexity.