SV_MEETING_TITLE -- 18 Sep 2015

dglazkov: ?

<dglazkov> https://plus.google.com/hangouts/_/google.com/shadow-dom

<dglazkov> https://www.w3.org/wiki/Webapps/WebComponentsSeptember2015Meeting

<dglazkov> fantasai: ^^^

<thorton> hi rniwa

https://etherpad.mozilla.org/shadow-dom

RRSAgent: make logs public

<scribe> ScribeNick: fantasai

Shadow DOM Styling

rniwa: Topics are :host, :host-context, ::content, style attributes cascading, ???, Travis's inheritance by default, composition algorithm unwrapping slots
... detached shadow.. what about replaced elements, SVG elements, MathML, etc.
... finally [?]

:host() pseudo-class

<rniwa> It's unclear when you say "div :host"

<rniwa> what happens?

It doesn't match

IIRC

It's specced in terms of scoping

selectors in the Shadow DOM are scope-contained

<rniwa> but how is that spec'ed? The spec text says: "When evaluated in the context of a shadow tree, it matches the shadow tree’s host element if the host element, in its normal context, matches the selector argument. In any other context, it matches nothing."

<dglazkov> discussion about "scope-contained" property of selectors

fantasai: Shadow DOM spec should be speccing that selectors in shadow tree are scope-contained
... You can't select an element outside the subtree that it's scoped to

elliott: What about :host-context()

fantasai: It doesn't match an element outside the scoping root, it's pulling info from outside it but it doesn't represent such an element

rniwa: CSS needs to be able to see not just composed tree, but also the original tree
... If you're only exposing compsed tree, a lot of these things don't exist
... we need to fix that

esprehn: We can fix the text.
... :host has nothing to do with the composed tree
... :host-context() operates on the composed tree

fantasai: :host-context() doesn't represent an element in the composed tree, it matches the :host ... if it happens to be in the context described (in the composed tree)

esprehn: It's matching the ancestor chain in the composed tree
... If you project a button into a toolbar through another widget, and the button says :host-context(toolbar) the button can add padding to itself when in a toolbar

<esprehn> x-panel contains <x-toolbar><slot /></x-toolbar>

hober: Shouldn't the toolbar be providing padding?

<esprehn> x-button has :host-context(x-button) { ... } it must match

fantasai: That's not a good example. A different example would be :host-context(.light) vs :host-context(.dark) or different styling whether in main content area vs toolbar
...

esprehn: Point is for widget to select styling based on the context
... To an author, the context is the composed tree
...

rniwa: Shouldn't discuss whether composed tree or what tree,
... Changes style based on context

<annevk> If the shadow tree is closed, can it still use :host and :host-context?

rniwa: If you have a button, it's always a button
... You can style the button
... Custom elements invovling shadow dom, pass certain variable into the component
... dark and light example, maybe you want to define theme color, which is dark or light. Goes into CSS variable and then styled
... Seems very weird that component needs to behave differently based on location in composed tree
... Seems anti-pattern to me

hober: I don't think :host-context is necessary because the stylesheet that defines the them sets a bunch of colors everywhere, and in some kind of shadow-styling world with name parts and vairable, for exposing parts of widget, cna style those parts
... Not responsibility of widget to say how ...

esprehn: We already have this in the platform
... form controls change their padding depending on whether it's likely to look bad
... E.g. if you put aqua buttons next to each other, they magically sprout margins to expand out
... You can solve it this way

hober: I don't think we should use quirky ems as a good example
...

esprehn: Maybe this might be pushed to next level, but it's an author requirement

dglazkov: We don't have devs here, maybe table dthe discussion...

esprehn: We might want to re-evaluate once we have @apply rules.
... Mixins solve this in a similar way
... Toolbar could provide a mixin, and widget could accept the mixin
... So let's present that to authors and see what they say

::content pseudo-element

<rniwa> Let's move onto ::content.

dglazkov: ::content changes drastically due to the way slotting works
... I think this is a great opportunity to fix ::content
... We have an opportunity to not unwrap nodes with slots
... The content or slot pseudo-element could be defined as simply bypass all the slots, and go to the ???

<hober> ::assigned

hober: It's like an assigned pseudo-element
...

<esprehn> ::content .a { }

esprehn: The complication of ::content comes from the fact you can write something like this ^
... You can put a descendant selector, which matches the composition, but arbitrarily deep
... The rules that apply to you can come from arbitrarily above you
... It requires a very complicated ... to accumulate this
... If it could only match one level...

