Web Components

23 Mar 2020



(irc_only_atm, calling_in_in_a_few)
hober, annevk
hober, annevk, jan


<annevk> I can't hear anyone I think...

<annevk> Maybe Meet is shitty in Firefox?

<annevk> Oh, Firefox blocked autoplay, maybe that's what's up

<hober> i'm testing if you can hear us

<hober> fantasai is having trouble joining the hangout

<annevk> Where does it break down fantasai?

pin number is incorrect

<pmdartus> Are you trying to join via phone or via a browser?

via phone

<annevk> fantasai: ping should be 380 055 694 126#

<annevk> fantasai: per https://meet.google.com/tel/bbj-kxox-cra?hs=-1

annevk, thanks, half the numbers are missing from https://github.com/w3c/webcomponents/wiki/2020-Spring-Virtual-F2F#conference-call-information


<pmdartus> @fantasai: My bad, sorry


"pin doesn't match a meeting that starts soon, hang up and try again"

<annevk> sigh

<pmdartus> Let me try

Scoped Custom Element Registries

<hober> Scribe: hober

<Justin> https://docs.google.com/presentation/d/17n93FMAkis9uWendzKgsOj7DVgbqG2bcnkK6k3Vdu9c/edit?usp=sharing

Justin: we've been talking about this for a while, #715
... I made a PR, #865
... some details from our toronto discussion is there
... would anyone like to hear the motivation again?
... proposal is a new CustomElementRegistry()
... use shadow roots as scope

<scribe> ... new elements created in that scope use that scope

UNKNOWN_SPEAKER: if a shadow root doesn't have a registry, use the global registry
... scopes are determined at element creation time, elements don't retain a pointer to their scope
... add element creation APIs to shadow root

<masonfreed> https://docs.google.com/presentation/d/1L60OCYeXmxYmQGFP76IHWp8AyPRZAfj2DFtm8WC7VEI/edit?usp=sharing

<annevk> (that document is the public variant of Justin's doc, for context)

UNKNOWN_SPEAKER: registries can inherit from a single parent at construction time
... scoped registries create scoped element constructors

justin describes the example code on slide 5

Justin: parent and definitions in the options bag passed to the customelementregistry constructor
... and a method, getDefinitions()
... why use shadow roots as scopes?
... they're already the ecapsulation boundry
... plugs the leak of custom elements being defined today
... registry lookup is simplified from toronto
... either the shadow root has a registry or the global registry
... you don't automatically inherit from the global registry
... you have to opt in to inheriting
... scoped element creation

createElement, etc.

scribe: inheritance is live, so you can override one definition
... slide 11, constructors example
... when you call a constructor, you have to decide what scope to use
... aka what tag name to use?
... tag name is per-scope

<fantasai> For the minutes, here's the slide deck: https://lists.w3.org/Archives/Public/www-archive/2020Mar/att-0002/Scoped_Custom_Element_Registries.pdf

scribe: registry.define() returns a scoped constructor that you can use
... the scoped registry creates a trivial subclass, and you get the constructor for that
... i think this is the least bad way to handle this
... which registry does .get return?
... three constructors: one you pass in to define, what define returns, and what get returns


rniwa: two major feedback
... don't want inheritance, because global object leaks when cross-document moves happen
... shouldn't be creating new constructors

caridy: i hope we can focus on the MVP here
... maybe some of this can wait
... we've discussed this extensively
... just having a global registry is fine
... mitigations available today for authors
... we have concerns about getDefinitions
... returning the universe of registered elements is not something we have today
... inheritance, same thing. we can live without it for now
... component authors are in control now, so can do what they need to


ack rniwa:

Justin: right now we have an ecosystem of self-registring components
... there will be a migration to scoped
... maybe we shouldn't design an api for the migration period
... folks are hitting an error right now
... scoped registry fixes that right now
... some people are using dynamic upgrade patterns
... that will only work in scoped registries if you have live inheritance
... if you move to a scoped registry without live inheritance, you'll break other things
... i don't understand the problem with getDefinitions
... the registry has that internal list
... interested to hear more about that

<diervo> hober that's caridy again

<diervo> :)

caridy: on the migration path, will describe what we do today in a later presentation
... don't want people to have to change what they have today to accomidate scoped registies
... we don't have getdefinitions today
... you can only get the names that you know exist

Justin: if a custom element registry constructor takes both registrations, now we have a use case for getting entire sets of registrations
... look at slide 5 example
... now we have a use case for getting the bulk registrations so we can pass them here

caridy: you still know the names that you're concerned with
... getting all, even things you don't know or need

Justin: what's the concern with that?

caridy: you lose control
... we control the things we create
... if you have access to read all the other components, that would be a problem

<Justin> q

rniwa: live inheritance from global is fine
... if you have both that and inheritance, you have trouble

Justin: would you prefer a flag (inherit from global yes/no)

rniwa: flag would be fine
... the problem with inheriting from anything is you can mix multiple globals

Justin: can't you do that without inheritance at all? moving element from one document to another

rniwa: no, because adoption happens

Justin: oh, do we have to define how adoption happens if shadow root moves document?

rniwa: yes, and i don't know how you would do inheritance in that case

Justin: even without inheritance?

rniwa: yeah, it's a serious issue

Justin: i don't see how it can take along it's registry at all

