Giters

WICG / webcomponents

Web Components specifications

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

April Face-to-face Scheduling/Agenda

Westbrook opened this issue · comments

commented

After the great success of our Q1 Face-to-Face (no kidding, we got featured in a podcast) it's time to start thinking about scheduling and agenda building for our next face-to-face. 🎉

ACTION REQUESTED: We're looking to schedule 2 separate 2-hour sessions around the week of the 15th in April. To support that, please share your availability for the middle of April on this when2meet.

From the standpoint of the Web Components Community Group, there are currently presentations coming together focusing on Open Styleable Shadow Roots and Declarative Custom Elements. If you'd like to participate in the ongoing conversation around these two subjects, check out w3c/webcomponents-cg#78, and w3c/webcomponents-cg#79 respectively to see when groups will be gathering in that name of those efforts in the interim.

In the comments below please share any thoughts you might have on the agenda, meeting "venue" (last time we used Google Meet well enough, but happy to have better suggestions), and anyone we should ensure can join various conversations.

commented

I wonder if we could have the f2f one week earlier, or two weeks later. Some relevant Mozilla folks might be a bit busy Apr 15-26 (there just happens to be two consecutive meetups during those weeks).

commented

@smaug----, thanks for the info. We want to see as many lovely Mozillians join the convo as possible, so I've moved the date range back two weeks. Please share availability in the updated link in the description above or at https://www.when2meet.com/?23874110-FaIek

It would be great if we could get availability from everyone before March 22nd, so we can have this on everyone's calendar well beforehand. 🤞🏼

commented

@rniwa @mfreed7 @annevk @keithamus @bkardell @zcorpan and more, how are your availabilities looking for this gathering?

commented

I'd prefer seeing somewhat concrete proposals first. Usually a meeting is scheduled to work through specific technical issues, not to have open-ended discussion.

commented

I'd prefer seeing somewhat concrete proposals first. Usually a meeting is scheduled to work through specific technical issues, not to have open-ended discussion.

Open ended discussions are the most efficient time to provide input on things that will affect the overall direction of the API. It'd be unfortunate if all features needed to be fully fleshed out before they got their first WHATWG rejection.

@rniwa @mfreed7 @annevk @keithamus @bkardell @zcorpan and more, how are your availabilities looking for this gathering?

I added my availability.

commented

@annevk, I reached out with a pretty long runway to get availability and didn't have agenda info at the time, but we'll have a structure to the conversation. However, I do agree with @mfreed7 that open discussion can be a very powerful part of developing for the future the way that has been brought up by several implementors (including yourself) as recently as January's face-to-face.

Not to set anything in stone, but the Web Components Community Group has been meeting on an almost weekly basis to address the action items from our last face-to-face. The top three or four items for discussion persist:

  1. Scoped Element Registries
    • we're working on getting in-person reportable feedback and findings from the Chromium prototype to help clarify next steps for all implementors
  2. Cross Root ARIA
    • a progress report on @behowell's prototyping and practical feedback from teams at WebKit and Firefox as to whether it's something we can support getting a contribution to their implementations of
  3. Open Stylable Shadow Roots
    • use cases!
    • proposals
    • demos
    • scoping, rescoping, dividing into one or more paths forward
  4. Declarative Custom Elements
    • it's time, and while it's a thorny complicated concept we've been gathering lots to discuss that will benefit from in-person attention across the whole implementor community

Beyond that, this would also be a great place to hopefully get insight on things like:

  • @tabatkins and @fantasai's position on w3c/csswg-drafts#6867 and w3c/csswg-drafts#5629 and w3c/csswg-drafts#10013
  • hear what implementors have been thinking about as far as specs and APIs, we'd love to have everyone join the WCCG's regular meetings but realize that's not always possible. We want to know what we as a community group can support the collection of you all in bringing to life, too.
  • there's also something to be said about triaging and cleaning up this issues list as a weeded garden is most likely to grow, etc., etc., platitudes 😉

