OT: css variables, (custom properties)

[pziecina]

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

}

[BenPleysier]

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.

[pziecina]

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.

[BenPleysier]

As I have repeatedly stated, Sass/Less doesn’t force you to write all your CSS in a completely new way. In fact, every (vanilla) .css file is automatically a valid .scss file. You are then free to use—or ignore—the features of Sass at your own pace. The advantage is a ready to use CSS document.

[pziecina]

BenPleysier  wrote

As I have repeatedly stated, Sass/Less doesn’t force you to write all your CSS in a completely new way. In fact, every (vanilla) .css file is automatically a valid .scss file. You are then free to use—or ignore—the features of Sass at your own pace. The advantage is a ready to use CSS document.

Then why use sass/less?

[BenPleysier]

Functions (mixins) and variables.

[pziecina]

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)

[BenPleysier]

This is a mixin

.box-shadow(@x: 0, @y: 0, @blur: 1px, @color: #000) {
  box-shadow: @arguments;
  -moz-box-shadow: @arguments;
  -webkit-box-shadow: @arguments;
}

This is its usage

.myBox {
    .box-shadow(2px, 5px);
}


This is the compiled version

.mybox {
    box-shadow: 2px 5px 1px #000;
    -moz-box-shadow: 2px 5px 1px #000;
    -webkit-box-shadow: 2px 5px 1px #000;
}


How on earth can that be done with DW snippets?

[pziecina]

You can create the snippet using the css that would be the result of the compiled version.

OR

You can create your snippet using the mixin, replacing the sass variables with css variable names.

The usage would be a simple selection whilst writing the css to include the snippet. This could be done by a code hint, right click menu option, and I am sure people can think of other ways to insert snippets, without having to 'go-to' the snippets panel.

[BenPleysier]

This is one of my real examples:

The mixin, where the colours have been defined a variables partial

@mixin pretty-buttons($color, $background, $text-shadow: none) {
  color: $color;
  @include gradient-vertical(lighten($background, 5%), darken($background, 15%), 0%, 100%);
  border-color: darken($background, 10%);
  border-bottom-color: darken($background, 20%);
  text-shadow: $text-shadow;
  @include box-shadow(inset 0 1px 0 rgba(255, 255, 255, .1));
  &:hover,
  &:focus,
  &:active,
  &.active {
  @include gradient-vertical(lighten($background, 20%), lighten($background, 0%), 0%, 100%);
  border-color: darken($background, 20%);
  color: $color;
  }
  &.disabled,
  &[disabled],
  fieldset[disabled] & {
  &,
  &:hover,
  &:focus,
  &:active,
  &.active {
  background-color: $background;
  border-color: darken($background, 5%);
  }
  }
}

These are the button styles that I have used