annevk: if you have a class in global b, you can add it to global a's registry
... so you already have that problem

rniwa: this case is more complicated, because it's the definition that would be referenced by multiple globals
... this is not implementable

Justin: isn't this the same that we have with global registries now?

rniwa: currently, we only have to keep custom element definition alive as long as one global is alive
... with this change we'd have to keep all globals with a reference alive

Goffert: how does it work currently?
... right now, if you create a custom element and then move it to another document, it must have a reference to its original document's registry?

rniwa: can't remember offhand

annevk: the registry has to be kept alive because you can get the constructor from the instance
... so some aspect of it has to be kept alive at least

Justin: is this fundamentally a new problem from multiple registries?
... i think the difficulties are the same
... hearing from implementers that their may be other difficulties
... this seems like the fundamental issue to resolve in this issue
... is this a problem with all registires

rniwa: when inheritance is limited to global, and registries are tied to single global, this isn't an issue

Goffert: do we know of a use case where someone requires inheritance from a non-global registry?

Justin: not concretely, no
... some people have asked about having a bunch of components that depend on hundreds, do they have to define all of them each time
... never with a concrete example

caridy: we've asked for that in the past
... we dropped that a while ago, we're okay creating the registry entirely when needed

RobE: that last scenario, i can provide a use case
... on very large teams or projects, you can have a shell team that owns the global registry and compoents, and then feature teams want their own registry and compoents
... in the team only the globals and their own are visible
... i think it really only happens on really large projects

caridy: similar to what we do
... it can be done in userland
... which creates the registry that you want

Justin: feedback around the MVP idea, often we've done something so minimal they require more steps to become usable
... i want to release something that's usable in its first version
... i dunno if information hiding via the registry is a general use case
... salesforce uses these as security boundaries and i don't know how generalizable
... components you're not allowed to use so you want to hide their existence

caridy: it's about integrity, not security
... you don't want to link little internal components, like the icon in a button

Justin: you could use a scoped registry for that
... if no one else had a reference, they couldn't introspect
... that's one of the use cases for inheritance
... e.g. i'm fine with the global registry except for one private one

jan: one question for justin: maybe start with a flag "this scoped registry should inherit from the global registry of the document it's currently in"
... and that'd be it
... teams can build helpers that build up registries for larger teams like that, so they can manage the problem themselves
... "defer to the document" might be a simpler way to go
... always live, deferring to the current document's global registry

Justin: live inheritance comes down to: is the component aware of all its dependencies?
... i can think of higher-level components (virtual lists, renderprop pattern)
... the component doesn't know what it's rendering
... it needs to defer its registry
... virtual list is a primary example

rniwa: could you clarify?

Justin: list virtualizers stamp out the dom for each item, but the items give it the template to stamp out
... the dom gets created in the shadow root
... how does that component get the elements in the right scope
... say you have a shadow root, and in that shadow root there's a list virtualizer which has its own shadow dom
... the template is being handed to the virtualizer from the outside shadow root

rniwa: how is it getting the template?

Justin: it's passed in fro mthe component that's using it

rniwa: what does that have to do with inheritance from some other registry?

Justin: the list virtualizer may want to inherit from it's user's scope

caridy: this example is problematic because you are receiving a template that you have to instantiate but you also need to be handed the registry
... so you pass both of them

Justin: right, so without inheritance, the list virtualizer can't register its own components
... it'd have to use the one passed to it

caridy: it could run through them and copy them

Justin: how?

caridy: seems more reliable to explicitly pass them in than relying on the registry

Justin: a lot of simple elements know all their dependencies
... there are some highly dynamic cases that don't know all the dom they're going to create
... right now that works well
... one option is for scoped registries to only apply to static components

hober: describes event listeners as an example of a registry-like api that doesn't have getDefinitions

RobE: it would be good to get to a good MVP for this; for me, if we just have what's on slide 5, we can make things work for ourselves
... we can emulate inheritance by pushing definitions into things like this
... yeah, we do lose some of the dynamism
... but if we went with the mvp represented by this slide, i don't think we prevent us from adding such features down the road
... i don't want even the flag to inherit from global
... so that when we come back to this we don't need to work around that
... in addition to msft, i also work on the aurelia framework
... we explicitly chose not to use custom elements
... precisely because this feature was missing
... we needed a way to scope element definitions
... this feature missing was the biggest reason we couldn't use custom elements

jan: echo much of what RobE said
... the only reason i wondered about inheritance is innerHTML
... if you want to use createElement, you could call that on the local registry or document
... if no inheritance and you set innerHTML, what happens?
... want it to look in the scoped registry and then global

rniwa: i thought we had this exact discussion in toronto, and we decided to not do inheritance

Justin: in toronto i proposed looking up the tree of scopes
... i thought that was the thing to get rid of
... annevk had recommended a reference in the constructor

rniwa: that would have worked if you hadn't made inheritance live
... we have to keep all the registries alive
... if a custom element moves from one global to another, we only keep its definition alive
... in webkit

smaug: gecko too

hober: that seems like a pretty solid argument against live inheritance to me

Goffert: wanted to echo RobE's statment
... the essential part is what's in slide 5

<Goffert> https://open-wc.org/scoped-elements/