Hopefully this positions this in the "want to attend" column of your schedule in the timeframe outlined in https://www.when2meet.com/?23874110-FaIek. If not, how can we make this something that more implementors like yourself would be excited to partake in?

commented

Looks like 3 May from 12pm ET to 3pm ET is the winner here. Unless there are any concerns with that, I will add the invite to https://calendar.google.com/calendar/u/0/embed?src=o25bim5rvcu42mfnqilirpmp44@group.calendar.google.com later this afternoon. I can invite people directly, if that's beneficial, or simply have it listed there for people to subscribe (we have other WCCG events listed there, too).

Last time around we used Google Meet, which will require three separate call URLs. Feel free to share any better solutions around gathering everyone. We can start to structure the agenda over the next month, so if there's anything missing above, please give a shout below!

commented

I can create a single Meet link that will work for the three hours. It's generally better not to share those links widely, but @Westbrook perhaps reach out to me and we can figure out a good way to publish it?

commented

This meeting is coming up in 1.5 weeks. Do we have an agenda & meet link?

commented

It looks like @Westbrook has been collating something of an agenda above and in w3c/webcomponents-cg#93

If we have time, I would like to throw a very early discussion of a DOM update scheduling API on the agenda. This is something that's been top-of-mind for me very recently as I've dug into signals and web components integration, and I think it intersects with template instantiation and declarative custom elements as well. I'll open an issue asap to sketch out what I see as a problem to address.

commented

@justinfagnani sounds like a powerful topic. Looking forward to the issue. If you have thoughts on goals you might have around bringing this to next week's meeting, as opposed to the Q3 meeting or TPAC after that, would be great to see in the OP. 🙏🏼

commented

Thanks for everyone's patience as we get ready to gather next week. Here's the meeting information:

Friday May 3rd
12pm - 3pm ET (timezones)

We will gather via this meeting link which should be good for the whole three-hour session.

Agenda
I suggest we take two 5 or 10-minute breaks through the session, which leaves us with three 50-minute segments to cover any number of topics including, but not exclusive to:

  • Scoped Element Registries (could easily be a whole 50-minute segment)
    • The community has been gathering feedback from Chrome's prototype, it may be useful to review issues therein to ensure they do not become normative bugs
    • @sorvell to discuss creation time registry resolution
    • The following issues have been left unaddressed by the current spec, but may be valuable to include therein:
  • DOM Scheduling, is it a good target to drive towards? (~10 minutes)
  • Cross Root Aria (~15 minutes)
    • @behowell proposal here has landed in the AOM repo, it's possible there is no discussion to be hand beyond that, but @annevk has opened the following issue referencing the proposal, is it worth discussing this in person?
  • Open Stylable Shadow Roots (~15 minutes)
  • CSS additions (~20 minutes)
  • Declarative Custom Elements (a whole 50-minute segment?)
    • It's everyone's favorite topic and we've been gathering use cases and possible paths forward
    • Chapters
      • Why start with HTML Modules (@justinfagnani)
      • The broader features that affect structuring a solution here
      • How can the CG best support implementors to a solution here?

These topics put us right at time, if we move expeditiously, but if there are better or different subjects we should cover, please share below. If we break the three segments into the following we could reorder them as best supports the presence of any specifically important implementor, were they not available for the whole session.

  1. Scoped Custom Element Registries
  2. Potpourri
  3. Declarative Custom Elements
commented

Looking forward to seeing everyone on Friday at 12pm ET. Please let me know if you have any issues with the agenda or meeting link in the previous comment. Thanks in advance for all the great discussion!

commented

Scoped Custom Element Registries

Chrome Prototype Feedback

  • createElement works
  • importNode does not work; therefore cannot be used in Lit
  • upgrades work, but not if element is globally defined
  • Issue: global registry applies in scoped registry; can be confusing
  • Issue: setting innerHTML customizes with global version before scoped (behaves same if element is connected in scoped shadowRoot or not)

