Replies: 15 comments 3 replies
-
|
Q: How easy would it be to customize the styling of these Web Components, since they are initially independent of the main USWDS styles? A: Our approach to styling is a work in progress, but will likely involve some combination of CSS custom properties/CSS variables, and named parts. Which parts of components are themeable will be part of the API surface for those components. Some things should be easy to style through a combination of custom variables and plain CSS declarations in an external stylesheet wherever the component provides hooks to support that customization. If there are accessibility or compliance reasons for limiting customization of some aspect of a component’s appearance, then we may make the decision to constrain styling there. |
Beta Was this translation helpful? Give feedback.
-
|
Q: What does the usa-banner.js do? Is there a reason that logic isn’t encapsulated inside the Web Component? A: The usa-banner.js defines that logic for the browser. It's the definition of the custom element. The Eleventy step just copies the JavaScript out of the Node module and into active assets. |
Beta Was this translation helpful? Give feedback.
-
|
Q: Does Eleventy not support linking directly to a file in node modules? Instead of having to copy? A: You could probably use Eleventy to point to node_modules, but it's also probably not a best practice. Eleventy is just a static site generator. You don’t typically ship your entire node_modules directly along with a built static site. Rather, you just copy whatever assets the built version will need. |
Beta Was this translation helpful? Give feedback.
-
Thanks for capturing this, and hopefully outside of chat I can expand a bit more. From the call I understood that Vite was also in use for this? Guess just trying to understand how 11ty and Vite are being used, since Vite has a bundler, and so should allow something like this, right? <html>
<head>
<script type="module" src="/node_modules/@uswds/path/to/usa-component.js></script>
</head>
<body>
<usa-component></usa-component>
</body>
<html>
This is what I meant as an alternative to having to manually copying out of node_modules and in fact, manually copying seems more error prone than letting the bundler walk the graph of imports, since it can also tree shake and handle dead code elimination to further prune things before shipping and would ultimately be less susceptible to shipping something unnecessary. Perhaps I'm just not super familiar on the workflow but ideally a bundler would be in the mix somewhere to help produce production ready bundles, which should also be accessible for development workflows too. |
Beta Was this translation helpful? Give feedback.
-
|
Q: Do you have an idea of how sites will migrate from “standard USWDS” to Web Components USWDS? A: Web Components and standard USWDS will be separate packages in npm. They can be run simultaneously on a site. Teams might begin to replace certain types of components/functionality a little bit at a time. We expect to support both methods at the same time. |
Beta Was this translation helpful? Give feedback.
-
|
Good to know, in case wrapping these web components in React becomes more work than its worth. |
Beta Was this translation helpful? Give feedback.
-
|
Q: Are the images located in a separate cdn? What happens if that cdn is down? Is there a fallback built in? A: Nothing is in a CDN now. If we ever did anything like that, it'd have some real redundancy needs. When there are CDN-hosted versions of components, we expect them to be used as a convenient way to get a site started quickly and with minimal tooling, but naturally any site that loads critical assets from a third party will need to have a plan for what happens in the event that the third-party service is unavailable. As such, CDN-hosted components may not be the best long-term solution for every team. |
Beta Was this translation helpful? Give feedback.
-
|
Q: Have you considered mapping your current design tokens to global CSS variables to use instead of the hardcoded fallbacks? A: Yes. Hard-coded fallbacks were the quick and dirty way to get something shipped. |
Beta Was this translation helpful? Give feedback.
-
|
Q: Curious if you've explored or thought about progressive enhancement. For example, what you're doing with the current combobox, where if the JS doesn't load, a <select> element is used instead? A: Yes. We are definitely thinking about that — trying to get a sense of what resilience means and what kinds of tools we'll deliver in no- and pre-JS environments. We do think of no-JS/JS-failures as edge cases, but ones we take seriously and will dig into. |
Beta Was this translation helpful? Give feedback.
-
|
Q: Will the CSS variables match existing design tokens? For example, instead of hot pink, which is an HTML color code, will there be a secondary-vivid variable? A: Yes, we will be reimplementing USWDS tokens as CSS variables. There should be pretty close to 1:1 correspondence between existing design tokens and future CSS variables. |
Beta Was this translation helpful? Give feedback.
-
|
Is this being completed for both the existing USWDS components and the new Web Components? |
Beta Was this translation helpful? Give feedback.
-
|
Q: Will the component-level accessibility tests be applicable to Web Components too? A: The tests should be useful for any implementation of components, Web-based or otherwise. The tests are meant to prompt teams to test using manual testing prompts, which fall outside of coded tests. |
Beta Was this translation helpful? Give feedback.
-
|
Q: How have you found interacting with browser resets (if any) with Web Components? One of the things that turned me off of them was not being able to globally apply CSS resets. A: When we’ve needed to reset user-agent styles in the components we have developed so far, we have included those styles with the component. As we develop more components, we will have to figure out the best way to share styles between components and the extent to which user-agent styles help or hinder incorporating components into full pages or applications. |
Beta Was this translation helpful? Give feedback.
-
|
Q: Any concerns with doing all the CSS in JS files? Constructable Stylesheets could possibly help https://web.dev/articles/css-module-scripts. A: Our approach to styling is very much a work in progress, so importing CSS in this way is very much still a possibility as we get further along in development. Styling Web Components presents a whole host of new challenges, and finding a way to solve those challenges while preserving as much of the style from existing versions of the components is part of what the team is working on in this early exploratory phase. We haven’t determined the best approach yet. |
Beta Was this translation helpful? Give feedback.
-
|
Q: We’re using the Google Translate language picker on our site. Would it conflict with the Web Component’s language attribute setting? A: This is an area we’re still in early stages of exploring. We want to follow best practices for multilingual components. Google Translate in browsers changes the lang attribute and translates strings inside of markup. It shouldn’t conflict. We should also note that using Google Translate alone is not a translation best practice. |
Beta Was this translation helpful? Give feedback.
-
|
Q: So because you are going the CSS variables/custom properties route, is there a larger plan to switch USWDS from being Sass-variable based to being entirely defined by CSS properties? A: We are planning to migrate away from Sass/SCSS towards a native CSS-based implementation of our styles and design tokens. CSS variables/custom properties work very well with Web Components so the current moment is a good opportunity to make that transition. Native CSS will be a big part of the USWDS theming story going forward, as will shadow parts. In general, one of the engineering principles that is guiding the team in our current efforts is to embrace the platform, and leveraging CSS more directly is a great example of that in practice. Moving away from Sass will also cut down on tooling overhead. |
Beta Was this translation helpful? Give feedback.
-
|
Q: What is the maturity of the Web Components of USWDS and would there be a seamless integration with these Web Components with React? A: The components we have developed so far are at about an alpha level of maturity. We expect to release beta versions of the first few components before the fall, and then to continue releasing other components on a rolling basis. We will be looking closely at how the components we develop interoperate with other frameworks—this will include React, but also Angular, Vue, and other Web Component-based frameworks like Stencil. Our goal is to support popular frameworks and libraries, and we are currently in the process of evaluating how each of these works with Web Components as-is, and which will need some kind of wrapper to support interoperability. We are also keeping an eye on the work frameworks are doing to support Web Components. React 19 aims to fully support native Web Components, so we are cautiously optimistic that the industry is headed towards better interoperability with web standard technologies. |
Beta Was this translation helpful? Give feedback.
-
|
Q: Will any of the components use and manipulate their light Dom children, or are you going full on into shadow Dom for these components? A: We haven’t made a decision on this yet, and may vary from component to component. Some components are best implemented in shadow DOM because they are less likely to allow much customization. The banner, for instance, is a component that needs to be fairly consistent across every site on which it appears, so there are practical reasons to insulate it from outside styles, and shadow DOM is a great way to do that. Additionally, since we anticipate agency teams adding Web Component versions of components to sites that are already using earlier versions of USWDS, shadow DOM will help different generations of components to peacefully coexist. That said, we will be exploring possible use cases for light DOM as we get further along in development. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
At the June 2024 monthly call, we shared our progress developing Web Components for the design system. We demoed early working prototypes of a few components and talked about some of the design questions we’re trying to answer through the prototyping process.
Note: These monthly call Q&A recap posts are a new feature here. We’re still experimenting with what works best for these both in the interest of transparency, but also how well they help you. Let us know whether you find them useful — or if you have a better idea. If you don’t see your question from the June call, feel free to discuss further here. Things may have changed since the call, and in those cases we’ve indicated updates with a date.
Questions from the June 2024 monthly call
Beta Was this translation helpful? Give feedback.
All reactions