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.