Slide 1
Slide 1 text
We’re All Writing Our Own
Web Standards Now
Jason Grigsby • @grigs • Cloud Four • cloudfour.com
Slide 2
Slide 2 text
No content
Slide 3
Slide 3 text
2013
First design system
Slide 4
Slide 4 text
Since then, we've worked on:
22
Design systems From hospitals… to large retailers
Slide 5
Slide 5 text
No content
Slide 6
Slide 6 text
No content
Slide 7
Slide 7 text
No content
Slide 8
Slide 8 text
No content
Slide 9
Slide 9 text
No content
Slide 10
Slide 10 text
No content
Slide 11
Slide 11 text
Speed Quality Cost
Slide 12
Slide 12 text
Speed Quality Cost
Slide 13
Slide 13 text
No content
Slide 14
Slide 14 text
No content
Slide 15
Slide 15 text
No content
Slide 16
Slide 16 text
Web components
Slide 17
Slide 17 text
No content
Slide 18
Slide 18 text
?
Slide 19
Slide 19 text
No content
Slide 20
Slide 20 text
What is a web component?
Slide 21
Slide 21 text
Define our own custom HTML elements
I'm a c4-button!
Slide 22
Slide 22 text
I'm a c4-button!
I'm a secondary c4-button!
I'm a tertiary c4-button!
I'm a disabled c4-button!
I'm actually a link!
Slide 23
Slide 23 text
Custom Elements
Shadow DOM
HTML Template
create new HTML elements
encapsulates style and markup
defines fragments of markup for later use
Slide 24
Slide 24 text
This design system was
much easier to integrate
Slide 25
Slide 25 text
No content
Slide 26
Slide 26 text
No content
Slide 27
Slide 27 text
Content
Slide 28
Slide 28 text
No content
Slide 29
Slide 29 text
Input field in a CSS-based design system
.c4-input {
...
}
Markup
CSS
Documentation
Hey, never use this without using a label element, too!
That's terrible for accessibility!
Slide 30
Slide 30 text
What clients need to do to integrate…
1. Install both the CSS and JavaScript.
2. Copy and paste the markup into their setup or integrate the markup into
their templates.
3. Figure out that accessibility requirement, which would involve creating a
label, giving it content, giving the input element a unique ID, and associating
the label with that form element.
Slide 31
Slide 31 text
No content
Slide 32
Slide 32 text
No content
Slide 33
Slide 33 text
Input field in a component-based design system
Markup
Rendered result
Slide 34
Slide 34 text
What clients need to do to integrate…
1. Install both the CSS and JavaScript.
2. Copy and paste the markup into their setup or integrate the markup into
their templates.
3. Figure out that accessibility requirement, which would involve creating a
label, giving it content, giving the input element a unique ID, and associating
the label with that form element.
Slide 35
Slide 35 text
What clients need to do to integrate…
3. Figure out that accessibility requirement, which would involve creating a
label, giving it content, giving the input element a unique ID, and associating
the label with that form element.
Slide 36
Slide 36 text
What clients need to do to integrate…
3. Figure out that accessibility requirement, which would involve creating a
label, giving it content, giving the input element a unique ID, and associating
the label with that form element.
Slide 37
Slide 37 text
How do we give the input an id?
Markup Our first instinct is to
add the id here.
But that won't work.
Rendered result
Slide 38
Slide 38 text
How do we give the input an id?
Markup
Rendered result
We need the id on the
input element hidden
inside of the component.
Slide 39
Slide 39 text
Maybe we add a custom input attribute
Label Text
Label Text
Markup
Rendered result
value="hello"/>
input-id="example"
Slide 40
Slide 40 text
Maybe we add a custom input attribute
Label Text
Label Text
Markup
Rendered result
value="hello"/>
input-id="example"
Is this easier to integrate?
Slide 41
Slide 41 text
Why not add an attribute for the label?
id="c4-input-{unique_id}"/>
Markup
Rendered result
Label text
Slide 42
Slide 42 text
Same logic applies to many features
Accessibility
Instructional text
Password visibility toggle
Validation states
Text-based a ordances
Better numeric input type
Polite masking
Slide 43
Slide 43 text
That's how you go from…
Slide 44
Slide 44 text
Input field in a CSS-based design system
.c4-input {
...
}
Markup
CSS
Documentation
Hey, never use this without using a label element, too!
That's terrible for accessibility!
Slide 45
Slide 45 text
to
Slide 46
Slide 46 text
No content
Slide 47
Slide 47 text
No content
Slide 48
Slide 48 text
No content
Slide 49
Slide 49 text
No content
Slide 50
Slide 50 text
No content
Slide 51
Slide 51 text
No content
Slide 52
Slide 52 text
Slide 53
Slide 53 text
Slide 54
Slide 54 text
Slide 55
Slide 55 text
Design System
Team
Custom Elements
or Components
Design System
Documentation
Slide 56
Slide 56 text
Slide 57
Slide 57 text
No content
Slide 58
Slide 58 text
No content
Slide 59
Slide 59 text
HTML API Design
Slide 60
Slide 60 text
Why should designers care about
HTML API design?
Slide 61
Slide 61 text
No content
Slide 62
Slide 62 text
No content
Slide 63
Slide 63 text
No content
Slide 64
Slide 64 text
No content
Slide 65
Slide 65 text
Shared vocabulary across tools is valuable
https://medium.com/eightshapes-llc/cra ing-ui-component-api-together-81946d140371
Slide 66
Slide 66 text
Nathan Curtis recommends 3 areas to align
1. Anatomy — the hierarchy of elements
2. Properties — consistent property names, options, and defaults
3. Layout — spacing, breakpoints, size, etc.
https://medium.com/eightshapes-llc/cra ing-ui-component-api-together-81946d140371
Slide 67
Slide 67 text
No content
Slide 68
Slide 68 text
More reasons HTML APIs matter for design
Designers should be concerned about the full behavior of a component.
If developers have to create additional variants, the variants should be
designed instead of created de facto by those coding.
Ideally, components should be easy enough to use that designers might be
able to use them to create small designs or prototypes.
Slide 69
Slide 69 text
What can we learn from web
standards organizations?
Slide 70
Slide 70 text
No content
Slide 71
Slide 71 text
API Design Across Languages
Prefer simple solutions
Name things thoughtfully
Consistency
Consider security and privacy
Re-use attribute names for similar
functionality
Slide 72
Slide 72 text
No content
Slide 73
Slide 73 text
No content
Slide 74
Slide 74 text
Naming principles
Use common words
Use ASCII names
Future proofing
Consistency
Consultation
• Please consult widely
• Use web consistent language
• Use inclusive language
Slide 75
Slide 75 text
Standards developed in isolation
o en fail to gain adoption
Slide 76
Slide 76 text
No content
Slide 77
Slide 77 text
No content
Slide 78
Slide 78 text
No content
Slide 79
Slide 79 text
No content
Slide 80
Slide 80 text
Nathan Curtis recommends API Dra is:
Findable and editable by everyone
Started from a template
Critiqued as a group
Available for asynchronous review
https://medium.com/eightshapes-llc/cra ing-ui-
component-api-together-81946d140371
Slide 81
Slide 81 text
No content
Slide 82
Slide 82 text
No content
Slide 83
Slide 83 text
No content
Slide 84
Slide 84 text
No content
Slide 85
Slide 85 text
Other factors to consider when
designing component APIs
Slide 86
Slide 86 text
No content
Slide 87
Slide 87 text
1. Which variations should be o ered?
What can people customize?
What has to remain the same in
order to maintain consistency?
https://dev.to/eduferfer/design-systems-designing-component-apis-2h94
Slide 88
Slide 88 text
2. Which styles should be customizable?
If the component uses the shadow
DOM, people cannot style it directly.
CSS variables can be used to change
the styles of component.
Ask whether it is a global or
component-level variable.
https://dev.to/eduferfer/design-systems-designing-component-apis-2h94
Slide 89
Slide 89 text
No content
Slide 90
Slide 90 text
#Shadow Root
Support styling via ::part
part="label">
Slide 91
Slide 91 text
c4-input::part(label) {
# Whatever styles apply to underlying element
background: #FFFFFF;
}
Support styling via ::part
c4-input::part(label):hover {
# Pseudo elements and most pseudo classes work
background: #FFFFCC;
}
Slide 92
Slide 92 text
3. How will the component evolve in the future?
Plan for future variations
A boolean property called warning,
solves current dialog need…
But fails when you need to add
other dialogs.
Using type="warning" is future proof
https://dev.to/eduferfer/design-systems-designing-component-apis-2h94
Slide 93
Slide 93 text
Make impossible states impossible
https://kentcdodds.com/blog/make-impossible-states-impossible
FYI
Error!
It worked!
FYI
Error!
It worked!
Slide 94
Slide 94 text
Make impossible states impossible
https://kentcdodds.com/blog/make-impossible-states-impossible
FYI
Error!
It worked!
FYI
Error!
It worked!
It worked!
Slide 95
Slide 95 text
Make impossible states impossible
https://kentcdodds.com/blog/make-impossible-states-impossible
It worked!
Slide 96
Slide 96 text
What parts could be reused?
Smaller components o en have
simpler APIs
Small components can be
combined into larger, more complex
components
4. Which parts can be isolated?
https://dev.to/eduferfer/design-systems-designing-component-apis-2h94
Slide 97
Slide 97 text
Web components allow content to
be inserted into predefined slots
This means you don't have to define
every possible option ahead of time
You just have to decide where
content can be inserted
5. Where can content be inserted?
https://dev.to/eduferfer/design-systems-designing-component-apis-2h94
Slide 98
Slide 98 text
Including the relevant attributes,
elements, and interactivity to make
components accessible by default
Enforcing accessibility between
components by throwing errors if a
component is configured incorrectly
Accessible by default and enforced where possible
Slide 99
Slide 99 text
Accessible by default and enforced where possible
Including the relevant attributes,
elements, and interactivity to make
components accessible by default
Enforcing accessibility between
components by throwing errors if a
component is configured incorrectly
Slide 100
Slide 100 text
This feels like more work
Slide 101
Slide 101 text
It is more work
Slide 102
Slide 102 text
Input field in a CSS-based design system
.c4-input {
...
}
Markup
CSS
Documentation
Hey, never use this without using a label element, too!
That's terrible for accessibility!
Slide 103
Slide 103 text
No content
Slide 104
Slide 104 text
No content
Slide 105
Slide 105 text
No content
Slide 106
Slide 106 text
But it’s worth it
Slide 107
Slide 107 text
What consumers need to do to integrate…
1. Install both the CSS and JavaScript.
2. Copy and paste the markup into their setup or integrate the markup into
their templates.
3. Figure out that accessibility requirement, which would involve creating a
label, giving it content, giving the input element a unique ID, and associating
the label with that form element.
Slide 108
Slide 108 text
What consumers need to do to integrate…
Slide 109
Slide 109 text
No content
Slide 110
Slide 110 text
Content
Slide 111
Slide 111 text
Just make sure you adjust your
project schedules accordingly
Slide 112
Slide 112 text
Getting our priorities straight
Slide 113
Slide 113 text
No content
Slide 114
Slide 114 text
1.1 Put user needs first
Slide 115
Slide 115 text
Priority of constituencies
User needs come before the needs of web page authors,
which come before the needs of user agent implementors,
which come before the needs of specification writers,
which come before theoretical purity.
Slide 116
Slide 116 text
No content
Slide 117
Slide 117 text
How would this apply to design systems?
Users
Authors
User Agent Implementors
Specification Writers
Theoretical Purity
Users
Component Consumers
Component Developers
Design System Team
Theoretical Purity
Slide 118
Slide 118 text
User needs come before the needs of component consumers,
which come before the needs of component developers,
which come before the needs of the design system team,
which come before theoretical purity.
Slide 119
Slide 119 text
Thank You!
Slide 120
Slide 120 text
Thanks to these fabulous people who graciously shared their work under Creative Commons.
Thank You!
Slide 121
Slide 121 text
Styling in the Shadow DOM With CSS Shadow Parts by Ollie Williams
Design System UI is More Expensive Than a Product Team’s UI by Nathan Curtis
Guidelines for creating web platform compatible components by W3C TAG
Web Components Best Practices by WebComponents.org
Special thanks to:
Nathan Curtis and Eduardo Ferreira for their insightful articles.
My colleagues at Cloud Four for helping refine my talk outline and ideas. In particular, this talk
wouldn’t have been possible without Tyler Sticka and Paul Hebert’s assistance.
And most of all, our clients who entrust us to work on their design systems with them. Without
these opportunities, we wouldn’t have anything to share in articles or in presentations like this.
Thank You!
Slide 122
Slide 122 text
No content