/irc-logs / w3c / #webapps / 2015-09-18 / end

Options:

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

Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn