We’re All Writing Our Own Web Standards Now

Design systems built on vanilla HTML and CSS can adhere closer to the “atomic” portion of Atomic Design, but when you move to a design system built on components—whether web components or JavaScript frameworks components like React—the smallest pieces of a design system become more complex. That evolution is inevitable, and the payoffs are significant, but the move to components means new challenges for the teams that maintain design systems. Now teams are defining their own HTML elements and associated attributes.

How an HTML element should work used to be a question left to the web's standard-setting bodies. Now it's a cross-disciplinary discussion about what components should or should not do, and how to support that behavior. For better or worse, we're all in the standards business now. In this session, Jason will teach you the questions you need to ask, how to plan for future use, and how your project schedules may change when you move from css-based to component-based design systems.

Transcript

1. We’re All Writing Our Own Web Standards Now Jason Grigsby • @grigs • Cloud Four • cloudfour.com
3. 2013 First design system
4. Since then, we've worked on: 22 Design systems From hospitals… to large retailers
11. Speed Quality Cost
12. Speed Quality Cost
16. Web components
18. ?
20. What is a web component?
21. Define our own custom HTML elements <c4-button>I'm a c4-button!</c4-button>
22. <c4-button> I'm a c4-button! </c4-button> <c4-button button-class="secondary"> I'm a secondary c4-button! </c4-button> <c4-button button-class="tertiary"> I'm a tertiary c4-button! </c4-button> <c4-button disabled="true"> I'm a disabled c4-button! </c4-button> <c4-button tag="a"> I'm actually a link! </c4-button>
23. Custom Elements Shadow DOM HTML Template create new HTML elements encapsulates style and markup defines fragments of markup for later use
24. This design system was much easier to integrate
27. <c4-modal title-text="Title">Content</c4-modal>
29. Input field in a CSS-based design system <input class="c4-input" type="text" value="hello"/> .c4-input { ... } Markup CSS Documentation Hey, never use this without using a label element, too! That's terrible for accessibility!
30. 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.
33. Input field in a component-based design system <c4-input value="hello"/> <c4-input value="hello"> <input type="text" value="hello"/> </c4-input> Markup Rendered result
34. 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.
35. What clients need to do to integrate… <c4-input value="hello"/> 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.
36. What clients need to do to integrate… <c4-input value="hello"/> 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.
37. <c4-input value="hello"/> How do we give the input an id? Markup Our first instinct is to add the id here. But that won't work. <c4-input value="hello"> <input class="c4-input" type="text" value="hello"/> </c4-input> Rendered result
38. <c4-input value="hello"/> How do we give the input an id? Markup <c4-input value="hello"> <input class="c4-input" type="text" value="hello"/> </c4-input> Rendered result We need the id on the input element hidden inside of the component.
39. Maybe we add a custom input attribute <label for="example">Label Text</label> <c4-input value="hello"> <input class="c4-input" type="text" value="hello" id="example"/> <c4-input <label for="example">Label Text</label> Markup Rendered result value="hello"/> input-id="example" </c4-input>
40. Maybe we add a custom input attribute <label for="example">Label Text</label> <c4-input value="hello"> <input class="c4-input" type="text" value="hello" id="example"/> <c4-input <label for="example">Label Text</label> Markup Rendered result value="hello"/> input-id="example" </c4-input> Is this easier to integrate?
41. Why not add an attribute for the label? <c4-input label="Label text" value="hello"> <c4-input label="Label text" value="hello"/> <input class="c4-input" type="text" value="hello" </c4-input> id="c4-input-{unique_id}"/> Markup Rendered result <label for="c4-input-{unique-id}"> Label text </label>
42. Same logic applies to many features Accessibility Instructional text Password visibility toggle Validation states Text-based a ordances Better numeric input type Polite masking
43. That's how you go from…
44. Input field in a CSS-based design system <input class="c4-input" type="text" value="hello"/> .c4-input { ... } Markup CSS Documentation Hey, never use this without using a label element, too! That's terrible for accessibility!
45. to
52. <mark> <marquee>
53. <img srcset="small-balloons.jpg 1x, large-balloons.jpg 2x"> background-image: image-set( url("small-balloons.jpg") 1x, url("large-balloon.jpg") 2x ) @media (min-resolution: 2dppx) { ... }
54. <mark> <marquee>
55. Design System Team Custom Elements or Components Design System Documentation
56. <our-banner fitted> <our-buybox padding="small">
59. HTML API Design
60. Why should designers care about HTML API design?
65. Shared vocabulary across tools is valuable https://medium.com/eightshapes-llc/cra ing-ui-component-api-together-81946d140371
66. 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
68. 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.
69. What can we learn from web standards organizations?
71. API Design Across Languages Prefer simple solutions Name things thoughtfully Consistency Consider security and privacy Re-use attribute names for similar functionality
74. Naming principles Use common words Use ASCII names Future proofing Consistency Consultation • Please consult widely • Use web consistent language • Use inclusive language
75. Standards developed in isolation o en fail to gain adoption
80. 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
85. Other factors to consider when designing component APIs
87. 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
88. 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
90. <c4-input label="Label text" value="hello"> #Shadow Root <label for="c4-input-{unique-id}" Label text </label> <input class="c4-input" type="text" value="hello" id="c4-input-{unique_id}"/> </c4-input> Support styling via ::part part="label">
91. 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; }
92. 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
93. Make impossible states impossible https://kentcdodds.com/blog/make-impossible-states-impossible <c4-alert warning>FYI</c4-alert> <c4-alert error />Error!</c4-alert> <c4-alert success />It worked!</c4-alert> FYI Error! It worked!
94. Make impossible states impossible https://kentcdodds.com/blog/make-impossible-states-impossible <c4-alert warning>FYI</c4-alert> <c4-alert error />Error!</c4-alert> <c4-alert success />It worked!</c4-alert> FYI Error! It worked! <c4-alert success warning>It worked!</c4-alert>
95. Make impossible states impossible https://kentcdodds.com/blog/make-impossible-states-impossible <c4-alert type="success">It worked!</c4-alert>
96. 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
97. 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
98. 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
99. 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
100. This feels like more work
101. It is more work
102. Input field in a CSS-based design system <input class="c4-input" type="text" value="hello"/> .c4-input { ... } Markup CSS Documentation Hey, never use this without using a label element, too! That's terrible for accessibility!
106. But it’s worth it
107. 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.
108. What consumers need to do to integrate… <c4-input value="hello"/>
110. <c4-modal title-text="Title">Content</c4-modal>
111. Just make sure you adjust your project schedules accordingly
112. Getting our priorities straight
114. 1.1 Put user needs first
115. 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.
117. 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
118. 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.
119. Thank You!
120. Thanks to these fabulous people who graciously shared their work under Creative Commons. Thank You!
121. 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!