Participants:

Phillipe Le Hegaret, Steven Bougon, Ben De Kosnik, Todd Reifsteck, Gilles Dubuc, Nic Jansma, Will Hawkins, Beng Eu, Alex Christiansen, Ryosuke Niwa, Ilya Grigorik


[yoav] Next call: we’ll determine at F2F

F2F

[yoav] Please sign up

… note that we have two different forms, you need to sign up on both

… first day will be split into two parts

….. first half of the day we have external participants sharing use cases, gaps and needs

….. second half focused on new platform features and areas we need to focus on

… anything missing on the agenda?

[ryosuke] for the use cases, what worked well for the web components f2f is presenting both how current APIs are being used (what works), not just wishlist of things to add

[todd] the goal is to get people to present how they’re using, plus where they had friction

[ryosuke] lgtm

[ryosuke] do we want to talk about how to (re)structure our spec work?

[yoav] we can recap our state at the end of the day

… CDN representation: we have Nic, but we’ll see if we can find others

… for the second day, we have ~8 people registered so far for issue hackathon

… if you can or willing to join, please subscribe on the form

[plh] I’ll be there

[ryosuke] I’m TBD for second day, will be there on first day

… btw, TPAC schedule is out, we should planning the agenda

… we’re meeting Monday and Tuesday

[yoav] yep, we can kick that off after f2f

Element Timing & Shadow DOM

[npm] element interaction with shadow DOM: issue

… the issue is that some components may be very large, which hide a lot of details

… on the other hand, there is encapsulation

… one proposal is to have the PO be scoped to shadow root instead of window

… this way the web component author can scope and then expose up to the document

… another approach is to treat elements with open shadow as something we can report

[yoav] is the problem clear?

… for RT, we expose fetches made by encapsulated logic

[alex] it would be useful to know where one would want to hide this information?

[todd] would it make sense to ask a couple of big folks using this?

… alternative, we can start by not exposing

[npm] agree, good idea to ask major users

… but they may have different opinions from those who distribute components

[steven] I can check with our team (SalesForce) to get their feedback

[ryosuke] getComposedRange approach might be a route to investigation

… maybe there is a way to add getEntries / PO could take a list of shadow roots that developer has access to

Registry vs registration model

[yoav] discussed on the last call, Philippe created a note to create the registry

… Ryosuke chimed in favor of registration model?

[ryosuke] registration model could work, I was echoing Boris’s concern that if we just have one list that advertises that features that may not be supported

… but if we have tests in each specification

[plh] we could add false positive test on the registry spec itself

… I will add a test and move forward on publishing the registry

[yoav] we also talked about other parameters, but we could add those later

… e.g. buffered flag and number of entries

… but that is non-blocking

[plh] can you please file an issue to track the above?

… I will setup auto publishing

… any objections?

+1’s from the group — onwards!