Legend

Question

OT: css variables, (custom properties)

Forum|Forum|8 years ago
March 28, 2017
3 replies
3430 views

As you all know I am not a fan of pre/post-processors, but I can understand why people use them.

One of the main reasons given is the use of variables, which I will agree is an advantage, but now that Edge is implementing support for the W3C CSS Custom Properties module, that reason will greatly diminish over the next few years.

Microsoft has published an article describing the use of css variables, with an example of how to create fallback for those interested.

https://blogs.windows.com/msedgedev/2017/03/24/css-custom-properties/#0m9wDZ4VAQAZdcsF.97

if your variable value is -

--primary: #0B61A4;

then the use with fallback would be -

body {

background: var(--primary, blue);

}

This topic has been closed for replies.

pziecinaAuthor

Legend

Just an update on css variables.

Microsoft Edge 15 now fully includes the feature, and the windows 10 dev edition shipped today, so it should be in the next major update for windows users.

B i r n o u

Legend

hello all, sorry I'm late on this thread... and sorry too if I didn't had time to read all this long thread... I just fly over... I will anyway digg further what have been said...

anyway, for much I red was about comparing sass and css custom properties,

well, FWIT, and at the risk of hearing some howling, it is like comparing what we call here in France, comparing canada dry and scotch...

Canada Dry is gilded like alcohol, its name sounds like an alcohol name ... but it's not alcohol.

wait... before going further... I'm a real Sass addict... and the next series of article to be publishe on creative pipeline is about sass... so don't take my word as argue...

first CSS CP is a w3c recommandation, so that do mean that in a next future all browser will understand it natively

second CSS CP is almost new...(I mean work on recommandation start years ago, but was'nt never took seriously... that's why preprocessor came out...) but now they just need to become stronger and complete... so applying them in IDE NOW is a real need as a first start...

third, currently one can do stuff with css CP that we can't with preprocessor... so that's a way to go... imagine what can do JavaScript above it.?...

to get what I mean... copy paste what's below and test it in a browser

<!doctype html>

<html>

<head>

<title>Document sans nom</title>

<style>

