6 ms·

The fundamental problems with CSS3

45 points by bdfh42 18y ago

cousin_it 18y ago
It seems CSS is eagerly following C++ templates into the Turing tarpit. For an alternative, I've heard good things about the TeX "boxes and glue" layout model.
- newt0311 18y ago
  It seems that anything that comes out of "standards bodies" ends up looking like C++. Standards in general need to become simpler.
  - smanek 18y ago
    Common Lisp came out of ANSI, and I'd say it doesn't look like C++ ;-)
    - pg 18y ago
      Scheme would be a better example.
    - newt0311 18y ago
      Yes it does. It has at least 4 different ways to loop, 4 different types of arguments to functions, 5 or 6 different lets (functions, macros, let* , normal let, ...), 3 or 4 different kinds of variables (with no unifying underlying theme), and at least 3 different flow models (the nested lists, tagbodies, loops with returns, etc...). That is exactly the same problem with C++. Instead of finding unifying abstractions which give the same functionality with 1 idea, they have chosen to add in multiple specific quick fixes to the language. They have chosen to amend the language with a thousand small changes, each suited to its own little use case, and have ended up with a monster of a standard that takes up 15 megabytes in 2300 files with 110,000 hyperlinks. Thats 15 mega bytes mostly of text. Scheme is a lot better but its going the way of CL, slowly but surely.
      - jshen 18y ago
        aren't the 4 different types of arguments useful? I end up hacking it into my ruby code because it's missing. Crap like def my_meth(options = {}); options[:named_arg_1] ||= 'bob'; options[:named_arg_2] ||= 'blub' end
        newt0311 18y ago
        To a limit. Admittedly, having different argument types is pretty useful but still, 5 independent parts with their own semantics some of which may not be usable in certain contexts* ? how are auxiliary arguments useful in the general case? This still does not affect the rest of my claims. Having multiple execution models in the same language is bloated. So are many other things in the CL standard. * Details: http://www.lispworks.com/documentation/HyperSpec/Body/03_da.htm http://www.lispworks.com/documentation/HyperSpec/Body/03_da....
        jshen 18y ago
        yeah, i wasn't trying to dispute your main claim, I just miss CLs argument types when I'm in other languages so it jumped out at me.
stillmotion 18y ago
My biggest horror with all this new W3C tech, is that in reality: it's really old. Because of Microsoft's stupid mistakes while reigning power over the browser world, we've been in this 10 year period of stagnation in which we've go nowhere. There's no real laws you can put against Microsoft, but if this were a real world situation, we'd be trying them for crimes against humanity. They have effectively ceased innovation for an incredible amount of time, and I would go ahead and say that they've slowed down the exceedingly fast development of the last decade. CSS3, Javascript 2, HTML 5, XHTML 2, etc. should've came out years ago. Possibly in different forms, but nonetheless this monopolization over a browser market has killed _everything_. I am glad that Google is getting into this game. Not only because it will definitely give Microsoft a run for its money, but we will finally have new innovation that before seemed to take years to implement.
- DLWormwood 18y ago
  > I would go ahead and say that they've slowed down the exceedingly fast development of the last decade. As a fellow developer, I'm about a commit a heresy down to text: "Most people don't want fast development." People may claim they want change or for things to be "done with" in a timely matter, but the reality is that change brings disruption in economic, social, and political terms. Take a look at IP4, for example. IP6 just isn't getting traction because the problems it solves have now become "features" to many people. (NAT being one of the big ones, since it's gotten the perception of being a security feature.) My job involves working with IE 6, since my organization refuses to update our systems to even use IE 7, much less standards-compliant stuff like Chrome or Firefox. Simply put, if MS was sent to trial for "crimes against humanity," the jury of "peers" who would to be selected would acquit them. Why? Because the court would likely consider "peers" to be end users, business men or the ignorant, not developers or technologists like us.
  - potatolicious 18y ago
    The removal of NAT, IMHO, is a major ache in the market. What used to be purely an annoyance to developers and technologists has now become a serious stumbling block for users. The internet is no longer the download-from-website model that it was years ago. There is a massive amount of user participation now, which is why upload caps are increasing as services like video chat, peer-to-peer gaming, etc take off. And now you tell them only one person can initiate a video chat from behind a single router. The user is annoyed. Or you tell them that you can't both be playing the same game at once on two computers due to a port conflict. IMHO there's a real need to get NAT out of our system, and there's a very real consumer benefit to doing so. It directly opens doors to services and products that people are already clamoring for.
