Web Components-related breakouts @ TPAC 2020

[hober]

The week of October 26th of TPAC will consist of a number of breakout sessions. A number of folks in the web components community have proposed breakouts. Please keep an eye on these two links to see when the breakouts will be!

[diervo]

We would love to from Salesforce end.

[EisenbergEffect]

Microsoft would love to participate as well 😄

[rniwa]

Note that there will be F2F centered around accessibility in September.

[rniwa]

Now that TC39 is working on import assertion and JSON modules, it's prime time for CSS script module :) It would be interesting to get a list of agenda and see how many hours we may need.

[leobalter]

I went ahead and created an agenda doc based on the F2F one by @JanMiksovsky, who helped me filling the agenda with some items that might be discussed at TPAC.

It would be great to have everyone's input there and I'd be happy to address any feedback.

[justinfagnani]

I'm sure several people from Google would attend. Tagging @mfreed7 @yuzhe-han @kevinpschaaf @aomarks for visibility

@rniwa I think the base Cascading Stylesheet Modules Script proposal is small enough that it should be ready to go soon, but we'll need applying stylesheets to be in place too. I'm not sure where all that work is, but is it the right venue for us to discuss at TPAC? We could also discuss next steps beyond the minimal semantics, like whether to export anything besides the stylesheet.

I'm hearing a lot more interest in Template Instantiation recently too. Work had trailed off since the Toronto f2f, but maybe we can get something together work talking about by TPAC.

[EisenbergEffect]

@justinfagnani Do you have a link to the latest on template instantiation? I'm very interested in that, particularly that the right low-level APIs are in place.

[mfreed7]

Several Google people would definitely attend. Thanks for adding declarative Shadow DOM to the agenda doc.

[yuzhe-han]

I've added template instantiation to the agenda.

[annevk]

@justinfagnani @yuzhe-han is there an update to template instantiation to discuss? There's also the discussion at whatwg/dom#736 started by @WebReflection and @wycats also expressed interest. I think to have a productive group-wide discussion on that topic some more work should be done on formalizing the template part bit (i.e., some new kind of primitive for node trees that helps template engines), which is what everyone was interested in moving forward last time we discussed this, with various caveats. Otherwise we'll essentially be revisiting the discussion from 2017.

[EisenbergEffect]

Slightly off topic, but Microsoft would be very interested in seeing a document that represents the latest template instantiation proposal and exploring how we can help out in this area.

The area of templating is highly contentious. I have my own opinions, backed by many years of working with communities on multiple frameworks and libraries I've designed. Other framework and library authors likely feel the same. Community members have their own opinions, sometimes even stronger than the library authors.

As a result, I'm mostly interested in starting with low-level APIs and seeing how existing DOM-based frameworks could be re-platformed on top without individual libraries/frameworks being forced down a path they don't feel fits their community. To that end, the new APIs should:

• Support existing libraries implementing the features they have today
• Reduce library code
• Improve performance
• Reduce memory

Nothing surprising there. It's just important to note that perf or reduced code alone are not necessarily enough. If the new APIs don't help with our real-world features and scenarios or force massive breaking re-design on the community, we'd likely stick to a user-land solution in spite of the new APIs. The 2017 proposal seemed a bit dubious in that some of the low-level details appeared an after-thought in the rush to try to provide a high-level templating solution.

[yuzhe-han]

@annevk @EisenbergEffect. Thanks for the feedback and interest from Microsoft.

Not yet, there are no updates to the initial template instantiation doc that I know. I'm planning to investigate this topic in the next few weeks and provide an update sometime later next month. Hopefully, that gives us time to review and decide whether it's worthwhile to have a group-wide discussion.

@justinfagnani and I discussed this topic a couple of weeks ago, and similar to you, he suggested focusing on the low-level API first. That makes sense; focus on the area that will benefit all frameworks first then work on improving ergonomics like templates syntax in a later revision.

I found the meeting minutes from the 2017 discussion, https://www.w3.org/2017/11/10-webplat-minutes.html.

[Westbrook]

There was further discussion of Template Instantiation at the 2019 Spring F2F, notes can be found at: https://www.w3.org/2019/04/26-components-minutes.html#item03 The (possibly) most important findings being:

annevk: I think Jan's point is valid, templating needs centralized use cases, requirements, and updated proposal

justin: next step is a fully updated proposal
... and polyfill

[rniwa]

We should probably propose this as a breakout topic.

[gregwhitworth]

Hey everyone, TPAC is right around the corner and it seems that there is interest in having a TPAC session but I don't see it on the list for group meetings. Who is driving this? @hober ??

[hober]

Hey everyone, TPAC is right around the corner and it seems that there is interest in having a TPAC session but I don't see it on the list for group meetings. Who is driving this? @hober ??

I think the current plan is to do a breakout during breakout week. @rniwa is going to update the wiki page.

[rniwa]

Added "Web Components" and "Parts and Template Instantiation" as two breakout ideas to https://www.w3.org/wiki/TPAC/2020/SessionIdeas#Proposed_sessions since after discussing with @hober and @justinfagnani since we didn't think one hour would be enough to discuss them all.

[rniwa]

I've also edited the OP to add the link to the agenda. Please add more topic as you see fit.

[yuzhe-han]

I have a draft for the Template Instantiation APIs. Currently sharing it internally to get some feedback. Hopefully, it be will be ready to share with everyone soon.

