[CSSWG] Minutes Sapporo F2F 2015-10-27 Part IV: Joint Meeting With WebApps

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
      - 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 { color: blue; }
          :host { color: red; }

  TabAtkins: If you're inside the shadow
  TabAtkins: as this style is, and you try to have a my-component
  TabAtkins: this component, this div, this style.
  TabAtkins: if you take my-component, it won't set on this (the

  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
  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:
  mjs: Although :host sort of refers to a real element, it sort of
  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
  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

  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
  fantasai: An element gets styles, and its pseudo gets its own
            styles, they're independent entities w/ independent
  TabAtkins: Correct, your styles get merged (outside +
  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
  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
  [ laughter ]
  Travis: :host-context
  TabAtkins: selector to host(...)
  TabAtkins: but we figured there were use cases for contexts higher
  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
  hober: :host-context is a pull model, currently things don't do
  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
  <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
  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
  [ 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
  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
  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
  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
  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
  adrianba: We accomplished some progress.
  adrianba: The conclusion is a bit more explanation of proposal,
            broken down in small pieces. Thanks all for the
  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:37 UTC