6 ms·

Either you have separation of data and presentation or you don't. HTML didn't. HTML5 still doesn't. It is not possible to present an arbitrary block of data in

by buff-a 15y ago

Either you have separation of data and presentation or you don't. HTML didn't. HTML5 still doesn't. It is not possible to present an arbitrary block of data in a normalized, optimal form, and have CSS render it any way you want. For that you need script (or XSLT!), but even then, unless you go canvas, you have to deal with a markup language for presentation that is actively trying to not be presentation but be data instead. Its trying and failing. Life would be so much easier (and involve much less cognitive dissonance) if the DOM stuck to being presentation. As it is, developing web apps is this giant joke, where you encrypt what you really want to happen in the form of pseudo-data (html) and magic rule-based transformation (css), and then the browser goes to a ton of effort to attempt to recreate what you really wanted. The effort the browser has to go through as soon as you introduce a div, or change its class, just to determine which, if any, of the CSS rules now apply to that node and any of its children, is just offensive. Worse: its something you, the programmer, must be able to model in your head to determine what the fuck is going on. Good luck with that! The result we get is "try it and see" "programming". HTML1.0 was a local optimum. Somewhere there is another, better optimum. The W3C appears to be willing to travel the Himalayas of suboptimal to find it.

fooandbarify 15y ago
While I certainly agree that there is tons of room for improvement with HTML/CSS/JS, I get confused when people start discussing it in such hyperbolic terms. It's not that bad. Most data on the internet fits really nicely into the document metaphor.
- knieveltech 15y ago
  Normally I immediately bridle when someone offers criticism without including proposals for improvement[1] but in this case it really is that bad. It really, really is. And while I would be willing to agree provisionally that most data (by volume of unique URLS) on the web does fit the document metaphor, if page views is your metric I'm not at all convinced. For example, is it logical to even attempt to reason about a Facebook wall containing recent updates from $n individuals in terms of authorship? Is this even relevant information given the entire contents of the page will have changed in 12 hours? The document metaphor made perfect sense 15 years ago but it breaks down quickly in the face anything dynamic, as is evidenced by the need for any credible web developer to have a minimum of 7 largely unrelated technologies[2] committed to memory to do their job effectively. Markup 15 layers deep? 2000+ lines of code to tell the browser how to render a website? Vendor-specific dynamic rendering engines to sidestep the limitations of native web languages? Surely this is not what success looks like? [1] Unfortunately I have no idea how to fix this mess. [2] HTML, CSS, JavaScript, a JS Framework (typically jQuery), at least one back-end language, SQL or similar and API stuff (SOAP, JSON, etc).
  - fooandbarify 15y ago
    Hmmm. I appreciate the way you laid out your argument, I'm not sure I understand it entirely though. I agree that the concept of authorship is not very logical in the context of your example, but I don't know of any HTML spec which requires defining an author for each document? I think my point was that it's pretty easy to mark up data in a semantic-enough way using the current tools. A wall post doesn't need to be a document of its own, it can be an item in a list of wall posts that make up part of a bigger page. I agree that "document" is sort of a silly metaphor for that use case, but that doesn't make HTML any less useful. We could use XML, but that would basically be the same thing. We could use JSON, but again... it's just another way of drawing the same relationships. I suspect that I've completely missed your point though, in which case I apologize and please be patient with me! With regard to the rest of your comment (7 unrelated technologies, deep layers of markup, huge numbers of LOC, etc) I agree, but as you said - how could it be fixed? The reality is that the web performs a complicated function. It would be nice to abstract the nuts and bolts behind it away cleanly, and I don't think it's unreasonable to believe that could happen in our lifetime, but it's also not unreasonable to expect that developing for a complicated platform will be complicated.
  - einhverfr 15y ago
    I think it is this unrelated technologies bit that is driving things like NoSQL. Interestingly, with LedgerSMB, you have to know: HTML, CSS, Javascript, Tempalte Toolkit, Perl, SQL (including PL/PGSQL), LaTeX That's only 7..... When we standardize on an AJAX API framework, I guess that will mean 8. However LaTeX is only required by some specialists (customizing printed check and PDF invoice templates), and a lot of the current approach is to hide the AJAX stuff inside TT widgets, meaning no more than 7 for most developers. And since the LaTeX stuff is a specialty (customizing higher-end printed templates and printed checks), that leaves only 6 for most developers. And since the SQL stuff can be easily handed off to others in the community (because the db API is defined through SQL, mostly through a procedural interface), it means 5. The perl is thin glue, and probably should hardly count (unless you are engineering the framework). A few master them all. Most work with the framework we provide. So here you have to know 4 well to do basic customizations, but 7 well to do the most advanced. Works pretty well, actually.
