February Meeting Agenda

[Westbrook]

For those of you who would like to take part in the February meeting of the Web Components Community Group, please share your availability here as we work to schedule the right day/time to gather. Don't forget, all WCCG events are listed on this calendar. 📆

Hitting the first week of the month puts us on schedule to have three sessions (February, March, and April) before the Q2 Face-to-face with implementors. 🤞🏼

Some topics for conversation may come directly from the Action Items that were gathered at the Q1 Face-to-face with implementors that happened this week. Anyone interested in supporting the completion of the Action Items should speak up below or on Discord. 🗒️

Please share your thoughts below as to subjects that you'd like to cover during the February meeting! 🙇🏼

[Westbrook]

This session has been scheduled as follows:

WCCG: February Meeting
Monday, February 5 · 1:00 – 2:00pm ET

Reminder that this an all other events are managed on this calendar.

[JRJurman]

As far as some agenda items to bring up, a reminder of the action items, and maybe a summary of the discussions happening so far in discord for each one of them:

• HTML Modules - Get high priority examples
• External Styling - Investigate and clarify smaller user stories
• ScopedCustomElementRegistry - Evaluate Prototype

I think it would probably be worthwhile to also talk about Declarative Custom Elements - it seemed to come up in the F2F several times, but I'm not actually familiar with what the WCCG's stance is here, if there are "cow paths" that we'd like to evaluate, or where we go next. With Declarative Shadow DOM, it certainly seems like a likely next step for people to go.

[sashafirsov]

There is DCE syntax and opinionated data layer for the discussion if it would come to it:

https://unpkg.com/@epa-wg/custom-element@0.0.13/index.html

As of now it is not yet polyfill ready, but cross-browser compatibility is next on its todo list.

[JRJurman]

It also occurs to me that the DOM Parts meeting happened (totally missed that one 😓), but there are minutes and slides referenced here - might be worthwhile to call out the results. Sounds like (from what I gather reading the minutes):

• Initial performance testing proved to be slower than the implementors would like - more testing (in other browsers) to happen here between now and the next meeting (most likely in April)
• Localization may be a key area that can be tackled with DOM parts, and examples are being put together to help understand the cross-section here.

[justinfagnani]

more testing (in other browsers) to happen here between now and the next meeting

I think the other browser representatives said that they were busy and unlikely to be able to prototype by the next meeting.

[justinfagnani]

I'd like to see if anyone can help contribute to webcomponents.org

[Westbrook]

I'd like to see if anyone can help contribute to webcomponents.org

There's likely a good number of people interested in something like this is the floor was lowered enough. Do you have thoughts on a path to making progress here that might be less expansive than some of our previous conversations in this area?

[michaelwarren1106]

I'd like to see if anyone can help contribute to webcomponents.org

i’d love to help. if we have specific goals, i can code, design and/or project manage if need be.

[jogibear9988]

I'd like to see if anyone can help contribute to webcomponents.org

i’d love to help. if we have specific goals, i can code, design and/or project manage if need be.

I'd also. For me it's the wish is based on the manifest, so everyone like to be listed needs one. And also needs npm's working without a bundler.

[Westbrook]

High-level agenda

1. Lots of great convos seem to be happening around February Meeting Agenda #77 (comment) Can we get volunteers to own collecting feedback (use cases, API reactions/questions/etc, proposals) on each of these to share with the CG in March/April in advance of sharing them to implementors in the April face-to-face?
2. DCE conversation also interrelates to some of the above, can someone own bringing the various conversations into a sharable format for the face-to-face?
3. Reviving webcomponents.org. @justinfagnani are you able to share any plans for this? It may be more beneficial to use this as a centering function before having a more focused breakout for this discussion.
4. Progress on community protocols.

If there's anything else we should get on the docket, now's the time to share with the class.

[sashafirsov]

Correction on DCE POC, cross-browser compatibility added in pre-release:
https://unpkg.com/@epa-wg/custom-element@0.0.14/index.html

The syntax is ready for discussion.

[nikkimk]

I'd like to see if anyone can help contribute to webcomponents.org

@justinfagnani I'd be interested

[Westbrook]

Great meeting everyone!

