June 2013 edition of Standards for Web Applications on Mobile: current state and roadmap
Hi all, I've just released another quarterly update to my overview of the most mobile-relevant Web application technologies: http://www.w3.org/2013/06/mobile-web-app-state/ In addition to integrating (hopefully) all the relevant changes to the platform in the past 4 months, it also highlights test suites that can be forked from github, and has a printer-friendly PDF version (generated from the HTML document via princexml). As always feedback, and even better, contributions to the wiki version at http://www.w3.org/wiki/Standards_for_Web_Applications_on_Mobile, are much welcome. Cheers, Dom
::part Additions
Hi, since new paradigm conserning Custom Pseudo Elements have been introduced http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0985.html (part 5) I'd like to suggest few additions/changes: 1/ ability to style nested shadow dom elements 2/ change of part attribute from DOMString to DOMTokenList 3/ ability to create complex selectors using ::part the description/reasoning for this can be found here: http://projects.webnt.eu/spec/shadow/index.php In case ::part will not be in spec, the same still applies to pseudos Bronislav Klucka
Re: ITS 2.0, Selectors 4 and Selectors API 2
On Tue, Jul 2, 2013 at 12:57 AM, Daniel Glazman daniel.glaz...@disruptive-innovations.com wrote: On 02/07/13 09:16, Tab Atkins Jr. wrote: Pseudo-elements do exist in the document tree as far as layout is concerned. No, they do not. They don't create new nodes (yet), even shadow nodes, they can't be serialized. They belong to the layout tree, NOT the document tree. As I said in the section you quoted, *as far as layout is concerned*, pseudo-elements exist. I didn't say anything about creating DOM, affecting stringification, etc. ~TJ
Re: ::part Additions
On Tue, Jul 2, 2013 at 6:32 AM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: Hi, since new paradigm conserning Custom Pseudo Elements have been introduced http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0985.html (part 5) I'd like to suggest few additions/changes: 1/ ability to style nested shadow dom elements We discussed this in a previous meeting (surfacing nested component parts, either automatically or via a switch) but I don't recall what the conclusion was. Dimitri? 2/ change of part attribute from DOMString to DOMTokenList This sounds all right. part='' is already class-like, since multiple elements can have the same part='' value. The example at your page is pretty compelling about this ability's usage. I guess ::part() would also expand to taking a list of idents. 3/ ability to create complex selectors using ::part Interesting! I guess it would just surface a synthesized tree based on only the elements that contain part=''? That is, two elements would have a parent-child relationship (and thus be selectable with the combinator) if they were the closest elements with part='', even if there were other elements between them? Like: div part='parent' div div part='child'/div /div /div ~TJ
Re: ::part Additions
On Tue, Jul 2, 2013 at 8:28 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: We discussed this in a previous meeting (surfacing nested component parts, either automatically or via a switch) but I don't recall what the conclusion was. Dimitri? The issue is tracked by https://www.w3.org/Bugs/Public/show_bug.cgi?id=22462, but I haven't had a chance to look at this in depth yet. :DG
Re: ::part Additions
On 2.7.2013 17:28, Tab Atkins Jr. wrote: On Tue, Jul 2, 2013 at 6:32 AM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: Hi, since new paradigm conserning Custom Pseudo Elements have been introduced http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0985.html (part 5) I'd like to suggest few additions/changes: 1/ ability to style nested shadow dom elements We discussed this in a previous meeting (surfacing nested component parts, either automatically or via a switch) but I don't recall what the conclusion was. Dimitri? As Dimitri mentioned, there is a bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=22462 I'm mentioning it in my document, I'm fine with this solution, the question there is with default value. 2/ change of part attribute from DOMString to DOMTokenList This sounds all right. part='' is already class-like, since multiple elements can have the same part='' value. The example at your page is pretty compelling about this ability's usage. I guess ::part() would also expand to taking a list of idents. Why would it? We have established convention for AND operator .class1.class2 would became ::part(node-checked)::part(node-selected) and for OR operator .class1, .class2 would became ::part(node-checked), ::part(node-selected) :matches(.class1, .class2) would became :matches(::part(node-checked), ::part(node-selected)) 3/ ability to create complex selectors using ::part Interesting! I guess it would just surface a synthesized tree based on only the elements that contain part=''? That is, two elements would have a parent-child relationship (and thus be selectable with the combinator) if they were the closest elements with part='', even if there were other elements between them? Like: div part='parent' div div part='child'/div /div /div ~TJ Interesting point, maybe little bit counter intuitive for some people, but since it's shadow and we are essentially targeting the only visible parts within the DOM it makes sense Brona
Re: ::part Additions
On Tue, Jul 2, 2013 at 8:52 AM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: On 2.7.2013 17:28, Tab Atkins Jr. wrote: On Tue, Jul 2, 2013 at 6:32 AM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: 2/ change of part attribute from DOMString to DOMTokenList This sounds all right. part='' is already class-like, since multiple elements can have the same part='' value. The example at your page is pretty compelling about this ability's usage. I guess ::part() would also expand to taking a list of idents. Why would it? We have established convention for AND operator .class1.class2 would became ::part(node-checked)::part(node-selected) and for OR operator .class1, .class2 would became ::part(node-checked), ::part(node-selected) :matches(.class1, .class2) would became :matches(::part(node-checked), ::part(node-selected)) Oh, no no no. ::part() is not a pseudo-class, it's a pseudo-element - it points to a brand new element, rather than filtering the one you've got. The fact that part='' is acting like class='' notwithstanding, using ::part() like would be an abuse of the syntax. If we want to support this, it has to be through something like ::part(node-checked node-selected). As an example of why violating the syntax model is a bad idea, this directly conflicts with your desire to surface the ::part()s of nested components - the thing that exposes them might be exposed as a ::part() as well, so you need to be able to chain off of an existing ::part(), like x-video::part(controls)::part(play-button) (assuming the controls were actually implemented by another component nested inside the x-video shadow tree). ~TJ
Re: ::part Additions
On 2.7.2013 18:03, Tab Atkins Jr. wrote:
On Tue, Jul 2, 2013 at 8:52 AM, Bronislav Klučka
bronislav.klu...@bauglir.com wrote:
On 2.7.2013 17:28, Tab Atkins Jr. wrote:
On Tue, Jul 2, 2013 at 6:32 AM, Bronislav Klučka
bronislav.klu...@bauglir.com wrote:
2/ change of part attribute from DOMString to DOMTokenList
This sounds all right. part='' is already class-like, since multiple
elements can have the same part='' value. The example at your page is
pretty compelling about this ability's usage. I guess ::part() would
also expand to taking a list of idents.
Why would it? We have established convention for AND operator
.class1.class2
would became
::part(node-checked)::part(node-selected)
and for OR operator
.class1, .class2
would became
::part(node-checked), ::part(node-selected)
:matches(.class1, .class2)
would became
:matches(::part(node-checked), ::part(node-selected))
Oh, no no no. ::part() is not a pseudo-class, it's a pseudo-element -
it points to a brand new element, rather than filtering the one you've
got. The fact that part='' is acting like class='' notwithstanding,
using ::part() like would be an abuse of the syntax. If we want to
support this, it has to be through something like ::part(node-checked
node-selected).
As an example of why violating the syntax model is a bad idea, this
directly conflicts with your desire to surface the ::part()s of nested
components - the thing that exposes them might be exposed as a
::part() as well, so you need to be able to chain off of an existing
::part(), like x-video::part(controls)::part(play-button) (assuming
the controls were actually implemented by another component nested
inside the x-video shadow tree).
~TJ
so
x-video::part(controls)::part(play-button)
would target part=play-button within part=controls within x-video?
and the list of idents
::part(part1 part2) {without comma? with comma?}
would target part=part1 part2? an AND operator?
the OR I've mentioned being correct?
so how about this:
::part(node-checked)::part(node-selected)
would represent any selected node within checked node (regardless of level of
nesting)
::part(node-checked) ::part(node-selected)
would represent selected node within checked node (directly within, no other
part in between)
?
Brona
Re: ::part Additions
On 2.7.2013 18:03, Tab Atkins Jr. wrote: On Tue, Jul 2, 2013 at 8:52 AM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: On 2.7.2013 17:28, Tab Atkins Jr. wrote: On Tue, Jul 2, 2013 at 6:32 AM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: 2/ change of part attribute from DOMString to DOMTokenList This sounds all right. part='' is already class-like, since multiple elements can have the same part='' value. The example at your page is pretty compelling about this ability's usage. I guess ::part() would also expand to taking a list of idents. Why would it? We have established convention for AND operator .class1.class2 would became ::part(node-checked)::part(node-selected) and for OR operator .class1, .class2 would became ::part(node-checked), ::part(node-selected) :matches(.class1, .class2) would became :matches(::part(node-checked), ::part(node-selected)) Oh, no no no. ::part() is not a pseudo-class, it's a pseudo-element - it points to a brand new element, rather than filtering the one you've got. The fact that part='' is acting like class='' notwithstanding, using ::part() like would be an abuse of the syntax. If we want to support this, it has to be through something like ::part(node-checked node-selected). As an example of why violating the syntax model is a bad idea, this directly conflicts with your desire to surface the ::part()s of nested components - the thing that exposes them might be exposed as a ::part() as well, so you need to be able to chain off of an existing ::part(), like x-video::part(controls)::part(play-button) (assuming the controls were actually implemented by another component nested inside the x-video shadow tree). ~TJ And back to x-video::part(controls)::part(play-button) example how it would be different from x-video ::part(controls) ::part(play-button) or this wouldn't be possible? the only possibilities being ::part(play-button) or ::part(controls)::part(play-button) or x-video::part(controls)::part(play-button) Brona
Re: ::part Additions
On 2.7.2013 18:21, Bronislav Klučka wrote:
On 2.7.2013 18:03, Tab Atkins Jr. wrote:
On Tue, Jul 2, 2013 at 8:52 AM, Bronislav Klučka
bronislav.klu...@bauglir.com wrote:
On 2.7.2013 17:28, Tab Atkins Jr. wrote:
On Tue, Jul 2, 2013 at 6:32 AM, Bronislav Klučka
bronislav.klu...@bauglir.com wrote:
2/ change of part attribute from DOMString to DOMTokenList
This sounds all right. part='' is already class-like, since multiple
elements can have the same part='' value. The example at your page is
pretty compelling about this ability's usage. I guess ::part() would
also expand to taking a list of idents.
Why would it? We have established convention for AND operator
.class1.class2
would became
::part(node-checked)::part(node-selected)
and for OR operator
.class1, .class2
would became
::part(node-checked), ::part(node-selected)
:matches(.class1, .class2)
would became
:matches(::part(node-checked), ::part(node-selected))
Oh, no no no. ::part() is not a pseudo-class, it's a pseudo-element -
it points to a brand new element, rather than filtering the one you've
got. The fact that part='' is acting like class='' notwithstanding,
using ::part() like would be an abuse of the syntax. If we want to
support this, it has to be through something like ::part(node-checked
node-selected).
As an example of why violating the syntax model is a bad idea, this
directly conflicts with your desire to surface the ::part()s of nested
components - the thing that exposes them might be exposed as a
::part() as well, so you need to be able to chain off of an existing
::part(), like x-video::part(controls)::part(play-button) (assuming
the controls were actually implemented by another component nested
inside the x-video shadow tree).
~TJ
And back to
x-video::part(controls)::part(play-button)
example
how it would be different from
x-video ::part(controls) ::part(play-button)
or this wouldn't be possible? the only possibilities being
::part(play-button)
or
::part(controls)::part(play-button)
or
x-video::part(controls)::part(play-button)
Brona
I do not want to spam this topic so just last thought on pseudo-elements
and custom pseudo elements (parts), it's more generic issue (CSS
selector syntax)
the no-space syntax can work when there is only one pseudo-element and
usually the last one
p::first-letter - makes sense
thou as an element:: it would be better to for something like
p ::first-letter or p ::first-letter not to target first letters in
SPANs in P..
because its element within other element... not a filter
but when we start to nest and go more complex it becomes really strange
consider chessboard
--
with regular HTML+CSS one would go for something like
table td { background: silver; }
table tr:nth-of-child(2n + 1) td:nth-of-child(2n),
table tr:nth-of-child(2n) td:nth-of-child(2n + 1) { background: black; }
--
my way (wrong way)
chessboard ::part(cell) { background: silver; }
chessboard ::part(row):nth-of-child(2n + 1) ::part(cell):nth-of-child(2n),
chessboard ::part(row):nth-of-child(2n) ::part(cell):nth-of-child(2n +
1) { background: black; }
nesting working as usual (no change there), replacing TR and TD with
custom counterparts - intuitive, easy
--
correct way
chessboard::part(cell) { background: silver; }
chessboard::part(row):nth-of-child(2n + 1)::part(cell):nth-of-child(2n),
chessboard::part(row):nth-of-child(2n)::part(cell):nth-of-child(2n + 1)
{ background: black; }
mixing of pseudo classes and pseudo elements into one strange selector
one have to carefully read to separate parts, what is pseudo element,
what is pseudo class.
--
the fact is, that no space creates filtering and space created nesting
is throughout the CSS, regardless of selector (tag, class, id,
attrribute), with this only exception. pseudo element is not actually
filter on set of parents, but nested parts of all parents
p ::part(this1) + ::part(this2) makes sense and only one sense
p::part(this1) + p::part(this2) is confusing
as I wrote above, nesting several pseudo elements, allowing complex
selectors makes this a lot more confusing.
Brona
Re: ::part Additions
On Tue, Jul 2, 2013 at 9:16 AM, Bronislav Klučka
bronislav.klu...@bauglir.com wrote:
On 2.7.2013 18:03, Tab Atkins Jr. wrote:
On Tue, Jul 2, 2013 at 8:52 AM, Bronislav Klučka
bronislav.klu...@bauglir.com wrote:
On 2.7.2013 17:28, Tab Atkins Jr. wrote:
On Tue, Jul 2, 2013 at 6:32 AM, Bronislav Klučka
bronislav.klu...@bauglir.com wrote:
2/ change of part attribute from DOMString to DOMTokenList
This sounds all right. part='' is already class-like, since multiple
elements can have the same part='' value. The example at your page is
pretty compelling about this ability's usage. I guess ::part() would
also expand to taking a list of idents.
Why would it? We have established convention for AND operator
.class1.class2
would became
::part(node-checked)::part(node-selected)
and for OR operator
.class1, .class2
would became
::part(node-checked), ::part(node-selected)
:matches(.class1, .class2)
would became
:matches(::part(node-checked), ::part(node-selected))
Oh, no no no. ::part() is not a pseudo-class, it's a pseudo-element -
it points to a brand new element, rather than filtering the one you've
got. The fact that part='' is acting like class='' notwithstanding,
using ::part() like would be an abuse of the syntax. If we want to
support this, it has to be through something like ::part(node-checked
node-selected).
As an example of why violating the syntax model is a bad idea, this
directly conflicts with your desire to surface the ::part()s of nested
components - the thing that exposes them might be exposed as a
::part() as well, so you need to be able to chain off of an existing
::part(), like x-video::part(controls)::part(play-button) (assuming
the controls were actually implemented by another component nested
inside the x-video shadow tree).
so
x-video::part(controls)::part(play-button)
would target part=play-button within part=controls within x-video?
Not quite what I intended. I was thinking that ::part(controls) would
be an x-controls element or something, and ::part(play-button) would
be in the x-controls shadow tree.
and the list of idents
::part(part1 part2) {without comma? with comma?}
would target part=part1 part2? an AND operator?
the OR I've mentioned being correct?
Yes to all.
so how about this:
::part(node-checked)::part(node-selected)
would represent any selected node within checked node (regardless of level
of nesting)
::part(node-checked) ::part(node-selected)
would represent selected node within checked node (directly within, no other
part in between)
No, this is definitely inconsistent. The first one would have to be
::part(node-checked) ::part(node-selected) (with a space between
them).
An alternative is to go the ::content route, and kill the parentheses.
As soon as you type ::part, you're in the surface shadow tree of
the component (which respects the shape of the real shadow tree, but
may skip nodes), and can then use the standard selectors/combinators
to get through it.
You'd need some additional work to make multiple part values work,
perhaps just treating part='' literally as a class, like:
x-video::part .play-button
Selecting multiple would be:
x-tree::part .node-checked.node-selected
(though I'd change the part='' stuff around so I could just write
.node.checked.selected)
Selecting children would be:
x-tree::part .node-checked .node-selected
Descending into nested shadow trees would just involve adding more
::part pseudos to the correct places.
~TJ
[Bug 22540] Fire event when database connection is closed without explicit close() call
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22540 Joshua Bell jsb...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |LATER -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 22540] New: Fire event when database connection is closed without explicit close() call
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22540 Bug ID: 22540 Summary: Fire event when database connection is closed without explicit close() call Classification: Unclassified Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API Assignee: dave.n...@w3.org Reporter: jsb...@google.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org NOTE: the following is a proposal for a future version of IndexedDB Just as an event is fired at a transaction when the transaction implicitly aborts (but not when abort() is called), there are cases where a database connection may close even without close() being called, and script should be notified with an event. Scenarios: * the user invokes the browser's clear my stored data option which deletes the backing store * backing store is on a removable storage medium; the browser detects when the medium is removed and further read/write attempts to the database will fail (while file handles will be lost, arguably the implementation could do some magic in this scenario to reestablish the connection behind the scenes, simply failing any attempted transactions with UnknownError in the mean time) Proposal: If the connection to the database is closed other than by a call to close(): 1. set the /closePending/ flag of /transaction/ 2. for each transaction created using /connection/ that is not complete, run the steps for aborting the transaction with /transaction/ and AbortError 3. fire a connectionclosed event at /connection/; the event does not bubble and is not cancelable -- You are receiving this mail because: You are on the CC list for the bug.
Re: ::part Additions
there are still too many strange things going on :]
see below
On 2.7.2013 22:19, Tab Atkins Jr. wrote:
On Tue, Jul 2, 2013 at 9:16 AM, Bronislav Klučka
bronislav.klu...@bauglir.com wrote:
On 2.7.2013 18:03, Tab Atkins Jr. wrote:
On Tue, Jul 2, 2013 at 8:52 AM, Bronislav Klučka
bronislav.klu...@bauglir.com wrote:
On 2.7.2013 17:28, Tab Atkins Jr. wrote:
On Tue, Jul 2, 2013 at 6:32 AM, Bronislav Klučka
bronislav.klu...@bauglir.com wrote:
2/ change of part attribute from DOMString to DOMTokenList
This sounds all right. part='' is already class-like, since multiple
elements can have the same part='' value. The example at your page is
pretty compelling about this ability's usage. I guess ::part() would
also expand to taking a list of idents.
Why would it? We have established convention for AND operator
.class1.class2
would became
::part(node-checked)::part(node-selected)
and for OR operator
.class1, .class2
would became
::part(node-checked), ::part(node-selected)
:matches(.class1, .class2)
would became
:matches(::part(node-checked), ::part(node-selected))
Oh, no no no. ::part() is not a pseudo-class, it's a pseudo-element -
it points to a brand new element, rather than filtering the one you've
got. The fact that part='' is acting like class='' notwithstanding,
using ::part() like would be an abuse of the syntax. If we want to
support this, it has to be through something like ::part(node-checked
node-selected).
As an example of why violating the syntax model is a bad idea, this
directly conflicts with your desire to surface the ::part()s of nested
components - the thing that exposes them might be exposed as a
::part() as well, so you need to be able to chain off of an existing
::part(), like x-video::part(controls)::part(play-button) (assuming
the controls were actually implemented by another component nested
inside the x-video shadow tree).
so
x-video::part(controls)::part(play-button)
would target part=play-button within part=controls within x-video?
Not quite what I intended. I was thinking that ::part(controls) would
be an x-controls element or something, and ::part(play-button) would
be in the x-controls shadow tree.
so it would select something like
x-video
#SHADOW ROOT
x-controls
#SHADOW ROOT
div part=play-button/div
x-controls
/x-video
how is it, that one time the ::part targets element and other time
attribute? or is it
x-video
#SHADOW ROOT
x-controls
#SHADOW ROOT
x-play-button/x-play-button
x-controls
/x-video
?
in both cases, how can you target element inside shadow tree? or do you
essentially mean
x-video
#SHADOW ROOT
x-controls part=controls
#SHADOW ROOT
x-play-button part=play-button/x-play-button
x-controls
/x-video
so the no space syntax means crossing shadow boudaries and space syntax
means no crossing
so
x-video::part(controls) ::part(play-button) //with space
would mean
x-video
#SHADOW ROOT
x-controls part=controls
x-play-button part=play-button/x-play-button
x-controls
/x-video
I have a problem with that, described below
and the list of idents
::part(part1 part2) {without comma? with comma?}
would target part=part1 part2? an AND operator?
the OR I've mentioned being correct?
Yes to all.
so how about this:
::part(node-checked)::part(node-selected)
would represent any selected node within checked node (regardless of level
of nesting)
::part(node-checked) ::part(node-selected)
would represent selected node within checked node (directly within, no other
part in between)
No, this is definitely inconsistent. The first one would have to be
::part(node-checked) ::part(node-selected) (with a space between
them).
An alternative is to go the ::content route, and kill the parentheses.
As soon as you type ::part, you're in the surface shadow tree of
the component (which respects the shape of the real shadow tree, but
may skip nodes), and can then use the standard selectors/combinators
to get through it.
You'd need some additional work to make multiple part values work,
perhaps just treating part='' literally as a class, like:
x-video::part .play-button
Selecting multiple would be:
x-tree::part .node-checked.node-selected
(though I'd change the part='' stuff around so I could just write
.node.checked.selected)
Selecting children would be:
x-tree::part .node-checked .node-selected
Descending into nested shadow trees would just involve adding more
::part pseudos to the correct places.
And that is exactly the problem, TreeView, popup menu, pretty much every
controls containers (thing about placing tabs into one tab of another
tabs, that is placed into on tab of the third tabs)
The shadow nesting could go on and on, there is no way you can style
that without knowing the exact structure
if I would want all LI to have disc, all I can do is type
li { list-style-type: disc; }
and it's always, everywhere
Re: ::part Additions
On Tue, Jul 2, 2013 at 5:00 PM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: On 2.7.2013 22:19, Tab Atkins Jr. wrote: On Tue, Jul 2, 2013 at 9:16 AM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: so x-video::part(controls)::part(play-button) would target part=play-button within part=controls within x-video? Not quite what I intended. I was thinking that ::part(controls) would be an x-controls element or something, and ::part(play-button) would be in the x-controls shadow tree. so it would select something like x-video #SHADOW ROOT x-controls #SHADOW ROOT div part=play-button/div x-controls /x-video how is it, that one time the ::part targets element and other time attribute? or is it x-video #SHADOW ROOT x-controls #SHADOW ROOT x-play-button/x-play-button x-controls /x-video Sorry, this whole time I've been meaning: x-video #SHADOW ROOT x-controls part=controls #SHADOW ROOT div part=play-button/div /x-controls /x-video x-video::part(controls) ::part(play-button) //with space would mean x-video #SHADOW ROOT x-controls part=controls x-play-button part=play-button/x-play-button x-controls /x-video Yes. Descending into nested shadow trees would just involve adding more ::part pseudos to the correct places. And that is exactly the problem, TreeView, popup menu, pretty much every controls containers (thing about placing tabs into one tab of another tabs, that is placed into on tab of the third tabs) The shadow nesting could go on and on, there is no way you can style that without knowing the exact structure Right, but the problem you have then is exposing the structure. If you want to be able to style parts based on their position in the tree, you need to start with a consistent tree. Once you mix in shadow, you end up with elements having two sets of children, and you need to be able to distinguish between them. If you can give up the ability to style based on tree structure, and accept only styling based on part='' value, then we can just blindly expose nested things on the uppermost component, so you don't have to know whether they belong to the component itself or something deeper. ~TJ
