CSS variables support

I am adding support of CSS variables. In Sciter this is pretty much about the same feature set as defined in CSS Variables Working Draft but with slightly different syntax:

Declaration of the variable:

body {
   var(foo): #f00;       /* declaring variable with name "foo" 
                            having color value */
   color: var(foo,#000); /* using the variable */

Variables are inheritable so everything inside <body> can use that variable:

div {
   background-color: var(foo,#00f);

Note that variable usage contains two pieces: name of the variable and default value that will be used when variable is not defined.

DOM API in script will also get methods to get/set variables in runtime:

$(body).style.variables { 
    foo: color(0,255,0) 

After that all elements that use the variable in their styles will get new color.

@mixin feature in Sciter’s CSS

I am adding @mixin construct to Sciter’s CSS.

The mixin is a named set of CSS properties that can be applied by name to CSS rules. The feature is similar SASS’s mixins (but no parameters yet)

Consider this declaration:

    @mixin LIKE-BUTTON 
      background: linear-gradient(top, #3498db, #2980b9);
      border-radius: 28dip;
      color: #ffffff;
      font-size: 20dip;
      padding: 10dip 20dip 10dip 20dip;
      text-decoration: none;

It declares LIKE-BUTTON block of properties that can be mixed into style rules by LIKE-BUTTON name (prepended by ‘@’)

    div { 

    a { 

CSS: vw/vh/vmin/vmax units are quite dangerous

Consider the following markup:

<section style="width:min-content">
  <div style="width:10vh">

Note that the div has width equal to 10% of window’s height.

That looks quite simple but introduces quite unpleasant problem.

HTML/CSS layout task consists of two major steps:

  1. Layout width -> will give us min/max widths and content height, quite expensive as almost always it is O(N) complex.
  2. Do layout height as a final step. That’s essentially quite cheap vertical alignment operation and only where it is needed.

When you change height of the window (but not width) you can skip step 1 completely.  Even while changing width many elements will keep their min/max widths intact. That allows to save CPU cycles quite a lot.

But width:10vh is a game changer here – it ruins such optimizations completely. Even when changing only height of the view you shall do full relayout 🙁 The same applies to vmin/vmax units.

Use vh/vmin/vmax units responsibly.