Web Components -- 26 Apr 2019

<bkardell_> who is speaking now?

<annevk> scribe: Ruphin

Moving to ::theme topic

Justin: There current state is that ::part has some current agreement
... The current implementation seems useful, it reduces the need for custom css variables
... The problem is mostly with deeply nested items and styling subtrees
... The question is if parts should be exposed higher up the tree implicitly
... The problem with that is name collision, if you use theme or part on a node there is no way to differentiate between children

Anne: It looks like we don't have a concrete proposal and we're just in a brainstorming stage
... It seems like we have a namespacing problem, similar to what we tackled with custom registries

Justin: There is a spectrum of use cases. One extreme is a world where everything in an app is constructed by the same vendor and they have full control so they just want access
... The other end is an application that uses many external components and there needs to be some form of communication/coordination

Brendan: Salesforce certainly needs some form of namespacing to prevent things from external parties leaking through the application

Rniwa: It seems like we have two usecases: One where you want to globally style an entire app, like giving the whole app a 'dark' theme. The other usecase is styling all instances of a certain element, like making all the buttons blue
... It looks like we need some form of namespacing

Justin: We have the same problem with custom variables, and the way people solve that is with custom prefixes

Alex: It's worth highlighting that element authors explicitly choose to expose things with part and theme, so unlike /deep/ it's less vulnerable

Anne: Parts automatically inheriting up will make it more like /deep/ where things all start leaking globally

Diego: Expanding on what Alex mentioned, it's important for authors to communicate what parts/themes they expose
... But it's easier to explain what themes are available, and harder to document all the parts that are deeply available

Justin: I suspect that most companies will use Theme over Part, because the part fowarding is cumbersome
... We have a situation where people ask for things, but maybe that's because people are used to being able to do a certain thing
... Perhaps it's just because they are not thinking in a model of encapsulation

Rniwa: One thing with themes is that it's hard to make things global, because for some elements it may make sense to theme for example the background, and for others it does not
... There is a question about how specificity works with theme and inherited styles

<bkardell_> one challenge with you specifying everything that you need fixed and letting other things through is that as new properties are added you wouldn't have set them - could that create issues?

Anne: It's hard to design a system around ::part that allows authors to do what they want, because you may expose too many things you don't want
... You would need some kind of blacklist to block styling certain properties

Rniwa: We're already in a situation where some elements are styled through ::theme and others with CSS variables

Anne: We don't yet have experience with what developers will do with ::part

Justin: @apply had some mechanism to keep some properties internally defined by authors

Brandon: We have parts that can absolutely not be overridden, like things related to layout

<rniwa_> rniwa: having to use completely different mechanisms as soon as you wanted to restrict the list of properties to apply doesn't strike me as a good design

Brandon: We prefer to keep things conservative in what we allow others to style

Justin: It seems like we're having the same kind of topic around part and theme, with whitelisting and blacklisting what can and cannot be styles

Rniwa: We need more concrete usecases so we can use those to shape the API

Justin: We have those from @apply usage
... @apply gave people to apply a style to a bunch of parts, and people used it to style a bunch of elements like applying a certain theme to all paper elements

Anne: It looks like Rniwa is referring more to an abstract list of things that developers would like to do

Rniwa: We need this list from developers, and then we can create an API and determine if our proposal covers all the requirements in the list

Diego: There are many different levels of what kind of exposure we need, down from allowing applying a single style to one deeply nested elements, up to being able to style everything everywhere

We could try to commit ourselves to finding out at what level our users need to have this exposure

Diego: We could try to commit ourselves to finding out at what level our users need to have this exposure

Anne: It would be great to have that information well before TPAC so we can discuss

Rniwa: It looks like the Polymer team also should have information on what customers use with @apply
... It would be nice if there was some overview on the different uses from those users

Justin: The usage for @apply was mostly closely mappable to ::the,e
... The usage for @apply was mostly closely mappable to ::theme

Rniwa: @apply is more powerful than ::theme because you can choose to apply different things

<dlockhart> @apply wasn't perfect though -- you needed to expose different @apply entrypoints for :hover, :focus, :disabled, etc.

@anne: We don't know all the requirements, so maybe we should move on to the next topic>

Alex: What other evidence do we need? We have a lot of information from @apply in what users are doing. Is the information from Salesforce going to be critical for the decision making process? How much additional data do we need

Justin: It would be really nice to have tabatkins here, because he is involved with this spec

<bkardell_> is tab able to join remotely

Anne: We are just missing a concrete enough proposal to get to any kind of concensus here

Justin: We did have a concrete proposal

Anne: That proposal had some issues where ::theme and ::part had some overlap, and there is no new concrete proposal that deals with those issues

Justin: But the original requirements from CSS shadow parts are unchanged, so we should have a list of requirements at least

Anne: But as long as we don't have a concrete proposal it's hard to really commit to anything right now
... The main problem was sharing namespace with ::part

Justin: Maybe we can get a conclusion that the namespacing problem applies to both theme and part and we can discuss what we want to do that now?
... I can commit to getting a concrete proposal here

<Stacey> Desire2Learn is in a different spot than Salesforce - we have full control over the all components and currently prefix all components and css variables with "d2l-"

Justin: From our customers we know that the major blockers to using shadowDOM are theming and SSR, so it would be nice to have progress on these topics today

Rniwa: Everything is too abstract, so it's hard to judge what exactly we are talking about

Tess: My recollection of the relevant CSS meeting was that there was consensus on the feature, and the usecases brought up at the time seemed to be addressed by css variables

<annevk> Ruphin: it looks like we're having an issue here with ::theme; it'd make sense to decide on a desired outcome for this discussion, what's the goal? Do we need more use cases, is that the blocker? Is the blocker the lack of concrete proposal?

Rniwa: The point of this meeting is to be determine what we need to move on
... It looks like there is more feature need over CSS variables from the user presentations
... So it looks like we need a clear documentation on what the requirements are that we do not currently address, and _then_ we can shape a new proposal that addresses these requirements and get concensus on that
... We need documentation on exactly what the current gap is that is still missing in styling capabilities
... For any feature we suggest now it's hard to say if it's necessary. Perhaps the namespacing problem can just be solved with prefixes for example
... More clarity on the requirements would help us determine this

Diego: Just to be sure, we can commit on testing certain proposals, but it would be nice to have some kind of proposal that we can test on our users

<bkardell_> * there's nothing to change except insofar as make something exist to evaluate :)

Justin: The problem with that is there is no current ::theme to test against, because theme is currently not in any spec

Anne: Ideally we get a list of concrete usecases/requirements from Salesforce, and not necessarily a test-implementation

Justin: It's somewhat difficult for framework vendors, because we currently offer some capabilities for users, but it's hard to hunt down how our users are using those features currently, but it's something we can work on