<esprehn> ::content(slot-1) > .a { }

esprehn: I'm not sure how you'd express this in CSS

<dglazkov> ::slot .a

esprehn: But if you're like forced into always having a child combinator right off the end of it
... that makes it much simpler
... then you know that it is directly from where the element was distributed to
... From that slot, not from some random ancestor's distribution

<dglazkov> .my-slot::slot .a

dglazkov: So inside of your shadow tree you would write something like
... All it does is it goes through all the slots
... And reaches the first non-slot thing and tries to match that

esprehn: Not sure I follow dglazkov

hober: Example is if you have a slot element distributed into another slot element

<dglazkov> composed:

hober: You have to go through all the slot elements to get to the actual assigned elements.

annevk: Are you considering whta would happen if the shadow DOM
... A shadow dom can be open or closed. Seems like nothing should work if it's closed, since should be undetectable

esprehn: That's how we implemented it
... otherwise you leak the widget

annevk: CSS spec doesn't account for this

esprehn: CSS spec predates closed shadow doms

ACTION TabAtkins Make CSS Scoping module account for lcosed Shadow DOMs

<trackbot> Error finding 'TabAtkins'. You can review and register nicknames at <http://www.w3.org/2008/webapps/track/users>.

rniwa: One thing we need to do is rename ::content to ::assigned

?: Or ::slot. Or something.

esprehn: I think ::slot is better

hober: ::slotted

dglazkov: ::assigned is better, you're operating on a slot
... Otherwise you'll be writing ::slot::slot

esprehn: In practice people don't write slot
... You'd just write ::assigned

annevk: I think ::slot or ::slotted would be better
... It's clearer that it relates to ShadowDOM

rniwa: I think of those options, I think ::slotted is better
... DOes anyone know why ::slotted doesn't take a functional syntax?
... It's magical think where lefthand side matchs to shadow dom, and righthand side matches to things in the slot

<hober> ::assigned-to(slot-1)

<esprehn> ::cue(.a .b) vs ::cue .a .b

rniwa: Inside a ShadowDOM you can have a slot
... In shadow host you can have children
... Some o f those children are assigned into one of those slots
... ::slotted is to style the children in those slots

<esprehn> This was done so you could add combinators

rniwa: So as it's currently specced, ::slotted on the righthandside will match against those children and its descendants

<annevk> A way to style those children from inside the shadow DOM, right?

<esprehn> ::slotted(> .a) doesn't work, so it's ::slotted > .a

rniwa: If you had ...

<rniwa> <span><b></b></span> as a assgiend node to a slot

<rniwa> then ::slotted span b would match b here

esprehn: It was not functional to use combinators

fantasai: You could certainly define a functional syntax that accepted combinators, e.g. :has()

<esprehn> ::cue(b) does the same thing though

<esprehn> b is in another tree

<dglazkov> fantasai: explains how CSS pseudoelement(function) syntax works

{insert explanation of pseud-element syntax as tree-context-shifting combinator }

<hober> #awesome-slot::slotted(div) then?

<dglazkov> ACTION TabAtkins define ::slotted in CSS Scoping text

<trackbot> Error finding 'TabAtkins'. You can review and register nicknames at <http://www.w3.org/2008/webapps/track/users>.