srl 15y ago
Amen. More disturbing still: because those people who are learning to program /now/ - in this decadent era of webapps and mobile devices - learn the brain damage that is modern web development early on. And it turns out (sorry, no evidence here but my own observations) that when you're first learning something, it's easy to mistake a brain-damaged system for an elegant one. And so, yes, there are people learning to program today, holding up CSS as an example of elegance. To be honest, I wouldn't complain about CSS so much - even if it lacked the much-seeked "separation of data and presentation" (isn't there a buzzword for that somewhere?) - if only accomplishing simple tasks didn't require obscure, unreliable hacks. As long as CSS was capable of formatting a reasonably-constructed document (titles before text, left-hand elements before right-hand elements) without hacks, I'd be happy. But it's not. And it doesn't look like it will be any time in the near future.
- rimantas 15y ago
  > As long as CSS was capable of formatting a > reasonably-constructed document (titles before text, > left-hand elements before right-hand elements) without > hacks, I'd be happy. What hacks do you need to do that?
  - joelanman 15y ago
    Not sure what is meant by titles before text, but it's impossible with css to reliably change the order of elements on the screen. You can try to float them differently, but this introduces side-effects, and won't work well with more than two elements.
    - talmand 15y ago
      Of course it's impossible, because CSS was never intended to do that in the first place. Seems to me that too many people are trying to use HTML/CSS in ways it was never meant to be and then complaining about the fact it doesn't work as expected. I'm totally shocked that my car won't drive up the side of my office building. If you are wanting to move stuff around in an HTML document with CSS you'll have to go with absolutely positioning every element within a container. Even then you'll need javascript to change classes and/or styles of the elements to accomplish that.
alex_c 15y ago
>Either you have separation of data and presentation or you don't. HTML didn't. HTML5 still doesn't. Is it really so desirable? I understand the appeal in theory, but in practice is it really worth it in most cases? Or perhaps I'm so scarred by HTML and CSS that I can't even visualize a web with true separation of data and presentation that actually makes life better. Edit: some of the other comments discuss this. Of course I see the advantage of abstraction and reusability. What I'm really asking about is the advantage, or even feasibility, of a pure, or strict, separation of data and presentation.
jeromeparadis 15y ago
Totally agree. In my opinion, the problem of separation of data and presentation won't be solved by markup or CSS. If a Web page is to contain data and a service wants to act on this data, it has to scrape the Web page. Which is even harder with scripted pages. But scraping data isn't a solution. The semantic web may try to have web developers bring sense to data on a web page, but the problem remains. It's just a markup patch. It's doesn't define how to act on that data. Web Intents are just another patch to markup to bring verbs. Direct access to the data sources with well define methods to act on that data and interact with it (instead of using form) is what works today through APIs. What doesn't work is that there aren't a lot of open standards APIs. Most well used APIs are proprietary and Facebook's a good example. I believe standard bodies should put their brains and efforts on defining API standards. Some standards APIs some clunky, are in use in B2B in the back ends but there's not much of it on the consumer facing Web. We must move forward to push separation of presentation, data and verbs for the whole Web, one small step at a time. If most use cases on the Web used standard APIs, we would have true separation of content and presentation. We would even have the verbs to exchange/create understandable content. Then, you can use HTML/CSS to adapt a UI to any device with true separation. That's the way we build apps and sites today and with standard, it would pave the way to a more exciting future. So one day, if I want to have my own customized UI for that new holographic/gesture recognition device to shop with my preferred merchants, I just have to build an app and I'll be able to browse their merchandise, sort it like I want and finalize a transaction without even visiting their Web site.
- epochwolf 15y ago
  > I believe standard bodies should put their brains and efforts on defining API standards. Have you seen SOAP?
  - DuncanIdaho 15y ago
    He said put brains into it. Not in a sense: "Throw your brains in for zombies to have a party". But in a sense that one should try and think and find protocols which are elegant in a sense that it makes reasoning about and using them easy and simple. I agree that coming up with SOAP and XML-RPC took quite some brains and effort, too bad that some really good people had to be lobotomized for it.
