05:00 | <annevk> | I wonder what https://github.com/w3c/webstorage-2nd-edition is. Is that localStorage? |
05:48 | <annevk_> | hsivonen: I looked at his issues and I'm not really sure what to say there |
05:49 | <annevk> | hsivonen: the space issues seem bs, but I can't really comment on email defaults... |
07:15 | <annevk_> | How can we be sure this tenXer stuff does not return? |
07:15 | <annevk> | It was in every repository... |
07:20 | <MikeSmith> | annevk: what tenXer stuff? something happened in the last couple days? |
07:20 | MikeSmith | has been traveling |
07:20 | <annevk> | MikeSmith: I think at some point somebody added it to a few repositories for statistics or some such |
07:21 | <annevk> | MikeSmith: but somehow it ended up "installed" everywhere including the private repository used for passwords |
07:21 | <MikeSmith> | Oh |
07:21 | <annevk> | Might want to check under Settings -> Webhooks & Services |
07:49 | <annevk> | terinjokes: Domenic: GitHub's pages is mostly about some legacy content |
07:49 | <terinjokes> | annevk: doesn't make me any less :( |
07:50 | <Domenic> | annevk: would be nice to have HSTS for e.g. http://domenic.github.io/streams-demo |
07:51 | <terinjokes> | Domenic: since it last came up, we now have a button to turn on HSTS headers |
07:51 | <Domenic> | terinjokes: oooh awesome let me go do that |
07:51 | <annevk> | terinjokes: Domenic: https://twitter.com/mikewest/status/553576868562362368 |
07:51 | <terinjokes> | but obviously requires a domain (or subdomain) going through our network |
07:52 | <Domenic> | replies there are heartening |
07:53 | <terinjokes> | Domenic: we're also beta testing x-content-type-options |
07:54 | <Domenic> | I don't really remember why I want that |
07:54 | <terinjokes> | tweet is correct, it's just a header and a 302 |
07:56 | <Domenic> | max-age 6 months seems low |
07:56 | <Domenic> | wow nice that it automatically does the preload flow for me |
08:00 | <Domenic> | when are we getting http2 tho |
10:05 | <timoxley> | https://fetch.spec.whatwg.org/#bodies "A body is a byte stream." |
10:05 | <timoxley> | what is a "byte stream" |
10:10 | <darobin> | honey, this here body is a lot more than a byte stream |
10:25 | <annevk> | timoxley: a stream of bytes? |
10:25 | <annevk> | timoxley: though see https://github.com/yutakahirano/fetch-with-streams/ (and in particular the open issues) about refactoring that to make it more concrete |
10:26 | <timoxley> | annevk: that's what I was looking for, thanks. |
10:26 | <jgraham> | To be fair "byte stream" should link to something since it's an abstract concept |
10:29 | <annevk> | jgraham: it could be https://encoding.spec.whatwg.org/#concept-stream I guess, but waiting for streams and layering everything on top of that seems more fruitful |
10:31 | <jgraham> | Sure |
10:38 | <timoxley> | "since it's an abstract concept" yeah I was expecting to see some kind of byte stream api |
10:39 | <timoxley> | considering "Let stream be an empty byte stream." |
10:39 | <timoxley> | https://fetch.spec.whatwg.org/#body-mixin |
12:31 | <annevk> | timoxley: oh, yeah, there'll be an API, that's that repository but also https://streams.spec.whatwg.org/ |
12:31 | <annevk> | timoxley: somewhat work in progress still |
12:52 | <wanderview> | jgraham: can you review this? https://critic.hoppipolla.co.uk/r/4918 |
12:54 | <jgraham> | wanderview: I can! |
12:54 | <wanderview> | jgraham: thanks! and this? https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=1161759&attachment=8601835 |
12:54 | <wanderview> | just trying to get this stuff sorted before going on PTO tomorrow |
12:55 | <jgraham> | wanderview: r+ on that if it doesn't land before the timeout increases |
12:55 | <jgraham> | I can kick off a wpt upgrade right away; should be trivial since I just did one |
12:55 | <wanderview> | jgraham: ok, just let me know when to go ahead |
12:56 | <wanderview> | thanks |
13:00 | <annevk> | wanderview++ for caring about wpt |
13:00 | <wanderview> | annevk: they really are great for highlighting ambiguity in the spec... |
13:01 | <wanderview> | I think the blink and gecko Cache APIs are better aligned because of wpt |
13:50 | smaug____ | is now lost with annevk's shadow dom v1 and v2 |
13:50 | <smaug____> | er, s/v1/1)/ |
13:50 | <smaug____> | er, s/v2/2)/ |
13:51 | <annevk> | smaug____: equivalent to 1/2 in https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Imperative-API-for-Node-Distribution-in-Shadow-DOM.md |
13:51 | <annevk> | smaug____: if that helps :-( |
13:53 | <smaug____> | I see |
13:53 | <smaug____> | annevk: it is the word "flattening" which I don't or didn't quite get in this context |
13:57 | <annevk> | smaug____: it's somewhat similar to promises in my mind |
13:57 | <annevk> | smaug____: one proposal keeps <content> intact, the other recursively unwraps <content> until there's only no-<content> nodes |
13:59 | <smaug____> | conceptually |
14:00 | <smaug____> | but ok, still feel like 2) is the way to go |
14:00 | <annevk> | yeah, I wonder if rniwa's perf concerns are valid |
14:00 | <smaug____> | feels just most natural... but I should have better arguments |
14:00 | <annevk> | seems like it's still a fairly trivial traversal algorithm |
14:01 | <annevk> | yeah my instincts say 2, definitely after seeing <content select> implemented in 1 |
14:01 | <annevk> | and 3 doesn't seem DOM-like |
14:03 | <smaug____> | 3 sounds very complicated |
14:03 | <annevk> | that too |
14:03 | <annevk> | I wonder if it would run at the same times as that proposed compositor worker or whether it would be the same thing |
14:03 | <smaug____> | if we did that, we should just do isolation and somehow use the same global for isolation and distribution |
14:03 | <annevk> | Hard to judge without a concrete proposal |
14:04 | <smaug____> | right |
14:04 | <annevk> | Yeah, and the fact that then for each custom element you create you need to have a separate script somewhere else just seems painful |
14:04 | <annevk> | With full isolation something like that is not really a problem maybe... |
14:30 | <hsivonen> | annevk: the locale attitude re: KOI8-R is terribly hostile to software devs and QA |
14:31 | <hsivonen> | annevk: but yeah, dunno about the true situation about the mail defaults |
14:42 | <SteveF_> | annevk: feedback on is= and way forward looks sane ;-) |
15:04 | <annevk> | ta |
15:15 | <dglazkov> | annevk, smaug____: are you not worried about the compounding factor of running distributions at the nanotask time? If there are X elements in doc that have distribution callbacks registered, every DOM operation that mutates the tree will need to run X callbacks at the end of it. |
15:15 | <dglazkov> | that seems scary |
15:16 | <dglazkov> | unless there's a way to determine and limit the scope of callbacks somehow? |
15:20 | <annevk> | dglazkov: only for childList changes, no? |
15:21 | <annevk> | dglazkov: I haven't fully considered the nanotask implications since it's a recent proposal |
15:21 | <annevk> | dglazkov: moving away from synchronous layout APIs still seems preferable |
15:22 | <smaug____> | yeah, only if childlist changes |
15:26 | <smaug____> | and web apps wanting to have better performance can start to rely on microtasks for distribution |
15:26 | <smaug____> | I see the nanotask part only something required for backwards compatibility |
15:56 | <dglazkov> | the "don't break the web" type of backward compatibility :) |
15:57 | <dglazkov> | childList changes only... interesting |
15:57 | <dglazkov> | what if I want to build a distribution algo that relies on attribute changes? |
16:02 | <dglazkov> | I do want to measure the impact of potential breakage we would cause by going to microtask timing. Working on it.. |
16:02 | <dglazkov> | if the impact seems small, then I am all for it |
16:29 | Krinkle | got buzzed for "timo" :) |
16:32 | <annevk> | dglazkov: the impact might be largish now, but once the CSS WG starts defining proper async APIs or you only use requestAnimationFrame() for layout stuff life might get better? |
16:32 | <annevk> | dglazkov: for attribute changes I guess you'd observe attribute changes of the childList too? |
16:37 | <dglazkov> | annevk: no disagreement that pain is temporary. Just the worry about the timeline of this pain being alleviated. My list of would-be-breakages keeps growing: https://github.com/dglazkov/nope-js/blob/master/nope.js#L12 |
16:43 | <annevk> | oh great, the new scrollingElement is one too? |
16:43 | <annevk> | how about we actually define style/layout triggers in CSSOM so people are more conscious about it |
16:44 | <annevk> | surprising that "the TAG" would approve of more sync layout |
16:45 | <TabAtkins> | Hm, why is scrollingElement on that? Is it because you can theoretically put a shadow tree on <html>? |
17:13 | <dglazkov> | TabAtkins: it's just a list of all of them |
17:15 | <zcorpan> | annevk: TabAtkins: it's really only in quirks mode, because the <body> can itself be independently scrollable, and then the APIs scroll the body element itself instead of the viewport |
17:15 | <annevk> | zcorpan: you should take that nope.js file and add annotations all over CSSOM |
17:15 | <zcorpan> | annevk: dunno what nope.js is |
17:15 | <annevk> | zcorpan: it should not be cheap to define properties that cause synchronous style/layout |
17:16 | <annevk> | zcorpan: https://github.com/dglazkov/nope-js/blob/master/nope.js#L12 |
17:16 | <annevk> | zcorpan: basically the list of getter/setter/methods that trigger synchronous stuff in CSS land |
17:16 | <zcorpan> | annevk: can you file a bug? |
17:16 | <annevk> | zcorpan: I'd like the spec for those getter/setter/methods to look suitably bad |
17:17 | <annevk> | zcorpan: can I file it against CSSOM and you'll sort out the rest? |
17:17 | <zcorpan> | annevk: sure |
18:02 | <dglazkov> | smaug____: is this your land? https://bugzilla.mozilla.org/show_bug.cgi?id=1162013 |
18:04 | <smaug____> | looking |
18:05 | <smaug____> | someone else has been dealing with Promises stuff |
18:05 | <smaug____> | sounds like a dup of some other bug... |
18:09 | <annevk> | dglazkov: basically, https://www.w3.org/Bugs/Public/show_bug.cgi?id=25981 is why we haven't sorted that yet |
18:09 | <annevk> | dglazkov: there's no normative specification for promise timing |
18:09 | <smaug____> | indeed |
18:11 | <annevk> | I actually cannot find a duplicate |
18:26 | <dglazkov> | thanks! |
21:02 | <terinjokes> | Domenic: (and possibly others) any recommendations on a Windows Phone for Mobile IE testing? |
21:03 | <terinjokes> | happy to take discussion somewhere else if needed |
21:41 | <TabAtkins> | annevk: Fetch kills javascript: urls from working, right? |
21:44 | <caitp-> | "Otherwise: Return a network error." |
21:45 | <TabAtkins> | caitp-: Sweet. |
22:58 | <nathanjosiah> | With the recent addition of rebeccapurple, it got me thinking. What is the possibility of adding satangrey for #666? |
23:06 | <hober> | nathanjosiah: not gonna happen |
23:09 | <nathanjosiah> | What about MarkOfTheBeastGrey? |
23:10 | <TabAtkins> | nathanjosiah: We added rebeccapurple as a service for one of the most important people in CSS's history. We're not actually interested in adding more named colors. |
23:10 | <TabAtkins> | Also, #666 is incredibly unsatanic anyway. |
23:10 | <TabAtkins> | (It expands to #666666 anyway, which is technically known as "double satan") |
23:11 | <tantek> | |m| |
23:11 | <TabAtkins> | |m| o |m| |
23:12 | <nathanjosiah> | So "doublesatangrey" then? |
23:12 | <TabAtkins> | No. |
23:12 | <nathanjosiah> | Ok... |
23:12 | <TabAtkins> | "We're not actually interested in adding more named colors." |
23:13 | <TabAtkins> | (I'm the editor of the Color spec, so you can take this as definitive. ^_^) |
23:13 | <nathanjosiah> | It just seems like a missed opportunity :) |
23:14 | <TabAtkins> | The missed opportunity was putting together a named color system that wasn't incredibly shitty. But we missed that opportunity over a decade ago. |
23:14 | <tantek> | X11 FTW! |
23:15 | <TabAtkins> | nathanjosiah: https://www.youtube.com/watch?v=HmStJQzclHc |
23:15 | <TabAtkins> | Wash your mouth out with soap, tantek. |
23:19 | <nathanjosiah> | TabAtkins: I would have to agree that the naming got a bit unwieldy. |