w/ SR { slot 1, slot 2 } 04:39:58 ... this div also has a direct child 04:40:09 ... and input, input 04:40:24 s/a direct child/two direct children/ 04:40:26 ... input1 in slot 2; input 2 in slot 1 04:40:47 rniwa: so you have an element that reorders light children in the shadow dom using slots. 04:41:02 ... So the question is should we respect the light dom order or the reordering done by the shadow dom? 04:41:27 hayato: I agree using composed tree is a good user experience; but here's a problem. tabindex is not a boolean; it's a number. 04:41:36 minami has joined #webapps 04:41:40 ... it is very difficult to get components to coordinate the indices. 04:41:50 ... imagine a component with a very high tab index? 04:42:19 rniwa: didn't we say using anything with a tabindex > 0 a bad idea anyway? I have a hard time thinking of a use case when the component has a tabindex > 0? 04:42:32 mishizaw has joined #webapps 04:42:38 chaals: The use case is: complex ordering structure. If you scatter elements with CSS, it is helpful to direct the focus order. 04:42:52 ... the reason we recommend people don't use this, is that it is easy to break. 04:43:06 ... but people who use it carefully can get a vastly superior result. 04:43:22 rniwa: What's the use case for reordering in a component? 04:43:28 q+ to talk about date picker 04:43:30 chaals: First, date picker. Date pickers are awful. 04:43:56 The idea than navigating a document in linear order is a good thing collapses when you have a dozen points. 04:44:00 kurosawa_ has joined #webapps 04:44:13 ack next 04:44:14 timeless, you wanted to talk about date picker 04:44:17 I have been taking the images out of shadow DOM, svg, and making them navigable for a screen reader. and it is bat**** insane. 04:44:24 ack 04:44:34 timeless: I have worked on a date picker 04:45:06 kimwooglae has joined #webapps 04:45:07 ... You can have RTL fun and the order stops being the way you expect, you might want to start on the right and exit on the left, but not do the reordering with CSS. 04:45:44 ... or doing really shiny styling, or responding to language changes and doing these sways; I doubt Shadow DOM encourages you to tear down and rebuild the entire tree; you would use CSS and update tabindexes. 04:45:52 ... I think that covers your datepicker nicely. 04:46:06 chaals: I see the problem that can arise but I am not sure of the use case that leads to this probelm. 04:46:29 ... I see they could create a component where the navigation is more sensible; but I don't see how navigation would break. 04:46:34 +1 04:46:51 ... Allowing people to do stupid things is reasonable; it does not seem like a dangerous trap. 04:47:01 ccho4 has joined #webapps 04:47:39 rniwa: I imagine we could treat shadow DOM like iframe; if you specify tabindex inside iframe it is a nested iframe, the scopes are different. We could do something like that. Specify tabindex inside shadow dom and move in that order inside the shadow DOM. 04:47:44 mjs has joined #webapps 04:47:56 timeless: that seems reasonable to understand, I didn't understand the other thing 04:48:05 hayato: that's what's in the current spec 04:48:17 adrianba: Seems important (obvious?) for component reuse. 04:48:35 [ e.g. outbound and return flight dates ] 04:48:35 chaals: One question: Being able to do scoped tab indexing would be really really good for navigation. 04:48:40 s/timeless/scribe/ 04:48:47 mishizaw has joined #webapps 04:49:01 ... In Shadow DOM is great; doing it in general would be great. Dumb, linear, all things navigation is a big failure of the web. 04:49:11 ... Having Shadow DOM allow it is a step. 04:49:17 q? 04:49:21 ... Maybe changing HTML is OT. 04:49:42 kochi: We have another scope of tab ordering. The input element's tab index scope is still the document tree's scope. 04:50:15 (chaals notates the diagram to put tabindex on slots AND inputs) 04:51:00 kochi: Slot itself is not focusable by default. Web authors may think specifying tabindex on slot influences tab navigation but it does not, at least not in Chrome today. 04:51:10 yoichio has joined #webapps 04:51:21 RyutaMiyoshi has joined #webapps 04:51:22 rniwa: I don't understand what the problem is? You want to change the ordering of the tab index in Shadow DOM, based on which slot it is assigned to? 04:51:48 kochi: Specifying tabindex on slot element does not control the order of tab navigation over the slotted input elements. 04:51:50 q+ 04:52:08 ... The input element tab index order is controlled by the input element itself, which is the insertion point. 04:52:50 rniwa: Two qs: Are there use cases where you need to specify tabindex on slot? This is similar to the problem of slot not generating a CSS box. Like that, you could wrap it in a span. 04:53:16 ack next 04:53:22 ... second q, when a node is assigned to a slot, we need to create other nested tab index scope for each slot, it needs to be isolated both from the slot and the shadow dom 04:53:38 ymasao_ has joined #webapps 04:53:46 mjs there are two cases: what if you want to control order in the shadow dom? the nested tab index shadow scope thing is a solution. 04:54:29 ymasao_ has left #webapps 04:54:54 ymasao_ has joined #webapps 04:54:58 ... what if, in this case, if the tab indices are specified or not, both answers--using the tab index in the page might be reordered; if you apply the nested tab index specially you... (missing) there's no way for the consumer to not become dependent on the implementation details of the component. You need to be able to override. 04:55:14 mjs: Say I have a custom element with an input element and a content slot. 04:55:25 ... In its light DOM you have an input element that puts it into the slot. 04:55:37 ... Say they both have an explicit tab index. How do you resolve them? 04:55:41 yosuke has joined #webapps 04:56:09 ... If you apply the nested scope thing, then the abstraction is violated because the consumer has to be aware of tabindices inside the component. 04:56:25 ... On the other hand, if you do it naively the tab index is surprising 04:56:30 ... You need a tab index override. 04:56:40 hfujisawa has joined #webapps 04:56:52 (makes sense to me) 04:56:55 ... I guess rniwa's proposal of having the slot scope tab index will work; slots are not tabbable but you could put a tabindex on it. 04:57:05 ... hopefully I understand the problem- 04:57:23 hayato: that's the problem. Today, current spec, light children are navigated after navigating all elements in the shadow tree. 04:57:38 ... It does not depend on distribution or not. (reiterates spec.) 04:58:04 ... I know this is not ideal but we don't have an idea how to meet the user's expectation which is the composed tree based navigation order. 04:58:13 q+ 04:58:21 q+ 04:58:29 ... ... distribution breaks everything because light children are later in document order. It's a huge unresolved problem. We need to answer this. 04:58:32 ack mjs 04:59:18 jeff has joined #webapps 04:59:32 mjs: this thing (you described) are you suggesting it should work that way, or what the spec says. It's a terrible behaviour when light and shadow DOM have focusable stuff; even if the light and shadow dom author collude they can't get a good result. rniwa's proposal gives control, sensible results, etc. 05:00:00 ... composed tree order is a sensible default but it is not enough, for example, if there's a table. The default order will not be what you want. 05:00:31 ... ... seems to me (rniwa's proposal) gives a clear answer. Realize you don't have to recompute tab cycle every time, you only need to have it when the user tabs. 05:01:06 ... The fact that it interacts with distribution does not matter, when you hit tab you look am I in the shadow tree, have I been distributed into a slot, etc. this seems like a clear answer to the problem. 05:01:12 rniwa: ditto, plus 05:01:41 ... we should solve this by defining tabindex scope at the shadow root boundary and the slot boundary and then it works by always working on the composed tree. 05:01:51 kochi: I'll file a bug with some examples and we can work on updating the spec. 05:01:58 +q 05:02:04 hayato: Nobody has spent much time on this, I welcome work on this, etc. 05:02:22 chaals: likes the proposed solution, it seems to make a lot of sense, have not thought about it carefully 05:02:24 ack next 05:02:32 rniwa: related to focus, selection 05:02:41 ... since I edit that specification it is my interest 05:03:06 ... there's a question whether the user can select across the shadow boundary; what happens when they copy paste? 05:03:10 travis: yes; it should work 05:03:20 hayato: This has been a multiyear problem in blink. yosin? 05:04:07 yosin: Current Blink defines selection in the composed tree. Blink does not support deleting; cut does not work in the shadow tree. Deleting from a composed tree is hard to define. We have no idea what the API surface is, we need a specification. That's the status. 05:04:20 dka has joined #webapps 05:04:22 rniwa: I think the fundamental issue is Shadow DOM is vague about selection. 05:05:06 Hyunjin has joined #webapps 05:05:21 ... Say you have an element with SR and users select from outside the element and stops the selection inside of it. How is that exposed to author scripts? Where should the ending boundary be? Does it contain the element outside the shadow dom or does it point inside the shadow dom, violating encapsulation. Seems bad. 05:05:43 jeff_ has joined #webapps 05:05:43 ... Or does the author know, seeing selection end at the element, know to go inside there and search. 05:05:52 yosin: We need deep anchor node and deep offset. 05:06:24 ... Exposing selection in shadow tree is from shadowRoot.getSelection, limited to shadow tree, a deep version of anchor and focus position would be easier to use for web authors. 05:06:29 rniwa: How is that easier? 05:06:30 sato_yasu has joined #webapps 05:06:49 yosin: Iterating over. We need to provide compare position on composed tree or shadow tree or something. 05:07:00 ... Most operations on selection iterates the nodes. 05:07:14 rniwa: What's the use case of iterating over selection? 05:07:18 ccho4 has joined #webapps 05:07:34 yosin: For caret, authors insert or delete at the caret position. Exposing a node and offset is enough. 05:07:45 ... For ranges, authors want to copy or delete the seleceted range. 05:07:53 ... Then we need to iterate. 05:08:01 rniwa: You are still talking about editing? 05:08:09 ivan_ has joined #webapps 05:08:14 yosin: Yes; and copying serializiation. 05:08:42 rniwa: Why is iteration better? Use a DOM walker and as soon as you hit the end, check if it has a shadow dom you created, and iterate inside of that tree. 05:08:50 kochi has joined #webapps 05:09:11 ... Whereas if all you have is container and deep offset, you need to find a node that is in your dom that is the deep end or start of your container. 05:10:00 ... If you are iterating dom in dom dom dom dom order ... why would you want to go into and modify the shadow dom? when editing it is not because you want to put each paragraph in shadow dom; you might have icons in shadow DOM and want to treat it as atomic. 05:10:13 ... It depends on the use case, etc. 05:10:45 hayato: We should be careful not to expose deep node api because it does not work with closed mode. 05:11:19 yosin: My main application is scoping selection and selecting partial node in shadow tree. copy should serialize selected node and not entire shadow tree or ignore it 05:11:42 atai has joined #webapps 05:11:50 rniwa: There's no specification for serializing selections across shadow tree; and what happens if that happens within contenteditable. 05:12:26 ... It is unclear if ... contenteditable state would not propagate into shadowdom. So if you are trying to delete things it kind of fails because it is in in some sense in a weird rainbow state. 05:12:45 yosin: contenteditable is not well defined, so can we not define something for shadow dom? 05:12:47 ... 05:12:57 just say shadow in contenteditable is not defined 05:13:05 vivien has joined #webapps 05:13:05 chaals: we can; should we? 05:13:33 rniwa: Effectively that is what we have today. Nothing is defined about contenteditable. 05:14:01 ... We could disallow contenteditable at all within shadow DOM for now, just like we disabled mutation events. This is a rare opportunity to disable features we do not like. 05:14:12 rniwa: Do you not like that chaals? 05:14:22 I have made the request to generate http://www.w3.org/2015/10/26-webapps-minutes.html timeless 05:14:38 chaals: It does not make me happy; nobody is happy about contenteditable. Yet people use it. Components can create editors. 05:14:43 rniwa: You could create an iframe. 05:14:55 timeless: Can you put a slot in an iframe? 05:15:03 karl has joined #webapps 05:15:41 rniwa: You could, but it does not do anything because the iframe is a separate document and the slot is in the regular known shadow dom; you can create a shadow dom inside the iframe too... but that is not what you are asking. 05:16:23 ... Should we keep this as an open issue? We should at least have a git hub issue about how selection works and how contenteditable inside shadow dom works. We need something defined before all the browsers can ship. 05:16:42 s/mjs there are two cases/mjs: there are two cases/ 05:16:49 chaals: It is nice to not have things end up in the magic rainbow state; delete should delete things, users will be crazy face 05:17:30 rniwa: When you have a clear user friendly scenario, when you select outside the shadow dom to inside, if the user asks to delete, it is weird to delete the whole shadow dom (and something) 05:17:37 jxck has joined #webapps 05:17:40 ... when a deletion happens, something should happen 05:18:21 chaals: Something should go away. If you delete half way into a table, what goes away? That's not interoperable or well defined; editing people don't trust browsers to do it and they work to specify their own behavior. 05:18:48 ... We could specify "you should delete something" and work it out as part of contenteditable1=tru. 05:19:02 ... We should have an issue and engage editing people for help. 05:19:08 s/tru./true/ 05:19:42 hayato: We have ancient bugs for that, I closed them for lack of recent activity. We are aware of these problems but they are unresolved. There are discussions on the bug. I will reopen the bugs. 05:19:51 rniwa: Let's discuss Custom Elements. 05:20:10 ... We have been prototyping in WebKit. Doing everything synchronous is not that bad. 05:20:48 ... There were a couple of places to fix but it seems better than alternatives like proxies, faking APIs to ignore elements, remove and reinsert, move native properties 05:20:55 ... Those are much, much harder to implement. 05:21:13 ... Do other vendors have experience with this, prototyping other designs? 05:21:59 travis: We have done a bit of exploration; code analysis and thought experiment, not experimentation. Similar results, we think synchronously instantiating during parsing, and that is because we have already paid the tax of running MutationEvents. 05:22:15 ... It might introduce a lot more context switching from parsing to script. I don't see a way around that. 05:22:32 scribe: timeless 05:22:47 chaals: other things? 05:22:51 ... run to half past... 05:23:12 rniwa: there was a request to have ZZZ, eliot from Google couldn't attend TPAC 05:23:15 ko has joined #webapps 05:23:18 ... does anyone have a preferred date? 05:23:22 ... perhaps in two weeks 05:23:26 ccho4 has joined #webapps 05:23:27 s/ZZZ/another meeting/ 05:23:37 ... alternatively first/second week of December 05:23:47 chaals: I have a preference for notice, two weeks is not 05:23:57 ... I'd assume a meeting would be in California 05:24:07 ... if you want Berlin, I could do it sooner, but I doubt you'd want that 05:24:12 Travis: I'd agree w/ chaals 05:24:21 ... the proposal submitted in the email was something we'd already talked about 05:24:25 ... not sure there was new content to discuss 05:24:29 ... not sure there won't be 05:24:35 udo has joined #webapps 05:24:35 ... i'd like to meet again, after the holidays 05:24:38 kbx has joined #webapps 05:24:39 ... perhaps a little further out 05:24:47 ... (January) 05:24:57 chaals: so, late January 05:25:12 QQQ: another F2F in December 05:25:14 ... we could host 05:25:18 ... about Custom Elements 05:25:22 ... there are still incoming proposals 05:25:43 s/QQQ/hayato/ 05:25:43 chaals: Chairs should take an ACTION item to gauge interest 05:26:01 rniwa: when we last had a meeting in the spring, there were open questions of what can be implemented 05:26:17 ... to answer that, people need to prototype or inspect their engines to see what could be implemented 05:26:24 ... i have some confidence that I could get it done before next month 05:26:27 .... Microsoft? 05:26:29 s/.././ 05:26:45 Travis: not sure I can 05:26:58 ... thinking about what's going on next month/next little bit 05:27:08 ACTION chaals to look into next F2F 05:27:09 Created ACTION-759 - Look into next f2f [on Charles McCathie Nevile - due 2015-11-03]. 05:27:29 chaals: do people have more for Custom Element? 05:27:49 Travis: is there any other significant issue in Custom Element other than 05:27:57 rniwa: no other issues 05:28:05 ... creation is the entirety of Custom Elements 05:28:07 yeonsoo_ has joined #webapps 05:28:12 s/other than/other than Creation timing 05:28:31 dcooney: this isn't very controversial, but there's some question of "ancestor-changed" v. in-/out- of document 05:28:44 mjs: not fully resolved last time, besides initial timing of creation 05:28:53 ... question of supporting upgrade/after-the-fact-upgrade 05:28:59 hfujisawa has joined #webapps 05:29:08 ... general consensus was to support it, but not sure how given Constructor() 05:29:15 ... exact timing of RRR 05:29:20 ... not totally resolved 05:29:49 s/RRR/lifecycle callbacks/ 05:30:02 chaals: we'll be back to talk about CSS and Shadow DOM at 3pm 05:30:13 ... I won't be back at 3pm 05:30:24 ... I'd like to thank you all, and especially those who scribed 05:30:30 [ Break until 3pm ] 05:30:36 topic: CSS and Shadow DOM 05:31:30 mhakkinen has joined #webapps 05:32:35 jyasskin has joined #webapps 05:34:13 SamLiu_ has joined #webapps 05:34:47 annbass_ has joined #webapps 05:35:50 hfujisawa has joined #webapps 05:37:34 mhakkinen has joined #webapps 05:38:13 yubo_ has joined #webapps 05:39:57 ats has joined #webapps 05:40:19 clapierre has joined #webapps 05:43:55 ats has joined #webapps 05:44:27 sicking has joined #webapps 05:45:39 mishizaw has joined #webapps 05:48:42 clapierre has joined #webapps 05:50:16 LJWatson has joined #webapps 05:51:18 hfujisawa has joined #webapps 05:51:27 sam_ has joined #webapps 05:51:36 kurosawa_ has joined #webapps 05:53:05 hfujisaw_ has joined #webapps 05:53:52 mjs has joined #webapps 05:55:15 hfujisaw_ has joined #webapps 05:55:22 ymasao has joined #webapps 05:55:28 kimwooglae has joined #webapps 05:57:23 mhakkinen has joined #webapps 05:57:31 rniwa has joined #webapps 05:59:12 CSSWG almost ready to come over 06:00:23 rhiaro_ has left #webapps 06:00:29 dka has joined #webapps 06:01:01 Florian has joined #webapps 06:01:01 adrianba: hopefully 06:01:29 Judy has joined #webapps 06:01:31 za12 has joined #webapps 06:02:10 hfujisawa has joined #webapps 06:02:22 danbri has joined #webapps 06:04:48 hfujisawa has joined #webapps 06:07:34 ymasao has joined #webapps 06:09:33 heh 06:09:53 dom has joined #webapps 06:11:31 ats has joined #webapps 06:11:45 anssik has joined #webapps 06:11:59 oonishi has joined #webapps 06:13:36 kikuchiharuma_ has joined #webapps 06:13:50 RRSAgent, draft minutes 06:13:50 I have made the request to generate http://www.w3.org/2015/10/26-webapps-minutes.html timeless 06:13:57 glazou has joined #webapps 06:14:12 s/heh// 06:14:23 shigeya has joined #webapps 06:14:29 s/adrianba: hopefully// 06:14:30 nulltask has joined #webapps 06:14:42 rniwa: a couple of questions we need to resolve for Shadow DOM before we can implement the feature 06:14:46 https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Shadow-DOM-Cascade-Order-in-v1.md 06:14:47 ... we have a list, we can go through it 06:14:49 ivan_ has joined #webapps 06:14:56 yukio has joined #webapps 06:14:56 ... go through each issue first 06:15:00 TabAtkins has joined #webapps 06:15:13 annbass has joined #webapps 06:15:17 dauwhe has joined #webapps 06:15:19 kochi has joined #webapps 06:15:23 ... first: combinators, and changes to them 06:15:29 ... we don't want deep or shallow combinators 06:15:37 ... rename ::content to ::slotted 06:15:49 ... still have :host and :host-context 06:16:05 Travis: I don't object 06:16:12 rniwa: I think we don't want :host-context 06:16:16 ccho4 has joined #webapps 06:16:19 Travis: :host is a shadow/guide 06:16:28 jyasskin has joined #webapps 06:16:33 mjs: could we have explanations of :host and :host-context 06:16:35 fantasai has joined #webapps 06:16:52 yoichio has joined #webapps 06:17:14 https://public.etherpad-mozilla.org/p/webapps 06:17:24 masayuki has joined #webapps 06:17:27 TabAtkins: I brought up an edit pad 06:17:38 ... I'll draw up an example real quick 06:17:44 annbass has left #webapps 06:17:47 Bert1 has joined #webapps 06:17:49 dbaron has joined #webapps 06:17:52 myles has joined #webapps 06:18:02 nsakai has joined #webapps 06:18:03 [ tab draws ] 06:18:12 leaverou has joined #webapps 06:18:18 [ adrianba increases the font size ] 06:18:21 fwtnb has joined #webapps 06:18:28 TabAtkins: if you're inside the shadow 06:18:40 ... as this style is, and you try to have a my-component selector 06:18:45 MaRakow has joined #webapps 06:19:05 ... this component, this div, this style 06:19:09 Tab draws: 06:19:09 <::shadow> 06:19:09 06:19:12 06:19:14