Anne: Looks like we can move to the next topic

<Travis> scribe: Travis

Asynchronous UI updates / DOM update batching

<annevk> https://github.com/WICG/display-locking

vmpstr: Will be talking about display locking to give rendering control of rendering engine
... developers sometimes have very little control over rendering

<scribe> .. New prop on HTML Element. "displayLock" with 3 functions.

UNKNOWN_SPEAKER: "acquire" puts an element in locked state. Clears it's painted output. Doesn't process any updates to its subtree. Takes optional size as fallback.
... Then its' OK to modify the subtree and no style/layout updates.
... "update" browser processes the lifecycle phases in "cooperative manner"
... so it can take multiple frames to complete. Browser should yield if possible.
... when update is done, script may read layout properties and the operations should be cheap.

"commit" - unlocks the element.

scribe: anything left is synchronously processed.
... back to "acquire"
... takes params: size [width, height]
... 'auto' layout once, then lock. (value of size)
... 'timeout': mili. Enables auto-unlock, cause devs can mess this up.
... can take value of Infinity.. :-)
... 'activatable' enables find-on-page, etc.
... The implementation details.
... uses 'contain: size" like layout.
... can skip subtree style/layout. skips paint/raster. ignores hit testing.
... 'activatable: true' adds Find-on-page, anchor links, scrollIntoView
... "update" call is allowed to take multiple frames. I think this was said before.
... To avoid "leaks" the element must have containment to avoid side-effects.
... That's it for me!
... Looking for feedback on devs and implelmenters.

justin: Suprrised by pixel clearing. This seems to eliminate primary use case!
... Like react's update mechanism.

vmpstr: We found there was lots of problems with 'stayed' pixels, than it solved.
... selection frozen. visual didn't match DOM. animated GIF, blinking cursors, etc.
... hit testing as well. Hard to not to react to that...

justin: Main case is to enable large update to DOM, but spread out async...

vmpstr: Use case we are considering is pre-rendering. Slide can be prepared in advance.
... tab UI. Virtual scrollers. More items added to the DOM and have them be searchable.

justin: Hmm. So no longer intended to address concurrent react case?

vmpstr: For React case, we're still thinking it should be possible to create simbling node with zero size, then remove existing sibling and show the other (element swap).
... yes, it does eliminate the clean layout. Work has to be done again.

justin: Any chance of locking pixels that doesn't have pixels. Ex: could blur...

vmpstr: That's the question, can we do it without copying the DOM. One way to preserve old pixels is to keep a copy of the DOM and use that to preserve painted output.
... we think that's too expensive.

Ruphin: Another problem. When you copy the DOM, you lose your selection state, etc. Has same issues.

vmpstr: That's what the proposal is as it stands.

rniwa_: Stepping back.
... what's it trying to solve?

vmpstr: Trying to give the rendering control to the DEv. Case of text editor, can prevent offscreen content from being style/layied out, but searchable.

rniwa_: display none?

vmpstr: That's not serachable with Find-on-page.
... (explanation...?)

rniwa_: visibility: collapse?
... that has entire style info, and is jsut as fast?

vmpstr: Not sure what that is (visibiliity: collapse)

BoCupp: I think collapse is not enqueued by rendering engine?
... to layout/paint.
... Use cases are for subtrees that are yet to be connected. So you can do some work and have the tree "blink into existance".

vmpstr: Want to lock something connected to tree and have it not do layout.
... should be quick because style/layout will be computed.

BoCupp: If you ahve display none, then switch to display block... the work to do this might take a lot of time. For a complex subtree can you prepare it in advance.

vmpstr: Collapsed thread in an email. If you expand it, this could cause jank.

annevk: Wouldn't it potentially require shifting other content around?

BoCupp: That's why contains is a requirement.
... Also, size attribute. Point is to prepare content and put it into the expected size.
... It's not depending on layout, you know it in advance. You already have an area reserved.

vmpstr: The way the update works...
... It goes into subtree of locked element, during layout the info available to subtree is as correct as we can make it (respecting styleing info of element)...
... if width is there, height is dependent... store the locked state after update is processed.
... possibility that more layout will be needed.

annevk: Still don't get the expand an email case.
... you need to replace part of the view that is to be replaced.

vmpstr: Idea: you'd insert the element (locked).
... you pass in the space you think it will take.

<slightlyoff> hey all, flackr is on the queue?

annevk: When you commit, there's reflow for ht element around it.

vmpstr: Subtree will be as clean as it could be...

annevk: It still might be expensive.

vmpstr: Alternative display none, then flip

<Zakim> annevk, you wanted to ask how it enables more elements in the node tree

flackr: I think you can get some of this with vis: hidden and contain: size.
... should allow lazy layout. Only think you don't get is "when the element is done laying out".
... but I think it gives all the other benefits.

vmpstr: Doesn't give cooperative layout.

flackr: Shoudl be able to lazily cooperatively layout.

vmpstr: REquires size to be specified?

flackr: Yes, and you do that until the layout is done.

BoCupp: Do you have scenarios for when the author needs specific control for when the subtree should...

<Zakim> BoCupp, you wanted to are al the scenarios now based on locking a subtree that is not yet connected?

flackr: Problem is when you flip, browser blocks on when layout is complete.
... Idea is that dev gets a signal when the flip is about to happen...

Ruphin: Now, if you acquire, you paint white pixels?

vmpstr: It's transparent

Ruphin: It paints transparent.. you see what's behind it?

rniwa: Seems it assumes a lot of how browser works.
... cooperative layout is not a think in Webkit.

vmpstr: Yes, this is the spec for that.

rniwa: Seems really immense.

slightlyoff: You pay nothing for not doing this...
... you're not forced to do the cooopeartive layout. You loose nothing.

rniwa: If you don't do it, then what's the point?

slightlyoff: Your implementation is just slower.

rniwa: Don't see the need for this feature?

slightlyoff: Familiar with React suspense work?

rniwa: Yes, but not convinced...
... They may be working around things, but not with good reason.
... if this was an issue in our browser, we would fix it by speeding up layout.
... doesn't strike me as an API we want to support.

Ruphin: This API allows DEvs to signal to browser where to optimize. If browsers want to make things faster, they can use this to improve perf.

annevk: No, it comes with requirements... certain aspects are expected to be fast.

Ruphin: There's no requirement (guarantee). App could be running on generally slow hardware.
... You can never get a guarantee

slightlyoff: Devs have no way to know today that the layout is clean, and wont' be invalidated by the next line.
... we don't have a locked time to know when readback is safe.

rniwa: I think CSS containment is working, then style calc can be fast...
... reason it's so expensive... without containment, there's inter-connectedness that makes perf slow.
... still don't see why we want to do this.

annevk: Point of order--transition to other proposals?