@media (max-width:25em){

body {

--couleur:red;

}

@media (min-width:25.0625em){

body {

--couleur:blue;

}

h1 {

color:var(--couleur);

}

</style>

</head>

<body>

<h1>Titre</h1>

</body>

</html>

O

osgood_

Legend

to get what I mean... copy paste what's below and test it in a browser
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>Document sans nom</title>
<style>
    @media (max-width:25em){
        body {
            --couleur:red;
        }
    }
    @media (min-width:25.0625em){
        body {
            --couleur:blue;
        }
    }
    h1 {
        color:var(--couleur);
    }
</style>
</head>
<body>
<h1>Titre</h1>
</body>
</html>

Could'nt they come up with something better than -- that's really awfully poor syntax and hard to read (is it a long dash or 2 short dashes) I mean even a + would have been better or even ++ if + is not available

This is what pisses me off about everything its ruined by short-sighted morons. What's the stupid thinking behind that?

Rob Hecker2

Legend

More than half my CSS is generated from PHP. Most of this is color choices for various elements. Structurally, web page sections share similarities, so a header, footer, logo bar, array of card boxes, and seven other page sections are created by a function that builds basic functionality. This then starts to make management of CSS organized and logical.

So I personally don't need variables in CSS, but I can see a huge advantage to it for others. One could then define a color palette at the top of the CSS file and all those colors would populate the right element definitions.

O

osgood_

Legend

Never found much use myself for css variables but maybe that's because I'm offput by having to keep 2 files on the go to make it happen. I suspect I might find use for them when eventually variables can be rendered directly within the css file itself. I don't seem to have much trouble just using vanilla css for the kind of sites that I produce. We don't see that many questions about SASS or LESS around these parts so I guess no-one apart from the odd one or two really find much use for them, certainly they play a small part in the bigger picture.

pziecinaAuthor

Legend

osgood_ wrote
Never found much use myself for css variables but maybe that's because I'm offput by having to keep 2 files on the go to make it happen. I suspect I might find use for them when eventually variables can be rendered directly within the css file itself. I don't seem to have much trouble just using vanilla css for the kind of sites that I produce. We don't see that many questions about SASS or LESS around these parts so I guess no-one apart from the odd one or two really find much use for them, certainly they play a small part in the bigger picture.

That's what the article i linked to is explaining, css variables are for use in your vanilla css file, not a sass file, (only one file required) as they are w3c css. That means css variables are used directly within the css file itself.

The use of css variables are similar to css grids, in that they require a fallback at the moment. The reason i think that standards complient w3c css variables are important, is that variables are one of the prime reasons given for using sass or less, and along with mixins, and the autoprefixer are the three top features used in sass/less. Now there is no reason to use sass/less as far as i can see for the avarage coder, providing they are not using Dw.

Dw is missing a stand-alone autoprefixer, and support for css variables along with almost everything else i mentioned, which is why i think it is still important to at least make users aware of what the specs and browsers are now supporting, even if Dw does not, and hope that once users become aware of what is possible without 3rd part plug-ins, they may ask for support.

If they don't, then Dw will move even more closer to becomming an EOL product.

BenPleysier

Community Expert

Me thinks this is a bad idea! Even if all browsers recognise CSS variables, the CSS would have to go through a process of substitution before the document can be rendered.

In the case of SASS, Less and Stylus, the source file is compiled into a usable CSS document. Using the latest version of Dreamweaver, compiling is a matter of saving the source file.

Wappler is the DMXzone-made Dreamweaver replacement and includes the best of their powerful extensions, as well as much more!

pziecinaAuthor

Legend

BenPleysier wrote
Me thinks this is a bad idea! Even if all browsers recognise CSS variables, the CSS would have to go through a process of substitution before the document can be rendered.
In the case of SASS, Less and Stylus, the source file is compiled into a usable CSS document. Using the latest version of Dreamweaver, compiling is a matter of saving the source file.

The css does not go through a process of substitution in the browser before rendering the css, it is processed in a similar manner to javascript execution, in that the variable value is substituted, 'on the go' as the variable usage is encountered, (very little to no overhead).

As for the use of pre/post-processors, the files created by these are on average about 20% bigger than those created if vanilla css is used. So a disadvantage in actual use.

rayek.elfin

Legend

BenPleysier wrote
Functions (mixins) and variables.

mixins = DW Snippets, (would need better functionality in Dw to include in css, but that is all they are)

Variables = css variables (will be a few years before can really be used, but the W3C is catching up)

@pziecina Why wouldn't you use a preprocessor? Sure, variables will be part of CSS in a year or five, but they aren't now - I am only interested in what makes my coding life easier NOW, not later.

Why on Earth would you prefer DW snippets over scss includes? They are quite different. For one, DW snippets cannot make use of variables. But more importantly, an edit to your snippet would not automatically cascade that updated code throughout your project, which sort-of renders them useless in my opinion - certainly not up to par to scss includes.

And I am not even mentioning the issues with relying on DW snippets when working in a team in which most other coders probably will be using other editors: at least with scss it is "cross-editor' compatible. It becomes more about workflow than anything else.

However, I do agree scss includes should not be used for browser prefixing at this point: post processing with autoprefixer takes care of that. You'd be very unkind to yourself (in my opinion) to not make use of autoprefixing.

And aside from the variables, there are a couple of things I like about using scss:

@import, and compartmentalizing the css code in modules, which then creates one minified css file. @import in regular css loads sequentially, slowing down the page load, unlike the @import statement in SASS.
functions. For example, easy and efficient method of working with REM values only instead of terrible px: simple function is all that is required.
https://codepen.io/jelleverzijden/pen/xGYZYV
the ability to nest @media queries in a rule. Much easier for code organization (granted, at a risk of larger code base at the end), and for handling @media exceptions.
conditions are handy. And we can use them NOW.
the option to have the task runner run autoprefixer and other routine tasks (minify the code, for example).

Having said this, I completely agree that scss can be abused to write obscure and overly complicated style code that becomes unreadable to anyone except the person who wrote the code. And I have seen people write ridiculous deep nested selectors - one of the main reasons of the 20% overhead. I avoid nested (descendant) selectors as much as I can, and my compiled css code is as lenient as if I had written it without scss. Scss does not take away the responsibility to manage your coding well: neither does css.

One argument you give is actually an argument in favour of using post-processors such as cssnext: you can write your css code with the latest W3 specs / features, and it will output css code that is compatible with all browsers. As time goes by, and those newer features are supported natively by all browsers, the updated cssnext post-processor will no longer need to generate alternate cross-browser compatible css code, and by then you have adapted to the new specs for years and years.

Some front-end coders are intimidated by the CLI and task runners. Tools like Prepros take the heavy lifting out of your hands, and you can be up an running within a minute. And your images are optimized automatically as well.

All in all, it's just so... convenient.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded