Linked by snydeq on Tue 16th Aug 2011 16:46 UTC
Permalink for comment 485651
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/20/13 11:29 UTC
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
Linked by Thom Holwerda on 04/18/13 11:21 UTC
Linked by Thom Holwerda on 04/16/13 9:29 UTC
More Features »
Sponsored Links



Member since:
2005-11-16
Hi,
It was internal, and not something web developers had to care about, and therefore very different to CSS from a web developers perspective (despite being very similar from a web browser's perspective).
I'm not sure which successful markup systems you're referring to. I hope it's not LaTeX (if you've ever tried to use LaTeX to get both HTML and PDF output that looks slightly similar you'll understand why I'd suggest using something else instead).
The web site's main page has changed since I wrote those numbers (3 new articles added, not sure how many removed), and (at the moment) I get 18.7 KiB for content. The CSS has also changed a lot - it was 215 lines (23.3 KiB) and now it's only 77 lines (8.4 KiB). I'm wondering if the OSNews staff have done a few things to reduce the bandwidth.
I don't think it's fair to ignore any of the javascript. I'd argue that HTML has made it difficult for web developers to control presentation, and therefore they're forced to rely on (for e.g.) CSS and javascript and direct DOM manipulation to regain control of presentation, and because the final "HTML + CSS + JavaScript + DOM + whatever is used server-side" quickly becomes an over-complicated mess; web developers use libraries and toolkits to try to cope. All of the javascript used by this site is a symptom of the problem, and therefore shouldn't be ignored.
1. Have a 5KB stylesheet, loaded once and cached by the browser, that can control presentation of all pages on the site for the entirety of the users visit.
2. Create some kind of crazy markup that incorporates all the styling it does, and then include that markup in the content of every page of the site, bearing in mind that the user will have to download all that markup again for every page load.
Ok. Now try to convince me that option 2 is "efficient". Or maintainable. Or even sane...
Given the choice between "HTML + CSS + DOM + who knows what else" and "a markup language designed for presentation and no need for anything else", I'd choose option 2; because a single 20 KiB page that uses one or 2 languages is much better than a 200 KiB mess that uses many more different languages.
..and ignoring the vast efficiency savings that HTML could have had if modern HTML was designed for presentation.
So you're suggesting that CSS means things like WML don't have a reason to exist now?
The model I want is where raw content comes from where-ever (e.g. database), something like HTML is used to present that content to visual users, some sort of "Aural Markup Language" is used to present that content to aural users, something like WML is used to present that content to small devices, something else is used to present the content to search engines, etc. Basically, markup languages designed for specific purposes, rather than a horrid mess that tries to cope with everything imaginable at once.
I did learn the basics. I spent hours fighting with it trying to make it work (and mostly failing because it was far from intuitive). The only thing that learning the basics did was increase my desire to replace the entire "web" stack, from HTTP all the way up.
- Brendan