justin: We're doing async rendering in our library.
... we want to respond to property/attribute changes to cause a layout/render.
... the algorithm we use does a syncrouns render.
... so everything we do enqueues a microtask to do the render.
... so now we hang a promise off to let it know when rendering is complete.
... From multiple levels, each one puts in its microtask...
... Children get enqueued one after another...
... we don't have a single at the top of the tree (to know when everything's done).
... API is nice--gives us batching.
... haven't seen too many issues where devs needed to block layout.
... seems like this + React's concurrent mode, are doing this.
... Browser doesn't ahve an affordance for what pending layout work is needing to be done.
... Discuss: should the DOM have affordances for subtree layout. Events? Promises? Coordination in some other way?

annevk: I'm confused often becaseu the DOM doesn't do layout.
... rendering happens elsewhere.
... certain getter/methods force layout to happen.
... getComputedStyle/offsetWidth...
... but not if you mutate the tree for a bit.
... the costly operation happens later. And only if there is interleaving.
... proposal for DOMChangeList... idea is to batch up tree mutations so that they can't be interleaved with operations that would force layout.
... problem with domchangelist is custom-elements. If you insert 100 CE, then that gets costly.
... Sometimes the way we talk about it, it doesn't match how the browser works...

BoCupp: to Justin, in LitElement, what part is being made async?

justin: Element author writes a render methods. like in React.
... it executes some logic...
... for perf and mental model for the dev, we want devs to think of the state of the lemeent as having settled.
... when render methods is called, an entire batch of changes has been applied.

BoCupp: Is that happening when the subtree is disconnected?

justin: If you set a property on the element, it enqueues and update.

BoCupp: So the user sees intermediate steps?

justin: No.

BoCupp: Trying to understand what the async step is...
... is it just to keep the stack shallow?

justin: No, it's to batch. Just one render after you've set them all.

BoCupp: It's just to organize the order of operations in JS.

justin: One problem you see with big trees, with network effects between then... when you have a sync effect, it must travel all the way down the tree.
... One property set flushes all the way down the tree.
... Then you do it again, and it flushes down the tree again.
... So, to avoid we batch, then you only get one pass down the tree.

BoCupp: So you fight the cost of DOM manipulation...

justin: Not just DOM, but the cost of the render method itself...

<Zakim> BoCupp, you wanted to can you clarify what parts of lit element are async behind those promises?

BoCupp: You have an efficient method to do that. Once you do the manipulation, you commit yourself for an uninterruptable layout process.
... Could have complex layouts, nested grids...
... Some of these other proposals enable the browser to stretch this time...

justin: different proposal.
... we're reordering, putting in microtask queue, avoiding interleaving.
... comes down to nested operations, brought on by custome elements and shadow dom.
... C-E with property change notifications, can really explode the number of operations.
... this has worked out well for us, with the exception of not having a standardized way of coordinating work.

rniwa: Stepping back...
... n^2 layout issue from DOM manip...
... is a normal problem.
... biggest mistake DOM api made from web devs perspective. They don't know what is cheap/expensive.
... modern batching dom libraires solve this.
... since your batching and finally do the work, it's relatively cheap. (virtual dom)
... two general approaches.
... 1) batched mutations. Make a list of changes, but make promises to make the changes, then commmit at once.
... drawback: when you query, you're getting old state.
... DOM is not live, can't get current state easily.
... cumbersome model to work with dom changes you haven't made.
... 2) Make global transaction model. Entire document stops update layout/style.
... browser uses values from previous layout.
... drawback: browser has to cache old values.
... browser is forced to update layout at the beginning of the transaction start.
... otherwise the browser won't know what values to provide during that frame.
... for interop, needs to have a consistent approach, and I think it's up front.
... we've talked internally. Conclusion, both models are bad. We just need to make layout faster.
... style containment is not necessarily required. Browser could automatically do it.
... Browser can invest more time optimizing.

smaug: Why do you use microtask? Will get tons of microtask checkpoints!
... Lots of promise chain callbacks.

justin: animation frames...

smaug: Today, you run tons of these callbacks...

justin: Any work you do might enqueue other animation frames.

annevk: Use animation frame as bootstrap..

rniwa: Have a library that does this--use rAF to track jobs.

justin: We don't have global coordination.
... no queue specifically for a base class to do its work.
... Microtask queue is one we can use.

annevk: You sort of want event-based animation frame, to allow multiple handlers.

<diervo> +q

justin: If we did this on animation frame, it would trigger other animation frames...

smaug: Maintain a separate queue to process in the rAF.

justin: You might not have all participatings in all the elments using that queue...

smaug: But they all use Microtasks...

justin: OK, you could do that if all C-E agreed.
... how else do you coordinate among the different disparate CE?

annevk: <suggests idea>

