<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
<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
<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
<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
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/is they/as they/ Succeeded: s/[missed]/In the initial proposal from the last year I noticed expressions for conditions, loops. What's you take on that?/ Succeeded: s/diervo/tomalec/ Succeeded: s/My/A/ Succeeded: s/tomalec/Ruphin/ WARNING: No "Present: ... " found! You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy <amy> Present+ Found Scribe: Ruphin Inferring ScribeNick: Ruphin Found Scribe: Travis Inferring ScribeNick: Travis Found Scribe: BoCupp Inferring ScribeNick: BoCupp Found Scribe: Ruphin Inferring ScribeNick: Ruphin Found Scribe: anne Found Scribe: annevk Inferring ScribeNick: annevk Found Scribe: travis Inferring ScribeNick: Travis Scribes: Ruphin, Travis, BoCupp, anne, annevk ScribeNicks: Ruphin, Travis, BoCupp, annevk Agenda: https://github.com/w3c/webcomponents/issues/802 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]