2018-07-02
[21:31:56.0000] <wfpkhc>
hello

[21:32:54.0000] <wfpkhc>
bye i will tlak later

[01:24:03.0000] <hsivonen>
annevk: should I expect to have to cherrypick a new version of WPT's IDL parser in order to have your addition of window.event to the IDL tests work?

[01:24:20.0000] <hsivonen>
just putting the IDL change in m-c breaks all WPT IDL tests

[01:24:56.0000] <SimonSapin>
are HTTP(S) documents allowed to fetch anything at all from file: URLs? Where would that be specified?

[01:30:33.0000] <hsivonen>
I see WebIDL tests including a script called /resources/WebIDLParser.js, but I don't see a file of that name in the WPT repo

[01:30:38.0000] <hsivonen>
where does it come from?

[01:31:11.0000] <hsivonen>
looks like wpt serve magically serves it

[01:34:22.0000] <hsivonen>
lots of changes between m-c and the wpt repo for /resources/idlharness.js :-(

[01:48:00.0000] <Ms2ger>
hsivonen, yeah, m-c is more than a month out of date

[01:48:14.0000] <Ms2ger>
hsivonen, but jgraham is back from vacation today

[01:49:10.0000] <Ms2ger>
hsivonen, /resources/WebIDLParser.js is in https://github.com/web-platform-tests/wpt/blob/master/resources/webidl2/lib/webidl2.js for historical reasons

[02:01:23.0000] <hsivonen>
Ms2ger: thanks

[02:41:59.0000] <hsivonen>
now attachShadow is not a function. Is that part of an old shadow DOM spec and got removed or is that part of the latest spec but isn't turned on by default in Gecko?

[02:43:30.0000] <annevk>
The latter

[02:43:33.0000] <hsivonen>
weird. dom.webcomponents.shadowdom.enabled shows up as *modified* to false

[06:16:49.0000] <mkwst>
SimonSapin: Chrome blocks `file:` from `http:`/`https:`. It falls into the exception sketched out in the `file:` bits of https://fetch.spec.whatwg.org/#scheme-fetch, that throws its hands in the air and says "Do whatever. Ugh." :)

[07:22:01.0000] <SimonSapin>
thanks mkwst

[07:22:54.0000] <Domenic>
Another unhelpful piece of the puzzle is at https://url.spec.whatwg.org/#origin

[07:23:54.0000] <SimonSapin>
(the context of this question is https://github.com/w3c/csswg-drafts/issues/2757#issuecomment-401656627)

[09:16:04.0000] <jugglinmike>
TabAtkins: Do you have a minute to talk about Bikeshed?

[10:28:14.0000] <gsnedders|ooo>
jugglinmike: he's in Sydney now, AFAIK

[10:28:38.0000] <jugglinmike>
ah, got it

[10:28:41.0000] <jugglinmike>
thanks for the heads up

[10:32:38.0000] <Domenic>
Does anyone know if Edge has a bfcache?

[11:07:41.0000] <wanderview>
Domenic: it seems to reload based on casual inspection, but I could be wrong

[11:07:54.0000] <wanderview>
or using devtools could disable it or something

[15:59:28.0000] <rniwa>
Domenic: yt?


2018-07-03
[20:10:48.0000] <rniwa>
annevk: yt?

[20:27:37.0000] <wanderview>
rniwa: annevk is on holiday for a few weeks I think

[20:35:16.0000] <annevk>
🏝

[20:37:33.0000] <rniwa>
I see.

[20:37:40.0000] <rniwa>
does anyone know about media loading?

[21:52:56.0000] <annevk>
rniwa: you want to email foolip and JakeA

[21:53:11.0000] <rniwa>
annevk: ok, thanks

[01:41:32.0000] <JakeA>
rniwa: I've been looking into this recently, but I'm about to go on holiday for a week. I'm around for the next~5 hours though

[01:41:43.0000] <rniwa>
JakeA: okay.

[01:42:21.0000] <rniwa>
JakeA

[01:42:33.0000] <rniwa>
JakeA: so we have "If a source element is inserted as a child of a media element that has no src attribute and whose networkState has the value NETWORK_EMPTY, the user agent must invoke the media element's resource selection algorithm."

[01:42:44.0000] <rniwa>
JakeA: what prevents this step from running inside a template element?

[01:44:09.0000] <JakeA>
rniwa: ah, I've been looking at it from more of a fetch perspective. For HTML integration, I guess foolip will know more.

[01:44:11.0000] <JakeA>
Sorry!

[01:44:30.0000] <JakeA>
I don't even know how template prevents img loading off the top of my head

[01:45:55.0000] <rniwa>
JakeA: ok, thanks

[01:48:33.0000] <rniwa>
JakeA

[01:48:52.0000] <rniwa>
JakeA: but surely, there is some choke point for a document without a browsing context from issuing a network request??

[01:54:34.0000] <JakeA>
rniwa: not within fetch. It looks like <script> handles this using language like "if src is changed and the script element is [=connected=]"

[01:54:45.0000] <JakeA>
I guess media should do the same

[01:54:52.0000] <rniwa>
JakeA: connected doesn't mean it doesn't lack a browsing context

[01:54:59.0000] <rniwa>
JakeA: a document may or may not have a browsing context

[01:55:39.0000] <JakeA>
rniwa: when does that occur? Bfcache?

[01:56:05.0000] <rniwa>
JakeA: or a document in XHR

[01:56:10.0000] <rniwa>
JakeA: there is a bunch of cases

[01:56:25.0000] <rniwa>
JakeA: you can have a document in iframe which navigates away from it

[01:56:53.0000] <rniwa>
there is nothing preventing from scripts to access to the document if the script previously stored a reference to it

[01:57:17.0000] <rniwa>
I guess it checks https://html.spec.whatwg.org/#concept-n-noscript

[01:57:27.0000] <rniwa>
in step 11 of https://html.spec.whatwg.org/#prepare-a-script

[02:00:29.0000] <JakeA>
rniwa: Stylesheets use https://html.spec.whatwg.org/multipage/infrastructure.html#browsing-context-connected

[02:01:59.0000] <Ms2ger>
rniwa, hmm, on first sight, it does look like the spec misses that case

[02:02:58.0000] <rniwa>
JakeA: oh neat

[02:03:21.0000] <rniwa>
Ms2ger, JakeA: it appears to me that source element's processing model doesn't really check any of that :(

[02:04:50.0000] <JakeA>
I wonder how this works for <img>, since they fetch before being connected.

[02:10:34.0000] <rniwa>
"In a browsing context where scripting is disabled, user agents may obtain images immediately or on demand. In a browsing context where scripting is enabled, user agents must obtain images immediately."

[02:10:39.0000] <rniwa>
what a vague statement...

[02:11:05.0000] <rniwa>
"A user agent that obtains images on demand must update the image data of an img element whenever it needs the image data (i.e., on demand), but only if the img element's current request's state is unavailable. When an img element has experienced relevant mutations, if the user agent only obtains images on demand, the img element's current request's state must return to unavailable."

[02:11:33.0000] <JakeA>
https://static-misc.glitch.me/dom-img-xhr/ Chrome, Firefox, & Safari fetch once the image is added to the browsing context

[02:13:12.0000] <rniwa>
JakeA: i guess we'd have to test what happens when img element is inside a template element, etc..

[02:13:38.0000] <rniwa>
JakeA: but it would be shitty if any browser fetched it since the whole point of inventing template element is not to do that

[02:13:59.0000] <JakeA>
rniwa: agreed. But I'm not really familiar with how <template> works.

[02:14:13.0000] <rniwa>
JakeA: it's just a document without a browsing context

[02:14:20.0000] <rniwa>
JakeA: what would be interesting is to figure out

[02:14:34.0000] <rniwa>
whether img is fetched inside a document which has been removed from a frame

[02:15:45.0000] <JakeA>
I think <img> is the outlier in terms of fetching before it's connected. Although IE does the same with <script> (not sure if Edge does the same)

[02:16:24.0000] <rniwa>
JakeA: yes, for historical reasons

[02:16:35.0000] <rniwa>
JakeA: img MUST fetch its resource right away

[02:16:43.0000] <rniwa>
it's the way we used to pre-fetch images...

[02:16:51.0000] <rniwa>
g'old JS1.3...

[02:17:24.0000] <rniwa>
anyhow, it's getting a bit too late for me here in Cupertino

[02:17:25.0000] <JakeA>
How else could hover effects work? 😀

[02:17:39.0000] <JakeA>
g'night!

[02:17:45.0000] <rniwa>
JakeA: anyhow, thanks!

[11:29:20.0000] <domfarolino>
annevk: We've talked a bit before about how impls should be able to discern between `null` and `undefined` for RequestInit's `AbortSignal?` member, however looking at https://heycam.github.io/webidl/#es-dictionary (step 4.1.2), it looks null/undefined are both treated the same, thus indistinguishable? Is that accurate?

[13:07:55.0000] <TimothyGu>
domfarolino: annevk is on vacation right now I think. But it does seem like null and undefined are treated the same way

[13:08:17.0000] <TimothyGu>
i.e., the dictionary member is treated as not present

[13:13:41.0000] <domfarolino>
TimothyGu: ah wasn’t sure if he was back yet. Following that logic, it seems that https://github.com/web-platform-tests/wpt/blob/master/fetch/api/abort/general.any.js#L149 shouldn’t be a valid scenario would

[13:13:56.0000] <domfarolino>
would you agree*

[13:14:51.0000] <domfarolino>
context: https://fetch.spec.whatwg.org/#dom-request step 28 & 30 wouldn’t be able to pick up a “null” AbortSignal as per WebIDL?

[13:16:22.0000] <TimothyGu>
domfarolino: I agree with you on this

[13:16:39.0000] <TimothyGu>
alternatively we could have special handling for nullable types in dictionary

[13:17:07.0000] <TimothyGu>
but that's definitely a rabbit hole that'll probably prove not worth going down

[13:19:40.0000] <TimothyGu>
It would be interesting to see how browsers actually behave in the case of this test.

[13:19:45.0000] <domfarolino>
TimothyGu: Agreed. Would that special handling probably be baked into the Request() constructor, or somewhere in the IDL perhaps? I feel like in the Request constructor it's technically too "late", since the WebIDL conversions should have taken place

[13:19:57.0000] <domfarolino>
Yeah, I've dug into FF a bit but need to look more

[13:19:58.0000] <TimothyGu>
Yeah it's gonna have to be in IDL

[13:20:05.0000] <domfarolino>
👍

[13:20:15.0000] <domfarolino>
For now I'll open an Fetch issue for discussion, ta

[13:26:40.0000] <TimothyGu>
domfarolino: interestingly Chrome's IDL codegen doesn't actually treat null as undefined

[13:26:41.0000] <TimothyGu>
https://cs.chromium.org/chromium/src/out/Debug/gen/third_party/blink/renderer/bindings/core/v8/v8_request_init.cc?gsn=ToImpl&l=258

[13:27:07.0000] <domfarolino>
That's because of a change we just made

[13:27:37.0000] <domfarolino>
So basically peria@ and I discussed that null and undefined should be distinguishable

[13:27:48.0000] <domfarolino>
However it seems that assumption was wrong

[13:27:55.0000] <Domenic>
Seems like you'd need to use any

[13:28:50.0000] <TimothyGu>
Domenic: I don't think any would either in this case actually

[13:29:02.0000] <Domenic>
Yeah, digging in...

[13:29:18.0000] <TimothyGu>
since null/undefined conversion happens before type conversion for the member

[13:29:21.0000] <domfarolino>
Right

[13:29:49.0000] <domfarolino>
For now in chrome we use any to detect, but likely our ability to distinguish null from undefined is not following WebIDL

[13:30:05.0000] <domfarolino>
s/detect/detect null

[13:33:25.0000] <Domenic>
This seems really strange... why are nullable dictionary members allowed anyway...

[13:33:39.0000] <Domenic>
s/allowed anyway/allowed anyway, if this is the case/

[13:34:20.0000] <domfarolino>
That's what I was thinking

[13:34:29.0000] <domfarolino>
hmmm

[13:34:59.0000] <Domenic>
I wonder if we broke the spec at some point

[13:35:19.0000] <Domenic>
Alternately we could try to find if any other nullable dictionary members exist. If not, maybe this is the first time we've run into it.

[13:35:43.0000] <TimothyGu>
Firefox seems to handle it correctly right now though

[13:35:45.0000] <TimothyGu>
https://searchfox.org/mozilla-central/source/__GENERATED__/dom/bindings/RequestBinding.cpp#530

[13:36:27.0000] <Domenic>
December 2016 /TR/ash spec has the same algorithm

[13:39:11.0000] <TimothyGu>
Also I'm kinda surprised making the change to distinguish between undefined and null in dictionary members didn't break any existing tests

[13:39:15.0000] <TimothyGu>
in Chrome

[13:39:30.0000] <domfarolino>
TimothyGu: Hmm I think FF breaks WebIDL spec though right? It looks like it distinguishes between null/undefined which as er #es-dictionary is incorrect

[13:40:27.0000] <domfarolino>
TimothyGu: It didn't break any changes because the change was sorta half made. `someDictionary.hasFoo()` still returns `false` when `dict.foo` is `null`, so that's maybe why

[13:40:43.0000] <TimothyGu>
domfarolino: hm what do you mean FF distinguishes between null/undefined?

[13:40:47.0000] <TimothyGu>
also ah lol

[13:43:30.0000] <domfarolino>
TimothyGu: Basically FF passes https://github.com/web-platform-tests/wpt/blob/master/fetch/api/abort/general.any.js#L149

[13:43:40.0000] <TimothyGu>
heh

[13:45:51.0000] <domfarolino>
I assume https://searchfox.org/mozilla-central/source/dom/fetch/Request.cpp#415 evals to true

[13:46:37.0000] <domfarolino>
But either way, nullable dictionary members seem pretty few and far between. I guess I'll file something on Fetch for now and maybe we can move the discussion to WebIDL?

[13:47:46.0000] <TimothyGu>
Agreed

[13:48:06.0000] <TimothyGu>
I know bz used to hack Firefox's idl codegen to check if an IDL feature is used in web platform

[13:48:21.0000] <TimothyGu>
maybe we could do the same with nullable members?

[13:48:34.0000] <Domenic>
OK false alarm everyone

[13:48:45.0000] <Domenic>
V is the dictionary

[13:48:49.0000] <Domenic>
value is the value

[13:49:06.0000] <Domenic>
So null/undefined canonicalization only happens for V

[13:49:08.0000] <Domenic>
Not for value

[13:49:24.0000] <Domenic>
(credit to bz)

[13:49:33.0000] <TimothyGu>
ah oops

[13:49:51.0000] <Domenic>
PR incoming to fix the variable names to not be stupid

[13:50:16.0000] <domfarolino>
phew

[13:50:25.0000] <domfarolino>
Thanks lol. cc me plz

[13:50:32.0000] <domfarolino>
\o/


2018-07-04
[04:36:31.0000] <smaug____>
does anyone happen to recall if there are wpt tests for form submission in shadow DOM?

[04:44:45.0000] <smaug____>
or any tests for form submission

[04:45:37.0000] <smaug____>
aha, https://searchfox.org/mozilla-central/source/testing/web-platform/tests/html/semantics/forms/form-submission-0


2018-07-05
[01:11:45.0000] <lgrahl>
Wat :)


2018-07-09
[02:20:13.0000] <haywirez>
hey, i'm new and pretty clueless so sorry for potential annoyances i might be causing... i have two main concerns at the moment, both related to the <audio>/media elements.

[02:20:28.0000] <haywirez>
1) preservesPitch - this does not seem to be in the spec, but is essential to proper creative uses and what i'm trying to make (a dj-able web player with decent scrubbing/pitching - ccan be easily accomplished by setting this flag to false). are there any reasons why this is so? i see that it's not properly implemented in Chrome even under -webkit prefix for now, but what are the downsides?

[02:20:41.0000] <haywirez>
2) playbackRate - in practice it seems to be constrained to values between 0.5 - 4. this is also undesirable, why can't they be negative and the range much wider? both seem like arbitrary constraints that are unnecessarily restrictive

