3 ms·

The root of the problem has little to do with either technology: it's related to the desire to cart application chrome around with documents, using a technology

The root of the problem has little to do with either technology: it's related to the desire to cart application chrome around with documents, using a technology that was designed to render documents -- and documents only. At a fundamental level, what's missing is the ability to add a link rel=chrome tag in a document's header, such that you'd only sends a header with a title, that link rel=chrome tag, and its contents within the body. The header, footer, navigation items, etc. should all be defined outside of the document itself, as part of the chrome. Put another way, a level of abstraction is still missing in the web developer's toolkit. Over the years, we've been compensating by: 1. mixing chrome and content together in html documents 2. sending boat loads of chrome-related styles alongside Add to this that a great many web developers received little to no education in computer science, and it's no wonder that web development is such a mess.

unclebucknasty 12y ago
Said another way... >a level of abstraction is still missing in the web developer's toolkit. As CS people we kind of intuitively feel this, but I'm not sure we really are missing anything, because, basically, HTML is already at the presentation layer. Remember when the proposed solution was to use XSLT to transform XML into HTML? Terrible as that was, the motivation behind it was a nod to the fact that XML is data and HTML is presentation. So, I also wouldn't agree that mixing chrome and content together in HTML documents was a compensation as much as simply using HTML for its purpose. The content actually starts elsewhere (XML,database, etc.). It ends up in HTML for the very purpose of presentation. There are ways to separate out chrome and modularize it that can use pure HTML. That makes sense. But, I don't think we really need another tech, language, or abstraction. Now, we have added CSS to further abstract and LESS on top if that for still more abstraction. It can go on ad infinitum, but at some point, we are losing value with each additional abstraction.
unclebucknasty 12y ago
The chrome (nav, footer, etc.) that you mentioned is one part of the equation, but the other part is styling/layout of the content itself. That is, within a page that features chrome, there is still the need to layout other elements of the page. So, CSS fails miserably at the latter. And, ironically, the former (i.e. chrome) can largely be handled very cleanly via other means (e.g. a templating system that modularizes the chrome and content elements). In any event, what you're saying is true to a large extent. It is not ideal to cart around data with presentation, so it is tempting to impose some degree of additional separation by some technology. But, the challenge is that it doesn't tend to match the real world. That is, the idea that there are or should be these agnostic HTML documents lying around filled with, effectively, unstructured data is more myth than anything. The unstructured data is in the database or elsewhere. What you're generally doing is taking all of that raw content and presenting it. That's how it ends up in HTML. And, the truth is that HTML is really a presentation language more than a document/data language. If you want the latter, then you'd move up a level to "pure" XML. But, the same problem exists: now you really do have raw content akin to DB data, so how do you now impose a visual layout on that data? So, here, I would argue that the separation has largely occurred before you get to HTML, thus it is OK to use HTML's more intuitive layout capabilities to layout the document. Attempting to instead remove it from the HTML is simply adding an abstraction. And, honestly, we haven't decoupled anything. We've just moved it to an interdependent, less intuitive document that must now be carted around too. So, while CSS is onerous for layout, I think the motivation behind relocating layout responsibility must also be scrutinized. Even if a less onerous CSS replacement existed, the cost of separation must really be weighed against what is actually being gained.

unclebucknasty 12y ago

Said another way... >a level of abstraction is still missing in the web developer's toolkit. As CS people we kind of intuitively feel this, but I'm not sure we really are missing anything, because, basically, HTML is already at the presentation layer. Remember when the proposed solution was to use XSLT to transform XML into HTML? Terrible as that was, the motivation behind it was a nod to the fact that XML is data and HTML is presentation. So, I also wouldn't agree that mixing chrome and content together in HTML documents was a compensation as much as simply using HTML for its purpose. The content actually starts elsewhere (XML,database, etc.). It ends up in HTML for the very purpose of presentation. There are ways to separate out chrome and modularize it that can use pure HTML. That makes sense. But, I don't think we really need another tech, language, or abstraction. Now, we have added CSS to further abstract and LESS on top if that for still more abstraction. It can go on ad infinitum, but at some point, we are losing value with each additional abstraction.

unclebucknasty 12y ago

The chrome (nav, footer, etc.) that you mentioned is one part of the equation, but the other part is styling/layout of the content itself. That is, within a page that features chrome, there is still the need to layout other elements of the page. So, CSS fails miserably at the latter. And, ironically, the former (i.e. chrome) can largely be handled very cleanly via other means (e.g. a templating system that modularizes the chrome and content elements). In any event, what you're saying is true to a large extent. It is not ideal to cart around data with presentation, so it is tempting to impose some degree of additional separation by some technology. But, the challenge is that it doesn't tend to match the real world. That is, the idea that there are or should be these agnostic HTML documents lying around filled with, effectively, unstructured data is more myth than anything. The unstructured data is in the database or elsewhere. What you're generally doing is taking all of that raw content and presenting it. That's how it ends up in HTML. And, the truth is that HTML is really a presentation language more than a document/data language. If you want the latter, then you'd move up a level to "pure" XML. But, the same problem exists: now you really do have raw content akin to DB data, so how do you now impose a visual layout on that data? So, here, I would argue that the separation has largely occurred before you get to HTML, thus it is OK to use HTML's more intuitive layout capabilities to layout the document. Attempting to instead remove it from the HTML is simply adding an abstraction. And, honestly, we haven't decoupled anything. We've just moved it to an interdependent, less intuitive document that must now be carted around too. So, while CSS is onerous for layout, I think the motivation behind relocating layout responsibility must also be scrutinized. Even if a less onerous CSS replacement existed, the cost of separation must really be weighed against what is actually being gained.