johns 18y ago
OT: The author's use of underline for emphasis is annoying. It looks like a lot of links, but they're not. He should swap the styles of his links and whatever he uses to emphasize text.
- Herring 18y ago
  It would also be nice if we started writing abstracts for the lengthier & more technical posts.
etal 18y ago
There are a lot of "what ifs" in the history of web tech, and considering this article, JSSS (http://en.wikipedia.org/wiki/JavaScript_Style_Sheets http://en.wikipedia.org/wiki/JavaScript_Style_Sheets) versus CSS springs immediately to mind. Using Javascript for styling pages in 1996 may have sounded like needless complexity, but in retrospect it seems like it would have been a much better choice. Whole-page layout deserves a true programming language.
- ambition 18y ago
  Separation of presentation from content is good, but presentation is a task of arbitrary complexity and requires arbitrary computation (aka a full programming language) to do properly. Many current frameworks are inadvertently used to bring the power of a programming language to presentation, but most of them don't seem to realize it yet.
lacker 18y ago
I think the fundamental problem is that the html/css/javascript/server stack needs to get simpler. For some apps, you are best off abandoning html entirely, and doing everything via javascript. Eventually we might be able to unify client-side and server-side code with approaches like Google Web Toolkit or YC's AppJet, but it is not quite simple enough yet.
- jonnytran 18y ago
  Yes, the ability to write code once that runs on either your server or the client is amazing, something Fog Creek implemented in Wasabi. But as JavaScript matures, it makes you start to wonder why you even bother with HTML at all; you can simply dynamically generate DOM nodes in JavaScript. And once you start doing this, most of the things you wanted to do running code on both client and server disappear.
  - jshen 18y ago
    "But as JavaScript matures, it makes you start to wonder why you even bother with HTML at all; you can simply dynamically generate DOM nodes in JavaScript." SEO
    - jerf 18y ago
      Oh! So that's why Google is developing a speedy JS interpreter... they want to be able to see JS-based pages! They can load a page into a browser-with-no-graphics, and give the JS a certain amount of time to run before freezing the page and then reading off the DOM nodes instead of reading HTML. If they don't like the results, they can just use the HTML like they used to. (Reading off the DOM nodes also gives them a fresh crack at some more semantic analysis that used to be really hard, since it involved emulating a browser... did you use <span class="some_header"> instead of <h1>? They can make a better heuristic guess at that if they are "inside" a browser and thus capable of seeing that the size is twenty points higher than the surrounding text, no matter how you implemented that.) To really pull this off, you need a browser engine that enough people are using that site designers need to account for it, and it needs to be designed with the goal of running just the engine as quickly as possible on the backend, with the ability to cut it off after a certain amount of time. So... has anybody dug deeply enough into Chrome to have an opinion on the feasibility of running the browser without a UI?
halo 18y ago
CSS does have its limitations, however I'm not convinced providing full DOM manipulation is a good idea. I admit it does solve the problem and provide greater flexibility, but the downside is that it'd be very quickly misused with content and presentation becoming more tightly coupled as people start using the convenient CSS DOM manipulation with dynamic pseudo-classes for interactivity and removing many of the accessibility advantages that CSS has. There's also very real unaddressed problems in terms of creating a readable syntax, maintaining CSS code with injections all over the place and potential browser rendering issues. To me, the cure seems worse than the disease, and the Advanced Layout Module, despite its ugliness, is probably a better solution. CSS3 has gone a long way towards improving selectors, and I'll be the first to admit calc is undoubtedly both necessary and long overdue. I'm not fussed either way by CSS variables - I can see both sides of the coin.
- neilk 18y ago
  Can accessibility really get any worse? Extremely few websites are accessible today. If it weren't helpful for SEO, nobody would bother with it at all. Can readability get any worse? Nobody really understands floats. This is a layout language in which people regularly boast about how they achieved three-column layouts. Think about that for a second. And if you look at the code that achieves said three-column layout, it is impossible to tell what it does without comments. That's because CSS is written out as a set of spring-loaded contraptions all interacting with each other, meaningless without the "cascade" of DOM elements just so, and a browser model just so. There's nothing like "three_column_layout(node, node, node)". As far as I can tell, your thesis is that because CSS is underpowered, this will help us maintain accessibility. That's totally backwards! There will always be requirements for complex layout and interaction. That part of the job is not going away. So something's got to give. The artistic people go to Flash, the scripting people just do it with tables, and the server-side programmers go for some toolkit that pretends the browser is Java. Very very few people have the sheer bloody-mindedness to do the right thing and learn every last browser quirk and the so-called CSS model. CSS is DEAD. It is not the basis for a better future.
  - halo 18y ago
    I'm going to break down the differences between my opinion and the original articles and hopefully your opinion. I admit CSS has its problems, and the core one is this: it's too complex to create good designs, and it's too easy to hit a brick wall. We can all agree on this. The most fundamental things about CSS aren't a problem. The cascade is sane, and is probably the best thing about CSS. It makes sense, it's fairly intuitive and can be describe in a couple of sentences. For styling, aside from the ugly non-JavaScript compatible syntax and the occasional unintuitive property-name choice, we're in pretty good state generally. The two biggest, and very real, problems are the unintuitive box model and layout model. Everyone should agree with this. I'll first deal with the relatively simply box model problem. The W3C box model was incredibly poorly thought out and makes like incredibly and unnecessarily difficult. It's simply inside-out. The width should refer to the total width of the box as in IE4 and quirks mode: this makes things wonderfully intuitive, makes things look as you expect and allows you to mix different units with ease. As it is, it width refers to the inside of the box and the real width is the inside width + border + padding. This is quite obviously nuts. There are two fixes to this problem: a nastier backwards-compatible one, and an actual nice solution. Both are in CSS3, and it gets full marks from me here. The first fix is to provide a way of calculating values so you can easily mix percentages with pixels. This is in CSS3 as the calc function. The second fix is switching to the traditional sane box model. In CSS3 there is a property to do this - add "box-sizing: border-box". So far, CSS3 gets full marks from me. The second core problem is layout. We currently have the "float model". I put them in quotes because it's not so much a model as people meeting the limitations of CSS2 but wanting many of the advantages of it and finding a way around them using floats. Presumably when CSS2 because a recommendation in 1998 the web looked like a very different place, the limitations of the model weren't considered a big problem, and then we were left in standards limbo which left us for several years without a decent CSS2 implementation and no table-replacing display: table implementation in the major browsers in sight. And up until now the only usable, accessible CSS model we had was arguably designed for something else entirely - the task of allowing text to flow around images on normal layout pages. To say this dirty hack is lacking is obvious an understatement, and that's excluding working around CSS bugs, but I'd still argue it's the best thing we have and the accessibility advantages and content seperation are worth the dirty hacks. And so we have where we are today and our problem - how do we provide a good, natural, way to make layouts? And any answer to this leads us to the fundamental subquestion and finally to where we started this discussion: how seperate do we want our content and presentation to be? This is actually a difficult, and slightly, ideological question. The more you seperate content and presentation, complexity of both the spec and language goes up, flexibility goes up, inherent accessibility goes down and so does inherent maintainability. The "completely" solution results in DOM injection, the "not completely" solution results in something nearer to the Advanced Layout Module. And this is where our fundmental differences clearly lie. I believe that forcing a reasonable amount of semantic ordering within content is a good idea as it helps encourage a certain amount of inherent accessibility as content has to be ordered. I believe that any syntax that would allow DOM injection would be inherently ugly syntax and not fit well within CSS. I believe that any syntax would have to be very carefully chosen to work at all. I believe that if you want ultimate control over the appearence of the page, you always have JavaScript and jQuery at your disposal. And you, and the article, believe that the advantages of flexibility outweighs my criticisms, and CSS would be underpowered without them. --- And to go back to your own post: Accessibility can get worse, and CSS3 is looking like it will improve the situation. Readability can get worse - floats are a dirty hack especially when combined with CSS hacks for dated browsers and as such inherently aren't readable, but adding injection into the mix won't automatically make life better. And yes, floats are a dirty hack and aren't an indicator of the future of CSS either way. CSS isn't really inherently underpowered: it depends how you see it. At the moment it needs fixing either way And CSS isn't dying at all, and CSS is going to be completely reborn over the coming years. Flash is still dying - Flash was always a dirty hack. CSS's display: table is going to replace with CSS as soon once IE7 dies in about 5 years. And CSS is getting better, compatability is improving and CSS3 is going to better than CSS2 whatever it chooses: DOM injection or not.
endergen 18y ago
The problem is that Microsoft inversely gains from improving the ease of browser development. The easier it becomes to develop software using open source tools(No Visual studios) on an OS-independent platform(The web with browsers) the less money they make. Google's recent project (Native Client) is what I've been waiting for as a C++ developer. It basically allows you to run native code(assembler) in browser. But then has security mechanism so that the code cannot do anything to the client computer unless the user of that client has given the container(Sandbox) that runs the code permission. This will allow people to build their own UI frameworks, that render much more rich graphics and hopefully behave the same no matter what Browser/OS combination you are running on. References: Announcement: http://google-code-updates.blogspot.com/2008/12/native-client-technology-for-running.html http://google-code-updates.blogspot.com/2008/12/native-clien... Native client code base hosted at Google code: http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/ Ars Technica review: http://arstechnica.com/news.ars/post/20081209-safer-than-activex-a-look-at-googles-native-client-plugin.html http://arstechnica.com/news.ars/post/20081209-safer-than-act... Do people really think we'll ever reach a point where different vendors building code-bases based on documentation built by a committee will ever behave even remotely the same? Have you read any of the W3C documentation, it's fucking ridiculous. We should be sharing implementations, it's the only way to ensure bit-level identical behavior of a target system(Performance characteristics aside). I really hope Native Client takes off. In combination with Gears for client side storage it would allow us to build desktop quality software but with the web advantages of cross platform development, zero install applications(well as long as you don't consider caching a form of installing), user's pulling down the latest client at all times, and etc. Awaiting our new Google overlords. Endergen
old-gregg 18y ago
If we're talking about fundamental problems, then the only fundamental problem is that we're using document markup tools to build rich UIs, which is super-retarded even comparing to early 90s VB6 era. WTF is <p> or <ul> or <div> and all that crap? I haven't seen an HTML template that looked comprehensible after a year in development. What do they have to do with UI programming? What we really need is something like MXML or XUL, only cleaned up and widely supported by all browsers, especially IE9.
- sjs382 18y ago
  <p> <div> <ul> don't have anything to do with UI.* They are document markup elements. UI is applied to a document (html) via CSS (style) and JS (behavior). This is all pretty elementary for someone reading this site... Maybe I missed some sarcasm? :p *Well, they do in a lot of instances, but when properly used, they have nothing to do with UI.
  - potatolicious 18y ago
    Well yes, in theory those are not UI - but how many times have you seen someone create two divs for the semantically same data just so the CSS styles will play nicely? The problem is that CSS is not powerful enough to do rich layouts, and that forces developers to cripple the semantic goal of CSS/HTML by injecting presentation into what is supposed to be a presentation-free markup.
  - fauigerzigerk 18y ago
    Yes that's the dogma. Alas, it's completely lost on me. I fail to understand how tables are more "semantic" than nested divs. Tables only have semantics within the context of some formalism that defines their semantic meaning. Outside of such a context they can be anything, so why not a way of laying out information on a page? I don't see how swaths of divs, some of them used for semantics (according to some metadata standard), some of them used for purely presentational purposes, improve anything. CSS people (or should I say modern web developers) are completely anal about not using tables for layout whilst at the same time the whole notion of document structure is so utterly destroyed in any JavaScript heavy app. These priorities make no sense to me. Laying out web pages with divs and CSS is a black art. It's fragile. It breaks in all kinds of nasty ways. It reduces the productivity of UI development to pre 90s levels and leads ot entire pages done in Flash.
thomasmallen 18y ago
"If you look at the specification there was only one property in CSS1 that could be used to effect layout - float. position didn’t even exist, and in HTML 2 neither did <div>, the two essential tools without which no modern design could be achieved (without resorting to tables)." Lost me there. A <div> is just a vanilla block-level element. You can turn anything into a <div>. "CSS can only be applied to elements that have semantic meaning" You should see the CSS that developers I've worked with write. Even worse is that DreamWeaver has its "style1", "style2" way of doing things which makes picking apart a stylesheet very tedious.
olavk 18y ago
He has a good point: CSS can only define the appearance of existing HTML elements. Sometimes you need visual elements which doesn't correspond to any semantic HTML element. I think SVG would be a good approach for designing these "unsemantic" visual elements, and you can use CSS with SVG. SVG would also be a good way to extend CSS beyound the built-in properties, eg. if I want to design a wawy border to apply to some elements. He also has a good point about the need for calculation in CSS. However I am really worried about the possible manitenance nightmare of a turing-complete CSS! It should be designed very carefully. A constraint-based sublanguage for CSS would perhaps make sense.
tptacek 18y ago
The fact that you can already accomplish what he wants with jQ, and that his proposed solution is to add imperative programming semantics to CSS, one assumes the reasonable response to this is simply a compiler that spits out CSS/JS based on whatever random feature he wants CSS to have.

45 points by bdfh42 18y ago

It seems CSS is eagerly following C++ templates into the Turing tarpit. For an alternative, I've heard good things about the TeX "boxes and glue" layout model.

newt0311 18y ago
It seems that anything that comes out of "standards bodies" ends up looking like C++. Standards in general need to become simpler.
- smanek 18y ago
  Common Lisp came out of ANSI, and I'd say it doesn't look like C++ ;-)
  - pg 18y ago
    Scheme would be a better example.
  - newt0311 18y ago
    Yes it does. It has at least 4 different ways to loop, 4 different types of arguments to functions, 5 or 6 different lets (functions, macros, let* , normal let, ...), 3 or 4 different kinds of variables (with no unifying underlying theme), and at least 3 different flow models (the nested lists, tagbodies, loops with returns, etc...). That is exactly the same problem with C++. Instead of finding unifying abstractions which give the same functionality with 1 idea, they have chosen to add in multiple specific quick fixes to the language. They have chosen to amend the language with a thousand small changes, each suited to its own little use case, and have ended up with a monster of a standard that takes up 15 megabytes in 2300 files with 110,000 hyperlinks. Thats 15 mega bytes mostly of text. Scheme is a lot better but its going the way of CL, slowly but surely.
    - jshen 18y ago
      aren't the 4 different types of arguments useful? I end up hacking it into my ruby code because it's missing. Crap like def my_meth(options = {}); options[:named_arg_1] ||= 'bob'; options[:named_arg_2] ||= 'blub' end
      - newt0311 18y ago
        To a limit. Admittedly, having different argument types is pretty useful but still, 5 independent parts with their own semantics some of which may not be usable in certain contexts* ? how are auxiliary arguments useful in the general case? This still does not affect the rest of my claims. Having multiple execution models in the same language is bloated. So are many other things in the CL standard. * Details: http://www.lispworks.com/documentation/HyperSpec/Body/03_da.htm http://www.lispworks.com/documentation/HyperSpec/Body/03_da....
        jshen 18y ago
        yeah, i wasn't trying to dispute your main claim, I just miss CLs argument types when I'm in other languages so it jumped out at me.

