Webcomponents: Spring 2019 F2F Agenda

[hayatoito]

cc: @tkent-google for Form associated custom elements.

[tkent-google]

Form associated custom elements, ~1 hour

I won't attend the F2F. I hope we discuss it online.

[justinfagnani]

My personal high-priority list:

• Scoped CustomElementRegistry #716
• Lazy element definition: #782
• Custom pseudo-classes: #738
• ::theme() or other theming ability across shadow roots

In addition, I'd love to have an open ended discussions on:

• SSR
• Async UIs: Display Locking, indicating pending rendering, fast-DOM-style batching, etc.

[rniwa]

Form associated custom elements, ~1 hour

I won't attend the F2F. I hope we discuss it online.

Do you think you may be able to join us over phone / video conf?

[travisleithead]

Probably aught to add: CSS and JSON modules to the list :)

[rniwa]

Updated the list per @justinfagnani & @travisleithead's comments.

[diervo]

@caridy (tentatively) and myself will be representing Salesforce.

Apart from the items already mentioned here is our ideal priority list (of the non mentioned):

• Observe connected-ness of a node (https://github.com/whatwg/dom/issues/533)
• Status on forms participation https://github.com/w3c/webcomponents/issues/187
• Make sure we have consensus for SVG (https://github.com/w3c/webcomponents/issues/772)
• Discuss the "internal" API (and consensus, if any) (https://github.com/w3c/webcomponents/issues/758)

Also +1 in everything @justinfagnani said :)

[annevk]

What is SSR?

[abdonrd]

What is SSR?

Server Side Rendering.

[annevk]

To make the most efficient use of F2F time it would also help if for each topic there's some recommended ahead-of-time reading.

[rniwa]

@diervo : form participation is already listed as form associated elements. I just updated the title to clarify the confusion. ID reference issue is already listed but I've put emphasis on #772.

Updated the list again.

[caridy]

@rniwa server side rendering is related to a couple of existing proposals: declarative shadow dom and declarative custom elements, but this time we can probably just cover concrete use-cases. 1hr is probably sufficient.

[justinfagnani]

@rniwa Some time slot suggestions:

• Lazy element definition could probably be less than an hour
• Custom pseudo-classes could probably be shorter as well, if we first have the custom elements only APIs discussion.

16.5 hours is a lot...

[rniwa]

Updated accordingly. We probably want to keep it under 13-14 hours so we probably need to trim down the time from other topics too.

e.g. maybe we can do CustomElementRegistry and ::theme() or other theming ability across shadow roots in 30 min each too?

[tkent-google]

Do you think you may be able to join us over phone / video conf?

I think it's difficult.

[rniwa]

Do you think you may be able to join us over phone / video conf?

I think it's difficult.

Okay, that's unfortunate. Do you think someone else from Google can speak on behalf of you during the meeting? If not, perhaps we should remove it from the agenda.

[domenic]

I will not be able to attend, but can dial in for an hour or so to speak specifically about form-associated custom elements if people feel there is work we cannot do asynchronously. If that is desired I'd love to hear what people want to talk about. Right now the spec PRs look good to me, and @tkent-google has provided a high-level summary in https://github.com/w3c/webcomponents/issues/187#issuecomment-467314213 . I could translate that into slides, but I presume that is not what people are looking for.

[ruphin]

What does the 'outstanding issues' list look like, and is there a way to put items on this list? There is a small outstanding compatibility issue I reported a year ago that needs some kind of resolution, and can hopefully be resolved in a few minutes.

[annevk]

@ruoxiran pointer to your issue? Outstanding issues are linked from the README for various technologies.

[ruphin]

It is this mentioned in this issue: https://github.com/w3c/csswg-drafts/issues/1995
Although I think that issue got somewhat derailed into a larger discussion on handling of name-defined constructs in shadow trees.

I'm only concerned about the current incompatibility between Safari and Chrome/Firefox regarding the lookup scope of name-defined constructs for slotted content.

A minimal reproduction of the issue is here: https://codepen.io/ruphin/pen/zPQvXw

[annevk]

@ruphin that does not seem like the kind of thing that can be solved in a couple of minutes unfortunately and we might not even have the right people attending for CSS-related issues.

[ruphin]

It is a very small edge-case that is currently unspecified in the specs, but it can be resolved without touching larger issues like scoping of css name defining constructs.

I think it is trivial to demonstrate that the Safari implementation is correct. It is currently impossible to apply animations to slotted content in Chrome and Firefox due to this.

If I have five minutes to make the case, I am sure we can get a consensus on it, so we can suggest a possible resolution to the csswg.

[rniwa]

It is a very small edge-case that is currently unspecified in the specs, but it can be resolved without touching larger issues like scoping of css name defining constructs.

I disagree with that characterization. This is really about global name resolution and we need a comprehensive plan to resolve it. To be fair, the issue #179 is already in the agenda so we can discuss this there.

[littledan]

Would it make sense to briefly discuss WebAssembly modules alongside the other module types? It's not web components, but I think we will face analogous issues about asynchronicity that other module types may have.

[rniwa]

Would it make sense to briefly discuss WebAssembly modules alongside the other module types?

Probably not. We don't have the right set of people to discuss that topic, and we've already got too many topics.

[rniwa]

@justinfagnani : I added some links for async DOM UI topic you suggested. Are there any relevant documents people should read beforehand? Also for ::theme and other shadow piercing styling, is there any new proposal, etc... other than ::theme?

[rniwa]

@travisleithead / @dandclark : I added the link to the HTML module explainer. Any other document we should review before showing up at the meeting?

[muan]

This agenda looks great!

Triaging of the outstanding issues

As part of this I am particularly interested in finding out the state/future of delegatesFocus. Some relevant links and discussions:

• https://github.com/w3c/webcomponents/blob/0625cf4c42785aa1202a9d0daed182e12466aa29/proposals/ShadowRoot-delegatesFocus-Proposal.md
• https://bugs.chromium.org/p/chromium/issues/detail?id=531790#c6
• https://github.com/w3c/webcomponents/issues/126
• https://github.com/w3c/webcomponents/issues/666
• https://github.com/whatwg/html/issues/833#issuecomment-432993680
• https://github.com/whatwg/html/issues/2013

In particular, https://github.com/github/details-dialog-element/issues/26#issuecomment-473069296 is the reason why we want to find out more about this.

[rniwa]

@muan : We've gotten the request for delegateFocus in our bug tracker as well. I think the biggest blocker is that nobody has done the work to refactor & integrate the feature into the HTML specification. We only have some vague text about how it may work in the old Shadow DOM specification. I think @TakayoshiKochi was working on it but he has since left the Chrome team and stopped working on it at some point as far as I know.

[rniwa]

I'm now wondering if folks from Github or Salesforce could tell us how they're using web components at the meeting? In the past, our meetings were very much focused on discussing specific standard issues but I think it would be great if we can learn more about how web components are used in real world at scale. What do you all think?

@muan, @caridy, @diervo, @pmdartus: any interests from your side?

[muan]

Thanks @rniwa for the suggestion. I'd be happy to talk about how we are using Web Components and the choices we had to make in-depth at the meeting. We have also shared a little bit about this in the post on our transition off jQuery last year.

[rniwa]

@muan That would be great. I added "Real world use cases of web components" for one hour in the hope that folks from Salesforce / Polymer / ComponentKitchen could also tell us something.

[ruphin]

For real world use cases I may be able to provide some insights from the perspective of ING, particularly in the area of accessibility.

[pmdartus]

Great idea @rniwa! I would be happy to present how Web Component aligns with Salesforce strategy from a technical and business perspective. I would also like to share what are the challenges we are currently facing with Web Components when trying to address the variety of use cases that Salesforce supports.

[JanMiksovsky]

@rniwa @justinfagnani Is there anything newer to read on template instantiation beyond the original proposal?

As I recall, at the Tokyo 2018 meeting, Google presented some interesting ideas for lower-level template primitives. I think the resolution was that Google and Apple would follow up on those ideas after the meeting. I was wondering if the outcome of those discussions was documented anywhere as pre-reading for the F2F.

[justinfagnani]

@JanMiksovsky I have a draft explainer of the latest Template Instantiation ideas here: https://docs.google.com/document/d/1XXJVGKm6UA6SfESDHEH1vFLP5EhTstFYm5DGMQ6Snl8

@rniwa, @hober and I met early this year to solidify the API, and I think we're all relatively happy with the current state. Reading the explainer should get you up to speed for the meeting.

[justinfagnani]

@annevk @rniwa @travisleithead ...

In Tokyo, Chris Joel and I had prepared a few slides for the topics we were most involved in - mostly background, some code samples, and open-questions - to try to help level-set everyone and prep the conversation. Was that helpful? If so I could make 1-3 slides for the topics I want to highlight, like Scoped CustomElementRegistry, lazy element definitions, custom pseudo-classes and ::theme().

Maybe this could help us regain some time. It's possible Scoped CustomElementRegistry won't take a full hour, etc.

[annevk]

@justinfagnani if kept short I think that helps. But also make sure OP has the relevant links so folks can study in advance (bit late now perhaps, but seems it's all mostly there already).

[justinfagnani]

The issue links are there. I'm thinking summary for context. I'll make them and we can use them if the seem likely to be helpful.

[tomalec]

Inspired by today's great presentations of real world use-cases from Component.Kitchen, GitHub, ING and Salesforce, I prepared a quick ad-hoc demo as well. If you anybody is interested, ad we could squeeze it somewhere in Friday's agenda, I'd be happy to show it. I hope it could give some value as well.

[annevk]

I updated OP with pointers to the meeting notes.

[askbeka]

Where can we check outcomes of this meeting?

[annevk]

@askbeka what kind of outcomes are you looking for? The main outcome is that various presented proposals will be further refined per given feedback.

[web-padawan]

I guess the "Summary of solutions" and "Summary of action items" sections are supposed to be filled by someone of the participants? It would be nice if you could write them down.

https://www.w3.org/2019/04/26-components-minutes.html#ActionSummary

[askbeka]

@annevk I would like to know if there are any conclusion Scoped CustomElementRegistry: #716.

I haven't noticed your changes with meeting notes, you have posted them seconds before I have commented.
Anyway, looking through meeting notes, I see that I was misinformed about the goal of this meeting, I expected some decisions on those issues.

[annevk]

We generally don't make decisions synchronously as that'd not allow for those not being able to attend to give input.

[rniwa]

I filed https://github.com/w3c/webcomponents/issues/809 to track the issue that we need a callback for when the parser finished parsing children or when child nodes had changed since this came up quite frequently during F2F. Please add your use cases & rationales as you see fit to make the case.

[LucaColonnello]

Guys, https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Declarative-Custom-Elements-Strawman.md....

This makes me sooooooooo happy!!!!!!!
Since more than 10 years developers have come up with their own solutions as abstraction layers to handle state changes reflecting DOM changes in a declarative way, and all we could do with the native DOM API was giving manual instruction for each and every single change needed to be performed in the UI.

Finally, finally we have a native declarative proposal!!!!
Please, please try make this a real thing. I appreciate all the effort and hard work around this.
It must be hard to come up with something standard, giving all the concerns the spec needs to be aware of when developing such generic and native apis...

But this is revolutionary, cause as developers, finally we could really use the platform for the way we intended to since 10 years. I guess all the frameworks out there are the prove that this is the way we would like to work!

Thanks for proposing this, looking forward to possible polyfills and new update to the proposal.

🎉

[rniwa]

For those who were in the photo we took on the last day, I have it ready. Please email me (same username as my Github account) at webkit.org, and I'll send it to you privately since I'm not certain if everyone wants their pictures being distributed publicly.