foo

06:19:16 06:19:32 ... if you take my-component, it won't set on this (the my-component) 06:19:39 er, now it's: 06:19:40 <--------- 06:19:40 <::shadow> 06:19:40 06:19:44

foo

06:19:46 06:19:48 06:19:49 ... from inside the shadow root, styles can only see other things inside the shadow root 06:19:53 AndreyR_ has joined #webapps 06:19:57 q? 06:20:07 ... the other stuff outside is in control of the user, not the shadow author 06:20:14 dyamada has joined #webapps 06:20:16 ... you do still sometimes want to be able to style your host element 06:20:21 ... to say make it a flex-box 06:20:27 ... that's what :host is for 06:20:34 ... :host-context is a little different 06:20:50 clapierre1 has joined #webapps 06:20:52 ... say you want to style things based on whether your anchor is class="light-theme" 06:21:02 ... you can't do `.light-theme div {...}` 06:21:18 ... you could do `:host(.light-theme) div {...}` this would only match the host if it matches 06:21:27 ... it's a function() because ... 06:21:31 minami has joined #webapps 06:21:42 ... :host.light-theme doesn't work, because .light-theme doesn't work 06:21:51 kawai has joined #webapps 06:21:52 ... removing a simple selector from a compound selector will never select "less" 06:21:58 ... by CSS Selectors definition 06:22:02 RyutaMiyoshi has joined #webapps 06:22:14 ... things with more selections must select not more than the other, it's more specific 06:22:18 ... it can't be a wider match 06:22:22 yosin has joined #webapps 06:22:30 ... .light-theme div #2 -- doesn't match anything 06:22:41 ... then :host.light-theme div #1 -- can't match more than #2 06:22:52 ... it's more specific, it can't match less 06:22:55 Rossen has joined #webapps 06:22:59 ... you can't select less than 0 06:23:14 ... so we have to use a function argument -- :host(.light-theme) div ... 06:23:37 DZZ: what does :host { color: red } do ? 06:23:43 s/DZZ/dino/ 06:23:50 TabAtkins: it selects the host object () and sets the color property to red 06:23:59 ... a more reasonable example is :host { display: flex } 06:24:09 ... because you need to use flex-box layout 06:24:18 ... does that sufficiently clarify functional host? 06:24:43 mjs: additional question, when you use the descendant selector, what does it select 06:24:49 TabAtkins: PPP 06:25:06 mjs: :host selects the host element, but if you select a descendant, it only selects things in the shadow 06:25:09 ymasao has joined #webapps 06:25:25 TabAtkins: yes, for the purpose of selectors, :host selects two things, the host, and the shadow dom, descendants select inside only 06:25:28 ko has joined #webapps 06:25:32 leaverou: why not a psuedo element? 06:25:53 ... there's a flaw that :host is a UUU and not a psuedo 06:26:05 TabAtkins: the reason it wasn't a pseudo is that it does exist 06:26:17 MMM: the projection exists, but the object doesn't exist 06:26:24 TabAtkins: but i'm styling the real element 06:26:25 s/MMM/ChrisLilley/ 06:26:34 leaverou: if you can't select it with * then ... 06:26:40 TabAtkins: no... 06:26:47 mjs: * would select everything except it 06:26:56 TabAtkins: * is not everything, it's all tag names in this tree 06:27:00 leaverou: any other examples? 06:27:03 TabAtkins: no, this is the first one 06:27:08 q? 06:27:26 NNN: do you agree *:host is equivalent to :host ? 06:27:27 hellojintae has joined #webapps 06:27:32 TabAtkins: it is not 06:27:35 garykac has joined #webapps 06:27:37 hjlee has joined #webapps 06:27:41 ... if you wrote * { color: grey} 06:27:44 s/NNN/SimonSapin/ 06:27:47 ... it selects every element in the shadow tree 06:28:03 SimonSapin: same as ... 06:28:04 q+ 06:28:16 q+ 06:28:20 TabAtkins: *:host is bad, it won't select anything 06:28:36 SimonSapin: defining this way is inconsistent, as with 1/2 06:28:43 TabAtkins: 1/2 both match nothing 06:29:22 mjs: point w/ *, every other psuedo class, *:whatever is exactly equivalent to :whatever 06:29:28 ... but for pseudo elements, that isn't the case 06:29:31 We had a similar discussion https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0295.html 06:29:32 q+ 06:29:37 ... although :host sort of refers to a real element, it sort of doesn't 06:29:49 ... descendant refers to something after refers to something it wouldn't normally would 06:30:04 ... the fact that it's weird kind of makes it a psuedo element 06:30:14 ack mjs 06:30:21 TabAtkins: it wouldn't be inconsistent, but i felt it leaned heavier to this style 06:30:22 sato has joined #webapps 06:30:37 hober: all selectors for forever have been scoped to a tree, we didn't know that because there was only one tree 06:30:38 plinss has joined #webapps 06:30:40 ... now we have more than one tree 06:30:47 ... :host projects from one tree to another 06:30:55 tfuji has joined #webapps 06:30:56 ... it's true it's inconsistent, but we're doing something before 06:31:05 ... but this entire argument is `:` or `::` and i don't care 06:31:18 TabAtkins: if you are ok w/ a full selector after a psuedo element? 06:31:22 ... then I'm ok 06:32:16 tantek has joined #webapps 06:32:18 dbaron: I just want 06:32:44