- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 23 Nov 2015 20:16:30 -0500
- To: www-style@w3.org
- Cc: public-webapps@w3.org
Joint Meeting With WebApps
--------------------------
- There was conversation to further understand the use of and use
cases for :host and :host-context in ShadowDOM
- There was a struggle to find a use case for :host.
- In regards to :host-context it was felt the same effect was
easier to achieve using CSS Variables.
- :host-context will be deferred from L1 for now
- The joint groups also discussed the correct order for the nested
levels in Shadow DOM.
- There were two existing proposals on the table (see bottom
of https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Shadow-DOM-Cascade-Order-in-v1.md)
and TabAtkins brought another one
(https://github.com/w3c/webcomponents/issues/316#issuecomment-149735841).
- The group understands the issue a lot better, but it was
requested that the first two proposals be written up in a
way similar to the proposal from TabAtkins and, once that
is done, all three proposals are summarized for the
mailing list with their differences made explicit.
===== FULL MINUTES BELOW =======
Scribe: timeless
Joint Meeting With WebApps
==========================
Shadow DOM
----------
<rniwa> https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Shadow-DOM-Cascade-Order-in-v1.md
rniwa: A couple of questions we need to resolve for Shadow DOM
before we can implement the feature.
rniwa: We have a list, we can go through it.
rniwa: I'll go through each issue first.
rniwa: First: combinators, and changes to them:
rniwa: We don't want deep or shallow combinators
rniwa: Rename ::content to ::slotted
rniwa: Still have :host and :host-context
Travis: I don't object.
rniwa: I think we don't want :host-context
Travis: :host is a shadow/guide.
mjs: Could we have explanations of :host and :host-context?
TabAtkins: I brought up an edit pad.
<TabAtkins> https://public.etherpad-mozilla.org/p/webapps
TabAtkins: I'll draw up an example real quick.
[ tab draws ]
[ adrianba increases the font size ]
Tab draws:
<my-component>
<::shadow>
<style>
my-component { color: blue; }
:host { color: red; }
</style>
</::shadow>
<div>foo</div>
</my-component>
TabAtkins: If you're inside the shadow
TabAtkins: as this style is, and you try to have a my-component
selector
TabAtkins: this component, this div, this style.
TabAtkins: if you take my-component, it won't set on this (the
my-component)
TabAtkins: From inside the shadow root, styles can only see other
things inside the shadow root.
TabAtkins: The other stuff outside is in control of the user, not
the shadow author.
TabAtkins: You do still sometimes want to be able to style your
host element,
TabAtkins: to say make it a flex-box.
TabAtkins: That's what :host is for.
TabAtkins: :host-context is a little different
TabAtkins: Say you want to style things based on whether your
anchor is class="light-theme".
TabAtkins: You can't do `.light-theme div {...}`.
TabAtkins: You could do `:host(.light-theme) div {...}` this would
only match the host if it matches.
TabAtkins: It's a function() because...
TabAtkins: :host.light-theme doesn't work, because .light-theme
doesn't work.
TabAtkins: Removing a simple selector from a compound selector
will never select "less",
TabAtkins: by CSS Selectors definition.
TabAtkins: Things with more selections must select not more than
the other, it's more specific.
TabAtkins: it can't be a wider match
TabAtkins: .light-theme div #2 -- doesn't match anything
TabAtkins: then :host.light-theme div #1 -- can't match more than
#2
TabAtkins: it's more specific, it can't match less.
TabAtkins: You can't select less than 0.
TabAtkins: So we have to use a function argument --
:host(.light-theme) div...
dino: what does :host { color: red } do ?
TabAtkins: It selects the host object (<my-component>) and sets
the color property to red.
TabAtkins: A more reasonable example is :host { display: flex },
TabAtkins: because you need to use flex-box layout.
TabAtkins: Does that sufficiently clarify functional host?
mjs: Additional question, when you use the descendant selector,
what does it select?
TabAtkins: [?]
mjs: :host selects the host element, but if you select a
descendant, it only selects things in the shadow
TabAtkins: Yes, for the purpose of selectors, :host selects two
things, the host, and the shadow DOM, descendants
select inside only.
leaverou: Why not a pseudo element?
leaverou: There's a flaw that :host is a [?] and not a pseudo.
TabAtkins: The reason it wasn't a pseudo is that it does exist.
ChrisLilley: The projection exists, but the object doesn't exist.
TabAtkins: But I'm styling the real element.
leaverou: If you can't select it with * then...
TabAtkins: No...
mjs: * would select everything except it.
TabAtkins: * is not everything, it's all tag names in this tree.
leaverou: Any other examples?
TabAtkins: No, this is the first one,
SimonSapin: do you agree *:host is equivalent to :host ?
TabAtkins: It is not.
TabAtkins: If you wrote * { color: grey}
TabAtkins: it selects every element in the shadow tree.
SimonSapin: Same as...
TabAtkins: *:host is bad, it won't select anything.
SimonSapin: Defining this way is inconsistent, as with 1/2
TabAtkins: 1/2 both match nothing.
mjs: A point w/ *, every other pseudo class, *:whatever is exactly
equivalent to :whatever,
mjs: but for pseudo elements, that isn't the case.
<hayato> We had a similar discussion:
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0295.html
mjs: Although :host sort of refers to a real element, it sort of
doesn't.
mjs: Descendant refers to something after refers to something it
wouldn't normally would.
mjs: The fact that it's weird kind of makes it a pseudo element.
TabAtkins: It wouldn't be inconsistent, but i felt it leaned
heavier to this style.
hober: All selectors for forever have been scoped to a tree, we
didn't know that because there was only one tree.
hober: Now we have more than one tree.
hober: :host projects from one tree to another.
hober: It's true it's inconsistent, but we're doing something
we haven't done before.
hober: But this entire argument is `:` or `::` and I don't care.
TabAtkins: If you are ok with a full selector after a pseudo
element?
TabAtkins: Then I'm ok.
dbaron: I just want...
dbaron: We use pseudos for things where we don't want to fully
explain the dragons.
dbaron: To mjs, you stick a * in front of it, and that doesn't
change anything.
dbaron: That's true for pseudo classes and not for pseudo elements,
dbaron: but it's true for both.
dbaron: Before this proposal, it was true for both.
TabAtkins: Pseudo elements are always "of" another element.
TabAtkins: but what element is this a pseudo of?
mjs: What is ::selection a pseudo of?
TabAtkins: That's an open question, but there are valid answers
for it.
[ laughter ]
dbaron: There's no spec for ::selection saying how it works.
fantasai: That's somewhat wrong, I haven't published it.
fantasai: We do have a spec for that now.
<kochi> https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/css/parser/CSSSelectorParser.cpp&q=%5C*:host&sq=package:chromium&type=cs&l=571
TabAtkins: What element does *::host(*) match?
TabAtkins: Just serves as the host host, but we've reinvented the
host.
fantasai: A pseudo element is an element with its own set of
computed styles,
fantasai: but here you're trying to cascade all of the stle rules
from outside and inside together onto the same element.
fantasai: It's taking both scopes as an input and cascading
together.
fantasai: An element gets styles, and its pseudo gets its own
styles, they're independent entities w/ independent
styles.
TabAtkins: Correct, your styles get merged (outside +
outside-inside)
TabAtkins: I think I need to put an explainer into the spec.
TabAtkins: We're sticking w/ single colon.
<zcorpan> how about dropping the colon(s)?
hober: TabAtkins, I think you've answered this question multiple
times in the past
hober: Why not `:::` ?
hober: "This is a weird thing", it should look different.
hober: I swear I'm not trolling.
TabAtkins: I considered it, but the single-double is the single
worst thing of CSS.
hober: We could do ::: so that people don't come w/ a preconceived
notion.
Simon: drop a `:` and just have a function.
TabAtkins: We could have a function, it isn't defined as allowed
for simple selectors yet.
TabAtkins: Maybe it would be clearer?
fantasai: It would look more like a tag name.
zcorpan: It would be better because you can't put a star in front
of it.
TabAtkins: That's good.
mjs: Now that we've colored the bike shed, can we go back to
semantics?
[ laughter ]
Travis: :host-context
TabAtkins: selector to host(...)
TabAtkins: but we figured there were use cases for contexts higher
up,
TabAtkins: e.g. body.light-theme.
TabAtkins: host-context() let's you try to select against the host
element or any of its ancestors.
rniwa: afaiu, that would be defined in CSS Variables
rniwa: Why do we need a separate very similar to address the same
use case?
TabAtkins: Using Variables is the right solution if you want to do
your own theme.
TabAtkins: An element that's openly theme-able, but if you want a
predetermined thing.
TabAtkins: This lets you...
rniwa: That seems wrong.
rniwa: We don't have any other elements like that.
TabAtkins: We absolutely do.
TabAtkins: Just like :host(.foo) > div is roughly equivalent to
:host.foo > div
TabAtkins: :host-context(.foo) > div is roughly eq to .foo div
rniwa: No host element styling different based on ancestor.
TabAtkins: :host-context lets you put anywhere in a tree.
hober: I disagree with that.
hober: For the .list-theme case,
hober: a typical page, we use class div.
hober: You stick in header v. main content (light/dark)
hober: You could see a push/pull question.
hober: Is component pulling in
hober: or is the page pushing in?
hober: I think that's the typical case (one of them -- unclear
which).
hober: :host-context is a pull model, currently things don't do
that.
hober: Does that make sense?
TabAtkins: Not a lot, but ok.
TabAtkins: It's about predefined styles from the component, vs.
the page poking in its own styles.
hober: I think you can do your own stuff without this.
TabAtkins: Only if you use :host with ...
hober: I don't think so.
mjs: :host-context, you could imagine a use case for it, but it
seems like a box-checking exercise...
mjs: It's true that built in classes.
TabAtkins: Do things disable themselves based on fieldset?
[ yeah ]
mjs: fieldset isn't a good case.
dbaron: <ul type=...>
rniwa: Disabled you can't rely on ancestor.
rniwa: Element disabled by label.
TabAtkins: Correct, it's more complicated than that.
TabAtkins: It's not nothing, forms can get more complicated.
hober: <ul type="a"> could be done w/ :host.
TabAtkins: Not if the <li>s are the shadows.
dbaron: <table rule> changes things on borders of <td>s.
<dbaron> also the list style rotation for nested ul
TabAtkins: The idea that there's no example is laughable.
[ agreed ]
mjs: It still seems too obscure.
mjs: I still think we could start w/ :host and see if real use
cases in the field demonstrate a need.
mjs: So much of this isn't read.
TabAtkins: I'm down w/ that.
hober: Let's get yelled at.
???: theming isn't a good use case?
mjs: I think adding it there isn't a good use case.
mjs: And I think theming is dumb anyway.
mjs: And CSS Variables seem like a better way.
dbaron: This is widely used as a developer practice.
jyasskin: Polymer is using something like CSS Variables.
TabAtkins: Our usage is below our kill threshold, so...
TabAtkins: I recognize :host-context is a lower value, I don't
think it's necessary for v1.
TabAtkins: I'm ok w/ deferring to later.
Cascading Models
----------------
<kochi> https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Shadow-DOM-Cascade-Order-in-v1.md
hayato: This is a summary of proposals of how cascading model
should work
hayato: See the end of the document.
hayato: There's proposal 1, and 2.
hayato: An element in shadow tree,
hayato: we have 5 nodes,
hayato: we have tree of trees,
hayato: dom tree w/ nodes,
hayato: tree of tree.
hayato: A is a tree, B is child of A.
hayato: Element in document tree host, shadow host is B,
hayato: C is child tree of B.
hayato: Shadow host in B, hosts shadow tree C.
hayato: In shadow ... we have a special selector,
hayato: like :host, or ::slotted.
hayato: We have a proposal for some pseudo elements:
hayato: Suppose an element in shadow tree B;
hayato: there are a lot of possibilities
hayato: for selectors applied to B.
hayato: We should define how cascading should be applied.
hayato: If multiple selectors apply to the same element
hayato: ...element B...
hayato: element B can have an attribute.
hayato: B style-attribute
mjs: I don't understand any of this.
mjs: how do A, B, C, D, E relate to the markup example?
hayato: <html>=A
hayato: It's a shadow host,
hayato: shadow tree hosted by A is B
rniwa: In the original markup, the things outside shadow DOM is A
rniwa: Host one has B.
rniwa: Three has C.
rniwa: If you look outside outer host one
rniwa: there's a node projected through 4.
TabAtkins: Host 4 is a light-dom child of host 2.
TabAtkins: Host 3 is a shadow child of host 2.
TabAtkins: You need target items to understand this.
mjs: I'm not sure anyone here can fully understand this example.
mjs: I think I'm more confused w/ further explanation.
mjs: If D is a shadow tree nested in C, nested in B
mjs: how can a selector in D affect something in B?
rniwa: That's a case where a light DOM node in B is getting
slotted in C in turn slotted into D.
rniwa: Cascading slotting.
rniwa: So selectors from B could apply
rniwa: and selectors from C could apply
rniwa: and selectors from D could apply.
mjs: Ok.
[ group finally understands ]
hayato: We need to consider...
mjs: How is B's style attribute affecting children in shadow DOM
of B?
mjs: I can understand through inheritance, but not cascading
mjs: a node that's a descendant element or ?
???: The host element has...
mjs: I wish the numbers in the markup matched the letters.
hayato: Maybe we need more time to understand.
fantasai: Maybe we need an application.
TabAtkins: We could use my example, it's simpler and more
consistent
<TabAtkins> https://github.com/w3c/webcomponents/issues/316#issuecomment-149735841
TabAtkins: Tinier example, expresses almost everything from the
bigger example:
TabAtkins: The element in question is a menu item example.
TabAtkins: It should express most of the items.
TabAtkins: The menu item is a light DOM child of menu.
TabAtkins: There's a style trying to turn it red.
TabAtkins: Style element trying to turn itself yellow.
TabAtkins: Style on the shadow trying to turn it green.
TabAtkins: Then there's a style inside trying to turn it blue.
TabAtkins: The winner was yellow.
TabAtkins: The ordering is determined by a couple of principles of
how to resolve this.
TabAtkins: style= attributes win.
TabAtkins: Shadow styles are the opposite
TabAtkins: They don't need to guard.
TabAtkins: Normally styles are treated like defaults.
TabAtkins: The opposite using !important inside shadow root.
TabAtkins: Styles from outside would lose.
TabAtkins: This gives defaults and invariants.
TabAtkins: The page rule beats content rule, and page rule beats
host rule.
TabAtkins: The example has things labeled.
TabAtkins: The ids on the styles,
TabAtkins: the inline style isn't labeled, I can't attribute that.
TabAtkins: The rules from outside win over inside.
TabAtkins: Page rules beat content rule.
TabAtkins: Page rules win over :host.
mjs: If you remove inline yellow, what color?
TabAtkins: Red from page.
mjs: The outermost styling scope wins?
TabAtkins: It wins against normal shadow rules.
TabAtkins: Whenever we conflict with normal shadow rules,
TabAtkins: outside ones win since they don't usually intermix,
TabAtkins: so we treat them as intentional.
mjs: I don't follow your logic.
TabAtkins: It was more obvious when we had shadow piercing.
mjs: If we're not overriding.
mjs: If you set :host {display: inline}
mjs: and it would otherwise have {display: block}
mjs: it won't work.
TabAtkins: That's why I mentioned invariants (!important).
mjs: What about UA style sheet?
TabAtkins: Yes, they lose at the origin step.
mjs: Everything in page win over UA at origin step.
mjs: Cascade is several independent steps.
mjs: Origin, author beats UA,
mjs: then style,
mjs: then scoping,
mjs: then specificity,
mjs: then sequence,
mjs: and importance?
TabAtkins: Important is origin.
TabAtkins: They'd be in the same origin
TabAtkins: and important inside shadow would win.
rniwa: Do other people have other questions about this example?
TabAtkins: Besides mjs.
hober: What I was originally going to say was covered.
hober: I think this works, I think it's difficult to follow,
hober: but it's fine.
jyasskin: A host rule is kind of like a UA style sheet for a
shadowed element?
TabAtkins: That's the way you should think of it.
TabAtkins: Originally it was all elements since you could poke
TabAtkins: but now you only can target the host.
adrianba: That's all the time we allocated.
adrianba: How much more time do you want to spend on this?
TabAtkins: What else is there for CSS to do?
astearns: Animations
adrianba: ok, 20 more minutes.
TabAtkins: One thing unordered.
TabAtkins: Eliminate page rule, and style attribute,
TabAtkins: you're left with content/slotted fighting with host-rule.
TabAtkins: I didn't have something, it's described by rune's
proposal.
TabAtkins: From general intuition, I think content should win
against host.
hober: Yep.
TabAtkins: So with remainder, you'd get green.
hober: I think it's the right answer, it's consistent.
hober: I'd love to hear disagreement.
[ None ]
rniwa: An element slotted through multiple shadow DOMs-
rniwa: element, inline-
rniwa: each slot element is a separate shadow DOM.
rniwa: Each could have different styles.
rniwa: All need to be ordered consistently.
rniwa: I heard you had an idea for this,
rniwa: e.g. not styling some...
rniwa: What was the conclusion?
hayato: We haven't...
hayato: First redistribute shadow tree wins.
hayato: If we agree w/ rune's proposal,
rniwa: outer shadow, then inner shadow,
rniwa: style from outer would win over inner.
mjs: That seems backwards from what you said.
mjs: Oh wait, it's consistent.
mjs: Another algorithm would be only your final position,
mjs: maybe simpler to compute.
mjs: I'm not sure it handles your use cases.
mjs: It's hard to tell which is more useful.
rniwa: Consider <listview>
rniwa: Maybe you have another component inside that has two extra
items :before, :after
rniwa: Styles applying to slots.
mjs: I'm already lost.
rniwa: A list of countries.
rniwa: <listview> [list of countries] </listview>
rniwa: You have a preferred countries;
rniwa: the light DOM has some countries (China, Japan),
rniwa: then you have outside USA which it's contributing at the top.
mjs: Can you put slot markers in?
Travis: I think we need to see this example in working browsers.
mjs: Outer things can't see into light children's shadow DOM
mjs: Maybe we should give up inventing this example and do it
offline.
[ laughter ]
rniwa: Ignoring intermediary shadow DOMs seems like a bad idea.
rniwa: Intermediary DOMs may need to add styles to nodes.
hayato: We should define how slotted...
hayato: The current spec says all styles should be applied when
redistribution happens
hayato: because slotted elements apply to distributed nodes.
hayato: Distribution depends on how slotted pseudo element:
hayato: slotted element applied to distributed node of slotted
element (??).
hayato: You might want to add a comment to the issue about slotted
element.
hayato: Make sense?
rniwa: No.
rniwa: The current spec only allows final destination?
hayato: Not only final.
rniwa: Ok, I think we should keep [allowing others to apply style]
rniwa: In addition to TabAtkins's proposal, there's rune's
proposal, and ...
rniwa: What are the differences?
rniwa: It's not obvious how they're different.
rniwa: What's the motivation for each proposal?
hayato: Differences...
rniwa: What are the motivations (for other proposals).
hayato: Proposal 1 is from rune's (Opera's) guys.
hayato: This makes implementation easier.
hayato: rune prefers style= should be treated
hayato: in same way as style in same node tree.
hayato: The reason same attribute is next to B.
mjs: I don't think we want to have style= consistent w/ in a top
level document.
mjs: It should be the same order in a shadow tree, or it's
ridiculous.
rniwa: TabAtkins's proposal, rune's proposal,
rniwa: there' no difference.
rniwa: Was his proposal in response to opinion 2?
rniwa: afaict, TabAtkins's and rune's proposal preserve the
invariants that we want.
rniwa: style rules / style= from same tree next to each other.
rniwa: I'm not sure who's opinion 2 is.
rniwa: Your proposal violates that by putting style= in a
different thing.
rniwa: Given we went through the exercise to understand
TabAtkins's rational...
mjs: TabAtkins's proposal doesn't contain all the letters
mjs: it's hard to tell how it's different from the others.
mjs: Do A+D never apply in TabAtkins, or are they...
mjs: And E isn't used, does that mean they can't apply in Option 2?
TabAtkins: My proposal doesn't have A.
mjs: Before next time we discuss this, could someone write this up
w/ the same set of letters/possibilities
mjs: I can't tell if it's agnostic, say it won't apply, written
against different example...
mjs: It's hard to understand how to pick.
koji: Sorry, proposal 1 is rune's.
koji: ryosuke didn't understand that rune's proposal.
mjs: Is rune's the same as TabAtkins's?
koji: TabAtkins's covers style=, rune's didn't.
koji:. hayato adds nested to TabAtkins's example.
hober: Is it all one proposal, different levels of detail in the
writeup?
hober: Or three proposals, one didn't cover everything, one added
a layer, the next added the next layer?
koji: TabAtkins's added a corner case.
koji: It's just an improvement over rune's.
rniwa: I think this situation is way too confusing for us to
conclude at this time.
rniwa: If one is a superset of another, we don't need the subset
proposals.
mjs: The way TabAtkins wrote his up was a lot easier to understand
than A, B, C, D, E.
mjs: Please write all the proposals up that way.
mjs: 1. explain proposals
mjs: 2. explain reasoning for differences
mjs: Doing 2 first wouldn't help
adrianba: We're out of time.
adrianba: I'm glad we waited until the end of day 2 to talk about
this.
adrianba: We accomplished some progress.
adrianba: The conclusion is a bit more explanation of proposal,
broken down in small pieces. Thanks all for the
discussion.
adrianba: That's the end of WebPlatform WG Meeting
adrianba: Thanks to CSS WG people who came.
[ Applause ]
Received on Tuesday, 24 November 2015 01:17:35 UTC