6 ms·

from http://www.w3.org/TR/css-variables/ http://www.w3.org/TR/css-variables/ :root { var-header-color: #06c; } h1 { background-color: v

• hellweaver666 14y ago
  It's nowhere near as nice as the sass/scss/less syntax for css variables.
  • randall 14y ago
    It's not the css we wanted, it's the css we deserved. :) But seriously, this is extremely consistant with other css directives. Yes, I'm still going to just use less / stylus / whatever, but browser based vars mean some interesting possibilities sans js.
    • benmccann 14y ago
      You can compile your LESS so that no JS is required in the browser.
      • randall 14y ago
        Yeah but then you can't do wild changes on the fly to vars, which was what I was alluding to.
• SquareWheel 14y ago
  Oh jeez, that's going to be really cumbersome to write. edit: I think I'll stick to PHP variables in my CSS for now: <?=$color1?>
  • Hovertruck 14y ago
    You do lose the benefit of caching with that approach, though.
    • philfreo 14y ago
      You don't have to. You treat it like you would with LESS - executes during development and you compile it for production
      • Hovertruck 14y ago
        At that point you should just be using LESS/SASS/etc, though, for the other niceties they provide for working with colors and such.
  • btipling 14y ago
    This is a terrible idea. Do you cachebust your CSS?
    • SquareWheel 14y ago
      I generally make heavy use of both server-side and client-side caching. It really depends on the site. If it's just an internal company tool then I usually don't worry about intelligent caching. I understand the danger of introducing PHP to CSS though. I won't be making database calls or anything like that from a .css file.
• voidr 14y ago
  This looks like crap, I am sticking to LESS. It's not worth standardizing half assed stuff like this. These standards groups should open their eyes and look around before standardizing something.
  • untog 14y ago
    It might be of use in CSS debugging, not that I have a huge problem debugging LESS files. But eventually perhaps there will be LESS -> CSS/variables we can test with.
    • drivingmenuts 14y ago
      Seriously? Debugging in Sass is a no-brainer - it barfs as soon as there's an error and it's blatantly obvious as soon as you load the page, since the relevant errors are splattered all over the the top of the page (this is a good thing). This proposal by the W3C is definitely not-even-half-baked.
      • untog 14y ago
        I don't mean debugging in the sense of "there's a compilation error", I mean in the sense of "oh, that box has a blue border? That's wrong- what line did I define that variable on?". As I said, it's not a huge problem right now, but in more complex files it can take time to track down the original definition that led to the CSS you're seeing.
• TabAtkins 14y ago
  Syntax isn't frozen. Here's another possibility: :root { $header-color: #06c; } h1 { background-color: $header-color; } (Note that the spec's use of the :root pseudo is just to generically declare "global" variables that should apply to the whole page. If you're just using HTML, feel free to use "html" or "body" as the selector instead.)
  • bkardell 14y ago
    To be very clear rhe one on the left defines, the one on the right uses.
  • aboodman 14y ago
    Out of curiosity, why was the syntax in the current draft chosen over this?
  • nilliams 14y ago
    This syntax is clearly preferable, but I think you knew that or you wouldn't have written it :) I'm guessing the justification for the existence of the awkward var(varname) version is so that you can also have the parent-var(varname) notation. I do think it's interesting how variables are scoped to dom nodes. Is there any reason it cannot be optional though, so if you omit it, it defaults to global? $header-color: #06c; h1 { background-color: $header-color; } I'm guessing the argument against, is that this requires too much of a change to CSS parsers, as it doesn't follow the standard form of <selector> { <properties> }. If that's really the reason it seems a bit of a shame though :/
    • bkardell 14y ago
      I disagree that it is preferable, but that is debatable. I say that in part for the reasons you mention, but also because it seems to me that quite a lot of people think that "$header-color" means "substitute the value of the header-color variable here" regardless of which side it is on. I think there is probably a happy middle ground where you achieve all of the goodness (looks like CSS, follows existing core grammar, shows the property nature, uses $ in familiar ways, etc). Not sure what it is, but probably something like: :root{ def-primarycolor: blue; } .x{ background-color: $primarycolor; }