Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CSS Variables landing in Chrome 49

developers.google.com

Post reply on HN
Print view View original

61–70 of 70 posts

Re: CSS Variables landing in Chrome 49

#61

Post by frik »

esailija wrote: post #43
frik wrote: post #15

Earlier quoted context omitted.

Stupid decision, the should have used $foo (dollar sign for variables) like in Perl and PHP. It remind me decisions of standards based on XML (XLST, XML-Schema, RDF, etc).

Read the linked post. Css variables are nothing like macros like sass's `$foo` and css might support macros with sass's `$foo` syntax in future.

I read the article, that's why I commented because "might support something in future" that probably never happens, is what I related to XML based formats design decisions go wrong. Argh, but thanks for misunderstanding and downvotings.

Re: CSS Variables landing in Chrome 49

#63

Post by dEnigma »

TazeTSchnitzel wrote: post #54
dEnigma wrote: post #42

Earlier quoted context omitted.

He was just explaining how it worked in Windows 95, he will be using CSS variables instead.

She, and yes, that's the idea. I couldn't explain it very clearly.

Sorry, I always default to the male form for some reason.

Re: CSS Variables landing in Chrome 49

#64

Post by TabAtkins »

SwellJoe wrote: post #10

I've wondered for years why we're using pre-processing to get variables into CSS. Given that there hasn't been a commonly advocated workflow that didn't include some sort of CSS processor (like LESS or SASS) in about a decade, it seems like somebody working on the standards would have realized that CSS needed variables, at the very least. So, it's cool that it's coming, though it's taken a lot longer than I reckon it…

Properly, the --foo stuff is a Custom Property. You can use its value as a variable, with var(), but it's not the only use custom properties have. That's why the spec's full name is "CSS Custom Properties for Cascading Variables". But that's a horrible mouthful, so "CSS Variables" is what it's usually called. (Plus that's the shortname in the url.)

(There's also a large focus, in v1 here, on the variables use-case, because that's what I needed to sell it to the group at the time. The CSS Houdini Task Force is now expanding Custom Properties properly, so they can actually be used for random JS things without a ton of hackery.)

Re: CSS Variables landing in Chrome 49

#65

Post by TabAtkins »

stupidcar wrote: post #50
nailer wrote: post #18

Earlier quoted context omitted.

The CSS team has people like this, who no longer make websites: https://www.w3.org/People/Bos/CSS-variables Thus they're disconnected from current web developers. Meanwhile Smashing says something like 77% of audience uses SASS.

Ah, Bert Bos, the W3C's "style activity lead". What a joke. He's the guy who wasted a decade writing an ASCII-art based "template layout module"[1], which he was never able to persuade a single browser vendor to implement. It eventually got demoted from a working draft to a "note", which is the W3C's polite term for standards fanfiction. His other major achievement is putting his own photo on every one of the CSS wor…

> He's the guy who wasted a decade writing an ASCII-art based "template layout module"[1], which he was never able to persuade a single browser vendor to implement. It eventually got demoted from a working draft to a "note", which is the W3C's polite term for standards fanfiction.

This is because it was absorbed into the larger and more fleshed-out Grid specification, which is nearly release-ready in multiple browsers. The ASCII art is actually really useful!

Re: CSS Variables landing in Chrome 49

#66

Post by TabAtkins »

innocentoldguy wrote: post #55
colinramsay wrote: post #8

Earlier quoted context omitted.

I think a lot of people agree with you but there is a reason: http://www.xanthir.com/blog/b4KT0

I understand the reasoning, but this new syntax is still kind of verbose and ugly. I think one of the reasons Sass has been so successful is that it is elegant. It adds a lot of functionality to CSS, but does so in a way that feels very much at home. This new syntax doesn't feels very elegant and it doesn't feel at home with current CSS syntax.

If I'd done what everyone keeps saying I should have done and just used $foo, then Sass would have gotten angry at me, because we'd be sharing syntax for different features. We already tweaked CSS a little to avoid that in another case (when specifying grid line names in Grid, you surround the names with []; it was originally (), but Sass asked us to change it because they use that for their list syntax).

