Meeting minutes
<astearns> w3c/
justinf: we had 3 open questions last time and we settled all of them
steve: have a registry on the apis for creating elements that are disconnected
steve: sethtml can have an option bag which can specify a registry
steve: that was resolved to be the simplest at the f2f, and its capture in the issue on this
masonf: to clarify: the proposal is that innerhtml will use the global registry, but sethtml/sethtmlunsafe will have an additional argument to use a registry
sorvell: my sense is that while its not ideal it makes the feature reasonable
rniwa: sethtml and sethtmlunsafe - we want to add the argument to both of them
sorvell: ideally yeah
<masonf> presumably parseHtml and parseHtmlUnsafe() also?
justinf: related: how to get registry for disconnected tree but also for a library ...
justinf: they could have similar solutions or different
sorvell: that is captured. i tried to make a summary of the issues in the breakout session github issue at the bottom
sorvell: rob made an issue for that and i had a separate issue for that
sorvell: my recollection at the last f2f was that we had discussed that those could be follow ons as long as we solve this disconnected issues which was needed for an mvp
sorvell: the two proposals around framework integration were trying to make that more seamless
sorvell: theres the steps to find the custom element registry. look for a root or use the global
sorvell: robs idea was that you could make a function wrapper - any time inside this callback, use this registry that im giving you
sorvell: my proposal was different - you could define a custom element - the problem is that in this disconnected state you can customize if youre in the global registry. you can define an element and only upgrade this element dont customize when its created. it wouldnt customize when its created. it would only customize when its connected to the
root that has the registry that you want, which is how upgrades work
sorvell: both of them are too hard to try to get through to get this landed. both of them could be done as a follow on to do better framework integration. in the meantime they can work around it
sorvell: this is the lit communitys most requested thing, i would love to see us get the mvp specified and on the road to impl
rniwa: could you qualify the problem statement?
sorvell: react and frameworks dont use special api to create dom, which you will have to use. to get those frameworks to use a new api to create dom it will be hard. to make this as seamless as we can for them to get this stuff for free that would be great. they dont use shadowdom, but you can make a react element or a framework element that stamps
into shadowdom
sorvell: we should do framework integration as a followon
keithamus: i dont think we should be specifying features to work aroudn existing limitations of frameworks. we should write patches for those frameworks or ask them to. the idea of executing a block of code by ... it would create more problems than it solves
keithamus: the most ergonomic way to do this is to hang apis off of getrootnode and ask them to use that instead of document
sorvell: thats a solid argument. that discussion should not block the core feature
justinf: i disagree with keith. theres a long history in the web components space of saying this is the new reality and - its taken 10 years for react to support custom elements with attributes and properties. we need to build bridges to those destinations. maybe react will never move away from document.createelement. being able to say im going to
call this library and this library calls document.createelement
rniwa: this isnt really a framework integration as much as its making the framework use your registry. you want to force it to integrate
keithamus: force is the word. i respect the argument that frameworks can be very slow to adopt these features, but if we introduce code that forces a situation, we might see the opposite effect where theyre quick to work around it. we're making a hostile situation in their code. the expectations of how their code is being executed is changing
because outside is forcing it, and frameworks try to address this, and it will have the opposite effect that we want.
justinf: isnt the global registry forcing them to use custom elements? were changing which definitions to use. theyre already unaware of the registry anyway
rniwa: lets say were going to do this thing in this function that uses document.createelement. what happens when someone uses innerhtml on it after?
justinf: if that was attached to the shadowroot then the current steps work. otherwise its an open question, what to do about detached trees
keithamus: its your point around timing. if youre saying that during the lifetime of a function we're using this registry. if they do a single await or settimeout then suddenly we changed the pointer of the scoped registry and you have an intermediate set of
justinf: the react patch is to patch the owner on prototype and not be a document but use a scoped registry. its sync and fragile but its what you have to do to get react to work
keithamus: make that a proper part of the spec including the fragility
masonf: im sympathetic to keith, lets not write an api for frameworks but lets make it good. justins point is a good one, the global registry is already happening and frameworks dont know. a similar api effect would be document.defaultregistry and set it to what you want and then run your code. its similar to the global registry, were just changing
how custom elements work
keithamus: you can mitigate timing issues
rniwa: isnt the whole point of scoped registries that you want multiple scoped registries? presumably different parts of the document are trying to use different scoped registries.
justinf: its a workaround when youre rendering into a shadowroot but the framework isnt aware of that
justinf: it could be used for micro frontned architectures. i have an element defined and i want to use it but i cant because it appears at the top of the document. if theres a way to create an element and force it to use a particular registry that would be useful
justinf: i want to take a step back. we have two open questions and we have zerod in on one of them. i dont know if people agree that the disconnected trees one is more important
rniwa: this uses different registry hinges on what we do with a disconnected tree, they are very related
justinf: how do people feel about that?
keithamus: if we have the same suite of apis on shadowroots then we avoid the problem of disconnected trees. people will have to use getrootnode
justinf: the spec does include putting a subset of element creation apis
justinf: if people started using that
sorvell: theres still a problem of innerhtml
sorvell: the core issue is innerhtmling which shadowroot innerhtml which doesnt work in the prototype yet. sethtml should work at the least
<westbrook> Referencing: https://
sorvell: if we have sethtml and we have a solution that does match this idea of - it is not a framework related solution we need a way of creating dom in a registry on an element
keithamus: thats where i think having everything on a root node solves that
sorvell: how does it solve inner html?
justinf: the lookup registry steps use the global registry. there was concern about the memory overhead of having a pointer on a node
justinf: i wonder if we can hang a rare data...
sorvell: at the last f2f the implementors said no
justinf: the lookup a registry steps look to see if theres a registry on the root node
keithamus: innerhtml is deprecated, sethtml and gethtml should be used, they have an options bag and you can pass in a registry. does that solve the issue?
sorvell: it solves the i need to do some inner html on this disconnected node. option bag is on element. if you dont know the registry
keithamus: if you did shadowroot.createelement, it would be disconnected and wouldnt be inside the shadowroot. if you did sethtml you already have a registry but tractable. is the registry a public part of the shadowroot?
justinf: does someone know the right registry to pass? if you create an element with a scoped registry and hand it off?
keithamus: thats always the same problem. you still have to have a reference to the registry at some point
justinf: if the root node knows its registry
justinf: for a disconnected tree
sorvell: it could function like owner document. once you put it in a new document it changes
sorvell: that would probably be better, but implementors said no already
sorvell: so this is the next best thing
sanketj: could you elaborate on the implementors saying no?
keithamus: elements dont have a pointer to the scoped registry because the default lregistry is going to be the specified one
keithamus: adding a pointer to every element would be a lot
rniwa: it would not be rare though
keithamus: createelement would have to return some sort of boxed value. if its an element then you have a box which says this is the custom element and this is the registry and unpacking it would be a bunch of extra work
justinf: if you do create element without a registry it would use the global registry. if you do it in a shadowroot then it would set it
masonf: if you attached it to a tree it could delete that rare thing
sorvell: if you disconnect you have to put it back
sanketj: i thought steve was saying tha tthe registry should live on the document or root and you have this to do the lookup, and that was the thing that was implementor objected about
justinf: the objection was to have a new pointer that every element has to have
sorvell: i think that the sethtml having an arguments bag is enough to move forward on this. its not ideal but i think its a ocmpropose thats reasonable and gets this feature off the ground.
sorvell: this is incredibly problematic for a lot of use cases, and if we can solve it then its awesome
jeff: im one of those people. ?? you lose out on some of those features like innerhtml or createelement. this whole system with registries sounds like its going to be cumbersome and how do i create a library that people can use? i really tried to use native elements instead of frameworks but i still hit that wall. if theres still going to be a wall
that im going to hit, especially with slots
rniwa: we are at time. we need to take the discussion offline
masonf: can somebody post the issue? i feel like we got close to adding an options bag to setinnerhtml
<sanketj> WICG/
<sorvell> WICG/
justinf: i can create a pr and we can argue about whether to merge it
sdfsdf
<masonf> title: Sdfsdf
<dandclark> https://
w3c/tpac2024-breakouts#30
dandclark: presenting https://
dandclark: Shadow roots provide encapsulation, but sometimes ID-based refs needed to cross shadow DOM, ex. ARIA
dandclark: Without totally exposing IDs and breaking encapsulation
… Reflected ARIA properties work for references out of shadow, but not into
… Focused on other direction today - unsolved problem
<jyasskin> Am I reading right that the first direction only works with Javascript enabled?
dandclark: No way to associate label outside shadow with input inside shadow
… Proposal is to add a property on the shadow DOM called referenceTarget to forward external ID references into shadow DOM
… shadowrootreferencetarget for declarative shadow DOM
… Want this to work generally for all ID-based attrs, ie. aria, form, popovertarget, for, etc.
… aria-owns is an exception, reparents parts of accessibility tree, hard to get right
… so aria-owns excluded, no use case found for this either
… Would like to hear if there is a reason to support aria-owns
<Michael_Warren0> ive never even heard of aria-owns :)
dandclark: Properties are reflected in the DOM, but cannot leak shadow contents
… Quering properties in DOM will just get the host element's info
… Works with nested shadow tree, can pass through to deeper shadows
… Prototyped in Blink already
… Forward looking, think about expanding to multiple ref forwarding via a ReferenceTargetMap
… Different attributes needed to target different elements
… Can name each property individually
… Will have both declarative and imperative versions
… ReferenceTargetMap and ReferenceTarget can be used together
… There is an open issue about reflection of properties with invariants
… form attr reflects form relationship, ex. a button associating with a form in shadow DOM
… need to reflect attr without leaking shadow contents
… One solution is to have property to reflect the host element (loosen invariant)
<bkardell_> null seems bad
dandclark: Another issue is association with invalid id
…
… No associated created, how to reflect that?
… One option is to return null, since no relationship
… But that is kind of leaking info about breakage in the shadow DOM
… Other option is to always reflect the host.
<sorvell> Put this in formAssociated custom elements and provide a way to set the form the element is providing
dandclark: Looking for feedback on problem, solution, specific issues, etc.
rniwa: One interesting thing with this feature is that there is a parallel to delegatesfocus
… That also forwards reference inside shadow tree
… There was a proposal for each attribute to have a target variant.
… Any reason for not doing that?
dandclark: Ben might know, but seems like dev ergonomics and future looking are good reasons
… Maybe others have more context
alice: That's right. Want there to be a default forwarding option.
… Ex: the label/input example is a good one
rniwa: having microsyntax of id-to-map is novel and might be better to avoid
<gregwhitworth> rniwa are you referring to cross-root aria? https://
westbrook: microsyntax can help prevent explosion of attributes
… lots of new attributes being brought in
<jyasskin> There's the `data-` -> `dataset` precedent. Could do `shadowrootreferencetarget-aria-controls=foo`
masonf: exception would be listing them all
<bkardell_> +1 to what masonf said
masonf: like that you only list one where the target is different from fallback
rniwa: agree with mason
dandclark: imperative side of reftargetmap allows you set separate properties for each of them, but listing only those differing from fallback for declarative one seems like a good thing
rniwa: maybe update delegatesfocus too in the same way
masonf: like this overall, but tricky to make sure we don't expose the shadow root
… more of an implementation concern
… for form property, would be compatible to switch to a different property, but not if used in wrong ways
sorvell: element could provide real form inside
… if there was something the element could opt into, that would solve it
… want a real form since this is a form API
… correct me if i'm wrong, but we shouldn't block the core feature on this
masonf: +1
aaronlev: noticed a pattern of creating a custom element and putting an aria label on it
… when widget is used, attr is copied
… problem is that there are two separate object in AX tree, can cause double speaking
… worried that this is problematic since very hard to fix once component has starting doing this
<aaronlev> w3c/
aaronlev: filed above issue to give component authors to put role: none
… will allow removing element to be removed from AX tree
<Zakim> jyasskin, you wanted to ask about CSS alignment
<Michael_Warren0> definitely a real issue, but imo thats separate from idref
<sanketj> +1 to what jyasskin
said
<Michael_Warren0> aria-labels arent idrefs etc
jyasskin: ref target seems inconsistent with how CSS exposes parts
… why?
keith: was proposed that way previously, don't remember why we moved to this
alice: that was more verbose
<aaronlev> Can we add my issue to a future agenda since I basically just don't want it to be dropped
masonf: this is more generic, other approach needs to know more about component
<aaronlev> I guess i can just file an issue in web components
rniwa: in the case where you want to forward all refs to one element, much more verbose
<Michael_Warren0> +1 I would argue that label -> input is a lot of the implementation that would be used
sorvell: Seen pattern of moving instead of copying
… Point is we need to get this feature landed
lea: Much better than prev solutions
… in response to Aaron, what you said highlights a big pain point, need to find a solution
… not just about ARIA, for native elements, need to copy properties, etc.
… wanted to ask if reftarget can be read outside the shadow DOM somehow
<westbrook> Level 2 converastion: WICG/
lea: would provide a natural solution to the 2nd open issue, will get host normally
… would also be nice for authors to define their own id ref down the line
… much much later
… shouldn't make that impossible though
… map needs to be able to ref the element itself, may need to specify the host as the reftarget
<Michael_Warren0> if the host is the reference target, wouldnt that just be adding an ID onto the host which is already doable?
dandclark: if reftargetmap doesn't specify reftarget explicitly, will fallback to the host
… for open shadow root, reftarget reflects actual thing in shadow tree
… obviously doesn't work for closed shadows
westbrook: web components CG has been reporting since 2021 that this is one of the top issues that needs to be addressed
… want to make sure that feature expansion doesn't block progress
<gregwhitworth> +1 to westbrook
westbrook: still good to think about level 2 and get agreement from implementors about direction
masonf: agree we are going in the right direction
smaug: me too
masonf: is reftarget is v1 and reftargetmap v2?
<Michael_Warren0> +1 phased approach
dandclark: yes
rniwa: need to check on support
westbrook: when?
rniwa: will try to get an answer ASAP
keith: for form, submit bubble isn't composed
… is form already exposed via other means?
… if not, returning host element is fine
<sorvell> I don't think submit is composed, but not sure.
keith: for open shadows, if submit happens outside form, can get the form?
dandclark: don't want it to be different between open vs closed, but interesting thought
sorvell: is submit really composed?
[keith is looking]
lea: if reftarget ships in level 1 and reftargetmap in level 2, what are semantics of level 1?
… worried it won't cover any use cases
masonf: still useful when forwarding different things to different elements
rniwa: reftargetmap solves this problem
lea: but ships in l2
dandclark: reftargetmap broader solution, but reftarget still addresses simpler cases
<aaronlev> I filed WICG/
dandclark: will eventually need l2
masonf: would be useful for minimal leaf nodes
westbrook: we think 80-90% of use cases to be covered
… perhaps authors are not making more complicated things because not possible
… maybe after reftarget/reftargetmap, we'll see more of those
<Michael_Warren0> https://
sarah: have a component where we can mark one element as target, works well
… is it possible to have a default role for custom element with reftarget/reftargetmap defined?
<Michael_Warren0> per a playground I just did haha
<keithamus> Yeah it's not composed. Click events are so if you had the button inside the form you could still get the composedpath
dandclark: feasible, need to understand about need
… see this as a transparent pass through shadow DOM boundary
<Michael_Warren0> bah, sorry for the bad link haha
sarah: idea is that aria-label, etc. apply to outer element but you want it applied to the inner element
… really want to forward everything to the shadow node
… would be nicer to implicitly forward rather than explicitly forwarding everything
… may encourage right patterns for authors
… : proposal is to have a different default AAM mapping
alice: implicit role none?
rniwa: can be overriden?
sarah: yes and yes
dandclark: would only be if you supplied reftarget but not reftargetmap?
sarah: yes
… current default role is generic
dandclark: will follow up with sarah
… would be possible
rniwa: Webkit supportive of proposal
<bkardell_> 🥳
lea: Support from Mozilla?
<Michael_Warren0> woo! ship it!
everyone: Olli said yes earlier.
<lea> 🚀
rniwa: should we move the list of attributes onto the shadow root instead of the map?
… would resemble delegatesfocus
lea: maybe rename delegatesfocus?
alice: I think delegatesfocus is doing something different. Picking focus based on direction.
<lea> delegatesReferences?
<lea> delegatesIds? delegatesTo?
<rniwa> rniwa: I think it might be better to have individual attributes instead of a map with a micro syntax to be consistent with delegatesFocus.
westbrook: do we have a spec writer on board? that would be helpful
dandclark: i'll do it, unless others want to be onboard
keith: i'll do it with Dan
alice: i'll help Dan and Keith work on the spec
jesse: when custom element wraps an input, can we just inherit the role onto the host?
keith: shadow roots are transparent
… want the opposite, role should be none or generic
masonf: yeah, would cause two nested elements with same role
sorvell: can we avoid long, verbose attribute names?
… can we revisit something like data-?
… no concrete proposal though
keith: don't mind on the attribute names, but microsyntax is worse than attributes
… easy to bundle attrs using templating libraries
sorvell: isn't that what happens with export parts?
rniwa: semantics very different
<Zakim> lea, you wanted to react to keithamus to say +1 for shorter attributes, but we need to avoid hyphens so we can have the option of custom attributes open
rniwa: may be an argument for not doing microsyntax
lea: custom attributes should still be explored
Michael_Warren: shorter attrs would be nice, especially people that hand write shadow DOM
… not everyone uses a build tool
<lea> +1 to "not everyone uses a build tool"
dandclark: Next step is to write the spec, continue to work on prototype, potentially consider OT in Blink
masonf: Can we come back to the form question? Since we didn't get an answer.
dandclark: Also the question about broken ref.
masonf: Should just return the host?
lea: yes
lea: AX tree would also fallback to host, right/
?
dandclark: yes
keith: would be good to try this on a test bench
… hard to come up with the expected answer
… weak argument though
Michael_Warren: Someone said id ref different than other ARIA references. How different are the implementations?
dandclark: reftarget as proposed is not limited to ARIA
… supports all id based lookups
masonf: string based ones could technically be adapted too
rniwa: are we adjusting svg use too?
lea: uses href, not id
rniwa: resolved to change semantics, does use id for things with that SVG tree
dandclark: not adjusted those
rniwa: may need to review where id lookup is done
<Zakim> alice, you wanted to go back to the <form> question if we have tiem
alice: RE form question: Not sure about issues from leaking, but tells info about host, which means it can 'act' as an element you are targeting
keith: what about .form today on an element?
… that's undefined, right?
dandclark: yeah, might be compat since it returns null today and now invalid ref would cause it to return the host
keith: Restating... .form returns null if element not form participant, but if reftarget always fallbacks to host, then .form will always fallback to the host element and look like a form participant
dandclark: Maybe a good principal is that reftarget won't change property reflections or other internal associations
… For aria properties, would just change those internal associations, but not the property reflections
keith: No way to use form property on custom element, right?
xiaochengh: Maybe shouldn't push reftargetmap to level 2?
lea: That's a lot more complex. Forwarding everything to one element is simpler and addresses a lot of use cases.
xiaochengh: Risky. Ex: How do we address form?
masonf: Maybe we try to address all properties first and strive for reftarget only in level 1.
<sorvell> w3c/
sorvell: Let's focus discussion on theming if we can, goals for how to do that. My 2c is we have two tools, custom props and parts
… Custom props apply narrowly and deeply , parts apply to any prop but shallowly
… Can we explore how to make parts apply deeply across the tree
… We have export parts which are broken. No traction on issue. Simple fix is to expose via wildcards
… Have exponential @@@, have levels of shadow roots
<westbrook> w3c/
<keithamus> WICG/
sorvell: Open styleable should be very specific tool to facilitae migrating old stylesheets
… Can discuss all of this in detail if we get there
justinf: Want to reiterate, discuss theming outside open styleable
… Want to take step back. We had ::parts selector and ::theme selector. Have idea on ::theme I'd like to talk about
… Have two tools, one is deep, want to find something in between
… Theme was blocked because people didn't want part attribute to imply something could be themed
sorvell: I want to plant early seed -- I highly doubt we'll get that far today on defining theme thing. Lots of related issues. Want to see CSSWG get more involved
… Especially because discussing how to match things across compose tree, how combinators work
masonf: The way you started as we should work on open styleable because it's easier.
justinf: They're different topics
… Theming is adding hew capability for deep theming across shadows
sorvell: Open styling is simple proposal blossoms into different issues.
masonf: There's like 10 different use cases from I have a shadow and want to style
justinf: Need a solution that works for existing sheets.
masonf: I've heard use case of I have existing styles, and I have global styles that I want to apply to a button
rniwa: Stepping back, we are trying to solve problem of you have a stylesheet in main doc, and want some part to apply to shadow.
… People arguing these are sufficiently different to need 2 solutions. Do people agree?
sorvell: yes. Open styleable blows away any type of encapsulation because everything is targetable. Theming API doesnt.
rniwa: Depends on what you mean by open shadow tree. Depends on semantics of what we define
masonf: Can hit use cases if you can control with an option
sorvell: Every shadow applying to shadow is very brittle
… vs something like part where you explicitly state everything you want to style
Michael_Warren0: I don't think it breaks all encapsulation. Breaks outside in.
… That's what folks who are used to how framework components expect.
<gregwhitworth> to throw a wrench in this I would prefer to have web components and slots not require a shadow
Michael_Warren0: The styles declared in component can't get out, but styles outside can get in
… Doesn't break all encapsulation that way. Breaks outside in but in a way folks want.
<masonf> +1 that's the complaint I've heard the most.
Michael_Warren0: They have to deal with this today with React components
… In some respects to the q of whether theyre sufficently different, comes down to the stylesheets. Looking at the issue there's not a lot of desire for limited API. Desire is for full application, and folks must manage risk of collisions
justinf: Open styleable and theming are different set of capabilities. What we walked about with `::theme` was related to parts
… Opening up shadow root is how you expose stuff in shadow. What is the role of part in this? Want something more controlled that doesn't throw out encapsulation.
<gregwhitworth> justinf can you give/link to a quick summary/recap of your impression of ::theme?
justinf: Theme selector can target parts deep in shadow tree. Doesn't loose validity because we have this other use case.
… We can make a more targeted API. We went down that path but didn't finish.
sorvell: I want to echo Justin. This is a 'yes and'.
<Michael_Warren0> headless components is another big feature for open-stylable. in the case of headless comps where you do want to open up "all" of the internals for styling from the outside, how would ::theme work for that?
sorvell: Problem is there are lots of use cases. Think if you did this with input. That div that you have contenteditable in, author can style it. This is about finishing part, making it reasonable. Like with open and closed shadow, there are different use cases.
… You can do this today
<Michael_Warren0> if ::theme is meant to not be an "all stylable" solution, we'd have to also solve for headless components too in an "unlimited" kind of way that might be cumbersome from the limitations of what ::theme would have
masonf: There are 2 viewpoints in the room. Webcomponents users and webcomponent authors. Have heard often, 'I want slots'. Just want styles to keep working. That's the perspective of component users.
… We keep going back and forth between those
justinf: I disagree with that characterization. People have problem with trying to fit component into page with existing stylesheet. People creating new components try the best they can with CSS custom props. Have limited styleability so can limp along with that.
masonf: Theres back compat, but also people used to doing this with non-shadow pages. They want to keep doing that.
gregwhitworth: 2 points. I feel like it's been eternity since I've seen what `theme` is. Is there a link?
TabAtkins: Variant on `part`. Doesn't exist in spec now.
<westbrook> https://
<westbrook> Woops link through: https://
gregwhitworth: At salesforce we've moved away from native webcomponents. We have 3p extensions. People use extensions for e.g. a11y. They don't support native webcomponents.
… We convert slots into light DOM
<westbrook> Inability to copy/paste right today: https://
gregwhitworth: Don't get `slotted`, don't get `part`, but @@@ just works
rniwa: I think solution for open styleable shadow and theming could be coherent with each other. Have one solution with ability be strict
… Could also apply all the styles. No design restriction that these need to be separate.
… Not saying that's what we want but we should consider the possibility.
… Problem seems to come up in many use cases.
… Don't want 3-4 solutions to same problem. Want single solution for most use cases. Or maybe 2 solutions.
<gregwhitworth> +1 to @rniwa
miriam: As author of page using components, and author of components, don't think it breaks down so easily.
… Sometimes I have specialized parts, so part approach makes sense
… But sometimes I just have a button I want you to style
… `part` doesn't work great, need to give button a specialized name.
… The other thing with `part` is that sometimes I have chunk of component I want to keep specialized. And other parts I want to expose for styling.
… So not total either-or.
… Want to expose some parts for global styles, and expose others selectively or keep hidden.
<gregwhitworth> +1 to miriam as our base components team uses native shadow for this
miriam: So it's a false dichotomy.
sorvell: I agree with that. Enhancing parts is what I want to focus on because I think it's straightforward. But not a full set of solutions.
… Potentially advancing open styleable helps with this. To mason -- I agree people want light dom slotting but I don't know how. Want your ideas, but separately
<gregwhitworth> Here is LWC's light DOM which takes a web component and renders it in Light DOM: https://
lea: Current style encapsulation is barrier for shadow DOM. One case is templating. Reusable widgets to enhance what HTML is able to do.
<justinf> a few slides on an idea for how to make ::theme() work with parts: https://
lea: All or nothing works well for templating, but not for reusable widgets
… Encapsulation of some degree is desirable
… right now we have the nothing, open styleable is the all, nothing cover all use cases
… Want to opt in specific nodes, or remove specific nodes from what is exposed
<miriam> (this is still using the dichotomy that I'm trying to argue against)
lea: Not saying open styleable shouldn't advance, it covers chunk of use cases. But we need more granularity.
… I posed proposal yesterday about exposing a subset.
… Not sure if want to center discussion around that, main focus is the problem
… I don't think I've ever needed full open styleability.
… There's always something you don't want to expose. But almost everything is exposed when you use parts.
<TabAtkins> Big +1 on the "almost is important here"
masonf: Rniwa has good point that more granular API can maybe handle fully open styles.
<justinf> +1. another thing people don't always want to expose is the tree structure relationship between parts... yes, sometimes they do
rniwa: Going back to use cases, expanding `part` is one approach.
… Can generalize it, make it work across different trees. That's `theme`
… Other approach is define back of props in CSS, have a way to apply those in your tree
… And I'm sure there are other proposals
<lea> In the spirit of throwing ideas out, here’s the very very rough draft I mentioned: w3c/
rniwa: Can we go through more concrete proposals and evaluate which is more suitable for the use cases. People have vague ideas of what it should look like, but have been very vague about how we will accomplish it.
<lea> though thinking some more, I wonder if what is more suitable is opting nodes *out*, rather than opting them *in*
miriam: I keep hearing assumption about this dichotomy that's not my experience. Mine is not that either i'm providing should or should not be fully styleable
… My assumption is always the page author knows what styles should or should not go inside
… And from both ends I want to apply some of my global styles to some of the things in the component
<bkardell_> +1 to that bit Mia just said
miriam: It's not simple dichotomy
masonf: Makes sense, but what's the API look like?
sorvell: I agree, we need to look at this as differnt pieces of overall puzzle.
… I want to focus on what I see as easier problem: We have syntax which is for opting parts of trees in, that's `part`. But falls over with composition. Exportparts sucks
… Because no wildcards. So should add those
… But still sucks, it's too fiddly
<TabAtkins> Wildcards are an easy fix, sorvell's exact idea was proposed back in 2018 (I linked in the issue)
sorvell: Deep composition -- inside this special container thing I want to target some buttons, I need combinators
… Shadow and deep from v0 spec was combinators into shadows
… We'd go really far with that capability but restricted to the `part` tree.
… Then we have that aspect of theming
… But don't know how that works in CSS
… Those 2 thinks, fixing exportparts and making parts deeply addressable; at least for that aspect of the puzzle moves the ball forward
TabAtkins: Lea linked proposal from a few days ago that's exactly what you're saying sorvell.
sorvell: Thanks!
<justinf> can someone repost the link?
masonf: The specific proposal is `part` exposes part of the tree but it painful to use, so this exposes all the parts as a reduced version of the shadow tree, selectable with combinators.
Michael_Warren0: It's tempting to think about the problem and solution from component perspective. But it's multidimensional. Depends on who you are relative to the cmponent and the application that's using it
<justinf> lea do you ahve the proposal link?
<lea> justinf: w3c/
<justinf> thanks!
Michael_Warren0: @@@ isn't necessarily theming because I'm not just changing a color, there are other bigger things like layout I'm changing.
… E.g. Shoelace, author has no knowledge of what exists in the component
… Want to narrow down the relationship between the component and the environment.
<sorvell> Thanks so much Lea, this proposal is amazing (w3c/
justinf: To rniwa's point about concrete proposals. We had thing that exist, CSS props and parts
… upcoming CSS features like mixins, vague versions of `theme`. Each has pros and cons.
… gatherting that might help us make a rubric for evaluating other things.
… Important aspect of the solution is you can potentially merge different styles.
… If you go through these you will come up with the types of objectsions you'll need to just solutions by
sorvell: We use style isolation in shadowDom as big hammer for core problem with CSS
… Want page to have styling policy where I say some user of lib can style certain things. But can't style others.
… e.g. input has placeholder. Lots of props you can set on placeholder that break the input.
… If browser had way to limit what you can do with that, that would be good
<lea> thanks sorvell, glad I posted it then! Took me a while to press the submit button, I thought it was so outside the Overton window and so ambitious that I'd lose all credibility 🤣
sorvell: It's just a CSS concept we don't have.
… For lack of better word I'm calling it a policy
justinf: Looking at nonwebcomonent solutions as well. It's common in corporate environments it's common to have policy that bans certain selectors. Have to use opaque classnames.
… That's common with solutions like userland CSS modules
… Points to people not using selectors like they could.
… Maybe also indicates we don't need the full selector feature set.
… People get by now using IDs and opaque classnames.
… I worry about exposing tree structure relationship of parts. Hvae seen components change where that changes, so that's a breaking change for the component.
sorvell: I think this is a big space. Have webcomponents CG but don't have CSS horsepower in that group. Want more participation. Know there's interest in CSSWG but not sure how we can do that. Ideas for that would be awesome
masonf: ONe specific idea was `::part` with some combinator. Can we look at that more?
JRJurman: Thinking about what greg mentioned, I get the sense that as people put out components, if there was some way to expose some part for styling, there will probably be pressure to expose the whole thing. E.g. extensions that want to change everything.
… Not sure if I'd ever want to say I"m making a thing and only some can be styled, then anticipate github issues about wanting more to be styleable
… If people want to style it, there's pressure to let them
rniwa: focusing on theming use cases might be valuable way to limit discussion. Problem space is v big.
… Despite I said needs to be solution for all of them, maybe don't need solution for all use cases.
masonf: +1 let;s pick solution and see what cases it solves
sanketj: I agree. Let's outline what proposals we have, what they solve.
<justinf> I'd like to present an idea for ::theme() that I think addresses a lot of problems with parts
<Michael_Warren0> +1 to Lea's proposal above. It seems like it would work for headless components (ie, in a tailwind global css env) and would work for design systems like web awesome
sanketj: Maybe there's some lines we can continue to bring discussion forward
justinf: Tab and I looked at theme. Big problem was it selected too many things. People that added part attrs to their shadow maybe dind't want those to be exposed all the way up the tree
… Component using child component doesn't necessarily want to expose all the child parts for theming
… So wanted to make theming more targeteable.
<Michael_Warren0> to justin's point, a good thing about lea's proposal above is that it doesnt need names that would have conflicts
justinf: Also need a way to filter by host, but not by host tag name, might be different by component. Want host to opt into exposing things as theme, and establish some identifier for those. When selecting for those, select some theme name and part.
<Michael_Warren0> the point about having naming conflicts is a good one, so imo a solution should prevent that
justinf: Goes deeply down the page, is coherent with parts but more targeted.
… Goes a long way towards letting design systems do what they want
sorvell: I think that's interesting idea.
<TabAtkins> I'd love to see that written as a rough proposal, it would help me understand it a little better.
sorvell: The reason I like having solution that includes combinators is my mental model for sytling is needs to satisfy: want to style one, want to style all, want to style some, where typically that's some subtree
<lea> +1 to sorvell
sorvell: Main point is: we have exportparts. We have parts. Not great, cumbersome -- don't work because need to export parts on all the things, becomes burdensome.
<TabAtkins> +1 to this
sorvell: Adding wildcards is very simple way to achieve something useful
justinf: It's more broken because of name collisions
<westbrook> WICG/
TabAtkins: Forwarding and prefix-changing was part of original proposal
sorvell: It's completely unusable. Shoelace uses but that's about it because it's so cumbersome
<TabAtkins> exportparts="*" to forward all as-is, exportparts="foo-*: bar-*" to forward all the foo- prefixes, replaced with bar- prefixes
masonf: Seems like separate issue, but a good one
<kschmi> w3c/
<masonf> Go here https://
<Michael_Warren0> export parts seems tricky. if lea's proposal gets traction, i could see export parts being deprecated in favor of that feature. lea's proposal seems to be a re-imagining of parts in a more robust way
<masonf> and click the join button
sorvell: I beg your patience because I respec the people in this room. One of the things as a component user is when there's awesome new stuff added CSS, but we wonder if it will work in shadow DOM.
… The more we can make stuff so these questions are worked out the better. E.g. how does `has` work with shadow DOM is unclear
<Michael_Warren0> +1000 to awesome css features in shadow dom
sorvell: The more we can get a genral solution the better
lea: <presents her new proposal>
… Filed this yesterday, wasn't sure if should post
… Was thinking part is a huge pain point both when defining and using components. When defining because have to expose with reasonable names. When using you have to figure out names, build mental model of how fits together, and there's still stuff you can't do
… I was thinking what is the real author intent? It's that we want to expose subset of shadow tree with `part`.
… When people use part, over 90% of elements are exposed
… Usually need reason *not* to expose something
… Open styleable sort of solves this but usually still need to hide something
… What if we had html attribute -- tentatively `export`; it just exports that element
… Introduce combinator that gives you access to this exposed subtree. Don't know if you need mutiple or just once works
… That subtee only consists of exposed elements.
… Within it, selectors just work normally but only apply to that subtree
… You could even use attribute selectors on `part` , making `part` work better
… Can introduce more granularity, cutting out subtrees, or even granularity on sub-element level
… Can even introduce syntax to allow aria to hook in
… Or other parts of the platform. Depends on the overlap of what elements you want to expose for styling and for other purposes
… Can also be used with native elements, instead of introducing a bunch of new pseudos
… Maybe the element type would not be exposed so you can't use type selectors
… Could even end up with a different structure then what you originally had
… <walks though example with spinner, where exposed subteee is different>
… But it could break expectations e.g. if you're applying grid
… But part has the same problem
… Open questions: Has access to full flattened subtree? And what if the better approach is to opt out rather than opt in?
justinf: think we need virtual DOM in this other place, where component can produce virtual subtree.
… One detail is that custom element tagnames aren't reliable as selectors. Host needs to apply a stable label.
… Material-button could be under any tagname. For this type of component, I want to expose this type of thing inside of it. That applies deeply
lea: You can just use part
justinf: But that's applied from the outside
sorvell: I like the direction of this. Exploring stuff like how do you want to export this is good. Might have internal classes I don't want to expose, but fine to export others. Other thing i want to expore is it seems like we're circling this idea of a policy of how I want to expose styling. Does this idea need to be locked in shadow DOM?
… I'm describing what I want to be styleable. That's sort of what scope is doing
<miriam> Scope is selector-in. It can't handle this sort of thing
<miriam> This sort of policy has to be DOM-out
Michael_Warren0: I think about this a lot -- stable names. Concern I have is applying that selector uses something considered internal to that component if it were a 3p. That introduces brittleness.
… The component could change, that thing we exposed might not be the same anymore. Could break every selector. Needs to be something that isn't selector based. Maybe proposal doesn
… 't let you use those. It's a place that can introduce brittleness. Class name might not exist later.
<sorvell> Rough... `@scope ... { appearance: exports-only; ... }`
masonf: Adding this export to your shadow means you're adding it to contract of your component
justinf: Might have classes that are internal that you don't want to be exposed. @@@
Michael_Warren0: I might refactor the component in a way that I don't know if it's breaking, because I don't know who's querying it.
… Might want to thing about putting stable names back in this.
<miriam> sorvell: Happy to follow up on that at some point (an issue?) but I'm not sure what you see that scoped appearance property doing.
Michael_Warren0: Want to make them truly stable so they can't be changed
lea: I heard discussions about theming. that's what the next breakout is about, but on a lower level
<astearns> https://
<emilio> rniwa: dan, can you summarize the state of the proposal?
<emilio> dandclark: I can try to summarize the current state after this morning's discussion
<rniwa> https://
<emilio> dandclark: css modules allow you to import your styles from CSS and then apply them dynamically with adopted stylesheets
<emilio> ... I can have just one stylesheet and I can apply it to all those different shadow trees
<emilio> ... that all works quite nicely
<emilio> ... with declarative shadow dom this isn't the full story
<emilio> ... because I don't want to need script to do this
<emilio> ... we can look at other solutions to apply styles to declarative shadow trees
<emilio> ... inline styles are not great and duplicate stuff
<emilio> ... css modules might be the best way of dealing with this
<emilio> kschmi: I think something like this (slide 5) is the best way to go
<emilio> ... we had some discussion about <script> vs. <template>
<emilio> ... all of them have pros and cons
<emilio> ... <style> would apply to the light dom which we don't want
<emilio> annevk: <style type=module> won't right?
<emilio> kschmi: older browsers will apply it
<emilio> annevk: they shouldn't right?
<emilio> ... <style type=module> doesn't style the page now
<emilio> kschmi: seems it'd be an option then
<emilio> rniwa: <style> seems the more natural thing to do
<emilio> ... that way we can do <template> for html, <script> for script, and <style> for style
<emilio> westbrook: right now import with syntax is blink-only
<emilio> ... are other browsers opposed to something like that?
<obuckley> there's an interop proposal for Import attributes (+ CSS / JSON)
<obuckley> web-platform-tests/
<emilio> annevk: we do support import with generally
<emilio> ... might not support css yet
<emilio> ... wonder if all browsers handle CSP around that correctly
<justinf> assert was removed from Chrome
<emilio> ... there's also the big syntax change from assert to with
<emilio> ... we're generally supportive
<astearns> "official" support: WebKit/
<justinf> I don't think Chrome has implemented the fetch destination yet
<masonf> emilio: for what it's worth, same here. Only blocking thing is time to implement it.
<emilio> emilio: same, on Mozilla's side, send patches? :)
<emilio> annevk: can I ask something else?
<emilio> ... how the specified thing relates to the content
<emilio> ... `specifier=/foo.css` in the slide
<emilio> kschmi: it's putting it into the module map with that specifier being the key
<emilio> ... it's effectively an identifier
<emilio> annevk: does script support that?
<emilio> justinf: I think it's a great idea to use the script tag
<emilio> ... because this approach applies to anything in the module map
<emilio> ... you want to inline a JS module but still be able to import it from other JS modules
<emilio> annevk: would you want it to execute it in today's browsers or not?
<emilio> justinf: Maybe we add another type
<emilio> ... but you might want this for WASM as well right?
<emilio> ... I think putting this in script is really powerful
<emilio> annevk: isn't WASM effectively a byte sequence? How would that work inline?
<emilio> justinf: dunno, but we have the module graph
<emilio> ... if we do it in a way that's potentially compatible with other things in the module graph then it's great
<emilio> rniwa: but <script> can't be nested
<emilio> justinf: you can escape it right?
<emilio> annevk: you can escape the end tag, it's very ugly
<emilio> ... like if you have a backslash before the closing tag
<emilio> justinf: I think it's potentially very powerful and it works beyond CSS
<emilio> sanketj: two things seems separate: (1) what elements we use. (2) how does the attribute work
<emilio> ... might be separate discussions, can we scope to one of them?
<emilio> hiroshige: same feeling
<emilio> ... re how it works, module maps are URL-keyed
<emilio> ... but this is equivalent to specifying the URL
<emilio> ... anyways I think there's ways of making the things consistently work
<emilio> ... if we are to specify an URL, it might also be an option given importmap has a similar ability
<emilio> ... here we specify the url in the inline script but is similar to intercept the url request
<emilio> rniwa: so you're seing `specifier` is like a url, then what
<emilio> hiroshige: then it looks like intercepting the request
<emilio> ... instead of actually requesting the thing
<emilio> rniwa: so there's a conflict between this and the file that exists (`foo.css`)
<masonf> masonf: there are also timing issues here - if you use the URL/name before it's defined, that could result in a network request.
<annevk> In particular if a script does import "/foo.js" as well, what happens? There might be a race.
<justinf> the "conflict" is useful
<justinf> you want to dedupe between modules that import /foo.css and the inline
<masonf> emilio: what if you request foo.css synchronously and you haven't sent the script tag yet.
<masonf> emilio: do JS modules have an answer for that? Or is this new?
<justinf> we need to break ties here
<emilio> annevk: I think you parse it and insert it in the module map
<emilio> emilio: but you might already have started a fetch
<emilio> dandclark: I think first one should win, and if we parse the inline one after we've tried to fetch we either ignore or fail
<emilio> annevk: either override or fail
<emilio> dandclark: don't think we want to override
<emilio> annevk: bail and log to console?
<emilio> westbrook: 2 cents re. element names
<emilio> ... really like the idea of different modules using specific elements
<emilio> ... so <script> for script modules, <template> for html, <style> for style
<masonf> +1
<emilio> ... that opens the possibilities to normalize the attributes
<justinf> what about resources that don't have tags with them?
<emilio> ... so type=module on <style> does the same for style as type=module for <template>
<masonf> <json>
<emilio> ... it has a ceiling which is where do you put the json module
<justinf> a new raw text element?
<emilio> ... because it fails apart I wonder if it makes sense to use <script>
<emilio> ... but given that falls apart for <template>...
<justinf> I don't think <script> falls apart with <template>
<emilio> sanketj: perhaps json and script modules should use <script>?
<emilio> ... the other thing is that you can reuse the type
<emilio> ... attribute
<emilio> sorvell: that throws me a little bit because it seems we need a solution for inline modules generally
<emilio> ... even inline JS modules
<emilio> annevk: I think TC39 is working on stuff around that
<emilio> justinf: they're working on it with JS syntax
<emilio> annevk: but we duplicate it with script type=inline-module
<emilio> justinf: I don't think it is a duplicate of the module declaration proposal because that gives you an object, not an specifier
<emilio> sorvell: if we have <script> we have inline or out of line
<emilio> ... but if we use <style>, we'd need <link> for out of line styles
<emilio> emilio: you don't need out-of-line modules right? You'd import the url directly
<justinf> we want <script> to be able to load non-JS modules, right?
<emilio> dandclark: you'll be able to do `import "myStyles.css" with { type: "css" }`
<justinf> isn't that how HTML modules are supposed to work?
<emilio> annevk: what if you just have the `<template>` thing?
<justinf> <script type="html" src="/foo.html"></script>
<emilio> dandclark: we'd make the template either trigger the fetch
<emilio> ... leaning not to do that
<emilio> ... I think it's clearer if the template attribute just pulls from the module map
<justinf> +1 to masonf
<emilio> masonf: There are two different things, `<script>` adds to the module map, and template pulls from it or fetches
<masonf> westbrook I added you to the queue
<emilio> emilio: why would you fetch instead of using `<link>`?
<emilio> westbrook: `<link>` doesn't add to the module map
<emilio> masonf: less typing too?
<Zakim> dandclark, you wanted to talk about <script> tags and no-JS
<emilio> dandclark: I agree these are two separate features
<emilio> ... we can probably do `<template adoptedstylesheets>` consume from the module map
<emilio> ... then figure out if that should do the fetch and add to the module map
<emilio> ... we need to give it some thought
<emilio> ... feedback would be great
<emilio> westbrook: I really like the idea that adoptedstylesheets is the declarative syntax with import with type=css and then can be brought to have inline module declarations
<emilio> ... I think that's valuable as a developer
<emilio> ... not so much about `<link>`, links are not for styling custom elements
<emilio> emilio: you can
<astearns> (disagreements on current reality)
<hiroshige> FYI as for how to name/import inline modules: previous discussions at whatwg/
emilio: What's the difference between this <link href> and between requesting a URL not in the module map?
<emilio> masonf: we're debating the less useful part of this proposal
<emilio> justinf: I want to reiterate that a huge part of the value is using the module map
<emilio> ... we have CSS modules on the module graph
<emilio> ... being able to deduplicate the styles via the module graph is a critical
emilio: I agree with that, but what I was discussing was the difference between if foo.css is not in the module graph -- We were discussing whether this attribute could trigger a fetch. I don't think we want that. If you say adoptedstylesheets=foo.css triggers the fetch, isn't the behavior we have now with <link>?
justinf: But <link> doesn't put them in the module graph
… We need it to populate the module graph
… Seems OK that having it populate the module graph here is OK.
annevk: Emilio is talking about the case where the module graph is not already populated
justinf: It's the same. You can have race conditions
… See the request before you have the script tag that defines it
annevk: But then there is something in the module graph
<emilio> dandclark: you suspend and wait until the initial fetch comes back
<emilio> ... you have an empty entry in the module map
emilio: So I'm clear, the only difference between foo.css not being in module map, and whether we trigger fetch or not here. I want to make it clear that if you hit this, assuming we trigger a fetch, the whole point of that is maybe some JS eventually will import this as a CSS module and it's already there.
… If you use a link the CSS is there in the browser cache but not the module map
… And if you were to import it, would have 2 sheets technically
… Not opposed to triggering fetch but feels like duplicating a lot with link
<emilio> sorvell: just a point of understanding, is there a difference with `<link>` with the browser cache? Is that different from the JS module graphi
emilio: It shouldn't trigger fetch
<emilio> emilio: the browser cache exists, but if you disable you most likely don't trigger multiple fetches
<emilio> sorvell: agree this is the less interesting bit but should be supported
<emilio> rniwa: I wonder if we could use a `#` at the beginning
<emilio> ... so that you'd use `specifier="#foo"`
emilio: But I thought we were saying that you should be able to trigger a regular fetch if the entry isn't there already.
<emilio> justinf: it's a feature, not a bug, that it uses the same url map as js modules
<Zakim> justinf, you wanted to react to rniwa
<emilio> ... when we do SSR we want to not pull the css if we've sent it already
<emilio> rniwa: wdym with sending the css?
<emilio> justinf: you have a module map with mixed css and js
<emilio> ... your server code loads this and tracks the URL and outputs the declarative CSS module using the same specifier as your JS modules use
<emilio> ... that way if you send the JS module to the client it's already in the module map
<emilio> rniwa: that doesn't affect whether you can use a prefix right?
<emilio> justinf: in JS you wouldn't import with a prefix
<emilio> annevk: what's the point of the prefix
<emilio> rniwa: the point is to avoid the confusion between actual files
<emilio> ... and the inline things
<justinf> importmaps let you use bare specifiers
<emilio> justinf: but it's not a confusion, it's a feature
<hiroshige> FYI as for how to name/import inline modules: previous discussions at whatwg/
<emilio> dandclark: do we want to allow random module specifiers like external domains or something?
<emilio> emilio: should probably be same origin
<justinf> JS imports don't have to be same origin
<emilio> hiroshige: previously has been proposed to use a `:` or some other special URL to separate inline modules
<emilio> rniwa: I see arguments for both, maybe the overriding with the inline thing is an anti-feature and we don't want that
<emilio> kouhei: was going to say the same thing
<emilio> ... we generally don't want to mix inline modules from fetch modules
<emilio> justinf: in the use cases we have nobody is writing this by hand
<emilio> ... you have an implementation of web components in js
<emilio> ... which have css imports
<annevk> This seems like it would be the first time we have specifiers in markup, right? It does seem a little confusing.
<emilio> ... so SSR would use this feature and eventually it will be pulled into the JS
<justinf> In JS:
<justinf> import styles from './styles.css';
<justinf> class MyElement extends HTMLElement {
<justinf> argh... I won't try write code here
<emilio> sorvell: So I have an SSRd component and a non-SSRd one you want to use the non-SSRd one independently of whether you've SSRd a component before
<emilio> hiroshige: but you could use the prefixed specifier in inline and SSR case if you set up the module map correctly
<emilio> ... you can set it to look the local specified and then the network, or just inline then fail
<emilio> ... same specifier can be used anywhere within a document
<emilio> sanketj: this new specifier (name tbd) is something that we can use to solve declarative modules in general
<emilio> ... specifier should go in <script> / <style> / <template>, and you could use it to put stuff declaratively in the module map
<emilio> ... is that correct?
<emilio> (yes)
<emilio> westbrook: having listened to the questions, could a link tag be aumented to inject the content in the module graph?
<sorvell> tc39/
<justinf> So here's an example of JS importing CSS: https://
<emilio> sorvell: I agree this seems like a general module inlining problem
Re: westrbrook, is that <link rel="modulepreload">? https://
<emilio> ... linked above the JS proposal, it's within JS so doesn't work for us
<justinf> q?
<justinf> q+
<emilio> rniwa: the idea that we want to share namespace to solve the general namespace inlining it seems like reinventing importmaps
<emilio> justinf: this is similar to import maps in the sense that it can populate the module graph
<emilio> ... but there's a bit difference because it's also inlining the contents
<emilio> ... but also it doesn't have to come at the top of the file
<emilio> ... which is an important use case because you don't know what elements you're going to render
<emilio> ... so they make them uniquely different from importmaps
<emilio> hiroshige: because of that the importmap is has complex implications
<emilio> annevk: afaict we don't have any attrs that have module specifiers
<emilio> ... and it's confusing that it looks a lot like a URL but isn't a URL
<justinf> as part of the import map proposal, we used to talk about the import: prefix for specifiers in HTML
<emilio> ... I understand why JS did that but from HTML perspective it's much less clear
<emilio> ... naive assumption would be that you'd just resolve /foo.css and start loading
<justinf> so you could do <img src="import:cool-package/hero.jpeg">
<emilio> kouhei: implementation wise this looks complex
<emilio> ... specially re. failure cases
<emilio> dandclark: next steps, we have explainers r/n, we want to put it through WHATWG stages
<emilio> ... trying to get those filed and tag people
<kschmi0> https://
<sorvell> #tpachelp
<keithamus> lea: not sure I am familiar with the later shape
<keithamus> masonf: slides are an overview?
<keithamus> justinf: this is a template API, another motivation for DOM parts.
rniwa: chromium prototype first?
<sorvell> Lea what happened to "Integrating UI components is too damn hard!"?
masonf: two links - imperative & declarative. Implemented majority of both
<rniwa> https://
<rniwa> https://
<lea> @sorvell: It was in the previous slot!
masonf: general concept: dom parts marks node in tree, retrieve reference to those with imperative API
… node part marks node, attribute part marks attribute child node part marks a range of nodes
… there is an imperative API for constructing node part, it'll be marked in the DOM tree and you can keep track as it moves around
… similarly for child nodes & attribute
… more interesting is declarative syntax. You can opt in with parseparts attribute, within that subtree {{}} mustache syntax will give you a part created there
… {{}} within attribute or within a node you'll get a attribute or node part respectively
<masonf> {{#}} dsfsdf {{/}}
masonf: child node part delimiters
… it looks like the explainer is outdated vs implementation
… this is all subject to bikeshedding but the takeaway is the concepts. Child node part is between two markers
… that's the broad strokes.
<sorvell> @lea are there minutes available somewhere?
masonf: How do you use those parts? You can do it on template element or document fragment to getPartRoot() - then ask that for its parts.
… so if you have a template you can get the parts without traversing
… value proposition being the parts are kept track of by the browser
rniwa: did you add clone with the parts?
masonf: yes. You can clone a tree and get parts attached that were attached to the original tree. So you get a stamped out copy where you know where all the parts were
<sorvell> @lea thanks so much
masonf: they're kept track of as the browser goes through them
masonf: Various teams in google have tried this out. How ergonomic/performant. Interesting thing is perf is tough. One possible competing technique is a compiled framework can do firstChild nextSibling which can get the nodes very fast.
… trying to replace with DOMparts can be challenging compared to compile ahead. At best its on par, at worst its slower
… there are other perf tradeoffs. You attach parts to interesting nodes - there is a question about if you want to keep track of dom mutations. Should I keep track of where the part went? If so it takes work and slows parts of the browser down
… if you don't then its less useful
tomayac: declarative shadowroots? with stamped out content? Would it be clonable and work?
<justinf> q+
masonf: yes
tomayac: if you have the same DSD several times on the page would it be copied?
masonf: this does not solve the duplicate DSD problem
tomayac: could it?
masonf: it just requires additional synax
… it may be orthogonal
sorvell: ask more about perf: initially the hope we could justify on the basis of building block of more interesting things, but also justifable on its own if it improves perf
… creating DOM with template is really fast. But you're saying this isn't a win?
… assuming we build other features, have you looked at how much perf we give up in more complex cases?
… With the minimal feature set is it a few % or twice as slow or something?
masonf: I think this is an ergonomic win and JS size win. The perf tradeoff is you cant make it a lot slower. So its a no-go. I don't think its a perf win but perf parity.
… that's tough to do
Thomas Nguyen: I think direct compiled approach is a stragegy that no one does. Theoretical limit. Compared to other frameworks this did better. Some signal that there's some promise here.
… even compared to direct compile its like the same line. It sometimes did better.
masonf: the best best numbers were where nodes weren't even tracked?
<masonf> acl mason
<Zakim> masonf, you wanted to react to sorvell
Thomas Nguyen: The general one seemed fine
justinf: its not just perf, but if perf is at parity that's awesome.
lea: I wanted to talk about a different point - the syntax. It's the double curlies. But without a way to override that - how do you combine that with tools like eleventy
lea: how do you generate templates with something like that? Turn off the pipeline?
<justinf> q+
keithamus: you can configure this in lots of tools like 11ty, mustache
lea: so why not both? Why not configure this in the browser?
<lea> expressions="{{ }}"
like this^
<lea> expressions="{ }"
<keithamus> s/like this^ /lea: like this^
<lea> expressions="[ ]"
lea: or something like this ^
<westbrook> <meta name="dompartdelineator" value="!magic! !/magic!" />
lea: you could put it on ancestors, subtrees; double curlies by default.
… would it make it harder to implement?
<Zakim> masonf, you wanted to react to lea
masonf: nothing fundementally. This already requires an attribute so we could extend that but there are strange things, e.g. angle brackets could be bad.
<Zakim> keithamus, you wanted to react to lea
sanketj: dynamic scenarios; attach parts and the thing follows you around. Are there use cases to set a part and move it elsewhere? Is there something interesting with SSR?
masonf: I didn't get much feedback when we removed this feature - so I think its peripheral
justinf: ???
sanketj: is it useful to do that? The context might be different
masonf: if you change orders... ???
justinf: once you've got the list of parts you just use that list. I've never seen that.
sanketj: in EdgeHTML we had this thing; cling, it would follow you around - we looked at removing it
masonf: all of our benchmarks were write-once read-once
rniwa: one interesting thing to explore is whether full template instantation would have any perf improvement over existing solutions
… another point is reducing JS that every website ships is generally a good idea. Removing a bunch of script for lib+frameworks is probably a win
… I think going back to the delimiters being configurable - it would complicate the implementation and I worry if it would be as performant as the non-configurable one
masonf: having an impl I don't disagree but I bet it comes pretty close.
justinf: Can I talk about JS template API?
westbrook: Glad perf is on par. Dom parts that leads onto templating unlocks - when people ask for custom elements, shadowdom, open styleable. What they want is templating. They sometimes don't even want slots. Just templating.
… as this gets all the way through to template instantiation are we getting enough of a non negative to drive this?
… this would relieve other areas.
eemeli: much same qs as westbrook - whats the positive driving force behind dom parts. If not perf, ergonomics? What is the reason we _should_ vs should not.
… all the things that can be done with DOM parts can be done now, but with some JS
… so why do we need this new way of doing this thing? What it selling this?
sorvell: I agree with westbrook on templating. We need a light dom slot solution and no one agreed. Templating might be it
justinf: DOM parts is the low level api... but *presents slides*
<iteriani> we need a solution that framework owners can incrementally adopt
<justinf> https://
<iteriani> and then build up so that frameworks can share rendering solutions instead of fighting over js-framework-benchmark until 2050
<sorvell> there's also a nuanced performance argument related to bytes over the wire: dom parts: "template + render data + other" v. today: "all rendered html + render data (used in hydration) + other"... where dom parts is less bytes.. maybe?
sorvell: I want to make sure people understand the motiviation for a JS api for generating html; why wouldn't you just in JS create the HTML to produce the right stamped output
justinf: convenience over DOM parts API - delims have real expressions in them, so similar to eg JSX. But the DOM parts have no expressions. You're delocating expressions from where they belong. Then you have to get the parts and fill them
sorvell: isn't it also the case that the expressions in DOM parts are empty? This is the crux of the issue - once you put some identifier in HTML that's an expression all of a sudden you've got a DSL. You sidestep the whole issue by using JavaScript.
<obuckley> like a list of "card" components on a products page
<obuckley> and provides a nice SSR API
eemeli: I really like the html tagged template literal idea. I presume though that the tagged template is that it would return HTML
eemeli: it can hide all of the magic but give me a documentfragment
… it doesnt support DOM parts but I would argue it gives better utility
justinf: you need to have an intermediate representation so you can render multiple times
justinf: you cant render in two places
rniwa: we're over time
justinf: i had a slide on JSX and whatabouts. If JS ever added JSX you could produce the same template result
… or functions that produce templateresults