Replies: 15 comments 3 replies
-
|
Q: Could you talk a little more about the considerations for multiple languages when you are planning Web Components? A: We have a few goals for language support. Our Web Components have the following requirements:
At this time, we don't know how implementation would work. We might allow teams to load their own translations into the component via something like JSON, or to use component slots to add that content. |
Beta Was this translation helpful? Give feedback.
-
|
Q: Will there be a public Web Components repo soon? Do you want contributors? A: Our goal is to deliver something in an alpha form ASAP. We’ll be publishing a separate Web Components repo for clarity. We absolutely think there’s a role for contributors to help build things out and work through these issues, and we hope that in about a month we'll publish this public repo and one component. Update (5-10-24): We have a new working repo at github.com/uswds/uswds-next |
Beta Was this translation helpful? Give feedback.
-
|
This is an exciting update; the |
Beta Was this translation helpful? Give feedback.
-
|
It's public now! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the prompt to flip the switch |
Beta Was this translation helpful? Give feedback.
-
|
Q: I've been developing Web Components (and integrating them in Drupal) for the last three years. How can I help? A: Contributions are welcome. We’d love to learn more about how you already use Web Components in the real world. Among other things, we’re always interested in how to handle component variants, passing content & data into components, multilingual support, and theming. Share your experience in GitHub discussions or Slack. |
Beta Was this translation helpful? Give feedback.
-
|
Q: Can we customize the alert headers, so that instead of "Error Status," "Info Status," or "Alert status" they state specific errors, information, and alert titles? Our engineers feel they need to use the boilerplate default headers. A: Yes, you can customize. The alert usability guidance recommends providing necessary context in plain language that avoids jargon or unnecessary technical language. |
Beta Was this translation helpful? Give feedback.
-
|
Q: Could you please make a connection between Web Components and digital experience indicators? A: We want a reliable way to understand when sites are using USWDS components, and that could potentially be used in these indicators. Right now, it’s tricky to scan a website and determine whether it’s using something like the USWDS banner since there are a lot of different ways a team could implement it. With the move to Web Components, we hope to make USWDS implementation more consistent, which could make it easier to determine the presence of specific components. |
Beta Was this translation helpful? Give feedback.
-
|
Q: What do you envision for plain language influences? A: The connection between Web Components and plain language is a bit indirect. The design system won’t have a lot of material on plain language. Our goal is to make it easy for teams to add plain language content to any component. Understanding your audience, alongside good writing and structure, is critical to an effective service. We want our components to support effective, plain language writing. There are some components that contain specific, consistent language, like the Banner. Web Components technology will make it easier for teams to stay up-to-date with any content improvements we make to the banner, and this certainly includes improvements to plain language. |
Beta Was this translation helpful? Give feedback.
-
|
Q: Does the move to Web Components mean a move towards more flexible components? For instance, the side nav is basically a list component, but it can’t be used as a list component because it’s built to be side navigation. Will a more generic list component be built to fill the role of side nav and the role of menu, and the role of a content feed, etc.? A: Components are created to fill a specific role, and a content feed might merit its own component and role. We recommend keeping components’ code encapsulated and separate from each other. If a generic, easy-to-maintain list component could meet multiple needs, we’d consider it, but we're a little skeptical of building extremely mutable components that parse component attributes to render very different outputs. Our GitHub component proposals discussion board is a great place to talk about this further. |
Beta Was this translation helpful? Give feedback.
-
|
Q: Do you plan to continue to use Sass for CSS processing, or is that up in the air, too? A: Yes, in the short term we will continue to use Sass to style our traditional HTML components. We may also use Sass to power the styling for Web Components, but this is still under discussion. Long-term, we’ll be looking at ways to use more native CSS to reduce our dependence on custom processors. |
Beta Was this translation helpful? Give feedback.
-
|
Q: Will this shift also include JSON design tokens? Have you looked into moving from hex number to OKLCH? A: Yes, JSON design tokens are an important part of the shift to Web Components. We want to support the existing Sass codebase as well as a Web Components implementation that may be better integrated with CSS custom properties (CSS variables). Right now we have no opinion on what color space or model we use for our color output. The important thing for us now is the color's relationship to a specific design token. If there are practical reasons to switch color spaces to something like OKLCH, we'd be interested in that discussion. |
Beta Was this translation helpful? Give feedback.
-
|
Q: What are the options you're looking at for Web Components? A: We looked at native methods and some frameworks very close to native. We’d like to stay flexible and also support teams using other frameworks, like Angular or React. We're looking at Open Web Components library, Lit, and StencilJS. For now, we're spending time with StencilJS because it gives us the opportunity to collaborate with teams who are using Web Components and StencilJS, but this is still an active discussion. |
Beta Was this translation helpful? Give feedback.
-
|
Q: Will Web Components live alongside existing USWDS components? Or will this be a departure? Will I need to convert all my components to Web Components? Will I need to do it all at once? A: We see Web Components existing at the same time as the current Version 3 of USWDS. We won't be switching Web Components on and traditional USWDS off. We expect to develop Web Components in a separate repo and as a separate package. We don’t want to immediately wind down our existing infrastructure that so many teams depend on. We want teams to be able to move to Web Components incrementally, replacing parts over time. You shouldn’t have to choose all one or the other. |
Beta Was this translation helpful? Give feedback.
-
|
Q: Will you be using Shadow DOM? A: Yes, especially for components where we want to minimize required changes for teams like possibly usa-banner and potentially usa-identifier. These core components contain a lot of markup that may not be easy for teams to update and maintain. With this in mind, we’ll need to be careful about any accessibility implications. There's a balancing act here, and we take both maintainability and component resilience seriously. |
Beta Was this translation helpful? Give feedback.
-
|
Q: How does USWDS alert agency and department project teams about specific component updates? A: You’ll find several ways to keep current:
|
Beta Was this translation helpful? Give feedback.
-
|
Q: What will updating look like in this Web Components future? A: In general, our goal is to make it simpler to update from version to version. Just as with the current distribution model, you'd be able to install or update to the latest version of the distribution package via npm. As long as our updates don't affect the component API, updates should be simple and straightforward. And one of the goals of our move to Web Components is to develop simple, reliable component APIs that don't change much. There could be other distribution methods as well. We are starting to investigate what it could mean to deliver the design system via something like a CDN. Simplicity, reliability, performance, predictability, and security are key priorities as we consider possibilities for updating. This is another place where we'd be open to more discussion. |
Beta Was this translation helpful? Give feedback.
-
|
Q: Will the accessibility checklists also work with the Web Components? A: Yes. Web Components will have the same accessibility baseline as our current components. |
Beta Was this translation helpful? Give feedback.
-
At the April 2024 monthly call, USWDS developers talked about Web Components technology: what it is and what it can mean for the design system. We discussed the value of bringing Web Components into the design system and exploring how they can affect all users.
Note: These monthly call Q&A recap posts are still a new feature here. We’re still experimenting with what works best for these in the interest of transparency, but also how well they help you. Let us know if you find them useful — or if you have a better idea. Also, if you don’t see your question about the April call answered, feel free to discuss further here. Keep in mind this covers what we said during call Q&A as well as questions we didn’t have time for, and they’ve been lightly edited, but things may have changed. In those cases, we indicate updates with a date (5-10-24, for example).
Questions from the April 2024 monthly call
Beta Was this translation helpful? Give feedback.
All reactions