Besides CSS variables, what are custom CSS properties used for?

From the CSS post working group:

Custom properties are used not only for variables [...]

Contradictory to what many people think (see this ), this message not only confirms that variables and user properties are not the same thing, but these user properties can be used for things other than variables.

My question is about the last part. Has anyone ever come across some kind of CSS code where custom properties were used for something other than variables?

+5
source share
3 answers

Note that the context of the text you are quoting is CSSWG, justifying why --foo and var(--foo) are used instead of $foo . I assume that their statement, “Custom properties are used not only for variables”, means that the syntax of the --foo syntax --foo set in other places used for other custom things, such as custom media queries that were originally in MQ4 and now are in MQ5. Clearly, these are not cascading variables, because media queries are not cascaded ( their nested rules do ). (Although, if so, Custom Properties should have been something else, but most likely the CSSWG was not thinking of a proper collective name for these things.)

Has anyone ever come across some kind of CSS code where custom properties were used for something other than variables?

I have not come across real-world examples, but I just hit an example that uses JavaScript to switch the class to an element based on a custom property, which in turn affects the selector elsewhere in CSS:

 let p = document.querySelector('p'); if (window.getComputedStyle(document.documentElement).getPropertyValue('--boolean').trim() === "'true'") p.classList.add('toggle'); else p.classList.remove('toggle'); 
 :root { --boolean: 'true'; } p.toggle { color: #f00; } p::before { content: 'Value of --boolean is "' var(--boolean) '"'; } 
 <p> 

The caveat, of course, is that it is CSS and JavaScript. You cannot use custom properties only for cascading variables only in CSS, because custom properties are cascaded like any other CSS property, and do not exist outside it, which is why authors combine the two terms in everyday use - because there are any differences between they are academic. Any other part of the stylesheet that wants to depend on a custom property must work with a script to use it.

You might be wondering why something like this cannot be implemented in CSS. Consider:

 p.toggle { --boolean: 'false'; } 

If we proposed a pseudo-class for matching elements based on their CSS property values, such as p:prop(--boolean: 'true') ,

  • should the pseudo-class be valid and always conform, be valid and never conform or invalid outside CSS?
  • What should be the reflected cost? Indicated value, calculated value or used value? Note that for historical reasons, even window.getComputedStyle() does not always return calculated values.
  • cyclic dependencies become inevitable:

     :root { --boolean: 'true'; } /* * Causes p to stop matching the selector, switching back to * inheriting from :root, which in turn causes it to start * matching the selector again, ad infinitum. */ p:prop(--boolean: 'true') { --boolean: 'false'; } 

Take a close look at the JavaScript example above and you will notice that it is not reliable. The value of a property is evaluated only once, once the document is compiled together. Change the value of the custom property again and the item will not be updated to reflect this change. If he listens to changes in the custom property value, he will immediately encounter the same cyclic dependency problem - and, even worse, block your browser (until he notices and intercepts infinite recursion).

+3
source

The answer of the Qaru answer that you linked is actually not the case, and is talking about something slightly different from what you are asking. It talks about how user properties are often described as variables in the corresponding CSS specification for ease of understanding, even though they differ from how variables work in other languages ​​(but what kind of course for CSS with CSS is this?).

The variable part of custom CSS properties is actually how you invoke (or use) a custom property:

 .example { background: var(--custom-property); } 

As you can see from the specification , fully entitled “Custom CSS Properties for the Level 1 Cascading Variable Module”, there is only one use: it is called as a value in the cascading element with var() . Therefore, it’s a little incomprehensible what the author of this post on the wiki means when they say that user properties are used not only for variables. In addition, subsequent sentences do not actually describe or reserve this application, they simply say that using $ instead of - is "strange".

Perhaps they mean that you can declare a custom property that only works when reading JavaScript? Or declare a custom property in JS, which then applies to CSS. The syntax of custom variables supports equations that would not be correctly read by CSS parsers, but would be correctly read in JavaScript. However, the result remains the property value of the element declared with var() .

And in order to translate the matter into some perspective, it would be pointless to call them custom properties if they used something other than the property. The specification does not mention an alternative way to call or use a property in CSS or JS without using var() in the cascading selector section of the properties (code bit between {} ).

+2
source

Other questions explain custom properties and CSS variables, but what if we make it simple and say that custom properties are just here to allow us to add additional properties in addition to the default default CSS. Of course, the custom property alone is useless, since the browser does nothing with it, and why in 99% of cases they are used with CSS variables.

Another fact is that when we execute CSS, we will intuitively think about using the default CSS properties to do what we want, and when we are faced with a difficult situation, we will try to combine many properties, pseudo-elements, etc. in to meet our needs. But what if we think differently and we start using custom properties for this purpose? What if, instead of complex CSS code, we just write a custom property and implement the JS / jQuery code that will do the job for us.


Take a simple and general example. You have an element that you want to make absolute to use as an overlay of its parent element. With CSS, we will do something like this:

 .block { height:100px; width:100px; margin:20px; border:1px solid red; position:relative; /* we usually forget this !*/ } .overlay { position:absolute; top:0; right:0; left:0; /*sometimes we use width:100% but it won't work with padding!*/ bottom:0; padding:5px; z-index:1; /* we can forget this sometimes*/ background:rgba(0,0,0,0.5); } 
 <div class="block"> <span class="overlay"></span> some text here </div> 

This is pretty easy, and we can use the same class everywhere if we want to have the same thing. But we can consider a custom property that will reduce CSS code and simplify it:

 $('*').each(function() { if ($.trim($(this).css('--overlay')) === "top") { $(this).css({ 'position': 'absolute', 'top': 0, 'bottom': 0, 'left': 0, 'right': 0, 'z-index':2 }); $(this).parent().css('position','relative'); } else { //we test the other values and we do the necessary changes } }) 
 .block { height: 100px; width: 100px; margin: 20px; border: 1px solid red; } .overlay { --overlay: top; background: rgba(0, 0, 0, 0.5); } 
 <script src="https://code.jquery.com/jquery-3.3.1.min.js"></script> <div class="block"> <span class="overlay"></span> some text here </div> 

I know the first thought: "Why use all this code for such a simple thing that we can do with CSS?" and "What if the property changes? What if the parent has an already established position?" This is true, but it is a very simplified example. Imagine you are creating a JS or jQuery library where you provide many custom properties for complex products (create common CSS forms, perform complex transformations where it is difficult to calculate values, etc.), and you provide documentation for each of them with its own corresponding values.

This is similar to the JS / jQuery library, in which you are invited to add a class to your element and call one function, and then you have a responsive slider, an interactive map, a Twitter widget, etc. Why not do the same with custom properties? We ask people to turn on the library and just write CSS and then see the magic.


We can also see this as an update, adding more useful features to make things easier. Just like the creators of CSS, BUT we do it on our own and don’t wait until a new specification appears and is approved.

Take the flexbox example. Before flexbox, if we want to have N div numbers inside a container with the same size and fill the entire container, we are required to write complex code that we have to configure every time we add a new element. Now with flexbox we just install flex:1 and that! The browser will do everything complicated for us.

We can do the same. We create our custom properties to simplify the work, and we will share it with the community. People will start using them and may find them useful, then they can become a reference to common problems. Perhaps some browser will even think about an implementation for their integration.

Thus, custom properties can also contribute to the extension of CSS.

+2
source

Source: https://habr.com/ru/post/1275927/


All Articles