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
   

   View Slide

2. View Slide

3. 2013
   First design system
   

   View Slide

4. Since then, we've worked on:
   22
   Design systems From hospitals… to large retailers
   

   View Slide

5. View Slide

6. View Slide

7. View Slide

8. View Slide

9. View Slide

10. View Slide

11. Speed Quality Cost
    

    View Slide

12. Speed Quality Cost
    

    View Slide

13. View Slide

14. View Slide

15. View Slide

16. Web components
    

    View Slide

17. View Slide

18. ?
    

    View Slide

19. View Slide

20. What is a web component?
    

    View Slide

21. Define our own custom HTML elements
    I'm a c4-button!
    

    View Slide

22. 
    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!
    
    

    View Slide

23. Custom Elements
    Shadow DOM
    HTML Template
    create new HTML elements
    encapsulates style and markup
    defines fragments of markup for later use
    

    View Slide

24. This design system was
    much easier to integrate
    

    View Slide

25. View Slide

26. View Slide

27. Content
    

    View Slide

28. View Slide

29. 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!
    

    View Slide

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.
    

    View Slide

31. View Slide

32. View Slide

33. Input field in a component-based design system
    
    
    
    
    Markup
    Rendered result
    

    View Slide

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.
    

    View Slide

35. 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.
    

    View Slide

36. 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.
    

    View Slide

37. 
    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
    

    View Slide

38. 
    How do we give the input an id?
    Markup
    
    
    
    Rendered result
    We need the id on the
    input element hidden
    inside of the component.
    

    View Slide

39. Maybe we add a custom input attribute
    Label Text
    
    id="example"/>
    Label Text
    Markup
    Rendered result
    value="hello"/>
    input-id="example"
    
    

    View Slide

40. Maybe we add a custom input attribute
    Label Text
    
    id="example"/>
    Label Text
    Markup
    Rendered result
    value="hello"/>
    input-id="example"
    
    Is this easier to integrate?
    

    View Slide

41. Why not add an attribute for the label?
    
    
    
    id="c4-input-{unique_id}"/>
    Markup
    Rendered result
    
    Label text
    
    

    View Slide

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
    

    View Slide

43. That's how you go from…
    

    View Slide

44. 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!
    

    View Slide

45. to
    

    View Slide

46. View Slide

47. View Slide

48. View Slide

49. View Slide

50. View Slide

51. View Slide

52. 
    
    

    View Slide

53. 
    background-image: image-set(
    url("small-balloons.jpg") 1x,
    url("large-balloon.jpg") 2x
    )
    @media (min-resolution: 2dppx) {
    ...
    }
    

    View Slide

54. 
    
    

    View Slide

55. Design System
    Team
    Custom Elements
    or Components
    Design System
    Documentation
    

    View Slide

56. 
    
    

    View Slide

57. View Slide

58. View Slide

59. HTML API Design
    

    View Slide

60. Why should designers care about
    HTML API design?
    

    View Slide

61. View Slide

62. View Slide

63. View Slide

64. View Slide

65. Shared vocabulary across tools is valuable
    https://medium.com/eightshapes-llc/cra ing-ui-component-api-together-81946d140371
    

    View Slide

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
    

    View Slide

67. View Slide

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.
    

    View Slide

69. What can we learn from web
    standards organizations?
    

    View Slide

70. View Slide

71. API Design Across Languages
    Prefer simple solutions
    Name things thoughtfully
    Consistency
    Consider security and privacy
    Re-use attribute names for similar
    functionality
    

    View Slide

72. View Slide

73. View Slide

74. Naming principles
    Use common words
    Use ASCII names
    Future proofing
    Consistency
    Consultation
    • Please consult widely
    • Use web consistent language
    • Use inclusive language
    

    View Slide

75. Standards developed in isolation
    o en fail to gain adoption
    

    View Slide

76. View Slide

77. View Slide

78. View Slide

79. View Slide

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
    

    View Slide

81. View Slide

82. View Slide

83. View Slide

84. View Slide

85. Other factors to consider when
    designing component APIs
    

    View Slide

86. View Slide

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
    

    View Slide

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
    

    View Slide

89. View Slide

90. 
    #Shadow Root
    Label text
    
    id="c4-input-{unique_id}"/>
    
    Support styling via ::part
    part="label">
    

    View Slide

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;
    }
    

    View Slide

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
    

    View Slide

93. Make impossible states impossible
    https://kentcdodds.com/blog/make-impossible-states-impossible
    FYI
    Error!
    It worked!
    FYI
    Error!
    It worked!
    

    View Slide

94. Make impossible states impossible
    https://kentcdodds.com/blog/make-impossible-states-impossible
    FYI
    Error!
    It worked!
    FYI
    Error!
    It worked!
    It worked!
    

    View Slide

95. Make impossible states impossible
    https://kentcdodds.com/blog/make-impossible-states-impossible
    It worked!
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

100. This feels like more work
     

     View Slide

101. It is more work
     

     View Slide

102. 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!
     

     View Slide

103. View Slide

104. View Slide

105. View Slide

106. But it’s worth it
     

     View Slide

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.
     

     View Slide

108. What consumers need to do to integrate…
     
     

     View Slide

109. View Slide

110. Content
     

     View Slide

111. Just make sure you adjust your
     project schedules accordingly
     

     View Slide

112. Getting our priorities straight
     

     View Slide

113. View Slide

114. 1.1 Put user needs first
     

     View Slide

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.
     

     View Slide

116. View Slide

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
     

     View Slide

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.
     

     View Slide

119. Thank You!
     

     View Slide

120. Thanks to these fabulous people who graciously shared their work under Creative Commons.
     Thank You!
     

     View Slide

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!
     

     View Slide

122. View Slide