2017-08-01
[18:38:46.0000] <jungkees>
Domenic: https://html.spec.whatwg.org/#dom-messageport-postmessage step 2 throws and aborts.

[18:39:38.0000] <jungkees>
Domenic: Infra clarified throw terminates the algorithm.. Does abort the steps there intentional or can be removed?

[18:40:05.0000] <Domenic>
jungkees: can be removed. We are converting sections of HTML as we touch them, but lots left to do.

[18:40:46.0000] <jungkees>
Domenic: Okay. Have the same in SW spec. I'll remove them

[18:44:29.0000] <Domenic>
jungkees: great. I will file an issue on HTML to track updating ourselves too.

[18:44:49.0000] <jungkees>
Sounds good. Thanks

[18:50:18.0000] <jungkees>
Domenic: related but something different in https://html.spec.whatwg.org/#dom-messageport-postmessage step 5

[18:50:44.0000] <jungkees>
Domenic: It says it rethrows any exception from StructuredSerializeWithTransfer

[18:51:13.0000] <jungkees>
Domenic: and Infra says: "Throw" will make the caller automatically rethrow the given value, if any, and thereby terminate the caller’s algorithm.

[18:51:55.0000] <jungkees>
Domenic: according to Infra definition, it seems we may not need the rethrow step here

[18:53:08.0000] <jungkees>
Domenic: but then the visibility of the behavior won't be apparent to the caller.. so we may need this rethrow step to clearly say we throw here anyway?

[18:54:04.0000] <Domenic>
jungkees: yeah, this one is a bit trickier, especially because we are mixing "ES-style" abstract operations (StructuredSerializeWithTransfer) with the normal prose style. ES-style abstract operations, in theory, return completion values. So I see "rethrow any exception" as a way of clarifying the boundary.

[18:55:06.0000] <jungkees>
Okay. Explicitly rethrowing in this prose makes more sense to me too.

[19:51:56.0000] <Domenic>
annevk: so I guess we are staying with flags and then converting all at once to booleans one day? I'm sorry I keep needing to be reminded...

[21:04:05.0000] <Domenic>
Hmm, unfortunate Rust's new http create uses URI instead of URL... maybe SimonSapin is interested in setting them straight? https://carllerche.github.io/http/http/uri/struct.Uri.html

[21:06:34.0000] <Domenic>
Looks like it is being discussed in https://github.com/carllerche/http/issues/73 ... this looks not so fun to get in to.

[21:10:28.0000] <Domenic>
(But I did anyway...)

[21:22:21.0000] <MikeSmith>
I admire you for putting in the effort on cases like that

[21:22:47.0000] <MikeSmith>
that one seems like a more real chance of success in enlightening others than some cases

[21:23:14.0000] <MikeSmith>
I would have gone with “unfortunate” rather than “tragic” there though :)

[21:25:41.0000] <Domenic>
Easy enough of an edit :)

[21:26:35.0000] <MikeSmith>
Domenic: related, I dunno if you been following https://github.com/httpwg/http11bis/issues/26 but that is one of cases I had in mind that seem less hopeful

[21:27:36.0000] <Domenic>
Oh boy that looks fun

[21:28:57.0000] <Domenic>
Good guy mnot giving it a try

[21:29:19.0000] <MikeSmith>
yup

[21:29:29.0000] <Domenic>
Going to need to be patched in Fetch I guess? Or "HTTP/1 for interoperable clients"

[21:29:56.0000] <MikeSmith>
seems unresolved

[21:30:36.0000] <MikeSmith>
other than the suggestion to annevk that the discussion be taken offline

[21:31:00.0000] <MikeSmith>
which kind of seems like not the right way to deal with it, but not my business

[21:34:18.0000] <Domenic>
Oh, there are some other fun issues there... e.g. https://github.com/httpwg/http11bis/issues/34

[21:34:29.0000] <Domenic>
Subscribing, although I'm sure it'll just raise my blood pressure

[21:34:40.0000] <MikeSmith>
haha

[21:34:48.0000] <MikeSmith>
yeah I know the feeling

[21:35:13.0000] <MikeSmith>
Joseph Conrad called this “the fascination with the abomination”

[21:36:35.0000] <Domenic>
Re https://github.com/httpwg/http11bis/issues/33, annevk (or anyone) do you know if MIME Sniffing is a good reference?

[21:36:49.0000] <Domenic>
It needs a bit of love to get rid of all the red XXX boxes, but I'd imagine it's pretty solid...

[21:37:28.0000] <Domenic>
(It also uses old spec-writing styles, as we discovered in e.g. https://github.com/whatwg/mimesniff/pull/26 )

[21:42:18.0000] <Domenic>
I guess most of the XXXs are around the question of whether values should be capped at 127 bytes

[21:46:47.0000] <MikeSmith>
which I’m kvetching I’d just like to say, I hope Google content-dev people are learning the right lesson from https://bugs.chromium.org/p/chromium/issues/detail?id=489954

[21:48:21.0000] <MikeSmith>
I mean as far as why the should not speculatively lock themselves into immature spec features before they have a clear trajectory to genuine cross-browser support

[21:48:49.0000] <MikeSmith>
or worse, I think in this case they did that even after Apple had made it very clear they weren’t going to be implementing it

[21:49:43.0000] <MikeSmith>
*should not speculatively lock themselves into building production services on top immature spec features

[21:52:58.0000] <Domenic>
Yes... if these were cross-browser sites (e.g. using the polyfill), they could just work with no effort.

[21:53:08.0000] <Domenic>
You create a Chrome-only site, you should expect some potential pain.

[23:07:57.0000] <SimonSapin>
Domenic: for terminology I agree but don’t really want to get into that arguement. For the library idk, the URL Standard makes it pretty much a non-goal to support anything that’s not in a browser

[00:54:06.0000] <annevk>
Domenic: also happy to start using booleans, maybe that's better

[00:54:16.0000] <annevk>
Domenic: we usually just migrate

[00:56:10.0000] <annevk>
SimonSapin: browsers are HTTP clients though (and some have servers)

[00:58:44.0000] <SimonSapin>
annevk: my point was that the parsing algorithm in the URL standard only helps with one case of

[00:58:45.0000] <SimonSapin>
  request-target = origin-form

[00:58:47.0000] <SimonSapin>
                 / absolute-form

[00:58:49.0000] <SimonSapin>
                 / authority-form

[00:58:51.0000] <SimonSapin>
                 / asterisk-form

[00:58:58.0000] <SimonSapin>
(things that can go in an HTTP request)

[00:59:00.0000] <SimonSapin>
for example

[01:00:15.0000] <annevk>
SimonSapin: yeah I saw that at some point but it was never raised against whatwg/url to my knowledge

[01:00:28.0000] <annevk>
SimonSapin: we should probably look into how to handle that

[01:04:02.0000] <annevk>
SimonSapin: surprised Node.js hasn't reported that case yet, would hit them too I'd imagine

[01:43:07.0000] <TabAtkins>
Domenic: Do we have some examples of upgrading a function returning undefined into returning something useful?

[01:43:22.0000] <TabAtkins>
I know that was claimed as a safe upgrade path for cb-using functions, to turn them into promise-returning functions.

[01:43:33.0000] <TabAtkins>
Wondering if it actually happened in practice that you're aware of.

[02:17:02.0000] <Ms2ger>
annevk, happy birthday!

[02:18:14.0000] <gsnedders>
A wild Ms2ger appears!

[02:18:23.0000] <gsnedders>
(also, +1)

[02:19:04.0000] <Ms2ger>
\o

[02:19:07.0000] <Ms2ger>
How's Paris?

[02:20:17.0000] <gsnedders>
Overcast and warm. How's Belgium?

[02:21:29.0000] <Ms2ger>
Overcastish and warmish :)

[02:23:23.0000] <gsnedders>
Is that -ish hiding where you live? ;P

[02:25:26.0000] <Ms2ger>
Surely knowing that it's not entirely overcast here gives about as much information as knowing that it is?

[02:25:41.0000] <gsnedders>
:)

[03:21:16.0000] <jgraham>
/me concludes that Ms2ger actually lives in Paris, but is more temperature sensitive than gsnedders 

[03:28:55.0000] <gsnedders>
jgraham: tbf, you did see how tanned I was last week

[03:58:44.0000] <Ms2ger>
gsnedders tanned? I'm skeptical

[04:02:23.0000] <JakeA>
annevk: https://fetch.spec.whatwg.org/#http-fetch 3.3.1 – transmitting the body after getting the response… isn't that the wrong way around?

[04:47:09.0000] <MikeSmith>
oh yay Ms2ger

[04:47:25.0000] <MikeSmith>
/me also tries to imagine a tanned gsnedders .. and fails

[04:48:55.0000] <gsnedders>
Ms2ger, MikeSmith: I'm still just about the most person in the CSS WG F2F :)

[04:49:07.0000] <gsnedders>
I'm just less of a total ghost than normal :)

[04:49:16.0000] <gsnedders>
(Also: got tanned with SPF 50 suncream on, obviously)

[04:49:32.0000] <MikeSmith>
the “most person” in the CSS WG

[04:49:41.0000] <MikeSmith>
now that I believee

[04:50:52.0000] <gsnedders>
s/most person/most white person/

[04:50:57.0000] <gsnedders>
MikeSmith: I AM VERY PERSON

[04:57:43.0000] <MikeSmith>
true

[04:57:59.0000] <MikeSmith>
anyway I do like that song those guys wrote about you some years back

[04:58:10.0000] <MikeSmith>
Whiter Shade of Pale

[04:58:14.0000] <MikeSmith>
I think was the name

[04:58:38.0000] <gsnedders>
hahaha

[04:59:16.0000] <MikeSmith>
Alabaster

[04:59:26.0000] <MikeSmith>
I’ll stop teasing you there

[04:59:41.0000] <MikeSmith>
and return to being very glad to see Ms2ger

[05:02:07.0000] <Ms2ger>
You're very sweet

[05:07:50.0000] <MikeSmith>
: )

[05:08:33.0000] <Ms2ger>
How is the kid?

[05:09:29.0000] <MikeSmith>
Ms2ger: which one? :) I just had a new one born on Friday

[05:09:35.0000] <MikeSmith>
little girl

[05:09:38.0000] <MikeSmith>
name Mui

[05:09:47.0000] <Ms2ger>
Well, you're not holding back :)

[05:09:54.0000] <MikeSmith>
haha

[05:10:02.0000] <MikeSmith>
gotta keep the world alive

[05:10:09.0000] <MikeSmith>
my boy Zen will be 2 soon

[05:10:32.0000] <MikeSmith>
and then there’s my daughter Satori who is 19 years old now

[05:10:42.0000] <MikeSmith>
gotta spread out the bets

[05:10:53.0000] <MikeSmith>
anyway there are all doing great

[05:11:03.0000] <MikeSmith>
hope you are doing great too

[05:11:16.0000] <MikeSmith>
or somewhere near great

[05:11:22.0000] <Ms2ger>
Great enough :)

[05:11:35.0000] <MikeSmith>
good to hear

[05:12:02.0000] <MikeSmith>
well we have been carefully saving up all the work you would have been doing in the mean time

[05:12:03.0000] <Ms2ger>
/me would have guessed Zen was a year, max

[05:12:07.0000] <Ms2ger>
Time flies

[05:12:15.0000] <MikeSmith>
yeah he grows fast that one

[05:12:32.0000] <MikeSmith>
he eats everything

[05:12:50.0000] <MikeSmith>
and he needs extra oxygen more than this planet provides by default

[05:13:05.0000] <MikeSmith>
but he has adjusted to that

[05:13:09.0000] <gsnedders>
Satori is that young? For some reason I thought she was close to my age.

[05:13:16.0000] <MikeSmith>
well

[05:13:26.0000] <MikeSmith>
you are close to 19

[05:13:30.0000] <gsnedders>
:)

[05:13:37.0000] <MikeSmith>
you pretty much will always be close to 19

[05:13:44.0000] <Ms2ger>
Can you drink in the US yet?

[05:13:46.0000] <gsnedders>
closer in age to Ms2ger, I'm pretty sure

[05:14:01.0000] <Ms2ger>
I'm close to 19, or so I'd like to think

[05:14:02.0000] <MikeSmith>
I think it depends on which state, the drinking

[05:14:02.0000] <gsnedders>
well, assuming Ms2ger does actually have an age ;P

[05:14:27.0000] <nox>
gsnedders: It's a complex number.

[05:14:29.0000] <Ms2ger>
What's seven years in a lifetime anyway

[05:14:56.0000] <gsnedders>
Ms2ger: wait are we actually the same age?

[05:15:09.0000] <nox>
gsnedders: We are all the same age if you wrap the universe enough.

[05:15:21.0000] <Ms2ger>
Hi nox, how are the cats?

[05:15:32.0000] <nox>
Ms2ger: Always good, happy to see you around again.

[05:15:49.0000] <Ms2ger>
gsnedders, well I dunno, how old are you?

[05:17:37.0000] <gsnedders>
Ms2ger: 25; born April '92

[05:17:56.0000] <jgraham>
gsnedders is 14. Ms2ger can have his age reset arbitarily by his sysadmin

[05:18:11.0000] <Ms2ger>
Then we were until last week :)

[05:18:23.0000] <gsnedders>
/me wonders how old he was when he first met jgraham 

[05:18:28.0000] <gsnedders>
…16?

[05:18:37.0000] <Ms2ger>
jgraham, I don't like the implication I'm not my own sysadmin

[05:18:40.0000] <gsnedders>
Ms2ger: so you are around a year older?

[05:19:03.0000] <Ms2ger>
-ish :)

[05:20:49.0000] <Ms2ger>
gsnedders, I suppose we should just figure out how old jgraham was when you met him... About 45?

[05:24:29.0000] <jgraham>
It's a little known fact that jgraham is an anagram of Benjamin Button

[05:25:05.0000] <gsnedders>
Ms2ger: so harsh

[06:10:12.0000] <annevk>
Thanks Ms2ger, wb

[06:12:12.0000] <annevk>
JakeA: while technically possible in that order, that does seem a little wrong; I suspect the layering between Fetch and Service Workers is wrong somehow

[06:13:41.0000] <JakeA>
annevk: yeah, it feels like the service worker is responsible for transmitting the request at that point, since it may never need transmitted

[06:13:50.0000] <JakeA>
I'll file an issue

[06:16:14.0000] <JakeA>
https://github.com/whatwg/fetch/issues/572

[06:16:16.0000] <annevk>
JakeA: well, it needs to be transmitted to the service worker from the main thread

[06:16:41.0000] <annevk>
JakeA: although maybe if the service worker never reads it... hmm

[06:17:04.0000] <JakeA>
annevk: maybe a stream needs to be constructed that the sw can pull from

[06:17:06.0000] <annevk>
JakeA: I guess upload streams have a lot more bugs than I thought

[06:17:51.0000] <annevk>
JakeA: btw, it's a holiday here so I'll get back to GitHub tomorrow

[06:18:21.0000] <JakeA>
annevk: you definitely shouldn't be on IRC. Go enjoy the day!

[06:19:45.0000] <annevk>
JakeA: heh, taking a break between putting together stuff from Ikea

[06:21:29.0000] <jgraham>
Pretty sure that's the opposite of "enjoy the day"

[06:22:49.0000] <annevk>
uhuh

[06:23:34.0000] <annevk>
I'll finish with some TV and a cocktail, it'll be okay

[06:24:02.0000] <JakeA>
annevk: I've been watching Legion, which I very much recommend

[06:25:19.0000] <Ms2ger>
Is it weird that I don't mind putting together IKEA stuff?

[06:25:54.0000] <jgraham>
I think it's the whole experiencec

[06:26:05.0000] <jgraham>
Liek having to buy stuff from Ikea in the first place

[06:26:40.0000] <Ms2ger>
Okay, actually being inside a store is pretty terrible

[06:27:02.0000] <JakeA>
Agreed

[06:27:29.0000] <JakeA>
Although putting the stuff together is often like Lego and makes me feel like I'm good at something manual

[06:29:43.0000] <gsnedders>
Ms2ger: my gf is scary good at putting together IKEA stuff

[06:33:08.0000] <Ms2ger>
Will keep that in mind for the next time I get back from IKEA :)

[06:45:41.0000] <gsnedders>
tobie: you can own WebIDL tests, right?

[06:46:15.0000] <gsnedders>
oh, you do

[06:46:18.0000] <gsnedders>
my list is out of date :)

[06:51:31.0000] <gsnedders>
https://github.com/w3c/web-platform-tests/issues/5915 has a list of every unowned spec in wpt. Plz add yourself as an owner if you care about any of them.

[07:00:23.0000] <Ms2ger>
I think annevk gets http/

[07:58:40.0000] <wanderview>
annevk: happy birthday!

[08:02:51.0000] <jgraham>
annevk is spending his birthday assembling Ikea furniture? And people still believe in God?

[08:19:00.0000] <Ms2ger>
He doesn't

[08:19:02.0000] <Ms2ger>
(I think?)

[08:24:59.0000] <wanderview>
JakeA: oh, I didn't see you made a new doodle... I'm an idiot

[08:25:07.0000] <wanderview>
/me tries to delete email...

[08:25:18.0000] <JakeA>
wanderview: To be fair, I'm the idiot who fucked up the first doodle

[08:30:18.0000] <wanderview>
JakeA: well, I guess my confused email convinced some pacific folks to sign up!

[08:30:35.0000] <wanderview>
JakeA: and really, who hasn't been screwed over by timezones...

[08:56:41.0000] <Mek>
unfortunately I won't be able to make it for any of the dates in the new doodle

[08:56:42.0000] <JakeA>
wanderview: Indeed, the meeting ends at 23:59 because Doodle couldn't handle the day change

[08:56:51.0000] <Mek>
but then I don't believe my presence is vital anyway

[08:58:01.0000] <JakeA>
Mek: We can have a catchup or something afterwards


2017-08-02
[00:02:16.0000] <annevk>
JakeA: oh thanks, I'll add that to our backlog

[00:03:06.0000] <annevk>
JakeA: best thing we recently finished is Sense8, but unfortunately it got canceled (though there'll be a long wrap up somewhere next year)

[00:05:56.0000] <JakeA>
I enjoyed the first series of that but haven't watched the extra episode they did

[00:25:56.0000] <domfarolino>
Anyone know whether or not it is spec'd somewhere that browsers should not block rendering on link tags whose media attributes do not apply to the current UA environment when loading a page?

[00:27:37.0000] <domfarolino>
https://html.spec.whatwg.org/multipage/semantics.html#processing-the-media-attribute doesn't get specific about it..idk whether or not the idea of renderblocking media is implementation-dependent or something is spec'd

[00:40:19.0000] <annevk>
JakeA: there's two seasons, and then there's some kind of upcoming long episode

[00:40:35.0000] <annevk>
JakeA: ah, and the first episode of season two was also a long one

[00:41:11.0000] <annevk>
domfarolino: all of that is super hand-wavy

[00:41:45.0000] <annevk>
domfarolino: right tradeoffs are still an area of research I suppose

[00:44:39.0000] <domfarolino>
annevk: ok makes sense. yeah, reason I asked is bc nightly seems to block rendering on stylesheets loaded from link whose media attr doesn't reflect current environ, where as canary + safari don't block (render screen much quicker) gotcha tho

[00:50:24.0000] <annevk>
domfarolino: we should probably fix nightly

[00:51:05.0000] <annevk>
domfarolino: though how exactly it is to be fixed is much less clear of course

[00:51:28.0000] <annevk>
domfarolino: like do canary + safari even end up populating document.styleSheets in the end with these stylesheets?

[00:51:46.0000] <annevk>
domfarolino: CSSOM was so poorly done

[00:59:13.0000] <domfarolino>
annevk: yeah, think I'm gonna make a small repro example...any recommendations on where to ask around about it?

[00:59:20.0000] <domfarolino>
annevk: canary + safari do populate document.styleSheets after they are loaded btw

[01:00:17.0000] <annevk>
domfarolino: the only person I can think of for Fx is bz

[01:01:04.0000] <domfarolino>
annevk: ok perhaps asking around in the slack will be beneficial too or something...you're saying CSSOM was don poorly in FF?

[01:01:20.0000] <annevk>
domfarolino: no, just done poorly as a thing

[01:01:20.0000] <domfarolino>
annevk: yeah, seems like something we shouldn't be doing (all this blocking for no reason when other implementations aren't)

[01:01:25.0000] <domfarolino>
ahhhh

[01:01:43.0000] <annevk>
domfarolino: the slack?

[01:02:45.0000] <domfarolino>
annevk: ah, yeah mozilla.slack.com the firefox channel is fairly active though I feel more engineers actually use IRC so it might be the best route yeah

[01:03:10.0000] <annevk>
oh, maybe I should finally gave and sign up for that, hmm

[01:03:47.0000] <annevk>
domfarolino: I'd expect #content and maybe #layout to have answers, but not this time of day

[01:03:55.0000] <annevk>
domfarolino: on Mozilla IRC, not Freenode

[01:04:05.0000] <domfarolino>
annevk: it's unfortunately fairly spammy IMO butttttt I've gotten some decent information on bugs ive been interested in so yeah pros and cons

[01:04:19.0000] <annevk>
s/gave/cave/

[01:04:26.0000] <domfarolino>
annevk: Gotcha, yeah I'll ask around tomorrow haha

[02:23:30.0000] <TabAtkins>
domfarolino: There's no particularly good reason to block rendering in that case, but I don't think the blocking behavior is defined anywhere.

[02:23:53.0000] <TabAtkins>
One does have to be careful, because even if it doesn't apply, scripts might expect the StyleSheet object to exist.

[02:24:06.0000] <TabAtkins>
But that doesn't have anything to do with the rendering, I wouldn't think.

[02:26:49.0000] <annevk>
TabAtkins: that's another thing that's poorly defined, whether StyleSheet existing implies the entire stylesheet is present or whether that can be incremental

[02:27:07.0000] <annevk>
TabAtkins: it's clear the DOM is incremental, but for CSSOM it's all rather vague and undefined?

[02:27:09.0000] <TabAtkins>
yup

[02:27:32.0000] <annevk>
I'm sure Glenn Adams will fix it any day now

[02:28:02.0000] <TabAtkins>
it's zcorpan's responsibility now ^_^

[04:58:30.0000] <JakeA>
annevk: I could try to reduce the amount of wrapping in cancellation, but it will leave some points not-cancellable, some which are potentially observable. Eg https://fetch.spec.whatwg.org/branch-snapshots/cancelation/#main-fetch 2.4 is observable through CSP reporting

[05:03:51.0000] <annevk>
JakeA: hmm, I wonder if it's bad if you can race with mixed content blocking and such, though obviously you already can the moment you hit redirects

[05:05:36.0000] <annevk>
JakeA: also, maybe we need to rephrase "Run these steps until" somehow to not make it seem like a while loop

[05:06:02.0000] <JakeA>
annevk: I'll make a branch that only deals with streams and network stuff. I went the other way because it seems weird to call out to CSP for a potentially already terminated fetch

[05:06:44.0000] <annevk>
JakeA: yeah, I think you're right that that's weird

[05:06:54.0000] <annevk>
JakeA: so I'm okay with your setup

[05:07:19.0000] <JakeA>
annevk: Yeah, I'll figure out some working for the |reason| stuff too. I started with "If the fetch terminates with reason |reason|", but it sounds like the |reason| is part of the conditional

[05:08:38.0000] <annevk>
"Run these steps once and stop if fetch is terminated"?

[05:15:37.0000] <JakeA>
Yeah, that works

[05:18:08.0000] <JakeA>
annevk: I don't mind the git blame issue. I'll use it to get a promotion. "I wrote 50% of the fetch spec"

[05:18:50.0000] <JakeA>
(a colleague was refused promotion because some idiot did a git blame on a project they worked on and decided they hadn't done much on it)

[05:19:08.0000] <annevk>
JakeA: pretty decent machine learning you got going on there

[05:19:45.0000] <nox>
JakeA: Next time you show managements the exact same figures,

[05:19:52.0000] <nox>
JakeA: but as the output of git praise instead.

[05:20:09.0000] <JakeA>
:D

[05:20:13.0000] <jgraham>
JakeA: At Google? That's pretty funny. (and also tragic)

[05:20:21.0000] <annevk>
git: 'praise' is not a git command. See 'git --help'.

[05:20:29.0000] <annevk>
/me is disappointed

[05:20:39.0000] <jgraham>
annevk: You are thinking of svn

[05:20:47.0000] <jgraham>
git-annotate is a command

[05:21:49.0000] <JakeA>
jgraham: yeah, pretty shitty. We did some complaining about it. Hopefully it won't happen again.

[05:21:52.0000] <annevk>
There should be promotions for leaving behind little technical debt (or just owning up to it for a long time)

[05:21:53.0000] <nox>
Yeah it's from svn.

[05:22:01.0000] <nox>
blame|annotate|praise

[05:24:49.0000] <jgraham>
annevk: And yet Hyatt got a huge payrise/promotion for abandoning us yet leaving XUL and XBL.

[05:26:45.0000] <annevk>
jgraham: yeah, creation gets rewarded much more than maintaining a pile of hacks, which is why there's also so many new APIs of dubious value and rather little architectural work (some of this is overly simplified and I'm biased)

[05:27:42.0000] <JakeA>
no I think you're right

[05:28:59.0000] <JakeA>
also creating stuff in solitude makes it easier when it comes to attribution

[06:22:36.0000] <JakeA>
annevk: what's the deal with the manual-wrapping in specs? I much prefer allowing the editor to wrap. Makes it easier when searching across the file too

[06:22:56.0000] <JakeA>
Makes diffs easier too, as you don't end up with loads of lines changing because of a one-word change

[06:24:11.0000] <nox>
JakeA: This was ambiguous.

[06:24:18.0000] <nox>
JakeA: The editor, or the editor? :)

[06:24:25.0000] <JakeA>
haha

[06:24:27.0000] <JakeA>
yeah

[06:24:36.0000] <JakeA>
um, I mean the text editor's wrapping feature

[06:24:44.0000] <annevk>
JakeA: so I don't wrap terms myself (though whatwg/html does) so searching should not be impacted generally

[06:24:53.0000] <nox>
I could see someone replying to you "well, that's exactly what we do?" passive-aggressively. :P

[06:25:31.0000] <annevk>
JakeA: and I think the wrapping is for more readable diffs, though it's somewhat terminal-orientated

[06:26:05.0000] <JakeA>
annevk: ah, so I've been following the whatwg/html rules. I guess I should fix that

[06:26:35.0000] <JakeA>
annevk: I don't agree that it makes diffs better, unless the diff viewer doesn't support wrapping (which unfortunately includes vscode)

[06:26:46.0000] <annevk>
JakeA: seems like something we could discuss for a bit in https://github.com/whatwg/meta/issues to see if the tooling is maybe good enough these days that we should just drop it and go with something else

[06:27:10.0000] <JakeA>
annevk: I guess the main bit of tooling that would need to support it is github

[06:27:21.0000] <JakeA>
which doesn't right now, although a small CSS change fixes it

[06:27:38.0000] <annevk>
JakeA: well this is from the days where we mostly used "diff -u p10" or some such (I forgot the exact syntax)

[06:28:57.0000] <tobie>
JakeA: I find GitHub's split view mostly good enough for this.

[06:29:30.0000] <nox>
JakeA: I think the argument about diffing is that if you insert a long word on a line,

[06:29:37.0000] <nox>
you may need to rewrap everything that follows,

[06:29:41.0000] <annevk>
Yeah, GitHub's diff viewing + tobie's tool might be enough to start giving up on the 100col thing

[06:29:42.0000] <nox>
and then 10 lines changed instead of 1.

[06:29:47.0000] <tobie>
JakeA: That said, I favor semantic line breaks of 100 character wrap, tbh

[06:30:01.0000] <annevk>
Anyway, I recommend someone file an issue if they want to see this changed generally

[06:30:01.0000] <tobie>
s/of/over/

[06:30:08.0000] <annevk>
Against whatwg/meta

[06:30:14.0000] <nox>
Ah that's the opposite direction, disregard me.

[06:30:43.0000] <tobie>
nox: semantic line breaks prevent that

[06:31:11.0000] <nox>
tobie: Yeah that's what I meant.

[06:32:34.0000] <JakeA>
tobie: huh, I didn't realise the split view now supported wrapping in github. I thought I tried this recently and it didn't.

[06:33:25.0000] <tobie>
JakeA: I think it mostly works? There might be cases where there's too much change for it to kind of fall apart, though.

[06:33:42.0000] <JakeA>
seems pretty good

[06:34:07.0000] <tobie>
good

[06:34:53.0000] <annevk>
What's really nice about GH is how it highlights the word changes

[06:35:10.0000] <annevk>
Though unfortunately those don't account for wrapping :/

[06:35:37.0000] <wanderview>
JakeA: have the useCache WPT tests landed?

[06:36:35.0000] <JakeA>
wanderview: https://github.com/w3c/web-platform-tests/pull/5515 - no one seems to want to review it :(

[06:36:42.0000] <TabAtkins>
JakeA: Semantic linefeeds, yo <http://rhodesmill.org/brandon/2012/one-sentence-per-line/>. All the benefits of short lines, *plus* you don't have to rewrap a bunch when you change one word.

[06:37:28.0000] <wanderview>
JakeA: aren't there lots of review comments on there?

[06:37:40.0000] <wanderview>
I'll look again

[06:39:20.0000] <JakeA>
wanderview: there were reviews, and I've addressed the comments. Just needs someone to say it's now good to go :D

[06:39:55.0000] <wanderview>
JakeA: done

[06:40:03.0000] <JakeA>
\o/ thanks!

[06:40:50.0000] <wanderview>
JakeA: sorry about that... I could complain about GH UX again I suppose

[06:41:16.0000] <wanderview>
I guess I'm really used to bugzilla flag system

[06:41:24.0000] <JakeA>
wanderview: it's my bad, there's a few prs I need to chase

[06:43:40.0000] <nox>
wanderview: Is that the needinfo thing?

[06:44:12.0000] <nox>
wanderview: There is https://github.com/pulls/review-requested

[06:44:14.0000] <wanderview>
nox: needinfo, explicit review flags, a place I can see all flags requested of me

[06:45:31.0000] <JakeA>
TabAtkins: I've never done that before, but I guess it makes sense. Have you written specs this way before?

[06:45:40.0000] <TabAtkins>
I write every single spec that way.

[06:45:47.0000] <TabAtkins>
Check any of the CSS specs I edit.

[06:47:30.0000] <TabAtkins>
https://github.com/w3c/csswg-drafts/blob/master/css-align/Overview.bs

[06:47:35.0000] <TabAtkins>
^^^ for example

[06:47:55.0000] <jgraham>
wanderview: GH kind of has explicit review flags now

[06:48:15.0000] <wanderview>
jgraham: yes... but targeted at specific people or just "i want someone to review"?

[06:48:17.0000] <nox>
Yep it's the link I pasted,

[06:48:21.0000] <jgraham>
wanderview: Yes

[06:48:33.0000] <nox>
but there is no unified view for review requests and things assigned to you, for example.

[06:48:50.0000] <jgraham>
wanderview: (although really targeted at specific people is a pretty bad system for contributors)

[06:49:15.0000] <jgraham>
(although I guess it has CODEOWNERS now, so that could help)

[06:49:35.0000] <JakeA>
https://github.com/whatwg/meta/issues/31 issue for removing the 100 column limit

[06:52:35.0000] <JakeA>
TabAtkins: When are you going to write typeshed so I can write specs in TypeScript and it'll convert them to prose?

[06:53:16.0000] <wanderview>
jgraham: all I know is that I still don't have a good way to know what PRs people are waiting on me to review...

[06:55:32.0000] <jgraham>
wanderview: I mean I agree that the GH sisten is not that great

[06:55:51.0000] <jgraham>
But in-principle looking at https://github.com/pulls/review-requested answers that question

[06:56:09.0000] <jgraham>
It's just hard to find, and you don't get reminder emails, and it's not integrated with any other data

[07:15:38.0000] <annevk>
(it's also broken on whatwg/html PRs likely due to the size of the source resource)

[07:15:54.0000] <annevk>
(reported but no fix)

[07:26:55.0000] <tobie>
TabAtkins, JakeA: I <3 semantic line feeds. Helps me think. But it seems pretty much everyone else hates them.

[07:31:17.0000] <wanderview>
anyone have safari handy and could run this test? https://timeout-clamp.glitch.me/

[07:34:58.0000] <gsnedders>
wanderview: first result is inconistent (1 to 6 I've observed), second is always 6

[07:35:09.0000] <wanderview>
gsnedders: thanks

[07:35:10.0000] <jgraham>
I find that semantic line feeds make the text harder to read due to the extreme raggedy right edge. It's like someone was trying to write particularly dull freeform poetry

[07:35:24.0000] <gsnedders>
wanderview: s/first/setTimeout/

[07:35:39.0000] <gsnedders>
wanderview: (this is on a laptop on AC power, given throttling might differ)

[07:35:57.0000] <gsnedders>
wanderview: and Safari TP 36

[07:36:23.0000] <wanderview>
gsnedders: thanks, its bound to be noisy... I think 6 is a reasonable answer

[07:36:53.0000] <tobie>
jgraham: "particularly dull freeform poetry" is an pretty adequate description of spec prose.

[07:37:01.0000] <tobie>
*accurate

[07:38:36.0000] <TabAtkins>
jgraham: I find it much easier to read, precisely because the "poetic" nature of it splits up thoughts better.

[07:49:38.0000] <wanderview>
JakeA: when you are able to land the useCache tests, can you let me know?  I want to ask jgraham to do a gecko sync to pull the tests in

[07:49:55.0000] <wanderview>
or maybe let jgraham know directly since you're in the same timezone

[07:50:50.0000] <jgraham>
wanderview: Just started a sync this morning, so the timing would be unfortunate if they land this afternoon

[07:50:52.0000] <wanderview>
we're just waiting to get the tests before landing our implementation of the enumeration

[07:51:00.0000] <jgraham>
Can probably try to make it work somehow though

[07:51:21.0000] <wanderview>
jgraham: in theory not much would have changed between this morning and the afternoon if you ran another sync?

[07:52:01.0000] <JakeA>
I guess someone with the appropriate rights just needs to hit the merge button on https://github.com/w3c/web-platform-tests/pull/5515

[07:52:14.0000] <jgraham>
wanderview: Right, might just be possible to mush it in

[07:57:18.0000] <gsnedders>
if anyone has latest Edge with new-grid enabled in about:flags, what do you get for https://codepen.io/gsnedders/pen/ZJpYBY?

[08:03:51.0000] <jgraham>
JakeA: Merged, although I didn't notice I should squash rather than rebase, sorry

[08:04:12.0000] <JakeA>
wanderview: ^

[08:04:31.0000] <JakeA>
jgraham: Cheers! Don't worry about the squash thing

[08:05:24.0000] <wanderview>
JakeA: wasn't there a "failed check" or something from travis?  what was that about?

[08:06:06.0000] <JakeA>
wanderview: it looked like a failure to connect to webdriver, so I assumed (perhaps wrongly?) that it was just a glitch

[08:06:27.0000] <jgraham>
Yeah I'm not worried about that

[08:06:29.0000] <wanderview>
ok... I was just curious

[08:06:48.0000] <jgraham>
On master this PR wouldn't even run those tests

[08:06:55.0000] <jgraham>
Because it doesn't modify tools

[08:07:47.0000] <jgraham>
wanderview: Will try to pull those changes in to the sync

[08:07:53.0000] <wanderview>
jgraham: thanks!

[08:13:11.0000] <wanderview>
and thanks to JakeA for writing the test!

[08:13:41.0000] <JakeA>
no problem!

[08:41:28.0000] <JakeA>
annevk: to handle the service worker parts, I'm thinking of adding an in parallel section in step 17 of https://w3c.github.io/ServiceWorker/#handle-fetch which waits for the fetch to terminate, then queues a task to signal abort on fetchEvent.request.signal – does this sound reasonable?

[08:42:39.0000] <JakeA>
It means we don't need the message port stuff for the signal, although I'd still like signals to be cloneable for other uses.

[09:16:55.0000] <annevk>
JakeA: yeah that's probably reasonable

[09:17:28.0000] <annevk>
JakeA: I vaguely remember wanting to refactor more around streams since Fetch and SW have some duplicate parts, but that's probably separate

[09:30:54.0000] <annevk>
JakeA: I'll rereview first thing tomorrow

[09:31:37.0000] <annevk>
JakeA: btw, there's still quite a bit of interest on our side to do multiple boxes at some point with good enough heuristics to avoid the need for persistent storage

[09:32:21.0000] <annevk>
JakeA: I guess I should sketch something at some point

[09:33:28.0000] <JakeA>
annevk: interesting! The biggest problem is "tripit" which is low engagement but high importance

[09:34:01.0000] <JakeA>
But then everything is potentially high importance when you about to get on a flight or a train

[09:35:03.0000] <annevk>
JakeA: we're thinking about replacing LRU with some kind of score that takes into account recency and first visit

[09:35:46.0000] <JakeA>
annevk: doesn't that fail the tripit case?

[09:36:38.0000] <annevk>
JakeA: don't think so, recent visit and long ago first visit would be a high score

[09:37:11.0000] <annevk>
JakeA: problematic would be long ago first visit and no visit in the last x months/years

[09:38:02.0000] <annevk>
JakeA: or single recent visit

[09:38:12.0000] <annevk>
(both recent and first)

[09:38:44.0000] <JakeA>
annevk: that can happen. Log in January. "Tripit added your December flight" notification in June, user dismisses it. But you still want that "flight changed" notification in November

[09:39:04.0000] <JakeA>
Or be able to get flight into from the app offline in October etc etc

[09:41:40.0000] <annevk>
Hmm I guess tripit might be one of the cases that actually needs persistent then

[09:42:11.0000] <annevk>
Hopefully they'll use it when we ship it

[09:43:05.0000] <annevk>
I'd expect Netflix and such to also want persistent; it seems they have enough brand to ask the user such a thing and that way they get to control when stuff breaks offline

[09:43:40.0000] <annevk>
But there's a lot of cases that could be helped by better heuristics and being able to say what it's important relative to other things (if the browser needs to prune)

[09:44:09.0000] <annevk>
Maybe prune isn't the correct term here, but...

[09:47:16.0000] <JakeA>
annevk: having both works. We don't show a permission for persistent, we grant it if there's a bookmark added or add-to-homescreen

[09:47:26.0000] <JakeA>
Which I guess counts as a heuristic

[09:47:37.0000] <JakeA>
But you can query whether you have it

[10:06:22.0000] <annevk>
JakeA: yeah I saw, we have a prompt but we might do something like that at some point

[10:07:00.0000] <annevk>
JakeA: but that still requires the site explaining to the user that they have to do something and keep it that way

[10:07:44.0000] <annevk>
JakeA: boxes + better LRU might enable sites that don't want any of that (we've mostly heard that from game developers)

[10:24:57.0000] <jgraham>
annevk, JakeA: Any reason https://github.com/w3c/web-platform-tests/pull/6484 isn't merged?

[10:43:10.0000] <JakeA>
jgraham: there's no spec yet, but I believe annevk was happy for it to merge anyway

[10:43:17.0000] <JakeA>
Just needs someone to hit the button

[10:47:08.0000] <jgraham>
JakeA: Invited you into the org so you can merge your own PRs now :)

[10:47:37.0000] <jgraham>
(in particular it looks like you want to edit the commit message for that one when you squash, so I'll let you do it)

[10:53:28.0000] <JakeA>
Ooooo thanks!


2017-08-03
[00:19:06.0000] <MikeSmith>
https://bugs.webkit.org/show_bug.cgi?id=175115

[00:19:41.0000] <MikeSmith>
https://lists.webkit.org/pipermail/webkit-dev/2017-August/029386.html

[00:25:06.0000] <Ms2ger>
Keen eye

[00:40:09.0000] <MikeSmith>
if you don’t know where you’re going, any road will take you there

[02:56:47.0000] <JakeA>
annevk: how do I terminate an "in parallel" series of steps? I'm within "Run these steps until fetch is terminated" so "abort these steps" is kinda ambiguous. "Abort these in-parallel steps"?

[03:14:08.0000] <annevk>
JakeA: not sure, might be good to raise against Infra, I think your proposal is reasonable though as a first go

[03:14:38.0000] <JakeA>
ta!

[04:03:44.0000] <JakeA>
annevk: "Run these steps, breaking if fetch is terminated" – does this sound less loopy?

[04:04:13.0000] <JakeA>
I think it was the "until" that made it sound like it might loop

[04:05:18.0000] <annevk>
JakeA: unfortunately, break is reserved for loops atm, https://infra.spec.whatwg.org/#algorithm-iteration

[04:05:30.0000] <JakeA>
hah

[04:10:33.0000] <JakeA>
annevk: I know you don't like substeps, but "Run these substeps, but abort the substeps at any point if fetch is terminated:"

[04:15:55.0000] <annevk>
JakeA: s/at any point// and an issue against Infra to figure out if this is one time we need them?

[04:16:19.0000] <JakeA>
wfm

[04:20:09.0000] <JakeA>
https://github.com/whatwg/infra/issues/143

[04:26:43.0000] <tobie>
JakeA: fwiw, the issue is missing your "in parallel" fetch use case described here. Think it's worth adding it for context (I understood the issue all wrong until I came back to read about it here).

[05:05:46.0000] <JakeA>
tobie: I think that's a different issue, and infra doesn't seem to want anything to do with in parallel https://github.com/whatwg/infra/issues/120

[05:41:59.0000] <tobie>
JakeA: oh. Because without that it just sounds like "if x or y or z, then..." would do.

[05:43:20.0000] <gsnedders>
so what specs outside of the WHATWG require tests alongside all normative changes now?

[05:44:07.0000] <annevk>
gsnedders: foolip_ would know, if around

[05:44:19.0000] <annevk>
gsnedders: I think there was one example at least

[05:45:01.0000] <gsnedders>
Payment Requests does, and I'm sure there was something else that rbyers had pushed it on ages ago

[05:46:10.0000] <annevk>
gsnedders: Web Performance (as a WG?) https://github.com/w3c/web-performance/blob/gh-pages/CONTRIBUTING.md#test-driven

[05:46:21.0000] <annevk>
gsnedders: via foolip_'s Twitter

[05:46:24.0000] <tobie>
I'm sort of informally moving towards that with Web IDL

[05:46:55.0000] <tobie>
It's a bit of a more complex problem, though.

[05:47:17.0000] <gsnedders>
ah, Web Perf.

[05:47:38.0000] <gsnedders>
annevk: do we have any examples of very early-stage specs that are changing massively that have done it?

[05:48:28.0000] <tobie>
gsnedders: ^ that was a response to your question

[05:48:47.0000] <gsnedders>
that wasn't meant to be really at annevk

[05:48:51.0000] <gsnedders>
I don't know why I did that :)

[05:50:17.0000] <annevk>
it's more of an idea if it still changes a lot

[05:51:00.0000] <gsnedders>
because at least here there seems to be some concern about time spent writing tests that nobody ever runs

[05:52:40.0000] <annevk>
gsnedders: I generally see it as two phases where phase one can be anything from a PR or separate document; phase one is the idea that you flush out, get commitments on, etc. then it's time for phase 2 where it lands in a proper spec inc tests

[05:52:58.0000] <annevk>
gsnedders: sometimes tests come first, as with cancelable fetch

[05:53:37.0000] <gsnedders>
annevk: so, e.g., one question is when you move to a proper spec with tests for something like CSS Grid

[05:54:24.0000] <annevk>
gsnedders: when two UAs are in principle happy to impl and ship it

[05:55:22.0000] <annevk>
gsnedders: in principle CSS grid is just a very large change, so https://whatwg.org/working-mode#changes applies

[05:57:03.0000] <gsnedders>
annevk: tbf for years simply applying that literally would be "you fail this new test because you still don't support grid at all" :)

[05:58:09.0000] <annevk>
gsnedders: that sounds like the implementer commitments were not as serious as assumed?

[05:58:43.0000] <annevk>
gsnedders: also note that writing decent tests will improve the change/addition tremendously as well due to lots of bugs being uncovered

[05:59:17.0000] <gsnedders>
annevk: I mean I guess there's also the question of what an implementer commitment is; whether it's "we want to implement some similar Grid system in CSS" or "we want to implement this exact spec"

[05:59:32.0000] <gsnedders>
which the former makes sense in the incubation case more than the latter

[05:59:35.0000] <annevk>
gsnedders: it's the latter

[05:59:46.0000] <annevk>
gsnedders: the former is whether you start working on phase 1 at all

[06:00:56.0000] <gsnedders>
so one question is when you start writing tests for every change, because you probably want to do that once you have any implementation, rather than waiting until you have two underway

[06:01:48.0000] <gsnedders>
annevk: see also https://www.w3.org/2017/08/03-css-minutes.html#item06

[06:01:58.0000] <gsnedders>
annevk: though a lot of that boils down to "nobody reviews tests"

[06:02:22.0000] <gsnedders>
and to a lesser degree "editors don't have time", but mostly "we'd never get any spec changes landed because nobody reviews tests"

[06:02:38.0000] <Ms2ger>
In other words, "we don't care"

[06:03:04.0000] <annevk>
So then you don't change specs for a while and work on interop first

[06:03:14.0000] <annevk>
I don't think many web developers would be displeased

[06:03:36.0000] <JakeA>
gsnedders: service worker

[06:04:08.0000] <jgraham>
gsnedders: You bake reviewing tests into how you write specs

[06:04:29.0000] <gsnedders>
jgraham: and how do you get anyone to review is the problem?

[06:04:33.0000] <jgraham>
Like you do for code. Pretty sure that "we don't write tests because no one reviews them" wouldn't wash in a software project

[06:04:35.0000] <JakeA>
tobie: It's more of a shortcut between putting "if <condition> then break" before every step of a set of steps

[06:04:43.0000] <jgraham>
gsnedders: You tell them they can't land spec changes without review

[06:04:56.0000] <jgraham>
of accompanying tests

[06:04:56.0000] <JakeA>
tobie: "shortcut for putting" I mean

[06:05:09.0000] <jgraham>
Like like software changes

[06:05:20.0000] <gsnedders>
jgraham: and how do you convince the WG of this?

[06:05:27.0000] <annevk>
gsnedders: if you don't take testing seriously you basically end up revisiting a whole bunch of things down the line

[06:05:42.0000] <jgraham>
gsnedders: Ask them if they're allowed to make changes to their code projects without tests

[06:05:43.0000] <botie>
will do

[06:05:52.0000] <jgraham>
See if they can justify the difference

[06:06:18.0000] <gsnedders>
jgraham: you've seen how many changes TabAtkins makes to BS without tests, right? ;

[06:06:21.0000] <gsnedders>
* ;P

[06:06:47.0000] <jgraham>
Sure, but I bet he wouldn't be allowed to ship chromium changes without tests

[06:07:03.0000] <TabAtkins>
You say, as I'm currently reviewing the delta a new change would make to tests to make sure rebasing them is safe. ^_^

[06:07:14.0000] <TabAtkins>
(I definitely don't test *enough*, tho.)

[06:07:27.0000] <gsnedders>
TabAtkins: were you here during the earlier discussion, BTW

[06:07:40.0000] <jgraham>
So the question is whether the spec is more like Chromium where bugs get shipped to millions of people, or bs where they get shipped to a few close collaborators

[06:07:40.0000] <TabAtkins>
Earlier CSS discussion, or earlier #whatwg discussion?

[06:07:51.0000] <jgraham>
(the answer is the former)

[06:07:56.0000] <gsnedders>
TabAtkins: earlier CSS

[06:08:20.0000] <gsnedders>
jgraham: the alternative answer is the latter because the spec gets shipped to vendors who are in the WG

[06:08:44.0000] <gsnedders>
that argument is that the spec doesn't affect users, impls do

[06:08:53.0000] <jgraham>
gsnedders: And how well has that approach worked for not shipping bugs to millions of users?

[06:09:17.0000] <gsnedders>
TabAtkins: mostly given you were mentioned at several points during it per the minutes

[06:09:27.0000] <jgraham>
The current state of the web suggests that interop approaches we have taken to date are not good enough

[06:09:29.0000] <gsnedders>
TabAtkins: oh you did say a few things

[06:09:35.0000] <TabAtkins>
Yes, I was there. ^_^

[06:09:38.0000] <annevk>
There's other reasons too, but I'm not sure how much I want to rehash everything

[06:09:49.0000] <annevk>
E.g., if a spec changes and there's no test changes, no implementer might notice

[06:09:56.0000] <annevk>
This happens a lot

[06:10:07.0000] <jgraham>
And then we ship bugs to millions of people…

[06:10:08.0000] <annevk>
Changing tests and filing bugs gets everyone in line

[06:10:16.0000] <TabAtkins>
But yeah, "stop working on new features and just improve quality" always sounds good, but is very rarely actually possible.

[06:10:25.0000] <TabAtkins>
Which sucks, but hey.

[06:10:35.0000] <annevk>
It's a little bit more work, but due to the due diligence it'll also last much longer since it's actually cemented

[06:10:46.0000] <jgraham>
FWIW I haven't said "stop working on new stuff"

[06:11:04.0000] <gsnedders>
jgraham: annevk did on the basis of being unable to land new spec changes given no test review

[06:11:32.0000] <annevk>
Yeah, I was assuming that if the new thing was important enough the review would come

[06:11:47.0000] <annevk>
Which it will, since the tests would save implementers time

[06:11:49.0000] <jgraham>
gsnedders: Right, but that's hyperbole, really. In practice the WG has to find a way to ship new stuff

[06:11:55.0000] <jgraham>
Otherwise it stops existing

[06:11:58.0000] <annevk>
But with CSS Grid it might not, if implementers are happy to wait years

[06:12:23.0000] <gsnedders>
annevk: is that really the case, though, given we have hundreds of open PRs on wpt?

[06:12:40.0000] <gsnedders>
or maybe that just implies they're all tests for unimportant things, but I'm unconvinced that's true

[06:12:42.0000] <annevk>
gsnedders: in my experience, yes

[06:13:14.0000] <annevk>
gsnedders: I went through those old PRs and they're not really in a great state

[06:13:23.0000] <annevk>
gsnedders: and if you compare the backlog to what gets merged it's tiny

[06:13:42.0000] <Ms2ger>
gsnedders, importance relative to the amount of work to get the PR in a landable state?

[06:14:12.0000] <annevk>
gsnedders: backlog will always grow a bit, since maintenance is not valued as much, but that doesn't mean there's not a lot that gets done

[06:15:08.0000] <jgraham>
gsnedders: Per GH we are landing 40-150 commits a week, every week at the moment

[06:19:44.0000] <jgraham>
2300 commits so far this year compared to 2600 all last year. The idea that nothing gets reviewed is frankly bollocks.

[06:20:22.0000] <foolip_>
annevk, gsnedders: search for "Existing policies at beginning of Q3" in https://docs.google.com/document/d/1aRpnNQ7Zz_-N9ngdcjQXNjlE1NblppN7lCQwGdxRLlc/edit?usp=sharing for the non-WHATWG testing policies

[06:21:00.0000] <gsnedders>
jgraham: nothing gets reviewed for CSS tests, that's not bollocks.

[06:21:02.0000] <foolip_>
gsnedders: is the Payment Requests policy documented?

[06:21:17.0000] <gsnedders>
foolip_: https://github.com/w3c/payment-request/blob/gh-pages/test-plan.md

[06:22:01.0000] <foolip_>
gsnedders: sweet! thanks MikeSmith!

[06:23:01.0000] <gsnedders>
jgraham: is there any way to search for only merged PRs?

[06:23:24.0000] <jgraham>
gsnedders: 30 open PRs with label wg-css and 448 closed.

[06:23:38.0000] <gsnedders>
jgraham: tbf, many haven't been reviewed in wpt

[06:24:01.0000] <gsnedders>
jgraham: 153 merged excluding those labelled with chromium-export or authored by you

[06:24:02.0000] <jgraham>
gsnedders: Anyway this is a silly conversation

[06:24:57.0000] <jgraham>
The CSS WG is observing that they aren't doing their job, and instead of working out how to fix that are trying to work out how to keep not doing it without any consequence

[06:25:06.0000] <jgraham>
Except making the web worse

[06:25:29.0000] <gsnedders>
that's not an argument that will change the WG's view, however

[06:25:55.0000] <jgraham>
I am saddened that the working gorup doesn't consider interop to be a compelling argument

[06:26:05.0000] <annevk>
gsnedders: if nobody in the CSS WG takes responsibility to review, you won't get reviews, no...

[06:26:16.0000] <jgraham>
Maybe they should consider going and working on something proprietary instead

[06:26:26.0000] <annevk>
gsnedders: it's not somebody else's problem though, it's the CSS WG's problem

[06:26:40.0000] <annevk>
gsnedders: it's the quality of their work

[06:27:21.0000] <jgraham>
Maybe Google could use some people on Flutter, for example

[06:27:23.0000] <annevk>
gsnedders: and it won't be solved by trying to find QA folks, editors actually do need to step up

[06:28:07.0000] <annevk>
gsnedders: and if there's not enough editors, they should figure out how to empower more folks to do that kind of thing

[06:29:59.0000] <gsnedders>
annevk: it's not clear to me they are any less empowered than in other groups that have more editors, though

[06:30:22.0000] <gsnedders>
there definitely seem to be cultural differences within the vendors between dom teams and layout/style teams.

[06:31:02.0000] <foolip_>
jgraham: how much of a credibility problem do you think it is with all of these open PRs? if it's plausible that it reduces vendors' commitment to wpt, then including some kind of maintainance in the ecosystem infra rotation would be an option, or setting up a shared think like was discussed in MTV, idea by patket I think?

[06:31:45.0000] <tobie>
foolip_: Do those open PRs have assigned reviewers?

[06:32:09.0000] <jgraham>
foolip_: I think it's a credibility problem if there are people looking for excuses

[06:32:31.0000] <jgraham>
foolip_: I have no confidence that an infra rotation system would actually work

[06:32:37.0000] <tobie>
jgraham: true, but if it's easy to fix, it might make finding excuses more difficult

[06:33:00.0000] <foolip_>
tobie: I assume it's a mixed bag, but most of them could presumbably be mapped to a group of people via OWNERS files

[06:34:17.0000] <jgraham>
So some PRs are legitimate tests but need considerable work to land. Lots of that is old stuff. Some are tests with feedback where the PR author never did the work. Some the spec is unclear. Some could probably land if someone reviewed them

[06:34:37.0000] <jgraham>
But getting people to review random stuff in wpt when it isn't part of their job is really hard

[06:34:47.0000] <tobie>
foolip_: combine that with a bot that closes the PR after a certain amount of non-activity from the reviewers, unless the reviewers tag them with a special tag and the problem should be largely solved.

[06:35:08.0000] <jgraham>
That's why out most effective strategies for getting contributions have all been of the form "make it part of people's job"

[06:35:12.0000] <annevk>
gsnedders: as far as I could tell dbaron supported tests there, but maybe other UAs have more differing ideas

[06:35:15.0000] <Ms2ger>
If someone has budget they'd like to throw at it...

[06:35:32.0000] <jgraham>
e.g. upstreaming from vendor repos where review is management enforced

[06:35:42.0000] <jgraham>
or making it part of the process to land spec changes

[06:36:01.0000] <dbaron>
?

[06:36:15.0000] <annevk>
dbaron: sorry, didn't mean to actually drag you into this

[06:36:37.0000] <jgraham>
tobie: Certainly we could just close all the old PRs. That seems like a pretty pyrrhic victory.

[06:36:49.0000] <annevk>
dbaron: we're discussing reasons to do tests and how to convince the CSS WG and https://www.w3.org/2017/08/03-css-minutes.html#item06 came up

[06:37:22.0000] <annevk>
jgraham: I agree with you that the real problem is people looking for excuses

[06:37:42.0000] <tobie>
jgraham: it might be a rational thing to do, if 100 poor old PRs prevent you from getting 10 good new ones a week…

[06:37:46.0000] <annevk>
jgraham: it's like saying w3c/html is higher quality than whatwg/html because it has less reported issues

[06:37:48.0000] <foolip>
If we have a mostly complete spec->wpt directory mapping, via links like at the top of https://dom.spec.whatwg.org/, and OWNERS files, then I think at least all old PRs could be put in a bucket. But it's only if the spec+test people care about maintaining the test suite well that the bucket will get tended of course.

[06:37:53.0000] <annevk>
jgraham: complete nonsense

[06:37:56.0000] <tobie>
jgraham: (or more realistically a month)

[06:38:00.0000] <dbaron>
I think the average Gecko developer working on a feature probably knows to check web-platform-tests for tests, but probably doesn't know to search through the PRs for more unlanded tests...

[06:38:03.0000] <Ms2ger>
tobie, it's not clear that that's something that happens, though

[06:38:11.0000] <foolip>
Like jgraham, I don't think a rotation to look at *all* PRs would make sense.

[06:38:21.0000] <dbaron>
I don't think that's "looking for excuses".  Maybe it's an education problem or maybe it's a process problem.

[06:38:40.0000] <annevk>
dbaron: so maybe you don't know this, but each WHATWG specs links to tests and open test issues using the WPT labeling system

[06:38:54.0000] <dbaron>
I didn't

[06:38:56.0000] <annevk>
dbaron: e.g., https://github.com/w3c/web-platform-tests/labels/fetch captures all ongoing work for fetch

[06:39:02.0000] <dbaron>
but there are more specs than whatwg specs

[06:39:06.0000] <annevk>
dbaron: and is linked from the top of the Fetch Standard

[06:39:24.0000] <annevk>
dbaron: the hope is that folks copy our example since it seems pretty good (though open to better ideas)

[06:39:30.0000] <dbaron>
is it clear that "open test issues" might include pull requests with 75% of the tests?

[06:40:32.0000] <annevk>
dbaron: about as clear as open spec issues potentially including security bugs and such

[06:40:34.0000] <jgraham>
dbaron: I don't really expect people to review random open PRs, although they can certainly sign up to be notified using the OWNERS file mechanism

[06:40:56.0000] <jgraham>
I epxect people working on implementations to write tests that get upstreamed, and for those to get internal review

[06:41:09.0000] <dbaron>
does wpt have labels for indiviual css specs?

[06:41:15.0000] <jgraham>
And I expect WGs to have a process that ensures relevant tests are written and reviewed as specs are written

[06:41:15.0000] <tobie>
dbaron: yes

[06:41:53.0000] <jgraham>
CSSWG seems to be lacking the latter, because any such process would of course involve ensuring the tests have a credible means of landing

[06:42:03.0000] <tobie>
dbaron: e.g.: https://github.com/w3c/web-platform-tests/labels/css-position-3

[06:42:14.0000] <jgraham>
"hoping that a random person on the internet does it" is not very credible

[06:42:24.0000] <dbaron>
ok, but then there's https://github.com/w3c/web-platform-tests/labels/css-fonts which is unleveled

[06:43:55.0000] <tobie>
dbaron: labels are given depending on which directories the tests go in.

[06:44:18.0000] <tobie>
dbaron: if you want this to be labelled differently, just rename the directory.

[06:44:37.0000] <Ms2ger>
dbaron, there's a bunch of css tests outside the top-level css/ directory that are unversioned

[06:45:47.0000] <tobie>
Ms2ger, dbaron: wasn't aware of this. These also don't get tagged with the csswg label it seems

[06:46:07.0000] <Ms2ger>
They predate the merge

[06:46:16.0000] <tobie>
dbaron: for ref all css-wg related stuff should be here: https://github.com/w3c/web-platform-tests/labels/wg-css

[06:46:44.0000] <jgraham>
Well some of them do

[06:46:47.0000] <Ms2ger>
It's probably worth merging them into the relevant css/css-foo-N dirs

[06:46:57.0000] <Ms2ger>
Or going the other way around

[06:46:57.0000] <tobie>
Ms2ger: agreed.

[06:48:07.0000] <jgraham>
css-fonts seems to be rather new, and based on moving css-fonts-4 stuff out of the css-fonts directory

[06:48:22.0000] <jgraham>
*out of the css/css-fonts-3 directory

[06:49:58.0000] <tobie>
well, if these want an wg-css label, we'll need to fix the bot

[06:51:39.0000] <annevk>
dbaron: presumably you don't want the tests to be leveled? You'd end up maintaining many more tests than if you just tracked whatever everyone is implementing

[06:51:59.0000] <dbaron>
yeah, dunno, but lots of the css dirs are leveled

[06:55:32.0000] <gsnedders>
dbaron:

[06:56:53.0000] <gsnedders>
annevk: all the UAs agree, but nobody's willing to do any work

[06:57:56.0000] <annevk>
gsnedders: film at 11?

[06:58:59.0000] <jgraham>
I mean I might not discourage people who are removing the leveling by re-moving tests back to a levelled directory

[07:01:00.0000] <gsnedders>
dbaron: so the mix of levelled and unlevelled is essentially just down to what we had agreement to do in the WG

[07:01:47.0000] <gsnedders>
dbaron: all tests for existing specs remained in their levelled dirs; all tests for new tests are unlevelled per standard wpt policy

[07:02:50.0000] <gsnedders>
I would like to move it so everything is unlevelled (but that gets a bit messy given the modularisation of CSS 2), but I'd expect massive pushback from the WG if I tried

[07:03:07.0000] <gsnedders>
and I don't currently think it's worth spending the political capital on

[07:03:26.0000] <Ms2ger>
*for new specs

[07:04:04.0000] <Ms2ger>
+ cssom

[07:04:46.0000] <Ms2ger>
Anyway, as long as there's a unique directory for each spec... *shrug*

[07:04:56.0000] <gsnedders>
yeah, I think there's a few level 1 specs

[07:05:19.0000] <gsnedders>
Ms2ger: the current pain point is the mixture across css/CSS2 and various css/*-3 directories

[07:05:29.0000] <gsnedders>
and there's no clear way to come up with the complete testsuite for the level 3 spec

[07:05:39.0000] <Ms2ger>
Yeah

[07:05:53.0000] <Ms2ger>
Ceterum censeo css2 delenda est

[07:06:14.0000] <gsnedders>
:)

[07:06:25.0000] <gsnedders>
Ms2ger: well, s/C/c/

[07:06:35.0000] <gsnedders>
(why am I correcting Latin now?)

[07:07:06.0000] <Ms2ger>
s/est/esse/, apparently

[07:07:19.0000] <Ms2ger>
/me merged two versions

[07:09:14.0000] <gsnedders>
uh, yeah, that would also make more sense

[08:25:10.0000] <Domenic>
Reading the above was depressing.

[08:25:50.0000] <jgraham>
Which part?

[08:25:50.0000] <botie>
i think Which part is old in this case?

[08:26:58.0000] <Domenic>
Just the fact that there are still people pushing back against tests with every spec change. Especially if those people are editors.

[08:27:43.0000] <nox>
How surprising.

[09:10:34.0000] <TabAtkins>
In a theoretical world where I wasn't already 200% committed on specs, *plus* another big chunk of commitment on Bikeshed, I'd love to do tests-with-every-commit.

[09:11:28.0000] <TabAtkins>
We theoretically are doing this now with the specs Shane and I edit in Houdini, tho I did a large rewrite of Typed OM over several weeks and didn't slowly change tests along with it; I need to catch myself back up with the now-final state.

[09:23:53.0000] <annevk>
TabAtkins: I think you'll find that you might write less, but what you end up writing ends up getting shipped and ends up being higher quality

[09:24:25.0000] <annevk>
TabAtkins: and you should probably look into trying to scale the editing somehow if you're 200% committed since that's not ok

[09:24:41.0000] <TabAtkins>
I agree, but, uh, doesn't seem likely to be fixed any time soon.

[09:24:52.0000] <annevk>
TabAtkins: for instance, delegate by getting implementers to write PRs for new features (and the tests) that you then review

[09:25:17.0000] <TabAtkins>
Implementors aren't particularly good at, or enjoy, writing spec features.

[09:25:24.0000] <annevk>
TabAtkins: I think if you're willing to change your priorities it should be possible

[09:26:10.0000] <Domenic>
+1

[09:26:28.0000] <annevk>
TabAtkins: if they want to ship something you can at least tell them they have to write tests because you can't merge the spec PR otherwise

[09:26:46.0000] <annevk>
TabAtkins: but I also think that if you ask you'll find that some people might want to try their hand at writing stuff

[09:27:06.0000] <TabAtkins>
I'm doing that for several Houdini features.

[09:27:21.0000] <TabAtkins>
Bringing impls up for simpler issues does indeed work.

[10:04:45.0000] <wanderview>
jugglinmike: ping

[10:18:41.0000] <wanderview>
jugglinmike: I just made a PR: https://github.com/w3c/web-platform-tests/pull/6745

[10:40:04.0000] <smaug>
there was some way to run wpt on any browser

[10:40:08.0000] <smaug>
what would be the url?

[10:40:23.0000] <smaug>
/me would like to run workers/data-url.html

[10:52:42.0000] <jgraham>
smaug: http://w3c-test.org/workers/data-url.html perhaps

[10:53:06.0000] <jgraham>
Or you can run it from m-c with ./mcah wpt --product chrome|edge workers/data-url.html

[10:53:33.0000] <smaug>
ah, that too

[12:36:08.0000] <Domenic>
Is there any way to unsubscribe from a Mozilla bug that I reported?

[12:36:14.0000] <Domenic>
I really don't need to see all the code review comments and patches

[12:42:23.0000] <wanderview>
Domenic: yes

[12:42:35.0000] <wanderview>
Domenic: there is a "never email me about this bug again" somewhere on the page

[12:43:49.0000] <wanderview>
Domenic:  at the bottom of the page immediately above the submit button

[12:44:34.0000] <Domenic>
Hmm all I see there is "Add me to CC list (follow this bug)" (which is unchecked)

[12:45:08.0000] <Domenic>
Oh I needed to hit "edit bug" first O_o

[12:45:33.0000] <Domenic>
Thanks!

[12:45:50.0000] <wanderview>
Domenic: sorry... bugzilla is a twisty mazy of corridors and you are likely to be eaten by a grue

[12:46:25.0000] <gsnedders>
s/likely/certain/

[14:14:33.0000] <Domenic>
Any historians may enjoy helping with https://github.com/whatwg/html/issues/2891

[14:14:38.0000] <Domenic>
Especially media folks, it seems

[14:27:27.0000] <MikeSmith>
/me looks


2017-08-04
[22:48:35.0000] <GPHemsley>
/me put in his linguistic two cents

[00:45:20.0000] <TabAtkins>
annevk: The CSSWG approved me advancing the Shadow Parts spec <https://tabatkins.github.io/specs/css-shadow-parts/> to ED. Part of this belongs in DOM, with the other shadow dom stuff. How do you want to handle this, especially as we'll probably be iterating on it?

[00:45:49.0000] <TabAtkins>
(This has good approval from Chrome, and other browsers don't have objections yet.)

[00:47:21.0000] <annevk>
TabAtkins: the part attribute is a superglobal?

[00:47:28.0000] <TabAtkins>
yeah

[00:47:35.0000] <TabAtkins>
name subject to change

[00:47:49.0000] <annevk>
TabAtkins: I guess the best would be to have a PR against DOM that we iterate on

[00:47:55.0000] <TabAtkins>
kk

[00:47:58.0000] <annevk>
TabAtkins: PRs automatically generate snapshot specs and HTML diffs

[00:48:05.0000] <TabAtkins>
excellent

[00:53:42.0000] <annevk>
TabAtkins: FWIW, pseudo-elements had a lot of interest from Apple and also various Mozillians at times

[00:54:10.0000] <TabAtkins>
yup

[00:54:47.0000] <TabAtkins>
Current feeling from Apple (per last comment from Ryosuke) is disapproval of ::theme(), but that won't affect the DOM part.

[00:55:40.0000] <annevk>
I guess I should read through it though I suspect we might lag behind a little bit due to not having implemented shadow trees just yet

[00:56:03.0000] <TabAtkins>
yeah. dbaron +1'd in the meeting

[01:20:24.0000] <annevk>
JakeA: you haven't run into https://twitter.com/philpennock/status/891734286864453632 yet

[01:23:03.0000] <JakeA>
I hadn't seen that

[01:23:07.0000] <JakeA>
annevk: haha brilliant

[01:23:34.0000] <JakeA>
Sure IRC cloud, deliver those messages in any order you want

[04:41:01.0000] <gsnedders>
/me feels zcorpan-OOO-14Au is somewhat failing at the OOO thing

[05:56:58.0000] <annevk>
mounir: didn't you look into deviceorientation at some point?

[06:55:58.0000] <wanderview>
rbyers: is jugglinmike still doing WPT stuff for you all?

[07:27:11.0000] <MikeSmith>
wanderview: jugglinmike is around on #testing and #webdriver on irc.w3.org

[07:27:31.0000] <gsnedders>
wanderview: (yes)

[07:27:58.0000] <wanderview>
ok, thanks

[08:05:07.0000] <wanderview>
MikeSmith: somehow I didn't even know that #testing channel existed!

[10:22:40.0000] <MikeSmith>
wanderview: yeah we should note it more prominently in the docs

[10:40:09.0000] <rbyers>
wanderview: Most of our Bocoup WPT work at the moment is going to the tooling infrastructure bobholt is With Apple's ServiceWorker announcement I'm very glad we had jugglinmike do the SW testing working (likelihood of Apple implementation was my #1 factor in choosing that as our top priority for Mike).  I expect to get back to investing more in WPT suite improvements like that in 2018.

[10:43:06.0000] <jgraham>
like what?

[10:44:20.0000] <jgraham>
Like serviceworker?

[10:44:30.0000] <jgraham>
/me just checking he understands

[11:32:48.0000] <jugglinmike>
rbyers: welcome back!

[11:36:30.0000] <rbyers>
jgraham: Sorry missed your response.  I'm not sure exactly what yet, but I'm convinced that there's likely to be an ongoing stream of high-value test suite improvements to be done (in parallel with our primary strategy of scalability via sustainable culture shift)

[11:40:09.0000] <rbyers>
... On my list of areas to look into (below SW and WebRTC where we've already invested heavily) are Fetch, SVG, Grid, webdriver, web payments, WebVR?  foolip likely has others.  Let us know if you have other areas you'd like to see on our list... We'll have to evaluate more carefully closer to 2018....

[11:40:13.0000] <rbyers>
jugglinmike: Thanks!

[16:00:24.0000] <MikeSmith>
did Apple actually make an announcement of Service Worker?

[16:01:13.0000] <MikeSmith>
(I’m of the related WebKit implementation bugs that have been raised, but can’t recall seeing an announcement)

[16:01:46.0000] <MikeSmith>
*Apple actually make an announcement about plans for Service Worker support

[16:05:45.0000] <MikeSmith>
JakeA: if you think we need a new mailing list for Service WG administrivia, lemme know. But by default I am reluctant to create any new mailing lists. Everybody repeatedly tells me we have too much already and they are tired of it

[16:05:59.0000] <gsnedders>
MikeSmith: they changed the status page to under development and landed the IDL into the repo

[16:06:45.0000] <MikeSmith>
gsnedders: OK yeah I knew about the IDL landing but did not know about the status-page change

[16:07:25.0000] <MikeSmith>
anyway the fact that they are actually implementing is the best news about about the web runtime that’s come along for quite a while

[16:26:04.0000] <MikeSmith>
annevk: https://stackoverflow.com/questions/45516070/urlsearchparams-does-not-return-the-same-string-as-found-in-a-urls-parameters

[16:26:24.0000] <MikeSmith>
> last I checked the API doesn't support parameter arrays like foo[]=1&foo[]=2

[16:35:01.0000] <Domenic>
That's some kind of PHP convention

[16:40:54.0000] <MikeSmith>
Domenic: yeah people assume it should be supported natively everywhere I guess

[16:41:26.0000] <MikeSmith>
but anyway that comment was incidental the original question there

[16:41:53.0000] <MikeSmith>
regardless, nice to see somebody posting about URLSearchParams at SO

[16:43:38.0000] <gsnedders>
I think few people know quite what the URL level actually defines about query strings

[16:43:41.0000] <gsnedders>
esp. how little it does


2017-08-05
[22:01:16.0000] <JakeA>
MikeSmith: agreed. Github is working well for us, we don't need a list

[22:23:39.0000] <MikeSmith>
JakeA: I figured you would say so :) thanks for confirming

[15:21:05.0000] <refack>
Domenic: thank you for answering my question. I'm very interested in helping make node as standard compliant as possible...

[15:50:17.0000] <Domenic>
:)


2017-08-06
[02:30:21.0000] <annevk>
/me finds https://wiki.php.net/rfc/replace_parse_url and emails author

[16:49:20.0000] <GPHemsley>
hmm... w3c-test.org is down

[16:51:20.0000] <MikeSmith>
yup

[16:51:25.0000] <MikeSmith>
will ping Ian


2017-08-07
[17:07:59.0000] <GPHemsley>
grazie

[17:12:37.0000] <TimothyGu>
Hey all *.spec.whatwg.org seems to be down, is this a known issue?

[17:12:59.0000] <TimothyGu>
curl: (7) Failed to connect to html.spec.whatwg.org port 443: Connection refused

[18:22:15.0000] <GPHemsley>
TimothyGu: I'm going to say yes, assuming it's the same issue as w3c-test.org

[18:22:34.0000] <GPHemsley>
(though the symptoms are different)

[18:22:48.0000] <TimothyGu>
hmm w3c-test.org was down for me yesterday, while whatwg.org starts not working today

[18:24:19.0000] <GPHemsley>
well then... MikeSmith?

[19:08:08.0000] <MikeSmith>
if w3c-test.org is down it’s my fault, if whatwg.org is down it’s Hixie’s fault

[19:08:23.0000] <MikeSmith>
oh both are down

[19:09:26.0000] <MikeSmith>
I pinged Hixie about whatwg.org

[19:09:33.0000] <MikeSmith>
did not hear back from him yet

[19:11:05.0000] <MikeSmith>
ah about w3c-test.org we changed the commands for starting it

[19:11:27.0000] <MikeSmith>
*the commands for starting wptserve

[19:11:36.0000] <MikeSmith>
so I need to update my init script

[23:32:55.0000] <MikeSmith>
GPHemsley: I run w3c-test.org, Hixie runs whatwg.org

[00:05:19.0000] <MikeSmith>
Domenic: ah OK I see now

[02:42:52.0000] <Ms2ger>
whatwg.org is down?

[02:45:03.0000] <annevk>
Ms2ger: yeah known

[02:45:25.0000] <Ms2ger>
I'd look at the logs, but they're down too

[02:46:02.0000] <annevk>
I don't think it was reported here yet, but I might have missed something

[03:33:02.0000] <Ms2ger>
If a video stops because it reaches the end of the video, does it also get a 'pause' event?

[03:57:09.0000] <annevk>
Wow, even Live DOM Viewer is down

[03:57:19.0000] <annevk>
It's serious now

[05:14:28.0000] <Domenic>
Everything seems back up

[05:15:07.0000] <annevk>
Wow that just happened then since I pushed something a minute or two ago and it failed

[05:46:37.0000] <rnd123>
hello, i have a problem with my implementation of microdata and google's image search service, is this the right place to ask things about it?

[06:24:02.0000] <wanderview>
Domenic: if the UA is consuming a ReadableStream with a js internal source... is the UA allowed to "steal" or transfer the Uint8Array buffer to avoid copying?  I assume its not since in theory the js internal source could still be holding on to it?

[06:24:50.0000] <wanderview>
I guess maybe the UA could do some kind of copy-on-write sort of thing

[06:24:55.0000] <JakeA>
wanderview: I think Domenic was thinking of a special stream type or option to enable transferring

[06:25:16.0000] <wanderview>
there is byob streams... but I think this is different, maybe?

[06:25:25.0000] <JakeA>
Yeah they're different

[06:25:50.0000] <wanderview>
JakeA: we're not really in a position to do the no-copying optimization stealing the buffer would allow... but if it wasn't permitted by the spec then I would feel better about not implementing it :-)

[06:25:54.0000] <JakeA>
I think it's complicated if you have an object stream and you want to specify which parts are transferrable

[06:26:45.0000] <JakeA>
wanderview: It'd be great if it was supported if all parts of the stream were behind the scenes

[06:27:09.0000] <wanderview>
JakeA: we definitely support it for native sourced streams

[06:27:11.0000] <JakeA>
eg, piping three items of the cache to a single transform stream that doesn't have a chunk handler

[06:27:21.0000] <wanderview>
or will

[06:27:49.0000] <wanderview>
hmm

[06:28:10.0000] <wanderview>
I guess we would not support the appending without copying, though

[06:28:54.0000] <JakeA>
wanderview: I may be wrong https://streams.spec.whatwg.org/#dfnReturnLink-1

[06:28:57.0000] <wanderview>
JakeA:  I guess you mean if the Uint8Array chunk was marked as "originally came from native code" and we never dirtied that bit by going through a js handler... then we could steal it

[06:29:10.0000] <JakeA>
oh, that link wasn't charable

[06:29:13.0000] <JakeA>
shareable

[06:29:21.0000] <JakeA>
wanderview: https://streams.spec.whatwg.org/#transfer-array-buffer

[06:29:43.0000] <JakeA>
looks like transferring happens by default with bytestreams

[06:29:47.0000] <JakeA>
did not know

[06:30:02.0000] <wanderview>
oh, ok

[06:30:06.0000] <annevk>
rnd123: probably not, I'd look at the URLs over at http://schema.org/docs/about.html

[06:30:20.0000] <wanderview>
JakeA: ok, I should feel bad we will be copying then

[06:32:01.0000] <annevk>
wanderview: do we at least invoke detach on the input buffer?

[06:32:18.0000] <wanderview>
annevk: I assume so... I would have to check with till

[06:32:36.0000] <JakeA>
wanderview: this is only with {type: 'bytes'}

[06:32:54.0000] <wanderview>
annevk: the bit I am talking about is specific to the fetch body stream being consumed by respondWith() or Cache.put()

[06:33:26.0000] <wanderview>
JakeA: yea, but these native APIs will fail for non-byte streams anyway

[06:33:38.0000] <annevk>
wanderview: would it not still be observable? I might be missing something though

[06:34:06.0000] <JakeA>
wanderview: is that per spec? I thought fetch would allow a non-byte stream as long as it returned bytes

[06:34:13.0000] <wanderview>
annevk: yea, it should detach... but that is handled in the js engine part of streams and not in the DOM integration code I'm looking at

[06:34:47.0000] <rnd123>
thanks annevk

[06:34:59.0000] <wanderview>
JakeA: its likely I am confused and you are correct

[06:35:11.0000] <JakeA>
that's not the way it usually goes

[06:35:12.0000] <wanderview>
I meant UA consumption requires Uint8Array

[06:35:48.0000] <JakeA>
wanderview: yeah, but the transfer only happens if it was created like new ReadableStream({ start, pull, type: 'bytes' })

[06:35:49.0000] <wanderview>
at this time of day you are better caffeinated than I am...

[06:35:53.0000] <wanderview>
ok

[06:36:12.0000] <wanderview>
JakeA: so it would have to be a selective optimization... I wonder if the "type" option was added later...

[06:36:13.0000] <JakeA>
otherwise I assume it copies

[06:37:00.0000] <JakeA>
wanderview: Chrome currently throws if you set "type" to "bytes"

[06:37:07.0000] <JakeA>
Not implemented

[06:37:40.0000] <wanderview>
oh, I see... its a property on the source... not an option passed to the ReadableStream construcotr

[06:37:55.0000] <wanderview>
I was getting confused by "type" not being in this line: https://streams.spec.whatwg.org/#rs-constructor

[06:38:25.0000] <JakeA>
I agree it feels more like an option

[06:38:35.0000] <JakeA>
but then I guess it also describes the unerlyingSource

[06:38:46.0000] <wanderview>
I think it fits with the underlying source

[06:38:58.0000] <wanderview>
"native" sources in theory always have it set

[06:39:08.0000] <wanderview>
so its exposing that part of their optimizations to js sources

[06:40:41.0000] <wanderview>
JakeA: we don't throw on type bytes

[06:41:37.0000] <JakeA>
wanderview: I guess in that case the buffer must appear transferred

[06:42:18.0000] <wanderview>
JakeA: yea, we try to do it: http://searchfox.org/mozilla-central/source/js/src/builtin/Stream.cpp#801

[06:42:43.0000] <wanderview>
maybe there is a test...

[06:46:29.0000] <wanderview>
JakeA: maybe this tests it? http://searchfox.org/mozilla-central/source/testing/web-platform/tests/streams/readable-byte-streams/general.js#816

[06:47:30.0000] <wanderview>
its confusing because it also uses a byob stream

[06:48:21.0000] <wanderview>
we seem to pass that test, though

[06:53:10.0000] <wanderview>
JakeA: filed a bug to track this optimization in the future: https://bugzilla.mozilla.org/show_bug.cgi?id=1388050

[06:53:37.0000] <JakeA>
cheers!

[09:17:06.0000] <annevk>
Domenic: thoughts on how to capture https://github.com/w3c/requestidlecallback/issues/61 in the API guidelines?

[09:18:34.0000] <annevk>
Domenic: make your prose closely resemble an implementation in an imperative programming language and stay away from stack inspection and such?

[09:44:33.0000] <rbyers>
I've been searching for 5 minutes to try to find the license / copyright notice for HTML (so I can link to it as a GOOD example of a spec that allows forking).  Am I just blind?  I'm surprised it's so hard to find.

[09:45:11.0000] <rbyers>
There's one line at the very bottom of the spec (at the end of acknowledgements), is that it?

[09:45:50.0000] <rbyers>
For some reason I thought html was CC0?

[09:45:59.0000] <rbyers>
annevk/foolip: ^

[09:46:37.0000] <jgraham>
rbyers: HTML isn't for historical reasons iiuc

[09:46:41.0000] <annevk>
rbyers: HTML is complicated

[09:46:42.0000] <jgraham>
rbyers: DOM is though

[09:46:56.0000] <rbyers>
Ah, figures.  I'll use DOM as a better example.  Thanks :-)

[09:46:58.0000] <annevk>
rbyers: everything else under WHATWG would be a good example

[10:42:55.0000] <TabAtkins>
annevk: Sorry about the failure on DOM - I spotted the issue on Friday and fixed it, but it looks like I didn't push my code. :( Fixing it again now on my desktop, but I have a quick question.

[10:43:54.0000] <TabAtkins>
Any opinion on using unicode characters for doing the deduping? I'm trying to make it much less likely that things will collide with intended URLs; in particular, that some of the multiple refs for a "foo" term collide with the refs for a "foo-0" term.

[10:44:16.0000] <TabAtkins>
I'm thinking about appending circled-digits for the dedup process.

[11:57:57.0000] <Mek>
hmm, should windows opened by clients.openWindow be considered script-created (and thus be able to close themselves) or not?

[11:58:31.0000] <Mek>
From a quick test it seems neither chrome nor firefox considers them script created currently (although chrome allows self.close() if no navigation occured after opening, while firefox doesn't seem to allow self.close() even in that case)

[14:12:46.0000] <wanderview>
JakeA: would you expect to get DOMContentLoaded much sooner with your blog when streams+sw are enabled?

[14:14:00.0000] <JakeA>
wanderview: maybe due to the script and styles being cached. But in terms of html delivery it shouldn't be that much faster

[14:14:55.0000] <wanderview>
JakeA: with streams enabled I see DOMContentLoaded dropping from ~150ms to ~35ms...

[14:17:10.0000] <JakeA>
wanderview: that's really cool… but I can't explain how streams cause that. If the CSS and JS is removed from the cache, is it still as fast?

[14:18:12.0000] <wanderview>
JakeA: yea, I more suspect something is broken... but let me check... (I'm really annoyed our network monitor pretends things coming from cache/SW are zero time)

[14:19:46.0000] <wanderview>
JakeA: hmm... deleting the css and js files made DOMContentLoaded go up to 320ms... so maybe this is legit

[14:20:07.0000] <wanderview>
JakeA: chrome on my machine gives DOMContentLoaded ~30ms as well... but I don't know how to test without streams there

[14:21:02.0000] <wanderview>
JakeA: looks like most of the added time was the "include" call

[14:23:31.0000] <wanderview>
anyway, I guess the good news is it works

[14:32:14.0000] <JakeA>
\o/ is this in nightly?

[14:33:42.0000] <wanderview>
JakeA: not in nightly yet... a preliminary build

[14:34:19.0000] <Mek>
JakeA/wanderview: either of you have opinions on wether clients.openWindow opened windows should be considered "created by script", and thus be able to self.close() themselves?

[14:34:36.0000] <wanderview>
JakeA: also there is probably a bug somewhere... the image on your blog and the bg image on surma's site did not load a couple times

[14:34:42.0000] <wanderview>
but it was pretty intermittent

[14:35:36.0000] <wanderview>
Mek: I wasn't aware of that restriction or feature... so don't really have an opinion... at first glance it seems "created by script", though

[14:35:46.0000] <wanderview>
I have to run to dinner...

[14:35:50.0000] <wanderview>
/me waves

[14:36:13.0000] <Mek>
wanderview: okay, thanks

[14:38:27.0000] <Mek>
actually, the browsing context wouldn't be an auxiliary browsing context so the html "script-closable" defintion wouldn't care if it was created by script or not...

[16:06:17.0000] <domfarolino>
annevk: just a heads up will be about a week before I can revisit https://github.com/whatwg/html/issues/2886


2017-08-08
[23:34:07.0000] <annevk>
domfarolino: that's cool, enjoy whatever else meanwhile

[23:34:42.0000] <annevk>
TabAtkins: Unicode and fragments is a bit of a hassle still

[23:35:01.0000] <annevk>
TabAtkins: probably best avoided, though it'll probably work

[00:32:14.0000] <Domenic>
TabAtkins: so FYI Watti seems to have a global table of IDs that it uses for deduping; then it can just use numeric suffixes. That seems less error-prone than your strategy?

[00:32:49.0000] <Domenic>
wanderview: JakeA: it sounds like you did figure out the idea. Which is that byte streams allow more transferring optimizations. (Even with non-BYOB readers.)

[00:33:44.0000] <Domenic>
annevk: that guidance seems good, although an example (perhaps the RIC one genericized) would help drive it home. People do seem to really like stack inspection sometimes, instead of explicit parameter passing.

[00:34:19.0000] <JakeA>
Domenic: together we got there!

[00:35:17.0000] <Domenic>
I should spend more time on streams stuff.....

[06:26:58.0000] <wanderview>
Domenic: no, no... let us catch up first

[06:52:14.0000] <tobie>
What are examples of interfaces that declare a named property getter but not an indexed property getter?

[06:54:03.0000] <annevk>
tobie: Storage

[06:54:21.0000] <annevk>
tobie: DOMStringMap

[06:54:39.0000] <tobie>
annevk: ta

[07:29:09.0000] <JakeA>
wanderview: I wasn't aware Firefox had double keying

[07:29:15.0000] <JakeA>
Similar to the Safari thing?

[07:29:41.0000] <wanderview>
JakeA: its behind a pref and called something else I think... I believe we imported it from tor project

[07:29:56.0000] <JakeA>
exciting though!

[07:30:11.0000] <wanderview>
JakeA: but our containers work in a similar way...  add some private data to the origin and its extra unique, etc

[07:31:49.0000] <wanderview>
JakeA: looks like privacy.firstparty.isolate

[07:32:08.0000] <wanderview>
JakeA: we may not have things like "visiting a site as first party exempts it from double-keying" like safari, though

[07:33:09.0000] <wanderview>
I haven't tried it

[07:37:39.0000] <Domenic>
We are looking into something similar to that ("origin attributes" is what it's called I believe) especially to underlie things like suborigins

[07:38:37.0000] <annevk>
Domenic: that's what Firefox has and some folks at Chrome want to copy

[07:38:39.0000] <wanderview>
Domenic: we also call it OriginAttributes :-)

[07:38:54.0000] <Domenic>
Yeah it's based on a paper some FF folks wrote I believe

[07:39:03.0000] <wanderview>
ah, cool

[07:39:08.0000] <wanderview>
is a "paper" like a blog?

[07:39:28.0000] <tobie>
annevk:  in https://github.com/heycam/webidl/pull/402#discussion_r131709808 you mention enum order is defined by underlying infra list. Are all APIs with named props specified with an underlying infra list?

[07:40:36.0000] <annevk>
tobie: pretty sure that's a no

[07:41:03.0000] <annevk>
tobie: I do think order is defined though typically

[07:41:09.0000] <annevk>
tobie: and when it's not that's a bug

[07:41:22.0000] <annevk>
tobie: and not using Infra list a minor bug that'd be nice to fix

[07:42:26.0000] <tobie>
annevk: shouldn't WebIDL call that out somehow, though? Or maybe infra's for each should?

[07:43:14.0000] <annevk>
tobie: it's called out by requiring it to be a list, which are ordered by definition

[07:47:43.0000] <tobie>
annevk: Oh! It had somehow never really clicked that while "while" was defined in 3.3 Iteration "for each" was just a reference to list/for each.

[07:49:13.0000] <tobie>
annevk: I guess that makes sense and will even more obvious as infra becomes ubiquitous.

[07:54:56.0000] <Domenic>
Anyone else have opinions on https://lists.w3.org/Archives/Public/public-whatwg-archive/2017Aug/0001.html ?

[10:15:01.0000] <TabAtkins>
@annevk What's troublesome about unicode in fragments? They seem to work just fine.  (I had to implement my own fragment-escaper, as Python2's urllib escaper doesn't understand unicode, but I did so by consulting HTML, so it should be correct.)

[10:15:40.0000] <refack>
Hello all, has there been any work (or interest) in standardizing `'assert'`? It's been bugging me, and I see it is used in the platform tests

[10:16:15.0000] <TabAtkins>
@Domenic Yeah, I have the same, it isn't a matter of a *practical* trouble in deduping, just that it can make the refs a little ambiguous to read when you have terms with a numeric suffix.  Purely aesthetic.

[10:21:15.0000] <annevk>
TabAtkins: URL parser may or may not escape it if you put it in raw

[10:21:40.0000] <annevk>
refack: in JavaScript you mean?

[10:21:47.0000] <TabAtkins>
I'm exactly following what HTML says is the valid charset for fragments, and %-escaping the rest.

[10:22:01.0000] <TabAtkins>
If URL and HTML differ, obviously one of them should be fixed. ^_^

[10:22:05.0000] <annevk>
I've no idea what HTML says :-)

[10:22:32.0000] <refack>
annevk: yes, specifically node's (or CommonJS)

[10:22:33.0000] <tobie>
refack: I don't think that's the same assert. ;)

[10:23:00.0000] <TabAtkins>
annevk: Ah, I didn't even realize the HTML links sent me over to URL anyway ^_^ https://url.spec.whatwg.org/#url-fragment-string

[10:23:01.0000] <refack>
Not the "Assert" in the docs, the `require('assert') in the tests

[10:23:03.0000] <annevk>
refack: anyway, I know of no such efforts

[10:23:08.0000] <TabAtkins>
(I *was* wondering when HTML got syntax highlighting...)

[10:23:16.0000] <annevk>
heh

[10:24:01.0000] <tobie>
this throws in FF: (function() { "use strict"; document.createElement("div").attributes["3"] = 123 })();

[10:24:18.0000] <annevk>
TabAtkins: anyway, if it works it's fine, since we can't break that, I just know there's a couple of minor issues and browser differences left, but they might not get exposed when simply navigating

[10:24:28.0000] <tobie>
But not this: document.createElement("div").attributes["3"] = 123;

[10:24:28.0000] <TabAtkins>
kk

[10:25:38.0000] <tobie>
Is this a known issue?

[10:26:39.0000] <annevk>
tobie: haven't seen that discussed before

[10:26:45.0000] <annevk>
tobie: typically IDL doesn't care about strict mode

[10:26:53.0000] <refack>
If I volunteer, is there interest? I know only `node` has an implementation, but it is used by the test e.g. https://github.com/whatwg/console/blob/master/test/tests/timing.js#L3

[10:27:16.0000] <refack>
It is sort of arbitrary, and definatly not rigorous

[10:27:31.0000] <tobie>
annevk: what do you mean by "typically IDL doesn't care about strict mode"

[10:27:53.0000] <annevk>
tobie: no different code path gets taken

[10:28:29.0000] <annevk>
refack: since it's a JavaScript extension I suspect #tc39 or es-discuss is a better place to ask

[10:28:37.0000] <tobie>
annevk: right, so these two things code snippets should not behave differently.

[10:29:07.0000] <tobie>
s/things //

[10:29:16.0000] <annevk>
refack: if there's some interest and someone is willing to present your proposal to the committee thingie they got going on you can write a proposal along the lines of the others: https://github.com/tc39/proposals

[10:29:33.0000] <refack>
hmmm

[10:29:55.0000] <annevk>
tobie: yeah, but maybe this is a weird case where the two worlds intersect? bit out of my depth

[10:30:34.0000] <annevk>
tobie: hmm, there is some stuff that behaves differently based on strict mode: https://heycam.github.io/webidl/#LenientSetter

[10:30:39.0000] <annevk>
tobie: this might just be one of those

[10:30:40.0000] <refack>
thanks, my intuition was that WHATWG would be easier, but I get what you are saying

[10:31:13.0000] <annevk>
refack: if you want it as an extension of the Console API you could do it through WHATWG

[10:31:26.0000] <annevk>
refack: not really sure we have a home for a generic assert library

[10:32:15.0000] <annevk>
refack: (and I'm also not entirely sure we need one, but that's a different discussion)

[10:32:30.0000] <tobie>
annevk: right, it didn't seem like NamedNodeMap was one of those, though.

[10:32:54.0000] <refack>
That was my lead, but I see how tc39 should be my first attempt. I agree it not an eco-system interop issue (yet)

[10:35:59.0000] <annevk>
tobie: I suspect it is looking at the algorithms

[10:37:41.0000] <annevk>
tobie: if there's no setter for a property you end up throwing in strict mode

[10:38:01.0000] <annevk>
tobie: that's what I think is happening

[10:38:17.0000] <annevk>
tobie: and there's no setter since NamedNodeMap only defines a getter

[10:42:32.0000] <tobie>
annevk: where is that defined, though? I thought this was only for readonly attributes not all properties?

[10:46:05.0000] <annevk>
tobie: it's no different from a readonly attribute afaict

[10:46:28.0000] <annevk>
tobie: a readonly attribute is a property with a getter and an undefined setter

[10:46:32.0000] <annevk>
tobie: this is no different

[10:46:39.0000] <annevk>
tobie: back tomorrow

[10:46:50.0000] <tobie>
annevk: night

[11:09:53.0000] <tobie>
annevk: OK, I got it now. You're right. And this has been fixed in chrome canary too.

[11:49:11.0000] <Domenic>
tobie: annevk: in general returning "false "from various meta-object protocol operations will throw in strict and no-op in sloppy. So this is pretty widespread even if it's not obviously so.

[11:49:49.0000] <Domenic>
refack: those console tests are kind of old and maybe should be removed; the canonical ones are at https://github.com/w3c/web-platform-tests/tree/master/console

[11:50:25.0000] <Domenic>
Note how they are nicely written in .any.js format so you can run them easily in Node :)

[11:52:12.0000] <refack>
Domenic: where's the harness? I'd like to take inspiration from it.

[11:52:48.0000] <Domenic>
refack: well Node has an implementation at https://github.com/nodejs/node/blob/master/test/common/wpt.js

[11:54:18.0000] <refack>
boo 😜 that uses require('assert')... I want to make 'assert' better

[11:55:42.0000] <Domenic>
Oh well I kind of doubt Node will want to change its assert module much

[11:55:59.0000] <Domenic>
But there's https://github.com/w3c/web-platform-tests/blob/master/resources/testharness.js

[11:56:10.0000] <Domenic>
I'm not sure it's super-great code tbh

[11:56:11.0000] <tobie>
Domenic: right.

[11:56:20.0000] <tobie>
Domenic: looking at https://github.com/TimothyGu/webidl-keys-test/blob/master/test-named-node-map.js#L23

[11:57:22.0000] <tobie>
Domenic: shouldn't that be a no-op by virtue of  NamedNodeMap not having a named prop setter?

[11:58:50.0000] <Domenic>
tobie: doesn't it fall through to https://heycam.github.io/webidl/#legacy-platform-object-set step 3?

[11:59:13.0000] <Domenic>
then it goes to https://heycam.github.io/webidl/#legacy-platform-object-defineownproperty step 2...

[12:00:05.0000] <tobie>
It falls through to step 2, first

[12:00:09.0000] <tobie>
no>

[12:00:13.0000] <tobie>
no?

[12:00:37.0000] <Domenic>
step 2 is just LegacyPlatformObjectGetOwnProperty right?

[12:00:56.0000] <Domenic>
I think it is a no-op because we end up in https://heycam.github.io/webidl/#legacy-platform-object-defineownproperty step 2.2

[12:01:14.0000] <Domenic>
wait no

[12:01:30.0000] <tobie>
Right, so it comes back with a desc object that has writable as false, no?

[12:01:31.0000] <Domenic>
it is not a no-op because we reach 2.2, but the condition is not met, so we go on to stop 3 + 4

[12:02:03.0000] <Domenic>
correct, writable = false

[12:02:06.0000] <Domenic>
ok

[12:02:08.0000] <Domenic>
so it will *throw*

[12:02:12.0000] <tobie>
in strict

[12:02:21.0000] <Domenic>
yep

[12:02:23.0000] <tobie>
and no-op elsewhere

[12:02:23.0000] <Domenic>
which is what this test is

[12:02:25.0000] <Domenic>
yep

[12:02:46.0000] <tobie>
So going back to the test

[12:03:35.0000] <tobie>
ownProp should not show up in Reflect.ownKeys

[12:03:43.0000] <Domenic>
I agree

[12:03:54.0000] <Domenic>
Although the fact I stumbled through several different outcomes implies my judgment might be suspect

[12:04:03.0000] <tobie>
heh

[12:04:50.0000] <tobie>
well, fwiw, both FF and Chrome Canary throw in that case for indexed prop in strict mode.

[12:05:03.0000] <Domenic>
That's good at least :)

[12:05:05.0000] <tobie>
haven't tested beyond, yet.

[12:05:13.0000] <Domenic>
This is good stuff in general

[12:05:20.0000] <Domenic>
TimothyGu remains amazing

[12:05:30.0000] <Domenic>
And thanks for backing him up with more testing work

[12:05:39.0000] <Domenic>
slash fact-checking

[12:06:29.0000] <tobie>
yes, it's really great to see people coming in with super solid PRs like this.

[12:06:50.0000] <Domenic>
I think the Bikeshed conversion can take some credit

[12:07:06.0000] <refack>
Domenic: thanks

[12:07:09.0000] <tobie>
I was about to say so

[12:07:19.0000] <TabAtkins>
Yeah, the old webidl was *so damn hard* to edit.

[12:07:31.0000] <TabAtkins>
Moving to any modern processor would have improved that.

[12:39:03.0000] <tobie>
Domenic: so I think I made an error earlier

[12:39:15.0000] <tobie>
Domenic: in https://heycam.github.io/webidl/#legacy-platform-object-set

[12:40:14.0000] <tobie>
Step 2 has last argument of  LegacyPlatformObjectGetOwnProperty see to true

[12:41:14.0000] <tobie>
Domenic: which means that we fall through to 3 in LegacyPlatformObjectGetOwnProperty

[12:41:37.0000] <tobie>
Domenic:  (As ignoreNamedProps is true)

[12:43:13.0000] <tobie>
/me grumbles something about using ignoreNamedProps as a name for a boolean

[12:57:10.0000] <tobie>
Domenic: documented those here: https://github.com/w3c/web-platform-tests/commit/0d8209f

[13:02:03.0000] <tobie>
Domenic: and here: https://github.com/w3c/web-platform-tests/pull/6786

[14:12:20.0000] <edsu>
hi all, i'd be curious about anyone's feedback on this proposal to allow rel=bookmark to be used with <link> https://github.com/whatwg/html/issues/2899

[16:10:35.0000] <MikeSmith>
https://stackoverflow.com/questions/45578828/dataset-vs-setattribute-performance


2017-08-09
[19:51:22.0000] <wanderview>
yhirano__: this might interest you: https://bugs.chromium.org/p/chromium/issues/detail?id=753646

[20:04:42.0000] <yhirano__>
wanderview: thanks

[00:18:07.0000] <MikeSmith>
KevinMarks_: rel=service.post apparently used by Google Blogger? (for a long time now)

[00:18:11.0000] <MikeSmith>
https://developers.google.com/blogger/docs/2.0/developers_guide_protocol

[00:18:24.0000] <MikeSmith>
but not mentioned anywhere on http://microformats.org/wiki/existing-rel-values

[00:18:52.0000] <MikeSmith>
immedidate context is https://github.com/validator/validator/issues/544

[00:31:47.0000] <a-ja>
MikeSmith, https://github.com/validator/validator/issues/545

[00:32:05.0000] <MikeSmith>
a-ja: thanks

[00:32:23.0000] <a-ja>
finally got an ID

[00:35:19.0000] <MikeSmith>
well then, welcome to github :)

[00:46:55.0000] <TimothyGu>
tobie: thanks for cleaning up my makeshift tests :)

[01:03:46.0000] <tobie>
TimothyGu: I'm essentially using this as an opportunity to figure out what's happening in his area of the spec. So thanks for that!

[01:04:20.0000] <tobie>
TimothyGu: FYI I'm ooo until Monday so don't expect a lot of movement until then.

[01:15:26.0000] <TimothyGu>
tobie: that's alright! I'll revisit the discussion you had with Domenic first

[01:27:45.0000] <tobie>
TimothyGu: Yeah. I was wrong btw. See the tests I added for [[Set]].

[02:26:10.0000] <a-ja>
it's about <time>

[02:49:00.0000] <MikeSmith>
annevk: thanks for responding on that SO question. I had forgotten about the event-listener thing

[03:29:31.0000] <MikeSmith>
annevk: As I just mentioned in the comment there I think we really need a note in the XHR spec explaining this. But despite having chatted with you know about this several times, I find I still don’t even know how to explain how the requirements in the current spec lead to this behavior

[03:30:31.0000] <MikeSmith>
annevk: I assume the relevant requirement is step 37 of https://fetch.spec.whatwg.org/#dom-request

[03:30:48.0000] <MikeSmith>
> If body is non-null and body’s source is null, then run these substeps:

[03:30:57.0000] <MikeSmith>
> Set r’s request’s use-CORS-preflight flag.

[03:31:20.0000] <MikeSmith>
(since that is the only place in the XHR spec where the use-CORS-preflight flag is set)

[03:31:37.0000] <MikeSmith>
but I have no idea how that relates to event listeners being set

[03:32:33.0000] <MikeSmith>
d’oh

[03:32:36.0000] <MikeSmith>
never mind

[03:32:48.0000] <MikeSmith>
I was looking at the fetch spec..

[03:36:27.0000] <MikeSmith>
/me decides that’s a sign it’s time for him to take a break

[05:05:01.0000] <nox>
⛔️

[05:05:04.0000] <nox>
MikeSmith: Like this?

[05:20:08.0000] <MikeSmith>
nox: :)

[05:45:07.0000] <JakeA>
annevk: I'm changing "A Response object also has an associated Headers object" to "A Response object also has associated headers, a Headers object", any objections? Doing the same for requests

[05:45:48.0000] <annevk>
JakeA: sure "a Headers object" could maybe be between parenthesis

[05:46:10.0000] <annevk>
that's mostly how we indicate types these days

[05:46:14.0000] <annevk>
though I suppose it varies

[05:46:31.0000] <JakeA>
Gotcha

[07:13:17.0000] <annevk>
JakeA: Edge is first to support abortable fetch?!

[07:13:29.0000] <annevk>
Weird, but also great

[07:13:51.0000] <JakeA>
annevk: I know right!! I was quite surprised

[07:14:06.0000] <JakeA>
I filed the bug but figured they'd get to it eventually

[07:14:12.0000] <JakeA>
one week later…

[07:14:30.0000] <JakeA>
Although I guess we'd need to see it to call them the winners :D

[07:17:06.0000] <annevk>
I suspect it'll be in Firefox Nightly somewhere in September, unless there's a lot of other things to take care of suddenly

[07:17:41.0000] <annevk>
I'll have another look at the spec tomorrow with Domenic's feedback in mind and also have a closer look at how it should work together with XHR

[07:18:03.0000] <JakeA>
annevk: I'll try to land some changes before then

[07:18:38.0000] <JakeA>
addressing Domenic's feedback now. But I kinda pulled on a string by adding headers to both request and response :D

[07:19:03.0000] <JakeA>
pulled on a thread

[07:19:08.0000] <JakeA>
whatever the saying is

[07:19:36.0000] <annevk>
JakeA: ah yeah, it might be worth landing that separately if easy to split

[07:21:05.0000] <JakeA>
annevk: I'm not sure it is, since it's part of clone() and the constructor

[07:21:28.0000] <annevk>
JakeA: I meant the initial change of turning it into a concept

[07:21:52.0000] <annevk>
which would be a purely editorial change

[07:22:35.0000] <JakeA>
annevk: I'll see if I can split it out

[07:22:53.0000] <gsnedders>
JakeA, annevk: I wonder if it's just simple-easy to do based on whatever Windows API they're using?

[07:23:04.0000] <JakeA>
should have thought about that earlier

[07:23:49.0000] <JakeA>
gsnedders: maybe… I guess it depends if the wired the service worker side in

[07:30:24.0000] <annevk>
From the speed I suppose it was somewhat easy in Firefox too, mostly delayed now due to vacation

[07:30:37.0000] <annevk>
But not sure if we got all the edge cases such as clone() correct

[07:31:42.0000] <JakeA>
Especially since it wasn't spec'd or tested

[07:36:50.0000] <annevk>
yup

[07:48:54.0000] <MikeSmith>
annevk: https://github.com/whatwg/xhr/pull/148 in hopes that it helps clarify things for people

[07:49:41.0000] <MikeSmith>
also I guess I should update the MDN CORS article to make it clear there too

[10:00:34.0000] <annevk>
MikeSmith: I'll have a look tomorrow, probably reasonable to have something

[10:00:43.0000] <annevk>
/me attempts to register the Refresh header with IANA

[10:05:30.0000] <annevk>
wanderview: slow clap for https://twitter.com/wanderview/status/895320296823046145

[10:05:34.0000] <annevk>
wanderview: that whole thread is amazing

[10:32:23.0000] <wanderview>
annevk: the funny thing (to me), is I actually saw the 7ms DOMContentLoaded first and was like "woah!"... then I saw the render... sad trombone...

[10:33:42.0000] <annevk>
heh

[10:37:54.0000] <wanderview>
annevk: and for what its worth the site totally does render with streams if I include the right patchset in my build

[10:50:24.0000] <TabAtkins>
Man tho, how'd they even get 7ms. I guess a SW doing the rendering?

[10:51:05.0000] <TabAtkins>
Here I am all proud of my blog getting content and first paint in 100ms and full rendering in 400. ^^_

[10:52:06.0000] <wanderview>
TabAtkins: yea, it was a service worker that was already running... and probably some lucky timing with main thread runnables

[10:52:33.0000] <wanderview>
TabAtkins: and it was the DOMContentLoaded number... I guess not first paint

[13:49:50.0000] <MikeSmith>
oh I like the background image of https://twitter.com/wanderview/

[13:50:09.0000] <MikeSmith>
wanderview: that’s from the imperial palace grounds?

[13:50:22.0000] <wanderview>
MikeSmith: thanks!  yep!  I took it the day before the service worker meeting in April

[13:50:36.0000] <MikeSmith>
ah super

[13:50:37.0000] <wanderview>
MikeSmith: btw, sorry I didn't really get to talk with you much at the meeting

[13:50:51.0000] <MikeSmith>
no worries, let’s talk more next time!

[13:51:00.0000] <wanderview>
cool... I'll be at tpac

[13:51:09.0000] <MikeSmith>
yeah me too

[13:51:11.0000] <MikeSmith>
let’s have another service worker meeting Tokyo

[13:51:29.0000] <MikeSmith>
actually I’d like we have a service worker meeting in China

[13:51:48.0000] <MikeSmith>
would be easy to arrange if the group wanted to

[13:52:25.0000] <wanderview>
I must admit the trans-pacific flights are not my first choice :-) but I know a lot of people have to make long trips, so I can't really complain

[13:52:59.0000] <MikeSmith>
yeah the flight part sucks

[13:53:10.0000] <wanderview>
"not in the usa" seems more likely in the future, though

[13:53:24.0000] <wanderview>
I'm guessing

[13:54:21.0000] <MikeSmith>
as far as China, having it in Hangzhou would make it more appealing than Beijing or elsewhere

[13:54:34.0000] <MikeSmith>
Hangzhou is Alibaba land

[13:54:38.0000] <MikeSmith>
HQ

[13:55:11.0000] <MikeSmith>
anyway btw Japan is a one of the likely candidate locations for TPAC 2019

[13:55:21.0000] <wanderview>
where is 2018?

[13:56:03.0000] <MikeSmith>
not sure it’s been announced yet

[13:56:15.0000] <MikeSmith>
in Europe, but unfortunately not in Lisbon

[13:56:46.0000] <MikeSmith>
tried to get it in Lisbon again but scheduling didn’t work out, we had a conflict with IETF the same week

[13:57:34.0000] <MikeSmith>
ah TPAC 2018 location was announced already

[13:57:36.0000] <MikeSmith>
Lyon

[13:57:51.0000] <MikeSmith>
which is very very nice too

[13:58:00.0000] <MikeSmith>
great food, beautiful old town

[13:59:34.0000] <wanderview>
cool

[13:59:49.0000] <wanderview>
I've never been... not quite sure what to expect yet

[14:26:14.0000] <TabAtkins>
wanderview: Some WG meetings, but the most useful part is all the "hallway meetings" you have with people. So many useful things come out of finally getting 5 minutes of face-to-face time with the right person.

[14:35:01.0000] <jgraham>
MikeSmith: Not sure Lyon isn't better than Lisbon

[14:35:38.0000] <jgraham>
Although Lisbon was also better than anywhere in the bay area, or China, or Hokkaido

[14:36:07.0000] <jgraham>
(I mean Japan is fun ofc, but Hokkaido in Autumn is not the best of Japan)

[14:36:42.0000] <jgraham>
Tokyo would be pretty great

[14:37:15.0000] <jgraham>
Probably won't go if it's in China again. Too much hassle for a place where the internet doesn't work

[14:38:03.0000] <jgraham>
(I appreciate Shenzhen is probably not the best of China)

[14:38:31.0000] <jgraham>
Anyway, nice to talk as if the world will still exist in two years and not be some nuclear wasteland

[14:42:46.0000] <jgraham>
Anyway these have been unsolicited opinions on TPAC locations

[14:43:01.0000] <jgraham>
One more: At least it isn't Orlando

[14:45:47.0000] <gsnedders>
/me probably wouldn't go if it were in China either

[14:45:50.0000] <gsnedders>
well maybe Hong Kong

[15:23:15.0000] <MikeSmith>
haha at least it isn't Orlando indeed

[15:25:10.0000] <MikeSmith>
anyway about TPAC, 100% agreed with TabAtkins about the bestest thing being hallway meetings, chance to talk with people in the real world

[15:46:33.0000] <gsnedders>
wait people exist in the real world

[15:46:59.0000] <gsnedders>
or is just ms2ger and bz that don't?


2017-08-10
[18:37:05.0000] <MikeSmith>
I’m curious why the Safari team chose to prioritize implementation of navigator.sendBeacon over other things

[18:37:32.0000] <MikeSmith>
context being, it’s one of the features that shipped in the latest Safari Technology Preview

[18:37:43.0000] <MikeSmith>
https://developer.apple.com/safari/technology-preview/release-notes/

[18:37:58.0000] <MikeSmith>
maybe that have some particular use for it

[18:38:35.0000] <MikeSmith>
I don’t know enough about teh use cases for sendBeacon to be able to guess at what that might be though

[18:39:14.0000] <MikeSmith>
I guess the level of effort for implementing it might be significantly lower relative to a lot other things

[00:11:53.0000] <annevk>
MikeSmith: could also be something like Facebook saying they need it

[01:16:55.0000] <MikeSmith>
annevk: ah yeah

[01:55:23.0000] <foolip>
Regarding https://github.com/whatwg/whatwg.org/pull/36, where should we put the HTML FAQ? annevk Domenic MikeSmith ^

[01:55:42.0000] <MikeSmith>
/me looks

[01:56:02.0000] <foolip>
An FAQ.md in https://github.com/whatwg/html/ perhaps? We don't really have another place to put things....

[01:59:07.0000] <MikeSmith>
foolip: yeah that

[01:59:07.0000] <botie>
yeah that is definitely an algorithm.

[01:59:13.0000] <MikeSmith>
I think that would be fine

[01:59:33.0000] <foolip>
MikeSmith: ok, so converting to markdown then...

[02:00:42.0000] <MikeSmith>
thanks for doing the work on that

[02:03:31.0000] <foolip>
MikeSmith: has bob asked you to push all the buttons needed to launch the new PR results app?

[02:06:57.0000] <MikeSmith>
foolip: he has the power

[02:07:01.0000] <MikeSmith>
to do it all

[02:07:43.0000] <MikeSmith>
can’t recall what it’s waiting on at this point but not me

[02:11:33.0000] <annevk>
foolip: yeah I guess that's reasonable for now

[02:11:47.0000] <foolip>
annevk: working on it

[02:48:21.0000] <MikeSmith>
getting a “Rats! WebGL hit a snag.” message in Gmail and now curious to find out what Gmail is using WebGL for

[03:08:30.0000] <foolip>
annevk, MikeSmith: https://github.com/whatwg/html/pull/2903

[03:10:35.0000] <foolip>
parts of the FAQ feel a bit dated, should we add a warning to say that it's being revised, or something like that?

[03:10:58.0000] <foolip>
to not give the impression that touching it again is a re-commitment to everything it says

[03:11:48.0000] <annevk>
You should feel free to update it

[03:11:55.0000] <annevk>
Though maybe as a separate commit?

[03:12:32.0000] <foolip>
annevk: yeah, actually reading it and making it more approachable would be more work than I'm signing up for today, thought I'd just spend a few hours

[03:39:03.0000] <MikeSmith>
merged

[03:40:24.0000] <MikeSmith>
if you don’t have time soonish, I can volunteer to take a shot at updating it, especially the dated parts you mentioned

[03:44:38.0000] <JakeA>
annevk: I went for "associated headers" rather than "an associated headers" as the latter sounds clunky, but I guess it's customary to treat the property "headers" as a singular?

[03:55:45.0000] <annevk>
JakeA: yeah

[03:56:13.0000] <JakeA>
cool, I've made that change

[04:20:50.0000] <foolip>
MikeSmith: thanks for review! and I don't plan to spend time on updating it soon, so that'd be much appreciated

[04:21:04.0000] <foolip>
MikeSmith: https://github.com/whatwg/whatwg.org/pull/36 is now also in good shape

[04:22:07.0000] <foolip>
MikeSmith: in particular, the "other specifications" bit is a bit wrong towards the end now

[04:22:18.0000] <foolip>
MikeSmith: and the overall structure is strange

[06:24:29.0000] <annevk>
JakeA: so what's the idea about how the termination reason bubbles back up to the API?

[06:44:37.0000] <JakeA>
annevk: I'm struggling to find a use for termination reason

[06:44:49.0000] <JakeA>
annevk: maybe it'll become useful again with FetchObserver?

[06:47:57.0000] <annevk>
JakeA: as I pointed out XHR uses it

[06:48:18.0000] <annevk>
JakeA: the other question is whether any termination is an "AbortError"

[06:50:11.0000] <JakeA>
annevk: right now it's only AbortError via the signal

[06:50:17.0000] <JakeA>
TypeError otherwise

[06:51:39.0000] <JakeA>
annevk: maybe it's best to replace termination reason with something else?

[06:53:09.0000] <annevk>
JakeA: that's fine, as long as we don't break XHR

[06:54:44.0000] <JakeA>
annevk: right now, if you otherWindow.fetch() and that window goes away, it's a TypeError rather than an AbortError

[08:06:28.0000] <gsnedders>
is https://www.w3.org/TR/uievents/ the old DOM Level 3 Events spec?

[08:06:52.0000] <Ms2ger>
Yes

[12:11:58.0000] <miketaylr>
what's the story w/ https://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-September/033196.html being down?

[12:12:01.0000] <miketaylr>
any mirrors?

[12:16:09.0000] <miketaylr>
ah ok found it

[12:16:14.0000] <miketaylr>
hosted on lists.w3.org

[14:54:10.0000] <MikeSmith>
miketaylr: yeah some Dreamhost limitation prevents the lists.whatwg.org archives from working with TLS

[14:54:49.0000] <MikeSmith>
I think the only way we could fix it is to move whatwg.org to a different hosting service


2017-08-11
[18:11:35.0000] <miketaylr>
MikeSmith: cool, good to know

[00:16:21.0000] <annevk>
It's rather ridiculous that DreamHost hasn't fixed it given they have integration with Let's Encrypt for quite a while now

[00:27:08.0000] <a-ja>
annevk: "it" being?

[00:27:23.0000] <annevk>
a-ja: lists.whatwg.org

[00:31:32.0000] <a-ja>
can't believe DreamHost still strands virtual hosting on Apache 2.2

[00:52:52.0000] <MikeSmith>
I think our problem with moving off Dreamhost remains that if we did it right it means moving to hosting on a VM with root access (at Digital Ocean or wherever) and that means one or more people would probably need to spend more time doing sysadmin tasks and if it’s just one person who is interested/able to handle that, then they become the bottleneck instead of Dreamhost support and borkedness being

[00:52:58.0000] <MikeSmith>
the problem

[00:52:59.0000] <botie>
the problem is a Bikeshed change

[01:01:17.0000] <a-ja>
MikeSmith, fwiw, Apache's working on a mod_md (as in Managed Domain)...haven't really delved into it too much yet

[01:01:49.0000] <a-ja>
might cut down on the sysadmin

[01:03:12.0000] <MikeSmith>
if we were to move to modern hosting I think one change that would come with it is moving to nginx

[01:03:53.0000] <MikeSmith>
IMHO it doesn’t make sense to do anything new in Apache unless you really have to for some reason

[01:04:43.0000] <a-ja>
haven't seen anything about a built-in acme client for nginx yet

[01:11:13.0000] <MikeSmith>
dunno what acme is

[01:11:21.0000] <MikeSmith>
Let’s Encrypt?

[01:11:26.0000] <a-ja>
yeah

[01:11:47.0000] <MikeSmith>
it has built-in support for easy automated nginx config

[01:11:53.0000] <MikeSmith>
Let’s Encrypt does

[01:12:45.0000] <MikeSmith>
can’t say I’ve ever used it though because I find it easy enough myself to just do that --standalone thing that doesn’t touch server config files

[01:13:04.0000] <MikeSmith>
or --config-only or whatever the actual option is that controls that

[04:29:02.0000] <JakeA>
https://developer.mozilla.org/en-US/Firefox/Releases/55 suggests that Firefox 55 supports async generators, but that doesn't seem to be the case

[04:30:32.0000] <TimothyGu>
JakeA: I think it's only about async generator *methods*

[04:30:51.0000] <TimothyGu>
as in ({ async* f() {} })

[04:38:25.0000] <JakeA>
ahh ok

[05:34:37.0000] <annevk>
SimonSapin: I'm thinking of looking into data URLs since bz asked me to

[05:34:50.0000] <SimonSapin>
annevk: cool

[05:34:50.0000] <annevk>
SimonSapin: does https://gist.github.com/annevk/4287452653921b2b7de35e4208b4a985 look about right for tests?

[05:35:05.0000] <annevk>
SimonSapin: or is there some other angle a potential harness would need to concern itself with?

[05:36:07.0000] <SimonSapin>
annevk: is .text() Unicode?

[05:36:33.0000] <annevk>
SimonSapin: UTF-8 decode

[05:36:55.0000] <SimonSapin>
not using charset from content-type?

[05:37:08.0000] <SimonSapin>
It’d be good to be able to test that

[05:37:15.0000] <annevk>
SimonSapin: no, I guess maybe that rules it out yeah

[05:37:33.0000] <annevk>
Back to our trusted friend <iframe>

[05:37:47.0000] <annevk>
SimonSapin: anything else?

[05:39:38.0000] <SimonSapin>
hmm, ideally there’s be an expected Unicode string for text/*, and and expected byte string for everything else

[05:39:48.0000] <SimonSapin>
but I don’t know how doable that is

[05:40:31.0000] <annevk>
SimonSapin: maybe byte string for everything is good enough since actual decoding of bytes can be tested separately

[05:41:17.0000] <annevk>
SimonSapin: that is, we're concerned that data URLs get turned into proper responses; how does responses get decoded is up to someone else

[05:42:08.0000] <JakeA>
annevk: Is it weird that the cloned request's signal will despatch onabort before the original's?

[05:42:42.0000] <annevk>
JakeA: it surprises me a bit

[05:42:44.0000] <SimonSapin>
annevk: I think we still want to test the extraction of an encoding label from the "charset" param

[05:42:48.0000] <SimonSapin>
ideally

[05:42:54.0000] <annevk>
JakeA: I'd have assumed the original would end up notifying the clone

[05:43:46.0000] <JakeA>
annevk: it does, but the "run algorithms" bit happens before despatching the event

[05:44:00.0000] <annevk>
SimonSapin: that is fair, but maybe that should be a separate set of tests

[05:44:47.0000] <JakeA>
annevk: I guess we could swap those around in the DOM spec. Set flag, despatch event, run algorithms

[05:44:56.0000] <JakeA>
not sure if that would have a negative impact yet

[05:45:03.0000] <SimonSapin>
annevk: one test case I had was data:text/plain%3Bcharset=utf8,%F0%9F%92%A9

[05:45:34.0000] <annevk>
JakeA: ah

[05:45:56.0000] <annevk>
JakeA: I think generally you'd want the event when everything else is done

[05:46:17.0000] <annevk>
JakeA: I guess it depends on what we end up using those algorithms for

[05:46:30.0000] <JakeA>
annevk: In the clone operation I could queue a microtask to despatch the event

[05:46:30.0000] <annevk>
JakeA: or maybe we should have a separate queue for forwarding events

[05:46:49.0000] <JakeA>
microtask seems hacky though

[05:47:09.0000] <annevk>
JakeA: yeah, you'd get weird timing that way

[05:47:19.0000] <JakeA>
separate queue would work

[05:47:51.0000] <annevk>
JakeA: worth asking some other folks if it would actually be bothersome

[05:48:17.0000] <annevk>
SimonSapin: good times 😊

[05:48:31.0000] <annevk>
SimonSapin: I read through your old doc for inspiration already

[05:51:25.0000] <annevk>
SimonSapin: though I do think that charset extraction ought to be identical to that of Content-Type so I'm still inclined to consider that separately and just make sure that matches each other

[05:53:58.0000] <SimonSapin>
isn’t there a form with "parameters" like charset but no MIME type?

[05:56:02.0000] <annevk>
SimonSapin: I haven't seen that, but it'd still need to become a Content-Type value first and then some other code would extract from that

[05:56:18.0000] <JakeA>
annevk: The more I think about it, allowing a signal to have a list of signals that should copy it makes sense. Especially as we might add an API for that in future

[06:15:20.0000] <foolip>
annevk: looks like https://github.com/whatwg/whatwg.org/pull/36 isn't auto-deploying, is there something that needs poking?

[06:17:12.0000] <annevk>
foolip: I suspect we need to update the server public key similar to how I did for resources.whatwg.org

[06:17:27.0000] <annevk>
foolip: although here it's located in .travis.yml

[06:17:54.0000] <annevk>
foolip: yeah, looking at Travis results that's it

[06:17:59.0000] <foolip>
annevk: oh right, that stuff. do you know how to fix it?

[06:18:14.0000] <annevk>
foolip: sure I can do it

[06:20:11.0000] <annevk>
foolip: done

[06:23:52.0000] <foolip>
ok, so https://whatwg.org/faq now works. I have a cached redirect in one browser, but assume it'll soon go away. thanks annevk !

[09:55:59.0000] <annevk>
SimonSapin: you were right btw, data:;charset=shift_jis,%C2%B1 is a thing

[09:56:44.0000] <annevk>
SimonSapin: I guess that means you can't really use a generic MIME type parser

[09:56:48.0000] <annevk>
ugh

[13:14:24.0000] <SimonSapin>
yeah :/

[14:00:24.0000] <Domenic>
I am excited for fixing data: URLs


2017-08-12
[00:21:00.0000] <TimothyGu>
FWIW I wrote some tests for data: URLs for a node module a while a back: https://github.com/TooTallNate/node-data-uri-to-buffer/blob/master/test/test.js

[00:25:12.0000] <TimothyGu>
some things I noticed: Firefox defaults to US-ASCII (well windows-1252) by default for both data:,text and data:text/plain,text, but Chrome uses UTF-8 for data:text/plain,text and US-ASCII data:,text

[00:25:32.0000] <TimothyGu>
just another data point, hope it helps

[03:08:00.0000] <annevk>
TimothyGu: how did you test the defaulting? Did you have a control test that was delivered over HTTP instead?

[03:08:23.0000] <annevk>
TimothyGu: Chrome has a non-standard encoding sniffer, so I'd be very suspect

[03:31:53.0000] <TimothyGu>
annevk: I just navigated to the data: URL. I don't expect fetch/xhr to act any differently though

[03:32:48.0000] <TimothyGu>
I also used a UTF-8 string to test (data:text/plain,%E4%B8%AD%E6%96%87)

[03:32:58.0000] <TimothyGu>
i.e. "中文"

[03:34:12.0000] <annevk>
TimothyGu: I suspect that's just Chrome's behavior when you load a text/plain resource containing those bytes

[03:34:25.0000] <annevk>
TimothyGu: not really related to data URLs

[03:34:47.0000] <TimothyGu>
yeah that's what I think as well

[03:35:32.0000] <TimothyGu>
per RFC data:,text defaults to text/plain;charset=US-ASCII, but data:text/plain,text is just text/plain

[03:35:58.0000] <annevk>
This might be the only location we expose US-ASCII as a string

[03:36:03.0000] <annevk>
So sad

[03:36:48.0000] <TimothyGu>
/me :/

[03:37:23.0000] <TimothyGu>
is there a PR or anything yet for whatwg/fetch?

[03:37:35.0000] <TimothyGu>
for data: that is

[03:42:26.0000] <TimothyGu>
annevk: IMO https://gist.github.com/annevk/4287452653921b2b7de35e4208b4a985 should also have a URL with text/plain but without charset

[03:43:52.0000] <annevk>
TimothyGu: there's nothing, I only worked on it a couple hours yesterday

[03:44:11.0000] <annevk>
TimothyGu: and yeah, need hundreds more tests

[03:45:15.0000] <TimothyGu>
...

[03:46:18.0000] <annevk>
?

[03:49:22.0000] <annevk>
TimothyGu: to be clear, that gist was mostly just a mockup for test format, the plan is to have that on WPT, probably with the tests in some kind of JSON resource again so they can be shared across impls

[03:49:30.0000] <TimothyGu>
just a bit surprised by "hundreds more tests"

[03:49:43.0000] <TimothyGu>
okay, that's wonderful

[03:49:46.0000] <annevk>
TimothyGu: oh, well, data URLs are complex

[03:49:52.0000] <annevk>
in a way

[04:49:47.0000] <Younder>
I'd say faulty URL parsing is the most common problem on the net

[04:50:37.0000] <Younder>
It does not render itself well to regexp parsing

[05:46:35.0000] <Domenic>
How does US-ASCII get exposed?

[05:48:47.0000] <Domenic>
(Fun story: in fifth grade I practiced how to pronounce ASCII, an unfamiliar phrase. Then I went to computer camp and the other kids made fun of me for saying "ay ess see eye eye" instead of "askee".)

[09:17:35.0000] <annevk>
TimothyGu: you should feel free to take over issues from Domenic I think

[09:17:43.0000] <annevk>
TimothyGu: especially if they haven't been touched in a while

[09:17:49.0000] <annevk>
TimothyGu: plenty on his plate

[09:18:23.0000] <annevk>
Domenic: the Content-Type header of the generated response has text/plain;charset=US-ASCII (consistently so across all impls)

[09:18:55.0000] <Domenic>
annevk: and .characterSet and aliases reflect the label, not the encosing name?

[09:19:16.0000] <annevk>
Domenic: .characterSet will be windows-1252

[09:20:08.0000] <Domenic>
Oh ok... Next guess how the header is observable: new Response().headers?

[09:20:18.0000] <annevk>
Domenic: yup

[09:20:54.0000] <Domenic>
Hmm. That's a rather new API... But I guess XHR has the same problem

[09:21:01.0000] <annevk>
Domenic: you can do fetch(dataURL).then(res => console.log(res.headers.get("content-type"))

[09:21:12.0000] <annevk>
Domenic: yeah

[09:21:36.0000] <annevk>
I'm not even going to try change that really

[09:21:57.0000] <annevk>
It's the same across all impls and the RFC sorta requires it

[09:22:48.0000] <annevk>
It's silly, but whatever, it'll likely be way more effort to change that than it's worth, and the most we could change it too is windows-1252 I think, which isn't great

[09:24:19.0000] <annevk>
I'm leaning towards first splitting on "," which is somewhat contrary to the RFC, but is what everyone is doing

[09:24:44.0000] <annevk>
Nobody does data:x/x;x=",",x correctly

[09:37:46.0000] <MikeSmith>
so I’m wondering where it’s defined that using a ReadableStream object for uploads will result in a CORS preflight

[09:38:39.0000] <MikeSmith>
annevk: 👆

[09:42:00.0000] <annevk>
MikeSmith: it's rather opaque

[09:42:31.0000] <annevk>
MikeSmith: the flag is set in step 38.2 of the Request constructor

[09:43:18.0000] <Domenic>
MikeSmith: annevk: I also don't understand that PR. I thought a bunch of other things caused CORS preflights, like unknown headers or methods.

[09:43:20.0000] <annevk>
MikeSmith: the reason we get there is because for a ReadableStream body's source will be null (it's the only object for which that is the case)

[09:44:00.0000] <annevk>
Domenic: that's different, those don't have a need for this flag as we can just check that in the fetch algorithm

[09:44:16.0000] <annevk>
Domenic: for these two cases the fetch algorithm has nothing to go on, that's why the flag is there

[09:44:57.0000] <Domenic>
Hmm OK. Well if we're planning on directing StackOverflow people there, maybe a note explaining that the use-CORS-preflight flag is just one factor in deciding whether to use a CORS preflight would be helpful

[09:45:58.0000] <MikeSmith>
annevk: ah OK yeah I knew that step is the only point in the Fetch spec itself wehre the use-CORS-preflight flag gets set, but didn’t know using a ReadableStream object for uploads would lead to that step

[09:46:26.0000] <annevk>
Domenic: good point, would you mind adding that MikeSmith?

[09:46:27.0000] <MikeSmith>
Domenic: I can expand on the note

[09:46:30.0000] <MikeSmith>
yeah

[09:46:58.0000] <MikeSmith>
I also updated the MDN CORS article for this point recently

[09:49:22.0000] <annevk>
I think yutakahirano did a good job with the streams stuff, but it would've been nice if we had more reviewers and more people invested in the various algorithms

[09:49:40.0000] <annevk>
JakeA's been reviewing a bit due to cancelation integration which has helped I think

[09:53:07.0000] <annevk>
I keep being surprised that you need something like Uint8Array to access data in an ArrayBuffer

[10:00:35.0000] <MikeSmith>
OK, pushed an update do that PR

[10:00:41.0000] <MikeSmith>
now reads:

[10:00:53.0000] <MikeSmith>
> The use-CORS-preflight flag being set is just one of several conditions that can result in a CORS-preflight request. The use-CORS-preflight flag will be set if either one or more event listeners are registered on an XMLHttpRequestUpload object, or else if a ReadableStream object is used for uploads.

[10:01:14.0000] <MikeSmith>
/me steps away now to get some sleep


2017-08-13
[19:03:22.0000] <rniwa>
anyone here?

[19:10:55.0000] <xfq>
yep

[19:12:37.0000] <MikeSmith>
rniwa: yep2

[19:12:48.0000] <MikeSmith>
rniwa: one more yep and you can ship

[19:13:25.0000] <rniwa>
MikeSmith: so DataTransfer is quite a bit of mess...

[19:14:08.0000] <MikeSmith>
agreed :)

[19:14:55.0000] <MikeSmith>
seems like all of drag and drop is a mess

[19:15:27.0000] <MikeSmith>
waiting to hear you say you gonna fix it all :)

[19:17:41.0000] <rniwa>
MikeSmith: e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1199729 means that Firefox would let you keep accessing dataTransfer.items, files, etc...

[19:17:48.0000] <rniwa>
while other browsers won't.

[19:18:05.0000] <MikeSmith>
/me looks

[19:18:06.0000] <rniwa>
so dataTransfer.files.length change in Blink/WebKit but not in Gecko

[19:18:28.0000] <rniwa>
my goodness, someone is using nic name of "so".

[19:18:30.0000] <rniwa>
this is very confusing.

[19:18:34.0000] <MikeSmith>
heh

[19:18:44.0000] <MikeSmith>
so what does the spec say?

[19:18:50.0000] <MikeSmith>
or it doesn’t say?

[19:18:56.0000] <MikeSmith>
/me is still reading the bug

[19:19:33.0000] <MikeSmith>
so the gecko behavior or just non-conforming, right?

[19:19:39.0000] <MikeSmith>
as far as what the bug says

[19:19:52.0000] <rniwa>
MikeSmith: as far as I read the spec, Blink/WebKit behavior implements this correctly

[19:20:42.0000] <MikeSmith>
the problem described in that bug seems different than what you just described btw

[19:21:46.0000] <MikeSmith>
oh, “means that Firefox would let you keep accessing dataTransfer.items, files, etc”

[19:22:04.0000] <rniwa>
MikeSmith: yeah

[19:22:29.0000] <rniwa>
it took me a while to decipher what the spec was trying to say

[19:22:37.0000] <MikeSmith>
OK yeah the word “Protected” threw me off

[19:23:03.0000] <MikeSmith>
I didn’t realize that was a specific dfn’ed term in the spec

[19:23:12.0000] <rniwa>
MikeSmith: see step 13 in https://html.spec.whatwg.org/multipage/dnd.html#fire-a-dnd-event

[19:23:42.0000] <MikeSmith>
“the data itself is unavailable”

[19:24:04.0000] <MikeSmith>
/me looks at https://html.spec.whatwg.org/multipage/dnd.html#fire-a-dnd-event

[19:24:35.0000] <MikeSmith>
rniwa: that seems clear enough to me

[19:24:56.0000] <MikeSmith>
but then I’m not implementing it..

[19:25:32.0000] <MikeSmith>
hmm though the first step is “If no specific related target was provided, set related target to null.”

[19:26:09.0000] <rniwa>
MikeSmith: it's step 3

[19:26:18.0000] <MikeSmith>
yeah I see that now

[19:26:23.0000] <rniwa>
it's really annoying that all these algorithm based spec text gets out of date easily

[19:26:29.0000] <MikeSmith>
yeah

[19:26:41.0000] <MikeSmith>
well I will PR that one right now

[19:26:45.0000] <MikeSmith>
before I forget

[19:26:51.0000] <MikeSmith>
(unless you have already)

[19:35:25.0000] <MikeSmith>
https://github.com/whatwg/html/pull/2907

[19:45:02.0000] <rniwa>
MikeSmith: the change looks great but I don't have the commit access to the repo

[20:02:28.0000] <MikeSmith>
yeah I'

[20:02:30.0000] <MikeSmith>
oofs

[20:02:50.0000] <MikeSmith>
yeah I’ll just wait for Domenic or annevk to review it

[20:03:47.0000] <MikeSmith>
a meta issue here is that ideally we should be writing those algorithms in a way where references like that get automatically updated if a step moves

[20:04:08.0000] <MikeSmith>
maybe bikeshed has some magic for that

[20:04:49.0000] <MikeSmith>
but it’s obviously pretty brittle to have references to step numbers hardcoded like that

[20:06:26.0000] <MikeSmith>
and it’s imaginable that in some cases it could cause real implementation bugs, if the changed step number being referenced isn’t obviously the wrong step as it was in this case

[06:36:07.0000] <TimothyGu>
annevk: ok, thanks. it's summer break for me so lots of time on my hand

[12:54:21.0000] <zcorpan-OOO-14Au>
Hello


2017-08-14
[18:21:10.0000] <MikeSmith>
CZ

[22:22:32.0000] <botie>
zcorpan, at 2017-06-25 09:26 UTC, MikeSmith said: should the checker not report an error for `&;`? https://github.com/validator/validator/issues/529

[22:49:52.0000] <MikeSmith>
of course nm that zcorpan

[22:49:57.0000] <MikeSmith>
very old

[22:50:33.0000] <zcorpan>
Yeah, saw it was resolved already

[00:31:14.0000] <annevk>
smaug____: https://github.com/whatwg/html/issues/2710

[00:35:32.0000] <annevk>
zcorpan: would you have time to review the WPT changes in https://bugzilla.mozilla.org/show_bug.cgi?id=1389274?

[00:35:47.0000] <annevk>
zcorpan: I'll have a look as well, but it seems you'd know more about how that method works at this point than I do

[00:40:16.0000] <annevk>
zcorpan: I think the specification is wrong actually

[00:59:36.0000] <zcorpan>
annevk: https://github.com/w3c/csswg-drafts/pull/1505 is probably relevant

[01:00:37.0000] <annevk>
zcorpan: making omitted and undefined different is pretty grotesque

[01:00:52.0000] <annevk>
zcorpan: there's only a couple of legacy APIs that need that

[01:01:51.0000] <zcorpan>
annevk: the new change makes them not be different

[01:02:28.0000] <annevk>
zcorpan: sorry, I assumed false was the default

[01:02:49.0000] <annevk>
zcorpan: are the dictionary defaults also the same as passing true?

[01:03:56.0000] <zcorpan>
annevk: no, they are not. {} is center-center, rationale is that center-center is a common case so there should be a convenient way to do that

[01:04:23.0000] <tobie>
zcorpan: the boolean's there for backwards compat, right?

[01:04:32.0000] <zcorpan>
annevk: but i think this is not yet interoperable so there is still room to change it

[01:04:37.0000] <zcorpan>
tobie: yeah

[01:05:34.0000] <annevk>
zcorpan: shouldn't you have gone with a bunch of enum values then if you wanted convenience?

[01:05:36.0000] <tobie>
zcorpan: I was just wondering if it might be worth keeping it as two overloading methods for the sake of pointing that out.

[01:06:11.0000] <annevk>
zcorpan: I don't think it's a good idea that for some APIs {} is magical and gives you different defaults than undefined

[01:06:34.0000] <annevk>
tobie: overloading is generally best avoided imo

[01:06:56.0000] <annevk>
tobie: it just leads to confusing argument handling, especially around omission and undefined

[01:07:47.0000] <tobie>
annevk: oh, that's a good point. I was just going for the split legacy stuff from non-legacy stuff. But maybe that causes more issues than it solves.

[01:07:48.0000] <zcorpan>
annevk: an enum argument isn't as extensible as a dictionary

[01:08:30.0000] <zcorpan>
annevk: personally i think i would prefer if {} means the same as passing true

[01:08:41.0000] <tobie>
zcorpan: are you suggesting there's a finite number of strings?

[01:08:44.0000] <tobie>
/me ducks

[01:08:44.0000] <annevk>
zcorpan: that's true, but if there's also a low-level pixel instruction set you might not need much high-level flexibility

[01:09:33.0000] <annevk>
zcorpan: I think you should make that change, having this API be different from others for the sake of convenience for the couple of folks that remember it's different isn't worth it

[01:10:07.0000] <zcorpan>
annevk: ok. i'll follow up. thanks

[01:10:50.0000] <annevk>
zcorpan: I filed https://github.com/w3c/csswg-drafts/issues/1720 btw

[01:28:22.0000] <annevk>
zcorpan: also filed https://github.com/w3ctag/design-principles/issues/73 to get this all covered in the design principles

[01:29:37.0000] <zcorpan>
annevk: thanks. I just finished drafting an issue, I'll comment it in your issue instead :-)

[02:21:55.0000] <annevk>
Hmm, could it be that atob(_X_) and data:;base64,_X_ are identical?

[02:22:24.0000] <annevk>
The YQ and YR examples from atob() produce identical results

[02:26:23.0000] <annevk>
Browsers actually using a shared primitive is somewhat surprising

[02:31:40.0000] <annevk>
Wow, it seems shared

[02:31:47.0000] <annevk>
Hurray?

[02:44:25.0000] <annevk>
beverloo: is https://github.com/whatwg/html/issues/351 still something you want to pursue?

[02:52:08.0000] <annevk>
TimothyGu: btw, as a reference, html/webappapis/atob/base64.html has 370 tests for btoa/atob; so a hundred or so tests could be just for base64 handling

[03:09:18.0000] <zcorpan>
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8536472/ 🎉 (Align the innerText setter with the spec and Gecko FIXED, FLIGHTED)

[03:18:05.0000] <Ms2ger>
I wonder who "Simon P." and "Arron E." are

[03:25:48.0000] <zcorpan>
Simon P. would be me

[03:28:36.0000] <jgraham>
zcorpan: If only they had waited another 8 days

[03:29:39.0000] <Ms2ger>
Or four

[03:31:51.0000] <zcorpan>
I guess Arron E. is https://github.com/arronei

[03:33:06.0000] <zcorpan>
jgraham: why?

[03:33:38.0000] <jgraham>
zcorpan: Just so it took exactly one year from filing to fixing

[03:34:29.0000] <Ms2ger>
Is it showing different dates to you?

[03:35:31.0000] <JakeA>
annevk: thinking more about this AbortSignal thing. It still feels like firing the event before the algorithms makes sense. This would match other events like "click" where the event comes before the default action.

[03:37:15.0000] <annevk>
JakeA: you mean that when the event needs to be forwarded it fires later on the signal that forwarded it?

[03:37:37.0000] <annevk>
JakeA: I'm fine with the current behavior, I was mostly wondering whether we should run it by some other people

[03:38:26.0000] <annevk>
JakeA: I'm okay with just going for it and having at least one test and attempt to revisit if it's a fatal issue somehow (which seems doubtful)

[03:39:07.0000] <JakeA>
annevk: I'll create an issue for it. Any idea who to cc? mkwst & jyasskin as they're the other users of AbortSignal I guess

[03:41:11.0000] <annevk>
JakeA: Domenic and maybe bterlson and wycats?

[03:41:21.0000] <JakeA>
ta

[03:49:23.0000] <jgraham>
Ms2ger: I saw filed on the 18th and fixed on the 10th

[03:50:08.0000] <Ms2ger>
Doh

[03:50:21.0000] <zcorpan>
foolip: thanks for taking care of DOMRectList PRs

[04:07:34.0000] <mkwst>
JakeA: Short answer: I don't have strong feelings about the timing semantics of the signal. I think your suggestion around timing makes sense, but I think WebAuthn will be fine either way.

[04:08:14.0000] <mkwst>
So, +1 to consistency, but I'm happy to defer to folks with opinions if there's a good reason for the current ordering.

[04:10:17.0000] <JakeA>
mkwst: ta!

[04:11:06.0000] <mkwst>
While I'm here: annevk, how would you feel about not treating `gopher` as a totally special scheme anymore?

[04:12:12.0000] <annevk>
mkwst: doesn't seem worth the churn, but okay if everyone wants that

[04:14:26.0000] <mkwst>
annevk: Sounds reasonable. It's not a valuable change in any real sense, but I don't like that Chrome's URL library has special cases for `gopher`. It would be nicer to remove them, given that we're never ever going to add support for the underlying protocol.

[04:15:24.0000] <annevk>
mkwst: yeah, I never quite understood why that existed to be fair

[04:24:02.0000] <TimothyGu>
annevk: wow, I mean thanks

[04:29:24.0000] <jgraham>
annevk: Want to approve https://github.com/w3c/web-platform-tests/pull/6858 ?

[04:30:04.0000] <hsivonen>
MikeSmith: if https://lists.w3.org/Archives/Public/public-review-announce/2017Aug/0004.html passes, are you going to trim http://www.w3.org/1999/xhtml ?

[04:32:58.0000] <foolip>
zcorpan: no problem, and welcome back!

[04:33:29.0000] <zcorpan>
thanks

[04:35:12.0000] <foolip>
zcorpan: wanna stamp https://github.com/w3c/web-platform-tests/pull/6870?

[04:36:42.0000] <zcorpan>
done

[04:37:08.0000] <foolip>
zcorpan: tack

[04:38:37.0000] <annevk>
jgraham: I rejected it

[04:39:00.0000] <jgraham>
annevk: That's fine too

[04:39:18.0000] <annevk>
good 😊

[04:40:53.0000] <annevk>
hsivonen: that namespace document should also have a big fat warning not to copy the address bar

[04:41:55.0000] <annevk>
hsivonen: otherwise it goes pretty quickly from follow your nose to fall on your nose

[04:42:03.0000] <hsivonen>
annevk: indeed!

[04:44:26.0000] <annevk>
JakeA: can you squash and merge yourself these days?

[04:44:53.0000] <annevk>
JakeA: https://github.com/w3c/web-platform-tests/pull/6736 is good to go, just needs a new commit title/body

[04:45:09.0000] <JakeA>
annevk: I can!

[04:45:12.0000] <JakeA>
Will do that now

[04:53:05.0000] <hsivonen>
annevk: FWIW, telemetry says that on Firefox release 55, of 4.9 million sessions opted into opt-in telemetry, 714 had the ISO-2022-JP decoder instantiated at least once

[04:54:23.0000] <hsivonen>
annevk: well, at least it's more than <isindex>...

[04:54:51.0000] <annevk>
hsivonen: between 0.01 and 0.02% if I did that right

[04:54:55.0000] <annevk>
hsivonen: seems above treshold

[04:56:33.0000] <hsivonen>
annevk: what's the threshold?

[04:59:54.0000] <annevk>
hsivonen: for Chrome it's 0.003% iirc, but I believe they stopped using that (not sure in favor of what, but likely more conservative)

[05:00:07.0000] <annevk>
hsivonen: I don't think Mozilla has a number

[05:00:23.0000] <hsivonen>
annevk: ok

[05:10:37.0000] <zcorpan>
annevk: in favor of better understanding of compat impact. in some cases things can be successfully removed with higher usage. usage number alone is not enough information

[05:44:58.0000] <annevk>
TimothyGu: make sure to add yourself to https://heycam.github.io/webidl/#acknowledgements next time

[05:45:33.0000] <annevk>
TimothyGu: and maybe fix the glaring Oxford comma bug while there

[06:25:10.0000] <TimothyGu>
annevk: okay I will

[06:27:36.0000] <annevk>
TimothyGu: https://gist.github.com/annevk/4287452653921b2b7de35e4208b4a985 now has some draft text for data URL processing

[06:27:45.0000] <annevk>
TimothyGu: need to clean it up a bit still and decide where to put it

[06:42:43.0000] <TimothyGu>
annevk: why is ;base64 only searched at the end of the mime type? e.g. data:text/plain;base64;charset=UTF-8,5Lit5paH works in Chrome and Firefox

[06:44:06.0000] <annevk>
TimothyGu: oh, I thought that only worked in a subset of UAs

[06:44:16.0000] <annevk>
TimothyGu: should have tested first I guess

[06:45:45.0000] <annevk>
TimothyGu: it doesn't work in Safari

[06:45:55.0000] <TimothyGu>
to be exact firefox ignores anything that comes after ;base64 in that case, but it still reads the data in base64

[06:45:58.0000] <TimothyGu>
:(

[06:46:17.0000] <annevk>
TimothyGu: the RFC also requires it to be last

[06:46:25.0000] <annevk>
/me writes test that can run in Edge

[06:47:38.0000] <TimothyGu>
yay more incompatibility

[06:48:42.0000] <annevk>
TimothyGu: Edge supports it

[06:48:44.0000] <MikeSmith>
hsivonen: I’ve not been involved at all with the https://lists.w3.org/Archives/Public/public-review-announce/2017Aug/0004.html plans so I don’t know if they include trimming http://www.w3.org/1999/xhtml

[06:49:15.0000] <annevk>
TimothyGu: supporting that is worse though as there's much more edge cases that way

[06:50:29.0000] <TimothyGu>
yeah well, too bad most browsers already support it

[06:51:00.0000] <annevk>
I hope they don't substring

[06:51:12.0000] <annevk>
Not sure what to do then

[06:55:46.0000] <AutomatedTester>
annevk: hey, got a weird case and need your thoughts. What would a property return on an element when its in a data url like data:text/html;charset=utf-8,<a href%3Dfoo>foobar</a>. e.g. what should document.querySelector('a').href return ?

[06:56:56.0000] <annevk>
TimothyGu: yeah, they do substring matching

[06:57:30.0000] <TimothyGu>
:\

[06:57:35.0000] <annevk>
AutomatedTester: typically the input value

[06:57:41.0000] <annevk>
AutomatedTester: because it cann be resolved

[06:57:56.0000] <annevk>
AutomatedTester: well, if it's a URL attribute anyway

[06:58:56.0000] <AutomatedTester>
annevk: ahh cool, thank you

[06:59:31.0000] <annevk>
TimothyGu: hmm, not quite substring either, data:x;base64x,WA ends up with length 2

[07:00:03.0000] <annevk>
TimothyGu: so I guess it's ends with ;base64 or contains ;base64; now

[07:51:43.0000] <foolip>
/me finds that the FAQ started at http://web.archive.org/web/20070821014820/http://blog.whatwg.org/faq/

[07:53:07.0000] <annevk>
TimothyGu: https://github.com/whatwg/fetch/pull/579 if you want to review (there should be Preview/Diff links in a bit)

[07:59:53.0000] <annevk>
/me updates OP with a TODO list

[08:45:43.0000] <TimothyGu>
annevk: will do.

[08:46:24.0000] <TimothyGu>
anybody have any idea why typeof document.all returns "undefined" on both Chrome and Firefox? bug or just plain weirdness with document.all?

[09:30:21.0000] <annevk>
TimothyGu: https://github.com/tc39/ecma262/pull/673

[09:32:48.0000] <Domenic>
TimothyGu: oh wow, we get to introduce you to https://html.spec.whatwg.org/multipage/obsolete.html#dom-document-all

[09:39:57.0000] <Domenic>
annevk: it looks like the base64 RFC doesn't have an algorithm, or is it hidden somewhere?

[09:41:27.0000] <annevk>
Domenic: I think you have to infer it from the description per usual

[09:41:33.0000] <Domenic>
Sigh

[09:42:16.0000] <Domenic>
I guess we can create an algorithm and say it's compatible with the RFC or something

[09:42:29.0000] <Domenic>
BTW we can just return null instead of throwing an DOMException to keep it at the Infra level

[09:43:03.0000] <annevk>
Domenic: we already have an algorithm

[09:43:14.0000] <annevk>
Domenic: it's how we define window.atob() as I've said a few times

[09:43:21.0000] <annevk>
Domenic: we just need to make that reusable

[09:43:41.0000] <annevk>
Domenic: I discovered this morning implementations share the code path

[09:44:01.0000] <Domenic>
Sorry, poor choice of words "create"

[09:44:47.0000] <Domenic>
I was just kind of hoping we could avoid the layering question by letting the RFC do the work

[09:47:39.0000] <annevk>
Hah, I've yet to find that RFC

[09:49:27.0000] <annevk>
Domenic: Infra seems fine btw, it also has things like namespaces, so a base64-with-errors seems reasonable

[09:49:45.0000] <annevk>
more like base64-with-some-errors

[10:38:40.0000] <smaug____>
foolip: does blink have usage data about alert/confirm/prompt ?

[11:04:36.0000] <Domenic>
smaug____: yes... around 1% or 2% IIRC for alert

[11:05:53.0000] <Domenic>
smaug____: I misremembered, it's lower. https://www.chromestatus.com/metrics/feature/timeline/popularity/950 + https://www.chromestatus.com/metrics/feature/timeline/popularity/951 + https://www.chromestatus.com/metrics/feature/timeline/popularity/952

[11:06:52.0000] <smaug____>
ahaa, even alert() is quite low

[15:49:19.0000] <TimothyGu>
annevk/Domenic: wat


2017-08-15
[17:08:02.0000] <rniwa>
dcheng: yt?

[17:08:40.0000] <rniwa>
Domenic: yt?

[18:42:56.0000] <rniwa>
MikeSmith: could you add @ehsan to https://github.com/whatwg/html>

[18:43:03.0000] <rniwa>
MikeSmith: he's a Gecko contributor

[19:12:12.0000] <MikeSmith>
rniwa: added with read access

[20:31:04.0000] <luxio>
why so many people idling here?

[23:30:47.0000] <annevk>
luxio: lots of people trying to get rid of their sense of logic

[00:53:39.0000] <tobie>
TimothyGu: isn't document.all awesome!?

[00:59:05.0000] <annevk>
Hmm I just noticed that Bikeshed puts <script> elements way late in the document

[00:59:11.0000] <annevk>
How do you get them in <head>?

[00:59:18.0000] <annevk>
And how would you do the same for a <style>?

[01:16:21.0000] <tobie>
annevk: iirc BS puts all <style> elements in <head>.

[01:17:22.0000] <tobie>
annevk: no idea about <script>

[02:52:35.0000] <foolip>
zcorpan: https://drafts.fxtf.org/geometry/ or https://drafts.fxtf.org/geometry-1/?

[02:52:53.0000] <foolip>
zcorpan: only the latter has DOMRectList, but is an uglier URL

[02:53:43.0000] <zcorpan>
foolip: huh. they're supposed to be identical

[02:53:58.0000] <foolip>
zcorpan: a deploy problem perhaps?

[02:55:14.0000] <zcorpan>
took a guess and pinged plinss

[02:55:24.0000] <zcorpan>
thanks

[02:55:30.0000] <foolip>
zcorpan: so linking to the one without the version should be the right thing?

[02:56:05.0000] <zcorpan>
foolip: yeah, in general, but in web-platform-tests the linter will whine about versionless spec links under css/

[02:56:09.0000] <zcorpan>
iirc

[02:56:32.0000] <foolip>
zcorpan: that's fine, those aren't URLs, just reviewing URL fixes in Blink's IDL files now

[02:58:03.0000] <TimothyGu>
tobie: totally

[03:44:42.0000] <annevk>
TimothyGu: https://github.com/w3c/web-platform-tests/pull/6890

[03:45:05.0000] <TimothyGu>
woo hoo!

[03:46:35.0000] <annevk>
I guess I'll start filing some browser bugs too on the base64 bits that don't interoperate

[04:30:44.0000] <tobie>
TimothyGu: looking at your latest change. You seem to understand the difference between an Object Type with a [[Call]] internal method and ECMAScript Function Objects. TBH, I don't. Care to enlighten me (or someone else for that matter).

[04:56:15.0000] <tobie>
Domenic, annevk: ^

[05:28:59.0000] <annevk>
tobie: oh sorry, missed that

[05:29:14.0000] <tobie>
annevk: np

[05:29:16.0000] <annevk>
tobie: I'm not really sure on the difference

[05:29:26.0000] <tobie>
annevk: :(

[05:29:27.0000] <annevk>
tobie: do functions have [] accessors?

[05:30:07.0000] <tobie>
annevk: oh; *that*. I have no idea.

[05:30:14.0000] <annevk>
tobie: I vaguely recall some types having (), some [], and weird ones having both

[05:31:16.0000] <annevk>
tobie: so object with call seems like one of those weird ones on the face of it, but I'd have to look into it more to be sure

[05:31:51.0000] <tobie>
annevk: what I'm trying to figure out is what do we mean when we say Function object

[05:32:52.0000] <annevk>
tobie: it doesn't mean alert(Function)?

[05:33:18.0000] <tobie>
annevk: related to https://github.com/heycam/webidl/pull/405#issuecomment-322244133

[05:33:39.0000] <tobie>
annevk: no. That would be "the Function object"?

[05:35:09.0000] <annevk>
tobie: hmm, a built-in function object is like a normal JavaScript function that's provided by the browser somehow

[05:35:26.0000] <annevk>
tobie: I think the most important bit is that the implementation is hidden

[05:35:40.0000] <annevk>
tobie: and defined by a spec

[05:36:14.0000] <tobie>
annevk: so we have the notion of built-in down, that's fine.

[05:36:34.0000] <tobie>
annevk: the issue is around the non built-in ones.

[05:38:26.0000] <annevk>
tobie: I think what is called "function object" in that PR just refers to all JavaScript functions, with built-in ones being a subset

[05:40:54.0000] <tobie>
annevk: I want venn diagrams of all the things.

[05:42:37.0000] <annevk>
tobie: pretty sure that would hang your computer

[05:43:05.0000] <zcorpan>
MikeSmith: WDYT about the bugs about <script>/<template> in the content model? Leave the spec as is or change it as I suggested back then?

[05:44:51.0000] <tobie>
annevk: that PR is changing a bunch of "<emu-val>Function</emu-val> object" to "function object" and linking to https://tc39.github.io/ecma262/#sec-object-internal-methods-and-internal-slots

[05:45:53.0000] <tobie>
annevk: maybe we should link it to https://tc39.github.io/ecma262/#sec-terms-and-definitions-function instead?

[05:46:10.0000] <tobie>
annevk: tbh I'm having a hard time figuring out how the ES spec is structured.

[05:59:25.0000] <annevk>
tobie: the section the PR refers to has the <dfn> it seems like: "A function object is an object that supports the [[Call]] internal method."

[06:00:26.0000] <tobie>
annevk: agreed. Is that what we mean by "<emu-val>Function</emu-val> object" is my question, I suppose.

[06:01:26.0000] <annevk>
tobie: I think uppercase Function is likely to refer to global.Function

[06:02:09.0000] <tobie>
annevk: I don't think that's what it was doing in the WebIDL spec.

[06:03:15.0000] <annevk>
tobie: not sure then, perhaps conventions changed between ES5 and ES6?

[06:03:27.0000] <annevk>
tobie: a lot of IDL is aligned with ES5 language

[06:06:25.0000] <tobie>
annevk: I know. :(

[06:08:41.0000] <annevk>
tobie: looking at https://es5.github.io/ it seems that ES was sloppy before ES6

[06:09:16.0000] <annevk>
tobie: that has stuff like "built-in Function object"

[06:09:27.0000] <annevk>
tobie: so IDL likely inherited a lot of that

[06:09:34.0000] <tobie>
\o/

[06:13:29.0000] <TimothyGu>
tobie: here's what I figured out

[06:13:31.0000] <Domenic>
tobie: "ECMAScript Function object" is https://tc39.github.io/ecma262/#sec-ecmascript-function-objects . It is a function derived from ECMAScript source text written down by a developer.

[06:13:38.0000] <TimothyGu>
^^ that :)

[06:14:10.0000] <Domenic>
lol sorry ^_^

[06:15:33.0000] <TimothyGu>
I did try to make the distinctions between "function object" and "built-in function object" very clear, though there are some instances I'm not too sure what to link

[06:15:36.0000] <tobie>
Right--so Object type with [[Call]] is a superset whose elements are built-ins and ES function objects?

[06:15:51.0000] <TimothyGu>
yes

[06:15:56.0000] <Domenic>
The set also includes non-function objects who just happen to have [[Call]]

[06:16:03.0000] <Domenic>
Like proxies, for example

[06:16:06.0000] <TimothyGu>
also bound function exotic objects, proxies

[06:16:28.0000] <TimothyGu>
e.g. for https://heycam.github.io/webidl/#es-map-size

[06:16:31.0000] <Domenic>
And probably legacy-caller platform objects

[06:17:13.0000] <Domenic>
built-in function objects have a specific [[Call]]: https://tc39.github.io/ecma262/#sec-built-in-function-objects

[06:17:19.0000] <TimothyGu>
I wrote "map size getter is a [=built-in function object=]" but below I kept "The value of the [=function object=]’s “length” property"

[06:17:48.0000] <TimothyGu>
felt writing "built-in function object" for the second case felt a bit redundant

[06:17:52.0000] <tobie>
What about https://tc39.github.io/ecma262/#sec-terms-and-definitions-function?

[06:18:00.0000] <TimothyGu>
tobie: it's too vague IMO

[06:18:29.0000] <TimothyGu>
generally that section is full of vague definitions that will be defined in detail later

[06:19:48.0000] <tobie>
TimothyGu: sure. But aren't we precisely aiming for vagueness here?

[06:20:18.0000] <tobie>
TimothyGu: I mean it seems that by "function object" we sort of mean all the callable things

[06:20:33.0000] <TimothyGu>
well, "object with [[Call]]" is similarly broad but more precise than "member of the Object type that may be invoked as a subroutine"

[06:21:05.0000] <tobie>
TimothyGu: agreed. It's just ES spec doesn't really let you link to this.

[06:21:19.0000] <tobie>
TimothyGu: which is a common issues with the ES spec.

[06:21:22.0000] <TimothyGu>
yeah, that's unfortunate

[06:21:31.0000] <tobie>
TimothyGu: agreed.

[06:22:09.0000] <tobie>
So, now that everyone has provided greater context, I'm with you that "object with [[Call]]" is what we'd like to link to.

[06:22:43.0000] <tobie>
TimothyGu: I'm not sure how to best do that, tbh.

[06:23:05.0000] <tobie>
TimothyGu: I guess it depends who the intended audience of that linking is.

[06:23:11.0000] <TimothyGu>
we can ask tc39 to put an id there

[06:25:45.0000] <tobie>
TimothyGu: around here: https://tc39.github.io/ecma262/#_ref_40 ?

[06:26:07.0000] <tobie>
"A function object is an object that supports the [[Call]] internal method."

[06:26:17.0000] <TimothyGu>
yes, specifically for "function object"

[06:26:41.0000] <tobie>
Right, just like one of our DFNs

[06:26:45.0000] <TimothyGu>
yep

[06:26:57.0000] <tobie>
WFM.

[06:27:01.0000] <TimothyGu>
they have a system to do that too, e.g. https://tc39.github.io/ecma262/#global-object

[06:28:00.0000] <tobie>
oh, neat.

[06:28:05.0000] <tobie>
I'll send a PR.

[06:29:46.0000] <TimothyGu>
tobie: do you have an opinion on the question I posed earlier, whether to use "built-in function object" for both cases or  "built-in" for the first one and just "function object" for the second?

[06:30:16.0000] <TimothyGu>
TimothyGu | e.g. for https://heycam.github.io/webidl/#es-map-size

[06:30:21.0000] <tobie>
TimothyGu: maybe not link it the second time at all?

[06:31:53.0000] <TimothyGu>
it's not really the linking  I'm worried about but what to write

[06:32:18.0000] <TimothyGu>
Domenic: do you know where "length" property for built-in functions are defined in ES?

[06:33:34.0000] <Domenic>
Yes, there's a clause...

[06:34:04.0000] <TimothyGu>
I mean, I can find the one for normal ECMAScript functions but not built-in ones...

[06:34:20.0000] <TimothyGu>
the one for ES functions is https://tc39.github.io/ecma262/#sec-functioninitialize

[06:35:06.0000] <Domenic>
No, there's something that says "look at the headings"...

[06:35:22.0000] <Domenic>
Every built-in function object, including constructors, has a length property whose value is an integer. Unless otherwise specified, this value is equal to the largest number of named arguments shown in the subclause headings for the function description. Optional parameters (which are indicated with brackets: [ ]) or rest parameters (which are shown using the form «...name») are not included in the default argument

[06:35:22.0000] <Domenic>
count.

[06:35:25.0000] <TimothyGu>
ah found it: https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects

[06:35:59.0000] <tobie>
Isn't there a way to use a more imperative style here? Similar to the last steps of https://heycam.github.io/webidl/#named-constructors

[06:38:04.0000] <TimothyGu>
We don't use CreateBuiltinFunction at all for functions defined in the IDL spec, we should probably fix that first

[06:38:23.0000] <TimothyGu>
we do for IDL operations though

[06:38:31.0000] <Ms2ger>
There's a bug about that, I think

[06:38:45.0000] <TimothyGu>
... there's a bug about everything...

[06:43:21.0000] <tobie>
:D :-/

[06:44:00.0000] <gsnedders>
Domenic: that clause is always so hard to find

[06:45:17.0000] <annevk>
TimothyGu: kudos for multiple ;base64 occurrences

[06:47:49.0000] <TimothyGu>
👍

[07:08:51.0000] <annevk>
Domenic: I'm getting a lot of failures from Travis that are fixed after a couple restarts

[07:08:58.0000] <annevk>
Domenic: 'The command "curl --remote-name --fail https://resources.whatwg.org/build/deploy.sh && bash ./deploy.sh" exited with 1.'

[07:09:29.0000] <Domenic>
annevk: hmm so that could be a problem with the deploy script since maybe we are hiding errors? But I suspect it means resources.whatwg.org is flaky.

[07:09:34.0000] <annevk>
Domenic: and it always seems to be the fetching that fails

[07:09:47.0000] <Domenic>
Yeah OK. So, more dreamhost problems.

[07:10:13.0000] <annevk>
Domenic: maybe they're rate-limiting Travis?

[07:10:46.0000] <Domenic>
Seems unlikely... we don't deploy that often. I think I hit the various specs myself more often than Travis does.

[07:10:54.0000] <Domenic>
Maybe there's something in the logs though, indeed.

[07:12:34.0000] <Domenic>
annevk: so I'd kind of like to avoid iso-...-decode since iso-... doesn't define mappings for various bytes

[07:12:46.0000] <Domenic>
annevk: I liked "numeric" because it's "take the number of the byte and turn it into the number of the codepoint"

[07:14:09.0000] <annevk>
Domenic: wait what? it doesn't?

[07:14:49.0000] <annevk>
Domenic: source? http://ftp.unicode.org/Public/MAPPINGS/ISO8859/8859-1.TXT

[07:14:59.0000] <Domenic>
ftp://std.dkuug.dk/JTC1/sc2/wg3/docs/n411.pdf  is missing several ranges

[07:15:10.0000] <Domenic>
Interesting!

[07:15:27.0000] <Domenic>
https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout matches the pdf

[07:16:14.0000] <Domenic>
So it looks like Unicode has a different definition of iso-8859-1 than ISO does

[07:16:32.0000] <gsnedders>
One of them keeps 0x80–0x9F undefined, IIRC?

[07:16:36.0000] <annevk>
Okay, the commonly understood meaning is that those are mapped as I understand it, although it's hard to test in browsers

[07:16:40.0000] <Domenic>
And 0x00-0x20

[07:17:01.0000] <Domenic>
(Also 0x7F)

[07:17:19.0000] <Domenic>
I don't feel like there is any "common meaning" here :). Besides maybe windows-1252 :)

[07:17:29.0000] <annevk>
Domenic: "string convert" and "byte sequence convert"?

[07:17:39.0000] <Domenic>
I think that works for me

[07:17:54.0000] <Domenic>
I'd kind of like to use "encode"/"decode" but those are OK-ish

[07:18:50.0000] <annevk>
Domenic: isomorphic encode/decode?

[07:19:03.0000] <Domenic>
oooh

[07:19:57.0000] <Domenic>
that works for me.

[07:20:51.0000] <annevk>
cool

[07:26:40.0000] <annevk>
Domenic: can https://github.com/whatwg/infra/pull/145 land?

[07:27:08.0000] <Domenic>
annevk: I'll do one more pass

[09:23:39.0000] <gsnedders>
the jsDoc docs are… pretty bad, for a documentation project

[09:24:08.0000] <tantek>
gsnedders, are they also, by any chance, js;dr?

[09:25:07.0000] <gsnedders>
tantek: no, they aren't, AFAICT

[09:25:17.0000] <tantek>
well that's a relief at least

[09:33:29.0000] <nox>
Domenic: Ain't that a case of IANA ISO-8859-1 vs ISO/CEI 8859-1?

[09:34:13.0000] <annevk>
Domenic: resources.whatwg.org does seem super reliable to me though

[09:35:12.0000] <annevk>
nox: don't think so

[09:36:04.0000] <nox>
annevk: AFAIK the ISO/CEI one doesn't define mappings for all the bytes.

[09:36:55.0000] <annevk>
nox: IANA's references don't either

[09:37:27.0000] <Domenic>
annevk: I approved and then realized https://github.com/whatwg/infra/pull/146#issuecomment-322519502 sorry

[09:37:34.0000] <nox>
annevk: You sure?

[09:38:31.0000] <nox>
"ISO-8859-1 is the IANA preferred name for this standard when supplemented with the C0 and C1 control codes from ISO/IEC 6429 (see below for HTML5 exception). IBM calls it Code page 819 or CP819. The following other aliases are registered for ISO-8859-1: iso-ir-100, csISOLatin1, latin1, l1, IBM819. Oracle calls it WE8ISO8859P1."

[09:41:11.0000] <annevk>
nox: I'm not sure where that quote is from, but the references on https://www.iana.org/assignments/character-sets/character-sets.xhtml (both ISO and the RFC) don't seem to define those areas

[09:41:17.0000] <nox>
https://tools.ietf.org/html/rfc1345 lists ISO-8859-1 with mappings for all bytes AFAIK, but maybe I miscounted.

[09:41:42.0000] <annevk>
Domenic: no worries

[09:42:32.0000] <annevk>
nox: oh I guess it does at the end, hmm

[09:42:54.0000] <annevk>
nox: oh well, IANA charsets is obsoleted too so best to avoid

[09:43:21.0000] <nox>
I've way more often saw the ISO-8859-1 version with the 256 code points,

[09:43:32.0000] <nox>
than the ISO/IEC 8859-1 one with the subset of them.

[09:45:18.0000] <gsnedders>
the only time I see the one without the controls is when people are claiming Windows-1252 is a compliant implementation of ISO-8859-1, just giving meaning to undefined bytes

[09:46:16.0000] <annevk>
Domenic: should we update that note though?

[09:46:26.0000] <annevk>
Domenic: it's still the best advice for getting a byte sequence out of a string

[09:46:56.0000] <annevk>
Domenic: isomorphic encode is mostly for legacy stuff

[09:47:56.0000] <Domenic>
annevk: I think we should update it, even if we keep recommending UTF-8. It's just weird to see that note and then two lines down see "here's a procedure for going from strings to byte sequences"

[09:50:00.0000] <annevk>
Domenic: two lines down is the other procedure, but okay

[09:51:31.0000] <Domenic>
annevk: lgtm

[09:59:16.0000] <annevk>
Domenic: I really don't understand what's wrong with the build process, resources.whatwg.org responds perfectly here

[09:59:27.0000] <annevk>
Domenic: oh right, if it's rate-limiting by DreamHost that would be it

[09:59:37.0000] <Domenic>
Hmm OK, maybe a Travis-specific thing then. Maybe we can add more debugging to the script somehow

[11:58:07.0000] <rniwa>
annevk: drag & drop is a bean bag of bugs and interoperability nightmare :(

[12:19:09.0000] <annevk>
rniwa: that's UI events

[12:19:44.0000] <rniwa>
annevk: well, not just that but dataTransfer behavior is really inconsistent

[12:19:47.0000] <annevk>
rniwa: one day I want to dig in, but I keep waiting and hoping someone else does it

[13:19:21.0000] <Domenic>
annevk: shall we merge https://github.com/whatwg/html/pull/2869 ?

[13:25:12.0000] <TabAtkins>
@annevk As noted by tobie, Bikeshed auto-moves all <style> elements into the <head> automatically, because it's guaranteed to not be a behavior change. But I can't guarantee that for <script>s; you might be depending on relative ordering, or for a <script> to execute after a particular element was parsed into the DOM, and moving would break it.

[13:25:29.0000] <TabAtkins>
Are these your own <script> elements you're having a problem with, or something that Bikeshed is generating?


2017-08-16
[21:03:00.0000] <TimothyGu>
tobie: anything I need to fix in https://github.com/heycam/webidl/pull/405 before it can get applied?

[21:09:01.0000] <TimothyGu>
or shall I just wait for the ECMA-262 PR to land?

[21:25:54.0000] <annevk>
TabAtkins: own

[21:39:29.0000] <TabAtkins>
annevk: And you'd like them to get moved into the head? If so, I can provide an attr that opts into that.

[21:40:04.0000] <annevk>
TabAtkins: yeah, seems better for the preparser

[21:40:28.0000] <annevk>
TabAtkins: the earlier those URLs are found the better

[21:41:13.0000] <TabAtkins>
Kk, file a bug on me and I'll do it. It just has to be opt-in for safety reasons, like I said

[21:41:28.0000] <TabAtkins>
Preferably point to a spec that is currently generating them late

[22:35:36.0000] <rniwa>
annevk: fyi, another drag & drop issue: https://github.com/whatwg/html/issues/2925

[22:39:48.0000] <rniwa>
oh my, Chrome & Gecko have a different behavior too :(

[22:54:53.0000] <MikeSmith>
hey rniwa since you’re still awake, please take a look at https://github.com/whatwg/html/pull/2907/commits/2381a269cdfade91ceb056086a494471ceff8e35

[22:55:21.0000] <rniwa>
MikeSmith: it looks good but I don't have commit privilege to the repo.

[22:57:05.0000] <MikeSmith>
rniwa: yeah annevk can (re)review and merge it

[22:57:23.0000] <MikeSmith>
just wanted to make sure you think it’s an improvement

[22:57:45.0000] <MikeSmith>
it future-proofs it against the class of problem it’s fixing

[22:58:11.0000] <rniwa>
MikeSmith: sure, it looks like an improvement

[22:58:17.0000] <MikeSmith>
k

[22:58:18.0000] <MikeSmith>
thanks

[22:58:49.0000] <MikeSmith>
I now feel like going back into the spec and changing any remaining cases we have of hard-coded step references

[22:59:03.0000] <MikeSmith>
maybe I’ll do that today

[23:01:02.0000] <MikeSmith>
annevk: I think I asked you this before but I guess there’s a reason we’re not doing branch snapshots for HTML

[23:42:50.0000] <annevk>
MikeSmith: I don't think we have a good reason

[23:46:24.0000] <a-ja>
MikeSmith, Please leave your sense of logic at the door, thanks!

[23:46:31.0000] <a-ja>
/me couldn't resist

[23:47:33.0000] <a-ja>
MikeSmith, btw...tks for script nomodule update to validator

[23:48:54.0000] <a-ja>
now has 0 html validation errors....and hundreds for my css :\

[23:51:12.0000] <MikeSmith>
a-ja: super 🖖

[00:05:24.0000] <annevk>
o_O

[00:05:39.0000] <annevk>
Safari uses a different character set for base64 in data: URLs: https://bugs.webkit.org/show_bug.cgi?id=175568

[00:06:04.0000] <annevk>
This really goes to demonstrate how poor testing is

[00:19:57.0000] <zcorpan>
should it be DOMMatrix2dInit or DOMMatrix2DInit? (there's a dictionary member called "is2D")

[00:25:06.0000] <annevk>
zcorpan: it's Path2D and CanvasRenderingContext2D

[00:25:45.0000] <annevk>
zcorpan: but also, dictionary names are not observable

[00:26:08.0000] <zcorpan>
yeah, but still :-) thanks

[00:27:11.0000] <annevk>
gotta paint the back of that fence

[00:40:20.0000] <a-ja>
which is preferred, bactrian or dromedary camel case?

[00:43:14.0000] <annevk>
a-ja: not sure if serious, but https://w3ctag.github.io/design-principles/#casing-rules

[00:44:02.0000] <a-ja>
wasn't serious...but reading

[00:44:51.0000] <a-ja>
TLDR; answer is "hybrid"

[00:45:06.0000] <zcorpan>
i prefer XMLHttpRequest case

[00:45:19.0000] <annevk>
oh my

[01:56:57.0000] <zcorpan>
annevk: was there an issue about changing setAttribute et al to check the attribute name according to what the html parser accepts?

[01:57:33.0000] <annevk>
zcorpan: there's https://github.com/whatwg/dom/pull/449

[02:03:03.0000] <tobie>
TimothyGu: I was pondering just that. Going through the whole list one by one again and adding a few comments. Sorry what seemed like a trivial change ended up as a long conversation on ES functions.

[02:04:17.0000] <tobie>
TimothyGu: no realizing that built-in functions is a subset of both function objects and constructors.

[02:04:42.0000] <tobie>
TimothyGu: s/no/now/

[02:06:24.0000] <tobie>
TimothyGu: i.e. these operate on a different axis; it's [[Call]] vs. [[Construct]] on one axis, and built-in vs. user land on the other.

[02:06:41.0000] <tobie>
TimothyGu: ES terminology is really letting us down, here.

[02:46:36.0000] <zcorpan>
Hmmmmmm. This worries me :-( https://github.com/w3c/web-platform-tests/pull/6418

[03:19:34.0000] <Ms2ger>
tobie, sounds like you need to put a table in the spec somewhere :)

[03:20:47.0000] <tobie>
Ms2ger: in which spec?

[03:20:59.0000] <Ms2ger>
Either webidl or ES, I suppose

[03:22:30.0000] <tobie>
Ms2ger: I've yet to understand what the exotic stuff is

[03:22:50.0000] <tobie>
Ms2ger: could well be that two dimensions aren't enough to sort this whole thing out.

[03:23:01.0000] <annevk>
tobie: custom internal methods

[03:23:42.0000] <tobie>
annevk: custom internal methods are exotic? I thought they were built-in.

[03:23:50.0000] <annevk>
tobie: e.g., custom [[Delete]] or [[OwnPropertyKeys]]

[03:24:18.0000] <annevk>
tobie: if an object has custom internal methods, that makes it an exotic object

[03:24:36.0000] <tobie>
Oh. The object is exotic.

[03:25:08.0000] <annevk>
tobie: WindowProxy and Location are good examples outside ECMAScript (and anything with getters/callers)

[03:37:26.0000] <TimothyGu>
tobie: thanks for the review! sure, I'll address the comments soon, no worries

[03:39:47.0000] <tobie>
TimothyGu: well hopefully by then the ES PR will have been merged.

[03:59:29.0000] <annevk>
Anyone ideas of how MIME types end up getting exposed in the platform?

[04:00:15.0000] <annevk>
I guess when you navigate whether something downloads or not, maybe Blob.prototype.type though as I understand it that's just what you passed in, Document.prototype.contentType though that doesn't have parameters

[04:00:35.0000] <annevk>
Getting the Content-Type header through fetch() or XMLHttpRequest just gives you the raw value

[04:01:27.0000] <annevk>
For data: URLs it's a mixed bag, but Chrome and Firefox do seem to expose something there (but unclear to me if that's desired)

[04:03:05.0000] <annevk>
Stuff that uses https://fetch.spec.whatwg.org/#concept-header-extract-mime-type I suppose, though I'm not hopeful

[04:14:06.0000] <TimothyGu>
tobie: sorry, just fixed the comments :|

[05:39:10.0000] <TimothyGu>
annevk: wait, there are plans to drop FTP support?

[05:52:01.0000] <annevk>
TimothyGu: sure, suspect before HTTP

[06:17:42.0000] <tobie>
is HTMLAllCollection now the last interface with legacycaller?

[06:19:17.0000] <annevk>
tobie: that might be true, yes

[06:19:58.0000] <tobie>
would there be an objection to me listing these weird interfaces in notes within the WebIDL spec?

[06:20:14.0000] <tobie>
I've got to look them  up all the time.

[06:20:27.0000] <tobie>
Alternatively, in an annex.

[06:20:34.0000] <annevk>
tobie: source comments seem definitely fine, notes probably too

[06:20:57.0000] <tobie>
cool

[06:21:25.0000] <annevk>
tobie: once ECMAScript defines HTML Document Dot All Objects or whatever they call them we might want to revisit how this gets defined

[06:21:37.0000] <annevk>
tobie: we could just put the legacycaller bits directly in HTML

[06:21:57.0000] <annevk>
(though haven't checked if that actually works out in practice, mind you)

[06:23:03.0000] <tobie>
annevk: I think that could work with a bit of refactoring.

[06:25:41.0000] <annevk>
tobie: if that means defining [[Call]] solely in HTML that would be a lot better

[06:26:11.0000] <tobie>
annevk: it would

[06:27:00.0000] <tobie>
annevk: well, the syntax should still stay in WebIDL, though.

[06:27:32.0000] <tobie>
annevk: unless we turn legacycaller into an extended attribute, of course.

[06:38:26.0000] <tobie>
annevk: how would you got about this in HTML? Just add some prose that HTMLAllCollection has an additional [[Call]] method? Or add a new extended attribute?

[06:38:49.0000] <annevk>
tobie: the former, just like we do for WindowProxy and Location

[06:39:01.0000] <tobie>
/me looks

[07:18:06.0000] <TimothyGu>
tobie: I'd love to remove legacycaller from IDL

[07:18:32.0000] <tobie>
TimothyGu: yeah, I think this plan might work

[07:18:48.0000] <tobie>
TimothyGu: toying with adding [[Call]] to HTML spec as we speak

[07:19:22.0000] <tobie>
TimothyGu: turns out there are some weird oddities;

[07:20:55.0000] <tobie>
TimothyGu: document.all("1") and document.all("1", "45") aren't returning the same thing, which blows my mind

[07:21:56.0000] <TimothyGu>
wait, why?

[07:21:56.0000] <botie>
wait, why are you using rawgit?

[07:22:06.0000] <tobie>
TimothyGu: never mind my last comment.

[07:22:22.0000] <TimothyGu>
you are aware of https://html.spec.whatwg.org/multipage/obsolete.html#dom-document-all right

[07:22:26.0000] <tobie>
TimothyGu: stupid mistake on my part due to poor eyesight

[07:22:44.0000] <TimothyGu>
guessing you are

[07:23:32.0000] <tobie>
yes

[07:23:40.0000] <tobie>
well, sort of.

[07:25:36.0000] <tobie>
TimothyGu: Was your initial comment "I'd love to remove legacycaller from IDL" to be interpreted as: (1) I'd love to see legacycaller go, (2) I'd love to do the work to remove legacycaller, or (3) both (1) and (2)?

[07:25:57.0000] <TimothyGu>
(3) :)

[07:26:32.0000] <TimothyGu>
well, more like "I'd love to see it go, and I *can* do the work if no one else wants to" :P

[07:27:02.0000] <tobie>
TimothyGu: sounds good. Do you mind if I work on the HTML spec PR while you rip it out of WebIDL?

[07:27:27.0000] <tobie>
biab

[07:27:44.0000] <TimothyGu>
sure!

[07:27:58.0000] <TimothyGu>
let me know when the HTML PR is ready

[07:29:07.0000] <nox>
How can we kill legacycaller given it's used?

[07:29:27.0000] <nox>
Oh, extended attribute.

[07:30:46.0000] <TimothyGu>
nox: it's only used in one place, so we can just specify its exotic behaviors *there*

[07:30:56.0000] <nox>
Oh, prose. :(

[07:34:48.0000] <annevk>
nox: there's going to be prose one way or another 😃

[07:35:13.0000] <nox>
annevk: [IOnlyTolerateCamelCaseProseWithSquareBracketsAroundIt] :P

[07:35:48.0000] <annevk>
nox: well, since it's about a custom [[Call]] there'll be brackets

[07:35:58.0000] <nox>
Perfect! :D

[07:57:32.0000] <TimothyGu>
tobie: you might want to take care of https://github.com/heycam/webidl/issues/407 while porting [[Call]] to HTML

[08:34:51.0000] <smaug____>
rbyers: when Chrome coalesces mousemoves, there isn't any way to get all the mousemoves, right?

[08:34:59.0000] <smaug____>
I mean this one move per rAF thing

[08:36:27.0000] <Domenic>
annevk: probably good to ping jasnell for things like https://github.com/whatwg/url/issues/342 too

[08:39:52.0000] <Domenic>
smaug____: I'm pretty sure there is

[08:40:03.0000] <Domenic>
something like mouseEvent.getCoaelescedThingies()

[08:40:06.0000] <Domenic>
or maybe it's pointer events only

[08:40:20.0000] <Domenic>
rbyers has some demo where he uses this to make drawing prettier

[08:58:16.0000] <smaug____>
Domenic: getCoalescedEvents() is a pointer events thing, not mouse event

[09:00:54.0000] <Domenic>
Right, OK. So yeah, use pointer events, they are the future :).

[09:07:32.0000] <tobie>
TimothyGu: well… I guess I can just close it now. :D

[09:45:07.0000] <rbyers>
smaug____: Yeah coalesced events are available on pointer events only.  One visualization is here BTW: https://rbyers.github.io/eventRate.html

[09:45:50.0000] <smaug____>
rbyers: has there been lots of regressions because of 1 mousemove per animation frame?

[09:46:27.0000] <rbyers>
... but PointerEvent is a MouseEvent so our hypothesis is that it's hopefully that much of a burden to ask existing MouseEvent-based sites to use this PointerEvent API for this without upgrading all their existing event code.

[09:47:24.0000] <smaug____>
well, only some browsers support pointer events atm

[09:47:32.0000] <smaug____>
/me wonders what https://rbyers.github.io/eventRate.html is supposed to do

[09:47:36.0000] <annevk>
Domenic: seems jasnell found it

[09:47:47.0000] <smaug____>
loaded in Chrome and if I click I see a gray dot

[09:48:54.0000] <smaug____>
oh, I need to mousedown and move

[09:49:31.0000] <rbyers>
smaug____: No regressions that we're aware of (just checked with dtapuska).  It shipped in M60 and AFAIK not a single bug was filed due to it (we can trust our regression bisect to connect back to the bug): https://bugs.chromium.org/p/chromium/issues/detail?id=703344

[09:54:33.0000] <smaug____>
rbyers: oh, eventRate.html behaves very differently on Windows than on Linux Chrome.

[09:54:45.0000] <smaug____>
I see some brown dots on windows

[09:54:46.0000] <rbyers>
smaug____: Yeah sorry there's no instructions on eventRate.  It draws larger dots for events, smaller ones for coalesced events.

[09:55:10.0000] <smaug____>
I see no coalesced events on linux

[09:55:20.0000] <rbyers>
... the larger blue dots should be consistent across platforms in Chrome 60+

[09:55:23.0000] <smaug____>
oh, maybe if I move mouse very fast there are some

[09:55:27.0000] <rbyers>
Are you on Chrome 60+

[09:55:35.0000] <smaug____>
yup

[09:55:46.0000] <smaug____>
yeah, I guess blue dots are consistent

[09:55:49.0000] <rbyers>
A non-graphical version with more detail is here: https://rbyers.github.io/event-timing.html

[09:56:23.0000] <rbyers>
Right effectively the blue dots are the events whose timing is now controlled by the browser, the red dots are the raw coalescedEvents which are really up to the OS (and leak OS impl details).

[09:56:28.0000] <dtapuska>
smaug____: each os already has some vsync alignment sampling... depends on your mouse at least on linux

[09:56:50.0000] <rbyers>
dtapuska: Windows doesn't do an vsync alignment, does it?

[09:58:44.0000] <dtapuska>
rbyers: it depends on the hardware and a registry setting..  same with linux

[10:00:27.0000] <rbyers>
ah, all the more reason for the timing exposed to the web by default to be standardized (with an explicit opt-out like getCoalescedEvents for the rare cases the site really wants it)

[10:04:21.0000] <rbyers>
smaug____: So are you thinking you might like to switch to vsync-aligned mousemove before shipping PointerEvents in Firefox?

[10:04:56.0000] <smaug____>
well, just thinking

[10:05:09.0000] <rbyers>
... I don't have any fundamental objection to exposing new capabilities on MouseEvent or even TouchEvent, I just don't see much reason to prioritize it unless developers are telling us that's a blocker for them.  I know several in the PEWG would prefer we NOT expose new things on TouchEvent.

[10:05:39.0000] <smaug____>
stone just wrote a patch to vsync-aligned mousemoves. Rather simple patch to coalesce, mostly reusing our wheel event coalescing

[10:05:57.0000] <smaug____>
/me can't recall if Chrome coalesces wheel events

[10:06:18.0000] <smaug____>
rbyers: oh, yeah, I wouldn't want to add anything new to mouse events

[10:06:42.0000] <rbyers>
... But I've been in a "let's follow Apple without proactively investing ourselves" there (as we did for stylus support: https://github.com/w3c/touch-events/pull/81)

[10:07:33.0000] <rbyers>
smaug____: Yes we coalesce wheel but I forget if we vsync align them yet or not.  We should be.  dtapuska?

[10:08:55.0000] <rbyers>
No coalesced mousemove events?

[10:09:01.0000] <rbyers>
Sorry pointermove?

[10:09:31.0000] <smaug____>
ah, yeah, we don't sync wheel with vsync

[10:09:50.0000] <smaug____>
there is the problem that too much stuff is happening around vsync time

[10:09:53.0000] <rbyers>
If your OS is sending mouse movement at 60hz then it may not be noticeable unless you add some jank (which is what the UI at the bottom of eventRate is for).

[10:10:44.0000] <rbyers>
Interesting.  Our main problem has been that things happen at the wrong time causing redundant/useless work.  We want to kick of ALL the per-frame work at about rAF time.

[10:13:45.0000] <rbyers>
Of course there's sometimes too much per-frame work to fit into a single frame, but the beast answer there is to drop main-thread frames IMHO (not try to drop some of the things like wheel/scroll without also dropping rAF).  Of course compositor frames should generally continue to tick reliably at vsync.

[10:14:15.0000] <tobie>
TimothyGu: https://github.com/whatwg/html/pull/2932

[10:16:00.0000] <dtapuska>
rbyers: we rAF align mousewheels and touchmoves

[10:17:20.0000] <dtapuska>
smaug___: we flush any continuous events when we get a discrete event though... 'continuous' events are mousewheel, touchmove, mousemove

[10:32:03.0000] <tobie>
Would  a kind soul explain what's wrong with my PR so I can fix it? https://github.com/whatwg/html/pull/2932

[10:51:50.0000] <tobie>
Never mind. Closed an h6 element with an h4 tag.

[10:52:08.0000] <tobie>
And couldn't parse the error log properly.

[12:34:37.0000] <Domenic>
yoav: is rel=prerender still a thing?

[12:35:32.0000] <yoav>
I'm not sure, tbh

[12:36:07.0000] <yoav>
I know that the prerender implementation in Chromium got removed

[12:36:51.0000] <yoav>
I know there are plans for a simpler implementation that's more mobile friendly

[12:37:46.0000] <yoav>
based on the no-state-prefetch project (at least that's what I last heard)

[12:48:47.0000] <Yuhong>
Just added a few more standards to https://en.wikipedia.org/wiki/WHATWG#Specifications

[12:49:17.0000] <Yuhong>
I wrote the full proposal here: https://news.ycombinator.com/item?id=14977363

[12:53:43.0000] <Yuhong>
The fun thing is that W3C does at least have a culture of testing unlike the IETF.

[13:12:17.0000] <Domenic>
Thanks for updating Wikipedia, Yuhong!

[13:13:04.0000] <Domenic>
Not sure about this supposed culture of testing; we were the ones who pioneered https://blog.whatwg.org/improving-interoperability and although some W3C groups have started to adopt that as well, it's not a requirement like it is at the WHATWG

[13:14:20.0000] <Yuhong>
I am talking about the W3C candidate recommendation which the IETF don't have.

[13:16:20.0000] <Yuhong>
https://blog.whatwg.org/improving-interoperability

[13:16:27.0000] <Yuhong>
"Two table-related interfaces were ignored by implementers for a decade, but when finally removed from the standard it turned out that WebKit had just added them. Sorry!"

[13:16:47.0000] <Yuhong>
W3C require two or more implementations, not just one.

[13:17:14.0000] <Domenic>
"require"

[13:17:34.0000] <Domenic>
We also do, as per recently-clarified working mode... but we don't count emacs and lynx as implementations, as some W3C specs have.

[13:19:12.0000] <Domenic>
botie: tell rniwa we appreciate him muddling through the spec for datatransfer/drag and drop and welcome suggestions for clearer wording to avoid others going through his pain in the future.

[13:19:12.0000] <botie>
will do

[13:20:11.0000] <Yuhong>
Yes, I am referring to Adam Barth giving up on the IETF.

[13:20:48.0000] <Yuhong>
That being said, text mode browsers are still important. I wished that Ubuntu installed one by default for example.

[13:27:19.0000] <Yuhong>
I assume that the HTML parser itself has not changed much in a long time, right?

[13:28:06.0000] <JakeA>
It's updated whenever a new element is added, at least

[13:28:29.0000] <Domenic>
It's changed a decent bit

[13:28:42.0000] <JakeA>
<template> springs to mind

[13:28:55.0000] <Domenic>
https://github.com/whatwg/html/issues?utf8=%E2%9C%93&q=label%3A%22topic%3A%20parser%22%20

[13:38:26.0000] <Yuhong>
Most of these including new elements should be easy for validators to deal with though

[13:40:41.0000] <Yuhong>
BTW, I am not saying that W3C is particularly good. I am suggesting a compromise.

[13:41:50.0000] <Yuhong>
Especially since Jeff Jaffe has been discussing with Ian Hickson on that matter.

[13:42:12.0000] <Domenic>
I can tell you for a fact he has not been discussing that, at least not for years.

[13:42:29.0000] <Yuhong>
Yea, i am talking about years ago.

[13:42:37.0000] <Domenic>
I don't see your "compromise" improving the world in any way.

[13:45:32.0000] <Yuhong>
Yes, I mean in the sense of "HTML 3.2 aims to capture recommended practice as of early '96" for example.

[13:48:34.0000] <Domenic>
I think you'll find nobody in the WHATWG believes that's a useful thing to capture, and thus are not interested in a compromise that promotes that kind of outdated thinking.

[13:49:50.0000] <Yuhong>
Yea, I am not saying that versioning HTML is particularly good either.

[13:52:09.0000] <Yuhong>
I think we can all agree that what W3C is doing right now is far worse though.

[13:53:00.0000] <Domenic>
I think it's best to not pay attention to what they're doing and just work on making the actual spec better.

[13:53:19.0000] <Domenic>
We have a lot of "good first bugs" you could work on :) https://github.com/whatwg/html/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+bug%22

[13:53:44.0000] <Yuhong>
And it is not like that we hasn't worked on it with W3C either.

[13:53:49.0000] <Yuhong>
And it is not like that we hasn't worked on it with W3C before either.

[13:57:52.0000] <Yuhong>
I think the MIME type registry still lists W3C for text/html for example.

[14:06:19.0000] <Yuhong>
Of course, the full spec was probably never a good fit which was probably where the 2022 date came from.


2017-08-17
[21:09:12.0000] <Yuhong>
"I think you'll find nobody in the WHATWG believes that's a useful thing to capture,"

[21:09:19.0000] <Yuhong>
What are the problems with it?

[22:04:39.0000] <MikeSmith>
I wonder if somebody on the channel complained to freenode about botie

[22:05:12.0000] <MikeSmith>
I got a message from freenode about a half hour ago:

[22:05:54.0000] <MikeSmith>
13:42 [freenode] -!- You are banned from this server- Spam is off topic on freenode. Email kline⊙fn if in error  (2017/8/17 04.42)

[22:05:58.0000] <MikeSmith>
13:42 [freenode] -!- ERROR Closing Link: sideshowbarker.net (K-Lined)

[22:06:30.0000] <MikeSmith>
and got kicked

[22:07:43.0000] <MikeSmith>
I e-mailed that address just now to ask why, and will leave botie off until I hear back from them about whether it was due to somebody complaining about botie

[22:10:16.0000] <MikeSmith>
ah OK nm

[22:10:29.0000] <MikeSmith>
just got an automated e-mail message:

[22:10:32.0000] <MikeSmith>
> During a wave of spam today on freenode, it appears at first glance that a

[22:10:32.0000] <MikeSmith>
networking issue has caused some automated anti-abuse tools to trigger k-lines

[22:10:32.0000] <MikeSmith>
on a large number of gateways, multi-user hosts, and individuals.

[22:10:57.0000] <MikeSmith>
/me restarts botie

[22:24:01.0000] <TimothyGu>
wait, botie is a bot?

[22:24:07.0000] <TimothyGu>
/me feels dumb

[22:26:18.0000] <xfq>
botie, who are you

[22:26:18.0000] <botie>
no idea, xfq

[22:49:04.0000] <MikeSmith>
heh

[22:49:45.0000] <MikeSmith>
botie is just a simple way to leave messages for people who aren’t joined to the channel

[22:50:04.0000] <xfq>
and a calculator :)

[22:50:07.0000] <xfq>
botie, 1+1

[22:50:07.0000] <botie>
2

[22:50:12.0000] <MikeSmith>
aha

[22:50:24.0000] <MikeSmith>
yeah there are some other weird features in there

[22:52:08.0000] <MikeSmith>
but as far as the message thing, you just say, “botie, inform foonick please look at bar” and the next time foonick joins the channel, botie reads off the message

[22:52:11.0000] <MikeSmith>
https://github.com/w3c/infobot#syntax

[22:57:50.0000] <a-ja>
botie, inform MikeSmith more botsnacks, please!

[22:57:51.0000] <botie>
will do

[22:58:02.0000] <MikeSmith>
:)

[22:58:02.0000] <botie>
MikeSmith, at 2017-08-17 05:57 UTC, a-ja said: more botsnacks, please!

[00:51:02.0000] <tobie>
Sounds like botie passes the Turing test.

[01:10:42.0000] <mkwst>
Y'all are probably aware, but the HTML spec is down. :( https://html.spec.whatwg.org/ => 404.

[01:12:49.0000] <tobie>
annevk, Domenic: ^

[01:12:50.0000] <annevk>
Yeah, it's rather unclear what's going on unfortunately

[01:13:40.0000] <tobie>
zcorpan: what did you end up using [LegacyWindowAlias] on?

[01:13:41.0000] <annevk>
Some kind of DOS attack might be the cause, but DreamHost didn't give much details

[01:14:05.0000] <annevk>
tobie: it's used on https://url.spec.whatwg.org/#url-class

[01:14:48.0000] <zcorpan>
tobie: webkitURL and some things in https://drafts.fxtf.org/geometry/

[01:15:40.0000] <zcorpan>
tobie: not yet HTMLDocument, i guess that's not resolved yet if it can be an alias

[01:15:56.0000] <annevk>
I don't think it will be

[01:16:21.0000] <tobie>
Cool. Thank you both.

[01:25:11.0000] <TimothyGu>
What's the reasoning behind using a separate web ost rather than something like GH Pages?

[01:25:11.0000] <botie>
TimothyGu, at 2017-08-17 05:25 UTC, TimothyGu said: he's a nice person

[01:25:30.0000] <TimothyGu>
lmao

[01:25:43.0000] <TimothyGu>
sorry it was an experiment y'all

[01:26:38.0000] <MikeSmith>
heh

[01:26:53.0000] <MikeSmith>
botie is gonna get us all kicked

[01:26:56.0000] <annevk>
TimothyGu: last I checked GH Pages doesn't allow for custom domains and HTTPS

[01:27:35.0000] <TimothyGu>
right, but cloudflare does, unless you guys hate how cf operates?

[01:27:42.0000] <MikeSmith>
to me publishing with GH Pages is kind of a “now you have two problems” case

[01:28:03.0000] <annevk>
TimothyGu: wouldn't the connection between CF and GH be insecure?

[01:28:07.0000] <MikeSmith>
TimothyGu: ah I guess you just mean doing the cname thing

[01:29:05.0000] <annevk>
TimothyGu: see https://notapattern.net/2014/10/14/ways-men-in-tech-are-unintentionally-sexist/ btw

[01:29:29.0000] <TimothyGu>
annevk: well there's "full" mode, which does use HTTPS but doesn't check CA etc., versus "strict" which uses HTTPS all the way and checks for cert validity

[01:30:51.0000] <MikeSmith>
setting up HTTPS is relatively to do on our own with Let’s Encrypt

[01:30:59.0000] <annevk>
Hmm, but also seems somewhat sad to give all the user data to CF and GH (although I suppose a lot of it goes there anyway)

[01:31:25.0000] <TimothyGu>
that's true... but it's free!

[01:33:22.0000] <tobie>
What are the APIs that use [LenientSetter]? I've only found the fullscreen stuff.

[01:34:02.0000] <TimothyGu>
annevk: and thanks for the link

[01:35:07.0000] <TimothyGu>
(Sorry to anyone I unintentionally insulted.)

[01:35:18.0000] <annevk>
TimothyGu: it is worth considering though, https://github.com/whatwg/meta/issues/8 is the corresponding issue

[01:35:37.0000] <annevk>
MikeSmith's been arguing for something we fully control for a while

[01:36:21.0000] <MikeSmith>
yeah if we move to something we have full root access to I am willing to invest time in ongoing maintenance

[01:36:29.0000] <annevk>
I like the idea of outsourcing most things, if we don't end up compromising too much

[01:36:41.0000] <TimothyGu>
DigitalOcean's cheapest is $5/month

[01:36:54.0000] <TimothyGu>
that's not too bad, right?

[01:37:13.0000] <Ms2ger>
tobie, that seems to be it, as far as Gecko's impl goes

[01:37:14.0000] <MikeSmith>
yeah it’s cheap but I think we would need to pay for more RAM

[01:37:29.0000] <annevk>
Heh yeah, we should be able to scrape some money together

[01:37:35.0000] <tobie>
Ms2ger: yeah, that's what searchfox gives me too.

[01:38:20.0000] <MikeSmith>
annevk: you could consider it as outsourcing to me

[01:38:45.0000] <tobie>
I'm pretty convinced DO would be happy to offer a large server for a small "graciously hosted by DO" mention somewhere, fwiw

[01:38:47.0000] <MikeSmith>
I reckon I would be a lot more responsive than some 3rd party, and more competent than Dreamhost by a giant stretch

[01:39:10.0000] <TimothyGu>
there's also S3 if the website's fully static

[01:39:30.0000] <tobie>
TimothyGu: it's not.

[01:39:35.0000] <MikeSmith>
I have run my own mail server and bind nameserver etc etc since relatively the dawn of time

[01:39:55.0000] <annevk>
tobie: apart from the wiki it mostly is I think

[01:40:04.0000] <TimothyGu>
oh well

[01:40:08.0000] <annevk>
MikeSmith: hahaha

[01:40:26.0000] <tobie>
annevk: well, that's the other option that I use for specref, for example.

[01:40:46.0000] <tobie>
annevk: host the static stuff on GH Pages (cert issues though)

[01:40:52.0000] <annevk>
MikeSmith: I'm starting to warm up to the idea tbh

[01:41:13.0000] <tobie>
annevk: and use something like Heroku for the part that needs server logic

[01:41:17.0000] <annevk>
MikeSmith: especially if we just manage all the configuration in a GitHub repository as well

[01:41:52.0000] <annevk>
tobie: yeah GH Pages isn't really an option imo

[01:42:09.0000] <annevk>
I'd like full marks for HTTPS

[01:42:17.0000] <annevk>
s/like/want/

[01:42:22.0000] <tobie>
S3 would give you that.

[01:42:27.0000] <tobie>
afaik

[01:42:45.0000] <tobie>
No?

[01:43:15.0000] <TimothyGu>
yeah it will

[01:43:23.0000] <TimothyGu>
still doesn't address the wiki issue though

[01:43:41.0000] <TimothyGu>
heroku *should* work but the startup performance of the free plan is kinda bad

[01:44:15.0000] <MikeSmith>
as far as no-static stuff IMHO, not having to run MySQL or some other DB would be feature

[01:44:26.0000] <MikeSmith>
oh, or PHP

[01:44:42.0000] <MikeSmith>
wiki.whatwg.org is PHP, right?

[01:44:58.0000] <MikeSmith>
don’t want to volunteer to maintain that

[01:44:59.0000] <TimothyGu>
mediawiki is, yeah

[01:45:02.0000] <MikeSmith>
OK

[01:45:26.0000] <MikeSmith>
well I think we should just move all the wiki.whatwg.org stuff to github wiki

[01:45:44.0000] <MikeSmith>
I did that already for all the stuff in the wiki related to the validator

[01:45:56.0000] <MikeSmith>
https://github.com/validator/validator/wiki

[01:46:04.0000] <annevk>
We could also leave wiki.whatwg.org and other problematic stuff, if any, on DreamHost for the time being

[01:46:05.0000] <MikeSmith>
that has worked out well for that case at ealst

[01:46:11.0000] <annevk>
I think that's doable

[01:46:16.0000] <MikeSmith>
ah true

[01:46:50.0000] <tobie>
TimothyGu: I'm in discussion with Heroku to get them to cover the cost of hosting specref, pr-preview, and the wpt-bot, which I'm currently paying for myself.

[01:47:25.0000] <tobie>
TimothyGu: if that works out, extending that sponsorship shouldn't be too difficult.

[01:48:57.0000] <TimothyGu>
tobie: ooh nice

[01:50:11.0000] <TimothyGu>
MikeSmith: GitHub's wiki isn't exactly the most featureful though. also not quite sure why it's called "gollum".

[01:50:41.0000] <MikeSmith>
yeah I think that’s by design

[01:50:50.0000] <TimothyGu>
not sure how many features the current wiki is using but IIRC gollum doesn't have templates. templates.

[01:50:53.0000] <MikeSmith>
like a lot of GitHub stuff

[01:50:58.0000] <MikeSmith>
the 20/80 thing

[01:51:12.0000] <TimothyGu>
yeah yeah

[01:51:27.0000] <MikeSmith>
I like the feature philosophy they follow at GitHub

[01:51:34.0000] <MikeSmith>
well in general at least

[01:52:00.0000] <MikeSmith>
except for the specific cases where they refuse to add some feature I personally want

[01:52:17.0000] <TimothyGu>
I like their issue tracker

[01:52:22.0000] <TimothyGu>
that's about it

[01:54:44.0000] <annevk>
MikeSmith: FWIW, I don't think we should embrace GH's wiki

[01:54:56.0000] <annevk>
MikeSmith: I much prefer static pages that can be maintained through PRs

[01:55:32.0000] <MikeSmith>
annevk: you can do that with GH wiki

[01:55:39.0000] <MikeSmith>
it is just a git repo

[01:55:44.0000] <TimothyGu>
PR's though?

[01:55:57.0000] <MikeSmith>
ah yeah maybe you can’t do PRs

[01:56:24.0000] <MikeSmith>
but you can roll back changes at least

[01:56:37.0000] <tobie>
Is fullscreen not in shepherd?

[01:56:56.0000] <tobie>
I can't seem to be able to link {{Document/fullscreenEnabled}}

[02:00:42.0000] <tobie>
Is summoning TabAtkins the way to get fullscreen in Shepherd? Or do I need to look for plinss in another channel?

[02:01:05.0000] <MikeSmith>
I think you need plinss

[02:01:23.0000] <MikeSmith>
but I think TabAtkins can also proxy efficiently

[02:01:38.0000] <tobie>
I'll ping plinss on #specs

[02:16:06.0000] <timdream>
https://html.spec.whatwg.org/ is down

[02:18:26.0000] <annevk>
timdream: ta, known :/

[02:24:06.0000] <a-ja>
/me hopes DOJ isn't confiscating DH's servers

[02:29:27.0000] <annevk>
timdream and everyone else, I put html.spec.whatwg.org back

[02:29:36.0000] <annevk>
Hopefully DH doesn't take us out...

[02:29:50.0000] <timdream>
annevk: \o/

[02:30:17.0000] <MikeSmith>
yay

[02:32:18.0000] <MikeSmith>
annevk: https://github.com/whatwg/fetch/pull/578 should be ready again (sorry for delay in getting back to it)

[02:39:00.0000] <annevk>
MikeSmith: ta, merged

[02:40:07.0000] <MikeSmith>
thanks

[03:31:49.0000] <tobie>
Started linking the legacy APIs affected by specific extended attributes directly from within the WebIDL spec:

[03:31:50.0000] <tobie>
https://s3.amazonaws.com/pr-preview/tobie/webidl/link-legacy-apis.html#LegacyWindowAlias

[03:32:03.0000] <tobie>
(and following)

[03:33:11.0000] <tobie>
Thoughts welcome before I continue with this, WIP PR is here:

[03:33:11.0000] <tobie>
https://github.com/heycam/webidl/pull/416

[03:34:20.0000] <Ms2ger>
The double colouring looks kinda odd

[03:37:16.0000] <tobie>
Ms2ger: agreed

[03:37:35.0000] <tobie>
Ms2ger: maybe there's another way in BS to make a paragraph non normative.

[03:38:07.0000] <tobie>
Ms2ger: I don't want the references to end-up as normative.

[03:40:30.0000] <Ms2ger>
Good point

[03:45:38.0000] <tobie>
Ms2ger: I guess I could manually style things differently.

[03:45:57.0000] <Ms2ger>
Isn't there an unstyled non-normative class?

[03:46:08.0000] <tobie>
Ms2ger: I don't think so?

[03:46:49.0000] <tobie>
oh, it could be a custom attribute

[03:47:07.0000] <tobie>
(class="informative" doesn't work)

[03:48:37.0000] <tobie>
it's non-normative

[03:48:39.0000] <tobie>
duh

[03:53:59.0000] <tobie>
Ms2ger: "non-normative" works

[03:54:35.0000] <tobie>
Ms2ger: we loose the separation between the advisement, and the know use cases

[03:54:43.0000] <tobie>
Ms2ger: subtitle for the latter?

[03:57:10.0000] <tobie>
Ms2ger: <small></small>?

[03:57:18.0000] <Ms2ger>
I dunno

[04:01:36.0000] <tobie>
Ms2ger: you should be able to refresh.

[04:06:14.0000] <Ms2ger>
That looks nicer, yes

[04:08:48.0000] <tobie>
 Good.

[04:09:32.0000] <tobie>
Otherwise having those in written like this seems valuable to someone else than just me?

[04:20:56.0000] <zcorpan>
Domenic: does https://github.com/whatwg/html/issues/2615 have data now?

[04:26:18.0000] <zcorpan>
found it on chromestatus

[05:34:12.0000] <annevk>
Domenic: https://github.com/whatwg/meta/issues/8#issuecomment-323059182 can't be everything

[05:34:24.0000] <annevk>
Domenic: not sure how things are structured, but e.g. spec.whatwg.org isn't listed

[05:34:41.0000] <Domenic>
Uhhh good point, hmm.

[05:34:54.0000] <Domenic>
It doesn't show up when cloudflare does a scan of the DNS, so that's not great...

[05:35:00.0000] <Domenic>
Maybe I should tell cloudflare to scan spec

[05:35:11.0000] <annevk>
Domenic: also missing validator.whatwg.org

[05:36:08.0000] <Domenic>
OK, I guess cloudflare auto-scanning is a bust. We need to get the DNS records list from Hixie. I'll update the issue.

[05:48:02.0000] <TimothyGu>
annevk: so y'all have decided to use cloudflare huh?

[05:48:55.0000] <annevk>
TimothyGu: Domenic is a fan

[05:49:10.0000] <TimothyGu>
ah nice

[05:49:24.0000] <annevk>
TimothyGu: and even if we move hosting providers it'd be annoying to deal with DOS ourselves

[05:49:34.0000] <Domenic>
It's trickier than anticipated I guess, so maybe not today. But I'd like to eventually.

[06:05:13.0000] <tobie>
annevk: what would you say the data-dfn-for would be for the event handlers in HTML?

[06:06:25.0000] <annevk>
tobie: depends on the object they're on I guess

[06:06:59.0000] <tobie>
annevk: I'm talking about these ones

[06:07:00.0000] <tobie>
https://html.spec.whatwg.org/#event-handlers-on-elements,-document-objects,-and-window-objects

[06:07:56.0000] <annevk>
tobie: HTMLElement,Document,Window?

[06:09:27.0000] <tobie>
yes, the conclusion I was arriving at too. As usual, stating the problem mostly solves it.

[06:09:34.0000] <tobie>
Sorry. :-/

[06:27:04.0000] <tobie>
Is exporting DFNs "Meta: " or "Editorial:  "?

[06:27:17.0000] <Domenic>
Meta:

[06:27:23.0000] <Domenic>
(Although I don't think the ES spec does Meta:)

[06:27:47.0000] <tobie>
Thanks

[06:32:35.0000] <zcorpan>
Should link-fixup.js do nothing if the URL doesn't start with /multipage/ ? what about /dev/ ? currently it redirects https://html.spec.whatwg.org/robots.txt#video to https://html.spec.whatwg.org/media.html#video which is still a 404

[06:33:25.0000] <Domenic>
zcorpan: doing nothing for non-/multipage/ or /dev/ sounds good.

[09:07:26.0000] <tobie>
Known uses of TreatNonObjectAsNull beyond EventHandlerNonNull, OnBeforeUnloadEventHandlerNonNull and OnErrorEventHandlerNonNull in HTML?

[09:17:29.0000] <gsnedders>
are WebIDL sequences what ES "array exotic objects"?

[09:17:48.0000] <gsnedders>
(i.e., does Array.isArray(x) return true for a WebIDL sequence x?)

[09:18:24.0000] <gsnedders>
yes, because WebIDL sequences are realised as Arrays, right?

[09:19:53.0000] <tobie>
gsnedders: yes, sequences are converted to arrays: https://heycam.github.io/webidl/#es-sequence

[09:21:17.0000] <gsnedders>
do we have any notion of a more general sequence, including e.g. NodeList?

[09:31:22.0000] <tobie>
gsnedders: Not sure what the question is.

[09:31:45.0000] <tobie>
gsnedders: Do we have a generic type that regroup all iterables?

[09:32:32.0000] <gsnedders>
(are iterables in ES necessarily finite?)

[09:33:07.0000] <gsnedders>
or subscriptable, I guess, too

[09:33:28.0000] <gsnedders>
like I want to know "is this an object x where I can do x[i] for all i < x.length?"

[09:33:48.0000] <gsnedders>
realistically, that probably just means "is there a x.length property?"

[09:35:56.0000] <annevk>
gsnedders: there's Infra's list

[09:36:11.0000] <annevk>
gsnedders: which eventually is what sequence<> (on the input side) would be converted into

[09:36:21.0000] <annevk>
gsnedders: after some editing iterations

[10:35:07.0000] <JakeA>
Is it ok in webidl to create an iterable where the values are created lazily? Eg, calling iterable[5] will run an algorithm that returns a promise, a further call to iterable[5] will return the value previously returned. The length of the iterable is known up front.

[10:38:09.0000] <JakeA>
Use-case: We have a disk-backed store of potentially 10000+ requests & responses (eg a chunked movie). We don't want to have to create all of them unless the developer asks for them.

[10:38:47.0000] <JakeA>
https://github.com/WICG/background-fetch/issues/47

[11:11:45.0000] <tobie>
JakeA: I *think* that's OK. Or rather, I can't seem to see upfront what would prevent that in the spec.

[11:12:35.0000] <JakeA>
tobie: ta!

[11:13:52.0000] <tobie>
JakeA: these will just be getters, right?

[11:17:01.0000] <JakeA>
tobie: indexed getters yeah. No setters.

[11:20:16.0000] <tobie>
JakeA: fwiw, outside of the Promise-returning concern, I'm not sure what the stance is wrt to setters and getters nowadays. I think it depends who you ask.

[11:24:42.0000] <nox>
Is calc() serialisation in specified values specified?

[11:26:42.0000] <ecobos>
nox: https://drafts.csswg.org/css-values/#calc-serialize

[11:26:48.0000] <ecobos>
nox: will file

[11:27:21.0000] <nox>
ecobos: I was like, "who are you, how do you know something needs to be filed?"

[11:27:32.0000] <ecobos>
nox: lol :)

[11:27:44.0000] <ecobos>
nox: there's apparently an emilio that was before me on freenode, oh well

[11:27:55.0000] <nox>
Hah.

[11:28:48.0000] <ecobos>
nox: oh, actually, section 3 defines what we should do

[13:24:14.0000] <rbyers>
annevk: Hey, I'm working on the spec for a new Observer-pattern API (ReportingObserver) and looking for good examples to follow.  Are you more-or-less happy with the definition of MutationObserver in the DOM spec?

[13:46:13.0000] <tobie>
Which are the [NoInterfaceObject] interfaces that aren't mixins?

[13:51:38.0000] <TabAtkins>
Mistakes.

[13:51:40.0000] <TabAtkins>
^_^

[13:53:51.0000] <tobie>
found FontFaceSetIterator for now

[13:54:16.0000] <tobie>
TabAtkins: :)

[14:08:23.0000] <Domenic>
gsnedders: on the input side, any ES iterable (e.g. a NodeList instance) can be converted to a sequence<>. On the output side, returning a sequence<> returns an ES Array.

[14:08:48.0000] <Domenic>
JakeA: this sounds like async iterators?

[14:18:21.0000] <JakeA>
Domenic: kinda, although we know the length in advance, and we can return the nth item at any point. Also Promise.all(fetches) works, which is nice

[14:20:18.0000] <Domenic>
Hmm I see, maybe not then, yeah.

[14:28:03.0000] <botie>
rniwa, at 2017-08-16 20:19 UTC, Domenic said: we appreciate him muddling through the spec for datatransfer/drag and drop and welcome suggestions for clearer wording to avoid others going through his pain in the future.

[16:51:43.0000] <wanderview>
JakeA: you can't use IDB for this because its a streamed Response?

[16:52:23.0000] <wanderview>
JakeA: also, I personally think any API like this should allow getRange(start, end) and getInList(indexList) type calls


2017-08-18
[00:20:06.0000] <annevk>
rbyers: I'm probably not the right person to ask, smaug____ et al designed that

[00:52:41.0000] <annevk>
rbyers: aklein is probably closer to you timezone wise, although you never know with smaug____

[00:53:40.0000] <annevk>
Is there something like ripgrep for blame?

[00:56:06.0000] <Ms2ger>
smaug____ tends to hover between US west coast and US east coast as far as timezones go

[01:22:17.0000] <JakeA>
wanderview: https://github.com/WICG/background-fetch/issues/47 might explain the use-cases better. Supporting list[index] should be fine. The JS equivalent for getRange is list.slice, but it doesn't seem like that comes by default with webidl iterators.

[01:32:14.0000] <tobie>
JakeA: I guess you can always file an issue. We'd need to check whether adding it in WebIDL would conflict with other interfaces implementing iterators and then whether there's implementor interest.

[01:39:14.0000] <JakeA>
It makes me sad the number of MDN pages that suggest APIs are "unstable". Who has the power to change policy here? Who do I have to convince?

[01:39:44.0000] <JakeA>
Eg, two unflagged stable implementations shouldn't be considered experimental/unstable (eg https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API)

[01:41:23.0000] <Ms2ger>
Talk to sheppy

[01:41:32.0000] <Ms2ger>
On irc.m.o

[01:45:15.0000] <smaug____>
/me pings sheppy on this matter

[01:51:31.0000] <zcorpan>
http://www.w3.org/mid/BAA808E3-0BCA-45AF-845C-541D35D7A330⊙wo ... wonder if i should point Tim to crbug.com/new ? Also shouldn't it be Vary: access-control-allow-origin ?

[01:56:25.0000] <annevk>
zcorpan: Vary: Origin is correct, I suspect it's credentials that's biting him

[01:57:09.0000] <annevk>
zcorpan: https://github.com/whatwg/fetch/issues/307

[01:58:15.0000] <zcorpan>
ah right, I somehow thought Vary was for response headers

[02:05:08.0000] <zcorpan>
annevk: so one of https://github.com/whatwg/fetch/pull/496#issuecomment-287659974 ?

[02:13:14.0000] <annevk>
zcorpan: no

[02:13:49.0000] <annevk>
zcorpan: the spec still doesn't specify that behavior because only Fx implements it and Chrome is opposed (well Ryan Sleevi is) and I dunno about Safari and Edge

[03:10:25.0000] <smaug____>
rbyers: FWIW, I think MutationObserver part of the spec is quite reasonable.

[03:11:30.0000] <smaug____>
(I do regret microtasks a bit, but that isn't so much to do with MutationObserver anymore.)

[04:04:44.0000] <MikeSmith>
annevk: I’m pretty sure Tim’s case is that he is sending credentials. Otherwise he’d just have the server responding with the wildcard in the ACAO value, instead of an origin

[04:05:35.0000] <MikeSmith>
but I don’t understand why it’s not just a Chrome bug, regardless of whether the request includes credentials

[04:06:07.0000] <MikeSmith>
I mean, on the face of it at least, it seems like Chrome is ignoring the Vary: Origin header and not invalidating its cache when it should be

[04:09:08.0000] <annevk>
MikeSmith: oh, that does seem like a more basic bug, yes

[04:11:01.0000] <MikeSmith>
yeah to be clear, as far as I understand, Tim’s issue isn’t about credentialed and non-credentialed requests and expecting the cache to be shared between those

[04:11:22.0000] <MikeSmith>
his issue is sorta the oppositi

[04:11:57.0000] <MikeSmith>
he described this problem to me a long time ago but I didn

[04:12:30.0000] <MikeSmith>
didn’t know what to say other than that it sounded like a browser bug to meーnon-conformant behavior

[06:35:50.0000] <wanderview>
JakeA: MDN is also a wiki... you can make changes directly

[06:38:16.0000] <wanderview>
JakeA: I guess I still just wish IDB had a bulk getter that didn't require contiguous ranges

[07:03:17.0000] <yoav_>
annevk: So, I'm looking at https://github.com/w3c/preload/issues/95 and I think we need to say (in HTML) that `as` defines both the potential destination as well as the resulting request type

[07:04:01.0000] <yoav_>
and wondered what's the best way to define destination=>type mapping

[07:04:23.0000] <yoav_>
it's already "defined" in the non-normative note table in Fetch

[07:04:40.0000] <yoav_>
but could probably benefit from a normative definition

[07:04:56.0000] <yoav_>
where is request type set today?

[07:15:57.0000] <annevk>
yoav_: it's set by the places that create a request to fetch

[07:16:36.0000] <annevk>
yoav_: there's not really a destination=>type mapping though, they are separate things

[07:37:06.0000] <yoav_>
annevk: so if I want to define such mapping for preload, should I do that in the preload spec?

[07:41:04.0000] <annevk>
yoav_: I don't think it makes sense

[07:41:16.0000] <annevk>
yoav_: they're intentionally separate

[07:41:35.0000] <yoav_>
annevk: What I want to define is that for `<link rel=preload as=image>` the a

[07:41:48.0000] <yoav_>
Accept headers will state supported image types

[07:41:54.0000] <yoav_>
similarly to <img src>

[07:42:48.0000] <yoav_>
that's currently vaguely defined in the preload spec, in the section that you said is a duplicate in https://github.com/w3c/preload/issues/95

[07:46:30.0000] <rbyers>
smaug____, annevk: thank you!

[07:46:56.0000] <annevk>
yoav_: looking over the current setup I wonder if we can do away with type now that destination is a strict superset (I don't think it was before)

[07:47:41.0000] <annevk>
yoav_: we'd have to define some shorthand for "is a script destination" though and update CSP and such

[07:47:50.0000] <yoav_>
that'd be good from my perspective

[07:48:04.0000] <annevk>
yoav_: (in particular, I think before media was a destination and types had audio and video)

[07:48:21.0000] <yoav_>
yeah, and then we broke them up

[07:49:26.0000] <annevk>
yoav_: I think that's probably the best course of action; we'd need review from mkwst and some other folks and figure out who depends on the current setup, would have to change quite a few standards I think

[10:23:32.0000] <Yuhong>
I do agree that caniuse.com etc probably does a better job than spec snapshots, but this is intended to be a compromise.

[10:46:49.0000] <Domenic>
annevk: I think rbyers was also asking about spec style.

[10:48:02.0000] <rbyers>
Domenic: Yeah, I just watched your "how to write good specs" talk, so am extra motivated to get better at using very precise style :-)

[10:49:29.0000] <annevk>
Domenic: oh, I haven't reviewed that section in a while, but it's probably okay

[10:50:16.0000] <Domenic>
It does seem OK

[10:50:34.0000] <Domenic>
DOM still does a lot of foo's <b>bar</b> instead of foo's <a>bar</a>

[10:50:47.0000] <Domenic>
But it seems to use internal slots correctly and such

[10:51:08.0000] <annevk>
Except for Event

[10:51:21.0000] <Domenic>
Oh, no, MutationRecord doesn't use slots properly

[10:51:33.0000] <Domenic>
Basically because MutationRecord should be a dictionary

[10:51:48.0000] <annevk>
And DOM has a problem in general with not having [[PlatformBrand]] in IDL

[10:52:24.0000] <Domenic>
rbyers: so yeah, MutationRecord being an interface instead of a dictionary seems not so good; otherwise things seem reasonable.

[10:55:26.0000] <rbyers>
Domenic: Thanks!

[10:59:39.0000] <annevk>
Domenic: note that esprehn will argue strongly for not using dictionaries for such things as it's hard for Chrome to cope

[11:00:26.0000] <TabAtkins>
For return values?

[11:00:40.0000] <annevk>
Yeah

[11:01:21.0000] <Domenic>
It's not really a return value, it's passed to a callback

[11:01:28.0000] <TabAtkins>
Yeah, agree; records are a bad pattern that we shouldn't be using. :(

[11:01:37.0000] <TabAtkins>
Domenic: Same diff really.

[11:01:52.0000] <annevk>
smaug____: I thought you said https://bugzilla.mozilla.org/show_bug.cgi?id=825057 was something we supported

[11:02:03.0000] <TabAtkins>
annevk: Note that esprehn has left Chrome to work elsewhere in Google. :(

[11:02:08.0000] <annevk>
TabAtkins: you agree with esprehn?

[11:02:16.0000] <annevk>
o_O

[11:02:28.0000] <TabAtkins>
I often do?

[11:02:38.0000] <smaug____>
annevk: hmm, I thought data was working

[11:02:39.0000] <annevk>
I do too, but for this issue

[11:03:23.0000] <TabAtkins>
Yeah, we shouldn't have done records, returning "dumb data objects" makes it user-observable if/when we change it to something with methods on it or with more complicated behavior.

[11:03:40.0000] <TabAtkins>
And passing to a callback is functionally identical to returning.

[11:06:04.0000] <smaug____>
annevk: data: seems to work here

[11:06:25.0000] <smaug____>
oh, silly me

[11:06:34.0000] <smaug____>
that was inside data: page

[11:06:37.0000] <smaug____>
not data: worker

[11:07:40.0000] <smaug____>
but I get PASS with the testcase there

[11:25:13.0000] <Yuhong>
If there are any other problems, I want to ask about them.

[13:24:56.0000] <jyasskin>
Has anyone started writing down the matching algorithm between request headers within Fetch and the request headers in a PUSH_PROMISE frame?

[16:54:22.0000] <luxio>
why do we only have one option for client-side scripting languages?


2017-08-19
[18:51:42.0000] <deltab>
luxio: there have been others, but ultimately they've failed to overcome the network effect of JS

[03:27:10.0000] <tobie>
Is travis build for https://github.com/whatwg/html/pull/2932 failing because of https://github.com/whatwg/html/pull/2941?

[03:28:56.0000] <MikeSmith>
tobie: yes

[03:29:43.0000] <tobie>
ty

[03:29:53.0000] <MikeSmith>
np

[03:50:25.0000] <tobie>
MikeSmith: is wattsi deployed somewhere?

[03:51:23.0000] <tobie>
MikeSmith: and will it continue being deployed once travis handles all of the builds?

[03:52:01.0000] <tobie>
Oh, I think I found it.

[05:27:27.0000] <tobie>
I can't seem to be able to unzip the output of the hosted wattsi server.

[06:06:07.0000] <TimothyGu>
wait, HTML has its own preprocessor?

[06:07:32.0000] <TimothyGu>
and it's written in Pascal? I'm impressed

[06:10:44.0000] <xfq>
yeah

[06:10:46.0000] <xfq>
it's created long before Bikeshed existed

[09:08:16.0000] <gsnedders>
TimothyGu: it went from a mess of Perl scripts calling custom C processors to a Python preprocessor (that was in many ways the pre-Bikeshed) to a custom Pascal one

[09:08:25.0000] <gsnedders>
TimothyGu: each move being faster than what came before

[12:11:47.0000] <Domenic>
This should fix PR CI https://github.com/whatwg/html-build/pull/119


2017-08-20
[23:59:04.0000] <JakeA>
Seems like MDN has a policy of marking APIs as experimental until they're in a spec marked CR. Pretty hostile to WHATWG specs.

[00:10:48.0000] <Domenic>
JakeA: That can't be right. The MDN folks have been pretty good to WHATWG specs recently. Maybe different MDN folks than the ones I talk to...

[00:12:45.0000] <JakeA>
Domenic: I was told it's explicit policy. Of course, the person who told me this could be mistaken.

[00:13:12.0000] <Domenic>
bizzare... Want me to start a thread with the person who was nice to me?

[00:13:37.0000] <JakeA>
That'd be great!

[01:46:56.0000] <annevk>
That should indeed be escalated somehow as that seems rather bogus

[01:47:08.0000] <annevk>
Happy to help if needed


2017-08-21
[00:09:12.0000] <yoav>
annevk: to continue our discussion from last week, maybe I can simply modify step 3 in https://fetch.spec.whatwg.org/#concept-fetch to be based on destination rather than type

[00:09:47.0000] <yoav>
that would solve the preload case and help nudge us towards a future without `type` (without breaking other specs that may rely on type)

[00:11:44.0000] <annevk>
I'd rather we just fix it all in one go

[00:11:48.0000] <annevk>
I'm happy to help

[00:14:06.0000] <yoav>
OK

[00:15:41.0000] <yoav>
what about other specs that may rely on type?

[00:17:02.0000] <annevk>
yoav: we should probably submit PRs

[00:17:46.0000] <yoav>
ok, is there an index that tracks usage? (or should we just look around for them)

[00:18:09.0000] <annevk>
yoav: no index, though we should maybe add one in the source of Fetch as we find them

[00:18:13.0000] <annevk>
I found https://w3c.github.io/webappsec-csp/#effective-directive-for-a-request

[00:19:08.0000] <annevk>
https://w3c.github.io/webappsec-mixed-content/

[00:19:10.0000] <annevk>
and HTML

[00:19:13.0000] <annevk>
I think that's it

[00:20:55.0000] <annevk>
https://w3c.github.io/webappsec-subresource-integrity/ uses destination, but not type

[00:21:00.0000] <annevk>
I guess we should note that it relies on destination

[00:21:15.0000] <annevk>
yoav: I'll file a tracking issue against Fetch

[00:21:22.0000] <yoav>
ok, thanks

[00:21:29.0000] <annevk>
yoav: and I'll work on the HTML patch

[00:22:37.0000] <yoav>
Thanks, I'll clean preload in the mean time

[00:35:24.0000] <annevk>
yoav: I found that we never aligned HTML with the change you made to Fetch...

[00:35:37.0000] <yoav>
hmm...

[00:35:45.0000] <annevk>
yoav: for <audio>, <video>, and <track> destination was still set to "media"

[00:35:53.0000] <annevk>
yoav: I hope we did end up testing that somehow

[00:36:37.0000] <yoav>
tested that change for preload, but not sure for HTML

[00:36:39.0000] <yoav>
looking

[00:39:08.0000] <yoav>
can't find an HTML test for that

[00:39:38.0000] <yoav>
also, IIRC last time I tried to test in SW based on Request.destination, it wasn't really implemented anywhere

[00:40:08.0000] <yoav>
but can try again (or add a failing test)

[00:41:23.0000] <annevk>
yoav: oh that's interesting, is .type implemented?

[00:41:44.0000] <yoav>
dunno

[00:42:20.0000] <annevk>
nope

[00:42:40.0000] <annevk>
Both are undefined for (new Request("about:blank")).type|destination

[00:42:46.0000] <annevk>
So I guess that means we can easily remove type

[00:42:56.0000] <annevk>
That simplifies matters

[00:43:12.0000] <yoav>
Regarding preload's https://w3c.github.io/preload/#link-element-extensions

[00:43:34.0000] <annevk>
Would still be good to have failing tests for destination I suppose, now we're double downing on that approach with rel=preload

[00:44:12.0000] <yoav>
I can easily remove the parts that use type, but there's nothing in HTML that replaces "When the resource is declared via the Link header field ([RFC5988]), the resource's as attribute is defined via the as link-extension target attribute. ([RFC5988] section 5.4)"

[00:45:00.0000] <yoav>
(or anything that maps the other attributes from WEBLINK to HTML)

[00:45:14.0000] <yoav>
and I'm not sure if this is needed or not

[00:46:29.0000] <annevk>
I suspect the HTTP Link header is rather poorly defined for things defined in HTML too

[00:46:42.0000] <annevk>
E.g., nothing really says how that header works for rel=stylesheet

[00:46:54.0000] <yoav>
yup

[00:47:09.0000] <annevk>
I'd probably keep the text and maybe file an issue against HTML about providing better infrastructure for that

[00:47:13.0000] <yoav>
there's no mapping from the header to the attributes

[00:47:46.0000] <annevk>
For rel=stylesheet you need even more, as it also influences APIs and such

[01:25:47.0000] <annevk>
JakeA: can https://github.com/whatwg/fetch/issues/556 be closed?

[01:25:51.0000] <annevk>
JakeA: and https://github.com/whatwg/fetch/issues/554?

[01:51:34.0000] <zcorpan>
Hmm, this is curious. `<!DOCTYPE html SYSTEM""` sets force-quirks, but `<!DOCTYPE html SYSTEM""x` does not

[01:52:31.0000] <zcorpan>
not going to change it though

[04:43:15.0000] <JakeA>
annevk: done

[05:55:28.0000] <annevk>
belated ta!

[07:02:07.0000] <annevk>
Is GitHub slow for anyone else?

[07:02:18.0000] <annevk>
It also doesn't seem to update Travis at a reasonable speed

[07:05:23.0000] <tobie>
annevk: https://status.github.com/

[07:05:37.0000] <tobie>
(i.e. yup)

[07:08:14.0000] <annevk>
ta

[07:21:28.0000] <annevk>
Oooh fun, Firefox Nightly is sticking with the doge logo

[07:21:30.0000] <wanderview>
JakeA: I wish MDN would just link to caniuse.com for API stability info... it seems to be more reliable and a better measure of "experimental" status

[07:22:49.0000] <wanderview>
annevk: I just wish they would stop changing the icon... its fun but too much gets a bit annoying

[07:22:56.0000] <JakeA>
Yeah, agreed!

[07:23:37.0000] <annevk>
wanderview: it's still the same icon in the doc here on macOS

[07:23:53.0000] <wanderview>
JakeA: or maybe make out "experimental" thing link to a "this a w3c spec related thing on MDN" explainer and also provide a caniuse.com link

[07:23:58.0000] <wanderview>
^out^our

[07:24:00.0000] <annevk>
wanderview: though in Spotlight I get the old logo

[07:24:08.0000] <annevk>
messy

[07:24:46.0000] <wanderview>
annevk: I just mean how it went from old nightly -> new nightly -> calvin+hobbes -> firefox 0.8 -> firedoge in the space of a few weeks

[07:25:08.0000] <annevk>
wanderview: ah yeah, I saw that on Twitter, though never really noticed it happening

[07:25:11.0000] <wanderview>
we should have an opt out if we are going to do this sort thing

[07:25:24.0000] <annevk>
wanderview: I only noticed the change to new Nightly as that ended up changing the icon on the doc

[07:25:27.0000] <wanderview>
although I can see how that would be hard

[07:25:38.0000] <annevk>
wanderview: maybe I need to reboot or some such for icons to update so often?

[07:26:06.0000] <beverloo>
annevk: qq for the push api, would we want to define [SecureContext] on the event types as well, given that them being limited to secure contexts is implied by them only being available on the SW global scope?

[07:26:22.0000] <wanderview>
annevk: I think its hit or miss whether it replaces your dock icon unless you stop and restart firefox... I think the dock keeps it cached or something

[07:26:36.0000] <annevk>
beverloo: the events already have Exposed=ServiceWorker?

[07:26:41.0000] <beverloo>
yes

[07:26:50.0000] <annevk>
beverloo: in that case it's a no-op, but might as well for clarity

[07:27:45.0000] <annevk>
wanderview: well starting Fx happens all the time due to updates

[07:27:50.0000] <annevk>
wanderview: restarting*

[07:28:10.0000] <wanderview>
annevk: yea, just saying I had to explicitly quit firefox and restart to get some icon updates... but only on my mac

[07:28:26.0000] <beverloo>
annevk: cool, thanks! I also notice that we have [Exposed=(Window,Worker)] on our ServiceWorkerGlobalScope extensions, lol, that needs to go

[07:28:54.0000] <annevk>
beverloo: if you really want to drive it home file an issue against heycam/webidl to get a statement on the matter, it seems like something we need to decide on although it might be hard to find enough people who care

[07:29:13.0000] <annevk>
beverloo: yeah that seems buggy 😃

[07:29:21.0000] <beverloo>
sure, will do!

[07:30:08.0000] <annevk>
wanderview: oh that's different from restart to update?

[07:36:55.0000] <wanderview>
I guess?  I don't know much about mac integration stuff

[07:42:17.0000] <wanderview>
annevk: I guess I would settle for another icon update for this: https://twitter.com/mart3ll/status/899637173682622468

[08:09:54.0000] <wanderview>
I should really avoid commenting on spec issues while I'm still drinking coffee...

[09:32:21.0000] <tobie>
^ me at least three times a week.

[09:32:43.0000] <tobie>
Am I the only one finding the phrase "the construct is not available only in secure contexts" hard to parse?

[09:45:02.0000] <tobie>
beverloo, annevk : would the [SecureContext] / [Exposed] issue  still be a thing if we flipped [SecuredContext] around to [AllowInNonSecureContext]?

[09:45:44.0000] <beverloo>
tobie: I think that'd more accurately reflect our intentions of pushing https, but there's a whole bunch of legacy specs that we'd never be able to update..

[09:46:09.0000] <beverloo>
the vast majority of things has no reason to be secure context only, too

[09:46:46.0000] <tobie>
beverloo: that's a good point.

[09:48:21.0000] <annevk>
Anything that can be should imo

[09:48:43.0000] <annevk>
HTTPS carrots ftw

[09:49:03.0000] <annevk>
Or sticks, depending on your pov

[09:49:38.0000] <tobie>
beverloo: I guess the question wrt to those APIs you mentioned is whether they'd need to be secured if they were suddenly exposed in an new global interface that wasn't https by default.

[09:51:57.0000] <beverloo>
tobie: unlikely as that may be (why would we introduce new non-secure context-only globals at this point?), it's a good point as it may impact a lot of assumptions

[09:54:48.0000] <annevk>
I wonder if all worklets are [SecureContext], I hope so...

[09:57:05.0000] <tobie>
annevk: https://github.com/w3c/css-houdini-drafts/issues/92 "this seems overdue"

[09:58:16.0000] <beverloo>
from the PR (#379): ""Specifications which use worklets should decide if their worklet(s) should be allowed outside SecureContexts""

[10:03:29.0000] <tobie>
beverloo: so the thing is we can't add a clause that says that if something is exposed in a SW, then it must be secure context only elsewhere.

[10:05:24.0000] <tobie>
beverloo: (as it would make secure context only in Window, stuff you would add to SW)

[10:06:46.0000] <tobie>
beverloo: so your options are basically (1) mark all Exposed=SW APIs also as [SecureContext] (2) mark only the ones that do represent as security concerns as [SecureContext] (3) consider these APIs won't ever be exposed elsewhere and not do anything.

[10:07:35.0000] <tobie>
beverloo: I think (1) is probably the cheapest and most forward-looking thing to do.

[10:11:51.0000] <tobie>
beverloo: I'm having the hardest time parsing my own comments above. Sorry about that.

[10:16:40.0000] <tobie>
beverloo: so without considering the unlikely case that we introduce a new non-secure context, you might have the case where you start adding an API to SW and then want to move it to workers or window. For example, I think that's what happened with fetch, caches, etc.

[10:19:46.0000] <tobie>
beverloo: unless you've added a [SecureContext] extended attribute to such APIs, you have to remember doing a privacy/security assessment when you expose those elsewhere.

[10:30:26.0000] <beverloo>
tobie: I agree with (1), too

[10:30:53.0000] <beverloo>
looks like we found enough arguments to warrant being explicit, even though it's repetitive (and hopefully will be even more repetitive in the future)

[10:31:31.0000] <tobie>
yeah, I guess the other option is to switch the extended attribute around

[10:31:51.0000] <tobie>
Note we have a plan to do that for Exposed. We could do both at the same time

[10:32:48.0000] <tobie>
beverloo: see: https://github.com/heycam/webidl/issues/365

[10:35:38.0000] <beverloo>
Ack, sounds good to me. I like making [Exposed] mandatory, we've had some bugs in the past where interfaces accidentally were not exposed on all global scopes they should've been

[13:52:30.0000] <TabAtkins>
annevk, Domenic: For MultiMaps, a non-existent key should still return undefined from getAll(), right? Same as .get()?  (Rather than returning `[]`.)


2017-08-22
[19:23:01.0000] <Domenic>
TabAtkins: yes, in theory, but unfortunately annevk's multimaps went with null, and he says it's probably too late to change

[19:23:44.0000] <TabAtkins>
Null, seriously? When Maps return undefined?

[19:23:54.0000] <Domenic>
Yes.

[19:23:58.0000] <Domenic>
Although belay my above

[19:24:04.0000] <Domenic>
Apparently they return []

[19:24:11.0000] <Domenic>
Which seems pretty good now that I think about it

[19:24:13.0000] <TabAtkins>
Okay.

[19:24:23.0000] <Domenic>
Less null/undefined-testing

[19:24:24.0000] <TabAtkins>
Yeah, I could lean either way

[19:24:53.0000] <TabAtkins>
If you're expecting to get an array of stuff, getting an empty one is usually what you want I think.

[19:25:14.0000] <TabAtkins>
Better if js had falsey empty arrays, but eh.

[19:29:13.0000] <TabAtkins>
Domenic: .get() returns undefined tho?

[19:29:31.0000] <TabAtkins>
If it returns null I'm not matching that.

[19:29:39.0000] <Domenic>
TabAtkins: that'd be good, to be consistent with JS, although it's not what Headers and URLSearchParams due, very sadly.

[19:30:09.0000] <Domenic>
Looks like maplike also does undefined for get()

[19:30:22.0000] <TabAtkins>
I'll just write those off as legacy mistakes, yeah.

[01:00:48.0000] <tobie>
"Better if js had falsey empty arrays, but eh." O_O

[01:15:03.0000] <nox>
tobie: Not as good as falsey midnight though!

[01:16:30.0000] <tobie>
nox: wow. Did not know that was a thing.

[01:16:55.0000] <nox>
tobie: In Python it is.

[01:17:09.0000] <tobie>
nox: yeah--googled it.

[01:17:20.0000] <nox>
tobie: Why did you inflict this upon yourself!

[01:17:31.0000] <nox>
Some things are better left unknown.

[01:18:43.0000] <annevk>
JakeA: patches for https://bugzilla.mozilla.org/show_bug.cgi?id=1378342 are coming in atm

[01:18:52.0000] <annevk>
[insert it's happening gif]

[01:21:07.0000] <JakeA>
yay!!

[03:14:27.0000] <annevk>
tobie: I lost your train of thought in https://github.com/heycam/webidl/issues/365

[03:14:45.0000] <annevk>
tobie: I'd like that issue to be focused on removing the need for PrimaryGlobal

[03:14:51.0000] <annevk>
tobie: by adding Exposed= everywhere

[03:15:02.0000] <annevk>
tobie: and just that as that's a big enough task

[03:15:10.0000] <tobie>
OK, see, that's the part I was missing.

[03:15:16.0000] <annevk>
tobie: I don't want to couple it with secure context changes

[03:15:58.0000] <tobie>
I'm just going to edit the comments to makes things less confusing to others.

[03:16:01.0000] <annevk>
tobie: and I guess I was wondering if we have enough consensus so that I could start doing some things in that direction

[03:16:05.0000] <annevk>
ta

[03:20:36.0000] <tobie>
annevk: we might have had this discussion already, but I'm not sure how making [Exposed] mandatory allows us to remove [PrimaryGlobal].

[03:21:09.0000] <annevk>
tobie: PrimaryGlobal is a fallback

[03:21:19.0000] <annevk>
tobie: if you haven't declared a global, you'll be exposed on PrimaryGlobal

[03:21:32.0000] <annevk>
tobie: if everything declares a global, there's no need for a fallback

[03:21:39.0000] <tobie>
annevk: oh. So all PrimaryGlobal -> Global

[03:22:14.0000] <tobie>
"all"

[03:22:20.0000] <annevk>
tobie: [PrimaryGlobal] is a marker on the Window object and IDL uses that as marker as a fallback for when an interface lacks Exposed

[03:22:41.0000] <annevk>
tobie: that this is still causing confusion is even more reason to get rid of it

[03:22:42.0000] <tobie>
We had this discussion already.

[03:22:46.0000] <annevk>
yeah

[03:23:08.0000] <annevk>
But it's easy enough to explain

[03:23:13.0000] <tobie>
Indeed.

[03:27:51.0000] <tobie>
annevk: Alright. Updated the issue with the above so I don't ask about it again in n months.

[03:28:48.0000] <tobie>
annevk: churn wise, it does seem however that inverting [SecureContext] at the same time would make sense.

[03:35:21.0000] <tobie>
annevk: wrt your initial question, who should we gather consensus from to proceed with this?

[03:39:21.0000] <Ms2ger>
I'm in favour

[04:12:29.0000] <annevk>
tobie: I think I'm just going ahead and make it happen

[05:55:57.0000] <tobie>
annevk: might be wrong, but I think the warning belongs at the BS/ReSpec layer rather than at the parser level.

[05:57:06.0000] <annevk>
tobie: well this is basically saying you can't write interface without Exposed so I don't really see how it's not a parser concern

[05:58:10.0000] <tobie>
annevk: Because it's described in prose, not as part of the grammar.

[05:58:28.0000] <tobie>
annevk: also it's ES-binding specific.

[06:01:41.0000] <Ms2ger>
Not sure I agree with that

[06:01:53.0000] <tobie>
Ms2ger: with what?

[06:02:04.0000] <Ms2ger>
That Exposed is ES-specific

[06:02:45.0000] <annevk>
Yeah, seems that would apply to Wasm and such too

[06:02:46.0000] <Ms2ger>
OTOH, all of WebIDL is de facto ES-specific, so it doesn't really matter :)

[06:02:47.0000] <tobie>
Ms2ger: "This section defines a number of extended attributes whose presence affects only the ECMAScript binding."

[06:02:58.0000] <annevk>
That's probably wrong

[06:03:19.0000] <tobie>
Well, we can't really find out, can we?

[06:03:24.0000] <tobie>
:D

[06:07:30.0000] <tobie>
Anyway, for our specific concerns, here, I'm not sure how this is implemented in BS, but in ReSpec and idlharness, this would need to happen at above the parser level (as the code is designed to handle parser errors, but not warnings).

[06:11:14.0000] <annevk>
tobie: do you have the ability to warn there in a way that gets folks to fix things?

[06:14:40.0000] <tobie>
annevk: well, it's an extra check to add to do on the AST, but in practice that should be a lot easier than adding such logic to the parser (which isn't designed to check things like that).

[06:15:51.0000] <annevk>
Okay, I don't really care how it gets done, just needs to be done

[06:25:30.0000] <tobie>
annevk: agreed. It just has a higher prob of getting done if the issue is on the right repository. ;)

[06:26:27.0000] <annevk>
plinss seems pretty good at closing issues so we'll find out soon enough

[07:26:53.0000] <annevk>
quarter-millimeters

[07:26:59.0000] <annevk>
I wonder what the use case for that was

[07:31:10.0000] <annevk>
ah okay, common in Japanese typesetting

[09:43:30.0000] <gsnedders>
if you have multiple event listeners on an event, is event dispatcher order defined?

[09:43:34.0000] <gsnedders>
*dispatched

[09:43:38.0000] <gsnedders>
*dispatch

[09:51:44.0000] <jyasskin>
gsnedders: i.e. you called addEventListener() multiple times?

[09:51:56.0000] <gsnedders>
jyasskin: yeah

[09:52:13.0000] <jyasskin>
The order of addEventListener() calls determines the order the listeners are called.

[09:52:36.0000] <gsnedders>
/me wonders why his Google-foo couldn't find a clear statement saying that :)

[09:52:40.0000] <gsnedders>
jyasskin: thx!

[09:55:11.0000] <jyasskin>
gsnedders: https://dom.spec.whatwg.org/#concept-event-listener-invoke is probably a good place to start if you want to trace exactly how it's defined.

[09:56:48.0000] <gsnedders>
jyasskin: "for each event listener associdated with object" isn't that explicit about iteration order

[09:57:38.0000] <gsnedders>
also I've basically given up on the DOM spec when it comes to understanding events, given https://github.com/whatwg/dom/issues/474 makes it hard to understand stuff :\

[09:57:55.0000] <jyasskin>
It'd be nice to be a bit clearer about that, but https://infra.spec.whatwg.org/#list-iterate says to go in order, and elements are added with https://infra.spec.whatwg.org/#list-append.

[09:59:45.0000] <gsnedders>
right, the list side is clear

[10:01:13.0000] <gsnedders>
it's not clear to me what the type of the association is

[10:02:20.0000] <jyasskin>
gsnedders: Ah, that looks like a bug: "For each event listener associated with object" should be "For each |listener| in the list of event listeners associated with object", since https://dom.spec.whatwg.org/#interface-eventtarget is clear that the EventTarget has a *list* of associated listeners, not just a pile.

[10:02:44.0000] <gsnedders>
jyasskin: right, and that would be unambiguous

[10:36:51.0000] <annevk>
If only we had formalized slots long ago this kind of stuff would have been patterned and addressed

[10:38:02.0000] <annevk>
I also hope that nobody tries to copy the Event specification text since it's full of badness

[10:38:14.0000] <annevk>
In particular around slots

[10:38:29.0000] <jyasskin>
The best time to [fix spec infrastructure] is 20 years ago. ;)

[10:38:35.0000] <annevk>
/me wonders if slots are still on tobie's radar

[10:39:12.0000] <annevk>
jyasskin: I like to stay optimistic and hope we're still at the start of it all

[10:39:34.0000] <jyasskin>
That's the second half of the quote: "The second-best time is now." :)

[10:39:51.0000] <annevk>
heh

[10:45:37.0000] <nox>
They should just be rewritten in Rust.

[10:46:06.0000] <gsnedders>
can we not rewrite them in something where we can more easily to formal analysis?

[10:46:27.0000] <nox>
gsnedders: I wasn't being serious. :p

[10:48:50.0000] <gsnedders>
nox: I was only being somewhat serious. :P

[10:49:08.0000] <nox>
gsnedders: Too late. Rewrite all specs in Coq, you have two hours.

[10:49:26.0000] <gsnedders>
nox: Coq? You are so French. ;P

[10:49:45.0000] <nox>
🥖🥖

[10:50:54.0000] <jyasskin>
The glue code for specs should be something with a formal definition, but after thinking about the purpose of specs for a while, I've concluded that there are some bits in the core where we specifically have to avoid being too formal, either because we want to let implementations innovate (e.g. all the UI parts: how do you formalize "ask the user for permission"?) or because we're referring to other specifications

[10:50:54.0000] <jyasskin>
that use different styles.

[10:51:57.0000] <nox>
jyasskin: Just wait two hours and all of them will be specified by gsnedders!

[10:52:02.0000] <nox>
formally*

[10:52:07.0000] <jyasskin>
/me holds breath

[10:52:29.0000] <gsnedders>
nox: unforuntately, I've already proven it impossible to formalise the HTML parser in Coq

[10:52:56.0000] <gsnedders>
(okay, a bit hand-wavey argument, but I did do this in my bachelor's thesis)

[10:53:22.0000] <nox>
gsnedders: Why?

[10:53:52.0000] <nox>
Formalise, or implement?

[10:55:32.0000] <nox>
Apart from the elephant in the room that is JS, I mean. :P

[11:06:43.0000] <gsnedders>
nox: the elephant in the room is the fact that HTML defines how to parse infinitely long documents, and Coq requires termination

[11:07:00.0000] <nox>
gsnedders: That's for implementation.

[11:07:06.0000] <nox>
gsnedders: You can still formalise it.

[11:07:43.0000] <gsnedders>
nox: yeah, ok

[11:08:11.0000] <nox>
Otherwise AFAIU CompCert wouldn't be a thing.

[11:08:56.0000] <nox>
Or https://www.microsoft.com/en-us/research/wp-content/uploads/2016/12/coqasm.pdf which is pretty cute. That being said, I've never did a thesis or whatsoever and I only know Coq superficially.

[11:09:10.0000] <gsnedders>
IIRC there were some limitations on stuff which doesn't terminate

[11:09:29.0000] <gsnedders>
but it's been years since I've touched Coq at all, and even that was only a bit superficial

[11:11:22.0000] <gsnedders>
OK, so you can do nontermination provided you explicitly state where it is and prove each iteration is well-typed

[11:11:27.0000] <tobie>
annevk: I want to tackle mixins first.

[11:28:47.0000] <nox>
gsnedders: The naive young me wanted to formalise the semantics of the Erlang VM, then I quickly realised I didn't have the skills.

[11:29:03.0000] <nox>
The naive less young but still young me thinks maybe in a decade he will be able to do that.

[11:36:18.0000] <gsnedders>
nox: you have me looking at stuff around Coq for the first time in years; I just about knew enough maths a few years ago to do some basic stuff, now I don't

[11:36:36.0000] <nox>
gsnedders: Eh eh.

[12:57:01.0000] <nox>
gsnedders: It's been 10 minutes and you've yet to give me the formalised specs in Coq.

[14:26:11.0000] <tobie>
If we remove [PrimaryGlobal], where do we define the primary global interface?

[14:35:22.0000] <Domenic>
I think the idea is that there is no longer a concept of primary global interface

[14:35:33.0000] <Domenic>
Since IIUC it's only used to determine the exposure set when there's no [Exposed]

[14:47:11.0000] <tobie>
Domenic: well, at least LegacyWindowAlias relies on that concept.

[14:47:31.0000] <Domenic>
lol, I thought it'd hard-code Window, per the name.

[14:47:40.0000] <tobie>
Domenic: I can replace it by Window instead.

[14:48:25.0000] <Domenic>
I'd kind of rather leave this to annevk since he's excited about it; I think mixins would be more impactful right now.

[14:49:51.0000] <tobie>
Domenic: Well, I'm half-way through the PR at this point, so…

[14:50:10.0000] <tobie>
But yeah, agreed wrt to mixins

[14:50:32.0000] <Domenic>
Mmm, OK'


2017-08-23
[23:56:32.0000] <Ms2ger>
Hixie's really made it now: https://twitter.com/CodeWisdom/status/898664302726356992

[02:20:17.0000] <TimothyGu>
annevk: what do you mean by obj.trailer != obj.trailer? obj.trailer is a promise that AFAICT isn't changed?

[02:22:56.0000] <annevk>
TimothyGu: hmm I was thinking of an IDL exception which would always be wrapped in a new promise

[02:23:21.0000] <annevk>
TimothyGu: I guess this might be slightly different

[02:23:47.0000] <TimothyGu>
yeah IIRC it just rejects an existing promise, doesn't create a new one

[02:23:58.0000] <annevk>
TimothyGu: still not a big fan of making it reject though, we don't even do that for network errors atm

[02:24:29.0000] <annevk>
TimothyGu: it's not like we make accessing obj.headers throw

[02:24:46.0000] <annevk>
that's prolly the better rationale, JakeA ^^

[02:30:07.0000] <JakeA>
annevk: hmm. We don't really return network error responses, but if headers works there I guess it makes sense. Although isn't it weird not being able to tell the difference between aborted response and no trailers?

[02:30:46.0000] <annevk>
JakeA: I think that is a bit weird

[02:31:09.0000] <annevk>
JakeA: okay, maybe we should just keep this as-is

[02:31:28.0000] <annevk>
JakeA: not a big fan of it, but adding response.aborted or some such also seems weird

[02:33:20.0000] <JakeA>
annevk: shall I try and fix up the trailer and response constructor stuff as part of the same PR?

[02:34:10.0000] <TimothyGu>
JakeA: would be good to add a [SameObject] to trailers, if you decide to work on the current PR a bit more

[02:35:23.0000] <JakeA>
TimothyGu: yeah, makes sense

[02:35:31.0000] <TimothyGu>
oh wait, https://github.com/heycam/webidl/issues/71... sigh never mind

[02:36:25.0000] <JakeA>
Hm

[02:37:58.0000] <annevk>
JakeA: what is wrong wit hthe trailer and response constructor? I might have missed something

[02:38:13.0000] <annevk>
TimothyGu: I think I explicitly removed [SameObject] at some point due to it being incompatible with promises

[02:39:47.0000] <JakeA>
annevk: https://fetch.spec.whatwg.org/#response-class always resolves the trailer promise with an empty set of headers

[02:40:12.0000] <JakeA>
So it can't later be resolved with the actual trailer headers

[02:41:41.0000] <JakeA>
annevk: oh, maybe I'm wrong, because the Response constructor isn't invoked

[02:41:54.0000] <JakeA>
It just creates a new Response object

[02:42:03.0000] <JakeA>
Sorry, my bad

[02:42:38.0000] <annevk>
TimothyGu: maybe you're up for reviewing the full changeset with Domenic being away?

[02:42:53.0000] <annevk>
TimothyGu: if you still have that free time that is

[02:43:03.0000] <JakeA>
Ah, you just posted that on the issue

[02:43:35.0000] <TimothyGu>
yeah I do, though I'm not sure I have the expertise to review properly. I'll try though.

[02:44:01.0000] <TimothyGu>
annevk: the language is "resolve the trailer promise" not "set the trailer promise to..." so I think it's still the same

[02:46:01.0000] <annevk>
https://github.com/heycam/webidl/pull/217 is why promise getters cannot use SameObject btw

[02:51:27.0000] <annevk>
JakeA: I guess what I meant is that if you have a late network error (something closes the connection) trailer will just be empty

[02:51:33.0000] <annevk>
JakeA: maybe that's okay though

[03:22:32.0000] <JakeA>
annevk: I don't have a strong opinion, but returning an empty set of headers on abort seems weird. Resolving with undefined is another option, but that's not what fetch() does in light of abort/failure

[03:24:34.0000] <annevk>
JakeA: that's fair, but it's also weird that early connection close does result in an empty set

[03:25:16.0000] <JakeA>
annevk: maybe networkError.headers should be null?

[03:25:31.0000] <JakeA>
or undefined. I'm never sure when we use one or the other

[03:28:08.0000] <annevk>
JakeA: sorry, networkError.headers doesn't matter as you said, I'm talking about response.trailer when there's an early connection close

[03:29:31.0000] <JakeA>
annevk: We error the stream in this case, so shouldn't we reject trailers with the same/similar error?

[03:30:22.0000] <annevk>
JakeA: yeah, I think that might make sense

[03:30:24.0000] <JakeA>
If response.text() rejects, but response.trailers fulfills, it's a little asymmetric

[03:31:18.0000] <JakeA>
But I take your point that's it'd be weird having a property throw (in a sync world), but I guess this is an async-only problem

[05:02:26.0000] <tobie>
annevk: do callback interfaces need  [Exposed=Window] to?

[05:03:10.0000] <tobie>
annevk: or is that just relevant for those that have constants?

[05:03:49.0000] <annevk>
tobie: dunno, tbh I was looking at IDL yesterday and was surprised by dictionaries having them

[05:03:57.0000] <annevk>
tobie: and apparently dictionaries can have constructors

[05:04:09.0000] <annevk>
tobie: I forgot about all that and I'm not totally sure I like it

[05:04:23.0000] <tobie>
what?

[05:05:05.0000] <annevk>
tobie: it seems that self.EventListener returns undefined so I guess only those with constants really need it

[05:05:38.0000] <annevk>
tobie: [Exposed] is a thing you can use on dictionaries (hopefully only required when it has a constructor, I didn't investigate)

[05:08:10.0000] <tobie>
So [Exposed] and [Constructor] don't apply to dictionaries (phew!)

[05:08:19.0000] <tobie>
annevk: ^

[05:11:24.0000] <annevk>
tobie: "The following extended attributes are applicable to dictionaries: [Constructor], [Exposed], [SecureContext],"

[05:11:41.0000] <annevk>
tobie: might wanna fix that then

[05:14:13.0000] <tobie>
annevk: weird. That doesn't seem to match the description of either extended attributes, nor (hopefully) actuals specs.

[05:15:50.0000] <tobie>
Same for SecureContext, really. What does it do to a dictionary?

[05:25:18.0000] <annevk>
I vaguely recall dictionaries having constructors somewhere

[05:25:26.0000] <annevk>
I don't know why that was done or how it works though

[05:27:15.0000] <tobie>
that's not defined anywhere

[05:34:18.0000] <annevk>
Maybe it got removed again? I'm pretty sure it was discussed

[05:41:34.0000] <Ms2ger>
Was that for DOMPoint?

[05:43:04.0000] <annevk>
Ms2ger: maybe

[05:48:26.0000] <annevk>
Ms2ger: https://lists.w3.org/Archives/Public/public-script-coord/2014JulSep/0032.html indeed maybe

[05:48:38.0000] <annevk>
Ms2ger: still unclear and not going to dig further for now

[05:49:46.0000] <annevk>
I'll file an issue on that sentence anyway

[06:02:32.0000] <tobie>
annevk: ty

[06:02:46.0000] <annevk>
JakeA: thoughts on TimothyGu's comment in the PR?

[06:03:23.0000] <tobie>
annevk: do global interfaces also need to have an [=Exposed=] ext attr?

[06:03:24.0000] <annevk>
JakeA: I'm happy to merge at this point; just need an updated commit title/body with links to tests and such

[06:03:35.0000] <annevk>
tobie: yeah

[06:03:40.0000] <tobie>
annevk: ta

[06:03:42.0000] <annevk>
tobie: and [Global]

[06:04:32.0000] <annevk>
tobie: I was thinking they could maybe omit Exposed, but that does not work for [Global=(Worker,DedicatedWorker), Exposed=DedicatedWorker] and such (it would end up too widely exposed)

[06:05:02.0000] <annevk>
tobie: and to create a special rule if Global only lists one value seems like too much magic

[06:05:33.0000] <tobie>
annevk: agreed it seems easier and less error-prone to be explicit all the time.

[06:14:51.0000] <wanderview>
does anyone know the current status of "html modules"?  es module semantics for loading html documents... I thought someone was working on a proposal for it

[06:23:20.0000] <annevk>
wanderview: https://github.com/w3c/webcomponents/issues/645 there's not much of a proposal thus far

[06:23:28.0000] <annevk>
wanderview: but there's some convergence on ideas it seems

[06:24:37.0000] <wanderview>
annevk: thanks

[06:25:49.0000] <wanderview>
annevk: ah, this was the last thing I had seen: https://github.com/dglazkov/webcomponents/blob/html-modules/proposals/HTML-Imports-and-ES-Modules.md

[06:26:23.0000] <annevk>
wanderview: that's pretty dated compared to that thread I'd say

[06:26:43.0000] <wanderview>
yea, just saying thats how old my info was before asking here

[06:33:53.0000] <annevk>
wanderview: I guess you'll be at TPAC?

[06:34:01.0000] <wanderview>
annevk: yes

[06:34:04.0000] <annevk>
wanderview: interested in also doing this?

[06:34:09.0000] <annevk>
/me isn't going

[06:34:43.0000] <wanderview>
annevk: I would sit in the meeting, but not sure I am very knowledgeable or on the same page as other folks at mozilla

[06:36:11.0000] <annevk>
wanderview: I don't think we really have a position per se, other than trying to work with library developers (including the non-Google ones)

[06:37:07.0000] <annevk>
wanderview: thus far our position has mostly been that we'd like to see <script type=module> roll out first and then see experimentation by libraries

[06:37:21.0000] <annevk>
wanderview: which hasn't really happened yet...

[06:37:47.0000] <wanderview>
yea

[07:39:52.0000] <zcorpan>
hmm, is Exposed needed even for NoInterfaceObject interfaces?

[07:40:03.0000] <zcorpan>
I thought first they were not allowed together

[07:46:32.0000] <tobie>
zcorpan: that'll be clearer once I include mixins

[07:47:39.0000] <tobie>
zcorpan: I think you want them to describe where they're exposed, as you can have a [NoInterfaceObject] that you want mixed-in in one global but not the other.

[07:47:42.0000] <annevk>
zcorpan: I think they are, but it should not be like that

[07:47:55.0000] <annevk>
hmm

[07:48:24.0000] <annevk>
tobie: I don't think that's a good model, since we don't assert which objects you can be mixed in with either

[07:49:25.0000] <annevk>
tobie: let me rephrase, I think it's good to allow, but I think by default it should inherit

[07:50:35.0000] <tobie>
annevk: OK, this is good stuff to get figured out.

[07:50:52.0000] <tobie>
annevk: (prior to adding mixins)

[07:51:59.0000] <tobie>
annevk: Do we have cases of mixins that choose where they're exposed?

[07:53:04.0000] <tobie>
annevk: or is it always the case that their exposition is decided by the interfaces which implement them?

[07:53:26.0000] <annevk>
tobie: mostly the latter, cannot think of cases for the former

[07:53:39.0000] <annevk>
tobie: note that the former can always be done by just putting [Exposed] on the member itself

[07:53:54.0000] <annevk>
tobie: as e.g. XHR does for responseXML (not a mixin, but same deal)

[07:54:01.0000] <tobie>
annevk: oh, right.

[07:54:26.0000] <annevk>
Navigator might have had more of that if it were designed in a time where we had [Exposed]

[07:54:33.0000] <annevk>
But now we have Navigator and WorkerNavigator

[07:54:44.0000] <annevk>
which is rather silly

[07:56:27.0000] <tobie>
annevk: so it optional if you have [NoInterfaceObject], but it's there, it must be a subset of what it gets implemented in.

[07:57:31.0000] <tobie>
annevk: let me rephrase that

[07:59:10.0000] <tobie>
annevk: so [Exposed] is optional if you have [NoInterfaceObject]. If it's nonetheless specified, then the exposed set must be a subset of what the exposed set of the interface it gets mixed-in to.

[08:02:07.0000] <annevk>
tobie: a subset of the union of the exposed sets of the interfaces it gets mixed into

[08:02:18.0000] <annevk>
tobie: I'd think

[08:03:01.0000] <annevk>
tobie: if you want to add something to Navigator and WorkerNavigator, but exclude the ServiceWorker global, for instance

[08:10:04.0000] <tobie>
annevk: the union or the intersection?

[08:10:51.0000] <annevk>
tobie: latter I guess

[08:11:17.0000] <annevk>
tobie: I think I continue to be confused by the word union when it comes to set theory

[08:11:34.0000] <annevk>
maybe back later, maybe tomorrow; good day all

[08:11:44.0000] <tobie>
have a nice evening

[08:14:21.0000] <zcorpan>
I didn't include Exposed for NoInterfaceObject interfaces in csswg-drafts, but can fix if they should have it

[08:30:30.0000] <Ms2ger>
I think you should

[12:32:34.0000] <tobie>
Relaxed the requirements for NoInterfaceObject

[12:34:08.0000] <zcorpan>
meanwhile I added Exposed in csswg-drafts :-P

[12:48:59.0000] <tobie>
I saw.

[12:49:05.0000] <tobie>
:)

[13:18:21.0000] <dmarr>
how does fetch know what credentials to send when the credentials: 'include' option is set?

[13:18:23.0000] <dmarr>
i am returning a 401 with WWW-Authenticate header from my api, and i want to basically have a client page that can send in the creds manually

[16:44:56.0000] <TabAtkins>
Domenic: I think I've hit my limit of obvious perf hacks for the moment, but the last few days of work have knocked off 15-20% of DOM's processing time, so yay! (And a bunch was changes that benefit short specs, too.)


2017-08-24
[17:35:58.0000] <MikeSmith>
dmarr: fetch just sends back whatever cookies are set for that domain, right?

[17:37:20.0000] <dmarr>
MikeSmith: I think so. I have a call to my api which challenges the user with the Basic Auth creds, and then subsequent requests send in the Authentication request header. I'm trying to understand the hooks there

[18:35:11.0000] <MikeSmith>
dmarr: to be clear, you know credentials: 'include' doesn’t affect the sending of the Authentication header?

[18:35:34.0000] <MikeSmith>
and I guess you probably mean Authorization header?

[18:36:00.0000] <MikeSmith>
anyway, I wonder what actual error you’re running into

[18:36:22.0000] <MikeSmith>
is the server not receiving cookies that you think it should be?

[20:18:34.0000] <MikeSmith>
https://webkit.org/blog/7877/release-notes-for-safari-technology-preview-38/

[20:18:43.0000] <MikeSmith>
> Enabled Payment Requests as an experimental feature

[20:19:57.0000] <MikeSmith>
nice

[20:20:13.0000] <MikeSmith>
... though I guess it might cause people to get their hopes up a little bit higher than intended

[20:21:08.0000] <MikeSmith>
since so far what they landed seems to be literally just the experimental-feature flag for it, but not the actual API

[20:21:18.0000] <MikeSmith>
anyway, progress

[20:51:58.0000] <TimothyGu>
anyone got thoughts on https://github.com/nodejs/node/issues/14994? basically, a user wants to go to a domain with xn--a--a in it, but some Node.js internal issue caused a replacement character to be added because that domain isn't valid Punycode.

[20:53:51.0000] <TimothyGu>
after https://github.com/whatwg/url/pull/309#issuecomment-301414556 the URL Standard decided to call ToASCII on all domains (including pure ASCII ones), and throw on invalid Punycode-encoded URLs, but I'm not sure if that's the best solution here, as the user (fairly) assumed pure ASCII input would not get transformed in any way

[20:54:29.0000] <TimothyGu>
annevk: ^^

[23:45:12.0000] <annevk>
TimothyGu: why would the user assume that?

[23:45:59.0000] <TimothyGu>
well, the name "ToASCII" kind of means "transform a domain to ASCII"

[23:46:35.0000] <annevk>
TimothyGu: ToASCII is an implementation detail of IDNA

[23:46:42.0000] <annevk>
TimothyGu: not exposed to users

[23:47:15.0000] <annevk>
TimothyGu: anyway, the xn--a--a is an interesting case, this is an internal domain that works, maybe even on some browsers?

[23:47:31.0000] <TimothyGu>
Chrome at least doesn't throw an error

[23:47:42.0000] <annevk>
TimothyGu: Fx probably doesn't either

[23:48:11.0000] <annevk>
TimothyGu: so even with ignore hyphens we still hit compat issues because of these rather weird domain names

[23:48:12.0000] <TimothyGu>
yeah

[23:48:13.0000] <annevk>
sigh

[23:48:32.0000] <annevk>
And Node gets bitten because browsers haven't fixed stuff yet

[23:49:15.0000] <annevk>
The idea behind applying ToASCII to ASCII input is that the a-z character set shouldn't get special treatment over other character sets

[23:50:04.0000] <annevk>
However, actual compat issues probably might trump that, depending on severity and willingness of browsers to do the right thing anyway

[23:58:20.0000] <TimothyGu>
annevk: would you mind explaining that in the issue?

[00:03:11.0000] <annevk>
TimothyGu: the node one? I guess I can in a bit

[00:03:20.0000] <TimothyGu>
yeah

[00:11:15.0000] <annevk>
done

[00:24:44.0000] <TimothyGu>
thanks!

[00:48:46.0000] <tobie>
TimothyGu: sorry for the back and forth on that small PR of yours. I can fix myself before merging if you prefer.

[00:49:25.0000] <TimothyGu>
tobie: sure, go ahead!

[00:52:37.0000] <tobie>
zcorpan: well, making [Exposed] explicit certainly has some benefits given https://github.com/w3c/css-houdini-drafts/pull/464!

[01:30:57.0000] <zcorpan>
FYI https://wiki.whatwg.org/index.php?title=What_you_can_do&diff=10184&oldid=10178

[04:53:48.0000] <xfq>
zcorpan: the [GitHub repositories] link doesn't work

[04:53:50.0000] <xfq>
(since it's Wikitext, instead of Markdown)

[04:54:14.0000] <zcorpan>
xfq: thanks. danged wikitext

[06:20:51.0000] <annevk>
GPHemsley: you around? We're moving a bunch of stuff away from DreamHost and were wondering if you could help with the wiki

[06:21:07.0000] <annevk>
GPHemsley: if you can, foolip can give you server access and such

[07:07:51.0000] <wanderview>
annevk: about the integrity bug where you said "its reasonable to not do anything"... you mean don't throw a TypeError and then check the integrity?  Or ignore the integrity check then?

[07:15:36.0000] <wanderview>
annevk: I went ahead and filed a spec issue: https://github.com/whatwg/fetch/issues/583

[07:32:19.0000] <annevk>
wanderview: sorry for being vague :/ I meant not throwing

[07:47:56.0000] <wanderview>
annevk: I think the spec is good about ignoring the integrity value on opaque responses... but we don't have a check for it on implementation side

[07:48:07.0000] <wanderview>
so I think we could probably just do that

[07:49:34.0000] <annevk>
wanderview: it doesn't ignore it

[07:49:39.0000] <annevk>
wanderview: it results in a network error

[07:49:43.0000] <wanderview>
annevk: the SRI spec does\

[07:49:54.0000] <annevk>
wanderview: hmm

[07:50:40.0000] <wanderview>
annevk: are you saying fetch throws network error because it looks at the body instead of unfiltered body?  and the opaque body is filtered to be empty?

[07:50:52.0000] <wanderview>
I guess it has a note to that effect

[07:51:08.0000] <annevk>
wanderview: "If ... response does not match request’s integrity metadata, set response and internalResponse to a network error"

[07:51:22.0000] <annevk>
wanderview: it doesn't match for an opaque response

[07:51:30.0000] <annevk>
wanderview: match is https://w3c.github.io/webappsec-subresource-integrity/#does-response-match-metadatalist

[07:51:37.0000] <wanderview>
annevk: the SRI spec has text suggesting if a <script integrity> results in a cross-origin no-cors, then integrity should be ignored

[07:51:50.0000] <annevk>
o_O

[07:52:26.0000] <wanderview>
oh, maybe I misunderstood that bit

[07:52:47.0000] <annevk>
That's not what I thought we had agreement on, but I haven't studied SRI in detail

[07:52:53.0000] <wanderview>
annevk: I think you are right

[07:52:54.0000] <annevk>
I thought it mostly deferred to Fetch at this point

[07:52:56.0000] <wanderview>
I misread it

[07:57:07.0000] <wanderview>
annevk: I wonder if it would be ok to reject immediately with network error when we go opaque and there is an integrity value... instead of computing hashes, etc

[07:57:24.0000] <wanderview>
or waiting for body to complete

[08:04:21.0000] <annevk>
wanderview: there'll be a timing difference but that should be okay

[08:05:13.0000] <annevk>
wanderview: maybe should be clarified though as currently it reads like it's not okay

[08:05:44.0000] <wanderview>
annevk: I think we will read to end and then evaluate against empty string

[08:06:03.0000] <wanderview>
annevk: also, I don't think there are any fetch integrity tests against no-cors

[08:06:39.0000] <wanderview>
AFAICT

[08:07:58.0000] <wanderview>
annevk: I'm going to see if tt has time to look at this... he wrote our fetch integrity support initially

[08:14:33.0000] <annevk>
wanderview: sounds good

[12:14:23.0000] <tantek>
saw this and wondered what folks here thought about the concept and general approach of a map/geo element to natively display a map on a page: https://shkspr.mobi/blog/2017/08/mapping-in-html-a-proposal-for-a-new-element/

[12:50:25.0000] <tobie>
tantek: why not offer as a custom element (at least as a first step)?

[12:51:06.0000] <tantek>
tobie, agreed!

[12:52:01.0000] <tantek>
might be an interesting / complex enough real world example to really exercise the capabilities of web components

[12:52:56.0000] <tobie>
TabAtkins: could bikeshed somehow allow templating the advisement here: https://heycam.github.io/webidl/#LegacyArrayClass, it's used  on a number of extended attributes.

[12:53:44.0000] <tobie>
tantek: yes, and there are high-level JS API requirements for navigation on top of it.

[13:18:17.0000] <tantek>
looks like the tweet thread links to a few custom element attempts https://twitter.com/edent/status/900677910998155265

[13:53:44.0000] <TabAtkins>
tobie: You can use a <pre class=include> element https://tabatkins.github.io/bikeshed/#including

[13:56:21.0000] <tobie>
TabAtkins: I can't have those inline, can I? (cake + eat it too)

[13:56:50.0000] <TabAtkins>
Hmm, not right now, but open an issue on me. I'd have to do something different for the macros, is all.

[13:57:12.0000] <tobie>
TabAtkins: as attributes?

[13:58:35.0000] <TabAtkins>
I'll figure it out.

[14:05:00.0000] <tobie>
TabAtkins: awesome. Thanks. https://github.com/tabatkins/bikeshed/issues/1078

[14:05:31.0000] <TabAtkins>
(Not gonna hit it immediately, I'm in the middle of making `bikeshed update` only download what's changed.)

[14:58:34.0000] <tobie>
TabAtkins: no hurry. (And as far as I'm concerned, https://github.com/tabatkins/bikeshed/issues/1077 is higher up in my list of priorities.)


2017-08-25
[01:23:20.0000] <annevk>
TimothyGu: gave you access to whatwg/html, should be an invite somewhere

[02:09:11.0000] <zcorpan>
https://github.com/whatwg/whatwg.org/issues/59 seems like something where we should ask for help from the community, if someone's willing to do a redesign

[02:27:22.0000] <annevk>
zcorpan: maybe time to email whatwg⊙wo again?

[02:29:12.0000] <zcorpan>
annevk: yeah, but maybe wait a few days, see if we get response from the tweet

[04:25:45.0000] <JakeA>
tobie: are there docs for your spec CI stuff? As in, the preview & diff links

[04:39:10.0000] <JakeA>
tobie: no worries, I've found it

[05:33:04.0000] <tobie>
JakeA: LMK if you have issues setting it up. It should just work out of the box.

[05:56:56.0000] <zcorpan>
TabAtkins: ping https://github.com/tabatkins/bikeshed/issues/964 :-)

[05:56:56.0000] <botie>
will do

[06:17:38.0000] <JakeA>
tobie: any way to get it to apply to existing PRs?

[06:18:16.0000] <tobie>
JakeA: I should *automate* that upon first setup.

[06:19:25.0000] <tobie>
JakeA: in the meantime, just editing the post ever slightly should be enough (e.g. extra line break)

[06:19:37.0000] <JakeA>
tobie: ta!

[06:19:41.0000] <tobie>
JakeA: LMK if it works

[06:21:46.0000] <JakeA>
tobie: It worked!

[06:21:54.0000] <tobie>
cool

[07:01:08.0000] <gsnedders>
addEventListener("foo", () => aEL("foo", () => undefined)) won't invoke both foo, but only the outter one, right? because it constructs a list of event listeners before it starts invoking any, right?

[07:11:03.0000] <annevk>
gsnedders: yeah, only remove is immediate

[08:46:39.0000] <wanderview>
I know people think wrapping lines shouldn't matter any more... but github PR's requiring horizontal scrolling are a lot harder to review

[08:48:05.0000] <tobie>
wanderview: use split view

[08:48:30.0000] <wanderview>
tobie: thanks, that does help

[08:53:11.0000] <wanderview>
I guess JakeA is reviewing it so I don't have to read the diff anyway

[08:54:19.0000] <JakeA>
wanderview: I use split view too. But did you see the preview/diff links in the top post?

[08:55:08.0000] <wanderview>
JakeA: no... and those are quite nice

[11:50:29.0000] <wanderview>
Domenic: JakeA: What spec does AbortController live in?

[11:50:47.0000] <wanderview>
I guess DOM

[11:53:17.0000] <wanderview>
JakeA: do we expect FetchObserver to be a thing or has it been axed?

[11:54:22.0000] <JakeA>
wanderview: yeah it's the DOM spec

[11:54:32.0000] <JakeA>
wanderview: I'm still interested in fetch observer

[11:54:49.0000] <wanderview>
ok, so it just hasn't landed in the spec yet?

[11:55:05.0000] <JakeA>
I want to get other stuff landed first, like abort & range requests

[11:55:12.0000] <wanderview>
k

[11:55:16.0000] <JakeA>
wanderview: yeah it's still just a sketch

[12:04:42.0000] <wanderview>
JakeA: is this the latest spec proposal for AbortSignal in fetch? https://fetch.spec.whatwg.org/branch-snapshots/cancelation/#requestinit

[12:05:12.0000] <wanderview>
JakeA: baku has a patch that makes RequestInit.signal `AbortSignal?` instead of `AbortSignal`... trying to determine if thats correct

[12:22:28.0000] <wanderview>
JakeA: can a Request have a null signal?

[12:23:06.0000] <wanderview>
oh, it says initial a new AbortSignal

[12:50:07.0000] <wanderview>
JakeA: I think we should probably add a WPT test that does a fetch() which is intercepted by a SW, then outer fetch() aborts and tests that the SW sees the abort on its signal

[15:25:13.0000] <JakeA>
wanderview: yeah, that makes sense


2017-08-26
[07:28:51.0000] <GPHemsley>
annevk, foolip: I'm here now

[07:29:32.0000] <GPHemsley>
I'm sure we're behind on updating the wiki as it is, so happy to help

[07:56:21.0000] <annevk>
GPHemsley: cool, I suspect foolip is only around on week days, but that might be impossible for you?

[07:56:59.0000] <annevk>
GPHemsley: I'll tell foolip Monday in any event and we can arrange it via email

[07:57:25.0000] <annevk>
GPHemsley: appreciate it

[08:19:54.0000] <GPHemsley>
annevk: Not impossible, just more unlikely. I can be here at a prearranged time during the week, if necessary... though I'm away beginning Thursday the 31st

[09:30:11.0000] <annevk>
GPHemsley: okay, let's do it via email, no need to make this complicated I think


2017-08-27
[19:15:59.0000] <tantek>
for annevk and w3cmemes: https://twitter.com/laneymg/status/901537082929143808

[22:00:50.0000] <KiChjang>
is it true that only input elements that are in the value mode can have value sanitization algorithms defined for it?

[23:17:43.0000] <foolip>
GPHemsley: here now? I can give you access to a fresh VM where you can do whatever you want

[23:43:17.0000] <foolip>
GPHemsley: I've sent you an email

[05:16:33.0000] <GPHemsley>
foolip: E-mail received. Logged in successfully. This is the most barebones setup I've ever experienced, I think. I had to install man!

[05:16:57.0000] <GPHemsley>
Now if only I could remember my password to the original wiki server...

[05:21:12.0000] <GPHemsley>
Ah, it seems I need to use the right username, too.


2017-08-28
[17:02:18.0000] <GPHemsley>
lists.whatwg.org is down

[17:49:11.0000] <MikeSmith>
GPHemsley: yeah it as been even since switching to TLS

[17:49:18.0000] <GPHemsley>
oh

[17:49:40.0000] <MikeSmith>
some Dreamhost borkenness prevents it from working

[00:20:07.0000] <annevk>
Domenic: say hi to mkwst

[00:20:08.0000] <botie>
will do

[00:20:13.0000] <annevk>
not you botie...

[00:24:23.0000] <zcorpan>
where's the source for botie?

[00:24:44.0000] <zcorpan>
seems like it's more annoying than helpful

[00:33:18.0000] <MikeSmith>
zcorpan: https://github.com/w3c/infobot

[00:45:18.0000] <zcorpan>
MikeSmith: either there's a bug with $addressed or it's set up wrong for this channel

[01:30:51.0000] <annevk>
foolip: you around?

[01:31:10.0000] <foolip>
annevk: yep

[01:31:28.0000] <annevk>
foolip: I was wondering if for https://github.com/whatwg/whatwg.org/pull/62 we could instead rebase and merge or some such

[01:31:46.0000] <annevk>
foolip: so all commits just follow the existing ones

[01:32:10.0000] <foolip>
annevk: I could filter-branch the whole old repo to make it look like it happened inside a subdirectory, sure

[01:32:22.0000] <annevk>
foolip: failing that a merge commit is probably cleaner than wiping history altogether

[01:32:43.0000] <annevk>
foolip: yeah, I guess that's what I mean, so we keep a linear history

[01:33:00.0000] <annevk>
foolip: but also don't lose the commits and blame et al keep working

[01:33:02.0000] <foolip>
I think that this is actually a good case to have a merge commit, makes it very easy to tell with confidence exactly what was merged

[01:33:56.0000] <foolip>
A squashed commit also isn't terrible if it points to the commit it came from, if the purpose is history digging

[01:34:02.0000] <foolip>
well, I'll let you decide, and I will do

[01:34:47.0000] <annevk>
foolip: meh, merge commit is fine I guess

[01:35:46.0000] <annevk>
foolip: hmm so if we remove deployment via the cgi script it seems you can remove the cgi script from .htaccess

[01:36:16.0000] <annevk>
foolip: and it seems we could use --delete for this as well, no?

[01:36:25.0000] <annevk>
foolip: anything other than the cgi script that would be gone?

[01:37:04.0000] <foolip>
annevk: some old browser logos, that kind of thing, only files that were once in git history

[01:38:08.0000] <annevk>
foolip: then --delete seems like the way to go, since leaving them up was more of a side effect of not having proper syncing

[01:38:32.0000] <foolip>
annevk: just a moment, will push new commits

[01:40:33.0000] <MikeSmith>
zcorpan: will take a look at the botie config

[01:40:34.0000] <annevk>
foolip: disabled the webhook

[01:40:43.0000] <foolip>
annevk: thanks

[01:41:33.0000] <annevk>
Hmm, changes to resources.whatwg.org ended up sending an email to a w3.org email address?

[01:42:02.0000] <MikeSmith>
annevk: my address?

[01:42:19.0000] <annevk>
MikeSmith: see pm, looks like it's meant to be a secret address

[01:44:26.0000] <MikeSmith>
annevk: http://simpsons.wikia.com/wiki/Kearney_Zzyzwicz

[01:47:01.0000] <foolip>
annevk: PR updated, see latest commit content and message

[01:48:43.0000] <annevk>
foolip: .htaccess still has the IndexIgnore line, but we can clean that up later too if you want

[01:48:58.0000] <annevk>
foolip: I approved the thing

[01:50:50.0000] <foolip>
annevk: I forgot to git commit --amend, just pushed the changes to .htaccess as well, can you take a look?

[01:51:57.0000] <annevk>
foolip: r+

[01:52:13.0000] <foolip>
annevk: hmm, so https://github.com/whatwg/resources.whatwg.org/pull/63#pullrequestreview-58884348

[01:52:45.0000] <annevk>
foolip: yeah? 😃

[01:52:46.0000] <foolip>
It's not even a sentence, and I think you don't mean the first line of the commit message?

[01:53:14.0000] <annevk>
foolip: the first line is the title, no dot

[01:53:19.0000] <annevk>
foolip: the remainder is the body, uses dots

[01:53:35.0000] <annevk>
foolip: but I guess we can make an exception for body that contains only a URL

[01:53:48.0000] <annevk>
foolip: I usually make a sentence of sorts out of it

[01:53:57.0000] <annevk>
foolip: anyway r+ either way, it's not important

[01:54:04.0000] <foolip>
ok :)

[01:58:29.0000] <zcorpan>
foolip: what happened here? https://github.com/whatwg/whatwg.org/issues/26

[01:59:09.0000] <foolip>
zcorpan: interesting, automatically closed because I merged in the history of resources.whatwg.org

[01:59:27.0000] <zcorpan>
aha

[01:59:53.0000] <foolip>
zcorpan: search my inbox, that was the only case

[02:08:44.0000] <annevk>
foolip: https://github.com/whatwg/whatwg.org/issues/18 too

[02:09:11.0000] <foolip>
annevk: oh, right, I can't just search for the same commit

[02:09:14.0000] <foolip>
trying inbox search again

[02:10:08.0000] <foolip>
OK, well, that is the only other one I find

[02:13:31.0000] <annevk>
same

[02:21:35.0000] <annevk>
Ugh, Travis is having trouble reaching resources.whatwg.org again, the sooner we move that the better

[02:21:56.0000] <annevk>
Must be DreamHost somehow intervening

[02:26:34.0000] <foolip>
annevk: has that been happening before?

[02:27:09.0000] <annevk>
foolip: yeah loads

[02:27:21.0000] <foolip>
annevk: ok, will prioritize getting that moved then

[02:27:30.0000] <annevk>
foolip: though only in the last couple weeks, some time before the trouble with the HTML Standard started

[02:28:01.0000] <annevk>
foolip: basically get The command "curl --remote-name --fail https://resources.whatwg.org/build/deploy.sh && bash ./deploy.sh" exited with 1.

[02:29:18.0000] <foolip>
annevk: we could get that from git I suppose instead

[02:29:31.0000] <foolip>
but, just fixing the hosting works too

[02:29:57.0000] <annevk>
foolip: fetching the whole repo seems worse though

[02:30:10.0000] <annevk>
foolip: perhaps if we had a Docker wrapper and cached it

[02:31:06.0000] <foolip>
annevk: I assumed one could just get a single file

[03:25:11.0000] <annevk>
foolip: ooh interesting

[03:27:14.0000] <foolip>
annevk: https://raw.githubusercontent.com/whatwg/whatwg.org/master/resources.whatwg.org/build/deploy.sh

[03:28:22.0000] <annevk>
From GitHub's servers, I see

[03:28:40.0000] <annevk>
Might be a good temporary fix

[03:28:52.0000] <foolip>
annevk: if one did that, there'd be no real reason to deploy it to resources.whatwg.org at all

[04:25:04.0000] <MikeSmith>
zcorpan: OK I just now changed botie config to have `addressing REQUIRED`

[04:25:30.0000] <MikeSmith>
which I think that should prevent it from saying anything unless directly addressed

[04:26:20.0000] <zcorpan>
MikeSmith: say hi to annevk

[04:26:26.0000] <zcorpan>
i guess it worked

[04:26:29.0000] <zcorpan>
thanks

[04:26:33.0000] <MikeSmith>
seems so

[04:27:09.0000] <zcorpan>
botie: say hi to MikeSmith

[04:27:09.0000] <botie>
will do

[05:03:34.0000] <annevk>
foolip: I'm back in a bit, but fully back Wednesday to help with things

[07:39:22.0000] <wanderview>
I was going to ask JakeA a question, but from reading this I guess he's supposed to be playing cricket or something... https://publicholidays.co.uk/summer-bank-holiday/

[07:43:01.0000] <Ms2ger>
Or watching the cricket, that's possible too

[07:43:27.0000] <Ms2ger>
Something unrelated to cricket should be unlikely, though

[08:31:40.0000] <gsnedders>
Ms2ger: You don't even have a bank holiday yet you're watching the cricket!

[08:32:01.0000] <Ms2ger>
/me denies watching anything

[08:32:07.0000] <Ms2ger>
Radio's on, though :)

[09:44:05.0000] <TabAtkins>
Protip: don't accidentally cron a git-updating script from the root account, then switch it to properly run on your user account, without remembering to update all git objects to be owned by your account again.

[10:48:13.0000] <Alming>
Hello


2017-08-29
[02:32:18.0000] <tobie>
Do we have any examples of inheriting NoInterfaceObjects? I think not, but I want to be sure.

[02:33:52.0000] <Ms2ger>
There used to be one in XHR

[02:34:10.0000] <Ms2ger>
I think we removed it because NoInterfaceObject should only be used on mixins

[02:35:58.0000] <tobie>
Ms2ger: so the reason I'm asking is because I'm busy adding dedicated mixin syntax right now

[02:36:16.0000] <Ms2ger>
Then we should not need NoInterfaceObject anymore

[02:36:20.0000] <tobie>
Ms2ger: and I want to be sure I can eschew inheritance altogether.

[02:36:38.0000] <Ms2ger>
Oh, inheriting mixins? Dunno

[02:36:59.0000] <tobie>
Ms2ger: we still need it for a bunch of things. But we'll call it LegacyNoInterfaceObjct

[02:38:27.0000] <tobie>
E.g. this guy: https://www.w3.org/TR/geolocation-API/#geolocation

[02:39:51.0000] <tobie>
Ms2ger: well, if there are no inheriting NoInterfaceObjects right now, we can keep things saner by preventing them altogether in the mixin design

[02:40:03.0000] <Ms2ger>
Makes sense

[02:43:09.0000] <tobie>
The follow-up question is whether there are any mixins with anything other than regular attributes and operations

[02:43:31.0000] <tobie>
i.e. statics? specials ops? etc.

[03:05:53.0000] <tobie>
Ms2ger: is moz-central still mirrored on Git somewhere?

[03:06:17.0000] <Ms2ger>
https://github.com/mozilla/gecko-dev

[03:11:04.0000] <tobie>
Ms2ger: ta

[03:11:41.0000] <gsnedders>
/me always want to know why it isn't mozilla-central but rather gecko-dev

[03:13:28.0000] <Ms2ger>
Np

[03:13:56.0000] <tobie>
gsnedders: to promote irc interactions between Mozillians and non-Mozillians

[03:14:07.0000] <tobie>
gsnedders: works like a charm

[03:14:50.0000] <tobie>
downloading gecko-dev is the new "waiting for the code to compile"

[04:06:09.0000] <zcorpan>
foolip: I'll let you merge the quirks PRs

[05:11:12.0000] <zcorpan>
/me finds files under demos/ with <!DOCTYPE html PUBLIC "-//WHATWG//NONSGML HTML5//EN">

[05:21:53.0000] <Ms2ger>
Nice

[05:33:15.0000] <gsnedders>
where does that PUBLIC ID even come from?

[05:34:06.0000] <oal_>
Any ideas why Chrome refuses to accept "793" and shows a value that "793.01" is valid when using an <input type="number"> field?

[05:42:01.0000] <ondras>
hm

[05:42:03.0000] <ondras>
The server at wiki.ecmascript.org is taking too long to respond.

[06:30:39.0000] <Domenic>
tobie: sounds like you're on the right track with mixins. I do not know of any statics or special ops yet, so we can start conservative.

[06:32:04.0000] <tobie>
Domenic: yeah, turns out awk + grep do wonders for that kind of research

[06:32:36.0000] <Domenic>
Special ops and even statics don't seem problematic in theory. But why make it more complex than it needs to be, IMO.

[06:33:13.0000] <tobie>
Domenic: yeah, this is the occasion to enforce cleaner design, so let's do it

[06:34:00.0000] <tobie>
Domenic: as you said, we can always add more stuff if there are compelling use cases

[06:36:39.0000] <wanderview>
JakeA: are there any real blockers to landing the fetch abort PR?

[06:41:20.0000] <JakeA>
wanderview: there were some additional comments, but I haven't gone through them yet. It feels close. Really close.

[06:41:48.0000] <wanderview>
yea, we already have the tests

[06:42:34.0000] <wanderview>
JakeA: do you think there is any reason to ship Abort API without the fetch integration?  I think no, but baku was proposing it

[06:43:58.0000] <JakeA>
wanderview: there are other specs interested in using it, but I don't see a huge benefit. I guess there's a danger that developers would think !!self.AbortController means fetch abort is supported

[06:44:24.0000] <wanderview>
yea

[06:44:31.0000] <wanderview>
just like ReadableStream!

[07:02:16.0000] <wanderview>
JakeA: so we are having trouble getting this test case to pass with the proposed webidl: https://hg.mozilla.org/integration/mozilla-inbound/file/92692c9a4f1e/testing/web-platform/meta/fetch/api/abort/general-serviceworker.https.html.ini#l3

[07:02:33.0000] <wanderview>
JakeA: baku tells me he has to change RequestInit.signal to `AbortSignal?` instead of `AbortSignal` for it to work

[07:03:10.0000] <JakeA>
wanderview: this is a mistake in the test, thanks for flagging it

[07:03:40.0000] <JakeA>
wanderview: I'll fix that now

[07:05:12.0000] <wanderview>
JakeA: thanks!

[07:05:19.0000] <wanderview>
JakeA: also, is the timing of this test guaranteed? http://searchfox.org/mozilla-central/source/testing/web-platform/tests/fetch/api/abort/general.js#439

[07:05:43.0000] <wanderview>
I don't understand how you can ensure the empty.txt file loads through the network stack before the abort() happens

[07:08:20.0000] <JakeA>
wanderview: hmm, I thought that since it had an empty body it'd be done by the time headers arrived, since that's all there was. I could clone the response and await responseClone.text(), would that help?

[07:08:23.0000] <wanderview>
JakeA: I mean, is there something in the spec that guarantees the network stack will detect the body is complete when it completes receiving the headers and resolves the fetch() promise?  we have some async steps that close the body shortly after, but its a separate task

[07:09:55.0000] <JakeA>
wanderview: I guess teeing the body stream and exhausting it would be better?

[07:10:02.0000] <JakeA>
no wait, teeing wouldn't work

[07:10:26.0000] <JakeA>
await response.clone().text()

[07:10:31.0000] <wanderview>
JakeA: I don't understand what you are trying to test here... that a complete empty stream is not errored on abort?

[07:13:44.0000] <JakeA>
wanderview: going to double check how I'm using streams here. A previous draft treated things like the readable canceling, but it was changed to erroring. Going to double check the assumptions in that test

[07:14:51.0000] <JakeA>
no, it's still cancelling, I remembered wrong. Actually, I'll stop piping brain to IRC until I'm sure

[07:18:01.0000] <zcorpan>
I... think I've managed to confuse myself https://github.com/whatwg/html/issues/2973

[07:18:04.0000] <wanderview>
JakeA: well, I think we are not going to block shipping on this test for now... right now we fail it

[07:19:41.0000] <JakeA>
wanderview: it's definitely an edge case

[07:20:19.0000] <wanderview>
JakeA: I do want this one fixed before shipping, though: https://bugzilla.mozilla.org/show_bug.cgi?id=1394102

[07:20:27.0000] <wanderview>
JakeA: and unfortunately I don't think there is a WPT test for it yet

[07:21:02.0000] <wanderview>
JakeA: is this something you want to add or do you want me to have baku write the WPT test and upstream it through gecko?

[07:21:47.0000] <JakeA>
wanderview: happy for baku to do it

[07:21:53.0000] <wanderview>
ok

[07:21:58.0000] <JakeA>
sorry there wasn't a test already

[07:22:01.0000] <wanderview>
np

[07:22:35.0000] <wanderview>
JakeA: at least in our implementation we often lose data on Request going to FetchEvent.request... because of how we have to convert to an itnernal network thing and then back to Request... so its a common bug I've started to look for

[07:27:12.0000] <wanderview>
JakeA: honestly its surprising how many of the tests work correctly without having an implementation to run them against initially

[07:28:04.0000] <JakeA>
wanderview: I built *the worst* polyfill so I could kinda test some of the tests

[07:28:29.0000] <JakeA>
but yeah, it helped catch mistakes

[07:29:15.0000] <wanderview>
JakeA: any chance you could rubber stamp this WPT change to SW tests? https://github.com/w3c/web-platform-tests/pull/6745

[07:30:25.0000] <wanderview>
test bug on the uplift from blink that wasn't caught because blink doesn't pass the test yet

[07:31:26.0000] <JakeA>
wanderview: merged!

[07:31:31.0000] <wanderview>
thanks!

[07:38:47.0000] <wanderview>
JakeA: I'm always conflicted about whether to do WPT changes in gecko and then pester jgraham to sync them... or to do an upstream PR directly

[07:39:52.0000] <JakeA>
I HATH RETURN'D FROM THE DEPTHS OF THE STREAMS SPEC

[07:40:40.0000] <JakeA>
wanderview: ok, so, https://streams.spec.whatwg.org/#readable-stream-default-controller-close - this is called when the stream is closed

[07:41:52.0000] <JakeA>
wanderview: Usually, the closing operation is in effect added to the end of a queue, behind data that's already been added

[07:42:14.0000] <JakeA>
So the stream doesn't become actually closed until something reads all the data

[07:42:32.0000] <JakeA>
However, if there's no data, the stream is closed immediately

[07:42:47.0000] <JakeA>
And once it's closed, it can't error

[07:43:29.0000] <JakeA>
So, if a byte is added to the stream, then it's closed, that stream can still error as the result of aborting

[07:43:48.0000] <wanderview>
JakeA: sure, but in fetch when does it make the determination that there is no data?

[07:44:53.0000] <JakeA>
wanderview: yeah, the timing of that test is broken. It assumes close() has already been called, which may not be the case

[07:45:14.0000] <wanderview>
perfect!

[07:46:12.0000] <JakeA>
wanderview: I'm trying to test that a closed response stream with nothing in the queue will not reject with AbortError

[07:46:30.0000] <JakeA>
but I'm not sure it's testable

[07:46:43.0000] <JakeA>
outside of a controlled streams test of course

[07:48:53.0000] <JakeA>
wanderview: would awaiting response.clone().text() sort it, or is that still unreliable?

[07:49:35.0000] <wanderview>
JakeA: I believe it would avoid the race, I'm just not 100% sure if aborting at that point tests what you want

[07:49:38.0000] <wanderview>
I guess it does?

[08:15:29.0000] <JakeA>
wanderview: the test would clone, read all of the response, abort, then read from the original request's stream

[08:16:32.0000] <JakeA>
wanderview: that means the browser would now have the whole response, but I guess it doesn't guarantee that the stream object has closed

[08:21:09.0000] <JakeA>
Domenic: If a response is empty, is response.body.getReader().closed guaranteed to fulfill?

[08:21:22.0000] <Domenic>
Pretty sure yes

[08:22:33.0000] <JakeA>
The underlying source may be waiting on a pull to call controller.close(), but I guess that will always happen, even without reader.read()

[08:58:22.0000] <JakeA>
wanderview: ok so I got distracted and didn't change those tests, but it's on my todos for tomorrow

[09:10:42.0000] <wanderview>
np, thanks

[13:46:47.0000] <gsnedders>
TabAtkins: how is perf under pypy nowadays?

[13:46:53.0000] <TabAtkins>
Not a clue.

[14:04:34.0000] <wanderview>
I wish WPT tests would include comments about the intent of the test... sometimes its hard to infer what its trying to test

[14:04:43.0000] <wanderview>
like this test: https://github.com/w3c/web-platform-tests/blob/master/service-workers/service-worker/navigation-redirect-body.https.html

[14:05:38.0000] <wanderview>
I think its trying to verify the POST gets converted to a GET on the redirect, but its a bit vague

[14:05:52.0000] <gsnedders>
oh god the number of arguments we've had over that

[14:06:37.0000] <gsnedders>
because 99% of the time a fair number of people go "my tests are obvious what they're testing and I'm not going back and adding comments so you're not getting them"

[14:07:02.0000] <wanderview>
gsnedders: I'm not saying to go back and add them... but we could encourage people to document future tests

[14:07:41.0000] <wanderview>
and unfortunately a lot of tests are not obvious when they are spread across main window, an iframe, a service worker event handler, and a .py server script

[14:11:38.0000] <wanderview>
JakeA: with foreign fetch going away, are we keeping link registration of service workers?  I assume so, but they were added together so wasn't sure


2017-08-30
[17:54:12.0000] <wanderview>
JakeA: also, I think this spec issue might be another one of those things we "decided", but neither firefox or chrome ships yet: https://github.com/w3c/ServiceWorker/issues/787

[17:54:30.0000] <wanderview>
JakeA: do we really want to do that or should we warn MS/webkit off from it?

[23:45:08.0000] <zcorpan>
gsnedders: https://whatwg.org/specs/web-forms/2005-07-03/

[23:57:26.0000] <zcorpan>
https://annevankesteren.nl/2005/07/html5-doctype is a good read; annevk's way of rambling, and the comments with sgml nerd snipes

[00:14:59.0000] <MikeSmith>
wow I think I never read that before maybe

[00:18:23.0000] <MikeSmith>
fun to look at https://annevankesteren.nl/2005/06/countdown

[00:21:20.0000] <MikeSmith>
and https://annevankesteren.nl/2003/08/markup

[00:36:44.0000] <ondras>
reading about the "noopener" stuff

[00:37:00.0000] <ondras>
apparently the attack vector is also relevant to <form target="_blank"> ?

[00:37:08.0000] <ondras>
but there is no rel attribute here to prevent it from happening?

[00:41:02.0000] <MikeSmith>
hmm yeah

[00:42:21.0000] <MikeSmith>
I wonder if mathiasbynens has written about this

[00:43:10.0000] <mathiasbynens>
not about <form target="_blank"> specifically (only https://mathiasbynens.github.io/rel-noopener/)

[00:43:24.0000] <MikeSmith>
hi mathiasbynens

[00:43:25.0000] <mathiasbynens>
/me wonders how common <form target=_blank> is

[00:43:38.0000] <mathiasbynens>
heya MikeSmith!

[00:43:39.0000] <MikeSmith>
yeah, I knew about https://mathiasbynens.github.io/rel-noopener/

[00:44:17.0000] <MikeSmith>
I find https://stackoverflow.com/questions/13569776/obtain-reference-to-blank-target-window-on-form-submit

[00:45:50.0000] <ondras>
mathiasbynens: probably not that common, but once people start adding noopeners to <a>s, attackers might switch to these forms

[00:46:27.0000] <MikeSmith>
Domenic: by the way, does the Stack Overflow stats info expose stats at the question level? Such that you could look at a particular question and find out where the views of that question are coming from?

[00:47:20.0000] <Domenic>
MikeSmith: not that I know of, hmm

[00:58:30.0000] <annevk>
ondras: I don't think the worry is attackers injecting the links

[00:58:40.0000] <ondras>
ok

[00:58:49.0000] <ondras>
(but attackers manipulating the target pages, right?)

[00:58:57.0000] <annevk>
ondras: it is worth considering though how much of the stuff that works on <a> should also work on <form>

[00:59:14.0000] <annevk>
ondras: since they're effectively the same and end up triggering the same algorithm

[00:59:20.0000] <ondras>
right

[00:59:35.0000] <annevk>
ondras: adding rel="" to <form> doesn't seem bad per se

[01:02:36.0000] <ondras>
annevk: agreed

[01:03:28.0000] <ondras>
annevk: also, perhaps, <base>, as these can specify target="_blank" as well

[01:04:37.0000] <annevk>
ondras: I'd rather people just avoid <base>

[01:04:44.0000] <ondras>
:)

[01:04:49.0000] <ondras>
/me has a use case

[01:05:08.0000] <annevk>
Of course you do

[01:05:13.0000] <ondras>
my html slide decks typically have <base target="_blank"> and I think it is reasonable

[01:05:51.0000] <annevk>
Yeah, I guess <base rel=noopener> would actually be nice

[01:06:04.0000] <ondras>
:)

[01:06:15.0000] <annevk>
ondras: you might be able to convince mkwst and make this a  thing

[01:06:43.0000] <ondras>
annevk: okay. I shall talk him to <form rel> or <base rel> or both?

[01:10:08.0000] <annevk>
ondras: both I suppose

[01:10:18.0000] <ondras>
annevk: okay, thanks

[03:04:01.0000] <ondras>
mkwst: what is your opinion regarding the possibility of adding the rel=noopener attribute/value for <form> and <base> tags?

[03:06:32.0000] <JakeA>
wanderview: Baku was right in terms of the signal null thing. It was just the IDL that was wrong. Fixing now.

[03:07:10.0000] <JakeA>
done

[04:38:29.0000] <ondras>
so, for an Atomics-related question, who is the best irc-enabled person?

[04:44:46.0000] <annevk>
ondras: maybe in #tc39 or #jslang on Mozilla IRC?

[04:44:56.0000] <annevk>
(#tc39 is on Freenode)

[04:45:42.0000] <annevk>
ondras: as for adding rel to <form> and <base>, might be better to file a bug against whatwg/html and get attention that way

[04:45:53.0000] <annevk>
ondras: I vaguely recall someone suggesting it before for <form>

[04:46:00.0000] <ondras>
annevk: okay, thanks

[05:25:41.0000] <JakeA>
annevk: any idea why XHR terminates the request during the open() method? https://xhr.spec.whatwg.org/#the-open()-method

[05:25:54.0000] <JakeA>
step 10

[05:30:48.0000] <JakeA>
can an XHR be opened, sent, then opened again (resulting in termination of the original)

[05:54:36.0000] <Ms2ger>
JakeA, why not?

[06:06:55.0000] <JakeA>
Ms2ger: I guess I'd always thought that new XMLHttpRequest maps to at most one request/response

[06:07:20.0000] <Ms2ger>
Now that would be the simple approach

[06:08:00.0000] <Ms2ger>
But imagine the overhead if you had to create a new object for your next request!

[06:08:08.0000] <Ms2ger>
(At least I suspect that was the idea)

[06:08:36.0000] <JakeA>
hmm

[06:10:39.0000] <zcorpan>
how's w3schools these days, for the purpose of being worthwhile for beginners? has it improved? i see http://www.w3fools.com/ has toned down its messaging from what i remember

[06:10:55.0000] <TimothyGu>
JakeA: just making sure, you did see my (mostly inconsequential) comment on that fetch cancelation PR right?

[06:11:15.0000] <JakeA>
TimothyGu: yep! I've made the changes, just haven't pushed yet

[06:11:24.0000] <JakeA>
Was OOO last week

[06:11:28.0000] <TimothyGu>
oh cool

[06:18:35.0000] <annevk>
JakeA: I'm not sure who made all the dubious decisions in the XMLHttpRequest API

[06:20:33.0000] <MikeSmith>
I thought Microsoft did and everybody else just had to reverse engineer the IE behavior

[06:21:22.0000] <MikeSmith>
zcorpan: I haven’t seen any indications that w3cschools has improved at all

[06:21:34.0000] <MikeSmith>
they have no incentive to improve really

[06:22:59.0000] <annevk>
MikeSmith: the module might have come from Outlook originally or some such

[06:23:17.0000] <MikeSmith>
yeah it did

[06:23:20.0000] <MikeSmith>
different team

[06:23:32.0000] <annevk>
MikeSmith: there was a post by a Microsoft engineer at some point, but nobody really wanted to come out say it was the truth

[06:24:06.0000] <zcorpan>
MikeSmith: "W3Schools still has issues but they have at least worked on the primary concern developers had." says w3fools, which seems like an indicator of improvement

[06:24:17.0000] <JakeA>
TimothyGu: thanks for the review btw!

[06:24:44.0000] <TimothyGu>
JakeA: np :)

[06:25:05.0000] <MikeSmith>
we met the guy who worked on the team that made XHR, when we went to Redmond for that sorta emergency meeting after Microsoft released their proprietary CORS thing

[06:25:16.0000] <gsnedders>
zcorpan: https://github.com/paulirish/w3fools/commit/0d78c7fe164418937695b7f20cd536a910760060

[06:25:52.0000] <MikeSmith>
zcorpan: I don’t think it’s observable that it’s improved

[06:26:17.0000] <zcorpan>
k, thanks

[06:26:39.0000] <MikeSmith>
at least I can say from reading questions at Stack Overflow that there are many cases still of content there which is out of date or plain wrong

[06:27:27.0000] <gsnedders>
zcorpan: thugh obviously that commit that doesn't say what changed

[06:28:45.0000] <MikeSmith>
http://www.hixie.ch/advocacy/writing-test-cases-for-web-browsers is a nice read (found by way of link in one of annevk old blog posts)

[06:29:16.0000] <MikeSmith>
I especially like STEP ONE of Creating testcases from scratch

[06:29:46.0000] <MikeSmith>
the advice on reading the specification

[06:29:57.0000] <wanderview>
JakeA: should baku write a github issue for the AbortSignal? thing?

[06:34:54.0000] <JakeA>
wanderview: I just pushed that change

[06:35:04.0000] <wanderview>
JakeA: thanks

[06:44:02.0000] <wanderview>
JakeA: I wonder what edge implemented here...

[06:44:26.0000] <JakeA>
wanderview: yeah, I'll ping them once the PR lands

[06:58:43.0000] <JakeA>
annevk: GitHub isn't displaying it on the main pull page for some reason, but I'm not sure what the best way forward is in terms of abort & XHR https://github.com/whatwg/fetch/pull/523/files#r136062170

[07:00:02.0000] <Ms2ger>
MikeSmith, yeah, good advice

[07:00:34.0000] <Ms2ger>
/me skips the spec-reading part (boooooooooring), writes a test that vaguely matches what he thinks the spec might say

[07:03:01.0000] <annevk>
JakeA: I will look tomorrow most likely, sorry about that

[07:03:19.0000] <JakeA>
annevk: no problem at all

[07:05:48.0000] <wanderview>
JakeA: oh, here is a tricky question... if a FetchEvent handler saves the evt.request.signal somewhere, but does *not* call respondWith(), should the signal still fire if the outer network request is aborted?

[07:06:28.0000] <wanderview>
JakeA: or can we mark disconnect the signal after the FetchEvent handler passes on intercepting the request

[07:06:30.0000] <wanderview>
?

[07:09:32.0000] <JakeA>
wanderview: that is a tricky question. I'm guessing it's much easier implementation-wise to disconnect the signal?

[07:10:10.0000] <wanderview>
JakeA: easier... not really... but from an efficiency and memory footprint it would be nice to

[07:10:13.0000] <wanderview>
to do

[07:12:13.0000] <wanderview>
JakeA: I guess there is a related question... if the event handler does not call respondWith(), but holds on to FetchEvent.request... can it read the body later?  or is the body marked used when the browser conceptually consumes it?

[07:17:42.0000] <JakeA>
wanderview: body should be marked as used

[07:18:29.0000] <JakeA>
I think

[07:18:43.0000] <nox>
annevk: Did we stop trying to get every interface to have a Exposed attribute and kill PrimaryGlobal?

[07:19:25.0000] <wanderview>
JakeA: hmm... I doubt we do that

[07:19:57.0000] <JakeA>
wanderview: I haven't found it in the spec yet either

[07:21:15.0000] <Ms2ger>
nox, that has recently started happening

[07:21:40.0000] <Ms2ger>
https://github.com/heycam/webidl/pull/423

[07:23:37.0000] <JakeA>
wanderview: hmm. It does feel like we're treating the request as a clone, which is especially broken in the body stream case

[07:23:43.0000] <JakeA>
wanderview: I'll write up an issue

[07:24:06.0000] <wanderview>
JakeA: in our implementation it is effectively a clone

[07:24:17.0000] <wanderview>
but not sure the spec should assume that

[07:31:50.0000] <ato>
annevk: What’s the right way to compare documents?

[07:32:05.0000] <ato>
annevk: Say I want to compare an element’s node document with the document of the WindowProxy?

[07:32:23.0000] <ato>
annevk: In specalese, that is.

[07:38:34.0000] <annevk>
nox: no

[07:39:02.0000] <annevk>
ato: doc is otherDoc?

[07:39:19.0000] <ato>
annevk: Just “is”?

[07:39:27.0000] <ato>
annevk: That’s super, thanks.

[07:56:26.0000] <JakeA>
wanderview: https://github.com/w3c/ServiceWorker/issues/1191

[07:57:15.0000] <JakeA>
wanderview: It feels like request.signal should continue to work until it's GC'd

[07:59:03.0000] <tobie>
wanderview/gsnedders: re: adding comments to tests about what it is they're testing, that's what the name of the test is for. Which is why it is absurd that it's the last arg instead of the first.

[07:59:09.0000] <annevk>
ato: object identity is is

[07:59:26.0000] <wanderview>
tobie: a single string is pretty inadequate for documentation, imo

[07:59:49.0000] <gsnedders>
tobie: I agree with that now. Unfortunately, I didn't agree it when I originally reviewed testharness.js. :P

[07:59:56.0000] <tobie>
wanderview: means you're testing too many things at once, then.

[08:00:17.0000] <tobie>
gsnedders: rwaldron had a fit over this

[08:00:22.0000] <wanderview>
tobie: no it doesn't... please come write some service workers tests and get back to me

[08:00:50.0000] <wanderview>
and putting multi-line paragraphs in the name make it hard to write things like expectation files where you need to reference the test

[08:02:34.0000] <tobie>
wanderview: yeah, this might very well not be the right solution for all the cases, but it clearly is for the 80% and yet…

[08:02:52.0000] <tobie>
wanderview: good point re the need to ref tests by name in acceptance tests.

[08:03:13.0000] <tobie>
wanderview: care to point me to some good examples of SW tests? curious as to what they look like

[08:05:51.0000] <tobie>
wanderview: (in case that wasn't clear, that was a general "you", not you specifically)

[08:06:14.0000] <wanderview>
ok

[08:16:08.0000] <annevk>
JakeA: you mean until request can be GC'd, right?

[08:16:36.0000] <annevk>
JakeA: request has a strong reference to any objects it holds

[08:19:36.0000] <wanderview>
annevk: in theory someone could hold the signal alive beyond the end of the Request

[08:20:35.0000] <annevk>
wanderview: in that case it seems fine to toss the request though

[08:21:38.0000] <wanderview>
annevk: I guess I don't know what you are saying... even if the Request wrapper is GC'd, the signal tied to the main thread request could still work, right?

[08:22:30.0000] <annevk>
wanderview: I was mostly saying that request.signal should continue working for as long as someone has a reference to request

[08:29:43.0000] <JakeA>
agreed

[08:29:58.0000] <JakeA>
signal can't be gc'd until request is

[08:30:49.0000] <wanderview>
JakeA: also I think FetchEvent.request might need to be a "clone" because of cross-thread stuff

[08:32:03.0000] <JakeA>
wanderview: hm, so we'd need to buffer any request body stream until fetchEvent.request can be GC'd?

[08:32:31.0000] <wanderview>
JakeA: well, it might depend on how ReadableStream transfer is spec'd?  is that spec'd yet?

[08:34:35.0000] <JakeA>
wanderview: nah, don't think so

[08:35:48.0000] <wanderview>
JakeA: in theory it should be like the browser consuming the Request.body stream on the main thread... it may stop reading if the worker thread is not consuming it, though

[08:57:17.0000] <ato>
annevk: Thanks

[09:21:35.0000] <wanderview>
JakeA: btw, current firefox nightly has abortable fetch enabled

[09:21:59.0000] <wanderview>
won't ride the trains to beta/release until we can fix the service worker FetchEvent.request.signal thing

[09:59:29.0000] <JakeA>
wanderview: ohhhh exciting!

[09:59:43.0000] <wanderview>
JakeA: I'm trying to make a glitch demo for it now

[10:03:59.0000] <wanderview>
JakeA: https://simple-abort-fetch.glitch.me/

[10:05:15.0000] <wanderview>
I'm not sure why we buffer for so long before returning the Response

[10:16:31.0000] <wanderview>
JakeA: do you know how to set headers on responses in glitch server.js?  I can't seem to make it work

[10:18:38.0000] <wanderview>
nevermind... I finally figured it out

[11:00:48.0000] <wanderview>
oh my https://webkit.org/blog/7846/concurrent-javascript-it-can-work/

[13:16:53.0000] <smaug____>
that is scary


2017-08-31
[23:19:17.0000] <zcorpan>
Hmm, found a bug with the redirect script. Clicking Table of Contents redirects to indices.html#index

[00:27:12.0000] <tobie>
Can anyone enlighten me on the difference between these two things: https://gist.github.com/tobie/13840ae7dd7dae00ab498f5d55c82ca9?

[00:29:39.0000] <tobie>
What's the benefit of using a mixin over a partial in such cases?

[00:30:18.0000] <tobie>
What elements should editors consider when deciding between one or the other?

[00:31:15.0000] <annevk>
tobie: that should be a partial, but html-build is being annoying

[00:31:30.0000] <tobie>
annevk: Oh!

[00:32:06.0000] <tobie>
annevk: That was my impression too. Will add a note to this effect in mixins.

[00:32:06.0000] <annevk>
tobie: I might even just put it straight on Window actually when I have some time, it's all in the same spec anyway

[00:32:58.0000] <tobie>
I've seen that pattern elsewhere recently, hence the question

[00:33:56.0000] <tobie>
annevk: eg: https://gist.github.com/tobie/999f7d5bcc3a7767f75945ad683162bb

[00:35:39.0000] <annevk>
tobie: that's different

[00:35:42.0000] <annevk>
tobie: that's a mixin

[00:36:19.0000] <annevk>
tobie: that could use partial interface  WindowOrWorkerGlobalScope though

[00:36:32.0000] <tobie>
yeah

[00:36:35.0000] <annevk>
tobie: for  WindowOrWorkerGlobalScope we'll need partial mixins, not sure if you already identified that

[00:37:35.0000] <tobie>
annevk: yes.

[00:44:47.0000] <zcorpan>
annevk: https://github.com/whatwg/wattsi/issues/37 still applies?

[00:46:06.0000] <annevk>
zcorpan: oh maybe

[00:46:23.0000] <annevk>
zcorpan: yeah it does

[00:46:44.0000] <annevk>
zcorpan: when we made html.spec.whatwg.org cgi free we didn't fix wattsi

[00:46:53.0000] <annevk>
zcorpan: Domenic probably knows what to do

[00:47:50.0000] <zcorpan>
ok, I assigned the issue to him

[00:48:07.0000] <annevk>
I disabled the webhook for now

[02:28:28.0000] <tobie>
Interfaces vs mixins vs namespaces: https://user-images.githubusercontent.com/3392/29916512-4f6a5b98-8e3f-11e7-923d-6c465c6c2352.jpg

[02:30:05.0000] <annevk>
looks reasonable

[02:55:07.0000] <tobie>
good

[03:05:21.0000] <annevk>
JakeA: btw, can you make changes to https://github.com/whatwg/fetch/pull/523 as new commits?

[03:05:31.0000] <annevk>
JakeA: we can just squash & merge when landing

[03:06:43.0000] <JakeA>
annevk: ok. I was squashing as I went along because it was easier to deal with rebase conflicts. I've been trying to keep up with master

[03:06:57.0000] <JakeA>
but we can leave that until merge time

[03:10:51.0000] <annevk>
JakeA: I think it's fair to squash after a round of reviews, but for new feedback having separate commits makes it easy to see if the feedback got addressed

[03:11:15.0000] <JakeA>
annevk: gotcha

[05:52:37.0000] <TimothyGu>
question: is there any history behind "Please leave your sense of logic at the door, thanks!"? sounds like an inside joke or something that I havent' been able to figure out

[05:54:13.0000] <nox>
TimothyGu: The Web grew organically,

[05:54:15.0000] <gsnedders>
TimothyGu: much of the web platform being totally nonsensical and undesigned

[05:54:19.0000] <nox>
and sometimes make no sense.

[05:54:23.0000] <nox>
makes*

[05:54:43.0000] <TimothyGu>
ah okay, that

[05:55:13.0000] <gsnedders>
(it's been in the topic for idk how long, over a decade I'm pretty sure, back when most work in here was on HTML and trying to reverse engineer browser behaviour)

[05:55:48.0000] <TimothyGu>
thanks people

[05:56:52.0000] <Ms2ger>
Dates back to 2006 at least: https://krijnhoetmer.nl/irc-logs/whatwg/20061201

[05:57:06.0000] <gsnedders>
pretty sure it was here when I joined a month or two before that

[05:57:38.0000] <Ms2ger>
What were you then, ten years old?

[05:57:51.0000] <gsnedders>
something like that

[05:59:36.0000] <TimothyGu>
hm

[05:59:45.0000] <TimothyGu>
is Hixie not active in whatwg anymore?

[06:00:19.0000] <Ms2ger>
Hasn't been for a few years now, I think

[06:00:55.0000] <TimothyGu>
ok..

[06:01:11.0000] <TimothyGu>
i'm just looking over the irc channel stats lol

[06:03:15.0000] <gsnedders>
AFAIK he works on Flutter nowadays

[06:12:07.0000] <gsnedders>
so I'm calling Promise.resolve(promise) but promise.then seemingly never gets called? have I misudnerstood something?

[06:14:27.0000] <gsnedders>
like, even Promise.resolve(pending_promise).then(function(){alert(1);}); doesn't do anything

[06:18:49.0000] <wanderview>
Domenic: did I see you comment on a github issue about xhr not triggering an error event if the window is closed?

[06:22:50.0000] <Ms2ger>
(Two years, apparently)

[06:25:08.0000] <jgraham>
More than that I thought

[06:25:11.0000] <jgraham>
But maybe

[06:25:18.0000] <gsnedders>
nah, seems about right

[06:25:31.0000] <wanderview>
JakeA: do you know about my question above regarding XHR and window close? ^^^

[06:25:37.0000] <Ms2ger>
That's what the git history claims

[06:26:04.0000] <Ms2ger>
But I guess he was starting to disappear for a while before that

[06:26:13.0000] <gsnedders>
a long while before that

[06:26:29.0000] <wanderview>
JakeA: we have a bug about FF rejecting fetch() promises when the window is navigated, but apparently chrome doesn't reject in that case... wondering if chrome is following some xhr behavior, etc? https://bugzilla.mozilla.org/show_bug.cgi?id=1280189

[06:26:39.0000] <wanderview>
might be relevant for the abort spec PR

[06:28:12.0000] <gsnedders>
more completely, Promise.resolve(new Promise(function(){})).then(function(){console.log(1);}); returns a still pending promise

[06:28:22.0000] <gsnedders>
which isn't what I understood Promise.resolve to do with a promise as an argument?

[06:28:54.0000] <Ms2ger>
Doesn't it wait for microtasks?

[06:29:14.0000] <gsnedders>
it should still eventually resolve, then, though?

[06:30:16.0000] <JakeA>
wanderview: hmm, I'm not sure what the correct behaviour is here, but I agree we should spec it. I guess Firefox is performing https://fetch.spec.whatwg.org/#concept-fetch-group-terminate

[06:34:29.0000] <wanderview>
JakeA: not sure what the spec says, but it seems we may avoid doing the XHR event on navigation because we check to see if the window is still the current, active one: http://searchfox.org/mozilla-central/source/dom/xhr/XMLHttpRequestMainThread.cpp#1389

[06:34:35.0000] <wanderview>
promise rejection probably doesn't do that

[06:35:08.0000] <wanderview>
maybe we shouldn't reject a promise on an inactive window?

[06:35:16.0000] <benjamingr_>
As a user I would not expect a rejection here - I would expect cancellation flow

[06:35:40.0000] <benjamingr_>
I would expect it to behave exactly like aborting with an AbortController

[06:35:40.0000] <JakeA>
That would be an AbortError rejection

[06:36:07.0000] <wanderview>
which currently gets converted to a NetworkError by fetch API, right?

[06:36:40.0000] <JakeA>
If it goes through a service worker, yeah

[06:36:59.0000] <wanderview>
hmm

[06:37:22.0000] <wanderview>
right, I guess my glitch test showed AbortError

[06:37:35.0000] <wanderview>
for some reason I thought fetch() always rejected with NetworkError

[06:37:48.0000] <JakeA>
Nah, almost always TypeError

[06:37:53.0000] <JakeA>
but now AbortError :D

[06:38:01.0000] <JakeA>
(if it's an abort)

[06:38:12.0000] <wanderview>
/me is getting himself confused.

[06:38:35.0000] <benjamingr_>
I gave a short talk on why fetch is cool after people complained about the API not being as nice as axios for some stuff - I used `AbortController` as if it has been there forever and no one called my bluff :D

[06:38:38.0000] <JakeA>
But if something else aborts the connection, like the browser, should that show up as an abort?

[06:38:56.0000] <JakeA>
Because the dev didn't abort it, the browser did

[06:39:04.0000] <wanderview>
JakeA: in my glitch test I seem to get TypeError

[06:39:08.0000] <benjamingr_>
I think so, I also think that's what XHR does

[06:39:18.0000] <benjamingr_>
(in terms of showing to the user)

[06:39:18.0000] <JakeA>
As in, if the server aborts, that *doesn't* show up as an abort error

[06:39:23.0000] <JakeA>
that's just a connection failure

[06:39:36.0000] <benjamingr_>
If the server aborts that's different because the server closed the socket and not the client

[06:39:57.0000] <wanderview>
well, I mean... I just tried loading my glitch test and navigated away while it was running... saw a TypeError displayed briefly before the next page appeared

[06:40:19.0000] <JakeA>
But if the browser cuts you off, is that "Ahh yes, this is just an abort", or "wtf I was cut off"?

[06:40:47.0000] <wanderview>
I kind of think it should be an AbortError

[06:40:53.0000] <wanderview>
but I dunno

[06:41:17.0000] <benjamingr_>
If the browser cuts you off for navigation, I'd expect "Ahh yes, this is just an abort" but not if the server aborts it.

[06:41:37.0000] <benjamingr_>
The reason is that if I have my own single page app - this is the behavior I'd expect navigation to have

[06:41:45.0000] <JakeA>
benjamingr_: what if the user cuts you off by hittin the X in their browser?

[06:49:51.0000] <benjamingr_>
That's still an abort

[06:50:08.0000] <JakeA>
Ok, cheers!

[06:50:14.0000] <benjamingr_>
I'm just going off my intuition here - none of what I'm saying is backed up by anything other than my feeling about what I'd expect, by the way :D

[06:57:21.0000] <JakeA>
yeah, I'm still trying to figure it out

[08:00:30.0000] <wanderview>
JakeA: riddle me this... outer fetch() is intercepted, FetchEvent is dispatched on worker thread, outer fetch() is aborted while FetchEvent is being processed... what should happen?

[08:00:55.0000] <wanderview>
should the outer fetch() reject with AbortError immediately?  or should it wait for the FetchEvent in some way?

[08:01:56.0000] <JakeA>
wanderview: immediate abort

[08:02:39.0000] <JakeA>
wanderview: the worker is like the network at this point. It may or may not abort, it may abort after some time, but as far as the page is concerned, it's aborted

[08:02:47.0000] <wanderview>
JakeA: what about a respondWith() called after that?  does it silently just eat the response or does it reject or something?

[08:03:05.0000] <wanderview>
does it keep the SW alive?

[08:03:46.0000] <JakeA>
wanderview: silent I think. It may not keep the sw alive, but waitUntil should. fetchEvent.request.signal will have signalled abort

[08:11:18.0000] <wanderview>
JakeA: in theory we could let respondWith() still keep the SW alive and trust that the FetchEvent.request.signal would abort that promise in most cases

[08:11:42.0000] <JakeA>
wanderview: true, I'm fine with that

[09:28:30.0000] <Domenic>
annevk: with the new scripts wattsi should be updated each time, in theory

[09:43:59.0000] <annevk>
Domenic: cool, so I can remove the Webhook completely then

[09:44:08.0000] <Domenic>
ah, yep

[09:44:21.0000] <annevk>
done

[09:45:11.0000] <tobie>
currently, NoInterfaceObject interfaces have an interface prototype object. Do we need to keep something similar for mixins (for web compat reasons) or can we basically treat mixins as a purely IDL construct (similarly to partials)?

[09:51:05.0000] <tobie>
Answering my own question: "If the interface is used solely as a supplemental interface, then there will be no way to access its interface prototype object, since no object will have the interface prototype object as its internal [[Prototype]] property value. In such cases, it is an acceptable optimization for this object not to exist."

[10:11:40.0000] <tobie>
Mmm,  it seems https://heycam.github.io/webidl/#es-constants says nothing about constants defined on consequential interfaces. It that by design or is that a mistake?

[10:12:38.0000] <tobie>
(For comparison, https://heycam.github.io/webidl/#es-attributes is explicit about this: "For each exposed attribute of the interface, whether it was declared on the interface itself or one of its consequential interfaces, […]"

[10:13:04.0000] <tobie>
Domenic: ^

[10:15:04.0000] <Domenic>
tobie: seems like an oversight, although maybe the intent was you can't declare constants on our current way of doing mixins

[10:15:38.0000] <tobie>
Domenic: some do declare constants (e.g. in WebGL)

[10:15:45.0000] <Domenic>
I see

[10:15:54.0000] <tobie>
Domenic: seems like an oversight, as operations is also missing this

[10:16:13.0000] <Domenic>
I mean maybe it's just a redundant clause

[10:16:13.0000] <tobie>
(again answering my own questions, I might be getting tired)

[10:16:38.0000] <tobie>
possibly. Would be good to be consistent.

[10:16:50.0000] <tobie>
Or better to move to a more imperative style.

[10:55:25.0000] <Domenic>
+1 imperative, as always

[11:33:56.0000] <gsnedders>
what are objects that define their own [[get]], [[set]], etc. called nowadays?

[11:34:09.0000] <gsnedders>
(or, rather, objects from WebIDL that do this)

[11:58:51.0000] <tobie>
gsnedders: https://heycam.github.io/webidl/#es-legacy-platform-objects ?

[12:45:12.0000] <gsnedders>
tobie: I guess I was thinking more something along the lines of what the ES spec used to call "host objects". Is there any term still defined in ES for such things?

[12:58:28.0000] <jsbell>
gsnedders: "exotic objects"

[12:59:17.0000] <jsbell>
semantics may not be identical, tho

[12:59:29.0000] <annevk>
Not quite the same, but new system has no place for host objects

[12:59:55.0000] <annevk>
All objects need to conform to the MOP

[13:01:32.0000] <tobie>
oh, yes, exotic objects. Defined here: https://tc39.github.io/ecma262/#sec-exotic-object

[13:04:29.0000] <tobie>
I need to distinguish "mixins included by interface A" from "mixins included by interface A and by inherited interfaces of A"

[13:05:48.0000] <tobie>
what can I call these knowing that the latter one is the one most commonly used across the spec? (Corresponds to the former "Consequential interfaces of A")

[13:06:18.0000] <TabAtkins>
"own interfaces"?

[13:07:27.0000] <tobie>
TabAtkins: "own mixins" would be for the former, right?

[13:07:35.0000] <TabAtkins>
yeah

[13:07:44.0000] <tobie>
TabAtkins: and you'd call the latter just "mixins of"

[13:07:49.0000] <TabAtkins>
yup

[13:08:41.0000] <tobie>
This is a lot more straightforward than consequential interfaces. I'm not sure it's acceptable.

[13:09:10.0000] <tobie>
WebIDL needs to be obscure and complicated, dammit!

[13:09:36.0000] <tobie>
That's super helpful, TabAtkins. Thanks.

[13:12:57.0000] <TabAtkins>
^_^

[13:26:11.0000] <gsnedders>
jsbell: ahhh, thx

[13:26:21.0000] <gsnedders>
annevk: yeah,  I knew they'd been changed as part of the rename

[15:39:28.0000] <tobie>
Do callback interfaces support maplike and setlike declarations? The spec isn't clear about this.

[16:02:48.0000] <TabAtkins>
They shouldn't? They're just a legacy feature around callback functions.

[16:02:53.0000] <Domenic>
^ that