einhverfr 15y ago
I think you are missing the fact that a good document really needs three things: 1) Data (RDF, NoSQL, RDBMS, etc) 2) Structural presentation (i.e. what HTML or LaTeX provides) and 3) Presentation to the user (i.e. what CSS or macro packages in LaTeX provide) To get from 1 to 2, you have to have some logic. You could do it with Javascript acting against RDF and HTML, I suppose. Or you could do it with XSLT. However there's no inherent guarantee that inherent data structure will in any way match your document structure and so these are really separate concerns. This is why HTML template systems are so important for web programming.
gambler 15y ago
"HTML1.0 was a local optimum. Somewhere there is another, better optimum. The W3C appears to be willing to travel the Himalayas of suboptimal to find it." I don't think they're even going in the general direction of better optimum. Here is what I think that optimum should include: - Better document model (vs no document model at all, which seems to be where it's all headed right now). - Separation of content, layout and styling. Yes, into three parts, rather than the two we have right now. - Partial caching and user-side includes that aren't a blob of ugly, shortsighted hacks. Something that's works with the document model, not against it. It's absolutely ridiculous that I have to write custom code to prevent the browser from re-downloading (and the server from re-generating) page headers so on. - Significant improvement of forms. New UI elements, support for pure-HTML put/delete requests, different format for sending data that has structure (vs only key-value pairs).
- einhverfr 15y ago
  Generally agreed, but would suggest a slightly different set of concerns separated. instead of separation of content, layout, and styling, I would suggest a separation of data, structure, and styling. Data + structure gives you content, structure plus styling gives you layout. So in this idea you might have RDF as data, an HTML template as structure, and CSS as styling. The browser would generate the HTML from the template and the RDF, and the CSS would then be used to lay it out and style it.
halo 15y ago
HTML is a structured document format, with CSS for styling and presentation. The web became so popular that developers want HTML to be an unstructured data format with a separate fully-fledged layout language.[1] Neither idea is wrong, there's just an impedance mismatch between the two. There are three options: 1. The status quo. Developers mangle technologies designed for something different so it does what they want, with an increasing use of libraries and abstractions. It's inefficient and messy, but it works and is backwards compatible. 2. Give up on the idea of structured data and try to mangle HTML/CSS to be closer to what developers want. You end up with a crap structured document language and a crap web application language, but the web application language will be slightly less crap than the status quo. 3. Create a new language actually designed for web applications with a proper layout engine and HIGs to go with it. Despite being the most sensible option, this isn't realistically going to happen. A lack of backwards compatibility kills adoption and browser makers will never agree. It took them a decade to agree on a font format. None of the options are ideal. I suspect somewhere between 1 and 2 will happen in reality. [1] Layout is also a really hard problem. I don't think it's been acceptably solved in the general case.
deleted 15y ago
[deleted]

by buff-a 15y ago

fooandbarify 15y ago

While I certainly agree that there is tons of room for improvement with HTML/CSS/JS, I get confused when people start discussing it in such hyperbolic terms. It's not that bad. Most data on the internet fits really nicely into the document metaphor.

knieveltech 15y ago
Normally I immediately bridle when someone offers criticism without including proposals for improvement[1] but in this case it really is that bad. It really, really is. And while I would be willing to agree provisionally that most data (by volume of unique URLS) on the web does fit the document metaphor, if page views is your metric I'm not at all convinced. For example, is it logical to even attempt to reason about a Facebook wall containing recent updates from $n individuals in terms of authorship? Is this even relevant information given the entire contents of the page will have changed in 12 hours? The document metaphor made perfect sense 15 years ago but it breaks down quickly in the face anything dynamic, as is evidenced by the need for any credible web developer to have a minimum of 7 largely unrelated technologies[2] committed to memory to do their job effectively. Markup 15 layers deep? 2000+ lines of code to tell the browser how to render a website? Vendor-specific dynamic rendering engines to sidestep the limitations of native web languages? Surely this is not what success looks like? [1] Unfortunately I have no idea how to fix this mess. [2] HTML, CSS, JavaScript, a JS Framework (typically jQuery), at least one back-end language, SQL or similar and API stuff (SOAP, JSON, etc).
- fooandbarify 15y ago
  Hmmm. I appreciate the way you laid out your argument, I'm not sure I understand it entirely though. I agree that the concept of authorship is not very logical in the context of your example, but I don't know of any HTML spec which requires defining an author for each document? I think my point was that it's pretty easy to mark up data in a semantic-enough way using the current tools. A wall post doesn't need to be a document of its own, it can be an item in a list of wall posts that make up part of a bigger page. I agree that "document" is sort of a silly metaphor for that use case, but that doesn't make HTML any less useful. We could use XML, but that would basically be the same thing. We could use JSON, but again... it's just another way of drawing the same relationships. I suspect that I've completely missed your point though, in which case I apologize and please be patient with me! With regard to the rest of your comment (7 unrelated technologies, deep layers of markup, huge numbers of LOC, etc) I agree, but as you said - how could it be fixed? The reality is that the web performs a complicated function. It would be nice to abstract the nuts and bolts behind it away cleanly, and I don't think it's unreasonable to believe that could happen in our lifetime, but it's also not unreasonable to expect that developing for a complicated platform will be complicated.
- einhverfr 15y ago
  I think it is this unrelated technologies bit that is driving things like NoSQL. Interestingly, with LedgerSMB, you have to know: HTML, CSS, Javascript, Tempalte Toolkit, Perl, SQL (including PL/PGSQL), LaTeX That's only 7..... When we standardize on an AJAX API framework, I guess that will mean 8. However LaTeX is only required by some specialists (customizing printed check and PDF invoice templates), and a lot of the current approach is to hide the AJAX stuff inside TT widgets, meaning no more than 7 for most developers. And since the LaTeX stuff is a specialty (customizing higher-end printed templates and printed checks), that leaves only 6 for most developers. And since the SQL stuff can be easily handed off to others in the community (because the db API is defined through SQL, mostly through a procedural interface), it means 5. The perl is thin glue, and probably should hardly count (unless you are engineering the framework). A few master them all. Most work with the framework we provide. So here you have to know 4 well to do basic customizations, but 7 well to do the most advanced. Works pretty well, actually.

srl 15y ago

Amen. More disturbing still: because those people who are learning to program /now/ - in this decadent era of webapps and mobile devices - learn the brain damage that is modern web development early on. And it turns out (sorry, no evidence here but my own observations) that when you're first learning something, it's easy to mistake a brain-damaged system for an elegant one. And so, yes, there are people learning to program today, holding up CSS as an example of elegance. To be honest, I wouldn't complain about CSS so much - even if it lacked the much-seeked "separation of data and presentation" (isn't there a buzzword for that somewhere?) - if only accomplishing simple tasks didn't require obscure, unreliable hacks. As long as CSS was capable of formatting a reasonably-constructed document (titles before text, left-hand elements before right-hand elements) without hacks, I'd be happy. But it's not. And it doesn't look like it will be any time in the near future.