This behavior verified on Canary 126.0.6452.0. The prototype hasn't been updated since 1/24. Is additional work planned?

Polyfill Usage/Issues

  • surprising amount of use within the Lit community, often by organizations using a micro-frontend architecture and supporting a variety of web frameworks
  • significant number of issues; many related to formAssocated which is currently always true in polyfill.
  • these issues have caused a number of users to avoid the polyfill and instead implement a bespoke in-situ element renaming strategy

Spec Issues

  • #1040: is it possible to have disconnected elements use the registry from the last scope to which they were connected?
  • #1043: introducing new rendering APIs adds significant adoption friction especially for frameworks
    • main concern is element names also defined in global registry
    • discuss possibility of mitigating this, by e.g. adding 'upgrade only' option to defined elements
commented

Thanks, everyone for joining in the conversation today! Whether you actively participated, or just listened along, having you all as part of the ongoing work is a valuable part of making the world of web components better for everyone.

Notes from today's conversation are available here. I'll close editing shortly, so if there are any further notes you'd like to add, please be sure to do so ASAP.

Action Items:

Meeting chat hidden within...

You
12:05 PM
https://docs.google.com/document/d/1RtGdU0DAiIKGY0p-IGgni3waaE_4UYU-PLfb-rW2lnU/edit
keep
Pinned
Brian Kardell
12:17 PM
hmm
Sasha Firsov
12:20 PM
like mixin of registries?
Mason Freed
12:21 PM
myRegistry.define('x-foo',customElements.get('global-x-foo')) ?
Rob Eisenberg
12:23 PM
I wouldn't want to block on this personally. I just think it's speaks to some common scenarios that come up.
Sasha Firsov
12:23 PM
myRegistry.inherit(...otherRegistries)
Sasha Firsov
12:25 PM
otherRegistry can be a domNode | LocalRegistry
Michael Warren
12:25 PM
i agree with Rob on this not being a blocker to implementation of some scoping
Justin Fagnani
12:26 PM
#716 (comment)
Michael Warren
12:26 PM
personally I've not seen a need for inherited registries in our WC design system and the MFE apps and such that need scoping today. imo the scoping is more about creating the encapsulation. I've not see a use case for sharing across registries
Rob Eisenberg
12:26 PM
I'll take an action item to create an issue for it.
We can explore use cases and then see if we need an api.
Keith Cirkel
12:27 PM
A small change to improve the ergonomics and discover use cases would be to propose iterable registries. A quick glance it seems doable (in lieu of implementer concerns).
Justin Fagnani
12:27 PM
^ that includes a mid point in the evolution of the discussion where we decided against registries having parents. There's another discussion where we nixed the tree-lookup idea
Rob Eisenberg
12:31 PM
How does all this work with templates and document fragments today? I haven't tried it. If I clone a fragment and then append it to a shadow root with a registry, does that work? or is the fragment already connected to the glogal registry?>
You
12:32 PM
For anyone making "Action items" in chat, please support the process moving forward by making sure we get those listed in the notes doc. Reposting for late joiners: https://docs.google.com/document/d/1RtGdU0DAiIKGY0p-IGgni3waaE_4UYU-PLfb-rW2lnU/edit
Rob Eisenberg
12:32 PM
On it.
Brian Kardell
12:36 PM
+1
down with innerHTML!
Nolan Lawson
12:38 PM
+1 to registry.run()
Sasha Firsov
12:39 PM
createElementNs is a scope kind of. Can be used for definig the scoped registry as NS :)
Justin Fagnani
12:41 PM
The change to enable scoping in React is pretty trivial
Keith Cirkel
12:42 PM
Whether or not they merge it is less trivial ;)
Sasha Firsov
12:48 PM
DCE should be implemented with namespace scoping in mind. API can follow
Pascal Vos
12:53 PM
vue is the same few lines of code
Brian Kardell
12:57 PM
i dont think that is why they do that though
You
12:59 PM
Luckily default tree shaking accidentally drops same file registrations anyways 🤪 and when not, the long-standing publishing best practices pointed away from same file registrations.
Ben Howell
1:08 PM
https://github.com/WICG/aom/blob/gh-pages/reference-target-explainer.md
Brian Kardell
1:12 PM
or to serialize I guess?
You
1:15 PM
Anne's issue here: WICG/aom#209
Nolan Lawson
1:24 PM
accname spec addresses infinite loops already: https://w3c.github.io/accname/#:~:text=This%20is%20done%20to%20avoid%20infinite%20loops.
Keith Cirkel
1:24 PM
Thanks Nolan!
Nolan Lawson
1:27 PM
you can test the accessible name (label) now
Michael Warren
1:29 PM
#1052
Nathan Knowler
1:30 PM
I created a GitHub discussion for collecting the use cases as well (which might be a better format for asking questions to owners of different use cases): w3c/webcomponents-cg#92
Mayank
1:33 PM
i think Firefox does allow targeting shadow-roots; this might be about browser extensions in Chromium
Nathan Knowler
1:33 PM
From what I understand both Safari and Firefox’s user styles implementation will apply user stylesheets to shadow roots too.
Justin Fagnani
1:37 PM
Open Stylable pulls styles from the containing scope, not the document.
So that's already taken into account
Mayank
1:39 PM
re: DSD streaming, I think slots of body's shadow-root should work fine with page CSS?
Justin Fagnani
1:41 PM
yep
Brian Kardell
1:41 PM
yes
Justin Fagnani
1:41 PM
the shadow root would only contain slots
Brian Kardell
1:42 PM
I'm happy to try to defend that :) I realize you might not agree
Justin Fagnani
1:42 PM
Do like you do with breaking JS encapsulation: copy the component's source code
Steve Orvell
1:46 PM
It's been basically impossible to scope as initially proposed. I think that means we need to solve theming.
Mayank
1:47 PM
user stories are just user stories, it should be totally ok for them to be "out of scope" of certain solutions
Maxime Bétrisey
1:48 PM
Isn't it possible to handle many of these cases by injecting CSSStyleSheet?
Nathan Knowler
1:49 PM
I’ve been using "Open Styling", but maybe that’s too close to “Open Styl(e)able"
Justin Fagnani
1:49 PM
not for unknown page styles, which is the original motivation for the Open Stylable proposal
Mayank
1:49 PM
maybe "external styling"?
Rob Eisenberg
1:49 PM
Is there a group I can join?
Brian Kardell
1:52 PM
don't feel bad, we don't either :)
Justin Fagnani
1:53 PM
or worse.. some CSSWG people just say that don't care to make it work in SD
Mixins and functions, specifically... they said they won't well with SD
Mayank
2:01 PM
I've suggested a simple two-phase approach:

  1. open-styleable = simple, backwards compatible.
  2. @sheet = more powerful, granular control.