[02:23:42.0000] <haywirez>
the spec says that the value should be double

[02:25:08.0000] <jochen__>
annevk: wondering whether i'm reading the URL spec correctly (or specifically, assigning to location.href)

[02:26:12.0000] <jochen__>
annevk: is my understanding correct that we'd strip leading unicode control characters, resulting in a validation error, but not a failure, and therefore continue with setting the location if the rest of the string is a correct url?

[02:26:14.0000] <deanedridge>
I think annevk is still on vacation, jochen__

[02:26:20.0000] <jochen__>
ah :/

[02:26:29.0000] <jochen__>
any other URL experts ? :)

[02:27:24.0000] <deanedridge>
Many of the WHATWG people are in the US and it's still the weekend there.

[03:26:58.0000] <kochi>
smaug____: a few tests in http://w3c-test.org/shadow-dom/untriaged/html-elements-in-shadow-trees/html-forms/

[03:30:26.0000] <kochi>
historically, most of tests under "shadow-dom/untriaged" were originally contributed from contracted vendor in v0 era.  They were converted to v1 where possible, but the coverage and the quality of the tests are quite questionable :(

[03:31:08.0000] <kochi>
Maybe we can throw them away completely.

[07:31:31.0000] <mnkk>
hi! i am a coding noob trying to query an API and therefore stumbled upon fetch API

[07:31:59.0000] <mnkk>
what I still dont get is how do i actually use fetch API to query an API?

[07:32:05.0000] <mnkk>
to i create a document?

[07:32:09.0000] <mnkk>
do i use command line?

[08:11:35.0000] <Domenic>
haywirez: preservesPitch: nobody has come up with an interoperable spec for how it works, and gotten in unprefixed. We should probably do so though, given it's implemented in a couple places. Not sure on the latest status.

[08:12:48.0000] <Domenic>
haywirez: playbackRate: in practice browsers haven't devoted the engineering resources to giving us infinitely customizable playback rates. The spec doesn't mandate that they support any playback rate in the double range; in fact UAs are supposed to throw if a range is not supported.

[08:13:45.0000] <Domenic>
jochen__: that looks correct from the current spec. You can generally test against the unofficial reference implementation at https://jsdom.github.io/whatwg-url/

[09:20:12.0000] <haywirez>
Domenic: thanks for the updates!

[14:16:45.0000] <thardin>
woop

[15:49:42.0000] <smaug____>
dtapuska: why MessageEvent would need .userActivation?

[15:52:45.0000] <smaug____>
filed an issue


2018-07-10
[02:13:30.0000] <haywirez>
would it be unreasonable to just use Firefox's .preservePitch implementation as a reference implementation?

[02:13:44.0000] <haywirez>
it works the best out of all browsers i tried

[02:14:08.0000] <Ms2ger>
We don't have reference implementations :)

[02:23:05.0000] <haywirez>
:(

[05:00:24.0000] <jochen__>
Domenic: filed https://github.com/whatwg/html/issues/3814 to track


2018-07-11
[13:20:57.0000] <jyasskin>
TabAtkins: Do you know if anyone's started a Bikeshed extension for VSCode (or another editor with compatible language definitions)?

[13:36:10.0000] <domfarolino>
^ sounds interesting

[13:39:15.0000] <Domenic>
Slight hijack: has anyone ever used a text editor that didn't rebel against you when you omitted closing tags?

[13:43:27.0000] <jyasskin>
Nope :)

[13:45:47.0000] <domfarolino>
What are you currently using, VSCode?

[13:48:07.0000] <Domenic>
Either VSCode or Sublime

[13:50:13.0000] <domfarolino>
A shame they don't react well to omitted closing tags :/

[13:57:46.0000] <Domenic>
Yeah, I'm not sure what my desired behavior would even be, but I know the current one is suboptimal....

[13:58:18.0000] <Domenic>
(Mostly the problem is around indents, although there's a few other things too depending on the editor.)

[15:45:31.0000] <domfarolino>
It’s been a while since I’ve used VSCode I need to get back on the train. But yeah that sounds annoying


2018-07-12
[05:02:00.0000] <benjamingr_>
o/

[05:02:47.0000] <benjamingr_>
Hey, if someone has overwritten `fetch` in a web page is there any way to get a reference to the original?

[05:03:11.0000] <benjamingr_>
I know I can grab it from an `iframe` but that messes with the referrer, it's not transferrable so I can't move it from the worker (I can facade it, maybe - but would rather not)

[05:08:57.0000] <Ms2ger>
benjamingr_, can you grab the function from the iframe and then do other_fetch.call(window)?

[05:09:21.0000] <Ms2ger>
Not sure if that would work

[05:09:32.0000] <benjamingr_>
That would mess with the referrer header

[05:10:09.0000] <Ms2ger>
Then your only option is to beat whatever code is overwriting it to the punch

[05:11:03.0000] <benjamingr_>
Can't, other ideas welcome

[05:12:30.0000] <Ms2ger>
I don't think there's any

[05:12:40.0000] <Ms2ger>
Maybe Domenic has some

[05:13:19.0000] <benjamingr_>
Domenic is/was working on a getOriginals which would have solved this for me anyway - but that's still a long way away afaik

[06:33:42.0000] <Domenic>
That shouldn't mess with the referrer if you use . call

[06:33:50.0000] <benjamingr_>
Ah, interesting, why?

[06:34:02.0000] <Domenic>
/me is unsure what benjamingr_ thinks of as "long"

[06:34:11.0000] <Domenic>
It uses the this value to compute things

[06:34:22.0000] <benjamingr_>
Ah, fabulous, I had no idea - thanks

[06:34:52.0000] <benjamingr_>
"long" - not something I can use in a PoC I want to do "just so it's cool" in the next 2-3 months.

[06:35:50.0000] <Domenic>
Yeah 2-3 months is a tight constraint

[06:36:31.0000] <benjamingr_>
+ not one you should or would be interested in fulfilling just for my PoC :D

[06:46:15.0000] <benjamingr_>
It's a little surprising to me since I'd expect `fetch(url)` to behave similarly to `fetch.call(window, url)` since either fetch is unbound (which means it gets `window` by default as context in loose mode) or it is bound in which case I don't understand why `.call` sets its this.

[06:46:15.0000] <benjamingr_>
What am I missing Domenic?

[06:50:28.0000] <Domenic>
I don't understand the confusion. It's unbound. Which means you can change its this value with .call. but the default this value is indeed window. No contradiction.

[06:51:25.0000] <Domenic>
Notice that Ms2ger is specifically suggesting using otherFetch.call(window), to change the this value of otherFetch.

[06:58:17.0000] <benjamingr_>
https://www.irccloud.com/pastebin/qw9X1cpj/

[06:59:37.0000] <benjamingr_>
"No contradiction." - I don't understand that part - it's unbound, the default value is indeed window, but when `.call`ing it and setting it explicitly to `window` it sets the referrer.

[07:05:33.0000] <wanderview>
benjamingr_: do you get the same behavior in different browsers?

[07:06:54.0000] <benjamingr_>
I haven't tested. I'm 95% convinced that this is the fact I've been sick myself and dealing with a sick relative and that there is a reasonable reason for this like me not understanding `this` for APIs across contexts. I'll check

[07:08:17.0000] <Ms2ger>
I think it's at least as likely that some browsers use the wrong object

[07:08:23.0000] <benjamingr_>
wanderview - Firefox sends the referrer anyway.

[07:09:45.0000] <benjamingr_>
So Firefox and Chrome behave differently and Chrome's behavior deviates from my understanding of how `this` works in JavaScript. The problem is that I still don't know if I should open a crbug or bugzilla.

[07:17:42.0000] <wanderview>
benjamingr_:  I don't see a WPT test for this, but maybe I'm just not finding it...

[07:19:11.0000] <benjamingr_>
I think I'll look into it some more and open an issue in the `fetch` repo, I still believe this is just sleep deprivation so I'm hesitant to spend more of other peoples' time

[07:20:08.0000] <wanderview>
sounds reasonable... thanks!  (and I hope you and your relative feel better)

[07:21:00.0000] <benjamingr_>
I guess if `fetch` itself is in strict mode it can explicitly check the `.call` value and differentiate but still confusing. Thanks for helping - I will update!

[07:21:17.0000] <Domenic>
Imagine the following code: `otherWindow.fetch = (...args) => { const referrerToUse = this.document.URL; }`

[07:21:33.0000] <Domenic>
Then if you do `otherWindow.fetch(...)` it will use `otherWindow.document.URL` as the referrer

[07:21:49.0000] <Domenic>
But if you do `otherWindow.fetch.call(window, ...)` it will use `window.document.URL` as the referrer

[07:22:20.0000] <Domenic>
Thus, if you want to get a "clean" copy of fetch (i.e. `otherWindow.fetch`), but have it use the "normal" referrer as if you were using "normal" `window.fetch()`, it suffices to just do `otherWindow.fetch.call(window, ...)`

[07:22:59.0000] <benjamingr_>
I think I understand what I was missing - if I grab a function from another context then when invoking it the `this` value is set to the global object _of that realm_ rather than the one I'm in - that should have been obvious. Thanks Domenic!

[07:25:58.0000] <Ms2ger>
Domenic, how about let f = otherWindow.fetch; f()?

[07:30:14.0000] <benjamingr_>
Ms2ger: when you call `f` there it calls it with `otherWindow` as the `this` since that's the global of its environment

[07:30:53.0000] <Domenic>
No... that's not how this works.

[07:31:41.0000] <Domenic>
It'll call it with undefined as this. Which per Web IDL gets converted to `window`, I am pretty sure.

[07:32:39.0000] <Domenic>
Oh nope, per Web IDL it gets converted to `otherWindow`, it looks like.

[07:32:54.0000] <Domenic>
https://heycam.github.io/webidl/#dfn-create-operation-function 2.1.2.1

[07:33:29.0000] <Domenic>
`window` wouldn't have made sense anyway, nevermind. +1 benjamingr_.

[07:35:14.0000] <wanderview>
so does any browser dtrt?

[07:36:29.0000] <benjamingr_>
Well - Firefox is behaving differently by sending `Referrer` from an iframe when Chrome doesn't. Personally I like Chrome's behaviour better as a default and the only reason I need this "hack" is that there is nothing like `getOriginals` in the browser yet.

[07:37:13.0000] <benjamingr_>
Other things that would have helped - `fetch` being transferable, `ReadableStream` being transferable (that'd make the shim easy). They're both 'hacks' for what I really want (a clean reference I can rely on).

[12:38:06.0000] <TimothyGu>
benjamingr_: hmm, so what was the conclusion here? tbh I don't see anything in the spec for fetch() I'm reading that uses the `this` object in anyway

[12:39:02.0000] <TimothyGu>
The place where the referrer header gets set is step 2 in https://fetch.spec.whatwg.org/#dom-global-fetch, with the implication that "initial value of Request" refers to that in the realm for which this fetch() function was created

[12:39:14.0000] <benjamingr_>
Well, two things - first: Firefox and Chrome behave differently regarding the `Referer` header in iframes.

[12:39:54.0000] <TimothyGu>
Step 13 in https://fetch.spec.whatwg.org/#dom-request says the "current settings object" is used, which for fetch() means that of the realm it was created for

[12:39:58.0000] <TimothyGu>
Interesting

[12:40:06.0000] <benjamingr_>
Second, Chrome's `this` behaves differently than I expect in `fetch` (and not in accordance to which the `fetch` function was created). I really like this behaviour but only because it's the only way I have to get a safe `fetch` as an SDK

[12:40:44.0000] <TimothyGu>
I see...

[12:42:01.0000] <benjamingr_>
I'd expect a same origin iframe without a `src` set to send XHR and fetch exactly the same way as the parent document - but that's unrelated. Chrome doing Firefox's behavior would be great. Otherwise I'd have to grab `fetch` from a worker and since neither `ReadableStream` nor `fetch` itself is transferable that's quite a bit of work.

[12:43:42.0000] <TimothyGu>
Yeah, but having to create a whole new iframe just for a fetch() method (which prevents the iframe from being GC'd) is not that great

[12:44:05.0000] <TimothyGu>
If Firefox's fetch is bound to the window it was created for, I think that's the right behavior here

[12:45:29.0000] <benjamingr_>
Domenic posted a spec link explaining why it isn't IIRC

[12:45:47.0000] <benjamingr_>
Something about 2.1.2.1 https://heycam.github.io/webidl/#dfn-create-operation-function

[12:46:12.0000] <TimothyGu>
Yeah that has to do with how the `this` value is set

[12:46:30.0000] <TimothyGu>
But `fetch` doesn't (or shouldn't) use the `this` value at all

[12:46:45.0000] <Domenic>
Blargh

[12:46:56.0000] <Domenic>
I didn't actually check the spec, I just assumed it used the relevant global, because that's the guidance these days

[12:47:14.0000] <Domenic>
But TimothyGu's right that the behavior seems to happen implicitly in "the initial value of Request"

[12:47:40.0000] <Domenic>
So I think it should still be relevant (= realm of this) due to https://github.com/heycam/webidl/issues/135

[12:47:45.0000] <Domenic>
But it's borderline

[12:48:24.0000] <Domenic>
"invoking the initial value of the Response constructor" is different from what 135 is talking about, which is "a new Request object"

[12:48:45.0000] <Domenic>
It'd be hard to argue that the spec is clear  here and any browser is specifically wrong

[12:52:01.0000] <benjamingr_>
I'm not sure Firefox behaves differently, just that it sends the `Referer` header anyway

[12:52:41.0000] <benjamingr_>
Any suggestions on how to check this welcome as the differing behavior in Chrome between `fetch` and `fetch.call(window` doesn't exist on Firefox as far as I know.

[13:01:46.0000] <Domenic>
Filed https://github.com/whatwg/fetch/issues/777

[13:02:17.0000] <Domenic>
It does seem like for practical purposes you may be in trouble here

[13:02:30.0000] <Domenic>
Even if in theory the spec gives you the tools you want


2018-07-13
[08:25:18.0000] <smaug____>
implementing unspec'ed stuff never stops amaze me

[08:25:29.0000] <smaug____>
(especially when that happens in several implementations)


2018-07-16
[05:26:14.0000] <jgraham>
annevk: Are you still on PTO?

[06:22:15.0000] <annevk>
jgraham: back Thursday-ish

[06:26:21.0000] <jgraham>
annevk: OK, have a good time/flight/jetlag recovery/etc.

[07:01:56.0000] <annevk>
Yeah, it's gonna be bad


2018-07-18
[07:55:57.0000] <lgrahl>
o/

[07:55:59.0000] <lgrahl>
I was just wondering... we still have no BYOB for writable streams, right? Is there a specific reason for that or just lack of interest? :)

[14:51:33.0000] <Domenic>
lgrahl: not quite sure what the design should be I think. Especially if we can combine BYOB readable + writable and then can we do transforms too? Also lack of implementations on BYOB readable streams is a bit demotivating.

[14:57:23.0000] <Domenic>
lgrahl: old brainstorming thread https://github.com/whatwg/streams/issues/495

[14:57:47.0000] <Domenic>
Ah I see you found it a while ago

[15:01:09.0000] <lgrahl>
Oh, did I...

[15:02:24.0000] <lgrahl>
Well, lack of implementations might be improved by more other specs using streams. Maybe the data channel streams extensions will help.

[16:36:40.0000] <Domenic>
I hope so :)

[16:37:06.0000] <Domenic>
New topic: wow, Firefox has still gotten away with not implementing the mousewheel event. I wonder if we can remove it from other browsers?

[16:37:32.0000] <Domenic>
I was filing an issue to standardize https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/dom/events/event_target.cc?l=252&rcl=37b6757f5f82d379b43903728641081141f94217 but then I realized it only applies to the apparently-nonstandard mousewheel event.


2018-07-19
[05:15:32.0000] <gsnedders|ooo>
I'd like to see some document of principles on specification. Like, "what do we do when we have complex behaviour that isn't interoperable but we don't expect to become interoperable in the short to medium term"

[05:16:48.0000] <gsnedders|ooo>
Because normally we'd revert new features if they didn't get implementation traction to stop the spec from being a lie, but when they're implemented everywhere but not interoperable it's much less clear.

[15:40:11.0000] <Alystair>
Who do I bribe to get an RFC for a CSS :visible pesudo-class, so one could do something like :visible:last-child without the assistance of JS?

[15:41:20.0000] <Alystair>
I have cake, and pie.

[15:44:35.0000] <TabAtkins>
Unfortunately, the laws of logic.

[15:46:04.0000] <TabAtkins>
Alystair: https://wiki.csswg.org/faq#selectors-that-depend-on-layout, but sub "depends on styling" in for "depends on layout".

[15:47:25.0000] <Alystair>
dang

[15:49:37.0000] <Alystair>
I guess that explains why :hover can create a repaint loop in some circumstances if you position your mouse just right :p

[15:50:56.0000] <TabAtkins>
Yup.

[15:51:25.0000] <TabAtkins>
Theoretically we could offer it in the snapshot profile, so querySelector() could use it, but that's it.


2018-07-21
[18:13:42.0000] <wfpkhc>
hello

[18:13:51.0000] <wfpkhc>
i have a questino about the whatwg standard

[18:14:00.0000] <wfpkhc>
anyone round?

[18:14:45.0000] <wfpkhc>
https://html.spec.whatwg.org/multipage/forms.html#the-form-element

[18:14:45.0000] <wfpkhc>
https://html.spec.whatwg.org/multipage/input.html#the-input-element

[18:14:45.0000] <wfpkhc>
the attribute novalidate and noformvalidate

[18:14:45.0000] <wfpkhc>
seems to be incorrectly described

[18:14:59.0000] <wfpkhc>
the form has "novalidate" while the element has "noformvalidate" - has that changed?

[18:15:10.0000] <wfpkhc>
since the first version of html5?

[18:15:19.0000] <wfpkhc>
(well first draft anway)

[18:18:52.0000] <wfpkhc>
hmmmmmmmm

[18:18:52.0000] <wfpkhc>
i should learn to spell and use better grammar :P

[18:21:23.0000] <wfpkhc>
/me #php

[18:21:24.0000] <wfpkhc>
hmm thats strange - i cannot seem to change channel


2018-07-23
[17:24:41.0000] <devsnek>
where does the fetch spec sit in relation to reading and writing bytes over a tcp socket

[17:45:57.0000] <Domenic>
two levels above that

[18:00:28.0000] <devsnek>
tfw you click on "handle fetch" and now you have to think about service workers

[18:07:15.0000] <TimothyGu>
devsnek: is this related in anyway to zero

[18:07:23.0000] <devsnek>
TimothyGu: yes

[18:07:29.0000] <TimothyGu>
ah

[18:07:43.0000] <devsnek>
i have a socket binding

[18:07:47.0000] <devsnek>
just need to plug fetch into it

[18:07:50.0000] <devsnek>
but this spec is spaghetti

[18:08:23.0000] <devsnek>
i've gone through like 5 different "concept fetch" algorithms and i still haven't found where an actual network request happens

[18:08:58.0000] <TimothyGu>
ah yeah

[18:09:09.0000] <devsnek>
hmmm here we go "concept-http-network-fetch"

[18:09:22.0000] <devsnek>
so all fetch requests are pooled with keepalive

[18:12:35.0000] <TimothyGu>
devsnek: btw I'd heavily recommend using node-fetch as a guide

[18:12:36.0000] <devsnek>
this API is just so enormous 😓

[18:12:44.0000] <devsnek>
I looked at it

[18:13:11.0000] <devsnek>
would be a good guide if I had an existing http interface

[18:13:16.0000] <devsnek>
but I'm going from scratch

[18:13:46.0000] <TimothyGu>
still

[18:14:02.0000] <TimothyGu>
 you can kind of see what steps are required

[18:14:13.0000] <TimothyGu>
up to you ofc

[18:14:35.0000] <devsnek>
yeah I've looked through it a few times

[18:14:46.0000] <devsnek>
believe me I'm trying to take every shortcut I can

[00:00:05.0000] <zewt>
bluh, browsers sure don't like nesting hover transitions inside scroll-behavior: smooth

[00:09:13.0000] <zewt>
man, smooth scrolling is nasty

[00:09:32.0000] <zewt>
doesn't even send mouseover events until it stops completely

[00:09:57.0000] <zewt>
smells like ancient optimizations that just make a mess of things now

[00:11:46.0000] <zewt>
and chrome doesn't send them at all until the mouse moves

[12:34:22.0000] <TimothyGu>
Are commit snapshots available for the HTML spec?

[13:43:32.0000] <Domenic>
TimothyGu: yeah, /commit-snapshots/

[13:43:43.0000] <Domenic>
MikeSmith: highlighter is not working on Ci despite my best efforts :-/. https://travis-ci.org/whatwg/html/jobs/407320112#L2920

[13:44:19.0000] <TimothyGu>
Domenic: heh ok

[13:44:24.0000] <TimothyGu>
Also, is there a way to get a reference to a document that's not in the origin of the current window?

[13:44:41.0000] <Domenic>
You can get documents that are cross-origin but not ones that are cross-origin-domain

[13:44:48.0000] <Domenic>
Basically, use document.domain

[13:47:41.0000] <Domenic>
Hmm IDL highlighting is working though

[13:50:33.0000] <Domenic>
MikeSmith: but non-Web IDL blocks have gotten their contents stripped to zero

[13:50:39.0000] <Domenic>
s/zero/empty string

[13:51:52.0000] <TimothyGu>
Domenic: I'm trying to use document.domain to get around the port restriction

[13:51:59.0000] <TimothyGu>
As the warning says "as the ports are ignored when comparing origins after the document.domain attribute has been used"

[13:52:08.0000] <Domenic>
yeah that should work

[13:52:11.0000] <TimothyGu>
But I haven't been able to do that

[13:52:15.0000] <Domenic>
Both pages need to set document.domain

[13:53:00.0000] <TimothyGu>
Yeah I'm doing that

[13:53:07.0000] <TimothyGu>
I'm also using localhost for testing

[13:53:13.0000] <TimothyGu>
Maybe that's part of the reason?

[13:54:44.0000] <TimothyGu>
specifically, I don't see how the effect of the port is cancelled out in domain's setter: https://html.spec.whatwg.org/#dom-document-domain

[13:58:00.0000] <Domenic>
It sets the domain component. And all same-origin-domain checks (including property access) only compare domain

[13:58:09.0000] <Domenic>
https://html.spec.whatwg.org/#same-origin-domain

[13:58:15.0000] <TimothyGu>
jk I got it

[13:58:33.0000] <Domenic>
\o/

[14:33:45.0000] <Domenic>
If anyone understands how Python include paths works and wants to help debug... https://github.com/whatwg/html-build/issues/169

[14:41:34.0000] <TimothyGu>
annevk / Domenic: thoughts on what to do for https://github.com/whatwg/html/issues/3836? Haven't tested Edge yet, but aligning with three browsers sounds fine to me

[14:42:28.0000] <Domenic>
TimothyGu: agreed!

[14:43:10.0000] <jgraham>
Domenic: No idea what you are doing there, but if you're hacking PYTHONPATH something has gone wrong

[14:43:37.0000] <jgraham>
Pretty sure you want to be running pip install on pygments at some point, which I don't see in your revert

[14:43:45.0000] <Domenic>
jgraham: yeah that was my impression

[14:43:49.0000] <TabAtkins>
No he doesn't. I've already diagnosed the error.

[14:43:52.0000] <jgraham>
But like I say I don't know what the overall setup is here

[14:43:59.0000] <TabAtkins>
(It's a bug on Pygments' part, but I can fix it locally.)

[14:44:02.0000] <Domenic>
jgraham: pygments is bundled somewhere

[14:44:57.0000] <TabAtkins>
(The bug you're running into: https://bitbucket.org/birkenfeld/pygments-main/issues/1448/pygments-relies-on-global-imports-of-its)

[14:45:04.0000] <Domenic>
Maybe it expects to be pip installed but in our setup it's bundled so this causes issues?

[14:45:24.0000] <TabAtkins>
Domenic: You... you can see my messages, right?

[14:45:35.0000] <Domenic>
Sorta, on a train so laggy :)

[14:45:40.0000] <TabAtkins>
Ah, kk. ^_^

[14:45:42.0000] <Domenic>
Thanks for the diagnosing

[14:46:27.0000] <jgraham>
TabAtkins: Seems like in a docker image just doing a global install is the fast path to the solution

[14:46:31.0000] <jgraham>
Anyway sleep

[14:46:43.0000] <TabAtkins>
jgraham: That doesn't help everyone else who might use this package. ^_^

[14:47:00.0000] <TabAtkins>
And Domenic already has a fast-path fix for right now.

[14:51:59.0000] <Domenic>
It does seem like the ecosystem is built on the assumption of global installs with pip, patched over with virtualenv or something. So when you want to do local installs manually a lot of code breaks.

[14:57:16.0000] <TabAtkins>
Yeah, but that's clumsy and terrible, and I really want a pure-local install for this. So I'm fixing it.

[14:57:29.0000] <TabAtkins>
The bug is marked "Major" in their bug tracker, so maybe they'll actually fix it themselves.

[15:27:14.0000] <MikeSmith>
Domenic: sorry about the build breakage

[15:28:16.0000] <MikeSmith>
well, spec breakage actually

[15:29:06.0000] <MikeSmith>
I need to figure out why the code isn’t working that I wrote for falling back to the source contents when the hightlighter fails

[15:33:30.0000] <MikeSmith>
hmm, I can’t reproduce the problem locally, even though I now have Pygments uninstalled (so it should just be using the Pygments copy from the highlighter submodule)

[15:47:38.0000] <MikeSmith>
nm, managed to reproduce it

[15:48:46.0000] <TabAtkins>
I've documented the problem in the README for now, with the obvious workaround (install Pygments globally) until I get it fixed.

[15:48:56.0000] <MikeSmith>
ok cool

[15:51:51.0000] <MikeSmith>
hmm, but even though I now have the highlighter failing in my environment too, my code for falling back to the source still works. I don’t get any empty <pre>s. Instead I just get the original <pre> contents (unhighlighted)


2018-07-24
[19:20:47.0000] <Domenic>
MikeSmith: so the problem with setting PYTHONPATH is that it then modifies the user's system forever.

[19:20:55.0000] <Domenic>
I'm trying to use sys.path.append in the python instead but no go...

[19:22:36.0000] <MikeSmith>
Domenic: hmm yeah I guess we may need to wait for TabAtkins’ fix then

[19:23:15.0000] <MikeSmith>
though well we could have the build script save the original PYTHONPATH value and then just restore it to that after

[19:28:00.0000] <Domenic>
Yeah...

[19:28:29.0000] <Domenic>
I tried just doing PYTHONPATH=... wattsi but it doesn't get passed down into the child python process

[19:29:18.0000] <Domenic>
Oh wait

[19:29:24.0000] <Domenic>
I seem to have forgotten how export works

[19:29:25.0000] <MikeSmith>
right yeah it must be exported for that tow roik

[19:29:32.0000] <Domenic>
It will only be for the duration of the script

[19:29:37.0000] <Domenic>
It only is global if you source the script

[19:29:49.0000] <MikeSmith>
ah yeah sure

[19:29:57.0000] <MikeSmith>
right

[19:31:42.0000] <Domenic>
Hmm but on this computer I can't get the PYTHONPATH fix to work either -_-

[19:35:40.0000] <MikeSmith>
I’ve also not gotten it working in my MacOS environment either

[19:36:10.0000] <MikeSmith>
I’m trying to figure out right now what specifically is failing and why

[19:41:00.0000] <TabAtkins>
Rather than messing around with paths, maybe just `pip install pygments` on the CI for now?

[19:44:15.0000] <Domenic>
TabAtkins: well it'd be nice if it worked for people building locally too

[20:08:34.0000] <MikeSmith>
Domenic: OK re-tested and exporting PYTHONPATH in build.sh is working as expected for me in my environment

[20:08:47.0000] <MikeSmith>
you want to PR it you want me to?

[20:20:17.0000] <Domenic>
MikeSmith: yeah that'd be great, and I'll test on my machine in an hour or two

[20:29:55.0000] <MikeSmith>
OK

[20:35:01.0000] <TimothyGu>
Domenic: are you not on a plane?

[20:35:29.0000] <Domenic>
TimothyGu: nope, tomorrow morning

[20:35:37.0000] <TimothyGu>
ah heh

[20:37:40.0000] <MikeSmith>
TimothyGu: so you’re working full-time at Google now?

[20:38:01.0000] <TimothyGu>
nope, just interning

[20:38:30.0000] <MikeSmith>
ah OK

[21:47:53.0000] <Domenic>
MikeSmith: sorry, did you figure out the pythonpath thing? I didn't see a PR, but looking back I guess I wasn't clear that I was suggesting you do it :)

