| 01:35 | <JakeA> | terinjokes: which tweet? |
| 05:02 | <annevk> | TabAtkins: for stuff like Encoding it still says "16 September 2014. CR." |
| 05:25 | <rniwa> | annevk: hi annevk! |
| 05:25 | <rniwa> | annevk: back in London? |
| 05:26 | <annevk> | rniwa: I'm based in Switzerland these days, but yeah :-) |
| 05:26 | <annevk> | rniwa: haven't read the latest batch of emails yet |
| 05:28 | <annevk> | rniwa: re superclass/subclass list, it seems only 3 has API implications |
| 05:29 | <annevk> | rniwa: well, 1/2 need some consideration as well, e.g. how to replace the shadow tree |
| 05:34 | <rniwa> | annevk: ah, okay. |
| 05:34 | <botie> | ah, okay. is there a spec out for it, or has it just been discussed? |
| 05:34 | <annevk> | rniwa: hmm and seems the other thread didn't progress much |
| 05:34 | <rniwa> | annevk: so i think replacing an existing shadow root is probably best done by attaching a new shadow root. |
| 05:35 | <rniwa> | annevk: yeah.. |
| 05:35 | <rniwa> | annevk: I'm meeting with dglazkov tomorrow to discuss it |
| 05:35 | <annevk> | rniwa: and not forwarding anything? |
| 05:35 | <rniwa> | annevk: right |
| 05:35 | <rniwa> | annevk: i think the simplest one is to simply detach the old one |
| 05:36 | <annevk> | sure, if you can detach and add that works too |
| 05:36 | <rniwa> | annevk: but that may have some weird implications like offsetTop, etc... being broken inside superclasss |
| 05:36 | <annevk> | though it's a bit unclear how that works with closed/isolated |
| 05:36 | <rniwa> | annevk: right. |
| 05:36 | <rniwa> | annevk: I'm not certain if it makes sense to support inheritance in isolated case though |
| 05:37 | <rniwa> | annevk: I can't think of a use case in which you want to do an inhertiance between mutually distrusting parties |
| 05:37 | <annevk> | rniwa: I think the only reasonable option for the API btw is my gist + nanotask mutation observers, unless we come up with something completely novel |
| 05:37 | <rniwa> | annevk: well, i think there are different trade offs as i outlined in the md/thread |
| 05:37 | <rniwa> | annevk: btw, https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Imperative-API-for-Node-Distribution-in-Shadow-DOM.md |
| 05:37 | <annevk> | rniwa: that md is quite confusing |
| 05:38 | <rniwa> | annevk: what i'm saying that there are two basic approaches to the problem |
| 05:38 | <rniwa> | one is what you described in your gist |
| 05:38 | <rniwa> | which is what we discussed at dinner |
| 05:38 | <rniwa> | annevk: we natively support redistributions |
| 05:38 | <rniwa> | annevk: what I then realized is that we don't really have a need for *selective* redistributions in nested shadow DOM case |
| 05:39 | <annevk> | if you don't it starts mattering where you put your host element though, right? |
| 05:39 | <rniwa> | annevk: what do you mean by that? |
| 05:39 | <annevk> | if redistribution is not a feature, your component may not work if someone put it inside a shadow tree |
| 05:40 | <rniwa> | annevk: it'll work just fine |
| 05:40 | <rniwa> | annevk: only thing we can't do is selecting distributed nodes using a different criteria than the one insertion point used |
| 05:40 | <annevk> | rniwa: hmm, I need some IDL for that proposal |
| 05:40 | <rniwa> | annevk: say you have <content select="blah"> in your shadow DOM |
| 05:41 | <rniwa> | annevk: we need redistribution only if you wanted to re-distribute a strict subset that's not identically equal to the set of nodes distributed to that content eleemnt |
| 05:41 | <rniwa> | annevk: if you either always redistribute everything <content select="blah"> got or none, then we don't need redistribution mechanism |
| 05:42 | <rniwa> | annevk: you just redistribute the entire content element or don't do it at all. |
| 05:44 | <rniwa> | (now i do see that we might be digging a rabbit hole if we went with more sync API that doesn't natively support redistribution because it's like we're re-introducing mutation events in some way, and some frameworks might decide to implement the full redistribution algorithm anyway, which will be horrific. furthermore, requiring sync redistribution might be an anti-pattern to begin with... it's like interleaving offsetLeft access with DOM mutations...) |
| 05:45 | <annevk> | I think distribution will have to be sync either way |
| 05:45 | <rniwa> | annevk: you mean propagating redistributions? |
| 05:47 | <annevk> | So in #1 you'd just observe the children of the host element, enumerate them and then distribute them |
| 05:48 | <annevk> | I just don't see how you don't always need to observe the <content> element... |
| 05:49 | <annevk> | E.g. if in your shadow tree you have <host><content select="header, content, footer"/></host> or some such |
| 05:49 | <annevk> | I guess you could split up the <content> elements, but then we'd be dictating API |
| 05:50 | <rniwa> | annevk: right, i think the way you'd do it is to split content elements. |
| 05:50 | <rniwa> | annevk: in the world of named slots, that's what you'd do |
| 05:50 | <rniwa> | annevk: and libraries/frameworks could add a sugar on top of it |
| 05:50 | <rniwa> | annevk: if we didn't need redistributions, it dramatically simplifies a lot of things. |
| 05:51 | <rniwa> | annevk: it's worth considering it. |
| 05:52 | <annevk> | well I'm not quite sure why we don't need it |
| 05:52 | <annevk> | how do we know what <content> element to pick? |
| 05:53 | <annevk> | that is, how does "redistribute everything" work, as you call it |
| 05:53 | <rniwa> | annevk: you pick whichever content element that fits your criteria |
| 05:54 | <rniwa> | annevk: in the case of <host><content select="header, content, footer"/></host> |
| 05:54 | <rniwa> | you know that <host> needs header, content, and footer, so you just define those |
| 05:54 | <rniwa> | e.g. |
| 05:54 | <rniwa> | <host><content class="header" select=".header header"/><content class="content" select=".content content"/><content class="footer" select=". footer footer"/></host> |
| 05:55 | <rniwa> | annevk: conceptually, <host> grabs header, content, footer, right? |
| 05:55 | <rniwa> | annevk: so in order to use that element, you have to supply those elements. |
| 05:55 | <rniwa> | annevk: it doesn't matter whether what you have is a content element or a regular element |
| 05:56 | <annevk> | hmm |
| 05:56 | <rniwa> | i certainly wouldn't argue this is more developer friendly but there's a lot of appeal for the simplicity |
| 05:57 | <rniwa> | it's deadly clear what one has to do to use an element |
| 05:58 | <annevk> | Does this also mean <content> elements no longer have to be descendants? |
| 05:58 | <annevk> | I guess there never was that restriction |
| 05:58 | <rniwa> | annevk: what do you mean by that? |
| 05:58 | <annevk> | Never mind, I was confused |
| 05:58 | <rniwa> | annevk: so the nice thing about this model is that we no longer need to propagate anything from one shadow DOM to another |
| 05:59 | <rniwa> | you just distribute per shadow DOM and done! |
| 05:59 | <annevk> | And authors will have to monitor DOM + <content> and distribute based on that? |
| 06:00 | <annevk> | What's also somewhat worse about this is that there's no explicit opt-in so the switch to purely declarative has to be different |
| 06:02 | <rniwa> | annevk: why would you monitor content element? |
| 06:02 | <annevk> | for redistribution? |
| 06:03 | <rniwa> | annevk: but why would you need redistribution for? |
| 06:03 | <rniwa> | annevk: if you did <host><content class="header" select=".header header"/><content class="content" select=".content content"/><content class="footer" select=". footer footer"/></host> |
| 06:04 | <rniwa> | it'll distribute just as well as <host><header>~</header><main class="content"></main><footer></footer></host> |
| 06:04 | <annevk> | <host><'shadow'> text <div><content/></div> <host2><content/></host2> </'shadow'></host> |
| 06:04 | <rniwa> | annevk: so you don't need to inspect content element at all. just distribute a content element like any other element and you'll be fine |
| 06:05 | <annevk> | <host2>'s shadow will have to monitor changes to <host2>'s <content> child |
| 06:05 | <rniwa> | annevk: how does host2 distribute nodes? |
| 06:05 | <rniwa> | annevk: i.e. what are insertion points and their criteria for selecting nodes? |
| 06:05 | <annevk> | rniwa: that's up to <host2> |
| 06:06 | <rniwa> | annevk: well, we need to know in order for this model to work. |
| 06:06 | <rniwa> | annevk: in the world without redistributions, you need to be deadly aware of what gets used by each custom element |
| 06:06 | <rniwa> | annevk: and supply those explicitly |
| 06:07 | <rniwa> | annevk: so if host2 needs a header and footer, then you have to define content elements yourself and supply those |
| 06:07 | <annevk> | and the browser magically knows what nodes are linked? |
| 06:07 | <rniwa> | annevk: we don't have to |
| 06:07 | <rniwa> | annevk: author will create <content> elements as needed for host2 |
| 06:08 | <rniwa> | annevk: so all we need to do in the first shadow DOM is to grab contents into each content element |
| 06:08 | <annevk> | how will those elements end up correctly within host2's shadow though? |
| 06:08 | <rniwa> | annevk: host2 then come in and grab those content elements in turn |
| 06:08 | <annevk> | doesn't it have to monitor changes for that? |
| 06:08 | <rniwa> | annevk: because content elements in host1 will themselves be distributed into insertion points inside host2 |
| 06:09 | <rniwa> | annevk: not really, it just needs to monitor direct children of <host2> which are <content> elements |
| 06:09 | <rniwa> | annevk: <host2> will grab each <content> element into its own insertion points as they fit their criteria |
| 06:10 | <annevk> | rniwa: I don't really follow how this actually works I think |
| 06:10 | <rniwa> | annevk: okay |
| 06:10 | <annevk> | rniwa: how does it grab, based on what? |
| 06:10 | <annevk> | rniwa: and what does the browser need to monitor? |
| 06:10 | <rniwa> | annevk: the browser only monitors direct child of <host1> and <host2> |
| 06:10 | <annevk> | rniwa: it seems like the md could use some additional text to explain this |
| 06:11 | <rniwa> | annevk: yeah... indeed |
| 06:11 | <rniwa> | i guess this idea isn't clear as it is to me... |
| 06:12 | <rniwa> | annevk: first, <host1> decides to distribute nodes into its own insertion points including ones that are under <host2> |
| 06:12 | <rniwa> | annevk: <host2> some time later or earlier will distribute its direct children into its own insertion points |
| 06:12 | <annevk> | right, all <content> in <host1>'s shadow are its insertion point |
| 06:12 | <rniwa> | it just so happens that <host2>'s direct children are <content> of <host1> |
| 06:13 | <annevk> | oh right |
| 06:13 | <rniwa> | annevk: because <host2> distributed <content> elements in <host1>'s shadow DOM into its insertion points |
| 06:13 | <annevk> | you don't distribute children of <content>, you distribute <content> |
| 06:13 | <annevk> | okay I see now |
| 06:13 | <rniwa> | annevk: right! |
| 06:14 | <rniwa> | sorry, i'm not great at explaining these things :( |
| 06:14 | <annevk> | I wonder if that's problematic for components that are almost the entire page |
| 06:14 | <annevk> | You might get to a point where there's too much <content> elements, but I guess it's worth studying what is out there |
| 06:15 | <rniwa> | annevk: yeah, that's one problem I can see as well |
| 06:15 | <rniwa> | annevk: but the model is so much simpler it's quite appealing. |
| 06:15 | <rniwa> | annevk: if anything, frameworks can (or we can) add some sugars to make things easier. |
| 06:16 | <annevk> | we have those components in Firefox OS |
| 06:16 | <rniwa> | annevk: ? |
| 06:17 | <rniwa> | annevk: it would certainly be useful if you can point to a use case in which this model breaks down. |
| 06:19 | <annevk> | rniwa: would have to ask Wilson, I'm not super familiar |
| 06:19 | <rniwa> | annevk: okay |
| 06:19 | <annevk> | rniwa: but now I understand it that'll be easier |
| 06:19 | <rniwa> | annevk: okay |
| 06:19 | <rniwa> | annevk: please feel free to edit / add comment to markdown file |
| 06:20 | <rniwa> | annevk: i'm sure you can do a better job of explaining it at this point. |
| 06:20 | <rniwa> | or at least point out parts that are confusing |
| 06:37 | <annevk> | rniwa: yeah, I'll try to provide a PR |
| 06:37 | <annevk> | I want to update #2 too |
| 06:37 | <rniwa> | annevk: ok |
| 06:43 | annevk | wonders if anyone knows the full name of https://github.com/davidsgrogan |
| 06:46 | <rniwa> | annevk: you mean his IRC nick? |
| 06:46 | <annevk> | rniwa: I need to add him to the Acknowledgments section |
| 06:46 | <rniwa> | annevk: David Grogan |
| 06:46 | <annevk> | thanks |
| 06:48 | <annevk> | rniwa: btw, with respect to extensions to custom elements |
| 06:49 | <annevk> | rniwa: I think my preference would be "nanotask" mutation observers; mutation observers that fire after a method has returned |
| 06:49 | <annevk> | rniwa: e.g. appendChild(obj); /* fire mutation observers for appending (and potentially removing if obj was elsewhere in the tree) */ |
| 06:50 | <annevk> | rniwa: but as a general extension to mutation observers rather than something specific for custom elements |
| 06:50 | <rniwa> | annevk: oh i see |
| 06:51 | <rniwa> | annevk: yeah, i think extending mutation observers will be better than adding an ad-hoc custom only callback mechanism |
| 06:52 | <annevk> | rniwa: I guess I can add that as alternative too |
| 06:52 | <annevk> | if we want to keep all proposals in this md |
| 06:52 | <rniwa> | annevk: there's a section about adding a callback |
| 06:53 | <rniwa> | annevk: to custom elements so you probably want to add there |
| 06:53 | <annevk> | yeah there's Extention to Custom Elements for Consistency with 1/2 |
| 06:53 | <rniwa> | annevk: right |
| 06:53 | <annevk> | but this is really an alternative to that whole section |
| 06:53 | <annevk> | but I could rename the section and make it work |
| 06:54 | <rniwa> | annevk: whichever you'd prefer |
| 07:09 | <annevk> | rniwa: still awake? |
| 07:09 | <annevk> | rniwa: rewriting now... what did you mean with "of the shadow host of the ancestor shadow root of containt or if index is larger than the length of distributedNodes"? |
| 07:09 | <rniwa> | annevk: yeah, debugging some editing bug as we speak |
| 07:09 | <annevk> | rniwa: containt -> content? |
| 07:09 | <rniwa> | annevk: yeah, right. |
| 07:10 | <rniwa> | annevk: what I meant is that a node can only be distributed to an insertion point which exists in a shadow DOM of its ancestor |
| 07:10 | <annevk> | not parent? |
| 07:10 | <rniwa> | annevk: or shadow DOMs inside of them |
| 07:11 | <annevk> | "of the shadow host of the ancestor shadow root" should that be /or/ the ancestor...? |
| 07:11 | <rniwa> | annevk: oh, i wanted to be permissive because there was a use case like table-chart element where being able to distribute non-direct child is desirable |
| 07:12 | <rniwa> | annevk: well, things need to be backwards in this case |
| 07:13 | <rniwa> | annevk: for a given node to be distributable to a an insertion point |
| 07:13 | <rniwa> | the shadow root of that insertion point needs to be an ancestor of the node to be distributed |
| 07:13 | <rniwa> | annevk: maybe you can just remove that whole sentence and rewrite it |
| 07:14 | <rniwa> | annevk: it's probably better to say just that instead of what's in the md |
| 07:40 | <annevk> | rniwa: https://github.com/w3c/webcomponents/pull/45 |
| 07:41 | <annevk> | rniwa: you can view it at https://github.com/annevk/webcomponents/blob/patch-1/proposals/Imperative-API-for-Node-Distribution-in-Shadow-DOM.md for now |
| 07:43 | <annevk> | dglazkov: if you're still awake ^^ |
| 07:47 | <rniwa> | annevk: thanks! |
| 07:48 | <rniwa> | annevk: dglazkov is a morning person as far as I know. |
| 07:48 | <annevk> | having kids does that to you |
| 07:48 | rniwa | is definitely not a morning person |
| 07:48 | <rniwa> | annevk: that might be reason for me not to have kids.. |
| 07:49 | <rniwa> | annevk: merged! |
| 07:50 | <rniwa> | annevk: wow, what happened to the table-chart example |
| 07:51 | <annevk> | rniwa: that was already like that |
| 07:51 | <rniwa> | :( |
| 07:51 | rniwa | fixes |
| 07:51 | <annevk> | rniwa: something happened to the Unicode when you copied it... |
| 07:54 | <rniwa> | annevk: https://github.com/w3c/webcomponents/pull/46 |
| 07:55 | <annevk> | rniwa: looks good but I can't merge |
| 07:57 | <annevk> | TabAtkins: I guess I should do that internal links thing... using spec=html makes origin point to concept-url-origin, which is really a term from URL that HTML happens to import |
| 07:57 | <rniwa> | annevk: oh you don't have write access? |
| 07:57 | <annevk> | rniwa: nope |
| 07:59 | <rniwa> | MikeSmith: could you add annevk to https://github.com/orgs/w3c/teams/webapps ? |
| 08:20 | <MikeSmith> | rniwa: yeah will do right now |
| 08:22 | <MikeSmith> | ใงใใ rniwa |
| 08:25 | <rniwa> | MikeSmith: thanks |
| 08:25 | <rniwa> | annevk: ^ |
| 08:29 | <rniwa> | sorry, gtg sleep now :( |
| 08:29 | <rniwa> | ttyl guys all! |
| 09:25 | <annevk> | nn |
| 09:26 | <annevk> | thanks MikeSmith |
| 09:26 | <MikeSmith> | cheers |
| 10:57 | <annevk> | https://storage.spec.whatwg.org/ |
| 11:00 | <annevk> | It seems I need to read the Bikeshed docs another time to figure out linking from IDL to definitions... |
| 11:01 | <annevk> | philipj: while setting that up I was reminded that mediasession probably wants a Twitter account too |
| 14:35 | <annevk_> | TabAtkins: you around? |
| 14:35 | <annevk> | TabAtkins: I get "No 'functionish' refs found for 'stringification behavior'." |
| 14:36 | <annevk> | TabAtkins: which seems to be due to <a dfn for=Range lt="stringification behavior">toString()</a> which is due to the () at the end of toString which seems weird as it uses lt="" |
| 14:36 | <annevk> | TabAtkins: what is happening? |
| 14:37 | <wanderview> | Domenic: so, first glance result from this system benchmark is that async-read is roughly equivalent to sync-read+ready-promise... except when the browser is under memory pressure... then the sync-read+ready-promise pulls away... I'm not sure how I feel about that yet |
| 14:43 | <TabAtkins> | annevk: I fixed that in Bikeshed. |
| 14:43 | <TabAtkins> | annevk: Before sending you the PR. ^_^ |
| 14:44 | <annevk> | TabAtkins: I see |
| 14:45 | <TabAtkins> | (In one particular place, it was accidentally falling through to doing text-based link-type identification, so it was trying to interpret that link as a functionish type, but still linking with "stringification behavior". |
| 14:45 | <TabAtkins> | ) |
| 14:46 | <TabAtkins> | annevk: Oh, yeah, about origin, use <pre class=anchors> to point the term "origin" to the url spec. |
| 14:46 | <annevk> | no I want HTML's origin |
| 14:46 | <annevk> | but not HTML's reference to URL's origin |
| 14:47 | <TabAtkins> | Then use <pre class=anchors> to point the term "origin" to the html spec. |
| 14:48 | <TabAtkins> | HTML is hell to link to at the moment, and that's... probably not going to get much better. At least, as I said yesterday, I'm going to add a way to fix common terms from it. |
| 14:48 | <annevk> | TabAtkins: I updated Bikeshed and I still get that error |
| 14:49 | <TabAtkins> | ...goddammit, I didn't push last night. Sorry, the fix is still on my work comp. I'll push in an hour or two when I get into the office. |
| 14:49 | <TabAtkins> | That's dumb of me, sorry. |
| 14:49 | <TabAtkins> | The error isn't serious, you can force-generate for now. That particular link won't autolink until you get the fix, is all, but it's just a thing from the DOM2 changes section. |
| 14:50 | <annevk> | TabAtkins: bikeshed -f says there's too few arguments |
| 14:50 | <annevk> | same for --force |
| 14:51 | <annevk> | or --force-generate |
| 14:51 | <TabAtkins> | Yup, need to specify the command if you're using flags, because argparse is dumb and I hate it. |
| 14:51 | <TabAtkins> | `bikeshed -f spec` |
| 14:51 | <annevk> | I have no words |
| 14:51 | <TabAtkins> | I do a cheaty hack around argparse's refusal to support a default command. |
| 14:51 | <TabAtkins> | But it doesn't work if you pass any flags. |
| 14:51 | <TabAtkins> | You should see argparse's bug if you pass a flag with a space in its value! |
| 14:52 | <TabAtkins> | (It assumes that you're giving the first positional argument instead; in this case, the input filename.) |
| 14:53 | <TabAtkins> | In case it isn't clear, `spec` is the literal command, not a variable I'm asking you to fill in. Bikeshed's `spec` command is the one that actually generates a spec. |
| 14:54 | <annevk> | Thanks TabAtkins |
| 14:55 | <TabAtkins> | And thank you for bearing with the rocky introduction of whatwg specs into Bikeshed. Every new spec finds bugs no previous spec poked at, and as WHATWG specs get bikeshedded and put into Shepherd, Bikeshedding them will be easier (because all the autolinks will work). |
| 14:56 | <annevk> | Yeah, looking forward to that |
| 14:56 | <annevk> | I noticed WebIDL does not link to HTTPS |
| 14:56 | <annevk> | which I thought was something we fixed |
| 14:56 | <TabAtkins> | That's all SpecRef bugs. :/ |
| 15:01 | <annevk> | TabAtkins: the duplicate selectors4 / selectors-4 is too? |
| 15:01 | <TabAtkins> | Yeah, but I'll be fixing that today or Monday. Got a PR almost ready to go. |
| 15:01 | <TabAtkins> | Went through and put together a bunch of aliases for all the CSS specs that aren't already named correctly. |
| 15:20 | <annevk> | Alright, sounds good |
| 15:20 | <annevk> | TabAtkins: I wrote https://storage.spec.whatwg.org/ in Bikeshed without too much effort |
| 15:20 | <annevk> | TabAtkins: first thing I wrote from scratch |
| 15:21 | <annevk> | TabAtkins: I got the IDL stuff wrong, but otherwise it mostly seems okay |
| 15:37 | <TabAtkins> | What'd you get wrong? I desperately need to improve the docs/help around IDL stuff, and would like to know your errors. |
| 15:54 | <annevk> | TabAtkins: I thought it would just automatically pick up that I was defining something from the IDL |
| 15:55 | <annevk> | TabAtkins: but instead it created two definitions |
| 16:03 | <TabAtkins> | annevk: How'd you initially mark up the second definition? It does automatically pick it up if you give it enough information for it to know you're defining the term elsewhere. |
| 16:03 | <annevk> | TabAtkins: <dfn><code>requestPersistent()</code></dfn> |
| 16:04 | <TabAtkins> | Yeah, you need to tell it it's a method, and of what interface. |
| 16:05 | <TabAtkins> | Writing this down, though, for a possible helpful warning in the future. |
| 16:06 | <TabAtkins> | (In general, definitions need to be given a type; the default type is "dfn", which is for general terms and such.) |
| 16:09 | <TabAtkins> | I also need to put together a "10 things you need to know to use Bikeshed effectively" thing, so you don't have to read the whole docs to get the basic usage info. |
| 16:10 | <annevk> | TabAtkins: the other thing I noticed was that while I like to link to /multipage/, Bikeshed's IDL autolinking prefers / for html.spec.whatwg.org |
| 16:10 | <annevk> | TabAtkins: same for SpecRef |
| 16:11 | <TabAtkins> | annevk: For SpecRef you can just give a PR to change the reference. |
| 16:11 | <annevk> | TabAtkins: / seems hostile to everyone on a slow computer or on slow bandwidth |
| 16:11 | <annevk> | okay |
| 16:11 | <TabAtkins> | For Bikeshed, that's an artifact of Shepherd; I'm not sure how to handle a spec spread across multiple pages. I'll talk to plinss about it, see if we can fix things. |
| 16:11 | <TabAtkins> | And yes, single-page is very hostile. |
| 16:12 | <TabAtkins> | I only load it when I need to ctrl-F for something, and I can't just guess the ID. |
| 16:23 | <annevk> | TabAtkins: https://github.com/tobie/specref/pull/183 |
| 16:24 | <TabAtkins> | Nice. |
| 16:26 | <TabAtkins> | annevk: Oh yeah, and I pushed the Bikeshed fixes from last night, so you should build clean now. |
| 16:26 | <dglazkov> | arrow functions are so cute |
| 16:27 | <annevk> | dglazkov: agreed, I like how they make complex things a lot easier to grasp |
| 16:29 | <dglazkov> | maybe this whole Javascript thing has legs after all |
| 16:29 | <annevk> | dglazkov: don't tell Lars |
| 16:30 | <dglazkov> | :-P |
| 16:32 | annevk | is trying to parse https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0473.html by rniwa and not succeeding |
| 16:34 | <philipj> | TabAtkins: I noticed some differences in references when building locally with Bikeshed and using https://api.csswg.org/bikeshed/ |
| 16:35 | <philipj> | Would that be because Bikeshed itself was at different versions, or is there a separate step to update the SpecRef database? |
| 16:38 | <annevk> | philipj: you need to run bikeshed update |
| 16:39 | <annevk> | philipj: that should update the databases locally |
| 16:41 | <Ms2ger> | "ExtendableEvent"? |
| 16:41 | <wanderview> | Ms2ger: from ServiceWorker spec |
| 16:41 | <annevk> | not the greatest name in the world |
| 16:41 | <wanderview> | https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#extendable-event |
| 16:42 | <wanderview> | basically a waitUntil() method |
| 16:43 | <philipj> | annevk: ok, thanks :) |
| 16:43 | <philipj> | annevk: unfortunately @mediasession is already taken on twitter |
| 16:46 | <Ms2ger> | Wow, those headers are way too big |
| 16:47 | <Ms2ger> | ... And now they're not |
| 16:48 | <annevk> | Ms2ger: I think that page uses Polymer, it's rather flaky |
| 16:48 | <annevk> | philipj: mediasessionapi too long? |
| 16:48 | <Ms2ger> | Well that's insane |
| 16:48 | <Domenic> | @mediasessions |
| 16:50 | <philipj> | annevk: would work, but the spec doesn't have an API yet :) |
| 16:50 | <philipj> | I guess I'll wait to discuss it with rich, since it's so half-baked that we don't really want to attract attention yet |
| 16:51 | <annevk> | philipj: btw, did you notice that on iOS if you play a podcast from Safari, it doesn't stop when you quit Safari? |
| 16:51 | <annevk> | philipj: browsers could do a lot here by just improving their default heuristics |
| 16:52 | <philipj> | annevk: yeah, we've looked a lot at the existing behavior in various browsers, and in fact step one of our roadmap is to improve the default behavior without adding anything Web-exposed |
| 16:53 | <philipj> | this particular aspect is "does playback stop when the page is not visible" (due to tab or app change) |
| 16:54 | <annevk> | yeah, this is also what I hate about browsers-inside-apps, they suck at all this |
| 16:54 | <philipj> | since the current default behavior for audio elements is to keep playing in this situation, pages that don't want this could use the page visibility API to change it |
| 16:54 | <philipj> | but it's not out of the question to make it a setting on media sessions |
| 16:55 | <philipj> | for example rich thinks we really should pause by default and require apps to opt in to the current behavior |
| 16:55 | <TabAtkins> | philipj: The API Bikeshed is always at ToT and has the most up-to-date refs. If you ever differ, update Bikeshed (`git pull --rebase` from within Bikeshed's folder) and/or update its local databases (`bikeshed update` from anywhere). |
| 16:56 | <annevk> | philipj: tab switching causing a pause would be annoying to most users I think |
| 16:56 | <annevk> | philipj: has rich never attended a YouTube party? :-P |
| 16:57 | <philipj> | annevk: that would be desktop, and as much as I'd like it making the default behavior the same on desktop and mobile does not look promising |
| 16:57 | <philipj> | annevk: on Android where tabs show up in the app switcher, having a different behavior for tab switching and app switching might be strange |
| 16:57 | <annevk> | I guess mobile has some memory issues? |
| 17:00 | <philipj> | I suppose initially bandwidth and battery might have been a reason for some differences, but at this point I think it's really about the risk of users expecting and relying on the complete lack of coordination on desktop, which would make it hard to do much useful by default |
| 17:01 | <philipj> | otherwise, I think having only one tab play at any one time would be a nice default |
| 17:02 | <philipj> | whatever changes to the defaults we can make, I hope to express them in terms of media sessions, so that it can be changed with an API |
| 17:04 | <TabAtkins> | philipj: I kinda agree - even on desktop, having multiple tabs playing at the same tab is usually just a frustrating accident, unless one of them is playing music. If music and such could mark themselves as being okay to play in the background, *and* users could mark or unmark players that way by themselves (an option in the right-click menu), it'd be cool. |
| 17:26 | <Ms2ger> | MikeSmith, ... a baby? :) |
| 17:28 | <MikeSmith> | Ms2ger: yup |
| 17:29 | <MikeSmith> | due in mid-October |
| 17:29 | <Ms2ger> | Sleep while you can :) |
| 17:29 | <MikeSmith> | haha |
| 17:29 | <MikeSmith> | yeah |
| 17:49 | <smaug____> | does any browser vendor have data about marquee usage? |
| 18:02 | <Ms2ger> | Anecdotally very popular in China |
| 18:08 | <smaug____> | sure, but does anyone actually have any data? |
| 18:09 | <smaug____> | like, was <marquee> popular 3 years ago, but not anymore ? |
| 18:09 | <smaug____> | (marquee is certainly in my remove-from-the-platform list) |
| 18:12 | <MikeSmith> | https://esdiscuss.org/topic/please-volunteer-to-maintain-the-html-version-of-the-spec |
| 18:15 | <MikeSmith> | jorendorff: hope somebody picks up the ball there but it seems absurd that in 2015 the source of the spec is still a Word document |
| 18:17 | <MikeSmith> | given that there are thousands of people who use the HTML version of the spec get work done and pretty much not even 1 person who reads the Word version (rather than writing it) |
| 18:29 | <dglazkov> | TabAtkins: how do I get a custom property value from in JS? |
| 18:36 | <jorendorff> | I think Domenic and bterlson are going to do it |
| 18:36 | <jorendorff> | It is truly absurd |
| 18:37 | <jorendorff> | I lose half a day to rage every time I think about it, so I won't elaborate |
| 18:50 | <philipj> | smaug____: https://www.chromestatus.com/metrics/feature/timeline/popularity/53 shows <marquee> usage is pretty high still |
| 18:56 | <smaug____> | ah, there |
| 18:56 | <smaug____> | somehow I missed that when looking at chromestatus |
| 22:00 | <MikeSmith> | http://lauren.vortex.com/archive/001099.html |
| 22:01 | <caitp-> | well they sound happy |
| 22:04 | <MikeSmith> | heh |