<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
lol
"pin doesn't match a meeting that starts soon, hang up and try again"
<annevk> sigh
<pmdartus> Let me try
<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
ack
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
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
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
https://docs.google.com/presentation/d/13qsQ5y1m7DXKtoEd0vAqr3iKpLQs0Fpqli-0RFyvSxs/edit?usp=sharing
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]
<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]
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]