[21:48:12.0000] <MikeSmith>
Domenic: I didn’t raise it yet

[21:48:20.0000] <MikeSmith>
but I will right now

[21:48:41.0000] <MikeSmith>
in further testing I found another problem that the pre->code change regressed

[21:48:56.0000] <MikeSmith>
all the included examples no longer actually get included

[21:49:14.0000] <MikeSmith>
because the regex in the perl script needs to be updated to account for that change

[21:49:24.0000] <Domenic>
Ah eek

[21:50:33.0000] <MikeSmith>
yeah see https://html.spec.whatwg.org/multipage/canvas.html#examples:the-canvas-element for instance

[21:50:55.0000] <MikeSmith>
anyway it should be easy to fix the perl script for that

[21:51:04.0000] <MikeSmith>
will do it after the build fix

[21:56:02.0000] <MikeSmith>
Domenic: oh but for the Docker files we don’t need/want to set the PYTHONPATH now? Because you updated those to pip install pygments?

[21:56:28.0000] <MikeSmith>
we want to keep it that way?

[21:57:36.0000] <MikeSmith>
I guess a downside of that would be, CI would be using a different Pygments than the local build

[21:59:21.0000] <MikeSmith>
so if/when TabAtkins makes changes/fixes to the highlighter Pygments copy, we could end up with the CI behavior being different, or even not having necessary fixes