Ruphin: I think we've diverged from the original issue.
... What's the evidance that Microtasks are a bad idea.
... Rendering system is really efficient. Don't see the evidence for slow down
... when we use queueing system, it's imposisble to tell when an element's rendering cascade is finished.
... (other Microtasks will have happened, and I don't know the extent of when that will be done).

annevk: animation frame callback is before animation frame happens...
... there is a proposal to tell after the animation frame is done.

rniwa: Use case?

Ruphin: Framework has a callback like 'updatecomplete' is called whenever its own rendering function is done.
... when rendering is done, promise resolves, you know then that rendering is done.
... you can't proceed with more style read, because you don't know if any children have pending tasks
... React solves this because they globally control this.

rniwa: Understand.
... How are component going to use that to do stuff? After knowing that all children are done with layout?

justin: virtual scroller. Add rows, measure layout, then add more rows.

diervo: Clarifications.. we use the same thing, everyone has to implement batching, and the queue.
... we had to add a callback re-render callback.
... they need to know when they are done and in the DOM.
... they need that single for devs to know when the work is done.
... rAF doesn't work because of timing delay...
... so we use Microtasks.
... would be great to have a native primitive to know when a thing is inserted and ready.
... probably not a panacea to make this cheap.
... you have to be very precise and prescriptive to get coordination.
... having a callback in the spec would allow frameworks to reconcile they're behavior.
... would love to see a proposal in a web copmonents spec.
... we do have the same layout thrashing problem.

rniwa_: When to render, or when rendering is done?

diervo: When it's finished.

justin: Confusion of terms. Not when the browser has finsihed rendering, but..
... element has state change and needs to make state changes.
... whatever the custom element logic is used to update it's shadow dom.

BoCupp: Moved from proposals...
... whatever's at the end of the pipeline, there's browser work to do. Does anyone have a problem with this perf problem.
... use case for after DOM update that rendering is taking too long?
... Saw DOMChangeList, DisplayLocking to enable DOM mutation to be batched up, and interleaved enabling DOM control.
... Use case: I have nodes that aren't critical for the next frame, but want them rendering.
... I think I heard rniwa say this really isn't a problem.
... want to summarize.

annevk: No strong position here.
... some folks at Mozilla have concerns. Maybe no one in the room that can speak to it
... needs more fleshing out of the problems.

BoCupp: Would like more use cases.

<hober> https://github.com/mozilla/standards-positions/issues/135

BoCupp: heard about Tab UI, only the one tab is critical.
... Powerpoint prev/next slide, prepare for next flip.
... Is there data we could use to see? What budgets are being blown in these scenarios.

rniwa_: Second problem, the coordination of custom elements is more interesting to me.
... Would like to see more details of what the challenges are.
... Seems aligned with what we are trying to solve in this group. We're interested in solving that.

annevk: Ok, we can end there.
... small break.

<Ruphin> https://github.com/w3c/csswg-drafts/issues/1995

rniwa: /me scribe volunteers please?

<scribe> scribe: BoCupp

Ruphin: presenting

Handling global name spaces in CSS

<rniwa> https://github.com/w3c/csswg-drafts/issues/1995

Ruphin: I want to style an element that is slotted
... there's a problem
... Safari looks like only correct result

<diervo> +q

<DanClark> Direct link to comment with proposal: https://github.com/w3c/csswg-drafts/issues/1995#issuecomment-485451689

annevk: this is another type of scoping and is alternative to scoped registries

not CE registry... about CSS application

rniwa: at whiteboard defines foo font face which inherits across SR boundary
... need to control the scope to which a font family will apply

annevk: what about when children are slotted, what will it get
... when the shild explicitly says font-family: inherit

Ruphin: what matters is where the name has been defined relative to the location of where the element has been slotted

annevk: good initial take on the solution, you want to avoid fallback to global scope

Ruphin: current behavior is always to use the global scope

annevk: what we want is the option to prevent fallback to the global scope

<annevk> (roughly)

rniwa: Chrome and FF are all looking up in global scope and if we change behavior to not leak inward then we could break sites
... discussing reflecting content attributes that have idrefs
... having a content attribute foo="x" should be able to have x refer to the id of another element with x and have property x that actually points to the element with id = x
... there is a problem when you want to use references across trees (across different shadow roots)

Jan: intent is for labeled by type attributes?

rniwa: defining rules for built in attributes right now, not new custom attributes for custom elements

<caridy> there are two spectrums here: basic linking (similar to what form participation does with the labels), and complex linking (usually for complex components that have multiple internal parts that should be linked to elements from other shadows).

<caridy> this proposal is for the complex linking

rniwa: general rule is you can reference things in your ancestral tree but not sibling shadow trees or any other trees than your own and ancestors

<caridy> only things that you can traverse to (programmatically) can be referenced?

Ruphin: my-label and my-input should have links and this doesn't solve that case

rniwa: agreed

Travis: what's rationale for disallowing?

annevk: violates encapsulation

<Travis> slightlyoff: Ignore content attributes for a moment, just look at JS props

<Travis> .. you can have getter/setters and refs.

<Travis> .. at runtime, you mean [that thing] over there.

<Travis> .. difficult is about forwarding that goes through content attributes.

<Travis> .. may need proxy on light dom in order to wire-up relationships

<Travis> .. hoped ElementInternals would give us this notion...

<Travis> .. also location to hold this state.

<Travis> annevk: Seems like a protocol that lives at that level.

<Travis> slightlyoff: I feel more comfortable with ElementInternals as it can be re-used in other places.

<Travis> annevk: Will continue in a bit to get some lunch.

<Travis> 🍕🍕

<caridy> just for the record, our current solution is very nasty: we use a mutation observer on the outer shadow root to keep up to date content for the element with the id. Then inside the inner shadow we create a span, with link the internal input to the span, and we use the mutation observer to keep the content of the span (contentText of the ref element) up to date.

<caridy> that is very very complicated... and only works if the ref is from the outer shadow... otherwise it is hard to fine the right shadow to observe the mutations.

<caridy> I do agree with @slightlyoff, having reflection directly into the inner elements is problematic... I rather prefer to have another low level API via internals where you can define the linking across shadow, but you do not leak that ref via the DOM

<caridy> e.g.: `this.#internals.linkAriaLabelElements(this.shadowRoot.querySelector('input'), outerLabelElement);`

<caridy> and the corresponding method to inspect such relationship via this.#internals, rather than using the DOM for such new reflection mechanism

<smaug> 're having lunch here

<annevk> scribe: Ruphin

Rniwa: Lets discuss how element reflection for IDREF works with Aria
... discussing https://github.com/w3c/aria/pull/920
... For example aria-controls, if they are assignable by ID, we can use that instead of attribute references based on ID
... So the idea is that for most current aria references these become assignable as properties which get node references

Travis: So getAttribute does still work?

rniwa: Yes, for IDs that are referenceable by ID, it will reflect to the attribute

diervo: Not reflecting to attribute is a bit problematic for us

rniwa: Can you specify?

diervo: We are already using these properties with those names, and when this becomes builtin it will cause name collisions with properties we are already using

rniwa: This is not just for custom elements. It will work on all elements

diervo: We have a crazy internal workaround for this specific thing, but once this is implemented it may conflict with our implementation
... We would prefer an implementation that works with elementInternals

Anne: This is an API on Element, so we cannot move this to elementInternals, it's a different thing

annevk: You can never use this to go inside shadow trees, it only goes outward

<caridy> to provide more details on diego's comment:

Travis: These are just reflected properties on all elements

<caridy> the problem is that today, you only have one way to escape the shadow root (shadowRoot.host)

<caridy> you will be able to escape the shadow by travering the shadowRoot and finding an element that is linked to something from outside

tomalec: This proposal is only about extending the capability of current ARIA attributes and making them assignable through properties

annevk: The new part is being able to assign nodes that are in different shadow subtrees

Justin: Do you have collisions with these specific names? Did you think that IDs would cause attributes to be set?

<caridy> that responsibility is for the shadowRoot owner to do the linking (most likely), and we will prefer another API, something that is only accessible for the owner of the shadowRoot

diervo: I'm not sure, we will have to look into this

Anne: The examples before may have been confusing. This is the more concrete usecase with ARIA attributes with actually newly introduced properties

<caridy> that IS accessible

<caridy> only for the shadowRoot owner

<caridy> I can try to explain, if the audio helps today

diervo: What caridy says

caridy: My main concern is that we only want custom element controllers to be able to control this behaviour, and not external users
... The problem with this is that the only way to use this is to reach outside your shadow to find elements to link to
... So we prefer if only the custom element has control over being able to set this up

annevk: I don't think the shadow boundary upwards is generally being preserved

caridy: For us this is important for our security model

annevk: This is not part of the encapsulation that the platform provides

caridy: We explicitly have protections that prevent this

annevk: Then you have to implement your own protection models for this
... If you already have the encapsulation to disallow people to reach out, this API should not be available to you anyway

tomalec: I don't see the collision. The way I understood it that the problem is that the owner of the shadowroot can now link properties outside to its own shadowroot, but if your element has protections to prevent reaching outside that is still preserved

caridy: We have some system that prevents reaching upwards but this API will break our confinement
... Let me give you a specific example
... Imagine having a shadow with an x-foo input inside
... If that input has a link to an external item set by the shadow owner, then that x-foo can use that link to reach outside itself

annevk: It is not necessarily an issue, because the other proposed API allows the same kind of access without explicitly setting these IDs
... So you can use elementInternals to get the same kind of behaviour in custom elements, and not this one

Alex: These are both conceptually different features, but they can be used to achieve the same thing

rniwa: This API is not meant to solve anything for Custom Element specifically, it's just a general solution. Custom elements can have different solutions for the same problem

diervo: So we can use the other proposal to solve our problem?

Alex: Correct

rniwa: This proposal does nothing automatically, so you have to explicitly use it, or it will do nothing. So it should not be a security concern
... Custom elements should be able to set having a default aria role, like being a button, or a checkbox
... And elementInternals can be used for this
... The question on how custom elements do references is still somewhat an open ended question
... One way to solve it is to delegate roles to parents, so things can resolve through delegation
... The other solution is being able to set links between elements explicitly through shadow boundaries
... And there can be a lot of complicated cases, like you can be labeled by multiple things, and the solutions to these things are not very clear

<caridy> yes, we have those use cases as well. eg. <lightning-location> which has two inputs inside, latitude and longitude

tomalec: From a developer perspective, what authors want is to be able to create elements that have the same capabilities as native elements, such as being able to create something that behaves like a label

annevk: This is a different issue, this is just about being able to directly link items

rniwa: There is another question too, what if you have things inside the shadow tree that need to be made accessible by things outside the tree
... For example if one shadow tree has a label and another shadow tree has an imput, you want to be able to link those

annevk: If developers can implement things that implement a 'label' or hook into the label protocol, it could be a way to solve this
... It is not necessarily related to aria

BoCupp: Can you give a concrete example where you want to link things through shadow trees?

rniwa: Suppose you want to describe an element that is in another shadow tree

BoCupp: Could you put some more detail on that?
... Which attributes do you assign to which nodes to do things like creating a link that describes an image with some text?

annevk: We're sort of out of time

<bkardell_> <ryosuke whiteboards?>

Whiteboard still empty

annevk: There's two different things going on. There's this public area API that we're talking about now, then there's the elementInternals API, and then there's this idea that you can create elements that behave like builtin elements
... This conversation is only about the public area API only

<dbatiste> We (@D2L) have this use-case for aria-describedby for custom tooltip component.

BoCupp: Let's go back to that then

rniwa: The case that the current proposal solves is that you can link descriptions across shadow boundaries, with certain limitations
... What this API can not yet solve is that you cannot link through sibling shadow roots

Ruphin: Why is that not possible?

annevk: It violates encapsulation boundaries

BoCupp: Perhaps we need some kind of other API shape that makes this possible without violating the encapsulation then?

Ruphin: What if the property is not readable?

annevk: This would work, but it's not a nice API

Rniwa: That would encourage the wrong kind of pattern where people start exposing internals

Tess: There are all sorts of things where the shadowroot shape can change and that leads to problems

Rniwa: It would be great if users that need these features can document the usecases so we can test if this proposal solves all the usecases

diervo: Should we create a new issue for this?

Rniwa: Yes

templating

<JanMiksovsky> https://docs.google.com/document/d/1XXJVGKm6UA6SfESDHEH1vFLP5EhTstFYm5DGMQ6Snl8/edit

<annevk> [Apologies for the lack of minutes.]

<annevk> scribe: anne

<annevk> Very rough summery: frameworks need to use a lot of workarounds to make templating work today. Parts gives them low-level insertion points for keeping track of where updates need to happen, without having to resort to Text nodes, script elements, or Comment nodes or some such.

<bkardell_> thank you annevk!

<annevk> scribe: annevk

rniwa: an alternative to template instances might be having part groups
... it might make sense to move this from <template> to something more generic as we've gotten requests for that

BoCupp: how does it work?

justin: there might be ways to break node parts
... if you detach the end it might not work
... but we'll have to define how that works

rniwa: there might be ways to fix things up, but there's a cost
... with range it's eager

justin: there are other proposals, e.g., live DocumentFragment
... this is essentially the low-level primitive for that

rniwa: I think it's basically the same

BoCupp: do these work for attributes?

justin: there's AttributePart
... should we support multiple expressions per attribute
... bit of an open question

rniwa: class="{ } something { }"

JanMiksovsky: also for the style attribute

justin: lit has specific interfaces for class and style attributes

JanMiksovsky: the current AttributePart solution does not work great for class/style

rniwa: my proposal is that there's a list of strings or Parts, and committing takes the concatenation of that

Ruphin: is it needed that AttributePart can be split in multiple strings
... ?

rniwa: I think there's no point in providing AttributePart in that case
... we really each curly brace syntax (far future) to map to a part

JanMiksovsky: justin and I want part behavior that's not defined here
... maybe for v0 there shouldn't be AttributePart and there's just a generic Part and a NodePart and for the remainder you implement it in userland

<tomalec> +1

rniwa: for the property case you don't need subclassing, you can implement your own object

JanMiksovsky: a value of parts is that they retain a reference to the node after cloning

Multiple people: okay, so you need some kind of userland cloning

diervo: if we allow customization we might lose performance
... we'd love to use this. A native way to do template interpolation would be good. This would fit pretty well. Interesting path forward. We have opinions on specific syntax and love to get agreement there once we get to v3.
... also would like to help move this forward.

Travis: In the initial proposal from the last year I noticed expressions for conditions, loops. What's you take on that?

justin: there might some inner template part
... don't need it until there's a default processor

rniwa: the way this thing is designed is that these part objects are a low-level way to update the tree
... second step is syntax
... iteration is final step
... interpolation depends on the template processor
... looping and such is to be defined by the template processor as they have opinions

justin: the key part is that we need to make sure that the pieces are there for instances

JanMiksovsky: I wonder if we can leave committing and updating out of v1
... it doesn't seem needed for the fundamental thing of having insertion points and being able to clone them

rniwa: not including it might prevent some optimization opportunities, potentially
... this aspect hasn't changed since the original proposal

annevk: I think Jan's point is valid, templating needs centralized use cases, requirements, and updated proposal

justin: next step is a fully updated proposal
... and polyfill

<Travis> scribe: travis

justin: last F2F, we had a discussion about declarative shadow/custom element...
... we could look at some current server-side rendering cases.

<bkardell_> it's pretty hard to compete if we can't do some degree of ssr

justin: server side rendering (SSR) is interesting. Regardless of what we think about it
... SSR is happening because folks _are_ doing it.
... major requirement for a variety of companies.

rniwa: please define SSR

annevk: What do we want out of our session?

justin: would love to see what approaches folks in the room are using SSR for
... highlight and get ack of the problem, not necessarily with a solution
... some kind of next step? (Not sure)

diervo: would love to connecalize on what a ShadowDOM might look like.

justin: would love to see a list of challenges for the cannon..
... (we have a closed issue apparently)

annevk: Have an idea that doesn't get traction
... we can't modify the HTML parser
... we could make the XML parser more similar to the HTML parser...
... like the tree builder
... then we could add tree-building for a shadow-root thing.
... then use CE without end-tag, in tables, etc.
... blocker is modifying html parser is hard
... years ago, XML5 defined what [..] could look like.

diervo: What does the XML parser mean?

rniwa: Let's come back.

justin: 1) "Classic" and "Modern" SSR.
... classic Ruby-on-rails, PHP, etc.
... modern same code that does client side rendering, use that on server.
... output is what most folks actually want.
... output without having to run script that can display the page correctly.
... not currently possible with shadow dom