rimantas 15y ago
> As long as CSS was capable of formatting a > reasonably-constructed document (titles before text, > left-hand elements before right-hand elements) without > hacks, I'd be happy. What hacks do you need to do that?
- joelanman 15y ago
  Not sure what is meant by titles before text, but it's impossible with css to reliably change the order of elements on the screen. You can try to float them differently, but this introduces side-effects, and won't work well with more than two elements.
  - talmand 15y ago
    Of course it's impossible, because CSS was never intended to do that in the first place. Seems to me that too many people are trying to use HTML/CSS in ways it was never meant to be and then complaining about the fact it doesn't work as expected. I'm totally shocked that my car won't drive up the side of my office building. If you are wanting to move stuff around in an HTML document with CSS you'll have to go with absolutely positioning every element within a container. Even then you'll need javascript to change classes and/or styles of the elements to accomplish that.

alex_c 15y ago

>Either you have separation of data and presentation or you don't. HTML didn't. HTML5 still doesn't. Is it really so desirable? I understand the appeal in theory, but in practice is it really worth it in most cases? Or perhaps I'm so scarred by HTML and CSS that I can't even visualize a web with true separation of data and presentation that actually makes life better. Edit: some of the other comments discuss this. Of course I see the advantage of abstraction and reusability. What I'm really asking about is the advantage, or even feasibility, of a pure, or strict, separation of data and presentation.

jeromeparadis 15y ago

