Upgrade to Pro — share decks privately, control downloads, hide ads and more …

We’re All Writing Our Own Web Standards Now

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.

Dac45089aeda3bca56193072601a49d4?s=128

Jason Grigsby

April 05, 2022
Tweet

More Decks by Jason Grigsby

Other Decks in Technology

Transcript

  1. We’re All Writing Our Own Web Standards Now Jason Grigsby

    • @grigs • Cloud Four • cloudfour.com
  2. None
  3. 2013 First design system

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

    to large retailers
  5. None
  6. None
  7. None
  8. None
  9. None
  10. None
  11. Speed Quality Cost

  12. Speed Quality Cost

  13. None
  14. None
  15. None
  16. Web components

  17. None
  18. ?

  19. None
  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

  25. None
  26. None
  27. <c4-modal title-text="Title">Content</c4-modal>

  28. None
  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.
  31. None
  32. None
  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

  46. None
  47. None
  48. None
  49. None
  50. None
  51. None
  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">

  57. None
  58. None
  59. HTML API Design

  60. Why should designers care about HTML API design?

  61. None
  62. None
  63. None
  64. None
  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
  67. None
  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?

  70. None
  71. API Design Across Languages Prefer simple solutions Name things thoughtfully

    Consistency Consider security and privacy Re-use attribute names for similar functionality
  72. None
  73. None
  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

  76. None
  77. None
  78. None
  79. None
  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
  81. None
  82. None
  83. None
  84. None
  85. Other factors to consider when designing component APIs

  86. None
  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
  89. None
  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!
  103. None
  104. None
  105. None
  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"/>

  109. None
  110. <c4-modal title-text="Title">Content</c4-modal>

  111. Just make sure you adjust your project schedules accordingly

  112. Getting our priorities straight

  113. None
  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.
  116. None
  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!
  122. None