stillmotion 18y ago

My biggest horror with all this new W3C tech, is that in reality: it's really old. Because of Microsoft's stupid mistakes while reigning power over the browser world, we've been in this 10 year period of stagnation in which we've go nowhere. There's no real laws you can put against Microsoft, but if this were a real world situation, we'd be trying them for crimes against humanity. They have effectively ceased innovation for an incredible amount of time, and I would go ahead and say that they've slowed down the exceedingly fast development of the last decade. CSS3, Javascript 2, HTML 5, XHTML 2, etc. should've came out years ago. Possibly in different forms, but nonetheless this monopolization over a browser market has killed _everything_. I am glad that Google is getting into this game. Not only because it will definitely give Microsoft a run for its money, but we will finally have new innovation that before seemed to take years to implement.

DLWormwood 18y ago
> I would go ahead and say that they've slowed down the exceedingly fast development of the last decade. As a fellow developer, I'm about a commit a heresy down to text: "Most people don't want fast development." People may claim they want change or for things to be "done with" in a timely matter, but the reality is that change brings disruption in economic, social, and political terms. Take a look at IP4, for example. IP6 just isn't getting traction because the problems it solves have now become "features" to many people. (NAT being one of the big ones, since it's gotten the perception of being a security feature.) My job involves working with IE 6, since my organization refuses to update our systems to even use IE 7, much less standards-compliant stuff like Chrome or Firefox. Simply put, if MS was sent to trial for "crimes against humanity," the jury of "peers" who would to be selected would acquit them. Why? Because the court would likely consider "peers" to be end users, business men or the ignorant, not developers or technologists like us.
- potatolicious 18y ago
  The removal of NAT, IMHO, is a major ache in the market. What used to be purely an annoyance to developers and technologists has now become a serious stumbling block for users. The internet is no longer the download-from-website model that it was years ago. There is a massive amount of user participation now, which is why upload caps are increasing as services like video chat, peer-to-peer gaming, etc take off. And now you tell them only one person can initiate a video chat from behind a single router. The user is annoyed. Or you tell them that you can't both be playing the same game at once on two computers due to a port conflict. IMHO there's a real need to get NAT out of our system, and there's a very real consumer benefit to doing so. It directly opens doors to services and products that people are already clamoring for.