Goffert: the single global registry is causing us a lot of troble internally
... this solution for us is enough
... it resolves the problem we have with the single registry
... move ahead with this in a first phase, then add inheritance later

Justin: if we have agreement on everything else i could be okay with that
... in terms of the mvp
... if we can record that consensus and find someone to spec it

rniwa: shadow roots moving between documents is still a problem

caridy: are we okay with the new constructor looking up in the global registry only?

Goffert: that doesn't seem to be a problem from our side

Justin: if a shadow root carries a registry, and you can create new dom that references that registry, if you move that element to another document, have memory concerns

rniwa: yes, that's the concern

Justin: any ideas on how to address that?

rniwa: i don't know, it's tricky. it would be bad if the element stopped working, but i don't know how else you'd make it work

Goffert: is there not already a precedent?

hober: yes, e.g. <input> some of the time

Goffert: if you move a component to another document, and then it re-renders itself, it'll break if the new document's global scope doesn't have dependencies

tomalec: upvoting RobE on the MVP
... i work on smaller projects, even there, what is on slide 5 is useful and sufficient

diervo: how is moving things around different from moving things cross-document?
... when you move a component, it could throw
... or a no-op
... what would be different?
... throwing solves the corner case

rniwa: if you have a custom element registry, and you can retrieve the registry from the element, in the javascript sense, if you move the node with the shadow root from one document from one document to another, that registry is still identical
... if you get an element definition from that registry, it'll be from the other document, which is problematic
... we can't have different behavior depending on where that registry is referenced

Justin: you can pass constructors to a realm with a different document and call it
... and get an element from the other document
... how is this different from passing a map of constructors?

rniwa: it's different because a javascipt-exposed document is invovled

Justin: what about adoptedCallback? and you ahve to re-create it?

caridy: [scribe missed]

rniwa: if you have two elements that have the same registry, and you move one of them to another document, we can't return different results when those elements both interrogate their registries

Justin: what different results would it return?

rniwa: we can't make the registry itself behave differently depending on where it's referenced

Justin: the only thing is to get definitions from it, or to create elements
... is the problem that shadowRoot.createElement will retun elemetns from another docuemnt

rniwa: shadowRoot.customElements

Justin: how would it return different results in different documents?

rniwa: you can't

annevk: i don't think anyone's proposing such a thing

hober: i thought jan was earlier

annevk: i thought that didn't survive

rniwa: document A, create custom element registry in document A. elements E1 and E2 both use that in their shadow roots
... move E1 to document B
... both E1 and E2's custom elements refer to the same object
... === on the registry objects is true
... this is not something that's implementable in webkit
... because now you keep it alive from two globals

smaug: we can deal with this in gecko

Justin: is this true of any object you pass around?

annevk: how is this not a problem for event listeners?

rniwa: pure javascript objects aren't a problem
... e.g. event listeners

annevk: so the problem is element registry is C++ backed?

rniwa: yes
... pure C++ objects are fine too
... problem is a javascript objects backed by C++ object

annevk: what about custom elements?

rniwa: the owner changes

annevk: the owner changes but the global doesn't

rniwa: that's okay
... because the global association is done on the javascript side

diervo: i'm confused

rniwa: i don't think i can cover how webkit's gc works right now

caridy: is it a good compromise that you have to rebuild the registry in the adopted callback?

rniwa: that would be good but that means you first have to clear / deassociate

caridy: you mean the element that you appended to the shadow root

rniwa: no the registry object connected to the shadow root
... current propsosal is you have access to it

Justin: yeah, the customElements property would be available on the shadow root
... that doesn't seem to be that important
... it may be in the PR
... minor part
... that could be removed

caridy: i missed that i would object to that part

<masonfreed> slide 8

Justin: if an element's going to rebuild the registry, it needs to have a reference to the one to rebuild

caridy: [scribe missed]

Goffert: unfortunate part is there is no API to add a registry to a shadow root
... if you move an element and you have to recreate the registry
... can only do that right now at shadow root creation time

jan: could we introduce a new callback
... "you should register your elements"
... the callback would get passed a reference to the new registry

Justin: i'd like to timebox this here
... lots of questions about GC
... sounds like the current registry is a C++ object tied to the window
... maybe scoped registries is a differnt kind of object entirely
... just a map
... does it even need to be tied to a document
... it sounds like there's enough depth here i think we should take this back to the issue or to a new issue
... give implementers time to dive into this

jan: let people think about it tonight and talk about it tomorrow

Justin: we've taken enoug htime on this now
... can we at least move ahead with this MVP

room: yes

<annevk> scribe: annevk

Construtable Stylesheets

TabAtkins: yo
... a lot of the details have been worked out
... IDL now has observable arrays which should help us with all list things going forward
... there are still some questions about exactly what we want
... the big sticking point that's still being discussed (observable array is generally agreed upon)
... there's a question as to whether assignment directly to adoptedStyleSheets should work
... not sure I can fairly represent Maciej
... I expect other APIs to allow direct assignment, e.g., Typed OM, so it would make sense to allow that here
... Maciej thinks it's a bit of a footgun
... assigning would mean that it's consumed by the setter and the getter would return a fresh object

[This is what classList does too, fwiw.]

<rniwa> https://github.com/w3c/webcomponents/issues/759#issuecomment-521053064

rniwa: the argument for not allowing assignment is that it produces racy code