<esprehn> ::slotted(div#awesome-slot)

hober: That's a div that got slotted into a slot that's called #awesome-slot

<rniwa> An example of creating a slot in shadow dom: <shadow-root><div><slot name="awsome-slot"></div></shadow-root>

fantasai askes for a concerete example with ShadowDOM syntax

<hober> more typically you'd probably write slot[name=awesome]::slotted(div)

OK, cool

<esprehn> ah then yes #awesome-slot::slotted(div)

So the selectors for that would be

<rune> hober: so how would you write it if you have combinators to select descendants of the div?

div > #awesome-slot::slotted stuff-inside-awesomeslot

<rniwa> (except I didn't id to slot element so #awesome-slot doesn't quite work...)

esprehn: What you want here is you need some kind of implicit child combinator
... so that you can only select one level down

fantasai: One level down period, or one level of shadow down?

esprehn: One level period

rniwa: The tricky part is ...

<hober> well, you can only slot children

<esprehn> #awesome-slot::slotted(div) > span { }

esprehn: I want to jump through the div that got slotted, and style stuff on the other side

<esprehn> #awesome-slot::slotted(div) a { }

esprehn: Complexity of ::content was that it didn't have to be a child combinator, coudl be a descendant combinator

dglazkov: That matches div that is slotted, then matching a child of that div

<esprehn> ::content > span { }

dglazkov: Devs wanted that, so that's why not built as a function

<esprehn> ::content a { }

esprehn: This replaced the pool of elements with things that were in that distribution

?: N levels ... ????

<hober> what about slot[name=awesome]::slotted(div NEW-SYNTAX a)?

<dglazkov> N levels of shadow trees

annevk: It seems a little weird that we have removed selector matching for things that have been distributed or slotted on the content side, but we keep it here in CSS

hober: Since we can only slot children, it would make sense to not be able to style arbitrary descendants

esprehn: You can't style only children. You can reslot a slot
... But somehow I need to be able to style those
... You have buttons into a panel. Panel moves into a toolbar.
... Toolbar wants to style buttons inside panen
... but its direct children are just more slots

?: can't we just do it with variables?

esprehn: Variables requires explicit coordination.

<dglazkov> ?: was dglazkov

esprehn: If your toolbar was written with JQuery and buttons were Angular
... Allowing you to style conceptiually what are your children
... Your children in the composed tree

annevk: I'm not necessarily concerned with the children
... The concer was more with the div bit
... Not with the span, but with the div inside the the parentheses
... That was the bit that seemed weird to me.

<rniwa> I agree with anne

esprehn: Maybe it's not clear here
... Given that example

<esprehn> ShadowRoot on <host>

esprehn: Host has a shadow root

esprehn: Shadow root contains <slot>
... the div goes into that slot
... This widget wants to style the divs that go into its slot

<esprehn> ::slot(div > span) { }

::slot div { style div }

::slot div > span { style span }

<annevk> fantasai: inconsistent with ::cue

esprehn: Needs to behave differently whether ... slots or actual ...

hober: I like that the :slot pseudo does the eliding the fact that there are N slots

<annevk> http://dev.w3.org/html5/webvtt/#the-cue-pseudo-element has functional :-/

esprehn: Conesnsus from WG was changing ::cue syntax to use tree-switching behavior

<esprehn> ::cue b { }

annevk: Is that still possible to change?

fantasai: Didn't ::cue match against somethign that wasn't a tree?

annevk: It's a tree, just not a DOM tree

esprehn: The way that webkit does this, there's a shadow root, and we put divs or bold in it
... It's just anonymous content

dglazkov: Is this someting we have to figure out now?
... Or go on rough consensus?
... Proceed with this on www-style

alexrussel: Hear from ppl who actually use it?

dglazkov: This syntax is that we have for :;content, it's just , we're tryng to figure out whether ::cue will conform to that in the future

Style attributes in shadow DOM ordering proposal

hober: My main concern with this issue is that in a world without shadow DOM, there is already a cascading order

<annevk> I'll have to bow out, getting close to dinner time here

<annevk> Thanks for taking minutes fantasai, much appreciated

hober: The world with shadow dom should simply be adding to that order, not changing what order exists
... Option 2 and 3 reverse the nroder of normal attributes and normal attr

<rniwa> proposal is at https://github.com/w3c/webcomponents/issues/316

hober: Whatever we agree should be consistent with what we have

esprehn: Intent was that person on outside is assumed to have more knowledge than person on inside

<rune> https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Shadow-DOM-Cascade-Order.md

esprehn: User of widget knows better what style should be than person who created widget

<rune> https://github.com/w3c/webcomponents/issues/316

esprehn: So this is trying to enforce that

<rniwa> Could someone clarify the current cascading order without shadow DOM?

http://www.w3.org/TR/css-cascade-4/#cascading

rune: Clarifies ordering in tree-of-trees, but doesn't clarify scoped

rniwa: Not clear it tells us which order these happen
... override is style attr?

<hober> http://www.w3.org/TR/CSS21/cascade.html#cascading-order

fantasai: style attr changes specificity, not origin

<rune> declarations from style attributes can be seen as author rules with infinite specificity

fantasai: The Cascade has several things that matter. Most important one is orign
... This is where things invert / are arbitrary. important vs. non-important is handled in origin

rune: Style attribute is only one part of what's handling

<rune> sorry

rune: ... ?

<kochi_home> style attribute has its own spec: https://drafts.csswg.org/css-style-attr/#interpret

fantasai: Within a single origin the next thing that's important is scoping
... Inner scope win over outer scope, except for !important rules where outer scope wins ove rinner scope
... The next thing that's important is specificity
... if you have the same origin and the same scoping level, then you sort by specificity.
... Style attribute is the most specific selector

<koji> The cascade-4 says "Normal declarations from style attributes are considered to be scoped to the element with the attribute, whereas important declarations from style attributes are considered to be scoped to the root element."

<koji> so the style attribute was top of specificity in CSS 2, but

<koji> was boosted to the top of scope in cascade-4

<rniwa> So style attribute is treated as a different scope as opposed to a different specificity?

fantasai:

esprehn: Someone from the outside applies 'display: flex' to something
... If you look at top of example

<esprehn> https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Shadow-DOM-Cascade-Order.md

esprehn: Example at top was ::slot menutiem { display flex }
... If menuitem set hidden attr, it would never apply
... The outer one would win, and that breaks all kinds of stuff
... The hidden attr fails to operate

<esprehn> ::slot div span { }

hober: I thought you said outer author knew more what should happen

esprehn: ...

esprehn: That would win, andif span had hidden attribute, it would not be hidden

<rune> hober, elliott: you just explained why I'm unsure about option 1 or 2 for style attribute cascading order

esprehn: This was very confusing to authors because widget woudl be trying to hide things, and person from outside would defeat it

<rune> leaning towards option 2 now

rniwa: I think the quesiton is what's the scoping order of attributes vs. rules coming from host and content
... Is that the question?

<esprehn> [hidden] { display: none; }

esprehn: If we wanted to make that win, that seems complicated
... Since UA rules are the default

hober: UA normal is the lowest priority

fantasai: You could consider using !improtant to sort
... e.g. ua rule sare lowest, but ua!important are highest
... similarly scoped styles, invert !important sorting

esprehn proposes something

rniwa: This seems issue of if I have a ::slotted rule, what is the scope owner of that scope
... against scope of rules apply on slotted nodes
... that's coming from teh light

<hober> I think the relevant principle is that we should not encourage a proliferation of !important rules. So whichever case is more common shouldn't get !important

esprehn: This is just host rules

<esprehn> :host(.a) { display: flex; }

hober, !important is for this kind of thing

rniwa: ... what is not clear to me is in case of content
... Problem is that scoping order is reversed in composed tree

<hober> fantasai, indeed! it's for exceptional cases, not the common case.

rniwa: In composed tree what's got assigned into a slot
... is coming from outer scop
... And then rules that apply come from outside composed tree

esprehn: In terms of simplified mental model
... hidden thing, don't do that
... outer always wins is simplest way to explain this
... confusion for us is compounded by our scoping impl was broken, exposing th fact that ... ????
... If shadow dom always have correct ehavior from the start

fantasai: There's a couple issues I see that I'm not clear what we're talking about
... First thing is styling stuff in shadow tree... I guess tha'ts not stylable from stuff outside shadow tree, so no conflict there.
... So the stuff we're talking about is the stuff that's been slotted, is that correct?

rniwa: yes

fantasai: So in that case, we have rules from the shadow root and stuf from the host element's ancestors

esprehn: It's from your distribution from your composted tree

<rune> What I'm trying to fix with https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Shadow-DOM-Cascade-Order.md is that the current wording in CSS scoping which makes specificity count between different shadow trees.

fantasai: We have a variety of sources of style
... One would be style linked from the top of the document
... another is style from shadow tree, linked or embedded
... another is scoped style attached to the distributed nodes or their descendants

<esprehn> <host><div slot="a" /></host> => ShadowRoot <style>::slot(div) { color: blue; }</style><host2><slot slot="b" name="a" /></host2> => ShadowRoot <style>::slot(div) { color: red; }</style><slot name="b">

fantasai: so the question is what wins over what
... And proposal currently is what?
... We have A) Document styles B) Shadow DOM styles C) Embedded styles