johns 18y ago

OT: The author's use of underline for emphasis is annoying. It looks like a lot of links, but they're not. He should swap the styles of his links and whatever he uses to emphasize text.

Herring 18y ago
It would also be nice if we started writing abstracts for the lengthier & more technical posts.

etal 18y ago

There are a lot of "what ifs" in the history of web tech, and considering this article, JSSS (http://en.wikipedia.org/wiki/JavaScript_Style_Sheets http://en.wikipedia.org/wiki/JavaScript_Style_Sheets) versus CSS springs immediately to mind. Using Javascript for styling pages in 1996 may have sounded like needless complexity, but in retrospect it seems like it would have been a much better choice. Whole-page layout deserves a true programming language.

ambition 18y ago
Separation of presentation from content is good, but presentation is a task of arbitrary complexity and requires arbitrary computation (aka a full programming language) to do properly. Many current frameworks are inadvertently used to bring the power of a programming language to presentation, but most of them don't seem to realize it yet.

lacker 18y ago

I think the fundamental problem is that the html/css/javascript/server stack needs to get simpler. For some apps, you are best off abandoning html entirely, and doing everything via javascript. Eventually we might be able to unify client-side and server-side code with approaches like Google Web Toolkit or YC's AppJet, but it is not quite simple enough yet.

jonnytran 18y ago
Yes, the ability to write code once that runs on either your server or the client is amazing, something Fog Creek implemented in Wasabi. But as JavaScript matures, it makes you start to wonder why you even bother with HTML at all; you can simply dynamically generate DOM nodes in JavaScript. And once you start doing this, most of the things you wanted to do running code on both client and server disappear.
- jshen 18y ago
  "But as JavaScript matures, it makes you start to wonder why you even bother with HTML at all; you can simply dynamically generate DOM nodes in JavaScript." SEO
  - jerf 18y ago
    Oh! So that's why Google is developing a speedy JS interpreter... they want to be able to see JS-based pages! They can load a page into a browser-with-no-graphics, and give the JS a certain amount of time to run before freezing the page and then reading off the DOM nodes instead of reading HTML. If they don't like the results, they can just use the HTML like they used to. (Reading off the DOM nodes also gives them a fresh crack at some more semantic analysis that used to be really hard, since it involved emulating a browser... did you use <span class="some_header"> instead of <h1>? They can make a better heuristic guess at that if they are "inside" a browser and thus capable of seeing that the size is twenty points higher than the surrounding text, no matter how you implemented that.) To really pull this off, you need a browser engine that enough people are using that site designers need to account for it, and it needs to be designed with the goal of running just the engine as quickly as possible on the backend, with the ability to cut it off after a certain amount of time. So... has anybody dug deeply enough into Chrome to have an opinion on the feasibility of running the browser without a UI?

halo 18y ago

CSS does have its limitations, however I'm not convinced providing full DOM manipulation is a good idea. I admit it does solve the problem and provide greater flexibility, but the downside is that it'd be very quickly misused with content and presentation becoming more tightly coupled as people start using the convenient CSS DOM manipulation with dynamic pseudo-classes for interactivity and removing many of the accessibility advantages that CSS has. There's also very real unaddressed problems in terms of creating a readable syntax, maintaining CSS code with injections all over the place and potential browser rendering issues. To me, the cure seems worse than the disease, and the Advanced Layout Module, despite its ugliness, is probably a better solution. CSS3 has gone a long way towards improving selectors, and I'll be the first to admit calc is undoubtedly both necessary and long overdue. I'm not fussed either way by CSS variables - I can see both sides of the coin.

neilk 18y ago
Can accessibility really get any worse? Extremely few websites are accessible today. If it weren't helpful for SEO, nobody would bother with it at all. Can readability get any worse? Nobody really understands floats. This is a layout language in which people regularly boast about how they achieved three-column layouts. Think about that for a second. And if you look at the code that achieves said three-column layout, it is impossible to tell what it does without comments. That's because CSS is written out as a set of spring-loaded contraptions all interacting with each other, meaningless without the "cascade" of DOM elements just so, and a browser model just so. There's nothing like "three_column_layout(node, node, node)". As far as I can tell, your thesis is that because CSS is underpowered, this will help us maintain accessibility. That's totally backwards! There will always be requirements for complex layout and interaction. That part of the job is not going away. So something's got to give. The artistic people go to Flash, the scripting people just do it with tables, and the server-side programmers go for some toolkit that pretends the browser is Java. Very very few people have the sheer bloody-mindedness to do the right thing and learn every last browser quirk and the so-called CSS model. CSS is DEAD. It is not the basis for a better future.
- halo 18y ago
  I'm going to break down the differences between my opinion and the original articles and hopefully your opinion. I admit CSS has its problems, and the core one is this: it's too complex to create good designs, and it's too easy to hit a brick wall. We can all agree on this. The most fundamental things about CSS aren't a problem. The cascade is sane, and is probably the best thing about CSS. It makes sense, it's fairly intuitive and can be describe in a couple of sentences. For styling, aside from the ugly non-JavaScript compatible syntax and the occasional unintuitive property-name choice, we're in pretty good state generally. The two biggest, and very real, problems are the unintuitive box model and layout model. Everyone should agree with this. I'll first deal with the relatively simply box model problem. The W3C box model was incredibly poorly thought out and makes like incredibly and unnecessarily difficult. It's simply inside-out. The width should refer to the total width of the box as in IE4 and quirks mode: this makes things wonderfully intuitive, makes things look as you expect and allows you to mix different units with ease. As it is, it width refers to the inside of the box and the real width is the inside width + border + padding. This is quite obviously nuts. There are two fixes to this problem: a nastier backwards-compatible one, and an actual nice solution. Both are in CSS3, and it gets full marks from me here. The first fix is to provide a way of calculating values so you can easily mix percentages with pixels. This is in CSS3 as the calc function. The second fix is switching to the traditional sane box model. In CSS3 there is a property to do this - add "box-sizing: border-box". So far, CSS3 gets full marks from me. The second core problem is layout. We currently have the "float model". I put them in quotes because it's not so much a model as people meeting the limitations of CSS2 but wanting many of the advantages of it and finding a way around them using floats. Presumably when CSS2 because a recommendation in 1998 the web looked like a very different place, the limitations of the model weren't considered a big problem, and then we were left in standards limbo which left us for several years without a decent CSS2 implementation and no table-replacing display: table implementation in the major browsers in sight. And up until now the only usable, accessible CSS model we had was arguably designed for something else entirely - the task of allowing text to flow around images on normal layout pages. To say this dirty hack is lacking is obvious an understatement, and that's excluding working around CSS bugs, but I'd still argue it's the best thing we have and the accessibility advantages and content seperation are worth the dirty hacks. And so we have where we are today and our problem - how do we provide a good, natural, way to make layouts? And any answer to this leads us to the fundamental subquestion and finally to where we started this discussion: how seperate do we want our content and presentation to be? This is actually a difficult, and slightly, ideological question. The more you seperate content and presentation, complexity of both the spec and language goes up, flexibility goes up, inherent accessibility goes down and so does inherent maintainability. The "completely" solution results in DOM injection, the "not completely" solution results in something nearer to the Advanced Layout Module. And this is where our fundmental differences clearly lie. I believe that forcing a reasonable amount of semantic ordering within content is a good idea as it helps encourage a certain amount of inherent accessibility as content has to be ordered. I believe that any syntax that would allow DOM injection would be inherently ugly syntax and not fit well within CSS. I believe that any syntax would have to be very carefully chosen to work at all. I believe that if you want ultimate control over the appearence of the page, you always have JavaScript and jQuery at your disposal. And you, and the article, believe that the advantages of flexibility outweighs my criticisms, and CSS would be underpowered without them. --- And to go back to your own post: Accessibility can get worse, and CSS3 is looking like it will improve the situation. Readability can get worse - floats are a dirty hack especially when combined with CSS hacks for dated browsers and as such inherently aren't readable, but adding injection into the mix won't automatically make life better. And yes, floats are a dirty hack and aren't an indicator of the future of CSS either way. CSS isn't really inherently underpowered: it depends how you see it. At the moment it needs fixing either way And CSS isn't dying at all, and CSS is going to be completely reborn over the coming years. Flash is still dying - Flash was always a dirty hack. CSS's display: table is going to replace with CSS as soon once IE7 dies in about 5 years. And CSS is getting better, compatability is improving and CSS3 is going to better than CSS2 whatever it chooses: DOM injection or not.

endergen 18y ago

The problem is that Microsoft inversely gains from improving the ease of browser development. The easier it becomes to develop software using open source tools(No Visual studios) on an OS-independent platform(The web with browsers) the less money they make. Google's recent project (Native Client) is what I've been waiting for as a C++ developer. It basically allows you to run native code(assembler) in browser. But then has security mechanism so that the code cannot do anything to the client computer unless the user of that client has given the container(Sandbox) that runs the code permission. This will allow people to build their own UI frameworks, that render much more rich graphics and hopefully behave the same no matter what Browser/OS combination you are running on. References: Announcement: http://google-code-updates.blogspot.com/2008/12/native-client-technology-for-running.html http://google-code-updates.blogspot.com/2008/12/native-clien... Native client code base hosted at Google code: http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/ Ars Technica review: http://arstechnica.com/news.ars/post/20081209-safer-than-activex-a-look-at-googles-native-client-plugin.html http://arstechnica.com/news.ars/post/20081209-safer-than-act... Do people really think we'll ever reach a point where different vendors building code-bases based on documentation built by a committee will ever behave even remotely the same? Have you read any of the W3C documentation, it's fucking ridiculous. We should be sharing implementations, it's the only way to ensure bit-level identical behavior of a target system(Performance characteristics aside). I really hope Native Client takes off. In combination with Gears for client side storage it would allow us to build desktop quality software but with the web advantages of cross platform development, zero install applications(well as long as you don't consider caching a form of installing), user's pulling down the latest client at all times, and etc. Awaiting our new Google overlords. Endergen

old-gregg 18y ago

If we're talking about fundamental problems, then the only fundamental problem is that we're using document markup tools to build rich UIs, which is super-retarded even comparing to early 90s VB6 era. WTF is <p> or <ul> or <div> and all that crap? I haven't seen an HTML template that looked comprehensible after a year in development. What do they have to do with UI programming? What we really need is something like MXML or XUL, only cleaned up and widely supported by all browsers, especially IE9.

sjs382 18y ago
<p> <div> <ul> don't have anything to do with UI.* They are document markup elements. UI is applied to a document (html) via CSS (style) and JS (behavior). This is all pretty elementary for someone reading this site... Maybe I missed some sarcasm? :p *Well, they do in a lot of instances, but when properly used, they have nothing to do with UI.
- potatolicious 18y ago
  Well yes, in theory those are not UI - but how many times have you seen someone create two divs for the semantically same data just so the CSS styles will play nicely? The problem is that CSS is not powerful enough to do rich layouts, and that forces developers to cripple the semantic goal of CSS/HTML by injecting presentation into what is supposed to be a presentation-free markup.
- fauigerzigerk 18y ago
  Yes that's the dogma. Alas, it's completely lost on me. I fail to understand how tables are more "semantic" than nested divs. Tables only have semantics within the context of some formalism that defines their semantic meaning. Outside of such a context they can be anything, so why not a way of laying out information on a page? I don't see how swaths of divs, some of them used for semantics (according to some metadata standard), some of them used for purely presentational purposes, improve anything. CSS people (or should I say modern web developers) are completely anal about not using tables for layout whilst at the same time the whole notion of document structure is so utterly destroyed in any JavaScript heavy app. These priorities make no sense to me. Laying out web pages with divs and CSS is a black art. It's fragile. It breaks in all kinds of nasty ways. It reduces the productivity of UI development to pre 90s levels and leads ot entire pages done in Flash.

thomasmallen 18y ago

"If you look at the specification there was only one property in CSS1 that could be used to effect layout - float. position didn’t even exist, and in HTML 2 neither did <div>, the two essential tools without which no modern design could be achieved (without resorting to tables)." Lost me there. A <div> is just a vanilla block-level element. You can turn anything into a <div>. "CSS can only be applied to elements that have semantic meaning" You should see the CSS that developers I've worked with write. Even worse is that DreamWeaver has its "style1", "style2" way of doing things which makes picking apart a stylesheet very tedious.

olavk 18y ago

He has a good point: CSS can only define the appearance of existing HTML elements. Sometimes you need visual elements which doesn't correspond to any semantic HTML element. I think SVG would be a good approach for designing these "unsemantic" visual elements, and you can use CSS with SVG. SVG would also be a good way to extend CSS beyound the built-in properties, eg. if I want to design a wawy border to apply to some elements. He also has a good point about the need for calculation in CSS. However I am really worried about the possible manitenance nightmare of a turing-complete CSS! It should be designed very carefully. A constraint-based sublanguage for CSS would perhaps make sense.

tptacek 18y ago

The fact that you can already accomplish what he wants with jQ, and that his proposed solution is to add imperative programming semantics to CSS, one assumes the reasonable response to this is simply a compiler that spits out CSS/JS based on whatever random feature he wants CSS to have.