<Zakim> TabAtkins, you wanted to respond to rniwa

rniwa: I don't like that it's different from StyleSheetList [scribe might have missed a detail]

TabAtkins: the code example that rniwa pointed to is no longer useful
... that predates observable arrays
... today you can use .push() and add style sheets
... the only case that could be described as "racy" is that your subclass sets some styles without knowledge about your superclass, but that's dumb
... I agree that it's bad that it's different from StyleSheetList and therefore Domenic will investigate updating that to a readonly observable array
... we should make everything observable arrays [even if they're not arrays :p]

hober: That sounds exciting. We want consistency and a platform that minimizes footguns
... Domenic changing document.styleSheets to be a readonly observable array would be interesting
... is document.styleSheets assignable?

TabAtkins: no

hober: then it's not consistent

TabAtkins: they're different in that one is readonly and the other is mutable
... so push() won't work, but the APIs will have consistency

hober: in the subclassing case, if you're assigning in the subclassing case you probably have other mistakes, but I don't think we should encourage bad code and I think assigning would allow for that.

masonfreed: if you don't allow assignment, folks are going to use .splice and that introduces a worse footgun
... I think it makes sense to use this observable arrays pattern, but I don't want everything to be tied, shipping-wise

rniwa: I only agree if we do them together, both styleSheets and adoptedStyleSheets
... with assignment subclassing becomes a lot harder

Justin: I'd like to address the subclassing question
... any API that can be called on the sub- and superclass side has issues
... subclassing itself has all kinds of encapsulation issues
... if you subclass something you have to know what the API is and know that it can change
... this is not unique to array-valued properties, it's general

TabAtkins: following up on that, I fail to see how this is different from any other API
... we shouldn't scenario solve; no other API protects for this
... classList allows direct assignment

[Scribe notes there's a subtle difference in that it takes a string and turns it into a set, but yes.]

Justin: if you subclass a superclass that you don't think defines connectedCallback, footgun
... if you don't think it does attachShadow(), but then it does, boom

<Zakim> hober, you wanted to say re assignment v. splice: easy (and safe) things should be easy, hard (unsafe?) things should be hard. if you have to jump through weird hoops to do the bad

hober: I agree that there are other footguns
... the obvious and simple thing is dangerous, so I think it's okay that .splice() works if you know what you're doing

<fantasai> +1 to hober's design principle

<TabAtkins> r+

TabAtkins: It's important for authors to have as much as possible a consistent and easily understandable boundary
... Nothing about subclassing is safe and nothing is going to help with that
... special casing this for subclassing is bad
... it complicates the boundary between what's allowed and what's not and makes simple cases involved
... yes one could always use .push()
... but that's not consistent with anything else
... you want to assign an array because it's an array and because that kind of thing works elsewhere
... making this API awkward because of worries about subclassing while subclassing is inherently complex and not used as much is a bad call

diervo: you're all right
... I think people are used to the difficulties of classes already
... and making this API awkward to use to help with a small part of subclassing will long term have ergonomics drawbacks

jan: I'll agree with diervo
... I'd be happy if we'd allow assignment, but I mostly want the feature

rniwa: I don't think there's consensus and we should move on to other topics

TabAtkins: I think we need to make a decision

hober: there is no Web Components "group"
... features are defined in the WHATWG
... and some in CSS

TabAtkins: adoptedStyleSheets is a CSS spec and it'll be part of the CSSOM

hober: CSS WG should probably make the decision then

<fantasai> possible option: file it as an issue on the TAG?

TabAtkins: I'll make sure it shows up on the CSS WG agenda
... likely will be discussed this Wednesday

rniwa: fantasai suggests to file an issue with the TAG

hober: I think we should let the CSS WG discuss first, then escalate

jan: I've added summaries in the live agenda for topics discussed
... please contribute so people don't have to read the minutes

RobE: we just want this API, gimme

masonfreed: we need to make sure whether or not we tackle document.styleSheets and document.adoptedStyleSheets together

rniwa: to that point, it's great that people are interested in this API
... the resolution in the CSS WG last time was a mutable StyleSheetList
... then observable arrays came along
... I find it hard to reconcile the various things that are happening

Justin: Google has multiple voices

rniwa: that's frustrating
... this isn't moving forward because we keep reneging on agreements

TabAtkins: given that observable arrays got done it seems good to adopt it rather than keep doing the bad practice of *List classes

hober: closing the queue after masonfreed

masonfreed: everyone wanted something better than *List, but it wasn't there, but now it's there

hober: break?

<Justin> +100

<Goffert> +1

<smaug> break, please

hober: we resume at :25

<masonfreed> Slides for declarative Shadow DOM (up next, I assume): https://docs.google.com/presentation/d/13qsQ5y1m7DXKtoEd0vAqr3iKpLQs0Fpqli-0RFyvSxs/edit?usp=sharing

<fantasai> ScribeNick: fantasai

Declarative Shadow DOM


masonfreed: First main motivation is to allow ppl to use Shadow DOM in no-JS environments
... E.g. server-side rendering
... also Search Engine Optimization
... and also developing CSS in a design system that prohibits JS
... Second main reason is ergonomics
... if you just want to use for style scoping, shouldn't have to resort to using JS
... if used to just using CSS and HTML, why use JS if don't need to
... Also allows ppl to write HTML markup that represents the shadow DOM
... We have varying notations for annotating shadow DOM
... let's just make it straightforward and write HTML
... Tagged into same proposal couple other things
... .innerHTML currently can't represent shadow root
... and also [...]
... Proposal is to re-use the <template> element with a new ?
... It gets re-used, contents become the shadow root

Slides archived at https://lists.w3.org/Archives/Public/www-archive/2020Mar/att-0003/Declarative_Shadow_DOM__WC-F2F.pdf

masonfreed: new proposed API is

element.getInnerHTML({ includesShadowRoots: true})

masonfreed: returns markup inlcuding the <template> element
... Lastly, I withdrew the thread and pulled out thought of contentious points
... Ones I've heard were...
... First, do we need to do this?
... Second was, what to do about styles, particularly adoptedStyleSheets?
... Unclear how to deal with that problem / how to solve here
... my proposal is to not solve that problem just yet
... There is discussion of bikeshedding: re-using <template>, or using a new element like <shadowroot>, vs creating a template and referencing it
... Long discussion about hydration
... How should component be implemented to detect properly whether there is content there, if matches expectations of the comonent
... lastly, whether to allow this to be used through DOM APIs, or is this parser-only?
... That's it for presentation

<TabAtkins> fantasai: One thing I didn't hear is, it looks like you ahve to put the entire contents of the shadow root into the markup of every single element that is gonna have that thing attached

<hober> fantasai: one thing i didn't see addressed here is you have to put the entire contents of every single element that will have it

<TabAtkins> fantasai: I think that might work fine fo rpeople trying to do this in a templating engine serverside, but

<TabAtkins> fantasai: Then you have the same problem as we had in the 90s, a lot of stuff getting repeated across the document.

<TabAtkins> fantasai: So I don't see people coming form a css perspective, I'd want to define it once and use it everywhere

fantasai: attach it with selectors, etc. like CSS

masonfreed: It would be boring if every component was the same

<Zakim> annevk, you wanted to ask about getInnerHTML()

masonfreed: The contents would be different, so need to do it separately each time

<bkardell_> can I add a typed question/comment? I find it strange if the template element is removed - I don think there is kind of a precedent for your light dom to change... t dont understand why it has to? Could it not even react to changes? Seems doable?

annevk: getInnerHTML doesn't work for closed shadow roots
... earlier for selection, we had pattern where you pass in a list of shadow roots
... if you know about a closed shadow root you can pass it in and get serialized, would be nice to adopt as well

masonfreed: so argument to pass in known closed shadow roots?

annevk: just one serialized shadow roots, and would ???

Justin: Wanted to bring up point, talked about use cases
... server side rendering is high, but another came up recently
... Shadow root breaks ability to serialize a page, and have something that roughly renders as your page

<bkardell_> should I q plus or will you put my question above in the queue hober ?

<annevk> getInnerHTML would take serializeShadowRoots or some such and that would take an array of ShadowRoot instances that can be serialized (which can be either open or closed, since the caller knows about them)

Justin: one way to look at this feature, bring back the ability to serialize a page into some rough shape
... know JS won't be there, event listeners won't work, but have most of the page structure and style there. Can archive it and render later.
... This brings back the ability to serialie a tree including shadow roots, and this seems important to have
... Relating to fantasai's comment about whether or not to write in all elements, I thought too
... server-side rendering
... won't be written by hand very often
... So might seem verbose in some ways, but I think that's the way of server-side rendering

<hober> bkardell_: i'll ask your question if not

<bkardell_> I am, it's ok

Justin: later can get to template instantiation which is more compact

TabAtkins: Supporting what was just said, I think there are 3 distinct cases
... declarative shadow roots solve two, declarative custom elements another
... One is serializing
... can be done by templating library, repetitition doesn't matter, just sending things over the wire just like raw HTML
... 2nd is using shadow DOM as style encapsulation layer
... just like you write out your HTML page, and say "this chunk is styled on its own, don't let other things style it"
... This handles that just fine as well with only just a tiny bit of extra syntax for isolation
... Final bit, wanting to establish a common set of DOM for a repeated set of elements you want to use
... don't want JS to run
... that's declarative custom elements
... Ability to say all my blog posts have this structure, pls transform into this DOM tree
... maybe add JS, maybe not
... That case is not great if you're doing this by hand, just declarative shadow DOM
... but that's a separate feature
... but first two, particularly pinpoint the style, is handled
... This works well for the things its designed for, other bits are worth worrying about but not atm

bkardell_: Looked at explainer some time ago, unsure if changed since then
... I think in the explainer and in your slides, the template element disappears
... and gets created as shadow root instead?
... that feels very unprecedented and strange to me
... feels better if it didn't disappear?

masonfreed: Discussed on thread and off
... One is, structurally it is strange, but then also so does the shadow root
... if you look at screen right now, there's a natural equivalence
... there are some technical issues as well
... if you leave <template> node around, it's still around. What happens to its contents? is it still there?

bkardell_: My expectation is that updating it would update the shadow DOM

masonfreed: that makes implementation complcated
... implementation difficulty was a big issue
... but as presented here, fairly trivial to implement
... implementation would get quite a bit later

annevk: Don't understand your suggestion.
... can't have both a <template> element and a shadow root

Justin: Expected template.reference would point at shadow root, but forget problems with that

bkardell_: That's what I was thinking, don't understand the flaw
... Is aid what Justin said was what I was thinking, it's sort of a document fragment like ??
... Justin said some technical problems with that
... Would be great if somebody explained it

Justin: What I had thought was if literal reference, template.content, points to shadow root that it induces
... template.content instead of shadow root is a document fragment
... live updates would just be updating shadow root
... follow existing steps to do that on the content as well
... I forget technical problems with it...

annevk: where is template element?

Justin: presumably still where it was

annevk: if the template element is still there it would get slotted which is just not feasible afaict

<bkardell_> ah I see :)

<bkardell_> thanks annevk, that is the obvious bit that I was missing

tomalec: Concern that it would show up in children list, while shadow root is not a child node of an element
... One of the use cases I had was not only for custom elements, but native elements that have shadow roots, multiple shadow DOM
... majority of use cases I had was not only for CSS scoping, but style scoping
... scoping CSS rules, but also adding structure individually for each container in bigger apps
... encapsulate and separated from each other
... HTML developers are not JS developers, can finally use feature of encapuslation
... this is a role that was quite popular in my previous company, HTML dev with minimal knowledge in JS

caridy: My comment here is mostly advocating for the output
... creating a component, shadow declaratively attached, about to attach a new one, but ? if conditions
... could work out in ways that don't introduce extra ??
... maybe have access to declarative shadow root attach that doesn't conflict with attaching new one
... throw away existing one
... things like that could do
... components out there today woould not work with this
... if they become part of server-side rendering
... even serialization
... wouldn't work because script doesn't know the serialize
... need to work out those details
... have many use cases for this, but more details need to be solved

rniwa: I don't think we have clear path for server-side rendering is ?
... Last iteration had some bugs, don't have data on that
... If the only reason is to perf, don't think it's worth
... the argument that people want to just write html and css is way stronger at this point
... Wrt upgrading custom elements with declarative shadow DOM attach
... Either replace shadow root when you attach as Caridy suggested
... or alternatively when you attach shadow root with constructor, do special one-time transfer
... instead of creating a new shadow root, return the existing one created by declarative shadow root
... That would allow DOM, in case of server-side rendering want to make functional, don't have to recreate everything
... if you replace shadow root, have to recreate
... that would be a significant perf cost
... Don't think there's any base to argue perf
... but if you did this replacement, perf definitely worse because doing twice as much work

Justin: Want to refer to a few points
... wrt purity and ocmponents and booting up with/without shadow root
... I don't think server-side rendering is really that possible for components in a way that's uncoordinated with the component def itself
... you either need full DOM emulation to drive lifecycle of element
... or you have some kind of coordination and cooperation between definition and server-side rendering

<rniwa> s/??? is way stronger at this point/ease of use and people who only know HTML are way stronger points/

Justin: We have systems at GOogle that translate component to other language to do server side rendering
... so I think components have to be written in a better way for library
... ... but only if written for that in the first place

<pmdartus> Agreed with Justin. Components need to be aware of SSR to be compatible.

Justin: not case that component has to deal with case of suddenly ??

caridy: take React component and get it to work on the server side

Justin: don't just work
... you have to get a subset
... and there's a very specific React renderer for toString, different from DOM render

caridy: Do I need to take extra precaution, add if statement, etc.

Justin: for majority of authors, no
... not going to write currently practical renderable components without helper library
... will extract whether or not shadowRoot is there or not
... library will ask, do i have shadowRoot? If not, attach, if so, already done server side so skip
... React breaks the component encapsulation because it can query for the vDOM for each an every components in the page.
... No system you ask webcomponent for template, doesn't exist

caridy: ?? server side, not accurate

Justin: I think at least until we get template instatiation and declarative custom elements, whole orchestration and serialization and booting up on client is going to be very library-specific for each component
... can have multitude of components on server
... have ability to boot up DOM
... towards SSR use case, we have a lot of potential customers who want to do design system in component
... but do this server-side, so need SSR
... We want assurance that can boot up to first paint at least without JS

masonfreed: Last one talking about, seems only backwards-compat way to do this is to make that attachShadow deletes the existing contents of declarative root
... don't think can return existing shadow root with all content
... component doesn't know about new delcarative thing
... One where you blow away existing contents and give new one makes sense to me

caridy: I'm good with that, I'm good with some of that
... what I was suggesting not just whatever you have, might give you access to that declarative intent of hte shadow root somehow
... if you want to pick up the pieces and maybe re-use
... maybe use different API

masonfreed: that's what I wrote in issue, if want to get more complicated, either get existing contents or blow away, something in between, authoring thing

caridy: attachShadow and ? call from outside, need to be careful

<masonfreed> +

<TabAtkins> fantasai: I didn't quite udnerstand why "this is gonna solve the problem for people who want styling, but you ahve to make markup changes"

<Zakim> hober, you wanted to say something

<TabAtkins> fantasai: I think this won't be ocmfortable for CSS authors to use

<TabAtkins> masonfreed: Can you clarify what you might see it working differently?

<TabAtkins> fantasai: Unsure. Point is just that 8if you want scoped styling; the previous scoped styling and this one requires duplicating markup changes doesn't seem great

rniwa: Problem with ? approach
... right now <template> content is special
... contents is document fragment, question why not point to shadow Root because tha'ts also a doc fragment
... doc fragment held by <tempate> right now is special, not same as other doc fragments
... if we change suddenly to be a shadow root, we're streaming content directly from parser to content of shadow root
... and don't think that's something we wnat ot do
... exprience with <Template>, even after 7-8 years after implementing, still finding security bugs

<bkardell_> fwiw, the slot thing annevk mentioned was enough for me :)

