26 October 2020


Balter, bkardell, boazsender, Clark, Dan, Dan Clark, Eisenberg, Hidde, Jemma, jensimmons, Joshue, Joshue108, justinfagnani, kenchris, Leo, Leo Balter, masonfreed, plh, Rob, Rob Eisenberg, slightlyoff, smaug, zcorpan

Meeting minutes

Title: Web Components


<zcorpan> Simon Pieters, Bocoup

ryosuke: any topic to discusss at this meeting?

<jensimmons> Jen Simmons, Apple

brian: can we do them in reverse order?

ryosuke: sure

Mason: also, we can talk is #45

<bkardell> https://‌docs.google.com/‌document/‌d/‌1tWvWBuPtQiJFhOEEfMiLtPZuxag1CV_tbTJHE187B_g/‌edit#heading=h.9ut5sja3keva

<leobalter> https://‌docs.google.com/‌document/‌d/‌1tWvWBuPtQiJFhOEEfMiLtPZuxag1CV_tbTJHE187B_g/‌edit#

<leobalter> You've got my by the hair, bkardell

SVG unknown element

Brian: SVG and MathML are both in HTML spec under embedded content

[Brian Kardell, Igalia]

Brian: they lack basic IDL definition until recently
… SVG has the concept of SVGUnknownElement
… Igalia would like to do the same for MathML
… both of those are interested in taking advantages of custom elements and ShadowDOM

Justin: this is related to do custom svg element in the future
… we've been working on a polyfill
… SVGUnknownElement is spec'ed out in SVG 2.0
… make it behave like a g element
… would be prefer to custom elements
… but nobody working on SVG anymore, and no implementation for SVG 2
… so I wanted to check in
… and if anybody knows what's going on

Tess: I agree with Justin. SVG is not high priority for implementers

Tess: SVG has 2 kinds
… SVG document as an XML doc
… and inline in HTML
… in the XML, it's obvious
… in the HTML, less obvious
… wouldn't you get HTMLUnknownElement?
… are you proposing to change the HTML parser?

Simon: when you have an SVG start tag
… so any unknown elements get the SVG namespace

Tess: so the only would be in the SVG space.

Simon: it would appear in the DOM inteface

Alex: wouldn't be a breaking change?

Simon: not aware of any

Brian: I agree it's not making changes to the parser
… worked for our prototype in MathML
… would be the same for SVG
… we are interested in SVG and are actively implementing
… so it's about going through custom elements and shadowDOM

Anne: Wouldn’t there be a change to the parser given that it introduces script execution at those points?

Simon: script execution doesn't really match what browser implementers
… we'd need to update the spec anyway to match implementation
… for the DOM interface, it's not a material change to the HTML parser
… script eexcution would need to change

Olli: list of possibilities or problems? like IDref?

Justin: there are several SVG issues in the webcomponents repo
… should we readjust them and/or open new ones?

Olli: having the big picture would be useful

Brian: is there any interest to do that?

Justin: it seems a big downside to the world at the moment. blocking use cases

<slightlyoff> +1 to making this possible

<Westbrook> +1 to making this possible

<bkardell> +1 to moving on - I thought it would actually be quicker than that :)

Ryosuke: let's move next topic. maybe best to open issues and track them

Justin: there are some issues open already

Ryosuke: have an umbrella issue

Scoped custom element registries

(Justin presents slides)

Justin: idea to create a registry, associate with shadowroot
… shadowdom is scoped to a registry or not

Justin: seems good consensus on the MVP
… some open question
… #895
… Upgrade Ordering

Justin: would be nice not have to walk the entire document but just a subtree

Rob: status on how this would interact with declarative shadowDOM?

Justin: still open question
… [quoting Ryosuke]

Ryosuke: what about constructors?
… not making constructors would be ok?
… there are some ways when we couldn't make it to work

Caridy: that case would be tricky, ie refactor hassle
… we focused on MVP
… there are some ideas for the future
… we wouldn't add more features unless people ask for them

?: if you register a constructor in the registry, what do you get if we're not supporting constructors?

Justin: you get the same constructor you passed to it
… in order to preserve backward compatibility, constructors are assumed to only work if they are in the global registry
… in the future, if we want it to work, it would have to be a different API call
… we want some kind of consistent behavior here

Caridy: yes, many holes there.

Ryosuke: in terms of solving this problem later.
… each constructor can only be register with at most one registry
… if we don't do that, we would forever close a path
… one way to have a proxy

Ryosuke: if we allow same object with multiple registration, I'm afraid of having an API that would prevent future solutions

Brian: so prevent the same constructor to be registered in different scope?

Ryosuke: right
… we could have a proxy or prevent multiple registrations

Brian: agreed

<caridy> Brian->Caridy

Justin: s/Brian:/Caridy/

Justin: image you have a class that is not registering in the global registry. if it gets used in an other package, the registry could fail

?: it feels like adopting Ryosuke doesn't prevent from changing in the future
… we can continue to work on this problem

Justin: the multi-actor hazard might be an issue
… this solves the constructor problem however
… I'm inclined to say that, with this solution, we would get callable constructor

?: I'm happy with that. we need to agree on the definition of MVP. is it small enough to try it out?

Ryosuke: let's wait on what to do until we get more feedback?

Justin: fine with this. newable constructor aren't that important. most things are created by createElement
… I'm fine with this restriction for now

Proposal: registration only accepts constructors that haven't been registered yet?

Justin: we should be able to merge my PR

<Rob> I don't think this combination of constraints is going to work.

Justin: and we can track that one decision separately

<Rob> I'

<Rob> I'd like to get a word in real quick.

Rob: if we have a situation with no inheritance and single registry, you'll have problems when you can't use the component
… eg a button

?: you would subclass the button

?: or proxy

<Westbrook> This means that is any of the code in your page uses scope then likely ALL code in your page needs to do this, which feels really forceful.

Justin: without subclassing, we don't have a way to introduce a constructor in a particular scope
… I'll open an issue on this

Ryosuke: can we agreement on restricting the registry?

Justin: fine with me

Next meeting

RyosukeL CSS script modules will be discussed in a different session

Caridi: what about the ordering issue?

Ryosuke: let's take it offline

Justin: I'll open separate issues
… after we merge the PR

<Rob> We need to keep discussing this issue of ctors in multiple registries.

Minutes manually created (not a transcript), formatted by scribe.perl version 123 (Tue Sep 1 21:19:13 2020 UTC).


Succeeded: s/realted/related

Succeeded: s/Iagalia/Igalia/

Succeeded: s/static/declarative/

Maybe present: ?, Alex, Anne, brian, Caridi, Caridy, Justin, Mason, Olli, ryosuke, Simon, Tess, Title