<esprehn> rune: In that example, is it blue?

fantasai: A < C for sure
... but A! > C!

<esprehn> if div had style="color: green" is it still blue?

<rune> so the proposal is that rules from different shadow trees are ordered by the tree-of-trees order, that is, inner/outer in the composed tree

fantasai: We have A < C < C! < A!

<rune> where outer normal wins over inner normal

<rune> and inner !important wins over outer !important

fantasai: slot B into the equation, please?

<dglazkov> example above in http://jsbin.com/fabacu/edit?html,output

<rune> so slotting is what's causing the inner/outer order in the composed tree

fantasai: yes, but can you make an expression with A, B, C, A!, B!, C!?

<shadow-root> <style>C</style> <slot distributes div></shadow-root>

shadow-root is attached to <section>

<rniwa> We only have 10min left and we won't be able to finish this

<rniwa> We should figure out how to resolve this.

<rune> I've tried to get attention on www-style before.

<dglazkov> topic for TPAC, continue discussion on www-style

<rniwa> Perhaps we need a joint discussion between CSS WG and WebApps WG.

fantasai: Need to explain clearly the situation, so that people who don't know shadow DOM can contribute

rune: I'm not so familiar with the slot syntax yet

rniwa: I think we should move on from this topic

esprehn: Next thing is inheritance