[rniwa]

It came to my attention that the meeting is planned to take place at UTC 2pm, which will be 7am in PDT (SF Bay Area). Given the vast majority of people attending this meeting is located in the West coast, I'd rather avoid this time slot.

My suggestion is to do it at UTC 16:00 or UTC 17:00, which will be PDT 9am or PDT 10am.

[mfreed7]

I'd like to discuss declarative Shadow DOM - do you think we could fit that into the existing Web Components breakout? How are we keeping track of the sub-agenda for this meeting?

[rniwa]

I'd like to discuss declarative Shadow DOM - do you think we could fit that into the existing Web Components breakout? How are we keeping track of the sub-agenda for this meeting?

That feature has enough interests & topics to cover that perhaps a separate breakout session is warranted. The last time we discussed about it, it took more than one hour.

[mfreed7]

That feature has enough interests & topics to cover that perhaps a separate breakout session is warranted. The last time we discussed about it, it took more than one hour.

Ok, good point. I added a separate breakout for DSD. Thanks!

[dandclark]

I wonder if we should have a separate breakout for CSS modules as well. The scope of the agenda item includes not just CSS modules themselves but also adoptedStyleSheets and potential future directions like exporting other objects from the stylesheet. That's a lot to work through in an hour if we want to leave time to discuss other things.

The risk is that if we have too many of these topics as separate sessions, they'll start to overlap, and I think a lot of us would not want to miss any of these.

[dandclark]

cc @justinfagnani who originally proposed the CSS modules agenda item -- do you think that there's enough to that topic to merit a separate breakout session outside of the 1 hour WebComponents slot?

[rniwa]

I think adding a separate one hour meeting might make sense. If it turns out that they overlap, we can either request the change of time or just collapse them back into a single meeting.

[justinfagnani]

Especially if this gives CSSWG members a good time to join.

And there are more topics we could discuss for follow-ons to CSS modules:

• @import: define behavior of @import in Cascading Style Sheet (CSS) modules #870
• The API sometimes known as adoptedStyleSheets: Instead of assignable FrozenArray, use add / remove construct-stylesheets#45
• Exporting things from CSS: [css-selectors] Reference selectors w3c/csswg-drafts#3714
• Bundling CSS: Multiple stylesheets per file w3c/csswg-drafts#5629

[dandclark]

Great -- I proposed the session: https://www.w3.org/wiki/TPAC/2020/SessionIdeas#CSS_Module_Scripts

[justinfagnani]

@dandclark looks like you copied the shortname from web components.

[dandclark]

@justinfagnani That was intentional. My understanding is that the shortname is just used to name the IRC, and since normally we'd have all these discussions in one longer meeting with all the chat logged in the same channel, reusing the #components IRC would just be continuing the same pattern used last year. I saw that Parts and Template Instantiation and Declarative Shadow DOM did this too, not sure if that was by-design for those meetings as well.

If there's a requirement that the shortnames are unique though, I can change it.

[justinfagnani]

Ah... I don't know, so probably my mistake there :)

[hober]

The shortnames should be distinct. If the sessions get scheduled to be overlapping, we don't want people simultaneously scribing distinct sessions into the same channel.

[rniwa]

The shortnames should be distinct. If the sessions get scheduled to be overlapping, we don't want people simultaneously scribing distinct sessions into the same channel.

FWIW, we can probably do the rename once sessions are scheduled. In the ideal situation in which there are no overlaps between these sessions, it would be nice if we used the same channel we've been using for many years for web components discussions.

[dontcallmedom]

I've made sure the sessions don't overlap and that they use the same IRC channel FWIW

[leobalter]

I've made sure the sessions don't overlap and that they use the same IRC channel FWIW

Do we already have any schedule? I have specific items I don't want to miss, it would be helpful to keep track of the date and time each of the sessions are being discussed next week.

[dontcallmedom]

I'm working on finalizing it for publication (most likely tomorrow), but I can already share that the 4 meetings will be scheduled as follows:

• Web Components, Mon 5pm UTC
• Template Instantiation, Tue 5pm UTC
• Declarative Shadow DOM, Wed 5pm UTC
• CSS Module Scripts, Thu 5pm UTC

[leobalter]

Thanks! @dontcallmedom if you don't mind, please also share the duration of the meetings in the publication so I can save the proper slots in my calendar.

[kenchris]

Calendar invites would be even better!

[dontcallmedom]

https://www.w3.org/2020/10/TPAC/breakout-schedule.html#calendar now has the details and the calendar invites

[rniwa]

Agenda

[rniwa]

I've worked with @hober @justinfagnani @yuzhe-han @mfreed7 to make a refined API proposal for templates:
https://github.com/rniwa/webcomponents/blob/add-dom-parts-proposal/proposals/DOM-Parts.md

There is a PR to merge it into this repository.

[EisenbergEffect]

I wish we had a little more time to review this before the meeting. Only having a limited amount of time to start thinking about it, I have some concerns. Chiefly is my interest in looking at more modular and general purpose primitives than what is spec'd out above. To help convey some ideas, I've created an alternative proposal which can be found here: https://github.com/EisenbergEffect/templating-primitives/blob/main/README.md

[rniwa]

Sorry for the late minute change but I won't be able to attend tomorrow's declarative shadow DOM session.