pmdartus: requirement that we have is req. to render pages in browsers w/no JS enabled
... navigate to e-commererce without js
... Good SEO for pages.

Ruphin: aside from impl. we should isolate the use cases.
... I know of 3
... 1) search engines to understand your page.
... 2) faster initial load
... - react renders without script, then while page is rendered, it adds features to page.
... 3) for users with JS disabled, want to see the page.
... I think that's all the cases. ANyone else?

diervo: Yes, those three.
... also: developer experience to write declaratively.
... also: learning HTML, in HTML-only way

<tomalec> that is tomas not me :)

Ruphin: Discuss what solutions are available?
... search engine use case: RenderTron
... runs on server, flattens the tree, putting everything in light dom.
... may not work 100% correctly, but search engine can index.

diervo: Millions and millions of visits by search engines.
... it's not scalable forever.

justin: Problems with this approach. You're "cloaking" your content for bots (they don't like that).
... 2nd you ahve to redirect your page to those services. We don't have a total list of these.

slightlyoff: And it's expensive.

justin: Other solutions?

pmdartus: 2 main solutions: running extenral service, render shadow tree
... use a tree-of-trees.
... create Custom Element (CE) on tree.
... what matters is serialization format
... to reconstruct the tree down on the client.
... for tree-of-trees, mark the shadow trees...
... associate light dom with these
... light dom then has sibling elements. Shelf the content, put it in shadow.
... problem: the static content is not represented in the right place.
... the search engine won't see things in the right place.

