It is amazing that there has been so much resistance to this sort of thing.
Why I'm Excited About Native CSS Variables
21–30 of 33 posts
Re: Why I'm Excited About Native CSS Variables
#22It is amazing that there has been so much resistance to this sort of thing.
Indeed! That's why I wrote the article :)
Re: Why I'm Excited About Native CSS Variables
#23Re: Why I'm Excited About Native CSS Variables
#24Re: Why I'm Excited About Native CSS Variables
#25The author lists all the ways CSS variables are better than preprocessor variables. But that is the same reason that the design is flawed. JavaScript has shown us the value of designing new features in a way that they can be polyfilled or emulated via a preprocessor, so that features can gain adoption without developers having to wait for older browsers to die. CSS variables were overdesigned in a way that makes this…
Polymer partially polyfills CSS Custom Properties:
https://www.polymer-project.org/1.0/docs/devguide/styling.ht...
Also, for what it's worth, not all new JavaScript features are polyfill-able. Proxies, for example, are impossible to polyfill, should they not have been added? WeakMaps are also only partially polyfill-able, are they overdesigned too?
Re: Why I'm Excited About Native CSS Variables
#26Earlier quoted context omitted.
Debating the syntax is not the same as resisting the feature.
I don't see a lot of "debating" going on. If you want to point me to some constructive debates, that would be nice.
I guess that depends on how you define debate. I'm referring to that the proposal is made and some people show their distaste for part of what is proposed. Those that made the proposal, or support it, respond. This is shown in the article. I see no resistance to the feature being introduced in that, just disagreement on a part of the proposal.
Re: Why I'm Excited About Native CSS Variables
#27Earlier quoted context omitted.
Debating the syntax is not the same as resisting the feature.
I don't see a lot of "debating" going on. If you want to point me to some constructive debates, that would be nice.
> I guess that depends on how you define debate. I'm referring to that the proposal is made and some people show their distaste for part of what is proposed. Those that made the proposal respond. I see no resistance to the feature being introduced in that, just disagreement on a part of the proposal.
Just to be clear, neither I nor Addy Osmani proposed CSS Custom Properties. We're just excited about the feature and sharing it with others. So when people respond negatively to us, it doesn't feel like debating.
The time for debating was when it was being discussed in the working group; before it was implemented in three different browsers.
Re: Why I'm Excited About Native CSS Variables
#28The author lists all the ways CSS variables are better than preprocessor variables. But that is the same reason that the design is flawed. JavaScript has shown us the value of designing new features in a way that they can be polyfilled or emulated via a preprocessor, so that features can gain adoption without developers having to wait for older browsers to die. CSS variables were overdesigned in a way that makes this…
Polymer partially polyfills CSS Custom Properties: https://www.polymer-project.org/1.0/docs/devguide/styling.ht... Also, for what it's worth, not all new JavaScript features are polyfill-able. Proxies, for example, are impossible to polyfill, should they not have been added? WeakMaps are also only partially polyfill-able, are they overdesigned too?
I believe that where possible it makes sense to follow what is already happening in the wider open source ecosystem, rather than trying to design a solution from scratch.
There is a huge demand for constants/variables in CSS, as well as a widespread use of preprocessors. The CSS variable spec does bring a lot of interesting ideas to the table, but it does so at the expense of ignoring how people are shipping code today.
Designing a solution that can be dropped into an existing pipeline can be valuable even if doesn't introduce any new concepts or features. For example Promises in JS are pretty simple and just replicate the functionality of existing libraries, but they normalized existing patterns and made it possible to trust that third party code would have consistent behavior. That was a huge boost.
Re: Why I'm Excited About Native CSS Variables
#29What I am most excited about is manipulating these using javascript, which is also something you cannot do with a CSS processor because the values are baked into the CSS.
I don't understand that use case. If you're happy using a JS value to update a style, what's wrong with just updating the style in JS? If you're concerned about performance then you can obviously do things like debouncing anything that changes the style, or you could use a MediaQueryListListener to fire an event your JS listens to when a user crosses over a media query breakpoint. While it'll be fun to manipulate CSS…
It seems like this would let you update lots of styles simultaneously, without having to keep track of exactly which styles they are.
Re: Why I'm Excited About Native CSS Variables
#30Earlier quoted context omitted.
I don't see a lot of "debating" going on. If you want to point me to some constructive debates, that would be nice.
> I guess that depends on how you define debate. I'm referring to that the proposal is made and some people show their distaste for part of what is proposed. Those that made the proposal respond. I see no resistance to the feature being introduced in that, just disagreement on a part of the proposal. Just to be clear, neither I nor Addy Osmani proposed CSS Custom Properties. We're just excited about the feature and s…
I realized the difference, which is why I edited and added in those that support the proposal. Weird that your response is listed underneath the post you are quoting.
So, you should be immune to a negative response when you publicly state your support for a feature? People don't like how the feature is implemented and say as much. Like I said, it depends on how you define debate and I guess it doesn't match your definition. That's fine with me. But that doesn't mean I don't get to refer to it as a debate. I see it as a debate and if you disagree, that's fine with me as well.
People did debate during the proposal and as such things usually go, people will continue to do so. People had similar issues with flex and gradients. Note that the syntax for those were altered after they were implemented into browsers.