Meeting minutes
westbrook: we've been working for about a years a community of framework authors and developers looking to understand the needs of web components developers and users. We've been meeting every couple of weeks and we're publishing a report summarizing what we've learned.
owen: want to open a channel of communication around what we've learned over the past year; in particular, want to highlight the cross-cutting concerns.
westbrook:
For late joiners:
Draft report: https://
CG Repo: https://
CG Slack Invite: https://
Community Protocol work: https://
owen: as westbrook mentioned, we're library, tooling, and website authors that have a mix of interests. Looking into things the community is using, and taking information from github issues to understand the nature of the specs in order to figure out opporunities to work around or suggest improvements
owen: when issues are embedded in the browser and hard to work around, trying to reflect the reality of where the technology is in order to make the most impact. Suggests are designed to unlock the most impact across other features as well. Hoping to show thematic issues.
owen: e.g., being able to expose certain features like selection, cross-component interfaces, etc.
owen: also looking at the way Shadow DOM has been JS-only, and looking at server-side rendering gaps
owen: we feel like there are great opportunities to close the gaps, building on a lot of interest and development based on Web Components
owen: the latest Chromestatus.com status show 17% of pages using Custom Elements and 10% using Shadow DOM
westbrook: want to talk about the top 6 most critical areas highlighted in the report
alan: I work for Line and I'm here to talk about Form Associated Custom Elements. This spec enables the ability for web components to participate in forms, including for accessiblity.
alan: this is fully implemented in Chrome today, with a partial implementation in Firefox in progress.
alan: one of the most common use-cases for custom elements today is the construction of custom form components
alan: there are fallbacks, for example the `formdata` event, but this doesn't cover every use-case and is error-prone
alangdm: the other option is to piggy back on a hidden form element, which breaks many things (e.g. `<label>`, etc.)
alangdm: this has caused many developers to avoid WC for their form elements, or forces them to construct full form systems to cover these use-cases (e.g., LION). These are painful and error prone
westbrook: the second issue is ARIA, which uses ID references. These don't work across shadow roots. We found 3 or 4 alternatives, but none of them are fully implemented.
westbrook: it's important to the web development community at large to find a solution to this situation.
westbrook: finding a solution in the near future is to avoid pushing people away from Shadow DOM. We'd like to be able to partner with implementers to solve these issues
(see: https://
westbrook: the next important area is Constructable Style Sheets; Justin is going to speak to that
(see: https://
<technical difficulties>
westbrook: while these APIs have some implementation, particularly in Chromium, the ability for custom stylesheets to add styles to shadow roots without creating new DOM objects has a measure performance impact
westbrook: CSS module scripts also depend on constructable style sheets
westbrook: this API not getting over the finishing line is blocking other APIs from being discussed seriously
westbrook: there is an implementation in Chromium, and there's excitement about it, but issues around Adopted Style Sheets (assignments vs. observable array) have prevented us from reaching full agreement on this API
dclark: talking about Constructable Style Sheets and CSS modules, we hear that authors would like to put their CSS in a CSS file or reference it
dclark: CSS module scripts allow developers to use the familiar style syntax and are integrated with teh JS module infrastructure, they have the same load order gaurantees, preventing flashes of unstyled content. They're implemented in Chromium but not other engines yet.
westbrook: the #5 issue we found was related to scoped element registries
westbrook: as more sites and pages are registering more custom elements, more of them are doing it on the same page. This creates the potential for conflicts over the same element name being potentially re-registered by multiple parties
westbrook: as pages/apps start to scale up, seeing conflicts betwen components or different versions of the same component can cause issues
westbrook: being able to connect registries directly on shadow roots would allow us to avoid conflicts
westbrook: when we get into projects that are distributed -- e.g., microfrontends -- we're starting to see the occurance of multiple registrations for the same name. Scoped registries will open the ability for solving this challenge
westbrook: encapsulation is also provided by scoped element registries. Helps developers ensure that developers are not creating side-effects outside their shadow DOMs
westbrook: there are number of polyfills, but they have performance issues, and require global control/visiblity which makes it hard to adopt
westbrook: the 6th and final issue is declarative shadow DOM
(see: https://
owen: declarative shadow DOM is the ability to declare shadow dom without the execution of JS
owen: our goal in advocating for this is to broaden the uses of web components outside of JS-only or JS-supported environments
owen: there has been interest in SSR with web components before, but it has involved pulling in infrastructure like puppeteer or another JS-supported runtime
owen: we'd like to see movement on this to see an HTML-first story for web components that can make delivering web components a bit more seamless for developers that have started off developing and delivering HTML
owen: this will also let server-side systems output HTML and "hydrate" from existing DOM rather than replacing it
owen: this will save initialization work for components
owen: depending less on JS-enabled environments relies on a spec that browsers can understand
owen: Chromium has experimental support and a polyfill for this todasy
scribe interrupt: this is shipped in Chromium-based browsers: https://
westbrook: we believe these 6 features are the most criticasl features for implementers to look at now and in the near future
westbrook: in the coming weeks we'll be rounding out the draft to identify future areas for focus
westbrook: we're looking for better ways to share developer priorities, and would like to identify ways to improve bi-directional sharing of priorities. Implementer priorities are important to understand and well
westbrook: with that, let's stop the recording and open teh floor for discussion
westbrook: if anyone was in disagreement about the importance of these priorities, that would be great to know
richard lea: I work for Rakuten. I'm interested in how the work and discussion on systems like Web Components, templates, etc. are covered by discussion in this group. Is this the correct forum to discuss them?
westbrook: yes, we're looking to help developers understand the priorities across this whole area
richard: is there a document that outlines these issues?
<yes>
https://
owen: you'll see the six items we discussed listed in the table of contents there, as well as others
owen: we are addressing issues in all these areas, with links to github discussions outward from there
owen: we felt these 6 give us the biggest impact
owen: we're open to discussing specifications in all of these areas
richard: I'm wondering if there's an expectation on existing component frameworks like Angular and React...understanding how they overlap...is the goal of web components to cover interop for this?
slightlyoff: yes <outlines history to use DOM>
see also: https://
(discussion of the costs and processes for interop)
travis: the AOM group has been looking at cross-root ARIA, with work on searching into and out of shadow roots
westbrook: the potential designs that are linked from the report are very promising; let's make sure any progress is represented in our document
westbrook: one of our sub-goals is, not just to make implementers aware of what we think is important, also looking for ways to increase the communication between web developers and implementers
westbrook: does anyone have thoughts on how to expand and grow the relationships there?
<discussion of that>
westbrook: any thoughts of how we can get a better understanding of the priorities of implementers in this area?
westbrook: often we hear "we might work on this in the future" and not "we are working on..."
travis: I'm smiling because that's the golden question that many have tried to solve for many years. Suspect there isn't a great answer there...figuring out how to prioritising this is difficult even within browser teams
travis: one idea; do you capture developers or customers that have expressed interest? browser teams want to look where the committed customer needs are, so tying this back to customers, along with contacts to validate it, can go a very long way
westbrook: that's not something we've done as part of this draft, but that's really great feedback
westbrook: the majority of us here are connecting our work needs to this draft, but connecting those name and hearing those are useful for implementers...that's something we can get included
owen: reports, with these extra points, might be tedious, but we're eager to fold in feedback that can make your work easier
<time check>
richard: about W3C process...not clear exactly the relationship between the WG and the community group...unclear how to find out what to expect from the Working Group
plh: the work of the Web Components efforts is integrated withing the DOM and HTML specs, which are primarialy developed at the WHATWG
alex: this group is a good way to form relationships. Working Groups and charters have a lot of history to them, but the group of people who are gathered here can help move designs forward in the various forums that matter
westbrook: our goal as a CG is to help drive those conversations
RRSAgent: help
thank you, gerald! Was looking for that command = )
<gerald> thanks much for scribing
any time
sorry for the relatively low quality