16:02:35 <RRSAgent> RRSAgent has joined #webapps
16:02:35 <RRSAgent> logging to http://www.w3.org/2015/09/18-webapps-irc
16:06:11 <fantasai> dglazkov: ?
16:06:56 <rniwa> rniwa has joined #webapps
16:08:20 <dglazkov> https://plus.google.com/hangouts/_/google.com/shadow-dom
16:08:34 <dglazkov> https://www.w3.org/wiki/Webapps/WebComponentsSeptember2015Meeting
16:09:23 <dglazkov> fantasai: ^^^
16:09:52 <arronei> arronei has joined #webapps
16:09:54 <dglazkov> dglazkov has changed the topic to: Shadow DOM styling https://www.w3.org/wiki/Webapps/WebComponentsSeptember2015Meeting
16:10:32 <thorton> thorton has joined #webapps
16:11:18 <thorton> hi rniwa
16:12:19 <fantasai> https://etherpad.mozilla.org/shadow-dom
16:13:06 <fantasai> RRSAgent: make logs public
16:13:14 <fantasai> ScribeNick: fantasai
16:13:22 <fantasai> Topic: Shadow DOM Styling
16:14:17 <fantasai> rniwa: Topics are :host, :host-context, ::content, style attributes cascading, ???, Travis's inheritance by default, composition algorithm unwrapping socks(?)
16:14:34 <fantasai> rniwa: detached shadow.. what about replaced elements, SVG elements, MathML, etc.
16:14:42 <koji> s/socks(?)/slots/
16:14:50 <fantasai> rniwa: finally [?]
16:15:12 <fantasai> Topic: :host() pseudo-class
16:15:27 <rniwa> It's unclear when you say "div :host"
16:15:32 <rniwa> what happens?
16:15:36 <fantasai> It doesn't match
16:15:38 <fantasai> IIRC
16:15:59 <fantasai> It's specced in terms of scoping
16:16:09 <fantasai> selectors in the Shadow DOM are scope-contained
16:16:18 <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."
16:17:04 <dglazkov> discussion about "scope-contained" property of selectors
16:17:45 <fantasai> fantasai: Shadow DOM spec should be speccing that selectors in shadow tree are scope-contained
16:17:58 <fantasai> fantasai: You can't select an element outside the subtree that it's scoped to
16:18:27 <fantasai> elliott: What about :host-context()
16:19:02 <fantasai> 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
16:19:20 <fantasai> rniwa: CSS needs to be able to see not just composed tree, but also the original tree
16:19:31 <fantasai> rniwa: If you're only exposing compsed tree, a lot of these things don't exist
16:19:34 <fantasai> rniwa: we need to fix that
16:19:40 <fantasai> esprehn: We can fix the text.
16:19:46 <fantasai> esprehn: :host has nothing to do with the composed tree
16:19:56 <fantasai> esprehn: :host-context() operates on the composed tree
16:20:10 <hgl> hgl has joined #webapps
16:20:48 <annevk> annevk has joined #webapps
16:20:51 <fantasai> 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)
16:21:01 <fantasai> esprehn: It's matching the ancestor chain in the composed tree
16:21:30 <fantasai> esprehn: 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
16:21:45 <esprehn> <x-panel><x-button></x-button></x-panel>
16:21:56 <esprehn> x-panel contains <x-toolbar><slot /></x-toolbar>
16:21:59 <fantasai> hober: Shouldn't the toolbar be providing padding?
16:22:07 <esprehn> x-button has :host-context(x-button) { ... } it must match
16:22:23 <fantasai> 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
16:22:35 <fantasai> ...
16:22:43 <fantasai> esprehn: Point is for widget to select styling based on the context
16:22:49 <fantasai> esprehn: To an author, the context is the composed tree
16:23:04 <fantasai> ...
16:23:15 <fantasai> rniwa: Shouldn't discuss whether composed tree or what tree,
16:23:21 <fantasai> rniwa: Changes style based on context
16:23:28 <annevk> If the shadow tree is closed, can it still use :host and :host-context?
16:23:30 <fantasai> rniwa: If you have a button, it's always a button
16:23:38 <fantasai> rniwa: You can style the button
16:23:47 <fantasai> rniwa: Custom elements invovling shadow dom, pass certain variable into the component
16:24:03 <fantasai> rniwa: dark and light example, maybe you want to define theme color, which is dark or light. Goes into CSS variable and then styled
16:24:14 <fantasai> rniwa: Seems very weird that component needs to behave differently based on location in composed tree
16:24:19 <fantasai> rniwa: Seems anti-pattern to me
16:24:49 <fantasai> 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
16:25:01 <fantasai> hober: Not responsibility of widget to say how ...
16:25:10 <fantasai> esprehn: We already have this in the platform
16:25:23 <fantasai> esprehn: form controls change their padding depending on whether it's likely to look bad
16:25:42 <fantasai> esprehn: E.g. if you put aqua buttons next to each other, they magically sprout margins to expand out
16:25:55 <fantasai> esprehn: You can solve it this way
16:26:05 <fantasai> hober: I don't think we should use quirky ems as a good example
16:26:35 <fantasai> ...
16:27:05 <fantasai> esprehn: Maybe this might be pushed to next level, but it's an author requirement
16:27:18 <fantasai> dglazkov: We don't have devs here, maybe table dthe discussion...
16:27:28 <fantasai> esprehn: We might want to re-evaluate once we have @apply rules.
16:27:33 <fantasai> esprehn: Mixins solve this in a similar way
16:27:45 <fantasai> esprehn: Toolbar could provide a mixin, and widget could accept the mixin
16:27:53 <fantasai> esprehn: So let's present that to authors and see what they say
16:28:02 <fantasai> Topic: ::content pseudo-element
16:28:02 <rniwa> Let's move onto ::content.
16:28:13 <fantasai> dglazkov: ::content changes drastically due to the way slotting works
16:28:20 <fantasai> dglazkov: I think this is a great opportunity to fix ::content
16:28:27 <fantasai> dglazkov: We have an opportunity to not unwrap nodes with slots
16:28:47 <fantasai> dglazkov: The content or slot pseudo-element could be defined as simply bypass all the slots, and go to the ???
16:29:01 <hober> ::assigned
16:29:03 <fantasai> hober: It's like an assigned pseudo-element
16:29:10 <fantasai> ...
16:29:15 <esprehn> ::content .a { }
16:29:19 <fantasai> esprehn: The complication of ::content comes from the fact you can write something like this ^
16:29:35 <fantasai> esprehn: You can put a descendant selector, which matches the composition, but arbitrarily deep
16:29:46 <fantasai> esprehn: The rules that apply to you can come from arbitrarily above you
16:29:51 <kochi_home> kochi_home has joined #webapps
16:29:56 <fantasai> esprehn: It requires a very complicated ... to accumulate this
16:30:01 <fantasai> esprehn: If it could only match one level...
16:30:02 <esprehn> ::content(slot-1) > .a { }
16:30:05 <fantasai> esprehn: I'm not sure how you'd express this in CSS
16:30:09 <dglazkov> ::slot .a
16:30:16 <fantasai> esprehn: But if you're like forced into always having a child combinator right off the end of it
16:30:23 <fantasai> esprehn: that makes it much simpler
16:30:31 <fantasai> esprehn: then you know that it is directly from where the element was distributed to
16:30:40 <fantasai> esprehn: From that slot, not from some random ancestor's distribution
16:30:45 <dglazkov> .my-slot::slot .a
16:30:48 <fantasai> dglazkov: So inside of your shadow tree you would write something like
16:30:54 <fantasai> dglazkov: All it does is it goes through all the slots
16:31:02 <fantasai> dglazkov: And reaches the first non-slot thing and tries to match that
16:31:12 <fantasai> esprehn: Not sure I follow dglazkov
16:31:12 <dglazkov> <slot class="my-slot></slot>
16:31:22 <fantasai> hober: Example is if you have a slot element distributed into another slot element
16:31:33 <dglazkov> composed:
16:31:34 <fantasai> hober: You have to go through all the slot elements to get to the actual assigned elements.
16:31:58 <dglazkov> <slot class="my-slot><slot><slot><div class="a"></div></slot></slot></slot>
16:32:17 <fantasai> annevk: Are you considering whta would happen if the shadow DOM [??]
16:32:45 <fantasai> s/[??]/
16:32:59 <fantasai> annevk: A shadow dom can be open or closed. Seems like nothing should work if it's closed, since should be undetectable
16:33:08 <fantasai> esprehn: That's how we implemented it
16:33:13 <fantasai> esprehn: otherwise you leak the widget
16:33:20 <fantasai> annevk: CSS spec doesn't account for this
16:33:26 <fantasai> esprehn: CSS spec predates closed shadow doms
16:33:40 <fantasai> ACTION TabAtkins Make CSS Scoping module account for lcosed Shadow DOMs
16:33:40 <trackbot> Error finding 'TabAtkins'. You can review and register nicknames at <http://www.w3.org/2008/webapps/track/users>.
16:34:03 <fantasai> rniwa: One thing we need to do is rename ::context to ::assigned
16:34:07 <fantasai> s/context/content/
16:34:15 <fantasai> ?: Or ::slot. Or something.
16:34:21 <fantasai> esprehn: I think ::slot is better
16:34:23 <fantasai> hober: ::slotted
16:34:35 <fantasai> dglazkov: ::assigned is better, you're operating on a slot
16:34:43 <fantasai> dglazkov: Otherwise you'll be writing ::slot::slot
16:34:54 <fantasai> esprehn: In practice people don't write slot
16:35:00 <fantasai> esprehn: You'd just write ::assigned
16:35:06 <fantasai> annevk: I think ::slot or ::slotted would be better
16:35:15 <fantasai> annevk: It's clearer that it relates to ShadowDOM
16:35:30 <fantasai> rniwa: I think of those options, I think ::slotted is better
16:35:43 <fantasai> rniwa: DOes anyone know why ::slotted doesn't take a functional syntax?
16:35:58 <fantasai> rniwa: It's magical think where lefthand side matchs to shadow dom, and righthand side matches to things in the slot
16:36:01 <hober> ::assigned-to(slot-1)
16:36:20 <esprehn> ::cue(.a .b) vs ::cue .a .b
16:36:35 <fantasai> rniwa: Inside a ShadowDOM you can have a slot
16:36:40 <fantasai> rniwa: In shadow host you can have children
16:36:49 <fantasai> rniwa: Some o f those children are assigned into one of those slots
16:36:56 <fantasai> rniwa: ::slotted is to style the children in those slots
16:37:05 <esprehn> This was done so you could add combinators
16:37:15 <fantasai> rniwa: So as it's currently specced, ::slotted on the righthandside will match against those children and its descendants
16:37:18 <annevk> A way to style those children from inside the shadow DOM, right?
16:37:21 <esprehn> ::slotted(> .a) doesn't work, so it's ::slotted > .a
16:37:21 <fantasai> rniwa: If you had ...
16:37:35 <rniwa> <span><b></b></span> as a assgiend node to a slot
16:37:43 <rniwa> then ::slotted span b would match b here
16:37:46 <fantasai> esprehn: It was not functional to use combinators
16:38:10 <fantasai> fantasai: You could certainly define a functional syntax that accepted combinators, e.g. :has()
16:38:44 <esprehn> ::cue(b) does the same thing though
16:38:55 <esprehn> b is in another tree
16:39:16 <dglazkov> fantasai: explains how CSS pseudoelement(function) syntax works
16:40:16 <fantasai> {insert explanation of pseud-element syntax as tree-context-shifting combinator }
16:40:32 <hober> #awesome-slot::slotted(div) then?
16:40:45 <dglazkov> ACTION TabAtkins define ::slotted in CSS Scoping text
16:40:45 <trackbot> Error finding 'TabAtkins'. You can review and register nicknames at <http://www.w3.org/2008/webapps/track/users>.
16:41:12 <esprehn> ::slotted(div#awesome-slot)
16:41:13 <fantasai> hober: That's a div that got slotted into a slot that's called #awesome-slot
16:42:09 <rniwa> An example of creating a slot in shadow dom: <shadow-root><div><slot name="awsome-slot"></div></shadow-root>
16:42:10 <fantasai> fantasai askes for a concerete example with ShadowDOM syntax
16:42:14 <hober> more typically you'd probably write slot[name=awesome]::slotted(div)
16:42:16 <fantasai> OK, cool
16:42:21 <esprehn> ah then yes #awesome-slot::slotted(div)
16:42:21 <fantasai> So the selectors for that would be
16:42:27 <rune> hober: so how would you write it if you have combinators to select descendants of the div?
16:42:40 <fantasai> div > #awesome-slot::slotted stuff-inside-awesomeslot
16:43:09 <rniwa> (except I didn't id to slot element so #awesome-slot doesn't quite work...)
16:43:13 <fantasai> esprehn: What you want here is you need some kind of implicit child combinator
16:43:19 <fantasai> esprehn: so that you can only select one level down
16:43:44 <fantasai> fantasai: One level down period, or one level of shadow down?
16:43:46 <fantasai> esprehn: One level period
16:43:58 <fantasai> rniwa: The tricky part is ...
16:44:00 <esprehn> <div><span><a /></span></div> => <shadow-root><slot name="awsome-slot" /></shadow-root>
16:44:00 <hober> well, you can only slot children
16:44:16 <esprehn> #awesome-slot::slotted(div) > span { }
16:44:35 <fantasai> esprehn: I want to jump through the div that got slotted, and style stuff on the other side
16:44:57 <esprehn> #awesome-slot::slotted(div) a { }
16:45:03 <fantasai> esprehn: Complexity of ::content was that it didn't have to be a child combinator, coudl be a descendant combinator
16:45:44 <fantasai> dglazkov: That matches div that is slotted, then matching a child of that div
16:45:52 <esprehn> ::content > span { }
16:45:55 <fantasai> dglazkov: Devs wanted that, so that's why not built as a function
16:46:12 <esprehn> ::content a { }
16:46:14 <fantasai> esprehn: This replaced the pool of elements with things that were in that distribution
16:46:31 <fantasai> ?: N levels ... ????
16:46:31 <hober> what about slot[name=awesome]::slotted(div NEW-SYNTAX a)?
16:46:42 <dglazkov> N levels of shadow trees
16:47:09 <fantasai> annevk: It seems a little wierd 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
16:47:20 <fantasai> hober: Since we can only slot children, it would make sense to not be able to style arbitrary descendants
16:47:29 <fantasai> esprehn: You can't style only children. You can reslot a slot
16:47:36 <fantasai> esprehn: But somehow I need to be able to style those
16:47:44 <fantasai> esprehn: You have buttons into a panel. Panel moves into a toolbar.
16:47:52 <fantasai> esprehn: Toolbar wants to style buttons inside panen
16:47:58 <fantasai> esprehn: but its direct children are just more slots
16:48:10 <fantasai> ?: can't we just do it with variables?
16:48:15 <fantasai> esprehn: Variables requires explicit coordination.
16:48:19 <dglazkov> ?: was dglazkov
16:48:24 <annevk> s/wierd/weird/
16:48:26 <fantasai> esprehn: If your toolbar was written with JQuery and buttons were Angular
16:48:35 <fantasai> esprehn: Allowing you to style conceptiually what are your children
16:48:39 <fantasai> esprehn: Your children in the composed tree
16:48:45 <fantasai> annevk: I'm not necessarily concerned with the children
16:48:49 <fantasai> annevk: The concer was more with the div bit
16:48:59 <fantasai> annevk: Not with the span, but with the div inside the the parentheses
16:49:08 <fantasai> annevk: That was the bit that seemed weird to me.
16:49:09 <rniwa> I agree with anne
16:49:18 <esprehn> <host><div><span /></div></host>
16:49:21 <fantasai> esprehn: Maybe it's not clear here
16:49:26 <fantasai> esprehn: Given that example
16:49:28 <esprehn> ShadowRoot on <host>
16:49:30 <fantasai> esprehn: Host has a shadow root
16:49:35 <esprehn> <slot>
16:49:36 <fantasai> esprehn: Shadow root contains <slot>
16:49:43 <fantasai> esprehn: the div goes into that slot
16:49:50 <fantasai> esprehn: This widget wants to style the divs that go into its slot
16:49:53 <esprehn> ::slot(div > span)  { }
16:50:02 <esprehn> <host><slot /></host>
16:50:06 <fantasai> ::slot div  { style div }
16:50:22 <fantasai> ::slot div > span { style span }
16:50:23 <fantasai> ?
16:50:33 <annevk> fantasai: inconsistent with ::cue
16:50:43 <fantasai> esprehn: Needs to behave differently whether ... slots or actual ...
16:50:53 <fantasai> hober: I like that the :slot pseudo does the eliding the fact that there are N slots
16:50:54 <annevk> http://dev.w3.org/html5/webvtt/#the-cue-pseudo-element has functional :-/
16:51:18 <fantasai> esprehn: Conesnsus from WG was changing ::cue syntax to use tree-switching behavior
16:51:21 <esprehn> ::cue b { }
16:51:24 <fantasai> annevk: Is that still possible to change?
16:52:01 <fantasai> fantasai: Didn't ::cue match against somethign that wasn't a tree?
16:52:04 <fantasai> annevk: It's a tree, just not a DOM tree
16:52:31 <fantasai> esprehn: The way that webkit does this, there's a shadow root, and we put divs or bold in it
16:52:36 <fantasai> esprehn: It's just anonymous content
16:52:48 <fantasai> dglazkov: Is this someting we have to figure out now?
16:52:55 <fantasai> dglazkov: Or go on rough consensus?
16:53:01 <fantasai> dglazkov: Proceed with this on www-style
16:53:18 <fantasai> alexrussel: Hear from ppl who actually use it?
16:53:47 <fantasai> 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
16:53:57 <fantasai> Topic: Style attributes in shadow DOM ordering proposal
16:54:17 <fantasai> hober: My main concern with this issue is that in a world without shadow DOM, there is already a cascading order
16:54:19 <annevk> I'll have to bow out, getting close to dinner time here
16:54:26 <annevk> Thanks for taking minutes fantasai, much appreciated
16:54:38 <fantasai> hober: The world with shadow dom should simply be adding to that order, not changing what order exists
16:55:12 <fantasai> hober: Option 2 and 3 reverse the nroder of normal attributes and normal attr
16:55:24 <rniwa> proposal is at https://github.com/w3c/webcomponents/issues/316
16:55:29 <fantasai> hober: Whatever we agree should be consistent with what we have
16:55:46 <fantasai> esprehn: Intent was that person on outside is assumed to have more knowledge than person on inside
16:55:53 <rune> https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Shadow-DOM-Cascade-Order.md
16:56:02 <fantasai> esprehn: User of widget knows better what style should be than person who created widget
16:56:06 <rune> https://github.com/w3c/webcomponents/issues/316
16:56:06 <fantasai> esprehn: So this is trying to enforce that
16:56:29 <rniwa> Could someone clarify the current cascading order without shadow DOM?
16:56:36 <fantasai> http://www.w3.org/TR/css-cascade-4/#cascading
16:56:52 <fantasai> rune: Clarifies ordering in tree-of-trees, but doesn't clarify scoped
16:57:12 <fantasai> rniwa: Not clear it tells us which order these happen
16:57:31 <fantasai> rniwa: override is style attr?
16:57:34 <hober> http://www.w3.org/TR/CSS21/cascade.html#cascading-order
16:57:40 <fantasai> fantasai: style attr changes specificity, not origin
16:57:53 <rune> declarations from style attributes can be seen as author rules with infinite specificity
16:58:52 <fantasai> fantasai: The Cascade has several things that matter. Most important one is orign
16:59:12 <fantasai> fantasai: This is where things invert / are arbitrary. important vs. non-important is handled in origin
16:59:30 <fantasai> rune: Style attribute is only one part of what's handling
16:59:42 <rune> sorry
16:59:43 <fantasai> rune: ... ?
16:59:48 <kochi_home> style attribute has its own spec: https://drafts.csswg.org/css-style-attr/#interpret
17:00:09 <fantasai> fantasai: Within a single origin the next thing that's important is scoping
17:00:36 <fantasai> fantasai: Inner scope win over outer scope, except for !important rules where outer scope wins ove rinner scope
17:00:51 <fantasai> fantasai: The next thing that's important is specificity
17:01:15 <fantasai> fantasai: if you have the same origin and the same scoping level, then you sort by specificity.
17:01:21 <fantasai> fantasai: Style attribute is the most specific selector
17:02:15 <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."
17:02:32 <koji> so the style attribute was top of specificity in CSS 2, but
17:02:40 <koji> was boosted to the top of scope in cascade-4
17:03:12 <rniwa> So style attribute is not treated as a different scope as opposed to a different specificity?
17:03:21 <rniwa> s/not treated/treated/
17:03:42 <fantasai> ...
17:03:49 <fantasai> esprehn: Someone from the outside applies 'display: flex' to something
17:03:56 <fantasai> esprehn: If you look at top of example
17:04:08 <esprehn> https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Shadow-DOM-Cascade-Order.md
17:04:29 <fantasai> esprehn: Example at top was ::slot menutiem { display flex }
17:04:38 <fantasai> esprehn: If menuitem set hidden attr, it would never apply
17:04:48 <fantasai> esprehn: The outer one would win, and that breaks all kinds of stuff
17:05:06 <fantasai> esprehn: The hidden attr fails to operate
17:05:30 <esprehn> ::slot div span { }
17:05:33 <fantasai> hober: I thought you said outer author knew more what should happen
17:05:36 <fantasai> esprehn: ...
17:05:39 <esprehn> <span hidden>
17:05:44 <fantasai> esprehn: That would win, andif span had hidden attribute, it would not be hidden
17:05:52 <rune> hober, elliott: you just explained why I'm unsure about option 1 or 2 for style attribute cascading order
17:05:59 <fantasai> esprehn: This was very confusing to authors because widget woudl be trying to hide things, and person from outside would defeat it
17:06:15 <rune> leaning towards option 2 now
17:06:41 <fantasai> rniwa: I think the quesiton is what's the scoping order of attributes vs. rules coming from host and content
17:06:45 <fantasai> rniwa: Is that the question?
17:06:54 <esprehn> [hidden] { display: none; }
17:07:10 <fantasai> esprehn: If we wanted to make that win, that seems complicated
17:07:14 <fantasai> esprehn: Since UA rules are the default
17:07:20 <fantasai> hober: UA normal is the lowest priority
17:08:06 <fantasai> fantasai: You could consider using !improtant to sort
17:08:25 <fantasai> fantasai: e.g. ua rule sare lowest, but ua!important are highest
17:08:41 <fantasai> fantasai: similarly scoped styles, invert !important sorting
17:09:01 <fantasai> esprehn proposes something
17:09:23 <fantasai> rniwa: This seems issue of if I have a ::slotted rule, what is the scope owner of that scope
17:09:34 <fantasai> rniwa: against scope of rules apply on slotted nodes
17:09:37 <fantasai> rniwa: that's coming from teh light
17:09:39 <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
17:09:42 <fantasai> esprehn: This is just host rules
17:09:49 <esprehn> :host(.a) { display: flex; }
17:10:02 <fantasai> hober, !important is for this kind of thing
17:10:16 <fantasai> rniwa: ... what is not clear to me is in case of content
17:10:25 <fantasai> rniwa: Problem is that scoping order is reversed in composed tree
17:10:27 <hober> fantasai: indeed! it's for exceptional cases, not the common case.
17:10:31 <fantasai> rniwa: In composed tree what's got assigned into a slot
17:10:36 <fantasai> rniwa: is coming from outer scop
17:10:43 <hober> s/fantasai:/fantasai,/
17:10:46 <fantasai> rniwa: And then rules that  apply come from outside composed tree
17:10:53 <fantasai> esprehn: In terms of simplified mental model
17:10:57 <fantasai> esprehn: hidden thing, don't do that
17:11:04 <fantasai> esprehn: outer always wins is simplest way to explain this
17:11:20 <fantasai> esprehn: confusion for us is compounded by our scoping impl was broken, exposing th fact that ... ????
17:11:28 <fantasai> esprehn: If shadow dom always have correct ehavior from the start
17:12:15 <sicking> sicking has joined #webapps
17:12:25 <fantasai> fantasai: There's a couple issues I see that I'm not clear what we're talking about
17:12:56 <fantasai> fantasai: First thing is styling stuff in shadow tree... I guess tha'ts not stylable from stuff outside shadow tree, so no conflict there.
17:13:10 <fantasai> fantasai: So the stuff we're talking about is the stuff that's been slotted, is that correct?
17:13:14 <fantasai> rniwa: yes
17:13:15 <Florian> Florian has joined #webapps
17:13:50 <fantasai> fantasai: So in that case, we have rules from the shadow root and stuf from the host element's ancestors
17:13:58 <fantasai> esprehn: It's from your distribution from your composted tree
17:14:13 <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.
17:14:24 <fantasai> fantasai: We have a variety of sources of style
17:14:29 <fantasai> fantasai: One would be style linked from the top of the document
17:14:44 <fantasai> fantasai: another is style from shadow tree, linked or embedded
17:15:10 <fantasai> fantasai: another is scoped style attached to the distributed nodes or their descendants
17:15:12 <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">
17:15:28 <fantasai> fantasai: so the question is what wins over what
17:15:37 <fantasai> fantasai: And proposal currently is what?
17:16:13 <fantasai> We have A) Document styles B) Shadow DOM styles C) Embedded styles
17:16:24 <esprehn> rune: In that example, is it blue?
17:16:27 <fantasai> A < C for sure
17:16:36 <fantasai> but A! > C!
17:16:38 <esprehn> if div had style="color: green" is it still blue?
17:16:38 <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
17:16:48 <fantasai> We have A < C < C! < A!
17:17:04 <rune> where outer normal wins over inner normal
17:17:15 <rune> and inner !important wins over outer !important
17:17:21 <fantasai> slot B into the equation, please?
17:17:56 <dglazkov> example above in http://jsbin.com/fabacu/edit?html,output
17:17:57 <rune> so slotting is what's causing the inner/outer order in the composed tree
17:18:20 <fantasai> yes, but can you make an expression with A, B, C, A!, B!, C!?
17:19:18 <fantasai> <html> <style>A</style> <section> <div><style scoped>B</style>...</div></section>
17:19:37 <fantasai> <shadow-root><style>C</style> <slot distributes div></shadow-root>
17:19:55 <fantasai> shadow-root is attached to <section>
17:20:45 <rniwa> We only have 10min left and we won't be able to finish this
17:20:57 <rniwa> We should figure out how to resolve this.
17:20:58 <rune> I've tried to get attention on www-style before.
17:21:10 <dglazkov> topic for TPAC, continue discussion on www-style
17:21:39 <rniwa> Perhaps we need a joint discussion between CSS WG and WebApps WG.
17:21:40 <fantasai> fantasai: Need to explain clearly the situation, so that people who don't know shadow DOM can contribute
17:22:35 <fantasai> rune: I'm not so familiar with the slot syntax yet
17:22:40 <fantasai> rniwa: I think we should move on from this topic
17:22:54 <fantasai> esprehn: Next thing is inheritance
17:23:05 <fantasai> arronei: Travis and I had a quesiton on inheritance
17:23:12 <fantasai> arronei: Some discussion that helps the story here...
17:23:20 <fantasai> arronei: If we can pound through this really quick, that'd be great
17:23:40 <fantasai> dglazkov: I tried early on turning inheritance off by default
17:23:56 <fantasai> dglazkov: For very simple widgets, you end up writing a ton of stuff
17:24:05 <fantasai> dglazkov: It's certainly a good feature of shadow dom to turn it off
17:24:25 <fantasai> dglazkov: We removed this attribute because CSS has 'all: initial' which does this
17:24:28 <hober> in browsers today, <b><button>hello</button></b> hello is not bold
17:24:38 <fantasai> dglazkov: For closed trees, seems very unlikely you'd want to inherit styles
17:24:49 <fantasai> arronei: Travis and I would prefer to make closed completely closed, you don't get inheritance
17:24:58 <fantasai> hober: I think this is a case where the default shouldn't differ between open and closed
17:25:10 <fantasai> esprehn: That doesn't match the platform
17:25:17 <fantasai> esprehn: font styles inherit into inputs
17:25:23 <fantasai> hober: But text doesn't become bold
17:25:37 <fantasai> fantasai: You can do both, depending on your widget
17:25:44 <fantasai> fantasai: you can say 'all: initial'
17:25:50 <fantasai> fantasai: that blocks everything
17:25:56 <fantasai> fantasai: but you can also selectively say
17:26:05 <fantasai> 'all: initial; font-family: inherit'
17:26:16 <fantasai> esprehn: button example is really good
17:26:36 <fantasai> esprehn: if you put a <b> around  it, it does turn bold, but if you make the text red, it inherits red
17:26:41 <fantasai> esprehn: It's selectively chosen what to inherit
17:26:49 <fantasai> hober: You can argue for either default depending on platform behavior
17:26:56 <fantasai> hober: MS perfers closed to not inherit
17:27:08 <fantasai> hober: I prefer to not differ between open and closed
17:27:17 <fantasai> hober: so sounds like we should have non-inherited by default
17:27:36 <fantasai> rniwa: 'all:initial' would erase the UA stylesheet
17:27:53 <fantasai> rniwa: Could maybe add a new value to all, but ...
17:28:11 <fantasai> hober: I think it's a good idea to add a new value to all
17:28:25 <rniwa> not inheriting by default would work because you can explicitly set "all: inherit"
17:28:42 <fantasai> fantasai: We have a revert value.
17:28:53 <fantasai> fantasai: Are you asking for a revert value that also blocks inheritance?
17:29:19 <esprehn> http://plexode.com/eval3/#s=aekVQXANJVQMbAx14Hw9CAVwBiBsBU0ZFAV4dEJY9T6gdQ1ZVVVBPAXcePQNCtR8pRk1NUAE4UFNNRaWsrrAfqKpysrS2uKgBAautr0+5u72/wcPF1ciqEHLJTwNeAA==
17:29:33 <esprehn> I'm wrong <button> seems to not inherit ever, you have to style it explicitly
17:29:37 <fantasai> fantasai explains revert
17:29:48 <fantasai> http://www.w3.org/TR/css-cascade-4/#default
17:29:56 <fantasai> hober: Wrt attached shadow
17:29:59 <rune> esprehn: regarding your example, yes blue.
17:30:05 <fantasai> hober: I don't think it's necessary to have a special rule
17:30:06 <real_wez> real_wez has joined #webapps
17:30:09 <rune> esprehn: yes, blue
17:30:11 <fantasai> hober: SVG and MathML are kindof weird
17:30:24 <fantasai> hober: If we wanted to say shadow trees only work on HTML elements, that'd be fine by me. I don't care
17:30:35 <fantasai> hober: replaced elements have interesting inrinsic size behavior
17:30:43 <fantasai> hober: Maybe we have an API for interacting with that intrinsic size
17:30:52 <fantasai> hober: But even without it, I don't see any reason not to allow shadow roots on them
17:31:08 <fantasai> hober: Does anyone object to disallowing shadow rootson non-HTML elements?
17:31:18 <fantasai> dglazkov: I don't think it's a bad idea. But need to ask SVGWG
17:31:29 <fantasai> esprehn: It's used in an explanation for what the SVG <use> element does
17:31:39 <fantasai> esprehn: But in terms of what we expose, I think it's fine to not allow it for now
17:31:53 <fantasai> esprehn: Originally there was some disagreement whether you could call attachShadow on an input element
17:31:58 <fantasai> esprehn: Is that okay now?
17:32:06 <fantasai> dglazkov: no, there's a blacklist
17:32:32 <fantasai> dglazkov: Okay, let's continue discussion on www-style
17:32:33 <esprehn> awesome, thanks for all the feedback!
17:32:50 <fantasai> dglazkov: Concrete actions are
17:32:55 <fantasai> dglazkov: ::slotted in the scoping spec
17:33:00 <fantasai> dglazkov: And generally align with v1 Shadow DOM
17:33:03 <fantasai> dglazkov: I'll help you and Tab
17:33:20 <fantasai> dglazkov: and bring you up to speed on the new spec
17:33:28 <fantasai> dglazkov: that's about it
17:33:44 <fantasai> fantasai: And we need to discuss cascading order
17:34:03 <fantasai> dglazkov: I'm more concerned .. this is something we can tweak once we have running code
17:34:06 <fantasai> dglazkov: First part is blocking
17:43:16 <fantasai> RRSAgent: Make Minutes
17:43:16 <RRSAgent> I have made the request to generate http://www.w3.org/2015/09/18-webapps-minutes.html fantasai
17:43:39 <fantasai> RRSAgent: Make logs public
17:43:49 <fantasai> RRSAgent: Make minutes
17:43:49 <RRSAgent> I have made the request to generate http://www.w3.org/2015/09/18-webapps-minutes.html fantasai
17:44:51 <fantasai> s/We have A/fantasai: We have A/
17:45:00 <fantasai> s/A < C/fantasai: A < C/
17:45:16 <fantasai> s/but A!/fantasai: but A!/
17:45:30 <fantasai> s/We have A/fantasai: We have A/
17:45:42 <fantasai> s/slot B into/fantasai: slot B into/
17:45:52 <fantasai> s/yes, but can you/fantasai: yes, but can you/
17:46:15 <fantasai> RRSAgent: make minutes
17:46:15 <RRSAgent> I have made the request to generate http://www.w3.org/2015/09/18-webapps-minutes.html fantasai
17:46:54 <fantasai> s/We have fantasai:/We have/
17:47:01 <fantasai> s/A < C for sure/fantasai: A < C for sure/
17:47:08 <fantasai> RRSAgent: make minutes
17:47:08 <RRSAgent> I have made the request to generate http://www.w3.org/2015/09/18-webapps-minutes.html fantasai
17:47:37 <fantasai> dglazkov: ^
17:48:14 <fantasai> dglazkov: If you want them formatted like the CSSWG minutes, you can ask Tab if he'll pay Dael to do it
17:59:47 <sicking> sicking has joined #webapps
18:10:54 <rniwa> rniwa has joined #webapps
18:22:38 <dgrogan> dgrogan has joined #webapps
18:35:55 <marcosc> marcosc has joined #webapps
18:58:31 <sicking> sicking has joined #webapps
19:15:03 <sicking> sicking has joined #webapps
19:19:54 <rune> rune has left #webapps
20:05:41 <sicking> sicking has joined #webapps
20:47:36 <gavin_> gavin_ has left #webapps
21:01:39 <estellevw> estellevw has joined #webapps
21:14:44 <Florian> Florian has joined #webapps
22:14:47 <dgrogan> dgrogan has joined #webapps
22:15:59 <Florian> Florian has joined #webapps