justin: ordering of light dom is wrong

pmdartus: Another approach (experiment as SalesForce)... create a [..]
... put fallback content in [template]?

justin: First technique is a shadow element implemented in user-land
... ++ styles don't have to be mutated
... -- non browser UA won't know how to generate the flat tree.

<pmdartus> SSR investigation summary: https://github.com/pmdartus/wc-ssr

justin: Flattenend tree -- you can convert back, but with styles it's tricky
... rehydrating the flattened tree requires reversing the style mangling

slightlyoff: Also GC-heavy

justin: and DOM operation heavy

rniwa: Are there lots of users with JS disabled?
... why?

tomalec: Banking app asking to disable..
... also users.

diervo: numbers, for commerce apps, they have requirement to ensure that works

pmdartus: And we have lots of IE8 users.. we don't even give them script

annevk: A survey is 2% of users

tomalec: If users has choice to disable script.
... expect a large part of the web is broken for them.
... these people are opting themselves out. Finding a solution for these folks is a non-starter.

justin: when a user hits one of these sites, the use case is incremental hydration (for speed/perf)

rniwa: Use cases?
... faster load?

slightlyoff: Yes

justin: You could say client-side rendering is the way to go...

rniwa: You could put 10 lines of JS on client side to do this.

justin: Hardest thing to solve is bot issue.
... not ever bot is google.
... twitter/facebook other embeds

rniwa: For search engines correctly interpret CSS to know visibiliyt/order?
... if style doesn't matter, then naive version would work.

justin: In order to do user-land shadow-dom, uses template element.
... we don't know how these bot use template

rniwa: If only browsers add support for shadowelement...

justin: It's standardizing on those semantics to help out these bots.

slightlyoff: I work iwth bots of large sights doing server side rendering. They're motivations are often confused
... search engine is a primary motivators.
... SEO is looking for hero elements, etc., ususally depend on light-dom anyway.
... some engines (bots) run faster when you dump HTML, not script
... want to keep the crawlers happy
... they pre-digest the content quickly
... they do this to give real users the idea that somethign has happened
... also to get credit
... modern support for crawlers... some are still quite degenerate
... others may run a DOM/JS server-side [poor] parser.
... others are running full browsers.
... Google's has improved, hasn't been great.
... I hope, if we focus on crawlers, and expect they will evolve as we move forward
... for argument, we should assume that most of these crawlers will run what we put into the platform

justin: Not sure its good to assume all bots will run JS
... even if they do, assume common place for fast-path and slow-path

slightlyoff: The decisions was more about historical evidence
... with so much content, you decided on [overall] feature support, and the support of the entity.
... it's an ocean, not a cup of water.

rniwa: We're in some place where the crawler may support css, might run script...

slightlyoff: assume they will all run script at some point.

rniwa: Fine, then at top of page, add a thing to find shadow doms...

Ruphin: maybe search engine thing will solve itself in time.

justin: Issue of semantics. What does it mean to have custom shadow root...
... shall be publish a doc that says what a declarative shadow dom

rniwa: Should be good to have a user-land impl.
... might be tricky to guess exactly what we want
... unclear of whether shadow-dom was something that we want

justin: I might be behind other folks at the table on <shadowdom> representation.

pmdartus: customer won't want to use it if the search engines won't use it...

tomalec: I do have an implementation for cases where I do have JS running

<bkardell_> what is the success criteria here? can we express it? there are multiple people trying to solve this relatvely similarly and people turning away from the platform solutions because we offer no answer... is the succeess criteria here "we need the jQuery of this" where that means something used by pratically everyone ever?

tomalec: since we cannot solve today, no support for scripting, we cannot get to point where we'll see a big community emerge

<rniwa> no, I'm saying that we probably want some user land experience of a feature like this.

justin: there is a solution where a user flattens a tree...
... best performing user-land solution for SEO could be the flattening-a-tree solution.
... but that doesn't inform the platform, since it's really not that feasable of a solution.

