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
  2. ?

  3. <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>
  4. Custom Elements Shadow DOM HTML Template create new HTML elements

    encapsulates style and markup defines fragments of markup for later use
  5. 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!
  6. 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.
  7. 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
  8. 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.
  9. 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.
  10. 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.
  11. <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
  12. <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.
  13. 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>
  14. 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?
  15. 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>
  16. Same logic applies to many features Accessibility Instructional text Password

    visibility toggle Validation states Text-based a ordances Better numeric input type Polite masking
  17. 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!
  18. to

  19. 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
  20. 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.
  21. API Design Across Languages Prefer simple solutions Name things thoughtfully

    Consistency Consider security and privacy Re-use attribute names for similar functionality
  22. Naming principles Use common words Use ASCII names Future proofing

    Consistency Consultation • Please consult widely • Use web consistent language • Use inclusive language
  23. 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
  24. 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
  25. 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
  26. <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">
  27. 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; }
  28. 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
  29. 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>
  30. 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
  31. 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
  32. 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
  33. 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
  34. 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!
  35. 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.
  36. 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.
  37. 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
  38. 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.
  39. 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!