Meeting notes: https://docs.google.com/document/d/1jOz2Mu8y49j81WPE7__sHkyoUQey6X09JNiYmEh4b1I/edit Thanks @JRJurman 👏🏼 👏🏼 👏🏼

High level take-aways:

• there will be action item forums for "External Styling" and "HTML-in-JS-in-HTML-in-JS"
• both of these areas of discussion will have individual breakout calls later this month
• there will be an action item forum for webcomponents.org revamp
• look out for an "SSR Community Protocol", there's desire to discuss this more closely in March

Meeting chat roll:

Jesse Jurman
1:03 PM
New year, new doc!
You
1:03 PM
https://docs.google.com/document/d/1jOz2Mu8y49j81WPE7__sHkyoUQey6X09JNiYmEh4b1I/edit
Steve Orvell
1:04 PM
no access yet
Nikki Massaro
1:05 PM
I need access too
Steve Orvell
1:05 PM
steveorvell@gmail.com
Nikki Massaro
1:05 PM
nmassaro@redhat.com
Owen Buckley
1:08 PM
should I screen share the issue?
You
1:09 PM
Owen: https://github.com/w3c/webcomponents-cg/issues/77#issuecomment-1912773780
Luke Dary
1:20 PM
For us it would remove a build step in the generation of our components.
You
1:21 PM
^ these sorts of user stories are what we're looking to collect for presentation to implementors.
Nathan Knowler
1:21 PM
For the external styling one, I am working on a bit of a problem statement that I can contribute. Not sure if I can own the issue for presenting during the April F2F though. (I am a bit biased too.)
Owen Buckley
1:21 PM
a sounding board would be great
Sasha Firsov
1:22 PM
demo for HTML modules: 
https://unpkg.com/@epa-wg/custom-element@0.0.14/demo/external-template.html
Owen Buckley
1:22 PM
HTML Modules === seperation of technologies, if you're into that thing, and as a companion to DOM Parts?
Rob Eisenberg
1:22 PM
I also have a prototype of HTML Modules, but it's coupled with DCE and DOM Parts-based templates. I didn't see why I would bother with it otherwise. (The prototype I have is a compiler that turns a declarative format into a JS module.)
Sasha Firsov
1:22 PM
@Owen, that needs own discussion if you open
Luke Dary
1:24 PM
I'm just looking for an import assertion with type = "html" that gives me a document.
Owen Buckley
1:25 PM
yeah Luke, that's where I was thinking of starting from
Luke Dary
1:26 PM
I wouldn't mind being included also.
Doug Wade
1:26 PM
If there's a signup sheet for a followup meeting on html modules, I'd like to come!
Sasha Firsov
1:26 PM
channel in discord?
Jeffrey Chew
1:26 PM
I also can at least help contribute use cases from the IBM side
Joseph Pea
1:26 PM
Additional Voice call would be nice
Sasha Firsov
1:26 PM
+1
James G
1:26 PM
a followup breakout call & a discord channel makes sense i think (would be interested to follow along at least)
Keith Cirkel
1:26 PM
I am happy to act in an advisory/mentorship capacity to each of these.
Owen Buckley
1:26 PM
+!
Steve Orvell
1:27 PM
+1
Owen Buckley
1:28 PM
thanks Keith, that would be very helpful
Joseph Pea
1:28 PM
JS in HTML!
Opposite of HTML in JS :)
Owen Buckley
1:29 PM
hehe
Steve Orvell
1:29 PM
sgtm
Sasha Firsov
1:29 PM
#html-modules
Luke Dary
1:29 PM
Just don't call them HTML imports, because that wording got thrown out before v1
Rob Eisenberg
1:30 PM
You can certainly have an html module that exports only templates. But I'm not sure why I would use that without dom parts because I'd have to turn around and parse/compile it in JS using some library/framework anyway. So, it seems better to just write it in an html tagged template literal to begin with. Hopefully that clarifies what I'm trying to say. I think a variety of things could be exported from an HTML module, just not sure why I'd use that if those things aren't usable ootb.
Owen Buckley
1:31 PM
got to start somewhere?  I think an HTML file that can be be imported as a template with placheolders that can then have those template string placeholders manipulated with a DOM Parts API could be a nice iteration on that starting point
Joseph Pea
1:31 PM
I think it is still reasonable to start without templates (but we of course want templates) because for example, we can choose implementation by writing `class extends TheImplementation` without any further JS, and the rest all in HTML
Brian Kardell
1:33 PM
someone give me a link the the rob proposal with a runnable?
Rob Eisenberg
1:34 PM
There's not a proposal officially for that.
I think it's a comment somewhere. We riffed on it a bit in a previous meeting.
It's something like this:
Brian Kardell
1:34 PM
where is it unofficially and how does it have to do with the scoped registries
Rob Eisenberg
1:35 PM
registry.run(() => node.innerHTML = "<custom-element></custon-element");
Nolan Lawson
1:35 PM
yes. this is what we would need ^
Joseph Pea
1:35 PM
I would love JS sandboxing for elements. But it seems like a very tricky thing to implement. It would need a way to decide what APIs are available in the sandbox (f.e. `.parent` could be set to always null, etc, so sandbox cannot get DOM outside of its own)
Brian Kardell
1:35 PM
I don't get it :)
like, how does that fit?  where does node come from?
Rob Eisenberg
1:36 PM
Basically, any elements created within the callback to run would use the registry that "run" was called on.
Nolan Lawson
1:36 PM
my comment on this: https://github.com/w3c/webcomponents-cg/discussions/73#discussioncomment-7007593
Brian Kardell
1:37 PM
excellent, thx nolan
Sasha Firsov
1:42 PM
people in CMS do not have JS option, DCE is only one
Joseph Pea
1:42 PM
Anyone here not following the existing concepts? If so, here's my concept which I've dubbed "element modules" as the focus is around making modules:
https://github.com/trusktr/element-modules 
It's good because the semantics are minimal, and similar to existing patterns from HTML-first frameworks like Vue, Svelte, etc.
The main problem we all want to solve: don't write JS if we don't need JS.
by "modules" I mean ES Modules with import attributes, like how CSS modules also hook into ES Modules.
Joseph Pea
1:46 PM
Alternative to HTML sandboxong Sasha is some form of JS sandboxing. Like a way for JS to manipulate an encapsulated DOM in a JS Realm without access to all global APIs, and a way to provide external APIs.
Sasha Firsov
1:50 PM
@Joseph Pea, scoping of JS is the problem in general for browser. It is needed, I agree. But not as argument in DCE.
Steve Orvell
1:53 PM
Sure, the sense was less code means less bytes, less bytes means faster/cheaper pages and these are user benefits.
Keith Cirkel
1:54 PM
I hope my messages come across as supportive; I would like to see success from this group. I want to make sure we're heading in the right direction for the right reasons.
Sasha Firsov
1:54 PM
less code = faster dev, reliable code(less bugs), JS dev cost is 3x larger of HTML dev
Brian Kardell
1:54 PM
I'd like to be clear that I do like the idea of dce in general, I just don't think that is a super compelling argument
Steve Orvell
1:55 PM
Yeah, asking hard questions is critical imo. +1
Keith Cirkel
1:56 PM
If the goal is less bytes there are many ways to deliver on that goal that might not be targeted toward web component technologies.
Brian Kardell
1:56 PM
https://github.com/bkardell/half-light/issues/1
If you have looked at this, even if you have provided some feedback already - would you plz emoji poll your feels on this? It has very low engagement, I'd like it in one place
You
1:56 PM
https://github.com/webcomponents-cg/community-protocols/pulls
Owen Buckley
1:57 PM
a shared DOM shim would a great topic IMO (re: community protiocols re: SSR)
Sasha Firsov
1:58 PM
SSR in DCE need to be part of SSR general discussion.
Michael Warren
1:58 PM
sorry i missed....got lots of work turmoil going on at the moment... :(
Joseph Pea
1:59 PM
SSR is like a Lamborghini: some people/apps can afford it. Most people/apps don't need it to get around. :)
Luke Dary
1:59 PM
You rock, Westbrook!
Doug Wade
1:59 PM
you did great! thanks Westbrook!
Steve Orvell
2:00 PM
yeah, thanks so much Westbrook!
Michael Warren
2:00 PM
Thanks! sorry to have missed it
Jesse Jurman
2:00 PM
Thanks everyone!
James G
2:00 PM
thanks all