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.

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

    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