• 200810 Apr

    This week has seen the release of a raft of new proposals for features to be integrated into the CSS specification:

    I personally have reservations about the Visual Effects proposals, feeling this is better suited to Javascript, but I seem to be in the minority on this so I will cede to the majority. I’m pretty excited about Variables, however.

    You can skip to the end and leave a response.

  • Comments

    • 01.

      […] nuevas propuestas presentadas por el equipo de WebKit, recopiladas en CSS3.info. Pueden llevar a un debate interesante por parte de los más […]

    • 02.

      Nuevas propuestas para CSS…

      Desde Webkit proponen una serie de mejoras para CSS que, sin duda, nos ayudarían a mejorar la elaboración de hojas de estilo. Entre ellas… ¡Manejo de variables!. Yo ya tengo ganas de echarle la mano, en caso de que prospere….

    • 03.

      […] it’s worth mentioning this article on CSS3.info. Read the variables spec at least — it’s short (so far), simple and solves […]

    • 04.

      I’m very wary of these animation ideas. Much like CSS Content, animation is potentially very useful, but extremely open to incorrect use. CSS content should be about revealing content that’s already in the document, or purely presentational. CSS animation ought to be about pure display effects, not linked to behaviour interactions.

      As long as the documentation is clear about how and when to use these things, they should be fine. But I think it’s not going to happen that way.

    • 05.

      I am as well wary, especially about performance on older machines (though maybe that is no concern), but actually I:

      – think something like this needs to be done
      – on CSS

      To be honest I always felt that CSS solutions are cleaner than a javascript hackery. Lets be patient and see if this will turn out “elegant”

    • 06.

      One has to wonder if current browsers can’t even get simple things such as box model done correctly, how they would ever implement all of these animation type things.

      I agree that it probably belongs in javascript. The only problem is even if you wrote compliant javascript, it’d probably be 100+ lines of code. Perhaps it’s javascript that needs to play catch up and just create something like obj.animation…..

      The variables prop. rocks!

    • 07.

      I was pretty sure someday CSS would do more and more that JS used to do. With CSS dropdown menus, target=”” galleries, :focus and other tricks people have found out. It kinda of makes sense to allow CSS to do more. I just wonder if some people will end up making sites work like Powerpoint.

      Now if IE would just support SVG, then CSS with animation could take the web to a new level of innovation.

    • 08.

      […] nuevas propuestas presentadas por el equipo de WebKit, recopiladas en CSS3.info. Pueden llevar a un debate interesante por parte de los más […]

    • 09.

      CSS is all about presentation. If there is movement, change, or animation that is strictly about presentation it seems more appropriate and accessible to put it in a style sheet rather than code it in Javascript.

      Today, CSS allows the end user to use local style sheets to override or disable annoying styles. I’d love for this to apply to presentational animation styles as well. Remember the annoying html blink tag? That was the poster child for annoying animation effect in the early days of the web. As html, you couldn’t turn it off or separate the content from presentation. If blink were re-implemented as a Javascript effect, you’d have to disable JS to stop the throbbing nightmare. If it was implemented as an annoying CSS 3 animation, it would be as easy to disable completely or override by the end user.

      The other place where it’s handy to know the movement is merely a presentation effect is when a browser can’t display something easily and has the choice: devote all resources to getting this pixel perfect, or degrade what’s presented in a manner that’s close enough. If you look at Figure 1 in the CSS Transitions doc (a red square changing color to blue while sliding right on the page), it’s easy to imagine a resource starved browser trying to implement this effect when palette changing or trying to reflow the document with each frame changing. With these instructions as Javascript, it would spike the CPU and go whole hog trying to implement the page author’s instructions (how could it know to do otherwise?). As a CSS3 style sheet, it knows what the end effect should be and can create some animation frames to illustrate the movement as best as it can under the current resource limitations.

      When I first heard about CSS 3 proposals to add movement, I thought it was a silly distraction, but the more I think about it, the more I think it’s an appropriate way to describe movement that’s purely about presentation. If this were a simulation of black body radiation and degrading or overriding the movement was fundamentally wrong, then Javascript or Flash or some other tech is the appropriate way to show movement. If it’s not a core concept of what’s being displayed and is merely a presentation effect, then a CSS style sheet would be a welcome place for it to reside.

    • 10.
    • 11.

      I love this blog!!!!

      Thanks, very much!

    • 12.

      I’m not very sure the animations and transitions/etc. are a good idea. Eventually we’re going to need entirely new extensions/blockers to browsers to block these effects, just like we have javascript and flash blockers now!

      But variables, that’s a good thing. IMO, it should be finalized and implemented in all major browsers by end of 2009.

    • 13.

      “But variables, that’s a good thing. IMO, it should be finalized and implemented in all major browsers by end of 2009.”

      Yes, in an ideal world they should be. However, in reality they won’t be; what Daniel has come up with is only a simple proposal. After enough feedback has been received (that’s even if the WG receive enough positive feedback to warrant it going any further), it needs to go through four levels of stability to make it to a REC; Namespaces was considered stable enough (although technically it’s still only a CR) to be included in the ’07 Snapshot, nine years after it was proposed (although it’s been implemented interoperably for many years). I’m not trying to say it’s going to take that long for Variables to make it to REC, but I honestly don’t think a time-frame of a year and a half allowing for Proposal to REC & browser adoption is realistic.

      Add to this there is no inherent fallback, and you are left with a feature that, from a cross-browser perspective (but depending on your targeted browsers), isn’t likely to see the light of day for many years to come.

    • 14.

      Comе on, how there will be innovation if we look at the old computers and say oh the old machines cant handle it. Things have to evolve.

    • 15.

      I agree with Emil… Whether software or hardware related, I think backward compatibility is overrated.
      Besides, if browsers implement and optimize these features, even old computers could be good to go.

    • 16.

      Why must someone always fight for the old? The thing about the old is that it worked. So if you want something fully developed stick with the old. If not go with the new.

      I say make it compatible but not at the expense of time. If people hate it they will upgrade. I stick with the old and that is my choice. My clients want what is new. Use the tried and tested.

    • 17.

      […] ese motivo en css3info, han publicado una lista de sugerencias para incorporar nuevas funcionalidades al […]

    • 18.

      I must say, these look very nice. The syntax for the variables seems very sensible, so we will probably see implementations for this in dev builds long before the rest of the properties. I also like the idea of moving animation to the browser and out of javascript, which should make the rendering smoother (anything being done in C++ should be quicker than JS). The proposals also seem sensible in that you usually want the animations to interact with the page, so they link it in with DOM events.

    • 19.

      It’s all very well, but CSS 2 has been with us for ten years now and none of the currently available browsers fully support it. The most widely used browser, the utterly horrible Internet Explorer (the most hated browser among web designers) has never been able to support any of the proper recognised standards.

      Microsoft seem to be very much against supporting a browser that adheres to any standards not invented by them, so unless IE dies a much deserved death CSS 3 will probably never live up to any of it’s promises anyway.

      Shame really because as a designer I would welcome many of the new proposals…

    • 20.

      CSS Variables would be killer useful. No more copy pasting or find/replacing.

    • 21.

      […] Expression suddenly came to me as a solution for the currently much debated feature (here and here) of variables in CSS3. This could theoretically be currently achieved through the use of CSS […]

    • 22.

      I agree with you regarding the visual effects thing. I’d like to note that I love CSS and hate JavaScript (although JQuery has gone a long way toward making me like it more). I don’t think CSS should bother with animations, with one caveat: I’ve always wanted to be able to add simple animations to :hover styles. I can do this with JQuery, but I want the :hover to work just like it does now if the user has JavaScript turned off, with the extra animation if they’ve got it on.

      I’ve poked around for a while, but so far the only way to do this seems to require some code duplication. (I just want to write a quick script that says something to the effect of, “$(‘element a:hover’).fadeIn();”, although that leaves me scratching my head because there is no *:unhover . :)

      Is it my imagination, or have the W3C gone way downhill after all the corporations (esp. Microsoft) became members? It seems that new proposals are become more poorly thought out every time I happen to come across any. A ‘word-wrap’ property? WTF? Shouldn’t this be part of ‘text-overflow’? At least as an optional value for ‘text-overflow’ that could be added after its standard values, much like the multiple values used in the shorthand properties for ‘border’, ‘font’, or ‘background’.


      Just found this site, BTW. Fantastic website, this. Great work! :)

    • 23.

      Have you tried $(’element a:not(:hover)’)? else you have events mouseout and mousein (or was it mouseover?).

      Another thing you could do is to use a gif/apng that doesn’t loop. That should work in most browsers I think.

      text-overflow sets the behavior of overflowing text when you have limited height and width while word-wrap sets whether words are allowed to be broken up between lines when the horizontal space isn’t enough. Putting these two together would be illogical. If you’re going to group text-overflow. grouping with the rest of the text-* properties would be more like the font case; same goes for word-wrap.

    • 24.

      […] Expression suddenly came to me as a solution for the currently much debated feature (here and here) of variables in CSS3. This could theoretically be currently achieved through the use of CSS […]

    • 25.
    • 26.



Advertise here?