Hacker News Reader

Comment by VMG | Hacker News Reader

from http://www.w3.org/TR/css-variables/

    :root {
      var-header-color: #06c;
    }
    
    h1 { background-color: var(header-color); }

looks slightly hacky, but better than nothing at all I suppose...

View on HN

It's nowhere near as nice as the sass/scss/less syntax for css variables.

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.

You can compile your LESS so that no JS is required in the browser.

Yeah but then you can't do wild changes on the fly to vars, which was what I was alluding to.

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.

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.

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.

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.

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.)

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 :/

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; }

Out of curiosity, why was the syntax in the current draft chosen over this?

To be very clear rhe one on the left defines, the one on the right uses.

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?>

This is a terrible idea. Do you cachebust your CSS?

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.

You do lose the benefit of caching with that approach, though.

You don't have to. You treat it like you would with LESS - executes during development and you compile it for production

At that point you should just be using LESS/SASS/etc, though, for the other niceties they provide for working with colors and such.

Reply on news.ycombinator.com