[22:02:50.0000] <Domenic>
MikeSmith: no I didn't update those. I'm hoping that since docker uses build.sh any changes you make there will work also

[22:05:12.0000] <MikeSmith>
Domenic: so we want to keep the https://github.com/whatwg/html-build/commit/349edd8c21b3350e96b857ee75f24493089c2a7c change?

[22:05:17.0000] <MikeSmith>
= Install Python in Docker

[22:05:46.0000] <Domenic>
Ah yeah, that's necessary

[22:06:18.0000] <Domenic>
Basically revert the revert commit + whatever PYTHONPATH magic in build.sh fixes things

[22:14:09.0000] <Domenic>
hmm gotta get a couple hours sleep, back in a bit

[01:35:14.0000] <Domenic>
MikeSmith: seems to have worked. Some missing classes in the source code I guess, e.g. for https://html.spec.whatwg.org/multipage/workers.html#introduction-14 but the rest is working. I can try to PR later.

[01:35:54.0000] <MikeSmith>
Domenic: w00t

[01:35:57.0000] <MikeSmith>
thanks much

[01:36:25.0000] <MikeSmith>
dunno how we can audit those missing-classes cases

[01:36:27.0000] <Domenic>
No, thank you... A long journey, but pretty great results

[01:36:57.0000] <MikeSmith>
yeah, glad it actually ended up working, and performantly