rniwa: not attainable to create something similar to that but different
... another point is that, I think the one thing we have to tackle still is that ...
... when the shadow root in HTML becomes something visible from script

masonfreed: +1 to what rniwa said about complexity of leaving <template> element in and security issues etc.
... wanted to ask, only reason I've heard about leaving it in is that it's weird that it disappears
... are there *use cases* that go away if we make it disappear?

<bkardell_> a shadow root is new but doesn't affect your light dom

jan: I could imagine something having to do with having to use an existing framework that's not written to use shadow root, and want to shim shadow root in ...

Goffert: Unsure

<bkardell_> masonfreed, that was to you "a shadow root is new but doesn't affect your light dom"

Goffert: If you render from template, but also use template to exist, could do it twice.
... [missed]
... Still have capability if required
... If you require template to exist after shadow root exists, could create duplicate, one <template> becomes shadow root, other stayes because it's a <template> element

Justin: Want to unwind to beginning
... in the past some reluctance was implementation complexity and question of demand for it
... we have customers who have to have it for SSR
... But regarding implementation complexity, but see if re-using template element like this is implementable, does this unblock us from that point?
... Previously objection was don't want to create a new element, new parse mode
... does using <template> solve that?

<hober> annevk: I'm not sure

rniwa: Specifically asking what masonfreed proposed?

