Making Future Interfaces: Custom Properties

The first thing you’ll notice about CSS
custom properties, or VARs if you hate syllables, is their weird-ass syntax. This
syntax was chosen because all of the normal syntax was already taken by older
CSS features. Custom properties are all set and reset or overridden using a – –
prefix — not to be confused with the Linus Linus prefix. You get a custom property’s
current value by wrapping its name in the VAR function. Don’t worry, unlike in
JavaScript the minuses do not mean the value will decrease each time the
property is invoked. It’s not a decrementer. Tthe second thing you’ll notice is
that custom properties are scoped to selectors. In this case, my actionColor
custom property has a global scope because I’ve attached it to the root
element. In webpages, root is the HTML element and it can also be targeted with
the HTML element selector. One thing having two names is a bit confusing but
that’s CSS for you. Custom properties really are global if you wants them to be. They even pass through shadow Dom boundaries like it ain’t no thing. In
this example I’m applying the action color custom property value to a
background color property inside my custom element’s shadow root, which is a
lot of jargon for just one sentence. If you want, you can set all your custom
properties globally or if you’re feeling confident you can harness the Cascade
(the C in CSS) to create localized exceptions. For example, I can override
the global action color value specifically for nav elements.
Automatically, any links inside nav elements will now adopt the local value.
I think we can agree this is more elegant than maintaining multiple
global custom properties for each case like blah blah blah blah blah blah.
Wicked good but what is the actual benefit of custom properties. It all has
to do with the Don’t Repeat Yourself Or Do It’s More
Than Once Principle — the DRI principle for short. With custom properties you can
set values in one place and simply propagates them around your application.
Better still, unlike the boring old static variables you get with the
preprocessors Sass and Less, custom properties change; they’re mutable. By
calling setProperty on the route element (documents.documentElement
in JavaScript) I can change the value globally. Everywhere I get and use a
property’s value the change can be immediately seen. This is great, but don’t
get carried away. Be aware that not all property values need custom properties
to be centrally managed. CSS inheritance means properties like font-family can
already be set at the root and will be adopted automatically by most element
types. The @media block in this example changes the root font-family for narrow
viewports. Paragraphs are affected without additional intervention. Elements
like inputs that don’t tend to inherit can be forced to do so using the inherit
keyword. By using custom properties with the CSS calc() function, you can even create
fake boolean values — or Foolians as everyone tells me not to call them. Since
something x 1 is something and something x 0 is nothing, we can use 1 for true and
0 to mean false. In this example, I’ve set two different border sizes and a borderOn property to toggle both border types on or off simultaneously. We might want
to expose borders as an option to users since borders may help some users to
better perceive and understand the layout of the interface. A simple
checkbox will suffice for the HTML. Javascript listens to the change event
to toggle the borderOn property between 1 and 0. Use native semantic elements for
controls wherever you can. It’s more efficient and more accessible than
creating custom controls for nonsense

s and bespoke JavaScript that doesn’t
need to be there because all it’s doing is emulating the most basic of browser
behaviors and states. So far our custom properties are not typed: that is, they
can accept any value we give them even if it doesn’t make
sence. This could, without warning, result in nonsense declarations like max-width:
2.5, line-height: blue, or position: 33.33%. This is where
the CSS Typed Object Model comes in. I like to call it
CSS Tom for short. Using registerProperty in JavaScript we can use the
Properties & Values API to supply an expected syntax, and an initial value. If
a new value parses successfully as a color — which could be a color name, a hex,
an HSL a function etc etc — then no problem. If it does not, then it’ll be
thrown out and the old value will remain. Unlike JavaScript itself, CSS doesn’t
just blow up when something goes a bit wrong. If you’re like me, you’ll not be
impressed by having this JavaScript all up in your CSS’s business. Fortunately,
at the time of writing, a declarative CSS based version of this registerProperty
example is being specified. The future of typing for CSS custom properties will
hopefully look something like this. In the present, you can see that the
weird-ass syntax has completely baffled my syntax highlighter Architects your experiment

13 Replies to “Making Future Interfaces: Custom Properties”

  1. Wow. I'm just getting to intermediate skill level with CSS and this is some seriously helpful information to help push my skills and understanding to the next level. Your videos are densely packed with information, and that's not a bad thing at all. I learned so much from this. Gonna have to probably re-watch it and take notes. 👍

Leave a Reply

Your email address will not be published. Required fields are marked *