<caridy> guys, it is very simple, if we don't have that spec'd, there will be a huge amount of people who will continue pointing to ShadowDOM as an incomplete solution compared to what is out there today...

<caridy> every popular framework supports that in a way that crawlers understand it, with shadowDOM, that is not possible.

<bkardell_> I typed my q, tried to add to q but phone is meh

Travis: There is a proposal...? Shall we look?

<bkardell_> it was really to ryosuke's comment

justin: rniwa last year you had concerns about moving this element?

rniwa: suggestions and oppositions... 😢

justin: Willing to look forward

rniwa: apple doesn't want to add a new parser method
... biggest source of security bugs

tomalec: also: we had to remove the shadowroot element after it was stamped.

rniwa: removing is OK, problem: you encounter element, leave it, put it's content into the DOM

<caridy> will you be able to query for it from JS?

<caridy> as you do with templates?

tomalec: Can't you make this match template.content?

annevk: Specific proposal?

Ruphin: CAn't you use template with type as shadow?

annevk: When/how would this behave?

<Domenic> template.toggleAttribute("type")

slightlyoff: template has an end-tag...
... when it's processed it takes it's tree and attaches it...
... at parse time, identify where the content is attached.

annevk: When would you move the content over?

justin: perhaps it really is a template element, but it's content property...
... just moves different content property

rniwa: we didn't want it streaming.
... there's an issue filed to change the static template content to be streamed

<slightlyoff> Domenic: inputElement.type = "..."?

tomalec: Firefox behaved that way.

<slightlyoff> Domenic: I agree it's weird, but not unprecendented

<Domenic> Yep, and a big nightmare

tomalec: chrome/safari that does stream.

annevk: It replaces it? What did content refer to?

<Domenic> I bet if the network pauses long enough Firefox will stream

tomalec: [describes behavior difference]

<slightlyoff> Domenic: I'm just saying we can define a sane behavior here where you don't do the dynamic thing; it's a parser-only behavior

justin: Trying to understand annevk's questions...
... it's literally a template element...?

annevk: Does the template element stay in tree and get slotted?

justin: user-land solutions will do something ugly

rniwa: have to refactor spec...

<bkardell_> why remove it? just weight?

annevk: there's lot of complexity [details elided]

slightlyoff: write down by hand what would happen, follow those steps.

rniwa: There's a difference between DocumentFragment and Document in content property

slightlyoff: We have a strong evidence of need!

annevk: We reached this conclusion a long time ago...

<caridy> I think slightlyoff suggestion is very strong... what about open shadow vs closed shadow? also components will have to be defensive, checking if the shadow was already attached to the element...

<caridy> I think keeping the shadowRoot on the template is the right thing

<slightlyoff> caridy: default open; nobody uses closed roots (according to our data)

Ruphin: Then conclusion is that we just can't support this feature! If this is blocking, then most convenient solution could ...

rniwa: Yes. There is use-cases for server-side rendering.
... there were objections for all the ideas [back in tokyo f2f]

<caridy> yse, but still, calling attachShadow() has to be conditional

rniwa: don't want to repeat the discusion.

<slightlyoff> caridy: on what?

<bkardell_> or ... has too much time passed and we should actually review them again?

<caridy> so, better to keep that in a separate element (the template) and let the browser to do the special allocation

Ruphin: So, no solution that's agreeable to everyone.
... Do we just arbitrarily pick one?
... We'll have to override objections!

<caridy> this.attachShadow() on a custom element, will have to be conditional

<caridy> to not attach if the server is producing one

rniwa: Must find least objectionable solution.

<slightlyoff> caridy: custom elements that are pre-processed this way can look to see if they have this property already

Ruphin: One proposal:
... 1) use template with different type.

<slightlyoff> caridy: else their attachShadow() fails

Ruphin: - are objections to this?

annevk: proposal is not fleshed out enough to judge it.
... what are the template element changes that make this feasable?
... what are the tradeoffs?
... don't recall the whole discussion there.

<caridy> slightlyoff I didn't get that. I haven't seen many custom elements doing a conditional attachShadow()

<slightlyoff> caridy: ...because we don't have this feature yet

rniwa: I can go through different proposals.

<slightlyoff> caridy: yes, it'd break existing elements; you need to not do this to CE's that aren't defensive to this

bkardell_: I have two Q and concerns
... "we need userland solutions..." held up jquery
... 1) people are currently trying to solve this--definately.
... -- are turning from platform solutions to things that are less-good.

<caridy> slightlyoff exactly, so, letting the browser to do the allocation on this extra shadow element (template) seems to be the right solution, rather than attempting to move things around into a real shadow root attached to the host-to-be

<slightlyoff> so multiple roots

bkardell_: I think we agreed: where we find things not solvable in user-land, we should prioritize?

<slightlyoff> I have a soft-spot for that ;-)

bkardell_: if this is, then what are the use cases to address?

rniwa: Not suggesting it needs to be jQuery level... just that before native solution, folks were trying it in user-land.
... last time we had real difficulty finding a solution.

<caridy> jajaja! hopefully not needed, just let the template to render that thing... once you attach the real shadow to the host element during the upgrade, the other content disappear. additionally, we need to have an easy way to get that content up front, in case the component does support rehydration of its shadow from SSR

<caridy> I have to run...

bkardell_: I think people are trying to solve this in user-land currently

Ruphin: but they can't since they don't have the right primitives.
... current primitives make it really hard to do in user-land. Not from lack of trying

justin: shadowroot CE...
... streaming would be difficult...
... would anyone understand what this document means?

rniwa: Two approaches:

<slightlyoff> caridy: thanks for the input

rniwa: 1) introduce new element <shadowroot>. Inserts it's content. (with many variants)
... 2) <template> under element.
... benefit for template has special html parser behavior that it can appear anywhere (unlike any element)

annevk: new idea: HTML modules with new mime-type, then you have [new behaivor], post-parse. Could be done.

slightlyoff: Are you saying, this would trigger if HTML import inline here?

annevk: Top-level document with modules mime-type. Will be new semantics

<Domenic> annevk: CE reactions can still observe weird stuff, delaying the dance doesn't seem to help much.

all: start to dream about what can be fixed in HTML...

rniwa: 4 things to consider...
... when shadowroot is attached
... whether template/shadow remain there
... (ok 2 issues)

<annevk> Domenic: how does CE work in modules? presumably they'd have to be delayed?

complication with parser's re-parenting.

<Domenic> annevk: in modules they don't work I think because they're not an active document. You need to move them into the active document to get them upgraded

diervo: clarify: is the problem about assignment about slots?

rniwa: Slots are fine. anything you can put in regular shadow-root

<annevk> Domenic: the idea here is that script won't run until after you deal with <shadowroot>