Justin: yes
... had discussed new element before, does using <template> solve some of the implementation complexity and risk issues?

rniwa: Does
... Still has cross-side reflection something..
... basically, can still do script injection
... content of template elmement used to not ?, but now it could
... so new security hole here

Justin: wouldn't that also require control over <template> attribute, not just contents?

smaug: wanted to mention something about <template> element disappearing
... might be problematic during transition, e.g. Firefox ESR vs latest
... scripts expect some behavior

Justin: you'd have a polyfill, it would remove the <template>

smaug: so all websites would need to use polyfill

masonfreed: or would'nt show up , and have to rely on existing hydration

hober: exhausted queue, any other points ppl want to make on the topic?

?: Talking about our desires for customers, but mention a couple things that our customers would like to see but unsure if feasible

?: one is streaming, ppl want to use something like this to get fastest possible time to first paint for components

Justin: can we make this streamJustin
... don't know if possible
... Question wrt integration with constructible style sheets

<Goffert> I have an urgent issue from work I have to attend to, so I will leave this meeting for today. There are no upcoming proposals/issues on the agenda that I want to attend particularly, so no need to account for me with planning. Good luck for the rest of the day

Justin: Would like feature of attribute in template that refers to style sheet or style tag that's written out earlier in the page, and style tag maybe has different 'type' than text/css, and gets automatically adopted into that shadow root
... Shadow roots tend to have subtle differences, but styles don't typically
... So we would get some savings by referring to a single style tag