[01:37:33.0000] <MikeSmith>
I’m (re)fixing the demos-examples include thing right now

[01:40:16.0000] <MikeSmith>
...and ready https://github.com/whatwg/html-build/pull/173

[01:41:14.0000] <Domenic>
Thanks, in a cab at the moment, but will test soon

[01:42:00.0000] <MikeSmith>
k

[01:42:09.0000] <MikeSmith>
/me heads off to cook dinner

[09:13:30.0000] <dtapuska>
should someone update the html-build readme? I wasn't aware my build was failing because of the new highlighter submodule so I had to go and init it and pull it to fix my build

[09:17:49.0000] <Domenic>
Ugggh that was supposed to be optional

[09:18:07.0000] <Domenic>
Like it would just detect the submodule absence and still work

[09:18:20.0000] <Domenic>
File an issue to make it so and we'll do that?

[09:18:58.0000] <Domenic>
After you inited it, things just worked though? That's good.

[09:19:02.0000] <dtapuska>
Ya the build fails horribly in the the highlighter isn't there

[09:19:05.0000] <Domenic>
I suppose we could make the script init for you, too.

[09:20:43.0000] <dtapuska>
ya essentially; cd highligher && git submodule init && git submodule update

[09:24:59.0000] <dtapuska>
Created https://github.com/whatwg/html-build/issues/174