.btn {
  &.btn-default {
    @include pretty-buttons($btn-default-color, $btn-default-bg);
  }
  &.btn-manila {
    @include pretty-buttons(#000000, #F3EAA7);
  }
  &.btn-primary {
    @include pretty-buttons($btn-primary-color, $btn-primary-bg);
  }
  &.btn-success {
    @include pretty-buttons($btn-success-color, $btn-success-bg);
  }
  &.btn-info {
    @include pretty-buttons($btn-info-color, $btn-info-bg);
  }
  &.btn-warning {
    @include pretty-buttons($btn-warning-color, $btn-warning-bg);
  }
  &.btn-danger {
    @include pretty-buttons($btn-danger-color, $btn-danger-bg);
  }
  &.btn-inverse {
    @include pretty-buttons(white, #474949);
  }
  &.btn-guide {
    @include pretty-buttons($brand-primary, #B9F2D6);
  }
  &.btn-video {
    @include pretty-buttons($brand-primary, #D6B9F2);
  }
  &.btn-activity {
    @include pretty-buttons($brand-primary, #F2D6B9);
  }
}

and this is the markup for a button

<a href="mylink" class="btn btn-guide" role="button">Go to my link</a>

and this is the result

[pziecina]

Sorry Ben, but you are not showing me anything that cannot be done using Dw's Snippets, css variables and @import.

There is even the css conditional rules such as the @support, and the one everyone is now familiar with @media. Then of course we have -

'will change' from the css module of the same name. The @scope, media-querys level 4, plus the upcoming spec that allows the developer to actually use css that is hidden behind a flag if the so wish.

W3C css is changing, and we can debate what is best to use without any resolution, if you prefer sass, that's O/K, I prefer what I can use from the W3C specs, and that is my choice.

[rayek.elfin]

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

[pziecina]

First I was one of the few that asked for PostCSS inclussion in Dw, so i am fully aware of cssnext.

I disagree that all the items you mention cannot be done using a combination of snippets and css. Yes, snippets would need more thought in how they work, and if done similar to library items could very easily be made to reflect changes.

Macro type coding options are used in other code editors, and are another way of including what Dw calls snippets, so other editors do support the feature, just under different names. As for autoprefixing almost every code editor has an extension available for one, except Dw, which i have been saying for years. Dw's reason for not including one is because they say that one should use sass/less for the feature, pure idiocy in my opinion.

I have used Postcss in the past, but have never found a reason to force the use on others, or say that it makes life easier for everyone. Any coding environment should in my opinion offer tools for the user, but they all should ensure that what is part of the W3C specs is supported, and not do as Dw currently does, and say other 3rd party tools such as pre/post-precessors should be used instead.

[Rob_Hecker2]

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.

[osgood_]

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.

[pziecina]

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.

[rayek.elfin]

pziecina  wrote

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.

True, good support for upcoming features (with a post-processor fallback) are important to have. And a lot can be achieved with post preprocessing nowadays, which may replace SASS at some point. Some coders have already switched. There are pros and cons.

[Rob_Hecker2]

All my client websites share a single "CSS file" so variables are critical. In the CMS there is a whole separate application that allows clients to define and control their site "theme."

But I can see how someone who creates static websites could have a collection of variables at the top of the file, making it really easy to modify the same CSS file for multiple websites on separate servers. No CMS needed. No database, no pre or post processors. The simplicity alone would make it popular, I suspect.

[osgood_]

https://forums.adobe.com/people/Rob+Hecker2  wrote

But I can see how someone who creates static websites could have a collection of variables at the top of the file, making it really easy to modify the same CSS file for multiple websites on separate servers. No CMS needed. No database, no pre or post processors. The simplicity alone would make it popular, I suspect.

I can see it might be useful on large projects but to me its just as simple to write vanilla css if you create small to medium sized projects. Most of my projects don't have many static pages, most pages are generated from information in a database and share the same fairly simple css file or files.

I could use sass and complicate it just for laughs but I dont see it would be any advantage to me personally and I probably produce sites something akin to 90% of what you see on the internet.

I think you have to weigh up what you do and make a judgement if its worth using on a personal level. Are you just using it because it makes you feel more skilfull rather than providing anything trully worthwhile and useful.

Most of the peripheral stuff is maybe nice to have but excess to essential requirement. I personally prefer to direct any spare time that I have into something which is going to make a real difference to my ability to code more interesting and subtle features into a website.

[pziecina]

Os, correct me if i am wrong, but are you thinking that css variables are variables used in sass/less?

[osgood_]

pziecina  wrote

Os, correct me if i am wrong, but are you thinking that css variables are variables used in sass/less?

No, Im just saying at the moment I cant see myself using either css variables or sass/less. I can't comment much on css variables so it might be that when everything is available to be compiled within the same file I'll see more benefits or a simpler workflow.

All I'm really saying is my css stylesheets are so simple, uncomplicated and not hugley long I don't think they would really benefit from either to the point its going to make a huge difference.

For others, depending on what they do maybe they see the benefits or just use something which really brings nothing to the table, its hard to tell.

Whats more important I feel anyway is an optional stanalone browser prefixer where the majority will benefit rather than css variables/git etc, etc which you can get by without.

[pziecina]

Thanks for explaining, I think it was your use of compiling that confused me, as css varables are not compiled but interpretated by the browsers rendering process.

[pziecina]

https://forums.adobe.com/people/Rob+Hecker2  wrote

All my client websites share a single "CSS file" so variables are critical. In the CMS there is a whole separate application that allows clients to define and control their site "theme."

But I can see how someone who creates static websites could have a collection of variables at the top of the file, making it really easy to modify the same CSS file for multiple websites on separate servers. No CMS needed. No database, no pre or post processors. The simplicity alone would make it popular, I suspect.

css variables also have a javascript api assosiated with them, so it is possible for your users to just change one value, (or many) to create a custom theme.

Edit - just a thought but could a simple change of a css variable via a user action in the browser, change all usages in a sass/less css created file?

[pziecina]

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]

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>

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