<Domenic> So all CEs become upgrades?

<diervo> I think we are still trying to figure out

Parser will stream content into shadow doc after the content is moved...

<annevk> Domenic: yeah, I suppose; XML5 might still be the best idea 😃

<diervo> Is there a document for XML5?

<diervo> How is that different to the special HTML mode?

rniwa: complications with various issues in parser (adoption agency algo.)
... another approach--wait until shadowroot closes. At end, grab the stuff in there and attach.

<annevk> diervo: https://ygg01.github.io/xml5_draft/ but https://annevankesteren.nl/2007/10/xml5 might be better

<diervo> annevk thanks

rniwa: content might appear during parsing...

justin: shadowroot has to act like template...

rniwa: is shadowroot real element or parser fiction.
... is a parser macro.

travis: saw that parser-macro until added to template, which I thought was interesting.

annevk: parser macro is only conceptually clean solution.

Ruphin: Attach at end? why is that bad?

<bkardell_> only works on DOMContentLoaded :-p

rniwa: maybe we should just add it.

diervo: knowing parsing quirks...
... I like the idea conceptually, of using annevk's special mode.
... seems the only potential solutions is orthogonal parsing or other mode. Is that insane? Can that be polyfilled in user-land?

<diervo> i mean to just prove that would work

annevk: HTML module mode might be tough around custom-elements... they would all end-up being upgraded.
... the XML one seems viable.
... it's work to replace XML parsers with new one...
... some work to define ShadowRoot macro.
... It's do-able.

rniwa: How about using template?

annevk: Problems is not conceptually clean.

rniwa: Template will know it's a special type...

<bkardell_> it's input, right?

slightlyoff: Or you could just instantiate it.

justin: Or you put a slot on it...
... options!

annevk: What about script?

rniwa: Shoudl run eventually, it's the right semantic.

<bkardell_> that is not me

<bkardell_> I dont know how to get that out of there :)

annevk: Don't CE constructors run and will have problems?

justin: be sure to unzip the tree from the bottom-up.
... so at top-level you're still in the shadow-root.

rniwa: .. then you wait until parsing is finished.

diervo: user-land folks who write it need help from an implementer.
... need to partner with an implementer.

<bkardell_> <template type="shadow-root-ish">

<Domenic> (Or use customized built-ins!)

tomalec: Once the template stamps, it removes itself...

<diervo> Domenic: say more about customized built-ins, for the new type?

<Domenic> <template is="shadow-root"> in userland

annevk: What happens if you remove it earlier?

justin: Continued to get filled in?

tomalec: Have implemented it that way... but we are not removing the template.
... maybe that's fine for the proposal.

annevk: Need a comment node.

tomalec: template today is inert. But with template as shadow that removes itself...
... Would love a 'contentready' event!!!

Domenic: Want to reiterate my stance... doesn't make sense to have the template ready--it's never ready/finished.

<bkardell_> the document can change too but it has a concept of readyness? is it just terminology

<bkardell_> TemplateContentLoaded

tomalec: Back to point, when we never know when it's done...

slightlyoff: Memory consumption is waaaay small compared to user-land behavior.

annevk: For rniwa: how is template element not a macro

rniwa: Once it's created it has to grab its contents and attach shadow root. Hook needed...
... script element has a hook.

smaug: Select element too?

rniwa: There's already precidence.

Domenic: script, style, textarea.
... reall makes sense for text-content based. Not sure it makes sense for DOM based.

<slightlyoff> i don't understand what the difference between "text content like" and "DOM based" is

Domenic: if you want to something script-link or style-like, then OK.

annevk: We have hook for when document is done parsing.
... template creates sub-tree, why doesn't it make sense?

Domenic: from implementation yes, from semantics, good practice, no
... jQuery's DOMContentLoaded.

justin: How much of a special case is template?
... it's not like a carosel?

rniwa: Modifying template might be...

justin: I modify templates like crazy.

slightlyoff: Template contents get stamped, and then used.
... this is a decision to instantiate at a certain time.
... is this 'moment in time' a place to stuff content and have it be useful?

<bkardell_> <template autostamp>

diervo: want to discuss it...
... let us implement in user-land.
... maybe template when parsing is different then instantiated programmatically.

<tomalec> bkardell_, <3 for `<template autosamp>`

diervo: for user-land, to detect when something is finished.. that could be a good hook.

<bkardell_> <template autostamp="shadow">

rniwa: strikes me bad that the only way to know when template is loaded...

Domenic: You want watch child mutations with MO.

tomalec: I think we just found a use case where that's not a solution.
... you can have element added after template element, before the template is parsed to the end.

rniwa: Could have async break during template parsing... and add random new element.

tomalec: special treatment of template: makes sense to process a template, once its finished parsing...
... how can you finish parsing a template before your expressions/bindings and not guaranteed to be done.

Domenic: If folks want to assume a template is done... then might be ok to have an event?

justin: concerns: modifying templates is tricky and not very clear what the semantics are supposed to be.

<bkardell_> if we had a concept of 'this is loaded' doesn't that make it easier, we could just say that is how it is

annevk: with nested templates... instantiation happens before outer-most is done... do inner templates assume?

justin: But won't happen because they are inert still?
... we generally have the problem of elements not realizing that their children may not be available.

annevk: Because you don't stream into shadow root...
... if outer-most CE constructor runs, its...

justin: From element's point of view: it boots up. [missed this]

annevk: Concerned about initial creation semantics

smaug: Could we put template before custom elements?

annevk: Declarative CE territory?

justin: I don't know this is required for declarative CE..

tomalec: I have this use case to add ShadowRoot for divs. For each instance of div, I want new shadowroot for layout/scopeed css, etc.

<bkardell_> tomalec: a whole bunch of people wanted shadow root for that purpose, didn't they? isn't that why shadow roots aren't exclusive to custom elements?

<tomalec> bkardell_, as far as I know, definitelly.

travis: would like volunteers from implementers to help draft up a concrete spec.
... ?

slightlyoff: I could try to find someone who might help.

👏

Travis: I'd be interested in helping too.

<tomalec> I'd be happy to participate from web developer perspective

annevk: [XML stuff..]

<bkardell_> thanks for arranging dialin and being a great moderator annevk <3

<westbrook_> Yes, ☝️, thanks you for the video dial in. great work, everyone!

<hober> I don't remember how to ask RRSAgent to generate minutes for yesterday

<hober> The raw minutes from yesterday are here: https://www.w3.org/2019/04/25-components-irc

<hober> The raw minutes for today are here: https://www.w3.org/2019/04/26-components-irc

- DRAFT -

Web Components

26 Apr 2019

Attendees

Contents

Asynchronous UI updates / DOM update batching

Handling global name spaces in CSS

templating

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output