rniwa: Wanted to re-iterate my point, proposal solves the main parser issues
... that was contentious pieces we discussed
... in case of shadow root, not way to get old one and no way to attach new one
... we need a solution there

<hober> qJustin

<annevk> qJustin

caridy: [missed]
... we could use element.internal to expose the content sof shadow root used
... could then do hydration that you want

Justin: As a library author that would directly use API, don't see this as an issue
... our base class will check for a shadow root, and if sees one considers it server-side rendered

annevk: closed shadow roots is what we were discussing

caridy: if it was closed, can't access it

Justin: would you return closed shadow root in ?

caridy: In the past, we talk about even allowing access element.internal can access shadow root
... no matter closed a lot
... this seems to be aligned iwht that

annevk: I like the idea of caridy

bkardell_: Not sure how I want to articulate this, but hearing rniwa talk...
... thing about it disappearing, and that being weird for shadow root,
... different in that it doesn't affect your light DOM
... whether JS runs or not, light DOM is light DOM
... changing your light DOM at some arbitrary point in time is the thing that feels strange to me
... I don't specifically have a concrete objection, but that's the part that feels weird to me
... becomes harder to reason about DOM, what's the nth child, etc.

masonfreed: Shadow DOM would be converted upon closing tag, that's a defined point in time

bkardell_: this is a ? element, so depends when you register element, but I guess proposal is to be a first-class element?
... think I misread

<Zakim> tomalec, you wanted to ask about scoped registires for declarative SD

bkardell_: so maybe not an issue

tomalec: Ask if you thought about how to couple that with scoped custom element sregistry,
... could you attach scoped registry to declarative shadow DOOM?

masonfreed: haven't thought of that as an open proposal

Justin: great question

<bkardell_> s/there is a ? element/there is a dasherized (custom) element

Justin: i think at the very least, in order to prevent a document from booting up and pulling in global definitions, would need to have an attribute that prevents upgrades
... or that going to get a scope registry
... At parse time, a lot of things happen before visible to script
... ....
... before light DOM changes
... wrt custom element registrations
... document boots up before components registered at global level
... ... we have to think about this, really good question
... [missed situation]
... I think Mason and I can get together and propose something