[09:49:10.0000] <MikeSmith>
my bad

[09:58:15.0000] <MikeSmith>
https://github.com/whatwg/html-build/pull/175

[14:44:43.0000] <TimothyGu>
MikeSmith: dtapuska: is it normal? https://travis-ci.org/whatwg/html/builds/407814639

[14:44:52.0000] <MikeSmith>
/me looks

[14:44:57.0000] <TimothyGu>
Tried restarting

[14:45:33.0000] <TimothyGu>
it was some kind of socket error

[14:45:38.0000] <MikeSmith>
OK, watching the log now

[14:47:01.0000] <TimothyGu>
yup there it is

[14:47:15.0000] <MikeSmith>
yup

[14:47:37.0000] <MikeSmith>
yeah that indicates it didn’t init the highlighter submodule

[14:47:51.0000] <MikeSmith>
you’re rebased against current master?

[14:47:54.0000] <MikeSmith>
on that branch

[14:49:05.0000] <TimothyGu>
hm let me try

[14:49:14.0000] <MikeSmith>
from https://github.com/whatwg/html/pull/3850 it seems you’re not rebased yet

[14:49:21.0000] <MikeSmith>
> TimothyGu added some commits 17 hours ago

[14:49:39.0000] <TimothyGu>
okay done

[14:49:43.0000] <TimothyGu>
lets see

[14:50:12.0000] <MikeSmith>
/me watches along again

[14:53:00.0000] <Domenic>
Rebasing whatwg/html shouldn't be necessary...

[14:53:36.0000] <Domenic>
This may be my fault: https://github.com/whatwg/html-build/commit/e1b191ce4d18f520795242c12359f6bed3182092

[14:54:06.0000] <MikeSmith>
yeah it’s still failing

[14:54:19.0000] <Domenic>
Probably should revert that... and stop making untested changes.

[14:54:37.0000] <MikeSmith>
:) yeah seems it wasn’t redundant

[14:59:07.0000] <Domenic>
MikeSmith: TimothyGu: reverted. I'll work on actual CI for html-build now...

[14:59:29.0000] <TimothyGu>
restarted

[15:00:01.0000] <MikeSmith>
I should do confession and penance for every time I introduce a submodule depedency anywhere

[15:00:13.0000] <MikeSmith>
/me re-watches the CI build

[15:04:09.0000] <MikeSmith>
victory

[15:04:39.0000] <TimothyGu>
yay

[15:06:25.0000] <Domenic>
https://github.com/whatwg/html-build/pull/176

[15:06:30.0000] <Domenic>
To put a stop to this madness

[15:07:33.0000] <TimothyGu>
Also, we probably want all the static resources like html-dfn.js on whatpr.org, no?

[15:08:49.0000] <Domenic>
Yeah whatpr.org needs to do the full html-build instead of just wattsi

[15:08:58.0000] <Domenic>
https://github.com/whatwg/html-build/issues/156

[15:09:11.0000] <MikeSmith>
/me looks

[15:09:31.0000] <TimothyGu>
ah

[15:09:38.0000] <Domenic>
Basically I have an old issue to convert wattsi-server into html-build-server

[15:10:40.0000] <TimothyGu>
Domenic: get an intern to do it for you ;)

[15:12:23.0000] <TimothyGu>
Also https://whatpr.org/html/3850/webappapis.html#event-handler-attributes could use some heavy editorial review. The whole expose vs. specify distinction is quite irritating and I tried to make it clearer by "redirect" but it doesn't help much it seems

[15:15:43.0000] <Domenic>
Oh this looks fun

[15:20:55.0000] <Domenic>
TimothyGu: it seems like you need a concept to encapsulate "Let eventTarget be the EventTarget object for which the corresponding event handler is specified. If such an object does not exist, then return."

[15:21:09.0000] <TimothyGu>
Yeah precisely

[15:21:15.0000] <TimothyGu>
I want to be able to link "specified"

[15:21:40.0000] <Domenic>
Trying to figure out what the inputs are... output is an EventTarget I guess

[15:22:04.0000] <TimothyGu>
inputs are an EventTarget and a string (the name of the event handler)

[15:22:30.0000] <TimothyGu>
output is usually the input EventTarget, but not for body element

[15:22:39.0000] <TimothyGu>
and some event handlers

[15:22:49.0000] <Domenic>
OK. Then yeah, define something like "event handler target", and an algorithm (?) for deriving that from the input EventTarget and string?

[15:23:00.0000] <Domenic>
That algorithm may involve looking at some of the spec tables?

[15:23:24.0000] <TimothyGu>
hmm

[15:23:28.0000] <TimothyGu>
target

[15:24:16.0000] <Domenic>
Gosh this is a big rewrite

[15:24:25.0000] <TimothyGu>
Yes

[15:25:02.0000] <TimothyGu>
Specifically here's the part the "target" concept/algorithm should capture

[15:25:11.0000] <TimothyGu>
The body element exposes as event handler content attributes a number of the event handlers of the Window object. It also mirrors their event handler IDL attributes.

[15:25:11.0000] <TimothyGu>
The onblur, onerror, onfocus, onload, onresize, and onscroll event handlers of the Window object, exposed on the body element, replace the generic event handlers with the same names normally supported by HTML elements.

[15:26:07.0000] <TimothyGu>
The biggest thing was probably the switch to attribute change steps, as well as the new activate + deactivate algorithms

[15:27:21.0000] <Domenic>
Yeah agreed trying to figure out the counterpart to activate/deactivate in the old text

[15:27:42.0000] <TimothyGu>
deactivate didn't really exist

[15:28:00.0000] <TimothyGu>
That's what https://github.com/whatwg/html/issues/3836 is for

[15:28:19.0000] <TimothyGu>
Activate used to be "When an event handler H of an EventTarget object T is first set to a non-null value"

[15:28:24.0000] <Domenic>
TimothyGu: seems like onafterprint and the rest of the table following those you list also have a similar thing

