– DRAFT –
(MEETING TITLE)

<Westbrook> Community Group GitHub repo: https://github.com/w3c/webcomponents-cg

<Westbrook> Community Group Slack Channel: https://github.com/w3c/webcomponents-cg

<Westbrook> Conversations we've lead around Community Protocols: https://github.com/webcomponents-cg/community-protocols

<Westbrook> Early draft of the report we are presenting today: https://w3c.github.io/webcomponents-cg/

4. Constructable Stylesheets & adoptedStyleSheets

issue 468 in WICG/WebComponents

5. CSS Module Scripts

6. Scoped Element Registries

7. Declarative Shadow DOM

Declarative Shadow DOM on Web.dev

Dom: how do you position the Web Components CG wrt OpenUI? WhatWG/WICG?

Westbrook: OpenUI CG is looking at expanding existing elements whereas we're looking at the web components capabilities themselves
… we're looking at the best way to leverage our realities wrt realities of Web browsers
… incl funnelling Web developers priorities
… if we can help support prioritization or reprioritization, that's great
… having a more direct connection with web developers producers & consumers

Owen: in terms of relations to WHATWG - we link to the underlying github issues and discussions
… based on sometimes years of conversations
… our draft refers to all of those

<tidoust> dom: Two ways to use Web components: encapsulation and "browser-grade" components, where you're trying to standardize around components. Needs are probably different in both cases. Is that something you've seen as well?

<tidoust> ... Open UI develops what I call "browser-grade" components. There are doing this for a number of use cases. That is also something that developers may want to do for specific use cases.

<tidoust> ... Designing components that work "as well as" native elements.

<tidoust> Gray_Norton: Those things do get discussed in the CG, so I encourage you to join. There may be things that are more important for browser-grade vs. other types of components.

<tidoust> Will_Riley: We're also looking to support broader HTML environments. Example of declarative Shadow DOM to remove the dependence on JS in some cases.

masonf: very useful input on prioritization - thank you all

olli: +1 - sometimes some features are really hard to get implemented

masonf: useful to have evidence of needs / usage for these features

owen: thanks, good feedback for us to provide prototypes / examples

PaulG: I've developed Chrome extensions before where the lack of x-browser implementations no longer matter
… there is no access to CE registry in web extension context - seeing that would help demonstrating usage of custom elements

masonf: I'm not a Web Extensions expert - I thought there was ways to hook to it somehow

owen: in terms of follow up & next steps - what's the best way for us to bring e.g. a potential spec on declarative shadow dom?

westbrook: in general, what are good ways for us to better surface these priorities on a year long basis?

masonf: keeping that doc up to date would be helpful
… having more documentation on the motivations for the prioritization also helps

Westbrook: is there anything we can do to support the browsers speaking to their community talking about their prioritization?
… even outside of the top 6 issues

owen: maybe we should add to the report that moving forward will need proof of concepts