| 04:47 | <dglazkov> | smaug____: apologies for a (day-long) delay |
| 04:50 | <dglazkov> | when you get a document from XHR, the document that was created will not have a registry associated with it: http://w3c.github.io/webcomponents/spec/custom/#creating-and-passing-registries |
| 04:50 | <smaug____> | right |
| 04:50 | <dglazkov> | when you append such an element to another document, nothing will happen |
| 04:50 | <dglazkov> | unless you import it |
| 04:50 | <smaug____> | meaning, clone into document.. |
| 04:50 | <smaug____> | but ok |
| 04:51 | <dglazkov> | yep |
| 04:51 | <dglazkov> | the element is once-born |
| 04:51 | <smaug____> | I've never understood why registry is for browsing context documents only |
| 04:52 | <dglazkov> | well, it seems bad that you're XHR-ing a doc, and suddenly you get all sorts of JS executed as a result |
| 04:52 | <smaug____> | but I can see that we don't want to change element's behavior when moving it between documents |
| 04:53 | <smaug____> | "suddenly", well you'd need to explicitly register stuff |
| 04:55 | <smaug____> | but not a big deal |
| 04:56 | <smaug____> | (the requirement for browsing context) |
| 04:56 | <dglazkov> | I guess because we don't have registries, another actor on the page could be registering elements. |
| 04:56 | <dglazkov> | FWIW, I really want to pursue registries and the ability to swap them around |
| 04:57 | <dglazkov> | so that you could potentially XHR a doc with a localized set of registered elements |
| 04:58 | <dglazkov> | but we need to learn to walk before flying |
| 04:58 | <dglazkov> | first get everyone agreed on the constructors/is=/upgrade |
| 12:53 | <Ms2ger> | mathiasbynens, ping |
| 15:11 | <mathiasbynens> | Ms2ger: pong |
| 15:11 | <Ms2ger> | Ah, now you're here :) |
| 15:11 | <Ms2ger> | https://github.com/w3c/csswg-test/pull/773 |
| 15:12 | mathiasbynens | checks |
| 15:14 | <mathiasbynens> | Ms2ger: did you have to add any tests that were not in https://github.com/mathiasbynens/CSS.escape/blob/master/tests/tests.js? if so please let me know |
| 15:16 | <Ms2ger> | mathiasbynens, nope |
| 17:45 | <wanderview> | Domenic: do you have examples of eliding ignored-returned-promise optimization being a big win? |
| 18:32 | annevk | finds out IDB doesn't really do tasks |
| 18:35 | <wanderview> | annevk: what do you mean? |
| 18:35 | <annevk> | wanderview: mostly that the specification is bonkers |
| 18:36 | <annevk> | wanderview: in that it doesn't really integrate with the event loop |
| 18:53 | <MikeSmith> | which spec |
| 21:31 | <annevk> | MikeSmith: IDB |
| 21:41 | <annevk> | Domenic: ah, .patch is nice |
| 21:42 | <annevk> | Domenic: now I just need to figure out multiline comments in the Terminal... |
| 21:55 | <MikeSmith> | the HTTP2 spec calls streams "promises"? |
| 22:27 | <TabAtkins> | zcorpan: Any chance you can search for any pages with "@media not" or "media='not", and give me the rest of the MQ? |
| 22:29 | <TabAtkins> | Seeking forward to the { or newline in the first case, and to the matching quote in the other. |
| 22:30 | <TabAtkins> | Wanna do some analysis on whether using Kleene's 3-value truth algebra is backwards compatible, or if we have to do something slightly different. |
| 22:36 | <TabAtkins> | (In particular, the question is whether "false AND unknown" should evaluate to false or unknown. Naively preserving backwards compat demands "unknown", but if the breakage would be minimal or non-existent, evaluating to "false" has more consistent semantics.) |
| 23:00 | <dglazkov> | annevk: what are your thoughts on https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution? |
| 23:00 | <dglazkov> | I posted mine here: https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0208.html |
| 23:13 | <TabAtkins> | While I'm not strongly opposed to a slot-name-based distribution, it's extra ugly work. Requiring people to use an additional attribute/value combo for the declarative syntax, and requiring use of the imperative form to get anything better, just means the declarative form is a ghetto, and for no good reason. |
| 23:13 | <TabAtkins> | Super simple things, like "put an <h1> into your <x-slide>" become much more annoying. :/ |
| 23:14 | <TabAtkins> | I mean, limiting the selectors that can be used is easy-peasy. |
| 23:17 | <dglazkov> | <x-side><h1>should work just fine</h1></x-side>, right? |
| 23:18 | <dglazkov> | oh, you mean the <details><summary> use case. |
| 23:20 | <TabAtkins> | dglazkov: Yeah, the <details> thing is actually pretty common. I wanna be able to write <x-slide><h1>A topic</h1><p>stuff about the topic<p>more stuff</x-slide> |
| 23:21 | <TabAtkins> | And if I have to write <x-slide><h1 content-slot="heading">A topic</h1><p>stuff about the topic<p>more stuff</x-slide> it's like, really? Really?? |
| 23:21 | <dglazkov> | I think we should start a page documenting where the flexibility is lost on the wiki |
| 23:21 | <TabAtkins> | Just screenshot the email thread. ^_^ |
| 23:24 | <TabAtkins> | This sort of syntax just screams "this is bolted-on, and we don't care that it's obvious". |
| 23:26 | <TabAtkins> | But also, reprojection being essentially impossible without explicit coordination sinks this right away imo. |