??: Not doing inheritance, maybe don't do anything until I attach

?caridy: Introduce callback to give better control over timing?

Justin: in case where all this happens at parse time, maybe simpler timing model here
... can do a lot of stuff before script runs
... in cases where this is dynamic, using innerHTML, have to be more careful
... might be as simple as an attribute that says shadowRoot will get registry later
... and will need way to add registry to shadow

?: Decouple ?jan and scope registries for this propsal

Justin: Any arguemnt to attachShadow has to have some affordance in declarative markup
... This applies to everything

masonfreed: Seems we need to summarize

<Justin> Sorry fantasai. Thanks for scribing!

<jan> fantasai, Sorry, and thanks

masonfreed: need to make some affordance for attachShadow with declarative shaodw attached
... and also ?????
... Respond ot Justin's point, streaming is important, because it does attachShadow at the closing tag, doens't support very well
... also style attach
... agree with both points, hoping to do follow-on proposal, think we can solve in the future
... Scoped custom element registires, that's an issue we do need to solve
... how does that handle existence of declarative shadow root

rniwa: I think if we want to solve streaming, have to solve now
... don't think we want two different versions of AIP

masonfreed?: Seems like that could be solved with attribute on <template>

rniwa: It would be insane to change behavior of parser based on attribute

??: would you be ok implementation-wise if we define this as streaming, and opens the document as a live shadow root?

rniwa: no, no!
... but if we're doing streaming; I don't think we should do it
... can't solve problem in the future

masonfreed: So in that case approach we take is the same

jan: Caridy mentioned exposing shadow root on element.internals
... seems oculd be split off as separate proposals
... is there an existing issue? Should i create one?

caridy: Think one from domenic from long time ago

hober: if you can't find, make a new issue

[time check]

Web Components Integrity

<westbrook> caridy's slides: https://docs.google.com/presentation/d/1ugqScaGIHdaXDgHVFaOKicoWFebifszq_MCJoFWvBnY/edit#slide=id.g71ca93c083_1_2270

<hober> scribe: jan

<bkardell_> is there a link to more about how you are doing this you could share ?

caridy: I can share some of the pieces of this infrastructure and the demo

smaug: What sorts of performance issues and bugs do you see?

caridy: We think we can gain a lot more with proxies for the part of the membrane implementation
... it takes time to create the iframe and detach it, after that things are pretty good
... the perf hit is considerable, but at the same time you don't have hundreds of these buckets (namespaces)

justin: this feels closer to iframes than shadow roots, like a new primitive
... or we could add features to iframes
... you're going after a DOM isolation problem, what's the delta with iframes?

caridy: We decided to spend not than much time on the DOM isolation and more on the integrity
... I think the encapsulation of the shadow root gives us some encapsulation
... Integrity is more about things like polyfills

tess: generating a list (comparing iframes to realms) would be useful

[end of topic]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2020/03/23 19:03:03 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/if no/... if no/
Succeeded: s/eys/yes/
Succeeded: s/jan:/TabAtkins:/
Succeeded: s/??/Justin/
Succeeded: s/??/tomalec/
Succeeded: s/???/if the template element is still there it would get slotted which is just not feasible afaict/
Succeeded: s/parse/perf/
Succeeded: s/???/the argument that people want to just write html and css/
FAILED: s/??? is way stronger at this point/ease of use and people who only know HTML are way stronger points/
Succeeded: s/??/caridy/
Succeeded: s/instead of returning shadow root would return ????/instead of creating a new shadow root, return the existing one created by declarative shadow root/
Succeeded: s/Every React system ?? vdoc/React breaks the component encapsulation because it can query for the vDOM for each an every components in the page./
Succeeded: s/styling/styling and this one/
Succeeded: s/???/Goffert/
Succeeded: s/????/Goffert/g
Succeeded: s/masonfreed:/masonfreed,/
Succeeded: s/?/Justin/
Succeeded: s/?/Justin/
Succeeded: s/?/Justin/
Succeeded: s/?/Justin/
Succeeded: s/?/Justin/
Succeeded: s/?/Justin/
Succeeded: s/?/Justin/
Succeeded: s/?/Justin/
Succeeded: s/?/Justin/
Succeeded: s/parity/caridy/
FAILED: s/there is a ? element/there is a dasherized (custom) element/
Succeeded: s/??/caridy/
Succeeded: s/???/jan/
Succeeded: s/?/jan/
Succeeded: s/fantasai:/fantasai,/
Succeeded: s/??/masonfreed/
Succeeded: s/??/smaug/
Present: (irc_only_atm calling_in_in_a_few)

WARNING: Fewer than 3 people found for Present list!

Found Scribe: hober
Inferring ScribeNick: hober
Found Scribe: annevk
Inferring ScribeNick: annevk
Found ScribeNick: fantasai
Found Scribe: jan
Inferring ScribeNick: jan
Scribes: hober, annevk, jan
ScribeNicks: fantasai, hober, annevk, jan
Agenda: https://docs.google.com/document/d/1lpy6k_ZlI5iVo-Y0vJaDfFAQvYRjpZqUcSlnOex2A0Q/edit#

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)

[End of scribe.perl diagnostic output]