Totally agree. In my opinion, the problem of separation of data and presentation won't be solved by markup or CSS. If a Web page is to contain data and a service wants to act on this data, it has to scrape the Web page. Which is even harder with scripted pages. But scraping data isn't a solution. The semantic web may try to have web developers bring sense to data on a web page, but the problem remains. It's just a markup patch. It's doesn't define how to act on that data. Web Intents are just another patch to markup to bring verbs. Direct access to the data sources with well define methods to act on that data and interact with it (instead of using form) is what works today through APIs. What doesn't work is that there aren't a lot of open standards APIs. Most well used APIs are proprietary and Facebook's a good example. I believe standard bodies should put their brains and efforts on defining API standards. Some standards APIs some clunky, are in use in B2B in the back ends but there's not much of it on the consumer facing Web. We must move forward to push separation of presentation, data and verbs for the whole Web, one small step at a time. If most use cases on the Web used standard APIs, we would have true separation of content and presentation. We would even have the verbs to exchange/create understandable content. Then, you can use HTML/CSS to adapt a UI to any device with true separation. That's the way we build apps and sites today and with standard, it would pave the way to a more exciting future. So one day, if I want to have my own customized UI for that new holographic/gesture recognition device to shop with my preferred merchants, I just have to build an app and I'll be able to browse their merchandise, sort it like I want and finalize a transaction without even visiting their Web site.

epochwolf 15y ago
> I believe standard bodies should put their brains and efforts on defining API standards. Have you seen SOAP?
- DuncanIdaho 15y ago
  He said put brains into it. Not in a sense: "Throw your brains in for zombies to have a party". But in a sense that one should try and think and find protocols which are elegant in a sense that it makes reasoning about and using them easy and simple. I agree that coming up with SOAP and XML-RPC took quite some brains and effort, too bad that some really good people had to be lobotomized for it.

einhverfr 15y ago

I think you are missing the fact that a good document really needs three things: 1) Data (RDF, NoSQL, RDBMS, etc) 2) Structural presentation (i.e. what HTML or LaTeX provides) and 3) Presentation to the user (i.e. what CSS or macro packages in LaTeX provide) To get from 1 to 2, you have to have some logic. You could do it with Javascript acting against RDF and HTML, I suppose. Or you could do it with XSLT. However there's no inherent guarantee that inherent data structure will in any way match your document structure and so these are really separate concerns. This is why HTML template systems are so important for web programming.

gambler 15y ago

"HTML1.0 was a local optimum. Somewhere there is another, better optimum. The W3C appears to be willing to travel the Himalayas of suboptimal to find it." I don't think they're even going in the general direction of better optimum. Here is what I think that optimum should include: - Better document model (vs no document model at all, which seems to be where it's all headed right now). - Separation of content, layout and styling. Yes, into three parts, rather than the two we have right now. - Partial caching and user-side includes that aren't a blob of ugly, shortsighted hacks. Something that's works with the document model, not against it. It's absolutely ridiculous that I have to write custom code to prevent the browser from re-downloading (and the server from re-generating) page headers so on. - Significant improvement of forms. New UI elements, support for pure-HTML put/delete requests, different format for sending data that has structure (vs only key-value pairs).

einhverfr 15y ago
Generally agreed, but would suggest a slightly different set of concerns separated. instead of separation of content, layout, and styling, I would suggest a separation of data, structure, and styling. Data + structure gives you content, structure plus styling gives you layout. So in this idea you might have RDF as data, an HTML template as structure, and CSS as styling. The browser would generate the HTML from the template and the RDF, and the CSS would then be used to lay it out and style it.

halo 15y ago

HTML is a structured document format, with CSS for styling and presentation. The web became so popular that developers want HTML to be an unstructured data format with a separate fully-fledged layout language.[1] Neither idea is wrong, there's just an impedance mismatch between the two. There are three options: 1. The status quo. Developers mangle technologies designed for something different so it does what they want, with an increasing use of libraries and abstractions. It's inefficient and messy, but it works and is backwards compatible. 2. Give up on the idea of structured data and try to mangle HTML/CSS to be closer to what developers want. You end up with a crap structured document language and a crap web application language, but the web application language will be slightly less crap than the status quo. 3. Create a new language actually designed for web applications with a proper layout engine and HIGs to go with it. Despite being the most sensible option, this isn't realistically going to happen. A lack of backwards compatibility kills adoption and browser makers will never agree. It took them a decade to agree on a font format. None of the options are ideal. I suspect somewhere between 1 and 2 will happen in reality. [1] Layout is also a really hard problem. I don't think it's been acceptably solved in the general case.

deleted 15y ago

[deleted]