[15:29:34.0000] <TimothyGu>
ah yeah I guess all of WindowEventHandlers

[15:30:34.0000] <Domenic>
So I think an algorithm, probably where one of the steps is "appears in table X's first column or table Y's first column" would be good. It would make it explicit that this body/window thing is an exception.

[15:32:13.0000] <Domenic>
Hmm the algorithm doesn't help clarify this situation much though: "When an EventTarget object that has one or more event handlers specified is created, its event handler map must be initialized such that it contains an entry for each event handler specified on that object."

[15:33:55.0000] <TimothyGu>
btw the .XXX box is wrong. it's not true for content attributes that contain invalid JS. it's a reminder for me to fix it

[15:34:55.0000] <Domenic>
I wonder if we could separate out all the event handler content attribute stuff

[15:34:58.0000] <Domenic>
OK time to pay attention to TC39

[16:56:36.0000] <sangwhan>
Curious question which popped up during the TAG F2F, has there been any plans/work on a image decoder/encoder API?


2018-07-25
[17:00:57.0000] <gsnedders|ooo>
sangwhan: I mean that would essentially be something you could do with canvas already, no?

[17:02:28.0000] <sangwhan>
gsnedders|ooo: to some extent, it's a bit roundabout and wouldn't work from a SW though. :-(

[17:02:46.0000] <Domenic>
sangwhan: bytes <-> pixel arrays, you mean? A lot of people want it; seems like a nice idea; no strong drivers to cause any implementers to actually spend resources, though.

[17:04:14.0000] <sangwhan>
Domenic: Yes, bytes<->object(with or without raw raster access) or also video I guess. I think it would be something worth iterating as a layered API first.

[02:45:26.0000] <KevinMarks>
Someone uploaded an SVG file that crashes any browser that tries to render it to svgshare.com - I'd like to file browser/spec bugs about it, but I'm not sure how best to do so as any process previewing it is going to run out of RAM and die.

[02:45:57.0000] <KevinMarks>
What's best practice here?

[02:51:30.0000] <ondras>
when you open the SVG with a file editor, do you see any obvious reason why the RAM runs out?

[02:51:39.0000] <ondras>
i.e. is the file size 100GB or similar? :)

[03:05:08.0000] <KevinMarks>
It builds a fractal by recursively transforming a rectangle. The file is 13k, but its effectively a transform fork bomb.

[03:14:26.0000] <ondras>
I see

[03:15:16.0000] <ondras>
well I suppose that other image formats are able to crash the renderer stuff as well (jpegs of billion X billion pixel sizes etc)

[03:15:36.0000] <ondras>
so to me this does not really sound like a spec/browser bug, or at least not specific to this one case

[03:16:24.0000] <ondras>
apparently this cannot be fixed by inspecting the file prior to rendering

[03:17:32.0000] <ondras>
so your best bet would be to submit the problematic file to all afflicted renderers and propose they fail in a more graceful fashion

[03:18:49.0000] <KevinMarks>
It's a tricky one, in that you need to pay attention to recursion depth. I assume postscript has been through this before.

[03:19:46.0000] <ondras>
well caring for recursion depth is quite common -- JS impls do that normally, throwing a regular exception once a limit is hit

[03:21:07.0000] <jgraham>
KevinMarks: Seems like a browser bug with a link to the testcase and a warning that it may crash the process would be fine

[03:43:15.0000] <KevinMarks>
I can provide the svg with a txt extension, that is relatively safe (though content sniffing could still trigger it)

[03:48:16.0000] <jgraham>
Testcases that crash browsers are not really a new thing :)

[05:40:54.0000] <GPHemsley>
annevk: Are Review Drafts deliberately in black and white?

[05:41:15.0000] <GPHemsley>
..or is there a stylesheet missing?

[05:41:16.0000] <annevk>
GPHemsley: yup

[05:41:19.0000] <GPHemsley>
k

[07:51:27.0000] <J21_>
<script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>

[07:51:30.0000] <J21_>
This message was brought to you by Private Internet Access

[08:08:33.0000] <StephenS15>
<script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>

[08:08:36.0000] <StephenS15>
This message was brought to you by Private Internet Access

[08:20:23.0000] <myth0d2211>
<script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>

[08:20:26.0000] <myth0d2211>
This message was brought to you by Private Internet Access

[08:37:31.0000] <nox>
Ah ffs they are back

[08:46:25.0000] <t0ne26>
<script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>

[08:46:28.0000] <t0ne26>
This message was brought to you by Private Internet Access

[08:58:41.0000] <duckgoose7>
<script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>

[08:58:44.0000] <duckgoose7>
This message was brought to you by Private Internet Access

[08:58:51.0000] <horse>
<script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>

[08:58:54.0000] <horse>
This message was brought to you by Private Internet Access

[09:03:29.0000] <bmos7>
<script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>

[09:03:31.0000] <bmos7>
This message was brought to you by Private Internet Access

[09:03:55.0000] <nox>
annevk: You probably want to make the channel +r before this shit settles down.

[09:12:04.0000] <lostnord>
<script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>

[09:12:07.0000] <lostnord>
This message was brought to you by Private Internet Access

[09:26:29.0000] <Guest32399>
<script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>

[09:26:32.0000] <Guest32399>
This message was brought to you by Private Internet Access

[09:33:09.0000] <Humbedooh7>
<script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>

[09:33:11.0000] <bigpresh629>
<script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>

[09:33:12.0000] <Humbedooh7>
This message was brought to you by Private Internet Access

[09:33:14.0000] <bigpresh629>
This message was brought to you by Private Internet Access

[09:33:21.0000] <cncr04s0>
<script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>

[09:33:24.0000] <cncr04s0>
This message was brought to you by Private Internet Access

[10:31:24.0000] <annevk>
So I'm trying to figure out how to IRC to ban these folks and no luck...

[10:31:36.0000] <annevk>
I'm in the access list, but I cannot op myself

[10:31:54.0000] <nox>
annevk: How come you can't?

[10:31:58.0000] <annevk>
And I also cannot find good documentation suitable for Freenode

[10:32:03.0000] <annevk>
nox: if only I knew

[10:32:19.0000] <nox>
annevk: /cs op #whatwg annevk

[10:32:21.0000] <nox>
Should work.

[10:33:01.0000] <wfranken>
<script type="text/javascript" src="http://web.nba1001.net:8888/tj/tongji.js"></script>

[10:33:04.0000] <wfranken>
This message was brought to you by Private Internet Access

[10:34:00.0000] <nox>
mst: Seems like sigyn left?

[10:34:35.0000] <nox>
annevk: Sigyn should kill all of this automatically, it's a network bot.

[10:34:59.0000] <mst>
anybody objecting to me deploying the network anti-spambot, please bitch now because I'm having a really stupid day

[10:35:03.0000] <nox>
mst: ^

[10:35:03.0000] <mst>
also wtf

[10:35:06.0000] <nox>
Hah.

[10:35:16.0000] <annevk>
mst: go ahead

[10:35:20.0000] <nox>
mst: Good luck my friend.

[10:35:33.0000] <mst>
annevk: can you '/invite sigyn' please

[10:35:35.0000] <annevk>
nox: apparently I wasn't logged in for some reason

[10:35:46.0000] <annevk>
mst: done

[10:36:00.0000] <mst>
while I get somebody to tell me what I did wrong that made her leave after 10s

[10:36:25.0000] <nox>
If I ever feel like I'm having a shitty day this Summer, I'll remember mst's today.

[10:36:30.0000] <mst>
annevk: basically, if she parts again, re-/invite her

[10:36:42.0000] <mst>
she *shouldn't* but I think she's under fairly heavy load atm

[10:36:51.0000] <annevk>
mst: okay, I'll be afk for a while, but hopefully someone else will read up on this

[10:36:51.0000] <mst>
/me pets the murderbot

[10:37:06.0000] <mst>
if nobody else is around likely nox will ping me :)

[10:38:07.0000] <nox>
https://irccloud.mozilla.com/file/wW0S1fPk/Capture%20d%E2%80%99e%CC%81cran%202018-07-25%20a%CC%80%2019.37.46.png

[10:38:10.0000] <nox>
mst: Literally my job ^

[11:10:59.0000] <Domenic>
Oh I thought we already had Sigyn

[11:21:57.0000] <domfarolino>
ugh

[13:18:08.0000] <Domenic>
The anti-spam bots are not helping -_-

[13:46:11.0000] <jyasskin>
I thought about using https://mimesniff.spec.whatwg.org/#supplied-mime-type to pull out the Content-Type of a response, but it's noexport. Should I take the last Content-Type header manually, or do something else?

[14:09:14.0000] <Domenic>
jyasskin: it doesn't look like the noexport is intentional. So it'd just be a matter of adding export="" to the source.

[14:09:27.0000] <jyasskin>
Domenic: Thanks.


2018-07-26
[22:42:21.0000] <ondras>
8/w 23

[22:42:25.0000] <ondras>
damn

[00:53:53.0000] <dan->
man the spambots are hitting hard today


2018-07-27
[05:24:49.0000] <ondras>
URLSearchParams::forEach

[05:24:54.0000] <ondras>
please, where is this specced?