More details here: #909 (comment)

It would be nice to get implementor feedback on it.
Brian Kardell
2:02 PM
+1
Steve Orvell
2:05 PM
Would love to get some feedback or +1's on: #1051
Rob Eisenberg
2:06 PM
Here's the issue on registry iteration and combining for those that want to chime in: #1057
And here's the issue on alternative ways to control registry scoping:
#1058
Justin Fagnani
2:06 PM
I'm bummed we don't seem to be getting to DOM Scheduling
I would cut down the time on declarative custom elements... we could talk about that for years.
You
2:08 PM
If you think we could close in 5 minutes, it does fall inline with some of that. You did seem to be looking specifically for go/no go on having a larger discussion over time?
Justin Fagnani
2:09 PM
yeah, I'd like to introduce the idea
Justin Fagnani
2:14 PM
https://docs.google.com/presentation/d/1jhc1B1XC1BNPMJpCxlC3AkFwQ4EDUB_Hty5Aj2S-V5I/edit?usp=sharing
Rob Eisenberg
2:15 PM
For references on signals: https://github.com/tc39/proposal-signals
Steve Orvell
2:17 PM
The browser does this type of thing too... in a way that isn't exposed to custom elements...

e.g.
this.style.width = 100px;
this.style.height = "200px':
this.getBoundingClientRect();
Rob Eisenberg
2:20 PM
Also, imagine that D is very expensive to render, and that C determines whether or not to render it. If D runs first, it will potentially execute a bunch of expensive, completely unnecessary code.
Olli Pettay
2:26 PM
whatwg/dom#1261
Brian Kardell
2:26 PM
was that shubie's thing?
Rob Eisenberg
2:27 PM
When the timing is right, we have a ton of folks involved with signals now. I'm sure they would all have feedback.
(Personally, I'd love something like this and use it immediately.)
Justin Fagnani
2:28 PM
https://docs.google.com/presentation/d/1QmeGJj1Xze_0yZ8ATJo5cLuQvEOUDDPrmDzb0eoU8zM/edit?usp=sharing
Sasha Firsov
2:33 PM
performance of DCE supperrior to js
Steve Orvell
2:37 PM
IMO, DCE is 1/1e6 as important to be implemented today as the other topics we've discussed: cross-root AOM, scoped registries, or styling improvements. Those things are existential for custom elements.

The key thing right now, IMO, s that implementers get a sense of the North Star, as a community, we want to work towards
Justin Fagnani
2:37 PM
+100
Rob Eisenberg
2:37 PM
Agree
Maxime Bétrisey
2:37 PM
+1
You
2:38 PM
w3ctag/design-reviews#334
Rob Eisenberg
2:41 PM
I think I have all these pieces in my document.
Michael Warren
2:42 PM
+100
You
2:42 PM
100%
Michael Warren
2:42 PM
100%
You
2:43 PM

... 😉 Rob Eisenberg 2:44 PM I have some thoughts on how to declaratively import individual elements from modules, including renaming/providing scoped tag names here: https://gist.github.com/EisenbergEffect/8ec5eaf93283fb5651196e0fdf304555 Justin Fagnani 2:44 PM +1 Michael Warren 2:48 PM +1 to importing svg...svgs are always tricky to deal with in design systems because we have an icon component but dont want to have 250+ icons in some app when they're not being used Rob Eisenberg 2:52 PM I have a proposal like this Justin Fagnani 2:54 PM Rob Eisenberg 2:54 PM I've got something like that as well. Yep. Olli Pettay 2:54 PM That is definitely nicer than XBL1's: elementname { binding: url("url.xml#"elementname"); } Rob Eisenberg 2:54 PM It's a declarative registry. Brian Kardell 2:58 PM justin can I have the stampino link? Justin Fagnani 2:58 PM https://github.com/justinfagnani/stampino-element Brian Kardell 2:58 PM thx Olli Pettay 2:59 PM sounds good Justin Fagnani 2:59 PM yep. And the slides I presented: https://docs.google.com/presentation/d/13mIqxQJVlQZxBrtYAsTP-WjhSbFcWO5p4a-NCDFBdhc/edit?usp=sharing Ryosuke Niwa 2:59 PM yeah, july sounds good to me. Steve Orvell 2:59 PM Great discussions today. Thanks everyone! Michael Warren 2:59 PM thanks everyone! Owen Buckley 3:01 PM thanks! Jesse Jurman 3:02 PM Thank you Westbrook! Maxime Bétrisey 3:02 PM Thanks everyone
commented

Here's the issue I created to start the conversation on HTML Module imports and exports:

#1059

commented

Added idea for augmenting setHTML to address applying registry to detached element: #1040 (comment)