We could only have used $foo if we hewed very close to Sass's functionality - global macros that operate at the stylesheet's lexical level. That wasn't what we wanted to do, though, either at the time (considering only the variables use-case) or looking forward (to the use of custom properties as the generic "inject info into your page via the CSS engine", a la data attributes for HTML).

By avoiding global macros, we also get context sensitivity - we can actually offer APIs for this stuff that are smarter than "here's the string you set". When we add custom pseudoclasses, custom media queries, etc they'll all get their own useful APIs. Sass is stuck with string manipulation, because you can use a Sass var anywhere, so it's impossible to infer anything about it.

Re: CSS Variables landing in Chrome 49

#67

Post by TabAtkins »

andrewingram wrote: post #56
achairapart wrote: post #11

Earlier quoted context omitted.

You can use it today with the help of http://cssnext.io

You can use a limited subset. cssnext isn't magic, it's purely a source transformation, there's no runtime. It can't handle the dynamic part of css variables.

Yeah, CSSNext here is basically the intersection of CSS variables and Sass variables - you can only use them in property values (like CSS), and you can only declare them at top-level (like Sass).

It's nice if you really want to utilize the current syntax, but it's less powerful than either option it's derived from.

Re: CSS Variables landing in Chrome 49

#68

Post by TabAtkins »

hanniabu wrote: post #31

I'm not a fan of this... /* JS */ var styles = getComputedStyle(document.documentElement); var value = String(styles.getPropertyValue('--primary-color')).trim(); // value = 'red' Rather than calling '--primary-color', you should really be able to call 'color' which points to the variable and will still return red. Otherwise you'll have to know the name of each variable being used, which is much more difficult than kn…

That's exactly what you can do. var() is replaced at computed-value time, so calling gCS().color will return "red" or whatever.

If you use an API that gives you the value at an earlier time, like el.style.color (which is "specified value"), you'll see the var().

Re: CSS Variables landing in Chrome 49

#69

Post by TabAtkins »

lcnmrn wrote: post #16

Just add native support for Sass and call it a day.

"Just add native support for jQuery and call it a day" "Just add native support for React and call it a day"

We can do lots of amazing things in the ecosystem, but often we're working around missing primitives in the platform. Just "adding native support" for today's hottest library doesn't fix things properly. It's better to figure out what problem they were solving, and then fix that problem more directly.

(jQuery is largely solving "DOM APIs suck". We've fixed that a little bit, with things like query() (née querySelector(), which was an awkward first attempt at it) and fetch(), but are still struggling to work through browser dev apathy at things like event registration or creating elements.)

(Figuring out what problem, precisely, React is solving is exciting and interesting. It's non-obvious - it's not just "some DOM things are slow", as there's lots of DOM things both fast and slow, and you don't need a fancy (read:slow) tree-diffing algo to fix those. There's something fundamental going on that we might be able to do better - maybe it's more fully separating the "display thread" that contains DOM from the rest of your JS, and letting you do a lot of DOM-ish manipulation in threads other than the display thread. Maybe that means actually using an even more lightweight display abstraction, so you can cheaply spam out updates without having to do expensive diffing first. There's a lot of possibilities here.)

Re: CSS Variables landing in Chrome 49

#70

Post by true_religion »

TabAtkins wrote: post #69
lcnmrn wrote: post #16

Just add native support for Sass and call it a day.

"Just add native support for jQuery and call it a day" "Just add native support for React and call it a day" We can do lots of amazing things in the ecosystem, but often we're working around missing primitives in the platform. Just "adding native support" for today's hottest library doesn't fix things properly. It's better to figure out what problem they were solving, and then fix that problem more directly. (jQuery…

DOM APIs didn't suck too badly. They weren't great, but they were usable.

The problem was that every old browser had its own API and feature set. Jquery abstracted over all that, including bugs in specific versions of browsers and continually is updated to handle the case of a browser claiming to implement a feature but lying.

Really if all browsers had the same API and feature set, there'd be no need for jQuery as it is today; you'd have a very different library.

Post reply on HN