forked from amazingphilippe/dynamic-css
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathsmashing.html
4545 lines (3945 loc) · 132 KB
/
smashing.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>Dynamic CSS Masterclass</title>
<link href="https://inspirejs.org/inspire.css" rel="stylesheet" />
<link href="https://inspirejs.org/theme.css" rel="stylesheet" />
<link href="https://projects.verou.me/talks/shared/intro-outro.css" rel="stylesheet" />
<link href="css/prism.css" rel="stylesheet" />
<link href="css/theme.css" rel="stylesheet" />
<link href="css/talk.css" rel="stylesheet" />
<link href="https://projects.verou.me/talks/shared/browser-support.css" rel="stylesheet" />
</head>
<body class="language-css"
data-markdown-elements="details.notes, .md, .takeaway.slide > h1, .credit"
data-balance-elements=".slide > h1:only-child, .takeaway.slide > h1, .speech.slide > h1"
data-load-plugins="docs">
<header id="intro" class="slide dont-resize">
<h1>Dynamic CSS Masterclass</h1>
<h2>Days 1-5</h2>
<p class="attribution">By <a href="http://lea.verou.me">Lea Verou</a> (<a href="http://twitter.com/leaverou">@LeaVerou</a>)</p>
</header>
<article class="slide" id="preprocessors" data-steps="1">
<h1>Variables in <span class="swap" style="--content: 'Sass'; --content-1: 'Less'"></span></h1>
<pre><code style="--content: '$'; --content-1: '@'">
<span class="swap"></span>accent-color: #f06;
<span class="swap"></span>heading-font: Fancy Webfont, serif;
h2 {
color: <span class="swap"></span>accent-color;
font-family: <span class="swap"></span>heading-font;
}
</code></pre>
<details class="notes">
You may come from a Sass or Less background, where variables are used like this…
</details>
</article>
<article class="slide" id="preprocessors-scope">
<h1>So many refactor to this…</h1>
<pre><code style="--content: '$'; --content-1: '@'">
:root {
--accent-color: #f06;
--heading-font: Fancy Webfont, serif;
}
h2 {
color: var(--accent-color);
font-family: var(--heading-font);
}
</code></pre>
<div class="note delayed">but CSS variables can do so much more!</div>
<details class="notes">
So people often migrate to CSS variables by just changing syntax.
And it works, for the most part.
But it's like hiring a Michelin star chef to fry eggs.
CSS Custom properties can do so much more!
</details>
</article>
<article class="slide">
<h1>What CSS variables <em>can’t do</em></h1>
<table>
<thead>
<tr>
<th></th>
<th>Valid Sass code</th>
<th>Invalid CSS code</th>
</tr>
</thead>
<tbody class="delayed-children">
<tr>
<th>Property names</th>
<td>
<pre><code class="language-scss">
$prop: margin-top;
#{$prop}: 10px;
</code></pre>
</td>
<td>
<pre><code>
--prop: margin-top;
var(--prop): 10px;
</code></pre>
</td>
</tr>
<tr>
<th>Selectors</th>
<td>
<pre><code class="language-scss">
$i: 1;
.foo-#{$i} {
...
}
</code></pre>
</td>
<td>
<pre><code>
:root { --i: 1; }
.foo-var(--i) {
...
}
</code></pre>
</td>
</tr>
<tr>
<th>@rules</th>
<td>
<pre><code class="language-scss">
$w: 500px;
@media (min-width: #{$w}) {
...
}
</code></pre>
</td>
<td>
<pre><code>
:root { --w: 500px; }
@media (min-width: var(--w)) {
...
}
</code></pre>
</td>
</tr>
</tbody>
</table>
<details class="notes">
This entire workshop will go in depth about how CSS variables are
more powerful than preprocessor variables.
So it's only fair that before we start we briefly discuss what they *can't* do.
</details>
</article>
<article class="isolated demo slide" id="cut-corner" style="--division: 65">
<textarea class="language-css">
.cut-corner {
padding: 1em;
clip-path: polygon(
calc(100% - var(--corner-size)) 0,
100% var(--corner-size),
100% 100%, 0 100%, 0 0
);
}
#a {
background: hotpink;
--corner-size: 1em;
}
#b {
background: skyblue;
--corner-size: 10px;
}
</textarea>
<textarea class="language-html">
<p class="cut-corner" id="a">CSS is awesome</p>
<p class="cut-corner" id="b">CSS is awesome</p>
</textarea>
<details class="notes">
CSS variables are scoped on elements, not curly bracket blocks,
taking full advantage of the browser’s DOM structure knowledge.
This means that we can set them and use them in entirely unrelated parts of
our CSS, and things just work beautifully.
Take a look at this example. How would you do it in Sass?
Try setting the corner size via an inline style.
That is definitely something you can't do with preprocessors!
You could also use any unit you want, even viewport units!
-------
*(We revisit this slide after discussing fallbacks)*
Note that these cutout corners can only be 45 degrees, we cannot have
different horizontal and vertical offsets.
How can we change this example so that we can also use
`--corner-size-x` and `--corner-size-y` (either both or just one)?
Does this work like a shorthand? If not, what's the difference?
</details>
</article>
<article class="takeaway slide">
<h1 class="no-md">
Sass variables are scoped on <em><code>{…}</code> blocks</em>,
CSS variables are scoped on <em>elements</em>
<div class="note">(lexical vs dynamic scope)</div>
</h1>
</article>
<article class="confused slide">
<h1 class="balance-lines">
<q>I thought we weren’t supposed to call them CSS variables?</q>
</h1>
<details class="notes bottom-right">
* Short answer: *it doesn't matter, use whatever term you want*
* [The spec itself](https://drafts.csswg.org/css-variables/) uses both.
* Yes, they are custom properties, but they can be used as reactive variables too.
Certain use cases naturally make more sense with one or the other term, others work with both.
* I will be using both terms throughout this workshop.
* Some people have suggested using the term "custom property" when setting (`--foo: ...`)
and "CSS variable" when getting (`var(--foo)`).
Feel free to adopt this if it resonates with you. Or don't. *It doesn't actually matter.*
</details>
</article>
<section>
<header class="slide" id="inheritance-header" style="--icon: 💸; background-color: var(--accent2)">
<h1>Inheritance</h1>
</header>
<article class="isolated demo slide" id="inheritance" style="--division: 55">
<textarea class="language-css">
:root {
--primary-color: hsl(250 30% 40%);
--secondary-color: hsl(190 40% 40%);
}
h1 {
color: var(--primary-color);
}
article {
background: var(--primary-color);
}
article h2 {
background: var(--primary-color);
color: white;
}
article .content {
background: hsl(0 0% 100% / .8);
}
</textarea>
<!--
article.alt {
--primary-color: var(--secondary-color);
}
-->
<style class="demo" data-slide media="not all">
body {
font-size: 100%;
line-height: 1.5;
}
article {
border-radius: .3rem;
overflow: hidden;
margin: 1em 0;
}
article h2 {
padding: .3rem .5rem;
margin: 0;
}
article .content {
padding: .1em .5rem;
}
</style>
<textarea class="language-html">
<h1>Lea Verou's blog</h1>
<article>
<h2>Blog Post 1</h2>
<div class="content">
<p>Blog post 1 content</p>
</div>
</article>
<article class="alt">
<h2>Blog Post 2</h2>
<div class="content">
<p>Blog post 2 content</p>
</div>
</article>
</textarea>
<details class="notes">
The browser is aware of our DOM structure, and custom properties inherit by default.
Here we have defined our properties on the `:root` selector,
but they are available on every other element.
But even better, we can *override* variables on individual elements
and it's the more specific value that inherits down.
Let's make any blog post with the `.alt` class use the secondary color instead.
------
One of the major ways we take advantage of this inheritance is media queries.
We can only overide a few variables in the media query and have all our styles adjust
instead of rewriting a bunch of rules.
Let's see how this works in practice with a dark mode version of this website.
------
Remember the clumsy dark mode we used here? Let's improve it!
</details>
</article>
<article class="takeaway slide">
<h1>CSS Variables are actually <br>
<span class="delayed collapsed">inherited</span> CSS properties</h1>
</article>
<article class="slide" data-insert="#inheritance"></article>
<article class="question slide">
<h1>What if we don’t want inheritance?</h1>
</article>
<article class="isolated demo slide" id="cut-corner">
<textarea class="language-css">
* {
clip-path: polygon(
calc(100% - var(--corner-size)) 0,
100% var(--corner-size),
100% 100%, 0 100%, 0 0
);
}
p {
padding: 1em;
background: skyblue;
--corner-size: 1em;
}
</textarea>
<textarea class="language-html">
<p>CSS is <mark>awesome</mark></p>
</textarea>
<details class="notes">
Sometimes inheritance is not desirable.
One common pattern for using custom properties more as properties
is to use them on very liberal selectors, e.g. `input` or even `*`
and then specify them only when we want to trigger the corresponding effect.
Often, these effects should not be inherited.
One way to disable inheritance is to just make sure the property always has a non-inherited value.
`initial` is perfect for that: it resets the property to its initial value,
as if it had not been set at all, but still prevents it from inheriting.
We can always opt-in inheritance on a case-by-case basis by using the `inherit` keyword.
</details>
</article>
<article class="takeaway slide">
<h1>
You can disable inheritance by setting the property to `initial` on `*`
</h1>
</article>
<article class="isolated demo slide" id="cut-corner">
<textarea class="language-css">
@property --corner-size {
syntax: "*";
inherits: false;
}
* {
clip-path: polygon(
calc(100% - var(--corner-size)) 0,
100% var(--corner-size),
100% 100%, 0 100%, 0 0
);
}
p {
padding: 1em;
background: skyblue;
--corner-size: 1em;
}
</textarea>
<textarea class="language-html">
<p>CSS is <mark>awesome</mark></p>
</textarea>
<details class="notes">
There is a newer, more explicit way to disable inheritance: the <code class="css">@property</code> rule.
It makes custom properties tremendously more powerful, and we will keep revisiting it
throughout this workshop.
</details>
</article>
<article class="takeaway slide">
<h1>`@property` allows us to register our properties and control how they behave</h1>
</article>
<article class="slide">
<h1>Remember this?</h1>
<pre><code class="language-javascript">
CSS.registerProperty({
name: "--corner-size",
syntax: "*";
inherits: false
})
</code></pre>
<details class="notes">
Registering custom properties, started as a JS API,
and we got the declarative `@property` rule later.
</details>
</article>
<article class="browser-support slide">
<table>
<thead>
<tr>
<th></th>
<th><img src="img/chrome-logo.svg" alt="Chrome"></th>
<th><img src="img/firefox-logo.svg" alt="Firefox"></th>
<th><img src="img/edge-logo.svg" alt="Edge"></th>
<th><img src="img/safari-logo.png" alt="Safari"></th>
</tr>
</thead>
<tbody>
<tr>
<th><a href="https://caniuse.com/mdn-css_at-rules_property">@property</a></th>
<td>85</td>
<td></td>
<td>85</td>
<td></td>
</tr>
<tr>
<th><a href="https://caniuse.com/mdn-api_css_registerproperty">CSS.registerProperty()</a></th>
<td>79</td>
<td></td>
<td>79</td>
<td></td>
</tr>
</tbody>
</table>
<details class="notes">
However, today there is only a very marginal benefit to using the JS API,
as it's supported by the same browsers,
it just shipped in a slightly older version compared to `@property`.
Given that most users of these browsers have updated to a version that supports `@property`
at this point, you would only be getting a small increase in support,
for a significant increase in maintainability cost.
Also, Safari has [hinted](https://github.com/w3c/css-houdini-drafts/issues/940)
that they may implement `@property` *first* due to its improved performance.
</details>
</article>
<article class="isolated demo slide" style="--division: 60">
<textarea class="language-css">
input[type=range] {
-webkit-appearance: none;
}
input[type=range]::-webkit-slider-runnable-track {
background: linear-gradient(to right, white, black);
height: 1em;
}
input[type=range]::-moz-range-track {
background: linear-gradient(to right, white, black);
height: 1em;
}
input[type=range]::-webkit-slider-thumb {
width: .5em; height: 1em;
-webkit-appearance: none;
border-radius: 2px;
border: 1px solid black;
box-shadow: 0 0 0 1px white;
}
input[type=range]::-moz-range-thumb {
width: .5em; height: 1em;
border-radius: 2px;
border: 1px solid black;
box-shadow: 0 0 0 1px white;
}
</textarea>
<textarea class="language-html">
<input type="range">
</textarea>
<style data-slide media="not all" class="demo">
html {
padding: 1em;
}
input[type=range] {
transform: scale(2);
transform-origin: 0 0;
width: 50%;
margin-bottom: 1em;
}
</style>
<details class="notes">
Sometimes, we have to get our hands dirty,
and use vendor prefixed pseudo-classes and pseudo-elements.
This is especially common when we need to style native elements.
Even if not ideal, it's still better for accessibility
than replicating the native elements with divs and JS.
Custom properties inherit down Shadow DOM boundaries
so they can help us contain the ugliness in one place.
Let's define a `--track-background` property that we can set
on the `<input>` itself, instead of having to use
pseudo-elements like `::-webkit-slider-runnable-track` and `::-moz-range-track` 🤢
This applies to both built-in components as well as Web Components.
</details>
</article>
<article class="takeaway slide">
<h1>
Custom properties inherit down Shadow DOM boundaries
<div class="note">(just like any inheritable property)</div>
</h1>
<details class="notes">
Unlike other inheritable properties however,
custom properties cannot be reset by `all: initial`.
</details>
</article>
</section>
<section id="fallbacks">
<header class="slide" style="--icon: 🧗🏽; background-color: var(--accent1)">
<h1>Fallbacks</h1>
</header>
<article class="isolated demo slide" id="gallery" style="--division: 55">
<textarea class="language-css">
img {
--size: 20vw;
width: var(--size);
height: var(--size);
object-fit: cover;
transform: scale(var(--scale))
rotate(var(--rotate));
transition: .3s;
}
img:hover {
background: yellow;
}
</textarea>
<style class="demo" data-slide media="not all">
img {
margin: .3em;
padding: .2em;
background: white;
box-shadow: 0 .05em .1em rgb(0 0 0 / .1);
}
</style>
<textarea class="language-html">
<img src="img/cat1.jpg" alt="">
<img src="img/cat2.jpg" alt="">
<img src="img/cat3.jpg" alt="">
<img src="img/cat4.jpg" alt="">
<img src="img/cat5.jpg" alt="">
<img src="img/cat6.jpg" alt="">
<img src="img/cat7.jpg" alt="">
<img src="img/cat8.jpg" alt="">
<img src="img/cat9.jpg" alt="">
<img src="img/cat10.jpg" alt="">
</textarea>
<!-- TODO translate to show it can have two tokens -->
<details class="notes">
* Often, we use custom properties as optional styling hooks that may or may not be used.
This allows us to create a sort of *"styling API"* for us or even other developers.
* In these cases, we want to provide default values along,
so that people using our code do not need to set every single property.
* Here, we are using `--rotate` and `--scale` properties to allow specifying
transforms individually on these images
(aside: there are [actual standardized properties for this, but support is still limited](https://developer.mozilla.org/en-US/docs/Web/CSS/rotate)).
* Let's try to apply subtle rotations to some images ([Cicada principle](https://lea.verou.me/2020/07/the-cicada-principle-revisited-with-css-variables/))
and also enlarge them slightly on `:hover`.
* Notice that for our transforms to be applied, both need to be set,
defeating the purpose of using a custom property. What to do?
* We *could* set `--scale` and `--rotate` on `img` as well, and it would fix the demo,
but is not ideal because:
- it breaks inheritance
- in "real life" cases where our selectors are not as simple as `img` it forces our API consumers to battle specificity
* Thankfully, the `var()` function allows for a fallback parameter too, which is perfect for this.
* Unlike just setting variables to values, the fallback parameter also allows us to provide
different fallbacks per usage, **for the same custom property**
</details>
</article>
<article class="question slide">
<h1>How do these fallbacks actually work?</h1>
</article>
<article class="slide color-reveal">
<div class="delayed-children">
<br>
<div style="background: yellowgreen">--accent-color: yellowgreen</div>
<br>
<div style="background: orange">No --accent-color set</div>
<br>
<div style="background: red">No CSS variables support</div>
</div>
<pre style="margin-top: 2em; overflow: visible"><code>
background: red;
background: var(--accent-color, orange);
</code></pre>
</article>
<article class="takeaway slide">
<h1>The `var()` fallback is no help in browsers that don’t support CSS variables</h1>
</article>
<article class="browser-support slide">
<table>
<thead>
<tr>
<th></th>
<th><img src="img/chrome-logo.svg" alt="Chrome"></th>
<th><img src="img/firefox-logo.svg" alt="Firefox"></th>
<th><img src="img/edge-logo.svg" alt="Edge"></th>
<th><img src="img/safari-logo.png" alt="Safari"></th>
</tr>
</thead>
<tbody>
<tr>
<th><a href="https://caniuse.com/css-variables" target="_blank">CSS Variables</a></th>
<td>49</td>
<td>31</td>
<td>15</td>
<td>9.1</td>
</tr>
</tbody>
</table>
</article>
<article class="isolated demo slide" id="atsupports" style="--division: 50">
<textarea class="language-css">
body {
background: red;
}
@supports (--css: variables) {
body {
background: green;
}
}
</textarea>
<details class="notes">
For most cases, providing fallbacks via the cascade
works fine to provide a baseline accessible experience to the
few browsers that still don’t support custom properties.
However, if you need a more elaborate fallback, you can use the
[`@supports`](https://developer.mozilla.org/en-US/docs/Web/CSS/@supports)
rule. Any custom property and any value will do as the test.
When do you need a more elaborate fallback?
Typically when you need to control more properties and/or rules than the ones with
the `var()` reference.
Avoid using its negative form (`@supports not (--css: variables)`),
as that will prevent you from targeting the really old browsers (notably, IE 11 or under)
that don’t even support `@supports`.
----------
Can we use `@supports` to detect `@property` support? Let's try.
</details>
</article>
<article class="slide takeaway">
<h1>Use `@supports` to provide more elaborate fallback styling</h1>
</article>
<article class="browser-support slide">
<table>
<thead>
<tr>
<th></th>
<th><img src="img/chrome-logo.svg" alt="Chrome"></th>
<th><img src="img/firefox-logo.svg" alt="Firefox"></th>
<th><img src="img/edge-logo.svg" alt="Edge"></th>
<th><img src="img/safari-logo.png" alt="Safari"></th>
</tr>
</thead>
<tbody>
<tr>
<th>CSS Variables</th>
<td>49</td>
<td>31</td>
<td>15</td>
<td>9.1</td>
</tr>
<tr>
<th><a href="https://caniuse.com/css-featurequeries">@supports</a></th>
<td>28</td>
<td>22</td>
<td>13</td>
<td>9</td>
</tr>
</tbody>
</table>
</article>
<article class="slide takeaway">
<h1>Avoid using `@supports not` for a single test</h1>
<details class="notes">
Why? It only applies what's inside to browsers that
both support `@supports` **and** don't support the thing you're testing.
`not` can be useful in conjunciton with positive tests,
but when you're just testing if a given feature is supported,
go with a positive test and progressive enhancement.
</details>
</article>
<article class="slide" data-insert="#atsupports"></article>
<article class="slide takeaway">
<h1>There is currently no way to use `@supports` to detect `@property` support</h1>
</article>
<article class="slide">
<h1 class="balance-lines">How can we detect <code>@property</code> then?</h1>
<pre><code class="language-javascript">
if (window.CSSPropertyRule) {
let root = document.documentElement;
root.classList.add("supports-atproperty");
}
</code></pre>
</article>
<article class="slide color-reveal">
<div class="delayed-children">
<br>
<div style="background: orange">--accent-color: initial</div>
<br>
<div style="background: orange">--accent-color: unset</div>
<br>
<div style="background: orange">--accent-color: inherit</div>
<br>
<div style="background: orange">--accent-color: revert</div>
</div>
<pre style="margin-top: 2em; overflow: visible"><code>
background: red;
background: var(--accent-color, orange);
</code></pre>
</article>
<article class="question slide">
<h1>Do all CSS wide keywords trigger a variable’s fallback?!</h1>
</article>
<article class="demo slide reveal" data-steps="1">
<textarea class="language-css preserve-selectors">
:root {
--accent-color: skyblue;
}
.slide {
/* --accent-color: inherit; */
background: var(--accent-color, orange);
}
</textarea>
<details class="notes css">
No, not all global CSS values simply trigger a variable's fallback.
* `initial` does, by definition
* `inherit` does not, unless there's no value to inherit
* `unset` in custom properties behaves identically to `inherit`
(unless they are defined as non-inheriting).
* `revert` reverts the custom property to its UA provided value,
which is ...`unset`.
* Surprised by the result of `revert`?
[You're not alone](https://twitter.com/LeaVerou/status/1395379573190168576)!
</details>
</article>
<article class="takeaway slide">
<h1>Out of all CSS wide keywords, only `initial` actually triggers the fallback
<div class="note">(and anything that resolves to it)</div>
</h1>
</article>
<article class="slide" id="multiple-default-values" data-steps="1">
<h1>Multiple fallbacks?</h1>
<div>
<pre><code>background: var(--nonexistent, none, yellowgreen);</code></pre>
<pre><code>
/* Resolves to: */
background: none, yellowgreen;
</code></pre>
</div>
<details class="notes">
Anything after the comma is part of the fallback, including …other commas.
</details>
</article>
<article class="slide dont-resize" id="daisy-chain" data-source="Image source: https://www.flickr.com/photos/26235325@N05/5641177399">
<pre><code>
var(--color1<span class="delayed">, var(--color2<span class="delayed">, var(--color3<span class="delayed" style="--length: 5">, gray</span>)</span>)</span>)
</code></pre>
<details class="notes">
A variable’s fallback can be another variable reference,
allowing us to have interactive defaults that can depend on other values.
</details>
</article>
<article class="slide" data-insert="#cut-corner"></article>
<article class="takeaway slide">
<h1>
Default values allow us to create “shorthands” of sorts
<div class="note">(but careful, they’re not real shorthands!)</div>
</h1>
</article>
<article class="isolated demo slide" id="button">
<textarea class="language-html">
<button>Click me</button>
<button class="pink">Click me</button>
</textarea>
<textarea class="language-css">
button {
border: .1em solid black;
background: transparent;
color: black;
}
button:hover {
background: black;
color: white;
}
button.pink {
border-color: #f06;
color: #f06;
}
button.pink:hover {
background: #f06;
color: white;
}
</textarea>
<style class="demo" data-slide media="not all">
button {
border-radius: .3em;
padding: .1em .5em .15em;
font-weight: bold;
font-size: 180%;
margin: .2em;
cursor: pointer;
}
</style>
<details class="notes">
This is a simplified flat button whose text color becomes its background color on hover, a common effect.
Note the repetition required to specify a color variation. Let's use CSS variables to eliminate that!
After rewriting with CSS variables, only a single `--color` declaration is sufficient to create a color variation of the entire component.
However, the fallbacks are getting quite repetitive.
Although the syntax allows us to use a different fallback in every usage,
in most cases, we don't need that.
Repeating the fallback value over and over is not [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).
What can we do to reduce that duplication?
-----------
Another benefit of custom properties is *encapsulation*.
We can change how styling works completely, and as long as we use the same custom properties
anyone using and styling our component doesn't need to change a thing.
</details>
</article>
<article class="takeaway slide">
<h1><abbr title="Don’t Repeat Yourself">DRY</abbr> fallback strategies</h1>
<ol>
<li>
Fallback in a variable
<pre><code>
--color-initial: black;
...
color: var(--color, var(--color-initial));
</code></pre>
</li>
<li>
Pseudo-private properties
<pre><code>
--__color: var(--color, black);
...
color: var(--__color);
</code></pre>
</li>
</ol>
<details class="notes">
The first way allows you to use the same property internally
that you expose to other people, but it makes each usage far more verbose.
The second way is more concise, but it suffers from the wart that
you have to use a different property internally than the one you expose
and it's only private by convention.
</details>
</article>
<article class="takeaway slide">
<h1><abbr title="Don’t Repeat Yourself">DRY</abbr> fallback with `@property`</h1>
<pre><code>
@property --color {
syntax: "<color>";
initial-value: black;
inherits: true;
}
...
color: var(--color);
</code></pre>
<details class="notes">
In most cases, `@property offers a far better solution,
with the main drawback being its browser support.
However, do note that the other approaches
allow for different defaults per element,
whereas an `@property` rule is global.
</details>
</article>
<article class="isolated demo slide" id="migraine" style="--division: 55">
<textarea class="language-css">
article {
/* To-do: Make color depend on intensity */
--color: hsl(0 70% 40%);
background: var(--color);
}
article h2 {
color: white;
}
article .content {
background: hsl(0 0% 100% / .8);
}
</textarea>
<style class="demo" data-slide media="not all">
body {
font-size: 100%;
line-height: 1.5;
}
article {
border-radius: .3rem;
overflow: hidden;
margin: 1em 0;
}
article h2 {
padding: .3rem .5rem;
margin: 0;
}
article .content {
padding: .1em .5rem;
}
</style>
<textarea class="language-html">
<h1>🤕 Migraine log</h1>
<article style="--intensity:1">
<h2>
<time datetime="2021-05-19T20:45">May 19th, 2021 at 20:45</time>
until <time datetime="2021-05-20T01:15">01:15</time>
<meter max="5" value="2"></meter>
</h2>
<div class="content">
<p>Started after dinner</p>
</div>
</article>
<article style="--intensity:3">
<h2>
<time datetime="2021-05-18T10:50">May 18th, 2021 at 10:50</time>
until <time datetime="2021-05-18T15:15">15:15</time>
<meter max="5" value="4"></meter>
</h2>
<div class="content">
<p>Upon waking up</p>
</div>
</article>
<article style="--intensity:;">
<h2>
<time datetime="2021-05-16T15:00">May 16th, 2021 at 15:00</time>
until <time datetime="2021-05-16T20:00">20:00</time>
<meter max="5"></meter>
</h2>