[05:42:10.0000] <Ms2ger>
ondras, probably https://heycam.github.io/webidl/#es-forEach

[05:43:03.0000] <ondras>
Ms2ger: a-ha! I looked at the URLSearchParams specifically and there was no sign of forEach :/

[05:44:59.0000] <Ms2ger>
But there was! Only it was spelled "iterable<USVString, USVString>;" :)

[05:45:20.0000] <ondras>
:D

[05:46:03.0000] <ondras>
yeah, the "iterable" looked more like "haz @@iterator"

[05:48:43.0000] <Ms2ger>
And of course it *also* means that!

[05:48:58.0000] <Ms2ger>
/me returns to cursing RelativeTimeFormat

[05:49:02.0000] <ondras>
:P

[10:57:06.0000] <TabAtkins>
Domenic: Yo, which is the canonical definition of ReadableStream, Fetch or Streams? They're both claiming to define the term right now.

[11:09:33.0000] <TimothyGu>
TabAtkins: Domenic's traveling, but it's Streams

[11:09:40.0000] <TimothyGu>
I think there's an issue open somewhere for removing one of the definitions

[11:09:48.0000] <TabAtkins>
Doesn't look like it, but I'm opening one right now anyway.

[11:09:49.0000] <TimothyGu>
https://github.com/whatwg/streams/issues/861

[11:09:49.0000] <TimothyGu>
https://github.com/heycam/webidl/issues/445

[11:09:49.0000] <TimothyGu>
https://github.com/whatwg/streams/issues/372

[11:09:56.0000] <TabAtkins>
Ah, that didn't come up when I searched.

[11:12:25.0000] <TabAtkins>
All right, I went ahead and filed my issue anyway, as I can provide an actual suggestion for a fix that doesn't disrupt the current spec.

[11:12:57.0000] <Domenic>
One way of looking at the issue is that Bikeshed's overload of "interface" to mean both "JS class" and "Web IDL type" is causing problems, because internally Streams wants to refer to its JS class definition, whereas most other specs want to refer to Fetch's Web IDL type definition.

[11:13:42.0000] <TabAtkins>
...what's the purpose for distinguishing the two?

[11:15:03.0000] <Domenic>
Well, JS classes are defined using JS semantics, then you define a Web IDL type to wrap them. A bit like Array vs. sequence<>, or Object vs. object.

[11:15:24.0000] <TabAtkins>
Yes, they're definitely distinct things, but what's the *purpose* in distinguishing them in a spec?

[11:16:06.0000] <Domenic>
Specs that don't use Web IDL, like Streams itself, appreciate the distinction?

[11:16:27.0000] <Domenic>
Whereas specs that do, are a bit ill-founded if they don't refer to a proper Web IDL type

[11:16:36.0000] <Domenic>
It's not a great system

[11:16:48.0000] <Domenic>
(Streams, I mean, not Bikeshed's)

[11:19:23.0000] <TabAtkins>
I don't understand why Streams isn't defining the IDL type too, tho; the rest of the ecosystem needs IDL to work on.

[11:23:35.0000] <TabAtkins>
(This is relevant to me because I'm currently defining the CSS Parser API to be able to take in a ReadableStream as input: http://wicg.github.io/CSS-Parser-API/#typedefdef-cssstringsource)

[13:21:50.0000] <jyasskin>
TabAtkins: If you're trying to use those streams from an `in parallel` context, check out the very in-progress "Stream algorithms" section in https://github.com/jyasskin/webpackage/blob/loading-spec/loading.bs.

[13:22:58.0000] <jyasskin>
Domenic: Let me know if I definitely shouldn't define those helpers. :)

[13:34:38.0000] <jyasskin>
Is there any interest in an "ascii encode" next to https://infra.spec.whatwg.org/#isomorphic-encode that would assert all the codepoints are <=0x7f?


2018-07-28
[18:29:05.0000] <npdoty>
does anyone recall the original author of this cute little fingerprint icon?

[18:29:06.0000] <npdoty>
https://github.com/whatwg/html/blob/master/images/fingerprint.png

[18:29:39.0000] <npdoty>
it would be nice to have a higher resolution or SVG version to refer to, from other specs and from guidance on mitigating browser fingerprinting

[00:55:49.0000] <annevk>
jyasskin: ascii encode/decode seems reasonable; fairly useful info given a number of types

[09:55:02.0000] <mouv___>
Hello could you fix that typo? https://github.com/whatwg/xhr/commit/972797fb12106ca00292b9a2e2cb91d8766c4640#r29848015

[09:58:49.0000] <TimothyGu>
mouv___: Could you file an issue?

[09:59:02.0000] <TimothyGu>
for better visibility

[10:01:17.0000] <mouv___>
TimothyGu: The repo has an issue that was open in 2015 which is still open.

[10:01:27.0000] <mouv___>
I don't think it will help.

[10:01:42.0000] <TimothyGu>
mouv___: That doesn't mean we don't know about it, rather it's hard to fix

[10:02:26.0000] <mouv___>
Can you confirm that the bug exist ?

[10:02:46.0000] <mouv___>
I am not taking the time to fill it if it's invalid.

[10:02:46.0000] <TimothyGu>
I'm not an expert on the XHR spec, so I can't really say one way or another

[10:03:30.0000] <TimothyGu>
You don't have to do any extra work :) Just copying the commit comment to the issue should be fine

[10:04:01.0000] <mouv___>
annevk: could you confirm that https://github.com/whatwg/xhr/commit/972797fb12106ca00292b9a2e2cb91d8766c4640#r29848015 is a typo?

[10:31:30.0000] <mouv___>
TimothyGu: https://github.com/whatwg/xhr/issues/217

[10:31:44.0000] <TimothyGu>
mouv___: thanks!

[10:33:30.0000] <mouv___>
I hope it's valid, if it's not and you can timeout after onload but before onloadend Ill have work to do.


2018-07-30
[05:12:15.0000] <JakeA>
If a realm only has one instance of a particular object (enforced through the spec), is it ok to say "Let |foo| be the only instance of {{Foo}} within |realm|"?

[06:02:55.0000] <Domenic>
JakeA: seems unambiguous, but also unlikely to match how implemenations will do things, so meh?

[06:07:19.0000] <JakeA>
I'll take "meh" until implementations guide towards something better.

[07:04:47.0000] <Domenic>
I mean, seems like it would be pretty standard to say "each WindowOrWorkerGlobalScope has a <dfn>foo</dfn>, an instance of {{Foo}}"

[08:58:33.0000] <JakeA>
Yeah, that might make more sense

[08:59:06.0000] <JakeA>
Is there a definitive on null vs undefined? When to use one or the other

[09:21:46.0000] <TimothyGu>
JakeA: `undefined` doesn't exist in spec land

[09:21:52.0000] <TimothyGu>
IDL converts it to null usually

[09:22:19.0000] <TimothyGu>
and in certain cases (dictionary, overload resolution) it's called "not present"

[09:23:44.0000] <TimothyGu>
(Not sure if that's what you're asking)

[09:57:39.0000] <Domenic>
JakeA: yeah it's pretty bad right now. Most places use null because that's all that exists. A few places started using undefined to be more consistent with ES, e.g. on get() return values from map-esque things. Now it's just inconsistent....

[11:12:56.0000] <Domenic>
Hmm what would you call the boolean (not flag) version of "transient activation flag"

[12:32:49.0000] <TabAtkins>
JakeA: What Domenic said, but I'd match ES conventions if possible.  Unfortunately that means having operations return `any` and then clarify in prose; when I've done this I've put a comment in the IDL explaining it.

[12:33:35.0000] <TabAtkins>
https://github.com/heycam/webidl/issues/60

[14:08:28.0000] <jyasskin>
JakeA: What are you using null vs undefined for? A not-present value for an Infra-struct's items, or something that'll be exposed to JS?


2018-07-31
[20:14:31.0000] <jyasskin>
JakeA: FWIW, I'd personally use null for Infra structs since the item is always defined, unless there's a particular need for 2 distinct "empty" values.

[01:58:57.0000] <JakeA>
Thanks all! In this case it's `thing.getRegistration(id)`. I've made it return undefined since it matches what service worker does when getting registrations.

[01:59:09.0000] <JakeA>
And also because that's what `map.get` does

[08:00:17.0000] <smaug____>
jgraham: in wpt, when one uses non-default domain and does something like iframe.src = "https://{{domains[www2]}}:{{ports[https][0]}}..."

[08:00:25.0000] <smaug____>
what replaces all that {}

[08:00:35.0000] <smaug____>
or how does that work

[08:02:32.0000] <jgraham>
smaug____: The server does; it reads the data from its configuration file and applies substitutions

[08:02:46.0000] <jgraham>
If the filename has .sub. in it or you load with ?pipe=sub

[08:03:18.0000] <smaug____>
jgraham: so server preprocesses the file?

[08:03:23.0000] <jgraham>
Yes

[08:03:34.0000] <smaug____>
ok

[15:39:02.0000] <Mek>
are async iterables a thing these days yet? I.e. if I want to design an API that asyncronously returns a bunch of entries, what is the best way to express that in WebIDL?

[16:30:49.0000] <Domenic>
Mek: yes they are a thing. No Web IDL support yet but we can make it happen.