Meeting minutes
Title: Web Components
https://github.com/w3c/webcomponents/issues/877
<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
<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.