arronei: Travis and I had a quesiton on inheritance
... Some discussion that helps the story here...
... If we can pound through this really quick, that'd be great

dglazkov: I tried early on turning inheritance off by default
... For very simple widgets, you end up writing a ton of stuff
... It's certainly a good feature of shadow dom to turn it off
... We removed this attribute because CSS has 'all: initial' which does this

<hober> in browsers today, <b><button>hello</button></b> hello is not bold

dglazkov: For closed trees, seems very unlikely you'd want to inherit styles

arronei: Travis and I would prefer to make closed completely closed, you don't get inheritance

hober: I think this is a case where the default shouldn't differ between open and closed

esprehn: That doesn't match the platform
... font styles inherit into inputs

hober: But text doesn't become bold

fantasai: You can do both, depending on your widget
... you can say 'all: initial'
... that blocks everything
... but you can also selectively say

'all: initial; font-family: inherit'

esprehn: button example is really good
... if you put a <b> around it, it does turn bold, but if you make the text red, it inherits red
... It's selectively chosen what to inherit

hober: You can argue for either default depending on platform behavior
... MS perfers closed to not inherit
... I prefer to not differ between open and closed
... so sounds like we should have non-inherited by default

rniwa: 'all:initial' would erase the UA stylesheet
... Could maybe add a new value to all, but ...

hober: I think it's a good idea to add a new value to all

<rniwa> not inheriting by default would work because you can explicitly set "all: inherit"

fantasai: We have a revert value.
... Are you asking for a revert value that also blocks inheritance?

<esprehn> http://plexode.com/eval3/#s=aekVQXANJVQMbAx14Hw9CAVwBiBsBU0ZFAV4dEJY9T6gdQ1ZVVVBPAXcePQNCtR8pRk1NUAE4UFNNRaWsrrAfqKpysrS2uKgBAautr0+5u72/wcPF1ciqEHLJTwNeAA==

<esprehn> I'm wrong <button> seems to not inherit ever, you have to style it explicitly

fantasai explains revert

http://www.w3.org/TR/css-cascade-4/#default

hober: Wrt attached shadow

<rune> esprehn: regarding your example, yes blue.

hober: I don't think it's necessary to have a special rule

<rune> esprehn: yes, blue

hober: SVG and MathML are kindof weird
... If we wanted to say shadow trees only work on HTML elements, that'd be fine by me. I don't care
... replaced elements have interesting inrinsic size behavior
... Maybe we have an API for interacting with that intrinsic size
... But even without it, I don't see any reason not to allow shadow roots on them
... Does anyone object to disallowing shadow rootson non-HTML elements?

dglazkov: I don't think it's a bad idea. But need to ask SVGWG

esprehn: It's used in an explanation for what the SVG <use> element does
... But in terms of what we expose, I think it's fine to not allow it for now
... Originally there was some disagreement whether you could call attachShadow on an input element
... Is that okay now?

dglazkov: no, there's a blacklist
... Okay, let's continue discussion on www-style

<esprehn> awesome, thanks for all the feedback!

dglazkov: Concrete actions are
... ::slotted in the scoping spec
... And generally align with v1 Shadow DOM
... I'll help you and Tab
... and bring you up to speed on the new spec
... that's about it

fantasai: And we need to discuss cascading order

dglazkov: I'm more concerned .. this is something we can tweak once we have running code
... First part is blocking

RRSAgent: Make Minutes

RRSAgent: Make logs public

RRSAgent: Make minutes

RRSAgent: make minutes

- DRAFT -

SV_MEETING_TITLE

18 Sep 2015

Attendees

Contents

Shadow DOM Styling

:host() pseudo-class

::content pseudo-element

Style attributes in shadow DOM ordering proposal

Summary of Action Items

Scribe.perl diagnostic output