2017-10-01
[18:29:12.0000] <MikeSmith>
as an implementor of a conformance-checking tool, my point of view on “must” language for the class of requirements discussed here earlier is that ideally they should be stated a requirement on *documents* (not authors)

[18:30:10.0000] <MikeSmith>
because a document must conform to the requirements in isolation from the author or system that created it

[18:31:04.0000] <MikeSmith>
and many to web documents aren’t really created directly but authors anyway, but instead generated in out of CMS or whatever

[18:33:43.0000] <MikeSmith>
see https://html.spec.whatwg.org/multipage/infrastructure.html#conforming-documents

[18:34:05.0000] <MikeSmith>
> For readability, some of these conformance requirements are phrased as conformance requirements on authors; such requirements are implicitly requirements on documents

[15:43:50.0000] <jyasskin>
MikeSmith: I'd missed that HTML specifically describes its conformance classes. That's great. WebIDL does the same: https://heycam.github.io/webidl/#conformance claims that it only 'must's IDL fragments. I bet we've drifted from that over time though, and if we want to keep 'must'ing other specs, we should say that in #conformance.

[15:50:57.0000] <jyasskin>
Domenic: I don't know of any documents describing how to write specifications. Fundamentally, I think we're in charge of making it up as we go along.

[15:50:57.0000] <jyasskin>
I think my axiom here is that we need to make sure our requirements for each conformance class are "complete", meaning they cover what happens when other conformance classes fail to live up to their requirements. Then what guidelines for specs make it most likely that we'll remember to do that?

[15:55:21.0000] <jyasskin>
"Don't must documents" is one of those, since it's much easier to forget to constrain the implementation when you've said that a situation must never happen. But we do break that one and just rely on spec writers to be careful.

[15:55:22.0000] <jyasskin>
I think that care is then somewhat undermined by having another conformance class (specs) where we *can* forget to handle the "must never happen" cases. https://infra.spec.whatwg.org/#assertions is great for this, since it's an entirely new word for the new kind of situation.

[16:26:48.0000] <MikeSmith>
jyasskin: yeah, Hixie has the details about conformance classes in the HTML spec from the beginning. It’s just not something we’ve otherwise done a good job of socializing to other spec authors

[16:27:08.0000] <MikeSmith>
we definitely ought to have better documents describeing how to write specifications

[16:27:39.0000] <MikeSmith>
a lot of W3C basically don '

[16:27:39.0000] <jyasskin>
At the moment, that's Infra.

[16:27:45.0000] <MikeSmith>
yeah

[16:29:06.0000] <jyasskin>
I don't know if I'll have time to send a patch for this any time soon.

[16:30:37.0000] <MikeSmith>
yeah that’t the problem: This never stays up high enough in anybody’s priority stack to get done

[16:32:21.0000] <MikeSmith>
but maybe I can make a patch for Infra myself


2017-10-02
[00:20:11.0000] <MikeSmith>
JakeA: was there an issue or PR associated with the “Reject on cache add/addAll/put if the response has Vary: *” https://github.com/w3c/ServiceWorker/commit/8c3dbf1

[00:21:47.0000] <MikeSmith>
nm I found https://github.com/w3c/ServiceWorker/issues/656

[01:43:19.0000] <annevk>
mkwst_sheriff: why samesite cookies? I thought you wanted "site" reserved for registrable domain type stuff?

[01:49:09.0000] <annevk>
jyasskin: MikeSmith: I filed https://github.com/whatwg/infra/issues/158 to keep track of this

[01:55:39.0000] <mkwst_sheriff>
annevk: They key on registrable domain.

[01:56:01.0000] <mkwst_sheriff>
`accounts.google.com` => `docs.google.com`

[01:56:10.0000] <mkwst_sheriff>
Because cookies are nuts. *shrug*

[02:02:11.0000] <annevk>
mkwst_sheriff: wait so how are they different from normal cookies?

[02:03:49.0000] <annevk>
mkwst_sheriff: ooh I see

[02:04:12.0000] <annevk>
mkwst_sheriff: the original "first party" name was more clear to me

[02:04:57.0000] <mkwst_sheriff>
It was originally "first-party". Folks objected.

[02:05:08.0000] <mkwst_sheriff>
Well. One folk.

[02:05:37.0000] <annevk>
mkwst_sheriff: was there also some same-origin cookie effort?

[02:05:43.0000] <annevk>
mkwst_sheriff: I guess I got this confused with that

[02:06:21.0000] <mkwst_sheriff>
There was. We ended up punting on it in favor of the `__Host-` prefix, which was trivial to implement, and gets us most of the way there (still doesn't deal with ports).

[02:07:15.0000] <annevk>
aah okay, thanks for clearing up my confusion

[02:07:32.0000] <annevk>
mkwst_sheriff: jochen__ has an idea for ports, but you know that

[02:07:48.0000] <mkwst_sheriff>
jochen__ has lots of ideas!

[02:07:55.0000] <mkwst_sheriff>
I thought his ports idea was for `document.domain`?

[02:08:00.0000] <annevk>
I happen to like this one

[02:08:17.0000] <annevk>
mkwst_sheriff: I think he wanted to extend it to all things that do document.domain-like things

[02:08:30.0000] <annevk>
So also cookies and webauthn

[02:12:28.0000] <mkwst_sheriff>
Hrm. I'm staring at the back of jochen__'s head through a door, but I think I'll have to wait until he walks out to see what his idea for cookies is.

[02:12:39.0000] <mkwst_sheriff>
(Is it that we don't store cookies on weird ports?)

[02:17:38.0000] <annevk>
Whoa, unicode.org supports HTTPS now?! Nice find MikeSmith!

[02:18:09.0000] <annevk>
mkwst_sheriff: if you got them over port 80 or 443, they're only going out to port 80 or 443

[02:18:19.0000] <annevk>
mkwst_sheriff: if you got them from a weird port, they'll continue to go to all ports

[02:18:34.0000] <annevk>
mkwst_sheriff: iirc

[02:19:00.0000] <MikeSmith>
annevk: yeah I was surprised by that too. Found it just be going through all the References one-by-one to see which might need to be updated

[02:19:33.0000] <annevk>
That must have been a very recent change

[02:19:55.0000] <MikeSmith>
yeah, weeks or a few months I guess

[02:20:58.0000] <MikeSmith>
anyway I ended up looking through the References only because of when I discovered last week that we didn’t have the Secure Contexts spec in there

[02:20:59.0000] <annevk>
Every now and then I go through http:// links and it's always unicode.org that sticks out

[02:21:02.0000] <annevk>
But no longer!

[02:21:10.0000] <MikeSmith>
heh :)

[02:21:25.0000] <annevk>
Even iso.org

[02:21:36.0000] <MikeSmith>
well you have my anxiety to thank for it :)

[02:22:17.0000] <MikeSmith>
after noticing that spec missing from the References, I got bothered about what else we might need to update there

[02:22:32.0000] <MikeSmith>
so, started pulling that thread

[02:22:54.0000] <MikeSmith>
then, N different PRs later I think I’m done for now

[02:23:14.0000] <MikeSmith>
though I still worry there’s something I overlooked

[02:23:24.0000] <MikeSmith>
didn’t really did it all very systematically

[02:23:50.0000] <mkwst_sheriff>
annevk: I guess we'd need to deal with `example.com:443` and `example.com:81` both trying to store a session ID or something? Either explicitly storing the port or sharding the cookie jar or something?

[02:23:53.0000] <MikeSmith>
Progress Not Perfection

[02:24:15.0000] <mkwst_sheriff>
It's not crazy! I imagine 99% of navigations are to standard ports.

[02:25:49.0000] <annevk>
mkwst_sheriff: I don't recall what the plan was when :81 adds something, if that's only for non-standard ports or if there's some kind of way that can also be used on :443 and :80

[02:26:46.0000] <mkwst_sheriff>
annevk: I just mean that we'd need to spec sane behavior for the case when a standard port sets a cookie, and then a non-standard port sets the same cookie.

[02:27:25.0000] <mkwst_sheriff>
Whatever the behavior, we'd need to store some metadata about the way the cookie was set, or put it into a separate jar based upon that context.

[02:27:42.0000] <mkwst_sheriff>
So we'd probably end up doing the simple thing and adding an int to the cookie database.

[02:27:46.0000] <mkwst_sheriff>
Which is probably fine.

[02:27:58.0000] <annevk>
mkwst_sheriff: ah yeah, I suspect the idea was to just say default-port yes/no and take that into account when making requests

[02:28:48.0000] <annevk>
mkwst_sheriff: that was also the plan for document.domain, the addition of a boolean

[02:29:47.0000] <mkwst_sheriff>
I thought the plan for `document.domain` was to just stop ignoring the port when doing comparisons.

[02:31:18.0000] <mkwst_sheriff>
https://www.chromestatus.com/metrics/feature/timeline/popularity/2025 is his metric for the `document.domain` bit. Not sure if it's hit stable yet...

[02:31:23.0000] <annevk>
mkwst_sheriff: anyway, addition of boolean or int

[02:31:37.0000] <annevk>
mkwst_sheriff: best to ask jochen__ for specifics, maybe it changed around

[02:31:44.0000] <mkwst_sheriff>
Sure. Boils down to the same thing. Being explicit about it is probably for the best.

[02:32:30.0000] <mkwst_sheriff>
Not sure how much it really helps for cookies, given that they span subdomains, not just ports, but `document.domain` and `WebAuthn` seem like good targets.

[02:33:00.0000] <annevk>
document.domain and WebAuthn also span subdomains, that's the whole point

[02:33:07.0000] <mkwst_sheriff>
(https://tools.ietf.org/html/draft-west-origin-cookies-01 was the origin cookie proposal, btw. Reading it again, it's pretty ugly.)

[02:33:09.0000] <annevk>
That's why they're all in the same boat

[02:33:19.0000] <mkwst_sheriff>
Fair.

[02:33:51.0000] <annevk>
That's also why I pushed jochen__ to not just restrict document.domain, since we'd still have the leak with webauthn/cookies

[02:43:44.0000] <mkwst_sheriff>
Presumably fixing the algorithm in HTML would also fix WebAuthn.

[02:49:01.0000] <annevk>
mkwst_sheriff: can we make cookies use that algorithm too?

[02:49:21.0000] <annevk>
mkwst_sheriff: would be nice if they all used a shared primitive

[02:50:30.0000] <mkwst_sheriff>
AFAIK, they all basically rely on "registrable domain" as the relevant primitive. `document.domain` additionally relies on the `domain` attribute of `Origin`.

[02:50:43.0000] <mkwst_sheriff>
But the comparison for each should be the same.

[02:51:27.0000] <annevk>
mkwst_sheriff: I meant reuse of "is a registrable domain suffix of or is equal to"

[02:52:36.0000] <mkwst_sheriff>
Cookies rely on "domain-match" (https://tools.ietf.org/html/rfc6265#section-5.1.3).

[02:53:17.0000] <mkwst_sheriff>
And on not setting cookies for public suffixes (Step 5 of https://tools.ietf.org/html/rfc6265#section-5.3)

[02:53:31.0000] <mkwst_sheriff>
Basically the same thing.

[02:54:12.0000] <annevk>
Sure, I just figured it would be nicer if they all actually used the same thing

[02:54:32.0000] <annevk>
But it doesn't matter much, as long as we don't forget they're all doing the same thing, so any updates should affect all three

[02:57:17.0000] <mkwst_sheriff>
It would be nicer if they all actually used the same thing.

[02:57:50.0000] <mkwst_sheriff>
And since I'm going to have to argue with folks about referencing Fetch and HTML from an RFC anyway, might as well argue with them even more, I guess.

[02:59:57.0000] <MikeSmith>
annevk: in https://github.com/whatwg/infra/issues/158 not sure what you mean by “it was suggested to require things from documents instead, but that doesn't quite work for APIs”

[03:00:25.0000] <MikeSmith>
the code that uses an API is (logically) part of the document

[03:00:58.0000] <MikeSmith>
so we can say, “Documents must not use this API in way that ...” or whatever

[03:03:49.0000] <annevk>
MikeSmith: I guess if everything is a document that might work

[03:03:56.0000] <annevk>
MikeSmith: my bad in that case

[03:04:05.0000] <annevk>
mkwst_sheriff: enjoy

[03:33:35.0000] <nox>
The spec for <video> says that when there is nothing to show, the <video> elements represents transparent black with no intrinsic dimensions,

[03:33:50.0000] <nox>
but if I load data:text/html,<video%20style="border:1px%20black%20solid"> in Safari, Chrome or Firefox, it draws a 300x150 box.

[03:33:53.0000] <nox>
Should the spec change?

[03:36:37.0000] <annevk>
nox: maybe

[03:36:53.0000] <nox>
annevk: Should I just file an issue?

[03:38:04.0000] <annevk>
nox: yeah, though I'm guessing it's not technically an issue since that's just what it represents

[03:38:14.0000] <nox>
annevk: What do you mean?

[03:38:15.0000] <annevk>
nox: it still needs to be rendered per the replaced element rules

[03:38:24.0000] <nox>
I don't understand what that means.

[03:38:50.0000] <jochen__>
what's up with ports & cookies?

[03:39:34.0000] <nox>
annevk: 'The video element represents its poster frame, if any, or else transparent black with no intrinsic dimensions.' is the only thing that specifies that <video> is supposed to not render anything by default, right?

[03:39:37.0000] <annevk>
jochen__: mkwst_sheriff and I were wondering how the "new model" would work with a cookie set on :81 vs one set on :443

[03:40:00.0000] <annevk>
nox: so wait if it doesn't have intrinsic dimensions isn't the fallback defined by CSS 300x150?

[03:40:11.0000] <nox>
annevk: Where?

[03:40:21.0000] <annevk>
nox: it still seems a little weird that we don't define this in the rendering section though

[03:40:44.0000] <nox>
annevk: I've never heard about such a fallback, so if you could point it out to me that would be well appreciated.

[03:41:41.0000] <annevk>
nox: https://www.w3.org/TR/CSS2/visudet.html#inline-replaced-width

[03:42:12.0000] <nox>
annevk: Thanks!

[03:48:30.0000] <nox>
annevk: But why do these rules apply?

[03:48:32.0000] <jochen__>
annevk: I'd basically introduce another bit to origin that says "default port", so http://example.com/ would be (http, example.com, 80, true) and https://test.com:31337 would be (https, test.com, 31337, false)

[03:48:53.0000] <annevk>
nox: you agree it's a replaced element?

[03:48:59.0000] <nox>
annevk: Maybe?

[03:49:00.0000] <jochen__>
and the "is default port" bit has to match in any case

[03:49:02.0000] <nox>
Where is that stated?

[03:49:07.0000] <annevk>
nox: in the rendering section

[03:49:38.0000] <nox>
annevk: Where is that in the spec?

[03:49:39.0000] <annevk>
jochen__: okay, mkwst_sheriff thought you wanted to to store the port

[03:49:52.0000] <nox>
I can't find "replaced" in the spec of <media>.

[03:50:00.0000] <jochen__>
annevk: for cookies?

[03:50:03.0000] <nox>
(Nor <video>..)

[03:50:08.0000] <annevk>
nox: https://html.spec.whatwg.org/multipage/rendering.html#embedded-content-rendering-rules

[03:50:16.0000] <jochen__>
annevk: I'd basically end up with two cookie jars, one for default_port = true and one for false

[03:50:28.0000] <nox>
annevk: Thanks.

[03:50:35.0000] <annevk>
jochen__: yeah, he thought the extra field would be int, not boolean

[03:51:09.0000] <annevk>
jochen__: anyway, looking forward to seeing that progress, it's a nice additional restriction I think

[03:51:54.0000] <nox>
annevk: Is there any more up-to-date spec than CSS2.1 that says the same thing?

[03:54:49.0000] <annevk>
nox: there wasn't a couple years ago

[03:55:03.0000] <nox>
Ok.

[03:55:06.0000] <annevk>
nox: maybe half a decade, it's been a while I suppose

[04:08:30.0000] <nox>
annevk: Any wording for the fact that <video width=500> will not keep 150 for the height, and will instead preserve ratio?

[04:10:22.0000] <smaug____>
annevk: "page" isn't any specified thing, right?

[04:10:46.0000] <smaug____>
like, not top level document + all the documents in iframes underneath, or anything like that

[04:22:00.0000] <gsnedders>
nox: yes, somewhere

[04:25:17.0000] <gsnedders>
nox: https://drafts.csswg.org/css2/visudet.html#inline-replaced-width

[04:25:51.0000] <gsnedders>
nox: uh, https://drafts.csswg.org/css2/visudet.html#inline-replaced-height

[04:26:29.0000] <nox>
gsnedders: "has a height not greater than 150px" wat

[04:27:16.0000] <gsnedders>
nox: hey, be glad the 300x150 default finally got spec'd

[04:27:20.0000] <nox>
lol

[04:27:29.0000] <nox>
gsnedders: But the words "has a height not greater than 150px" are wrong right?

[04:27:33.0000] <gsnedders>
nox: but yeah, "Otherwise, if 'height' has a computed value of 'auto', and the element has an intrinsic ratio then the used value of 'height' is:

[04:27:40.0000] <gsnedders>
nox: is the case <video width=500> is in

[04:27:58.0000] <gsnedders>
nox: (assuming the video format has an intrinsic ratio, which all that I'm aware of do)

[04:28:14.0000] <nox>
gsnedders: I literally meant <video width=500>.

[04:28:24.0000] <nox>
No src, no source child, nothing.

[04:28:59.0000] <gsnedders>
nox: oh, then yeah it's the 150px case

[04:29:08.0000] <gsnedders>
nox: and yeah, that's a bit awkward to read

[04:29:08.0000] <nox>
gsnedders: So the spec is wrong?

[04:29:34.0000] <gsnedders>
nox: I haven't read what's in the HTML spec about this :)

[04:29:46.0000] <nox>
gsnedders: I mean,

[04:29:51.0000] <nox>
if the ratio of 2:1 needs to be preserved,

[04:29:57.0000] <nox>
how do you do that if the width is >300px?

[04:30:04.0000] <nox>
And the height cannot be >150px.

[04:31:17.0000] <gsnedders>
yeah, the spec doesn't seem very clear there. file a bug?

[04:31:26.0000] <nox>
Mmh <video width=500 style="border: 1px black solid"> is not rendered the same as <object width=500 style="border: 1px black solid">.

[04:31:43.0000] <nox>
gsnedders: So what's missing, I think, is a definition of the intrinsic ratio of the video element.

[04:34:58.0000] <annevk>
Hmm, http://cldr.unicode.org/ doesn't use HTTPS; you'd think that would be even more important

[04:35:25.0000] <annevk>
smaug____: I think it has some meaning in CSS printing

[04:35:37.0000] <smaug____>
right, but not in DOM

[04:35:40.0000] <annevk>
smaug____: not in any DOM/HTML context that I know of

[04:36:05.0000] <smaug____>
I was trying to understand pointer events spec, and couldn't.  Filed a bug, well 3.

[04:36:42.0000] <ondras>
/me uses @page for printing stuff

[04:37:01.0000] <nox>
gsnedders: Filed. https://github.com/whatwg/html/issues/3090

[05:33:16.0000] <annevk>
tobie: oh, so https://github.com/tobie/specref/blob/master/refs/legacy.json is parsed later or something?

[05:34:32.0000] <annevk>
tobie: which files from https://github.com/tobie/specref/tree/master/refs are auto-generated?

[05:34:37.0000] <tobie>
annevk: nope, that's all the ones that were too hard to automatically parse

[05:35:02.0000] <tobie>
they're dumped as a string to the clients who then have to deal with it.

[05:35:18.0000] <tobie>
annevk: that's why ideally they should be fixed

[05:35:34.0000] <tobie>
annevk: all but biblio and legacy

[05:36:03.0000] <annevk>
tobie: what's the source for csswg.json?

[05:36:08.0000] <tobie>
annevk: but it's a little more subtle than auto-generation, though, as they're fed into the input themselves

[05:36:12.0000] <annevk>
tobie: it was last patched manually 5 months ago it seems

[05:36:37.0000] <tobie>
annevk: which makes them manually patched for some cases

[05:37:32.0000] <tobie>
annevk: http://dev.w3.org/csswg/biblio.ref

[05:38:07.0000] <tobie>
annevk: at https://github.com/tobie/specref/blob/master/scripts/csswg.js#L46

[05:38:41.0000] <annevk>
tobie: I see, that URL can now be HTTPS

[05:39:06.0000] <annevk>
tobie: do you want a PR for that?

[05:39:11.0000] <tobie>
annevk: sure

[05:40:46.0000] <annevk>
MikeSmith: the redirect for     http://dev.w3.org/2009/dap/contacts/ is rather useless

[06:26:12.0000] <annevk>
Domenic: how is forging in https://github.com/whatwg/dom/issues/270#issuecomment-333531823 a problem though?

[06:28:03.0000] <annevk>
Domenic: is there a new subtlety the subsequent comments didn't go into?

[06:29:02.0000] <Domenic>
annevk: it basically means you are no longer constrained by the API; seems pretty unsafe.

[06:29:24.0000] <Domenic>
you can get a pointer to objects you weren't originally allowed to access, since everyone shares the same global space ("integers")

[06:31:21.0000] <annevk>
Domenic: so this is only problematic if we actually expose the buffer?

[06:32:28.0000] <annevk>
I guess you can still queue invalid operations or with integers that potentially are used for some other purpose

[06:32:33.0000] <annevk>
Maybe

[06:32:42.0000] <Domenic>
Yeah, it's problematic if we use integers for the arguments to these methods

[06:33:12.0000] <Domenic>
(or return them)

[06:35:37.0000] <annevk>
If they return integers to get a handle on a node later and we only return nodes within the appended tree (so these are not global references) it might be okay

[06:36:03.0000] <annevk>
I mean, it's definitely something we need to be mindful of, but I'm not sure it's a showstopper for the general idea

[06:36:30.0000] <annevk>
We also haven't really seen any alternatives pop up, but this also hasn't gotten any experimentation yet unfortunately

[06:37:03.0000] <annevk>
Might be another interesting intern project

[07:22:51.0000] <annevk>
TabAtkins: doesn't CSS also need some way to reference Node objects from another thread?

[07:22:57.0000] <annevk>
TabAtkins: for layout worklets and such?

[07:23:09.0000] <annevk>
TabAtkins: or is that worked around differently?

[07:23:21.0000] <TabAtkins>
Worked around differently

[07:23:38.0000] <annevk>
surma: hey, where is that proposal you talked about in HTTP 403?

[07:23:46.0000] <TabAtkins>
You just get a property bag and some objects representing the box tree

[07:23:52.0000] <annevk>
surma: assuming you're that surma

[07:24:22.0000] <surma>
i am that surma ^^

[07:24:26.0000] <annevk>
TabAtkins: kk, was wondering if you maybe shared a need with https://github.com/whatwg/dom/issues/270

[07:24:33.0000] <surma>
You mean tasklets?

[07:24:39.0000] <annevk>
surma: yeah

[07:24:59.0000] <surma>
https://discourse.wicg.io/t/proposal-tasklets/2199

[07:25:18.0000] <annevk>
/me wonders if JakeA learned meanwhile that Worklets are very much intended to be able to run on a different thread

[07:25:46.0000] <annevk>
surma: new version of https://github.com/esprehn/tasklets basically?

[07:26:26.0000] <annevk>
Seems your variant has more commits, but a similar README

[07:26:52.0000] <surma>
Yeah esprehn, bfgeek and I had 3 versions before the canonical one on ChromeLabs got created

[07:27:38.0000] <surma>
The commits mostly stem from the polyfill that we wrote.

[07:28:16.0000] <surma>
Which reminds me I need to Backport all the progress and features I made with Comlink

[07:28:50.0000] <JakeA>
annevk: ohhh, I think I knew that. I was unsure if they had an event loop. At one point I thought async stuff wasn't allowed in them, but not sure where I got that from

[07:30:08.0000] <annevk>
JakeA: they have an event loop of sorts, but very little is queued to it

[07:30:44.0000] <annevk>
JakeA: but e.g. audio worklets have a postMessage API so very much need to loop

[07:31:04.0000] <annevk>
JakeA: and I suspect paint has similar things and will at least need to deal with promises

[07:32:04.0000] <JakeA>
annevk: so the only difference between them and workers is the ability to run on the same thread as eachother, and perhaps different APIs exposed?

[07:33:50.0000] <annevk>
JakeA: I think the difference is that there's less APIs exposed (just ECMAScript builtins and a couple basic things; though some worklets might still expose quite a bit of new objects)

[07:34:29.0000] <JakeA>
annevk: unrelated, but do you know of any web APIs that have the ability to terminate fetches in a standardised way? Aside from fetch & xhr

[07:34:52.0000] <annevk>
JakeA: I don't think it's really sorted what the ideal mapping to OS threads is (though they won't be able to use Atomics.wait, which dedicated workers can, but no other workers can)

[07:35:23.0000] <annevk>
JakeA: maybe window.stop()? But I couldn't really create good tests with that myself

[07:35:36.0000] <annevk>
JakeA: another trick might be navigating a document that has ongoing fetches

[07:35:53.0000] <annevk>
JakeA: the latter one is documented, but there's a bunch of interop and timing differences between browsers

[07:36:32.0000] <annevk>
surma: that proxy bridge is interesting, but also the first proxy we'd add after we have deprecated them all

[07:36:37.0000] <annevk>
surma: not sure how I feel about that

[07:36:51.0000] <JakeA>
annevk: timing isn't really an issue. Navigating an iframe sounds like a good bet

[07:37:41.0000] <annevk>
JakeA: oh, window.close() should be similar

[07:37:47.0000] <annevk>
JakeA: and maybe removing an <iframe>

[07:38:03.0000] <annevk>
JakeA: (you can use window.open() within web-platform-tests, it's safelisted)

[07:38:52.0000] <JakeA>
annevk: I thought about removing an iframe, but wondered if it might keep the fetches alive while there's a reference.

[07:39:06.0000] <JakeA>
Good few avenues to test there, though

[07:39:27.0000] <annevk>
JakeA: I don't think it should, since removing an <iframe> triggers some synchronous stuff

[07:39:36.0000] <annevk>
JakeA: that is, removing and then appending is destructive

[07:40:57.0000] <annevk>
JakeA: yeah, removing an <iframe> triggers discard for the browsing context, which triggers discard for documents, which triggers abort for the document

[07:43:31.0000] <JakeA>
annevk: that'll do the trick then, thanks!

[07:54:28.0000] <annevk>
surma: might also be good to update those older repositories to point to the one true source for tasklets

[07:57:05.0000] <Domenic>
+1 updating older repos

[08:02:46.0000] <annevk>
gwicke: why does Wikipedia percent-encode URLs with Unicode in them?

[08:03:08.0000] <annevk>
gwicke: if you consistently enforce UTF-8 it would presumably save quite a bit of bandwidth on non-Western content to not do that

[08:03:43.0000] <gwicke>
annevk: in the default desktop view that is a historical hold-over

[08:04:19.0000] <gwicke>
part of the damage inflicted by the xhtml validator back in the day

[08:04:45.0000] <gwicke>
the newer parsoid parser uses UTF8 wherever it can

[08:04:53.0000] <annevk>
gwicke: okido

[08:05:25.0000] <gwicke>
annevk: thanks for the prod!

[08:07:53.0000] <surma>
annevk: feel free to comment on the wicg thread. Good point about the old repos, I wasn't actually aware that they got shared outside Google.

[08:12:33.0000] <annevk>
surma: I guess I'll file an issue

[08:13:15.0000] <surma>
Appreciate it!

[08:24:37.0000] <gsnedders>
who should be pinged about CSSOM stuff?

[08:24:50.0000] <gsnedders>
now zcorpan is gone (:()

[08:27:23.0000] <annevk>
gsnedders: Glenn Adams!

[08:29:16.0000] <gsnedders>
oh, I mean CSSOM View seemingly. still the same answer?

[08:49:47.0000] <gsnedders>
Also: is there anyone around IRC I can ask probably stupid font-related questions?

[08:50:06.0000] <gsnedders>
(I ask to ask given I've only ever got silence before :))

[09:10:21.0000] <TabAtkins>
gsnedders: I'll probably do unofficial editting on the spec until we decide on a real editor.

[10:30:09.0000] <annevk>
jyasskin: won't derail the thread further, but your statement doesn't work generically for worklets either

[10:30:13.0000] <annevk>
jyasskin: consider audio worklets

[10:30:50.0000] <jyasskin>
annevk: What's wrong for audio workets?

[10:31:16.0000] <annevk>
jyasskin: they need to be on their own thread, nothing's wrong

[10:31:44.0000] <jyasskin>
annevk: Couldn't the browser multiplex multiple audio worklets from a single origin onto the same thread?

[10:33:01.0000] <annevk>
jyasskin: I don't see why that would be okay but it wouldn't be okay for workers

[10:33:15.0000] <jyasskin>
annevk: Ah, no, the AudioWorklet spec says they're multiplexed onto the rendering thread: https://webaudio.github.io/web-audio-api/#AudioWorklet

[10:34:35.0000] <annevk>
jyasskin: I guess I don't understand why that's okay, but it's not okay for workers

[10:34:56.0000] <annevk>
jyasskin: other than worklets being a subset they're fundamentally the same, and audio worklets also have a messaging channel

[10:36:10.0000] <jyasskin>
annevk: I'm not certain why it doesn't work for workers. I think it has something to do with their synchronous APIs, but I don't know the JS engine details that prevent us from pausing those to switch to another worker.

[10:37:13.0000] <annevk>
jyasskin: so maybe it only applies to dedicated workers because of Atomics.wait?

[10:37:24.0000] <annevk>
jyasskin: I guess that must be it

[10:40:29.0000] <jyasskin>
I'd also include synchronous XHR and probably some of the OffscreenCanvas API, but again I'm not certain.

[10:41:55.0000] <annevk>
jyasskin: according to lth it's problematic for anything that can wake

[10:42:19.0000] <annevk>
jyasskin: which seems to suggest these cooperative multithreading designs are somewhat at odds with SAB

[10:45:09.0000] <jyasskin>
annevk: That's the part I'm still missing. I see the conflict with Atomics.wait(), but that already explicitly guards itself with AgentCanSuspend() and so wouldn't be usable from a cooperative-multithreaded agent.

[10:46:38.0000] <annevk>
jyasskin: I think I convinced lth that the issue also arises with a document and a child document

[10:46:50.0000] <annevk>
jyasskin: next step is filing an issue to explore further when there's more time

[10:47:05.0000] <jyasskin>
Thanks :)

[10:47:11.0000] <jyasskin>
Also thanks for your Infra issue.

[10:50:52.0000] <ato>
Does anyone have a hotline to Hixie? http://software.hixie.ch/utilities/cgi/data/data appears to be malfunctioning.

[11:05:12.0000] <annevk>
jyasskin: did reach a resolution, apparently cooperative multithreading still meets the definition of fp

[11:05:32.0000] <annevk>
jyasskin: they just really want workers to be actually 1:1 with threads

[11:06:11.0000] <annevk>
jyasskin: fp being forward progress

[11:06:56.0000] <jyasskin>
And they probably would have written that into the forward progress definition if anyone knew how to specify forward progress precisely. The C++ committee is in the middle of years of work trying to specify the guarantees systems actually provide.

[11:18:07.0000] <annevk>
jyasskin: you mean requiring threads?

[11:18:54.0000] <annevk>
jyasskin: if they had done that that would've been bad for worklets and friends

[11:19:37.0000] <jyasskin>
annevk: We do need two different forward progress guarantees for Workers vs Worklets.

[11:20:48.0000] <jyasskin>
I don't know, I wasn't in the discussion, and maybe TC39 had other reasons for wanting a weaker FP guarantee for Workers than anyone actually wanted to implement.

[11:22:49.0000] <jyasskin>
Fundamentally, a dedicated Worker should be able to run "while (true){}" without blocking anything else, and Worklets, Service Workers, Tasklets, etc. shouldn't have that property. Right?

[12:30:20.0000] <annevk>
ato: in what way?

[12:31:52.0000] <annevk>
jyasskin: yeah, though [[CanBlock]] is not the signifier for this even though it rather strongly appears that way

[12:32:29.0000] <jyasskin>
[[CanInfiniteLoop]] would be more like it. ;)

[12:32:57.0000] <ato>
annevk: The ‘Generate’ button doesn’t create a data URI and redirects back to the main page.

[12:33:23.0000] <annevk>
ato: hmm works here

[12:34:12.0000] <ato>
annevk: Are you sure? In Firefox it does nothing, whereas Chrome complains about ERR_UNSAFE_REDIRECT.

[12:35:16.0000] <ato>
/me wonders if the Mozilla network people have broken something more when they tried fixing IPv6 for the nth time

[12:35:17.0000] <annevk>
ato: suspect navigating to data URLs is restricted in Fx too now

[12:35:51.0000] <annevk>
ato: I’m only aware of putting them in opaque origins

[12:36:09.0000] <ato>
Is that a CSP directive that should be whitelisted or somesuch?

[12:56:18.0000] <gsnedders>
TabAtkins: really I wouldn't object to using something like CSSOM View for a more WHATWG-like editorial expierments in the CSS WG

[13:11:56.0000] <rwaldron>
Are the substeps of "7.8.1 Navigating across documents", step 12 (found here: https://html.spec.whatwg.org/multipage/browsing-the-web.html#javascript-protocol ) always expected to occur in a later task queue?

[13:13:20.0000] <rwaldron>
It says "queue a task", so I'm assuming yes, but I'm reviewing tests for "javascript:" behaviors (in form action) and every browser disagrees

[13:37:30.0000] <annevk>
ato: no, basically no longer a feature, but not fully standardized either

[13:38:23.0000] <annevk>
rwaldron: there are some known issues; don’t remember any on timing though

[13:38:34.0000] <annevk>
rwaldron: would be good to file

[14:14:32.0000] <domfarolino>
annevk: (Domenic too): where would you recommend domintro boxes for the fetch spec go, below the class IDL in section 5? That seems to be a good place as that's where the event domintro box is in the dom spec.

[15:03:26.0000] <TabAtkins>
gsnedders: Strongly agree. It's a low-churn spec, and most changes are just implementation-chasing anyway; it seems perfect for doing WHATWG-style.

[15:06:51.0000] <jyasskin>
Domenic/bz: I'm reviewing https://github.com/w3c/webappsec-credential-management/pull/93, and pulling on thread-safety keeps getting hairier. For example, [[Store]] currently takes a Credential instance, but it's called in parallel, so reading fields off instances isn't allowed. It seems like we're assuming that a struct-of-primitives is made and copied before going in parallel, and that exactly which struct it is

[15:06:51.0000] <jyasskin>
depends on which subtype of Credential we got. Do any other specs demonstrate concise ways to describe this?

[15:26:16.0000] <jyasskin>
(I could be wrong about whether reading fields off instances is disallowed. If they're otherwise readonly, maybe it's ok? I think this isn't specified anywhere.)


2017-10-03
[18:59:40.0000] <Domenic>
domfarolino: that sounds great to me. One for each class, I think

[19:00:57.0000] <Domenic>
jyasskin: if the fields on the instances never change, then it's OK, although perhaps it's a bit trickier for the reader to know that ahead of time. (Although, indirecting through more abstraction might also be trickier for the reader.)

[19:01:21.0000] <Domenic>
jyasskin: I think Fetch does this pretty well with its `Response`-has-an-associated-response-struct separation?

[19:02:54.0000] <domfarolino>
Domenic: Perfect. Also...I was considering submitting a PR to wpt removing https://github.com/w3c/web-platform-tests/blob/master/fetch/api/request/request-idl.html#L40 and some other lines that use the `type` parameter since https://github.com/whatwg/fetch/pull/582 has been merged, does this sound OK, as correct implementations incorrectly fail a couple tests now?

[19:03:20.0000] <domfarolino>
Or would we want to take it a step further and assert that `type` does not exist as an attribute or something (less confident in this option)

[19:04:30.0000] <Domenic>
Oh, yeah, so updating the IDL tests is always good. foolip has been looking into centralizing all of those into https://github.com/w3c/web-platform-tests/tree/master/interfaces .

[19:04:42.0000] <Domenic>
Adding a -historical.html test that asserts that something is gone is a nice bonus

[19:05:35.0000] <Domenic>
Example https://github.com/w3c/web-platform-tests/blob/master/html/semantics/tabular-data/historical.html (but there are lots of different styles if you Ctrl+F for historical.html)

[19:10:29.0000] <domfarolino>
Domenic: Thanks!

[21:37:06.0000] <jyasskin>
Domenic: https://fetch.spec.whatwg.org/#concept-response-response does kind of exemplify the problem: since fields of the response struct change, it's not really any safer to use in parallel than the interface that it's associated with.

[21:50:40.0000] <annevk>
jyasskin: they can change but not always

[21:50:59.0000] <annevk>
jyasskin: we discussed this here recently

[21:51:39.0000] <annevk>
jyasskin: my suggestion was that we ensure things are safe via review and try to uplift as we learn

[21:52:58.0000] <annevk>
jyasskin: our type system is still incomplete too; suspect when that is better and we have more common operations defined we can suitably restrict in parallel

[21:56:02.0000] <jyasskin>
annevk: Yeah, reviewing for actual races seems reasonable. Are we also avoiding use of interfaces from parallel sections, or just avoiding races on their fields?

[21:56:26.0000] <jyasskin>
(In particular, readonly fields and internal slots could be safe.)

[21:57:00.0000] <annevk>
jyasskin: only internal slots could be safe

[21:57:42.0000] <annevk>
jyasskin: it seems okayish to do that, maybe with a note explaining why you need not be alarmed

[21:57:44.0000] <jyasskin>
... because readonly fields' getters use something from the current global?

[21:58:39.0000] <annevk>
jyasskin: yeah, and because we don’t know if it still holds the same getter

[21:58:54.0000] <jyasskin>
'k, thanks.

[00:19:02.0000] <domfarolino>
annevk: Is it possible to observe anything besides "about:client" or "" when looking at Request.referrer? My understanding is that the fetch algorithm may set the Request's referrer to a URL, but this will be on a copy of the passed in Request object...so can you ever observe this URL in application code?

[00:41:23.0000] <annevk>
domfarolino: in a service worker, but you can also set it to a same-origin URL

[00:48:35.0000] <domfarolino>
annevk: ah ok how do

[00:48:50.0000] <domfarolino>
annevk: you set it?

[00:49:50.0000] <annevk>
annevk: fetch(url, { referrer: "/hi" })

[05:30:49.0000] <tobie>
annevk: think you can take a look at: https://github.com/whatwg/infra/pull/155#issuecomment-332964862 at some point?

[05:33:17.0000] <annevk>
tobie: oh sorry, I thought that landed already

[05:33:26.0000] <tobie>
annevk: np

[05:36:21.0000] <annevk>
tobie: squashed and merged

[05:36:30.0000] <tobie>
annevk: ta

[05:36:46.0000] <annevk>
tobie: feel free to ping sooner next time

[05:37:03.0000] <annevk>
tobie: if I haven't replied within a day or two it's highly likely I missed something

[05:37:06.0000] <tobie>
annevk: the pr that needs it is far from being ready

[05:37:27.0000] <tobie>
annevk: so there was no reason to stress anyone out. :)

[06:40:39.0000] <rwaldron>
annevk thanks for the confirmation

[06:43:06.0000] <annevk>
rwaldron: I hope you can find some joy in working on this, since there's a lot of sad things in that algorithm

[06:45:07.0000] <rwaldron>
I cannot lie, it's been a slog getting to where I am now. I have a WIP branch that includes informative prose that describes "what this test file is actually doing, and what spec parts are relevant to that end".

[06:46:21.0000] <annevk>
Coupled with reverse engineering browsers it can indeed be rather painful

[06:46:25.0000] <rwaldron>
Each file has a special multiline comment area that contains meta data (I'm using yaml, because it's easy to type)

[06:46:36.0000] <rwaldron>
Yes, I've been carrying around two computers for the last month

[06:46:56.0000] <rwaldron>
A MBP and Surface Book

[06:47:04.0000] <annevk>
What I personally enjoy about is that once I've solved some gnarly task like that hopefully nobody else will have to

[06:47:21.0000] <rwaldron>
That's definitely the silver lining

[07:48:24.0000] <tobie>
mkwst: Does `new A().foo()` throw a SecurityError in this context: [SecureContext, Constructor] interface A : B {}; interface B { void foo(); }; The spec says no. Can you confirm?

[07:50:20.0000] <Ms2ger>
Shouldn't new A() throw?

[07:50:26.0000] <Ms2ger>
/me didn't check

[07:54:22.0000] <tobie>
Ms2ger: oh, yes, of course.

[07:55:00.0000] <Ms2ger>
And I would hope new B() too, if it has a ctro

[07:55:01.0000] <tobie>
Ms2ger: Duh. Thanks

[07:55:05.0000] <Ms2ger>
Np :)

[07:55:23.0000] <tobie>
No, B wouldn't

[07:55:37.0000] <tobie>
(Why would it?)

[07:55:50.0000] <Ms2ger>
Oh

[07:55:57.0000] <Ms2ger>
I read B : A, not A : B

[08:07:02.0000] <tobie>
The fact that [Exposed] and [SecureContext] cater to both the interface and its members is confusing, imho

[08:07:43.0000] <tobie>
Especially once you have partials (and now mixins involved)

[08:07:58.0000] <tobie>
s/now/soon/

[08:54:55.0000] <annevk>
tobie: partials and mixin just inherit (unless they are specifically restricted I suppose)

[08:55:35.0000] <annevk>
tobie: but specific restrictions should prolly only work for members

[09:00:28.0000] <annevk>
hsivonen: please look at https://github.com/whatwg/html/pull/3091 if you have the chance (requiring UTF-8 throughout HTML)

[10:31:06.0000] <jyasskin>
TabAtkins: Is there a way to attach an [algorithm] attribute to a ### header, or do I need to convert back to <h3 algorithm>?

[10:31:54.0000] <TabAtkins>
Currently no, you have to use HTML markup. Happy to accept patches to the markdown processor to add attr/class support alongside the id support.

[10:32:17.0000] <jyasskin>
Thx

[13:25:46.0000] <wanderview>
Domenic: JakeA: do you think its fair to write a WPT test that does a respondWith() a ReadableStream, provides a single chunk but does not close, and then tests if the window see the data from the intercepted fetch() Response.body?

[13:26:18.0000] <wanderview>
Domenic: JakeA: I think this should work, but in theory the spec could allow some re-buffering that might delay some/all of the data if only a single chunk is sent

[13:26:51.0000] <Domenic>
ehhhhh maybe with an appropriate comment saying that you could still fail this and be spec-conformant, and that if a browser has problems with the test they should file an issue to discuss

[13:26:53.0000] <wanderview>
I could write this as a firefox specific test instead of a WPT if we think that test is too strict

[13:26:54.0000] <Domenic>
Why not just close the stream?

[13:27:33.0000] <wanderview>
Domenic: because I specifically want to test that streaming works... for example, today chrome and firefox behavior differently on this test: https://html-sw-stream.glitch.me/

[13:27:48.0000] <wanderview>
Domenic: firefox won't send any data to the outer window until the body is closed today

[13:28:08.0000] <wanderview>
I'm fixing that

[13:28:10.0000] <Domenic>
Hmmm

[13:28:16.0000] <Domenic>
I guess I see your point

[13:28:31.0000] <Domenic>
As long as it has appropriately liberal timeouts (e.g. the default WPT timeout)

[13:28:47.0000] <Domenic>
i.e. it's just like chunk received, then t.done()

[13:29:14.0000] <wanderview>
Domenic: I was planning to receive chunk, then postMessage() the SW to close the stream, cleanup and done

[13:29:25.0000] <Domenic>
oh, why?

[13:29:43.0000] <wanderview>
Domenic: to allow the service worker to gracefully cleanup instead of timing out

[13:30:02.0000] <Domenic>
I guess I don't understand enough about service workers to know why that would matter

[13:30:54.0000] <wanderview>
you can't unregister the service worker fully until its done processing any outstanding events... so if you only partially provide the body to respondWith() then the worker may live for a few minutes... that could screw up later tests

[13:31:31.0000] <wanderview>
I guess I have to waitUntil() to hold the worker alive since we haven't done any magic respondWith()+ReadableStream lifetime stuff

[14:35:32.0000] <wanderview>
Domenic: JakeA: FWIW this is the test I came up with: https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=1204254&attachment=8914930


2017-10-04
[17:38:11.0000] <jyasskin>
tobie: Quick mention: https://github.com/w3c/webappsec-credential-management/pull/100#discussion_r142558995 is also considering using callback functions to hold references to platform functions, as mentioned in the issue under https://heycam.github.io/webidl/#idl-callback-functions. I didn't see a github issue to mention this in.

[19:24:04.0000] <Domenic>
That seems OK?

[19:26:27.0000] <jyasskin>
Domenic: I think I agree we should allow it. WebIDL currently says "An identifier that identifies a callback function is used to refer to a type whose values are references to objects that are functions with the given signature.", but a platform function isn't a reference to an object.

[19:26:40.0000] <Domenic>
It isn't?

[19:28:00.0000] <jyasskin>
Domenic: Hm. Well, if it is, it's a Javascript object, and then calling the function involves conversions to and from JS. Isn't that slower than a direct call to an algorithm?

[19:28:24.0000] <Domenic>
Oh, yeah, for sure, are you not trying to call the platform function?

[19:28:38.0000] <Domenic>
If you're trying to just invoke the algorithm, you should do that instead of indirecting through the callback function type

[19:29:13.0000] <jyasskin>
(I have to run off for 30 minutes, sorry.)

[19:55:41.0000] <jyasskin>
Domenic: Ok, son's in bed. Right now, we're having implementations of Credential.[[Create]] return an algorithm that Credential's algorithms queue onto the main thread. It seemed like it might have been cleaner to say that was a callback function, but I think you're saying we should just say it's an algorithm. Or possibly we should choose another way to express it entirely.

[19:56:20.0000] <Domenic>
Yeah, it seems cleaner to have it be an algorithm, unless you actually need the JS engine involved in some way.

[19:56:38.0000] <Domenic>
I mean, do you anticipate implementers actually going through their Web IDL bindings? If not, then don't use a Web IDL type.

[20:04:20.0000] <jyasskin>
Domenic: That sounds like a good rule of thumb; thanks.

[22:31:03.0000] <annevk>
We should really make it so that invoking JS or IDL end points requires some kind of review

[03:12:19.0000] <zcorpan>
MikeSmith: would be nice to have conformance-checker/ tests for the utf-8 change also

[03:14:23.0000] <zcorpan>
/me will write tests for chocolate :-P

[03:26:07.0000] <annevk>
/me wonders what EU law states around companies refusing to remove former addresses from accounts

[03:33:04.0000] <zcorpan>
http://www.datainspektionen.se/lagar-och-regler/eus-dataskyddsreform/ (in Swedish; this reform doesn't apply until May 2018. Currently for Sweden there's http://www.datainspektionen.se/lagar-och-regler/personuppgiftslagen/ which the reform will replace; not sure what the deal is for other countries)

[04:15:58.0000] <annevk>
zcorpan: does that cover this? I tried to skim through the one published on the EU site, but it was rather dense

[06:26:39.0000] <annevk>
Given text/html;charset=gbk;charset=utf-8 what's the encoding going to be?

[06:51:00.0000] <annevk>
It is hard to believe that no normative text on MIME type parameters even discusses the possibility of duplicates

[06:56:42.0000] <Ms2ger>
Not all that hard...

[07:18:23.0000] <gsnedders>
annevk: depends on the type of company, and why they want to keep the former address?

[07:18:48.0000] <tobie>
foolip: sorry, you're having such a bad time with the different pieces of software I built. Thing is, they've all been built on a shoestring budget (essentially my own free time) and no one wants to invest in them, so…

[07:19:18.0000] <foolip>
tobie: specref has been great, really

[07:19:34.0000] <foolip>
tobie: it's not your fault the upstream DB isn't proactively maintained

[07:19:52.0000] <foolip>
tobie: and the PR reviewer assigner is also great

[07:20:02.0000] <tobie>
foolip: at least, now that Heroku stepped up, I no longer have to pay for hosting those.

[07:20:48.0000] <annevk>
gsnedders: do you have a reference?

[07:20:55.0000] <gsnedders>
annevk: no :)

[07:21:38.0000] <tobie>
foolip: yeah, PR preview was a lot easier: clear scope upfront.

[07:21:43.0000] <gsnedders>
annevk: but, e.g., financial companies and companies who've had large transactions with you are likely obliged due to money laundring regulation

[07:22:38.0000] <tobie>
foolip: specref + wpt-pr-bot were just duct taped as we moved along.

[07:22:53.0000] <gsnedders>
tobie: did we not spray some WD-40 in there at some point?

[07:23:17.0000] <tobie>
gsnedders: probably, which is why everything is now slippery

[08:47:43.0000] <wanderview>
JakeA: I know you are traveling today, but when you get a chance can you sanity check something for me?  does it make any sense that this should expect .workerStart on a performance timeline entry for an intercepted <script> request? https://github.com/w3c/web-platform-tests/blob/master/service-workers/service-worker/resource-timing.https.html#L13

[08:57:17.0000] <wanderview>
JakeA: oh, I think MDN confused me... looking at the spec this is specifically to capture the service worker start time

[08:57:20.0000] <wanderview>
nm

[09:10:48.0000] <annevk>
Domenic: I think I found some more <script> follow-up, <script language> executes too

[09:13:30.0000] <Domenic>
hmm and the spec doesn't support this?

[09:15:29.0000] <annevk>
Domenic: processing model does, but there's some inconsistency in the obsolete-but-conforming section

[09:19:40.0000] <annevk>
Domenic: also https://github.com/bmeck/I-D/issues/2#issuecomment-334207482

[09:21:25.0000] <Domenic>
Not sure what the action is there, you mean we should change HTML to recommend something for servers?

[09:21:39.0000] <annevk>
Domenic: yeah

[09:21:55.0000] <annevk>
Domenic: there's no normative statement corresponding to the MIME type summary of everything but text/javascript being obsolete

[09:22:06.0000] <Domenic>
Hmm ok

[09:22:28.0000] <Domenic>
Makes sense, please file both so I don't lose track, as I'm still feeling kinda behind after BlinkOn and TC39

[09:22:58.0000] <annevk>
Domenic: will do, looking into a PR for the former

[09:23:50.0000] <annevk>
I no longer think the former is a problem, since the requirement is subtly different from type

[10:30:19.0000] <annevk>
Domenic: I haven't seen much come out regarding either so far

[10:30:53.0000] <annevk>
Domenic: I did read some TC39 minutes, but not all the days yet

[10:31:24.0000] <Domenic>
Either what?

[10:34:23.0000] <annevk>
Domenic: BlinkOn or TC39 in terms of announcements or stuff to watch

[10:34:35.0000] <annevk>
I see now that import.meta is pretty close to done though

[10:37:10.0000] <Domenic>
Ah yeah

[10:37:22.0000] <annevk>
Float16 Typed Arrays, hmm, I wonder if the high definition color folks might want to reconsider using that

[11:07:43.0000] <TabAtkins>
annevk: What do you mean?

[11:33:07.0000] <Domenic>
I think they were currently considering using Float32Arrays in some strange format?

[11:33:45.0000] <Domenic>
"ImageData uses float32, which is inefficient due to memory consumption and necessary conversion operations. Float32 was chosen because it is convenient for manipulation (e.g. image processing) due to its native support in JavaScript (and current CPUs). A possible extension would be to add and option for rec-2020 content to be encoded as float16s packed into Uint16 values. "

[11:33:49.0000] <Domenic>
from https://wiki.whatwg.org/wiki/CanvasColorSpace

[11:42:58.0000] <TabAtkins>
Float32 doesn't have native support in JS? JS is all float64.

[11:47:59.0000] <jyasskin>
TabAtkins: It converts back and forth: https://tc39.github.io/ecma262/#sec-numbertorawbytes

[11:48:31.0000] <TabAtkins>
Ah, by "native support" they just mean "in Typed Array"?

[11:48:56.0000] <TabAtkins>
We just need to add Float16 to Typed Arrays, honestly.

[12:02:15.0000] <Domenic>
that is literally what the discussion was about :)

[13:20:21.0000] <tobie>
TabAtkins: given the below DFNs, how would you organize them in Bikeshed (when/how would you use the "for" attribute and why)?

[13:20:28.0000] <tobie>
https://www.irccloud.com/pastebin/tda6zUq1/

[13:22:52.0000] <tobie>
TabAtkins: here's the relevant PR for context: https://github.com/heycam/webidl/pull/433

[13:23:24.0000] <tobie>
TabAtkins: (Which doesn't include dictionary mixins)

[13:28:23.0000] <jyasskin>
tobie: In cases like that, if I'm happy writing out "partial dictionary mixin" wherever it's used, I'd just make that the <dfn> with no [for]. If not, I'd probably make "mixin" or "member" the [lt] with "*interface", "*dictionary" or "mixin" the [for].

[13:28:28.0000] <jyasskin>
But that's just me.

[13:30:55.0000] <tobie>
jyasskin: so convenience over system.

[13:31:37.0000] <tobie>
(or should I say "convenience as a system"?)

[13:39:39.0000] <TabAtkins>
Domenic: Yeah, I (eventually) got that; annevk's comment came out of nowhere and didn't have the context for me to understand the convo. ^_^

[13:41:05.0000] <TabAtkins>
tobie: "for" is a namespacing mechanism. Interfaces and dictionaries live in the same namespace; partials are the same. Presumably mixins are the in the same namespace too? (I don't think they *have* to be, but it would be convenient to have that guarantee.)

[13:41:32.0000] <TabAtkins>
members are all namespaced to their interface/dictionary/whatever, because you can have multiple members with the same name if they're in different interfaces.

[14:44:39.0000] <tobie>
TabAtkins: so the term "interface member" would reside in the same (global) namespace as "interface"?

[14:44:53.0000] <TabAtkins>
Oh, the *terms*?

[14:45:02.0000] <TabAtkins>
Sorry, I completely misunderstood the question.

[14:45:14.0000] <TabAtkins>
They're all independent dfns, no for.

[14:48:57.0000] <tobie>
TabAtkins: gotcha, thanks!

[14:51:52.0000] <TabAtkins>
Ugh, I wish I'd actually thought about the namespacing of IDL before I made all the IDL dfn types.

[14:52:27.0000] <TabAtkins>
Interfaces/dictionaries/callbacks/typedefs all live together, and attr/methods/constructors live together. They should have just been two types, not 7.

[14:53:21.0000] <MikeSmith>
noticing *Enabled File and Directory Entries API* in https://developer.apple.com/safari/technology-preview/release-notes/

[14:56:07.0000] <MikeSmith>
https://wicg.github.io/entries-api/

[14:56:10.0000] <MikeSmith>
so we now have three shipping implementations of that

[14:58:52.0000] <MikeSmith>
jsbell: are there WPT tests for it?

[14:58:54.0000] <tobie>
TabAtkins: it's always easier in hindsight.

[15:22:22.0000] <jsbell>
MikeSmith: Sorry, was at the dentist...

[15:22:40.0000] <jsbell>
MikeSmith: https://github.com/w3c/web-platform-tests/pull/6142

[15:22:53.0000] <jsbell>
MikeSmith: Want to review? :)

[15:23:01.0000] <jsbell>
Sadly, mostly .manual

[15:23:23.0000] <jsbell>
Wait WAT? That'd be 4 implementations

[15:26:32.0000] <jsbell>
MikeSmith: Curious how you counted 3 implementations, though.

[15:37:33.0000] <MikeSmith>
jsbell: I was counting Blink, Gecko, and WebKit

[15:37:41.0000] <MikeSmith>
what are you counting?

[15:37:45.0000] <jsbell>
MikeSmith: Edge has it too

[15:39:21.0000] <MikeSmith>
oh wow great

[15:39:46.0000] <MikeSmith>
well that’s a pretty nice success story

[15:40:54.0000] <jsbell>
MikeSmith: Well, Edge added directory upload support to be compatible with Chrome, Firefox dropped an alternate proposal and just went with compatibility.

[15:40:54.0000] <MikeSmith>
jsbell: is there a Chrome developer advocate responsible for this API?

[15:41:02.0000] <MikeSmith>
ah OK

[15:41:34.0000] <MikeSmith>
well I’m kinda surprised we haven’t been getting the word out about this more

[15:41:57.0000] <MikeSmith>
I think there are a lot of web developers who don’t know about this

[15:42:25.0000] <jsbell>
MikeSmith: A bit of sordid history because there was a cleaner API proposal, but this de facto one codifies the webkit prefixes and crufty API.

[15:42:28.0000] <MikeSmith>
anyway, I’ll review the tests today, and get them merged

[15:42:32.0000] <jsbell>
But that's life.

[15:42:37.0000] <jsbell>
MikeSmith: thanks!

[15:42:54.0000] <MikeSmith>
ah yeah I now start to remember the history a bit more

[15:42:59.0000] <MikeSmith>
it’s been a while

[15:43:05.0000] <jsbell>
MikeSmith: I'm on point as much as anyone is for them on the Chrome side. I can point one of my MDN editor friends at it if we need to doc 'em more

[15:43:46.0000] <jsbell>
There are old  html5rocks articles from back when we (Chrome) thought the whole FileSystem API was going to be the hot new thing.

[15:43:56.0000] <MikeSmith>
yeah those I remember

[15:44:16.0000] <jsbell>
So... we didn't evangelize more since there wasn't uptake elsewhere until recently.

[15:44:37.0000] <MikeSmith>
OK well we can change that

[15:44:40.0000] <MikeSmith>
and as far as the MDN docs, I could help with those

[15:46:10.0000] <MikeSmith>
jsbell: oh wait why are these all manual tests? just because of the user interaction needed around granted permission?

[15:46:17.0000] <jsbell>
MikeSmith: yah

[15:46:31.0000] <MikeSmith>
OK

[15:46:36.0000] <jsbell>
MikeSmith: The only way to trigger most of the API is dragging a file/directory in

[15:46:43.0000] <jsbell>
If there's fancy webdriver magic that can do that, great.

[15:46:44.0000] <MikeSmith>
yeah, makes sense

[15:47:02.0000] <MikeSmith>
I think we can get it automated with webdriver eventually

[15:47:08.0000] <MikeSmith>
gsnedders has been working on it

[15:47:47.0000] <MikeSmith>
working on the general problem of automating WPT tests using webdriver that are currently manual

[15:47:53.0000] <jsbell>
ossm

[15:48:18.0000] <MikeSmith>
there’s no test yet for the IDL conformance?

[15:48:25.0000] <MikeSmith>
you know what I mean?

[15:48:34.0000] <jsbell>
I'll be curious to see how Safari did on the edge cases, and whether they matched Chrome's behavior or the slightly more aspirational version in the spec...

[15:48:41.0000] <jsbell>
MikeSmith; there should be two, hrm...

[15:49:02.0000] <MikeSmith>
ah nm

[15:49:02.0000] <jsbell>
MikeSmith: interfaces.html and interfaces-manual.html

[15:49:26.0000] <MikeSmith>
yeah, github UI was spinning while loading the tests

[15:49:41.0000] <MikeSmith>
still spinning

[15:50:01.0000] <MikeSmith>
anyway I should just go ahead and check them out locally

[15:50:18.0000] <jsbell>
yay, thanks for your help/interest/encouragement!

[15:50:37.0000] <MikeSmith>
thank you for doing all the hard work! :)

[15:52:33.0000] <MikeSmith>
jsbell: oh btw have these tests already had any Chrome-team review?

[15:53:09.0000] <jsbell>
MikeSmith: good question, let me see... I did them outside our repo so maybe I didn't...

[15:56:08.0000] <jsbell>
MikeSmith: let's go with "no"; I can rope someone into that if it helps. We're NOT running these as part of our CI yet. (We have a suite of non-WPT tests)

[15:56:37.0000] <MikeSmith>
OK

[15:56:55.0000] <MikeSmith>
no need to rope in anybody else

[15:58:25.0000] <jsbell>
MikeSmith: off to a mtg now; if you comment here I'll see it eventually tho

[15:58:40.0000] <MikeSmith>
hai

[16:05:38.0000] <MikeSmith>
jsbell: (when you’re back) can you please make your branch writeable by WPT maintainers so I can rebase it against current WPT master and push?

[16:06:20.0000] <MikeSmith>
and also so I can fix some minor lint errors myself


2017-10-05
[17:04:44.0000] <jsbell>
MikeSmith: will do...

[17:05:15.0000] <jsbell>
MikeSmith: done

[17:05:32.0000] <jsbell>
Yeah, I think it predates some (all?) lint checks

[17:06:49.0000] <jsbell>
MikeSmith: dropping off now, so followups -> email/github. Thank you VERY much for your help!

[01:42:05.0000] <mkwst>
annevk: jochen__ just closed https://bugs.chromium.org/p/chromium/issues/detail?id=760096#c6 as WontFix, which reminded me how much I hate that `file:` URLs can have hostnames.

[01:42:28.0000] <mkwst>
Before I go through the trouble of adding metrics, would you fundamentally object to not allowing hostnames? :)(

[01:43:07.0000] <annevk>
mkwst: probably not, file URLs already have a lot of special cases in the parser

[01:43:26.0000] <annevk>
mkwst: it's probably worth raising an issue at the same time though since Node.js uses file URLs a fair bit too

[01:43:55.0000] <annevk>
mkwst: the other thing you could do of course is block them at the resolve layer

[01:43:57.0000] <mkwst>
I'd add metrics before raising an issue. No point in poking if there's no way to follow through.

[01:44:01.0000] <annevk>
mkwst: maybe that's cleaner

[01:44:19.0000] <mkwst>
Sure. Chrome could decide that it doesn't like the behavior. But I'd like other folks on board.

[01:44:42.0000] <mkwst>
Eh. I guess? I'm not sure what's simpler to implement, really, since I think we delegate to the OS for filesystem access.

[01:44:44.0000] <annevk>
We haven't really defined how file URLs resolve since it's platform dependent

[01:45:15.0000] <annevk>
You'd have to gate those calls somehow if you block at the resolve layer

[01:45:59.0000] <mkwst>
I haven't looked at any of the code. Maybe it's trivial.

[01:46:31.0000] <mkwst>
But I know it's trivial to remove the URL-parsing special case in Chrome's URL library, so. :)

[02:00:24.0000] <mkwst>
annevk: Hey, more file things! https://bugs.chromium.org/p/chromium/issues/detail?id=756416#c3

[02:00:33.0000] <mkwst>
I'll file something against... HTML, I guess?

[02:01:07.0000] <mkwst>
Or maybe URL, which already hand-waves in the direction of opaqueness for `file:`?

[02:01:37.0000] <annevk>
mkwst: the main problem is getting user agents to agree

[02:01:47.0000] <annevk>
mkwst: is it consistently cross-origin in Chrome or can you still do XHR?

[02:01:55.0000] <mkwst>
Yeah. Which is why I'd file a bug for discussion.

[02:02:29.0000] <mkwst>
I'm just looking now, actually. I remember that we had some strange carveouts where we called the origin `file:` for all file URLs,  but I don't recall the details.

[02:03:10.0000] <annevk>
mkwst: I guess it would be HTML, since URL gives an opaque origin for data URLs too, but that's not always what we do because of overrides

[02:03:31.0000] <mkwst>
Got it.

[02:03:44.0000] <annevk>
mkwst: Firefox has some kind of same-or-deeper directory thing going on

[02:04:03.0000] <mkwst>
Yeah. We considered that, but intentionally chose not to because of the downloads directory.

[02:04:06.0000] <annevk>
mkwst: it doesn't really seem worth it and will probably all go away the more we force HTTPS

[02:04:30.0000] <annevk>
mkwst: that's a compelling argument

[02:04:41.0000] <mkwst>
On the HTTPS note, I saw that you poked at dev-platform@ regarding pushing for secure contexts.

[02:05:00.0000] <mkwst>
Is there anything I can do there to help out? Other than poking at folks on Chrome's end in the same way?

[02:06:09.0000] <annevk>
mkwst: I need to talk to some more folks and at some point I mean to investigate what Chrome has disabled and Firefox has not

[02:06:53.0000] <annevk>
mkwst: if the latter is available somewhere that'd be swell, but I don't see anything else right now (other than pushing the worklets folks up the hill and getting a story for CSS and such)

[02:07:28.0000] <annevk>
mkwst: agreed with your review on the TAG PR too, FWIW

[02:07:52.0000] <mkwst>
There's an internal thread among API owners that wasn't actually meant to be internal. Will try to externalize that when folks wake up.

[02:08:18.0000] <annevk>
I saw the public thread, but there weren't many convincing arguments there

[02:08:27.0000] <mkwst>
But it's more or less the same story. slightlyoff, jochen__, and I are the bad cops.

[02:09:23.0000] <annevk>
The resistance mostly seems to be that transition is hard

[02:10:01.0000] <annevk>
But the argument also changes, since first the resistance was that it would be too expansive or too slow

[02:23:25.0000] <nox>
annevk: I need a poster image for a <video> in wpt,

[02:23:30.0000] <nox>
annevk: what image should I use?

[02:23:56.0000] <nox>
Oh, media/poster.png

[02:25:35.0000] <annevk>
Glad you found something 😊

[02:27:24.0000] <nox>
Hah. :)

[02:27:35.0000] <nox>
annevk: Almost done with them tests,

[02:28:38.0000] <nox>
annevk: and I have a question: there is nothing that lets me know whether a poster frame loaded, apart from making sure the poster frame starts loading before the document's load event, so that I can do stuff in the onload handler?

[02:30:10.0000] <annevk>
nox: I don't know about that either

[02:30:29.0000] <annevk>
nox: I was really only closely involved with <video> before it became all complicated

[02:32:33.0000] <nox>
annevk: Hah!

[02:33:08.0000] <nox>
annevk: tfw local clone is thousands of commits in the past and you need to push all of them to make a PR with a single test

[06:09:23.0000] <annevk>
And as we get closer to requiring UTF-8 all over, XMLHttpRequest and Firefox have to regress on that point: https://github.com/whatwg/xhr/issues/159

[06:09:58.0000] <annevk>
It even had a test, but I suspect no bugs were filed back then

[06:10:43.0000] <annevk>
Makes me wonder whether we test fetch() for this

[08:30:14.0000] <wanderview>
JakeA: do you know who knows about chrome performance timeline stuff with service workers involved?

[08:35:47.0000] <wanderview>
just trying to figure out: https://github.com/w3c/resource-timing/issues/119

[08:39:20.0000] <JakeA>
wanderview: falken maybe?

[08:40:01.0000] <wanderview>
JakeA: ok... I pinged him in the github issue... thanks

[08:40:09.0000] <wanderview>
these values are pretty confusing right now

[10:33:17.0000] <ondras>
damn, apparently font-size:calc(1vw*1vh) is not possible :/

[10:33:26.0000] <ondras>
why not? sounds like a useful idea.

[10:38:00.0000] <Domenic>
annevk: mkwst: according to https://quuz.org/url/liveview.html#file://x.jd.com/mkt/pcwap?&callback=dsp_1504020242543&r=1504020242544 in Firefox there is no hostname there, at least. So that's a point in its favor.

[11:00:10.0000] <mkwst>
Domenic: Great! Go file a bug against every other browser to align with Firefox!

[11:27:06.0000] <Krinkle>
JakeA: I'm curious about your thoughts on Wikimedia's approach to the client-side caching of javascript/css module bundles. As you might know, we currently do it as follows (in a nut shell): JS has a module manifest (dependency tree and version hashes), and an array of modules names to load on this page. For each module+version key it checks localStorage, and if present, evals it. Any remaining modules are fetched from the server in 1 batch

[11:27:06.0000] <Krinkle>
request. On response, after normal execution, we also stash each module's response closure from the batch request into localStorage.

[11:27:26.0000] <Krinkle>
I've considered using ServiceWorkers and/or its Cache API in various ways over the past 2 years but always came back to the current solution.

[11:29:30.0000] <TabAtkins>
ondras: Because it's multiplying a length by a length, so the unit ends up being length^2.  (V&U 4 will allow unit algebra, so you can divide that expression by 1px and get back to a plain length, and that's already specified in the TypedOM spec.)

[11:29:59.0000] <ondras>
@TabAtkins: yeah, I would happily divide that by Npx to get to a reasonable unit

[11:30:16.0000] <ondras>
TabAtkins: ^ (sorry for bad highlight)

[11:30:26.0000] <Krinkle>
The main reason I want to get out of localStorage is because it's synchronous and because it's limited and is sometimes breaking user features when its full (e.g. 99% full with js/css, no space for "normal" usage like small key/value pairs for things like hiding notices or keeping track of collapsed/expanded state of something).

[11:30:26.0000] <ondras>
ideally, I would like to take a square root tho

[11:32:12.0000] <Mek>
replacing localstorage usage with cache API usage or something definitely sounds like a sensible thing to do

[11:38:56.0000] <Krinkle>
At first I tried the "obvious" way with proper ServiceWorker intercepting network requests, and disabling the main thread logic of using localStorage.

[11:40:29.0000] <Krinkle>
That means the SW thread needs to unpack the request url to find the raw list of module names again, then it needs access to the module manifest (postMessage, or separate request), and then for each moduleName/moduleVersion, construct a non-batch fake url and do cache lookups, then the logic is essentially the same as before: Make a batch request for the cache misses, and then mimick the server-side's logic of concatenating the hits from Cache

[11:40:29.0000] <Krinkle>
and cache-miss-batch responses.

[11:40:51.0000] <Krinkle>
The downside is that now the whole thing is a lot slower. we used to eval modules right away from those that are in the cache. I don't wanna block those on 1 cache  miss.

[11:40:57.0000] <Krinkle>
And JS responses don't stream execution.

[11:42:05.0000] <Krinkle>
So it seems more natural to ditch the SW part of it, and do the cache lookups in the main thread instead, but that means resorting to eval again, which is fine I suppose, (as long as V8's parse cache still works, which seems to be fine for us at the moment).

[11:44:06.0000] <wanderview>
Krinkle: what do you mean by "And JS responses don't stream execution."

[12:00:43.0000] <Krinkle>
wanderview: Given 10 keys, where 8 are going to hit cache. We currently read from localStorage, eval, and then request 2 from network. At this point, the first 8 modules are not waiting or blocked, they're executed and are done.

[12:01:06.0000] <Krinkle>
If I'd do the same in SW, I'd have to wait for the batch request for the remaining 2 modules in order to concat the response and send it back to the client.

[12:01:27.0000] <Krinkle>
E.g. given the client making a request for 10, SW.js unpacking it and composing it of 8 cache entries and the real request for 2 more.

[12:01:33.0000] <wanderview>
Krinkle: even with ReadableStream in the service worker script?

[12:01:44.0000] <Krinkle>
wanderview: I can stream alright, but JS doesn't execute in a streaming way.

[12:02:05.0000] <Krinkle>
Even if Chrome/V8 does streamed parsing (does it?), it certainly won't execute any JS code until the last byte arrives afaik.

[12:02:52.0000] <wanderview>
Krinkle: ah, ok

[12:03:09.0000] <gsnedders>
well you can't given JS semantics

[12:03:21.0000] <gsnedders>
oh wait that was literally your previous line

[12:04:05.0000] <Krinkle>
Yeah, I get it. I'm not blaming the browser here. Just looking for a suitable way to get this stash out of localStorage without making things worse :)

[12:05:17.0000] <wanderview>
Krinkle: I wonder if streaming html with <script> tags would let them evaluate incrementally

[12:06:03.0000] <gsnedders>
wanderview: yes

[12:06:05.0000] <Krinkle>
wanderview: Yeah, I suppose it would. but is there a way to stream HTML into an existing browsing context? Maybe with an iframe, that then accesses the parent.

[12:06:20.0000] <Krinkle>
but I don't expect code to then work as-is.

[12:06:35.0000] <Krinkle>
Any use of 'window' or 'document' would be broken.

[12:07:01.0000] <Krinkle>
For a single script that would work, but not with e.g. existing code base or something like jquery.js or any standard lib.

[12:07:38.0000] <Krinkle>
dependency injection is nice, but use of browser APIs directly is quite common, DI in JS hasn't gotten much traction yet.

[12:16:48.0000] <Krinkle>
gsnedders: wanderview: JakeA: Thanks for your input :-) I summarised it again at https://github.com/w3c/ServiceWorker/issues/1203


2017-10-06
[02:22:33.0000] <Ms2ger>
annevk, ping re wpt #7574

[02:23:34.0000] <annevk>
Ms2ger: yeah?

[02:24:45.0000] <Ms2ger>
You think it makes sense to land with my edit? I'm not sure how well-specified stuff is with the window after removing the iframe?

[02:25:10.0000] <Ms2ger>
Or should I just land the document parts and leave the new test until we figured out the right behaviour

[02:25:36.0000] <annevk>
Ms2ger: I think for window.location it is defined, but I also think it's already tested per that issue I pointed to

[02:25:57.0000] <annevk>
Ms2ger: it's just that only Firefox implements it so far and other browsers haven't really investigated whether they can align

[02:26:54.0000] <annevk>
Ms2ger: so I'm not sure we need that new test, the other parts look okay

[02:28:20.0000] <Ms2ger>
Even better

[03:43:22.0000] <annevk>
So many MIME type parser bugs

[03:43:40.0000] <Ms2ger>
So very unsurprised

[04:21:45.0000] <gsnedders>
In other news, Scotland is overcast.

[05:28:34.0000] <annevk>
hsivonen: is there a canonical document for the UTF-16 being superior to UTF-8 due to size argument?

[06:15:21.0000] <annevk>
So, I've written a MIME type parser: https://github.com/whatwg/mimesniff/pull/36

[06:15:36.0000] <annevk>
I also have some ideas about how to refine how we define MIME types (basically copy what we do for URLs)

[06:16:01.0000] <annevk>
Input appreciated, including "fine, please proceed", "no, you should do X", etc.

[06:16:15.0000] <nox>
/me files bug because annevk's parser isn't written in Rust.

[06:17:46.0000] <annevk>
nox: I'd love to see the one written for Servo

[06:18:17.0000] <nox>
annevk: There is one, which had massive breaking changes in its last major version so Servo still lags behind. :(

[06:18:52.0000] <nox>
https://docs.rs/mime

[06:24:55.0000] <annevk>
nox: that library looks too strict for the web

[06:25:07.0000] <nox>
annevk: On which part?

[06:27:07.0000] <annevk>
nox: throwing parse errors when there's something wrong with a parameter

[06:28:16.0000] <nox>
annevk: I've heard at least once that we weren't too sure whether that is supposed to be an error or not.

[06:43:45.0000] <annevk>
nox: not sure if you all keep track of such a list, but I would expect any dependency that doesn't have reverse engineering of other browsers involved in it somehow to probably not be suitable

[06:44:44.0000] <annevk>
nox: in particular any IETF RFC tends to not reflect implementation reality

[06:45:03.0000] <nox>
Yeah I know that.

[10:38:26.0000] <Domenic>
TabAtkins: for my own edification, why are UA stylesheets better "when a particular value isn't good globally"? I don't really understand the functional difference between initial value and UA stylesheet.

[10:40:30.0000] <annevk>
Domenic: e.g., when you want <b> to be blue, but normally you want things to be black

[10:40:53.0000] <annevk>
Domenic: if we actually want it for *|*:root in this case though and the thing inherits, I'm not sure what the difference is

[10:41:26.0000] <annevk>
Domenic: well, I guess *|*:root would not apply to shadow trees, but not sure if that's a feature or not

[10:42:30.0000] <Domenic>
I think UA stylesheets apply to shadow trees, but maybe :root doesn't apply to shadow roots?

[10:43:24.0000] <annevk>
Domenic: the main question is whether things inherit into a shadow trees, maybe they actually do

[10:43:47.0000] <annevk>
I really don't know enough about this anymore by heart 😟

[11:00:39.0000] <TabAtkins>
annevk got it. Also yes, UA stylesheets apply in shadow trees, and inheritance crosses shadows by default.

[11:01:13.0000] <TabAtkins>
So yeah, UA stylesheet is for when a value is a good default for some elements only, or only for SVG vs HTML, etc.

[11:01:58.0000] <TabAtkins>
Also :root applies to all the top-level elements in a shadow tree.

[11:02:19.0000] <TabAtkins>
Oh wait, that's not true.

[11:05:20.0000] <TabAtkins>
But anyway, yeah, the only reason to ever run a *|*:root selector in the UA stylesheet is if, for some reason, you want it not to apply when people use "all" to block inheritance.

[11:07:58.0000] <Domenic>
Oh, I see, UA stylesheet is for when you need a more specific selector; you can't say "initial value for X elements". That makes sense.

[11:30:58.0000] <TabAtkins>
Yup, exactly.


2017-10-07
[22:46:51.0000] <GPHemsley>
wiki is down?

[22:47:01.0000] <GPHemsley>
(Cannot contact the database server)

[22:47:12.0000] <GPHemsley>
...I suppose I could check on that myself, but zzzz

[22:49:45.0000] <GPHemsley>
hmm... did the server get restarted after some bozo forgot to make the database server start at startup?

[22:49:58.0000] <GPHemsley>
/me wanders off mumbling to himself

[02:51:25.0000] <nox>
Is there any existing WPT stuff for https://github.com/servo/servo/issues/14390?

[06:53:09.0000] <Domenic>
nox: seems like https://github.com/w3c/web-platform-tests/pull/5911 ; also follow the links there

[06:53:32.0000] <nox>
Domenic: Thanks!

[07:34:03.0000] <ondras>
hmh

[07:34:07.0000] <ondras>
counter-reset: test var(--x)

[07:34:08.0000] <ondras>
works

[07:34:10.0000] <ondras>
counter-reset: test -var(--x)

[07:34:12.0000] <ondras>
does not work

[07:34:20.0000] <ondras>
unable to subtract a counter value, apparently

[07:38:14.0000] <Domenic>
Maybe need to use calc()

[08:11:13.0000] <GPHemsley>
ok, wiki is back up

[08:11:19.0000] <GPHemsley>
dunno why the database went down

[08:37:34.0000] <annevk>
GPHemsley: thanks for looking into it

[08:37:46.0000] <GPHemsley>
np

[08:38:20.0000] <annevk>
GPHemsley: do you know of any tests written for MIME Sniffing?

[08:38:38.0000] <GPHemsley>
I have a few basic, incomplete, probably useless ones

[08:39:03.0000] <GPHemsley>
http://whatwg.gphemsley.org/tests/mimesniff/

[08:39:05.0000] <annevk>
GPHemsley: okay, I'm planning on writing a comprehensive test suite for MIME type parsing next week, to go along with the PR

[08:39:27.0000] <annevk>
GPHemsley: but at some point I also want to study the sniffing behavior we got going on and find out how interoperable it really is

[08:39:45.0000] <GPHemsley>
sounds good; happy to help if I can

[08:40:19.0000] <annevk>
GPHemsley: I can make sure to ping you whenever there's something actionable, but it seems you're already watching the repo

[08:40:30.0000] <GPHemsley>
I am, yeah

[08:40:39.0000] <GPHemsley>
whenever I wander back to my computer

[08:56:02.0000] <ondras>
Domenic: no, calc() does not work with counter-*, at least in ff

[08:57:21.0000] <ondras>
a-ha, but it does in Chrome

[08:57:25.0000] <ondras>
time to submit a ff bug.

[08:58:12.0000] <annevk>
ondras: and write a web-platform-tests test?

[08:58:39.0000] <annevk>
(we need something for web-platform-tests test; WPT test kinda works, but I'm always a little worried to scare folks of with abbreviations)

[09:00:13.0000] <ondras>
annevk: now that is a good idea!

[09:01:04.0000] <ondras>
annevk: I happen to have that repo already cloned, as I submitted one recently. Will try to send a PR when I have some time.

[09:55:49.0000] <TabAtkins>
ondras: That's because `-var(--x)` isn't the var() function, it's the -var() function, a totally different (and unrecognized) thing.

[09:56:10.0000] <TabAtkins>
So yeah, calc(), and bugs on anyone that doesn't support it.

[10:21:11.0000] <ondras>
annevk: PR sent

[11:17:44.0000] <hsivonen>
annevk: I'm not aware of a canonical document arguing the superiority of UTF-16 over UTF-8 on any argument.

[13:29:05.0000] <Domenic>
I'd assumed annevk meant a canonical refutation of that argument


2017-10-09
[22:10:25.0000] <hsivonen>
looks like the new UTF-8 requirement isn't 100% clear: https://bugzilla.mozilla.org/show_bug.cgi?id=1406742

[22:37:47.0000] <MikeSmith>
hsivonen: /me looks

[22:39:07.0000] <MikeSmith>
hmm yeah I guess that’s the general problem of many (most) readers of the spec not knowing the difference between UA requirements and document-conformance requirements

[22:39:37.0000] <MikeSmith>
not sure how we could have made it more clear in the case of the UTF-8 document-conformance requirement

[22:40:11.0000] <MikeSmith>
I guess we could add a note to that section saying “This is not a requirement on user agents”

[22:41:07.0000] <MikeSmith>
but if we did, for consistency there’s a lot of other places we should also add that

[22:59:56.0000] <hsivonen>
MikeSmith: yeah. I guess we'll just mark browser bug report INVALID as they arise

[23:50:01.0000] <annevk>
MikeSmith: what does https://twitter.com/robert_kimata/status/917251436966141954 say?

[23:50:31.0000] <annevk>
MikeSmith: seems a lot of the require UTF-8 tweets are from folks in Japan

[23:59:12.0000] <MikeSmith>
/me looks

[00:03:44.0000] <MikeSmith>
/me had to look up 脆弱性

[00:04:11.0000] <MikeSmith>
annevk: Have read it a few times but I’m really not sure what point he’s trying to make

[00:04:15.0000] <MikeSmith>
in the first tweet

[00:04:35.0000] <MikeSmith>
He’s talking about the security risk if ISO-2022-JP

[00:04:49.0000] <MikeSmith>
which is a known thing of cource

[00:04:55.0000] <MikeSmith>
*course

[00:05:16.0000] <MikeSmith>
but I don’t know what he means by また、UTF-16とエンコーディングアルゴリズムが区別つかないUTF-32も使うなとある

[00:05:59.0000] <MikeSmith>
it sounds like he’s saying that UTF-16 is no different from UTF-32 .. in some regard

[00:06:09.0000] <MikeSmith>
but the follow-up tweet is pretty clear

[00:06:19.0000] <MikeSmith>
https://twitter.com/robert_KIMATA/status/917252289563201536

[00:07:08.0000] <MikeSmith>
that one basically just says, according to the W3C HTML spec, you can still use UTF-16, and it’s OK to use it

[00:07:31.0000] <hsivonen>
:-(

[00:07:42.0000] <MikeSmith>
yeah..

[00:11:06.0000] <hsivonen>
Currently, decode from UTF-16BE/LE is very slow. I've been thinking about how much complexity and effort I should put into making it faster

[00:11:53.0000] <hsivonen>
On one hand, using UTF-16 on the wire is such a bad idea, that I want to say "none" in protest. On the other hand, it annoys me to have the asterisk that encoding_rs decodes fast except for UTF-16BE/LE

[00:12:27.0000] <hsivonen>
there's a matrix of 8 cases to optimize

[00:12:50.0000] <hsivonen>
decoding into UTF-16 vs. UTF-8

[00:12:59.0000] <hsivonen>
big-endian vs. little-endian

[00:13:07.0000] <hsivonen>
aligned vs. unaligned

[00:14:33.0000] <hsivonen>
and not just "none" in protest but also in order to make better use of time

[00:23:57.0000] <MikeSmith>
hsivonen: to be fair as far as what the person said in that tweet, he said more like, “If you really *must* use UTF-16, then it’s OK”

[00:24:39.0000] <MikeSmith>
but I guess that’s commonly the reason people give for using UTF-16, that they’re forced into it somehow for reasons outside their control

[00:48:16.0000] <annevk>
hsivonen: don’t unless it becomes a priority somehow?

[00:48:47.0000] <annevk>
hsivonen: seems more worthwhile to document why UTF-16 is bad

[01:32:55.0000] <annevk>
JakeA: we should figure out workers/worklets, module scripts, and service workers

[01:33:41.0000] <annevk>
JakeA: I think the answer is that worklets are subresources, and worker module scripts need a same-origin restriction

[01:34:53.0000] <JakeA>
annevk: ohh, I thought worklets were a new global that could make requests, therefore they're a client?

[01:35:18.0000] <JakeA>
annevk: for module scripts… why same-origin? We don't have a that requirement for importScripts

[01:49:17.0000] <annevk>
JakeA: seems like you missed my message in that issue

[01:49:30.0000] <annevk>
JakeA: you cannot have a cross-origin client fetch backed by a same-origin service worker

[01:50:40.0000] <annevk>
JakeA: otherwise you have some limited variant of foreign fetch

[01:51:45.0000] <JakeA>
annevk: I'll catch up with the issues. I'm behind post-Fronteers :D

[01:52:04.0000] <annevk>
JakeA: and yeah, it would be better if worklets could be a client, but I think it's probably more important you can host them on CDNs and such, and ultimately it shouldn't matter much, though we should look at what it means for referrer and such I suppose

[01:52:35.0000] <annevk>
JakeA: ah okay, forgot that was going on

[02:12:34.0000] <annevk>
That streams thread on Twitter resulted in a 150 or so mentions

[02:12:50.0000] <annevk>
Not a single joke

[03:03:02.0000] <JakeA>
oh wow I didn't realise it had that many replies

[04:14:01.0000] <nox>
Is it me or https://w3c.github.io/media-source/#htmlmediaelement-extensions is extremely vague?

[04:14:04.0000] <nox>
Err,

[04:14:08.0000] <nox>
https://w3c.github.io/media-source/#url

[04:14:31.0000] <nox>
especially the part where it basically says "oh btw, you can revoke them URLs too, but the how is left as an exercice to the reader".

[04:16:05.0000] <annevk>
nox: yeah, should integrate with the URL Standard somehow I suspect

[04:16:21.0000] <annevk>
nox: I haven't really chased up all those dependencies yet, would appreciate you filing an issue

[04:16:34.0000] <nox>
annevk: On which spec?

[04:17:09.0000] <annevk>
nox: media-source as a start

[04:17:13.0000] <annevk>
nox: feel free to copy me

[04:17:16.0000] <nox>
annevk: Ok.

[04:46:44.0000] <nox>
annevk: https://www.w3.org/TR/FileAPI/#BlobURLStore This is per-global, right?

[04:47:08.0000] <nox>
Can a same-origin worker use an URL that was created from the Window global?

[04:47:37.0000] <annevk>
nox: ask Mek I suppose

[04:47:45.0000] <nox>
Mek: ^

[04:47:46.0000] <annevk>
nox: that kind of stuff is not defined well enough I think

[04:47:53.0000] <nox>
annevk: O RLY

[04:47:55.0000] <nox>
/me cries.

[04:48:28.0000] <annevk>
nox: I don't think it's per global per se

[04:48:40.0000] <annevk>
nox: maybe per event loop with some same-origin restriction

[05:02:40.0000] <nox>
annevk: According to Firefox, yeah it's per event loop.

[05:03:07.0000] <nox>
Or rather, calling it from a worker sends a runnable to the main thread for the registration, so I assume it's not per-global at the very least.

[05:48:11.0000] <annevk>
nox: worker and main thread sharing lookup sounds bad

[05:48:36.0000] <annevk>
nox: if that is true hopefully it can be removed still

[05:53:13.0000] <wanderview>
nox: annevk: having a worker use a blob URL create in the window (and vice versa) is pretty common I thought... in particular, we support worker scripts defined as a blob URL

[06:19:57.0000] <nox>
This is all so vaguely defined. :(

[06:35:43.0000] <nox>
annevk: https://github.com/w3c/media-source/issues/200

[06:49:13.0000] <annevk>
wanderview: but can you importScripts one created in a window?

[06:49:33.0000] <wanderview>
annevk: I believe you should be able to... my impression that is the intent

[06:50:03.0000] <annevk>
wanderview: so the scope of these strings is basically unbounded?

[06:50:28.0000] <wanderview>
annevk: limited to the origin and the life of the global that created them, right?

[06:50:41.0000] <wanderview>
I mean... they can be removed after the global dies

[06:50:42.0000] <annevk>
wanderview: I wonder if that’s cross-browser, but in any event it would be good to nail this down

[06:51:45.0000] <annevk>
wanderview: same-origin, yes, lifetime of the creator global, maybe? Seems a little weird if they’re cross-global otherwise

[06:52:15.0000] <nox>
Well,

[06:52:22.0000] <nox>
MediaSource doesn't help,

[06:52:40.0000] <nox>
because MediaSource is Exposed=Window, and the createObjectURL from that spec is Exposed=Window too.

[06:53:24.0000] <nox>
Who would have known Blob URLs would be so complicated

[07:05:44.0000] <annevk>
createObjectURL was a bad idea and we knew it from the start 😟

[07:06:04.0000] <annevk>
Just didn’t have the power to stop it

[07:08:35.0000] <wanderview>
annevk: we need to make these APIs consume Response objects... and make Response objects transferable

[07:10:37.0000] <annevk>
wanderview: yeah, maybe I should make some effort toward that

[07:10:58.0000] <annevk>
wanderview: Response or Blob, prolly

[07:11:18.0000] <wanderview>
annevk: Response would be preferable since its consumable and also integrates with ReadableStream

[07:11:50.0000] <wanderview>
IMO

[07:12:57.0000] <nox>
Is an url's object ever exposed to the Web?

[07:13:33.0000] <annevk>
wanderview: yeah, but I think something that does not come with a MIME type can be nice too usability-wise

[07:13:57.0000] <wanderview>
annevk: blob have types, no?

[07:14:03.0000] <annevk>
nox: not directly, if that’s what you mean

[07:14:10.0000] <nox>
annevk: Ok.

[07:14:13.0000] <annevk>
wanderview: ooh right

[07:14:32.0000] <wanderview>
yea, I was thinking of this: https://developer.mozilla.org/en-US/docs/Web/API/Blob/type

[07:14:42.0000] <nox>
annevk: So technically, even if the URL parser sets the url's object to a MediaSource instance in a worker, nothing bad is supposed to happen, right?

[07:14:48.0000] <wanderview>
annevk: if you want data with no type, then I think thats ReadableStream

[07:15:20.0000] <annevk>
wanderview: anyway, I agree we should do this, starting with Response seems good, can broaden later

[07:16:08.0000] <annevk>
nox: if MediaSource is not exposed there that cannot happen

[07:19:41.0000] <nox>
annevk: How?

[07:20:14.0000] <nox>
Did you mean that it shouldn’t happen?

[07:20:50.0000] <nox>
Because the URL parser with how it’s stated currently doesn’t care that the interface is not exposed.

[07:21:55.0000] <annevk>
nox: it seems the structured deserialize operation would fail when that url is fetched

[07:22:09.0000] <annevk>
nox: but maybe it should fail sooner

[07:23:22.0000] <annevk>
nox: I hope Mek can make some time to clean this up

[07:23:48.0000] <annevk>
nox: Blob should really be a solid part of the platform by now 😟

[07:25:13.0000] <nox>
annevk: I assumed it was.

[07:25:19.0000] <nox>
I think I should never assume such things.

[07:25:34.0000] <nox>
annevk: What do you mean "when that url is fetched"?

[07:25:46.0000] <nox>
Oh, from a video element?

[07:25:58.0000] <wanderview>
annevk: did workers exist when Blob was created?

[07:26:51.0000] <annevk>
wanderview: not sure

[07:29:12.0000] <nox>
annevk: OH

[07:29:19.0000] <nox>
annevk: I had not noticed that srcObject exists.

[07:29:33.0000] <nox>
I'll just disregard Blob URLs for now (I'm implementing MSE stubs in Servo).

[08:24:58.0000] <annevk>
nox: why only stubs?

[08:25:39.0000] <nox>
annevk: Because Gecko people are changing the media stack so it's usable in Servo.

[08:25:56.0000] <nox>
annevk: The plan is for them to decouple it from the rest of Gecko in the cleanest way possible,

[08:26:02.0000] <nox>
while I implement as much as the DOM stuff in Rust,

[08:26:15.0000] <nox>
and then we combine our forces and join the missing dots.

[08:26:47.0000] <annevk>
nox: rewrite the Gecko parts in Rust?

[08:27:26.0000] <nox>
annevk: What do you mean? Which parts?

[08:27:29.0000] <nox>
The whole media stack?

[08:27:42.0000] <nox>
That would be above my pay-check my friend.

[08:27:49.0000] <annevk>
nox: heh

[08:28:11.0000] <nox>
annevk: I had lunch with some of them, mfw I realise most people on the media stack are IC5.

[08:28:30.0000] <annevk>
nox: it’s interesting that Gecko is now helping Servo without obvious benefit to Gecko

[08:28:53.0000] <annevk>
nox: heh

[08:30:48.0000] <nox>
annevk: Well, we already are using the JS engine.

[08:31:03.0000] <gsnedders>
nox: do you support promises yet?

[08:31:26.0000] <nox>
Yes since last Fall IIRC.

[08:31:47.0000] <gsnedders>
what was it that people kept getting annoyed at WPT using, then?

[08:31:49.0000] <gsnedders>
arrow functions?

[08:31:56.0000] <annevk>
nox: JS engine was always fairly reusable no?

[08:32:15.0000] <annevk>
gsnedders: yeah

[08:34:18.0000] <nox>
annevk: Meh. :p

[08:34:35.0000] <nox>
Updating it takes months.

[08:34:53.0000] <nox>
fitzgen is working hard on improving that though.

[08:35:54.0000] <gsnedders>
https://lists.w3.org/Archives/Member/w3c-css-wg/2017OctDec/0025.html — wow (re: last paragraph)

[08:54:30.0000] <nox>
gsnedders: arrow functions, let, const…

[08:55:02.0000] <nox>
gsnedders: Also, Safari doesn't support some of that stuff either, IIRC.

[08:55:45.0000] <gsnedders>
nox: Safari has since 10 a year ago

[08:56:25.0000] <nox>
Arrow functions?

[08:56:46.0000] <gsnedders>
yeah

[08:57:00.0000] <nox>
http://caniuse.com/#feat=arrow-functions disagrees

[08:57:29.0000] <gsnedders>
nox: huh? that shows Safari 10 supporting?

[08:57:57.0000] <espadrine>
gsnedders’ sentence was hard to parse, but he meant “a year ago, Safari 10”

[08:57:58.0000] <nox>
gsnedders: OH

[08:58:02.0000] <nox>
Yes.

[08:58:07.0000] <nox>
I read "since 10 years ago".

[08:58:08.0000] <nox>
Hah.

[08:58:32.0000] <gsnedders>
:)

[08:58:43.0000] <gsnedders>
but yeah, Safari 10 supported all of ES6

[08:59:14.0000] <gsnedders>
I think even ES 2016 is universal now?

[08:59:47.0000] <gsnedders>
ES 2017 is everywhere except Edge (which tbf means that isn't relevant for WPT)

[11:04:51.0000] <Domenic>
annevk: my thought for cross-origin module workers was that it was just fetching the script cross-origin. It still executes like a normal worker.

[11:05:01.0000] <Domenic>
It doesn't execute in the target origin or anything weird like that.

[11:48:08.0000] <annevk>
Domenic: doesn’t work with selecting a service worker for it based on the request URL

[11:48:37.0000] <Domenic>
How do we select a service worker for <script src="cross-origin-url">?

[11:48:57.0000] <wanderview>
Domenic: the controller of the owning document

[11:49:07.0000] <Domenic>
OK. Do that?

[11:50:01.0000] <wanderview>
does anyone know if chrome separates http cache based on fetch credentials mode?

[13:03:53.0000] <annevk>
Domenic: that does not work for clients

[13:04:13.0000] <annevk>
Domenic: for clients you use the request URL

[13:04:47.0000] <annevk>
wanderview: pretty sure they don’t

[13:05:05.0000] <annevk>
wanderview: there is some discussion in a Fetch issue

[13:06:52.0000] <jyasskin>
annevk: https://github.com/whatwg/fetch/issues/307?

[13:07:28.0000] <annevk>
jyasskin: yeah

[14:13:20.0000] <Domenic>
annevk: why does that not work for clients?

[14:19:47.0000] <wanderview>
annevk: are modules clients?

[14:19:56.0000] <wanderview>
annevk: I thought modules were subresource requests

[14:20:44.0000] <wanderview>
Domenic: for non-subresource requests there is no controlling client in place... so you have to do scope matching to determine if it should intercepted

[14:20:59.0000] <wanderview>
are we trying to support cross-origin top level module scripts in workers or something?

[14:43:55.0000] <Domenic>
My intent with module workers (in the spec, not implemented) was just to allow fetching the module source text from another URL, the same way <script src=> can do

[14:44:01.0000] <Domenic>
But apparently this doesn't work, for reasons I don't understand.

[16:35:13.0000] <bathos>
I’ve got a question about interactions between module loading and HTTP2 that’s had me scratching my head for a few days — is that something appropriate to ask about here?

[16:37:27.0000] <jyasskin>
bathos: Yes.

[16:39:32.0000] <bathos>
Cool. I’ve been experimenting with serving resources using HTTP2 push — assemble a dep graph in advance and follow through on requests by provisioning their known dependencies as push promises. This works great on the whole, but there’s a quirk I’ve observed that seems to be related specifically to ES module "entrypoints".

[16:40:11.0000] <bathos>
I asked about it on SO, so there’s a bit of detail in the question and comments there: https://stackoverflow.com/questions/46642569/http2-push-and-native-es-modules-entry-module-push-is-ignored

[16:40:44.0000] <bathos>
The gist though:

[16:41:37.0000] <bathos>
Given a request for a document which contains <script type="module" src="something">, and an http2 session which includes a push promise for "something", the "something" push is never adopted. Instead, the browser makes a fresh request for it.

[16:41:39.0000] <jyasskin>
Domenic: ^

[16:42:05.0000] <bathos>
Dependencies imported _in_ ES are adopted.

[16:42:51.0000] <jyasskin>
bathos: I'm not an expert here, but your question reminds me of the with-vs-no-credentials problem in https://github.com/whatwg/fetch/issues/354.

[16:42:57.0000] <bathos>
And if I reference the same module in a different way in the root document, e.g. a preload <link>, it is successfully adopted. It’s peculiar to type="module"

[16:43:16.0000] <bathos>
oh, interesting

[16:43:42.0000] <jyasskin>
Apologies if I've just sent you on a wild goose chase.

[16:44:46.0000] <bathos>
I have been on a lot for the last two days haha! Since HTTP2 is still pretty mysterious to me, it’d been hard to rule out the possibility that I’m doing something weird there, though I’m pretty sure at this point that I’m not.

[16:52:58.0000] <bathos>
jyasskin you genius!

[16:53:14.0000] <jyasskin>
s/genius/pattern-matcher/ :)

[16:53:38.0000] <bathos>
crossorigin="use-credentials" in the doc actually makes the module push promise get adopted

[16:54:02.0000] <bathos>
I never would have thought to try "crossorigin" on a file on the same host haha

[16:54:23.0000] <jyasskin>
JakeA: Do you know if anyone's looking into a devtools warning when this happens?


2017-10-10
[17:04:02.0000] <bathos>
jyasskin I answered the question, tried to give attribution for your assistance, and quoted this chat: https://stackoverflow.com/questions/46642569/http2-push-and-native-es-modules-entry-module-push-is-ignored/46656731#46656731

[17:04:20.0000] <bathos>
(let me know if you’d prefer I didn’t and I’ll edit accordingly)

[17:04:44.0000] <bathos>
I have a feeling this is gonna be helpful for others in the future in any case.

[18:47:58.0000] <wanderview>
Domenic: <script> tags is a subresource of a document/window... a worker script is a top level entity itself

[19:48:55.0000] <Domenic>
Still don't really understand why that matters. I guess we use different rules for picking the service worker in such cases but I don't understand why or what goes wrong when we don't.

[19:52:18.0000] <Mek>
I don't think anything goes wrong per-se. It just would be a bit weird where currently the service worker controlling a client is determined by the URL the client is loaded from being in scope of the SW, while for a cross-origin worker the URL would never be in scope. So either we change the logic to select a SW for all module workers (making them behave differently than non-module workers), or we only change it for cross-origin workers, which is also a

[19:52:18.0000] <Mek>
bit inconsistent.

[19:53:08.0000] <Mek>
To me it doesn't sound too strange to treat them similar to about:blank iframes etc, where we also just take the SW of the creating document as the controlling service worker. Treat cross-origin module workers almost like an anonymous "about:blank" worker that just happens to import a cross-origin module...

[19:53:22.0000] <wanderview>
there is no cross-origin non-subresource from a service worker perspective... it just matches scopes on that other origin

[19:53:24.0000] <wanderview>
right?

[19:55:00.0000] <wanderview>
what Domenic is asking for sounds like window.open(crossOriginURL) where it loads resources from another origin, but then would weirdly be forced the openers origin...

[19:57:48.0000] <wanderview>
Domenic: new Worker(url) is very similar to window.open(url)... they both open top level clients

[19:58:12.0000] <wanderview>
with the notable difference that we throw a security error for new Worker() if the url is cross origin from the current context

[20:00:58.0000] <Mek>
it's kind of new Worker("about:blank") followed by worker.write("import("cross-origin-url")), if that would be possible. I'm not saying it isn't different than what we do now, but it surely isn't impossible either. We'd juts have to decide how to treat it.

[20:01:20.0000] <Mek>
(and I'm not sure if the difference in treatment should be made at same-origin vs cross origin or at classic vs module worker)

[20:02:13.0000] <wanderview>
hmm

[20:04:02.0000] <Mek>
(and for what it's worth, I think having cross-origin (module) workers that actually are cross origin (access the other origins storage etc) would also be a worthwhile thing to explore, but yet again another complication (it would address at least some of the foreign-fetch/navigator.connect use cases, combined with nested workers)

[20:04:06.0000] <wanderview>
I guess I would be more comfortable just requiring the top level module URL to be same-origin to match classic script loading

[20:05:27.0000] <wanderview>
adding cross-origin worker support seems orthogonal to module loading to me

[20:18:30.0000] <wanderview>
or maybe thats what this PR is about

[21:32:48.0000] <annevk>
wanderview: agreed, will file an issue later with hopefully a detailed enough explanation

[22:47:39.0000] <JakeA>
jyasskin: bathos: also covered at https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/#requests-without-credentials-use-a-separate-connection

[01:38:45.0000] <tobie>
Hey folks, if you have thoughts &/|| comments to make about adding mixins to WebIDL, now's about the right time: https://github.com/heycam/webidl/pull/433

[01:59:20.0000] <JakeA>
jyasskin: filed https://bugs.chromium.org/p/chromium/issues/detail?id=773219

[04:16:24.0000] <ondras>
so, is calc() supposed to work in font: shorthand property? as in https://jsfiddle.net/29fsrxq3/

[04:44:45.0000] <nox>
ondras: calc() is supposed to work everywhere until specified otherwise.

[04:45:03.0000] <ondras>
nox: thanks. will report a bug and a wpt test then.

[04:45:32.0000] <nox>
ondras: It appears big for me in both Safari and Chrome.

[04:45:52.0000] <ondras>
nox: right. but not in firefox.

[04:46:10.0000] <nox>
Yep.

[05:50:43.0000] <annevk>
hsivonen: what's a web-observable caller of "UTF-8 decode without BOM or fail"?

[05:51:00.0000] <annevk>
hsivonen: I thought I found one in HTML, but that appears to be an error when I tested

[06:16:44.0000] <annevk>
hsivonen: I found another decoder, the thing that navigates to fragments...

[06:16:52.0000] <annevk>
/me is not amused

[06:22:48.0000] <annevk>
hsivonen: also, it seems this endpoint doesn't allow a BOM to override it

[06:40:19.0000] <Domenic>
annevk: does not escaping % break the idempotency/parse-serialize-parse guarantees for URLs? Haven't checked but feels like it might.

[06:42:08.0000] <annevk>
Domenic: we only do something for %2e. But you cannot get that serialized I think.

[06:42:28.0000] <annevk>
Domenic: at least not in a place where parse will then take it away again

[07:04:50.0000] <annevk>
Domenic: hope the module worker issue is clear now

[07:05:13.0000] <annevk>
Domenic: also, are implementations first shipping import()? Before <script type=module>?

[07:05:25.0000] <annevk>
Domenic: or is <script type=module> happening before workers?

[08:27:33.0000] <hsivonen>
annevk: Web Socket as implented in Gecko, maybe?

[08:53:31.0000] <annevk>
hsivonen: that does indeed seem required as per https://tools.ietf.org/html/rfc6455#section-8.1

[08:53:43.0000] <annevk>
hsivonen: I'll make a note of that in the source

[08:54:47.0000] <annevk>
hsivonen: ta

[10:15:21.0000] <annevk>
Hmm, NTLMv2

[10:15:34.0000] <annevk>
I wonder if I want to explore that further; probably not

[10:16:00.0000] <gsnedders>
the answer is definitely not

[10:16:58.0000] <jyasskin>
JakeA: Thanks!

[11:34:58.0000] <TabAtkins>
ondras: Yeah, what nox said - calc() represents a <number> or <length> or whatever according to its contents, and should be usable *literally everywhere* that any of those types are accepted.

[11:43:03.0000] <ondras>
TabAtkins: thanks for confirmation. I already submitted a PR to web-platform-tests and there is an existing (~year) old report in mozilla's bugzilla.

[11:46:08.0000] <TabAtkins>
Cool.

[11:47:31.0000] <nox>
ondras: With Stylo landing soon, it will not get fixed in Firefox right now,

[11:47:50.0000] <nox>
ondras: but after Stylo lands, the Rust code that do the parsing is way easier to update to support this, so that's nice.

[11:48:15.0000] <ondras>
nox: I understand that Stylo is some brand new css engine for Firefox and people are focused at delivering it instead of fixing old bugs in the old css engine?

[11:49:06.0000] <nox>
ondras: Yes and no.

[11:49:43.0000] <nox>
ondras: Not supporting that in font doesn't break anything currently,

[11:49:49.0000] <nox>
ondras: supporting it *could* break things,

[11:50:48.0000] <nox>
ondras: and we can't afford to deploy Stylo and suddenly realise it breaks websites because it supports more stuff than the previous engine.

[11:52:11.0000] <ondras>
nox: I see, okay. (calc in font works in both Chrome and Safari, though.)

[11:52:32.0000] <nox>
ondras: Yeah, so for example, a website could have a font property with calc, for Firefox and Chrome,

[11:52:43.0000] <nox>
Err, Safari and Chrome*

[11:52:47.0000] <nox>
and a different font property for Firefox, without calc,

[11:53:23.0000] <ondras>
That is true.

[11:53:26.0000] <nox>
and while it's not much probable, supporting calc in Firefox could then break the site under Firefox (for example if the two fonts were different, because they didn't combine well with the rest of the stylesheet as interpreted by Firefox),

[11:53:36.0000] <nox>
and then we need to disable Stylo on that website, which sucks.

[12:03:47.0000] <TabAtkins>
Yeah, it's reasonable to want to separate out those concerns when doing a big launch. ^_^ It's not super-pressing, but it is important to fix eventually - calc() not working in random places is very frustrating for devs.

[12:15:54.0000] <ondras>
true that.

[12:16:33.0000] <ondras>
The point is that Custom Properties are almost useless without calc(), so I suppose that calc() is now getting a lot more attention. At least in my case :-)

[12:21:42.0000] <TabAtkins>
Ah, true!

[12:21:42.0000] <nox>
TabAtkins: It's frustrating to le me who participated into Stylo too!

[12:21:59.0000] <nox>
It takes more code to not support calc() in some places, than to support it everywhere.

[12:22:12.0000] <nox>
So we had issues about having to *unsupport* calc sometimes.

[12:22:49.0000] <TabAtkins>
Nice.

[12:27:20.0000] <annevk>
nox: seems we can undo thos now with 57 having branched?

[12:28:19.0000] <nox>
annevk: The story is "don't worry fam we won't forget about doing these changes afterwards".

[12:28:41.0000] <nox>
annevk: I myself have been kidnapped for a different adventure, so I'm not in the know anymore about that kind of mundane details.

[12:30:20.0000] <annevk>
Maybe SimonSapin knows? I’m curious now 😊

[12:33:27.0000] <SimonSapin>
Right now pretty much any style system change needs to be done twice. It’ll all be much easier when we can remove the old style system

[12:33:52.0000] <SimonSapin>
but it’ll be a couple release cycles at least before we can

[12:34:35.0000] <SimonSapin>
we need to enable Stylo on Android, support XBL, etc

[12:35:38.0000] <annevk>
SimonSapin: ah ok, ta

[12:36:54.0000] <Domenic>
annevk: I'm still not sure on why shared workers would be nondeterministic. They are keyed by (creator origin, worker script URL) so they'd always use the service worker of the creator origin.

[12:38:08.0000] <Mek>
but which service worker of that origin?

[12:38:18.0000] <Domenic>
Oh.

[12:42:07.0000] <annevk>
Yup

[12:42:33.0000] <annevk>
/me curses scopes once more

[12:44:07.0000] <nox>
360 noscope 4ever

[12:50:14.0000] <tobie>
Domenic: hey, so I found a reliable way to check that the WebIDL grammar stays LL(1)

[12:50:34.0000] <tobie>
Domenic: Which btw uncovered 3 violations in the existing grammar. :)

[12:50:40.0000] <Domenic>
Exciting :)

[12:51:07.0000] <tobie>
Well, I'm not sure exciting is the best way to characterize that…

[12:51:23.0000] <tobie>
But it's going to solve an otherwise painful problem.

[12:51:34.0000] <tobie>
Domenic: It relies on node.js + jsdom + syntax-cli + a custom JS script.

[12:52:25.0000] <tobie>
Domenic: and should be called by the deploy script (as it's going to be more robust if run on a build rather than on bs source)

[12:52:50.0000] <tobie>
Domenic: what do you think the best strategy is to incorporate it into the repo/travis file?

[12:53:56.0000] <tobie>
Domenic: this is basically what the script looks like: https://gist.github.com/tobie/ea7e12bb4cbbc5a28527684e7f14ef20

[12:54:38.0000] <Domenic>
(Use new jsdom API plz ^_^)

[12:54:58.0000] <tobie>
Domenic: oh. sure. :D

[12:55:29.0000] <Domenic>
Basically I would borrow from https://github.com/whatwg/streams

[12:55:35.0000] <Domenic>
Setup travis as if it's a node project

[12:55:40.0000] <Domenic>
Check in a package.json and the .js file

[12:56:03.0000] <Domenic>
and run `node script.js` inside the deploy.sh

[12:56:13.0000] <Domenic>
be sure to update it to exit with return code 1 on failure

[12:56:30.0000] <tobie>
Cool. That's perfect.

[12:57:21.0000] <tobie>
That's what I had in mind, but wasn't too sure about all the details of handling multiple scripts.

[12:57:29.0000] <tobie>
All set now. Thanks.

[12:58:37.0000] <Domenic>
\o/

[13:09:34.0000] <tobie>
Domenic: what did you do to jsdom!?!?!? it's about 2 orders of magnitude faster. o_O

[13:09:47.0000] <Sebmaster>
🌈

[13:09:48.0000] <Domenic>
lol, dunno, lots of work over time

[13:10:37.0000] <tobie>
Domenic: I was running 9.6.0, apparently

[13:11:38.0000] <Domenic>
tobie: ah, probably https://github.com/tmpvar/jsdom/blob/master/Changelog.md#971

[13:12:47.0000] <tobie>
Domenic: that sounds about right (and pretty close to 2 orders of magnitude indeed)

[13:13:22.0000] <Domenic>
I wonder how many poor souls are stuck on 9.5.0-9.7.0

[13:42:32.0000] <tobie>
well, one less today. :)

[14:05:43.0000] <smaug____>
<a href="javascript:window.open();" target="_blank"> Should that open one or two windows

[14:05:57.0000] <smaug____>
I assume two, since that would make sense


2017-10-11
[17:46:02.0000] <gsnedders>
does anyone know where Acid3 test 99 comes from?

[17:46:10.0000] <gsnedders>
"check for the weirdest bug ever"

[17:46:19.0000] <gsnedders>
I presume some browser at some point genuinely failed it

[17:46:45.0000] <gsnedders>
or is it literally just there as a sanity test?

[18:56:51.0000] <ali0>
Hello! Would it be possible for fetch to set a header like X-Requested-With: XMLHttpRequest by default?

[18:57:50.0000] <ali0>
Libraries like jQuery set it without the user knowing, and server frameworks such as Rails use it to identify that it was an AJAX request

[19:16:39.0000] <MikeSmith>
alwu: https://github.com/whatwg/fetch/issues/58#issuecomment-110339399 is relevant

[19:19:33.0000] <MikeSmith>
also, why not just check for the Origin header

[19:28:55.0000] <MikeSmith>
question for any git experts here:

[19:30:01.0000] <MikeSmith>
when I do a `git log --decorate` on a clone of git⊙gc:w3c/web-platform-tests.git

[19:30:06.0000] <MikeSmith>
or https://github.com/w3c/web-platform-tests.git

[19:30:42.0000] <MikeSmith>
it shows `(origin/marcoscaceres-patch-1)` for commit 5516a2bcb3a7e67da0ba3d69b973ef008c7c350b

[19:31:07.0000] <MikeSmith>
= “Remove @alphan102, add @mnoorenberghe”

[19:31:52.0000] <MikeSmith>
and for commit b0c75cd8857f9f9596a744fac65c3be5e526aede (origin/TimothyGu/jsdom-tmp)

[19:32:13.0000] <MikeSmith>
but it only shows the branch names like that for those two commits

[19:32:14.0000] <MikeSmith>
why?

[19:32:32.0000] <MikeSmith>
what’s special about those commits?

[19:33:07.0000] <MikeSmith>
I don’t see any metadata in the raw commit log that would cause those to be show differently like that

[19:33:17.0000] <MikeSmith>
TimothyGu: maybe you know

[22:29:39.0000] <bathos>
is there a mechanism / is there a proposed mechanism for custom pseudoclasses in web components (or something equivalent?) — in some cases, css vars do the trick, but in others it doesn’t work out that way

[22:33:24.0000] <MikeSmith>
so to close the loop on the git question I asked here earlier about the branch refs in the WPT git log --decorate:

[22:34:07.0000] <MikeSmith>
the branch refs were shown for those two commits because the branches were still in the origin

[22:35:41.0000] <MikeSmith>
that is, it basically is showing that those two cases are for merged PR branches that somebody forgot to delete when they merged the commits from the PRs for those

[22:37:40.0000] <MikeSmith>
so it’s kind of a handy indicator for visually catching those cases from the command line, so that you can know those merged branches need to deleted and locally pruned

[23:31:48.0000] <tobie>
MikeSmith: git would definitely benefit from some form of branch cleanup option

[23:32:01.0000] <MikeSmith>
yeah

[23:32:26.0000] <MikeSmith>
the ongoing guessing game with git is fun though

[00:42:52.0000] <nox>
git remote prune

[00:43:35.0000] <nox>
git log --decorate has been the default for a long time now btw.

[03:09:09.0000] <kochi>
I found there are two distinct "SyntaxError"s : https://bugs.chromium.org/p/chromium/issues/detail?id=609415#c20

[03:09:47.0000] <kochi>
One is DOMException whose name is "SyntaxError", and the other is `SyntaxError` which is an exception itself.

[03:10:22.0000] <annevk>
kochi: the latter is very specific and should not be used outside ECMAScript

[03:10:53.0000] <kochi>
annevk: yeah, I learned it today.

[03:15:24.0000] <kochi>
Even though the webidl spec describes both, it doesn't say "they are different" explicitly :-(

[03:16:34.0000] <kochi>
I'm tempted to add a note on "SyntaxError" in the webidl spec.

[03:23:34.0000] <annevk>
kochi: https://heycam.github.io/webidl/#idl-exceptions mentions they're explicitly omitted

[03:24:17.0000] <annevk>
kochi: but maybe you mean in the section of DOMException? Might be good

[03:25:26.0000] <kochi>
annevk: yes, the spec is kinda sound, but "SyntaxError" typeface aren't different, so without reading carefully readers may not make out the difference.

[03:26:04.0000] <kochi>
annevk: so yeah, in the exceptions section is okay, but adding a note in DOMException section could make sense.

[06:06:06.0000] <annevk>
Domenic: seen RTCIdentityProviderGlobalScope?

[06:07:00.0000] <annevk>
Domenic: https://github.com/w3c/webrtc-pc/issues/1627

[06:33:30.0000] <annevk>
https://github.com/WebAssembly/spec/issues/577 makes me wonder how much review WebAssembly's type system has had

[06:56:18.0000] <annevk>
Turns out that strings are byte sequences in WebAssembly

[06:56:29.0000] <annevk>
And names are strings

[07:02:18.0000] <nox>
annevk: Not the first string-related misnomer.

[07:02:19.0000] <nox>
:)

[07:04:16.0000] <bathos>
answering my own q from last nite: I was able to achieve what I wanted through element attributes & just a bit of extra logic to ensure said attributes can not be in invalid states ... seems to be a viable substitute for pseudoclasses in at least some cases (someElemWithASlot[specialAttr] somethingInSlot {})

[07:09:39.0000] <annevk>
bathos: pseudo-elements are semi-planned btw

[07:09:56.0000] <annevk>
bathos: there's an issue, I can look it up for you

[07:10:05.0000] <annevk>
bathos: wanted to ping you earlier, but you were not around anymore

[07:10:30.0000] <annevk>
bathos: https://github.com/w3c/webcomponents/issues/300

[07:19:18.0000] <bathos>
oh, cool! I’ve occasionally wished for both pseudo elems and pseudo classes, though the latter is a lot easier to work around

[08:41:48.0000] <wanderview>
as a browser vendor person at tpac, should I register for this meetup?  I don't want to take a web devs seat if space is limited: https://www.w3.org/2017/11/Meetup/

[08:44:06.0000] <annevk>
wanderview: I have attended such a meetup at one point; suspect it's fine

[11:38:31.0000] <ondras>
webcrypto question: is there an api to compute a public key from a corresponding private key?

[11:39:24.0000] <TabAtkins>
That would defeat public-key crypto entirely, so no. ^_^

[11:40:16.0000] <ondras>
https://stackoverflow.com/questions/696472/given-a-private-key-is-it-possible-to-derive-its-public-key

[11:40:19.0000] <TabAtkins>
(The public and private keys are identical in purpose; we designate one as "public" and one as "private" arbitrarily. If you could compute one from the other, pk crypto wouldn't work at all.)

[11:41:48.0000] <TabAtkins>
Ah, interesting, so practical concerns mean that it usually can be computed, because we make some choices that make the public key much more predictable than it should be theoretically.

[13:27:02.0000] <jyasskin>
TabAtkins/ondras: Generally the data we call the "private" key also includes the public key, whereas the public key doesn't include the private key.

[16:02:56.0000] <TimothyGu>
MikeSmith: feel free to delete TimothyGu/jsdom-tmp. I forgot what it was for.

[16:23:44.0000] <MikeSmith>
TimothyGu: thanks yeah I did already


2017-10-12
[19:03:58.0000] <sangwhan>
Think ondras is asking if there is no openssl -pubout equivalent, not having that isn't critical but having it is probably useful. I don't know any algorithms where this would be impossible, so not sure if there is a really good excuse for not having it aside from it not being a wide audience API

[23:26:33.0000] <annevk>
Domenic: GPHemsley: I’m thinking we should add a MIMEType object too, in due course

[23:26:49.0000] <annevk>
Once all other questions are resolved

[23:39:06.0000] <ondras>
sangwhan: my case: the client will be generating a keypair, sending the pubkey to the server, storing the privkey in localStorage to sign stuff later.

[23:39:42.0000] <ondras>
sangwhan: my point is, whether I need to store the pubkey in localStorage as well (if the server needs it again), or if it is derivable from the (already stored) privkey

[00:32:12.0000] <tobie>
Is there some kind of solution to add footnotes (or similar) to Bikeshed?

[00:34:42.0000] <tobie>
E.g. to link the (a) in https://heycam.github.io/webidl/#distinguishable-table to it's description right below.

[00:35:57.0000] <tobie>
I have a bunch of other cases in the spec where this would be useful. It doable by hand, but then it implies scoping identifiers somehow, which is error prone.

[00:36:05.0000] <tobie>
TabAtkins: ^

[00:44:03.0000] <tobie>
TabAtkins: I *think* that boils down to (1) an incrementing integer (e.g. <sup><a href="#path-to-note">[INT++]</a></sup>), and (2) some form of mechanism to go back to where the footnote was referenced, similar to what's already in place with DFNs and the like.

[00:44:13.0000] <tobie>
TabAtkins: also maybe this is completely overkill.

[01:16:38.0000] <freesamael>
annevk: Do you know if there's a defined session history entry limit in the spec, or the 50 entries limit is just an implementation practice happened to be used in most browsers?

[01:16:55.0000] <freesamael>
(I couldn't find the defined limit in spec)

[01:19:01.0000] <annevk>
freesamael: I haven't seen a defined a limit

[01:19:23.0000] <annevk>
freesamael: generally we leave that up to impl, unless it becomes a compat problem (such as with redirects, where we do define a limit)

[01:20:25.0000] <freesamael>
annevk: I see. Thx.

[01:49:49.0000] <tobie>
annevk: mind giving https://github.com/heycam/webidl/pull/459 a quick double check ?

[01:53:55.0000] <annevk>
acks are sorted on last name?

[01:53:57.0000] <annevk>
weird

[01:54:10.0000] <annevk>
tobie: it looks good except I'd drop "CSS"

[01:54:36.0000] <annevk>
tobie: since the technology is selectors and it's supposedly independent from CSS (even though everyone calls it CSS selectors)

[01:55:10.0000] <tobie>
annevk:  apparently (wrt to acks sort order)

[01:55:13.0000] <annevk>
(well, not just supposedly, these days there's DOM APIs)

[01:55:58.0000] <tobie>
Should I add a [[selectors4]] reference?

[01:59:54.0000] <annevk>
tobie: I'd drop the 4 if you do

[02:00:04.0000] <tobie>
yes, obv.

[02:00:33.0000] <annevk>
tobie: it probably makes sense since you don't want to assume too much knowledge from the reader

[02:00:52.0000] <annevk>
this might be an interesting example for that reference discussion

[02:01:02.0000] <tobie>
annevk: that said, the syntax error is actually thrown from DOM, not SELECTORS

[02:01:24.0000] <annevk>
tobie: you could ref DOM instead, since it has all the relevant info

[02:02:20.0000] <tobie>
annevk: by "reference discussion" do you mean the "footnotes" I was mentioning above?

[02:02:55.0000] <annevk>
tobie: I don't see the assert discussed in https://github.com/heycam/webidl/issues/118 in the commit that closed the issue

[02:03:33.0000] <annevk>
tobie: https://github.com/whatwg/meta/issues/41

[02:03:39.0000] <tobie>
annevk: yes, filed https://github.com/heycam/webidl/issues/449 for that

[02:05:08.0000] <annevk>
cool

[02:14:51.0000] <kochi>
annevk: tobie: thanks!

[02:15:04.0000] <tobie>
kochi: thank you!

[02:15:23.0000] <tobie>
kochi: also see the PR I sent to DOM

[02:16:01.0000] <kochi>
tobie: whatwg/dom#518?

[02:16:26.0000] <tobie>
kochi: yes

[02:16:45.0000] <tobie>
kochi: as imho that's the root of the initial confusion.

[02:17:18.0000] <kochi>
tobie: absolutely.  thanks for doing all the stuff.

[02:23:52.0000] <kochi>
tobie: as already annevk reviewed the PR, I don't have anything to add and it looks great to me.

[03:36:03.0000] <annevk>
JakeA: sorry, I missed that you wanted my review on those SW abort tests

[03:36:17.0000] <annevk>
JakeA: I'm not really sure I'm the right candidate, but I'll look through them

[03:36:44.0000] <JakeA>
annevk: no worries, I only pushed them a day ago I think

[03:38:09.0000] <annevk>
JakeA: says 4 days here

[03:38:31.0000] <JakeA>
annevk: shit, time flies

[03:38:32.0000] <annevk>
JakeA: oh my, I'm confusing days and commits

[03:38:51.0000] <annevk>
Further evidence I'm not qualified

[03:39:06.0000] <JakeA>
haha well I just took your world for it

[03:39:18.0000] <JakeA>
word*

[04:19:27.0000] <annevk>
JakeA: thanks for commenting on that push thing

[04:19:42.0000] <annevk>
JakeA: we should indeed do the lower-level thing first

[04:20:04.0000] <annevk>
(but someone should also figure out if we want to keep the current architecture where a push is tied to the connection)

[04:27:24.0000] <JakeA>
annevk: no problem! I think the push cache has to sit beyond the HTTP cache, otherwise it risks skipping stuff like CSP.

[04:55:02.0000] <annevk>
foolip: https://github.com/w3c/web-platform-tests/issues/7693 would be nice for the roadmap

[04:55:29.0000] <annevk>
foolip: there's some other older issues in w3c/wptserve too that are still relevant I guess

[06:14:40.0000] <TabAtkins>
tobie: Not currently, no. For now, just link it manually. Feel free to open an issue tho - if we can collect results I can see if there's a pattern that would be useful to capture.

[06:15:02.0000] <tobie>
TabAtkins: thanks

[07:43:55.0000] <wanderview>
annevk: JakeA: is there a reason we can't use the WebSockets API on top of H2 under the hood?  aren't network layers a useful abstraction? just curious about some of the motivations

[07:44:40.0000] <annevk>
wanderview: I think it's because nobody defined how it would work

[07:45:29.0000] <annevk>
wanderview: WebSocket now is an HTTP/1 handshake followed by framed data over a single connection

[07:46:06.0000] <annevk>
wanderview: to do it over HTTP/2 would require new H/2 frames or layering on top of H/2 frames, I'd imagine

[07:48:36.0000] <wanderview>
hmm

[07:49:07.0000] <JakeA>
Didn't someone draft that?

[07:49:49.0000] <JakeA>
https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01

[07:49:53.0000] <JakeA>
But it was abandoned

[07:52:54.0000] <annevk>
Give me full-duplex fetch first and then we'll see if we still need WebSocket or just smaller frames in H2

[07:53:02.0000] <JakeA>
agree

[07:53:03.0000] <JakeA>
d

[07:57:05.0000] <wanderview>
JakeA: oh, alex linked to that in his gist

[09:12:47.0000] <wanderview>
annevk: JakeA: if we did do `.src = Response()` type integration... would you want it to be `.src` or `.srcobj`?

[09:15:54.0000] <annevk>
wanderview: prolly the latter for consistency with existing APIs and to not break things that assume .src is a string

[09:16:35.0000] <annevk>
wanderview: I  totally forgot that was something I volunteered for looking into; I'll have a look tomorrow, but it might be a while

[09:16:56.0000] <wanderview>
annevk: its ok... not like I have time to implement it (although it may not be that hard)

[09:17:47.0000] <wanderview>
annevk: if we could tap into the same `respondWith()` resolved a Response logic it might be dead easy

[09:22:49.0000] <wanderview>
annevk: nothing is on the SW TPAC agenda yet... I guess I could try to propose something there

[09:44:40.0000] <annevk>
wanderview: which APIs were you thinking anyway? For <audio> and <video> there's quite a simple entry point; I suspect for <img> it would be quite involved specification-wise

[09:46:18.0000] <wanderview>
annevk: I was thinking for everything... if it supports a ServiceWorker interception/respondWith() it seems like we should be able to manually synthesize a response... was my naive thinking

[09:48:00.0000] <annevk>
wanderview: makes sense, though I suspect we'll have some different challenges for each endpoint, even though if you imagine a service worker it's rather easy

[11:11:42.0000] <annevk>
Maybe I should start blocking email that copies mailing lists

[14:56:00.0000] <tantek>
has anyone heard of the disableRemotePlayback attribute?

[14:56:39.0000] <tantek>
or seen / read the Remote Playback API spec? https://w3c.github.io/remote-playback/


2017-10-13
[18:05:06.0000] <sangwhan>
tantek: It went through TAG review a couple months ago, so I've seen it - what about it?

[18:15:48.0000] <sangwhan>
TL:DR; summary is letting <video> to be thrown at your Apple TV or equivalent OTT box - has some worms in terms of cross browser/device pair interop though

[18:51:00.0000] <MikeSmith>
sangwhan: do you still build Chrome and if some are you using jumbo builds and if so how much has it reduced your build time in your environment

[18:51:42.0000] <MikeSmith>
in particular, how much has it reduced it for a full build from a clean working directory

[18:52:35.0000] <MikeSmith>
*still build Chrome and if *so* are you using jumbo builds

[20:53:13.0000] <DDK>
Does anyone here know how to hack Elvenar to get mo

[20:53:20.0000] <DDK>
more diamonds*

[21:22:37.0000] <tantek>
sangwhan: the attribute disableRemotePlayback sounded vaguely DRMish so I thought I'd ask critical crowd like here :)

[21:40:32.0000] <sangwhan>
MikeSmith: last time I had to build chrome I recall using sumo, but that was quite a while ago. Not sure if sumo is jumbo based - sounds dangerous to do on Chrome.

[22:37:14.0000] <MikeSmith>
annevk: about “Credentials

[22:37:20.0000] <MikeSmith>
are HTTP cookies, TLS client certificates, and authentication entries.”

[22:37:29.0000] <MikeSmith>
in the Fetch spec

[22:37:56.0000] <MikeSmith>
*authentication entries* is a link just to https://fetch.spec.whatwg.org/#authentication-entry

[22:38:31.0000] <MikeSmith>
which dfn does not normatively include proxy-authentication entries

[22:39:14.0000] <MikeSmith>
> An authentication entry and a proxy-authentication entry are tuples of username, password, and realm, associated with one or more requests.

[22:41:00.0000] <MikeSmith>
so should the definition of credentials instead be:

[22:41:02.0000] <MikeSmith>
> Credentials are HTTP cookies, TLS client certificates, authentication entries, and proxy-authentication entries.

[22:43:10.0000] <MikeSmith>
annevk: or to help clarify and fix that open issue:

[22:43:53.0000] <MikeSmith>
> Credentials are HTTP cookies, TLS client certificates, and, for HTTP Authentication, authentication entries and proxy-authentication entries.

[22:49:42.0000] <MikeSmith>
or even better:

[22:49:44.0000] <MikeSmith>
> Credentials are HTTP cookies, TLS client certificates, and, for HTTP Authentication, authentication entries and proxy-authentication entries. [COOKIES] [TLS] [HTTP-AUTH]

[00:30:43.0000] <MikeSmith>
annevk: oh, does the definition of credentials intentionally not include proxy authentication?

[00:31:59.0000] <MikeSmith>
because I notice that XHR defines “user credentials” as not including proxy authentication

[00:32:07.0000] <MikeSmith>
> The term user credentialsfor the purposes of this specification means cookies, HTTP authentication, and TLS client certificates. Specifically it does not refer to proxy authentication or the Origin header.

[00:32:13.0000] <MikeSmith>
...

[00:33:12.0000] <MikeSmith>
or are what the Fetch spec defines as “credentials” and what the XHR spec defines as “user credentials” not actually exactly the same thing?

[00:36:15.0000] <annevk>
MikeSmith: hey

[00:36:21.0000] <annevk>
MikeSmith: I'm not sure about proxies

[00:36:59.0000] <annevk>
MikeSmith: I basically have never played with them, but as far as I know user agents consider them part of credentials; though that might have changed or might differ across user agents

[00:37:29.0000] <annevk>
MikeSmith: it seems safest to exclude them as long as we're not sure

[00:38:26.0000] <MikeSmith>
OK but don'

[00:38:29.0000] <MikeSmith>
oofs

[00:39:05.0000] <MikeSmith>
OK but don't see how “it seems safest to exclude them as long as we're not sure” follows from “as far as I know user agents consider them part of credentials”..

[00:39:41.0000] <MikeSmith>
but anyway I will update the Fetch PR to (re)exclude them

[00:42:38.0000] <annevk>
MikeSmith: well that was going from memory

[00:42:54.0000] <MikeSmith>
ok

[00:42:57.0000] <annevk>
MikeSmith: if Fetch and XHR don't include proxies I'd rather we continue to do so

[00:44:22.0000] <MikeSmith>
hai

[00:44:43.0000] <MikeSmith>
will do the XHR PR in a bit (to change it to just reference the Fetch dfn)

[02:05:18.0000] <qswz>
I'm trying to implement        ] [ mmn            ] [ tyoshino      ]

[02:05:53.0000] <qswz>
I'm trying to implement https://dom.spec.whatwg.org/#dom-childnode-replacewith here: https://github.com/caub/jsdom/blob/a/lib/jsdom/living/nodes/ChildNode-impl.js#L53-L78

[02:06:05.0000] <qswz>
but for the moment it makes no sense in terms of code

[02:06:32.0000] <qswz>
for .after and .before I think it's good, but .replaceWith's spec is harder to understand

[02:20:26.0000] <nox>
/me qswz: What's your issue?

[02:54:47.0000] <zcorpan>
qswz: rows 69..70 don't match up with the spec, right?

[03:31:42.0000] <qswz>
zcorpan: no, it doesn't

[03:32:11.0000] <qswz>
until then it was following it, but after I'm super confused

[03:34:27.0000] <qswz>
I understand it's problematic if nodes contains the context object

[03:34:58.0000] <qswz>
so I tried something

[09:23:09.0000] <domfarolino>
annevk: in what case would the condition in step 14 substep 1 of request constructor ever be triggered? I ask because it seems we can't ever construct a Request object whose mode is "navigate" without throwing a TypeError right?

[09:24:26.0000] <wanderview>
domfarolino: I think you can in a FetchEvent handler with new Request(evt.request), no?

[09:24:43.0000] <wanderview>
in that case the input Request object was created by the browser for FetchEvent.request

[09:30:52.0000] <domfarolino>
wanderview: so evt.request would have to be a request whose mode is "navigate"?

[09:32:20.0000] <annevk>
domfarolino: yeah, you get that in a service worker

[09:39:10.0000] <domfarolino>
wanderview: annevk: ok that makes sense, how exactly is this request whose mode is "navigate" constructed then? Because if the browser constructs it internally, doesn't that still sort of violate step 18 where we throw?

[09:39:35.0000] <domfarolino>
In other words, do internally constructed objects not necessarily follow the constructor steps outlined in the spec?

[09:40:09.0000] <domfarolino>
hm that might be a naïve question

[09:45:01.0000] <annevk>
domfarolino: yup, browser has special powers

[09:45:56.0000] <annevk>
domfarolino: it can just create a Request object instance and then back it with an arbitrary request

[09:46:25.0000] <annevk>
domfarolino: this pattern is used a lot, but we haven't been very formal about it thus far; at some point IDL will define object allocation/creation, which should make it a little clearer whenever it happens

[09:52:14.0000] <domfarolino>
annevk: Ok so I believe I've heard that the objects defined in fetch spec are used in general browser resource loading (all managed internally)...so does this mean when the browser "fetches" things like images and stylesheets, it creates request and possibly other objects under the hood, just it its own way?

[09:52:42.0000] <domfarolino>
annevk: Gotcha, thanks. Ah yeah that sounds pretty helpful!

[09:53:41.0000] <annevk>
domfarolino: yes

[09:53:59.0000] <annevk>
domfarolino: that's also why there's a distinction between a "request" and a Request object, to some extent

[09:54:50.0000] <annevk>
domfarolino: we could potentially merge them into one, but it's a little weird for non-JavaScript algorithms to pass around JavaScript objects, whereas abstract concepts seems a bit more natural

[09:55:16.0000] <annevk>
again though, largely convention, not formalized

[09:57:25.0000] <domfarolino>
annevk: Right that makes sense. That's what was a tad confusing to me at first because I figured if a browser constructed this object internally (i.e. not in JavaScript), it couldn't necessarily throw a TypeError, so it must not be following the rules. So when we say "request" instead of Request object, do we expect internals to actually create an object of type Request, just in its own way? Or is it valid for the

[09:57:25.0000] <domfarolino>
internal representation to be whatever the heck it wants, so long as objects exposed to the DOM are compliant

[09:59:17.0000] <annevk>
domfarolino: a request doesn't necessarily have an associated Request

[09:59:40.0000] <annevk>
domfarolino: service workers ends up creating a Request object for them

[10:00:22.0000] <annevk>
domfarolino: that's how they end up exposed, but the way it creates those Request objects doesn't go through the constructor, it just allocates a shell and fills in the slots

[10:00:33.0000] <domfarolino>
annevk: Right, but when an image is fetched let's say, can we expect somewhere in c++ land is calling `new Request(...)`, even though there is no formal requirement to do so

[10:00:39.0000] <domfarolino>
Ah ok that's what I was getting at yes

[10:01:40.0000] <annevk>
domfarolino: for <img> I'd expect C++^H^H^H^HRust land to do something like create_request() which creates some internal object which maps to the request concept

[10:02:27.0000] <annevk>
It wouldn't involve the Request class at all, unless there's a service worker

[10:07:57.0000] <domfarolino>
annevk: ok, so it won't involve the literal class, it would just need the attributes defined in https://fetch.spec.whatwg.org/#concept-request

[10:08:50.0000] <annevk>
smaug____: if you happen to know why setAttribute("test", sameValueAsNow) creates a mutation record, maybe reply to https://github.com/whatwg/dom/issues/520?

[10:09:12.0000] <annevk>
domfarolino: yeah, could be a struct or whatever

[10:09:31.0000] <annevk>
domfarolino: or even just parameters, as long as the end result is the same

[10:10:05.0000] <annevk>
domfarolino: implementations can pretty much do whatever they want as long as they give the same outputs

[10:11:42.0000] <annevk>
domfarolino: see also paragraph after example here https://infra.spec.whatwg.org/#algorithms

[10:12:13.0000] <domfarolino>
Right, as long as main fetch can perform with whatever the input “request” is, all is well.

[10:14:06.0000] <domfarolino>
annevk: excellent that makes sense, thank you

[10:26:32.0000] <domfarolino>
Yeah the differentiation between “request” and Request makes a lot of sense, I guess wasn’t something I put much thought into before


2017-10-14
[17:29:38.0000] <GPHemsley>
annevk: What was the context for your MIMEType object proposal? Just free-standing within mimesniff, or attached somewhere?

[20:06:10.0000] <KiChjang>
for the fetch standard here https://fetch.spec.whatwg.org/#concept-fetch

[20:06:34.0000] <KiChjang>
on the first step, it says "Run these steps, but abort if the ongoing fetch is terminated"

[20:06:49.0000] <KiChjang>
does that mean before every substep, we do a check and see whether it is terminated?

[20:07:11.0000] <KiChjang>
or does it mean the check is only done during step 1?

[21:24:49.0000] <annevk>
KiChjang: each, but that needs to be clarified with some Infra concept

[21:25:17.0000] <KiChjang>
annevk, ah ok, that's what i realized while reading other parts of the spec

[21:25:49.0000] <KiChjang>
however one natural question comes up - does it also include subsequent subsubsteps and subsubsubsubsubsub...

[22:04:27.0000] <annevk>
GPHemsley: free-standing

[22:28:47.0000] <domfarolino>
is this a mistake? https://usercontent.irccloud-cdn.com/file/QSJFBE2K/Screen%20Shot%202017-10-14%20at%201.28.21%20AM.png

[00:00:16.0000] <domfarolino>
or it's probably a joke..

[00:07:28.0000] <domfarolino>
annevk: Seems that in Request constructor step 15 substep 5 we set a request's referrer to client if the parsedReferrer isn't same origin w/ origin, however I get a TypeError when actually constructing a new request w/ crossorigin referrer, could you point out where we do this in the spec?

[00:32:46.0000] <annevk>
domfarolino: we changed the req, so bug

[00:33:14.0000] <domfarolino>
annevk: Ok I can make a PR to throw

[00:33:31.0000] <annevk>
Stylesheet overlap is intentional, but confusing

[00:33:38.0000] <annevk>
domfarolino: impl bug

[00:33:48.0000] <domfarolino>
ahhh

[05:15:12.0000] <GPHemsley>
annevk: I'm for it.

[06:15:03.0000] <domfarolino>
annevk: The test regarding https://github.com/whatwg/html/pull/2984#discussion_r144617841, where do you suppose the best place to put it would be?

[06:36:18.0000] <annevk>
domfarolino: hmm, html/ has directories per section, so presumably there's a fitting subdirectory somewhere

[06:36:29.0000] <annevk>
domfarolino: I can look in a bit

[06:39:21.0000] <annevk>
domfarolino: looks like it should be a new directory in html/semantics/document-metadata/

[06:39:41.0000] <annevk>
domfarolino: named interactions-of-styling-and-scripting

[06:52:14.0000] <domfarolino>
annevk: Cool thank you

[16:01:37.0000] <domfarolino>
Domenic: possible dumb question: Taking a look at the wpt PR where I'm adding the console IDL to /interfaces...why exactly are we using `namespace` for the console IDL though as opposed to just an `interface`? Is it because of the prototype = empty object requirement?


2017-10-15
[06:42:25.0000] <annevk>
domfarolino: see issues linked from https://github.com/whatwg/console/commit/9a0792da2037f988efc3374bc53ef51e59544d4c

[11:45:52.0000] <domfarolino>
👍


2017-10-16
[01:18:23.0000] <tobie>
domfarolino: wrt to add namespace support to idlharness: it's going to be a bit involved.

[01:21:08.0000] <tobie>
domfarolino: you'll want to create a dedicated constructor IdlNamespace, that inherits from IdlObject just like IdlInterface does: https://github.com/w3c/web-platform-tests/blob/master/resources/idlharness.js#L880

[01:22:23.0000] <tobie>
Maybe you even want some kind of extra abstract class that both IdlNamespace and IdlInterface inherit from.

[01:23:01.0000] <tobie>
And then you'll want to hook it in properly, notably here: https://github.com/w3c/web-platform-tests/blob/master/resources/idlharness.js#L198

[01:32:04.0000] <tobie>
domfarolino: moved the above comments to the GH issue: https://github.com/w3c/web-platform-tests/pull/7551#issuecomment-336817155

[03:12:07.0000] <tobie>
ricea: you can trigger pr-preview by editing ever slightly the body of an existing PR (just add a linebreak)

[03:16:48.0000] <tobie>
ricea: yup, just noticed.

[06:10:23.0000] <domfarolino>
tobie: awesome thank you!

[06:11:33.0000] <domfarolino>
annevk: the Request domintro should contain attributes/methods that also appear in the Body interface since it implements it right?

[06:12:32.0000] <annevk>
domfarolino: hmm, I'd be okay with listing those under Body

[06:12:39.0000] <domfarolino>
Ok

[06:12:45.0000] <annevk>
domfarolino: so we don't have to duplicate between Request/Response

[06:14:08.0000] <domfarolino>
annevk: Ok that makes sense, I've updated https://github.com/whatwg/fetch/issues/543#issuecomment-336784513 to include a checkbox for the `RequestInit` members to be added to domintro so that is tracked independently of the current PR

[06:18:44.0000] <annevk>
domfarolino: okay, that violates how I think tree-style checkboxes should behave, but I'll allow it

[06:19:04.0000] <annevk>
domfarolino: so I'll land this then?

[06:19:56.0000] <domfarolino>
Ah yes it doesn't make too much sense as is. Sure if the nits and everything look good I think it's ready!

[06:21:42.0000] <annevk>
domfarolino: thank you!

[06:29:21.0000] <domfarolino>
annevk: NP thanks!

[06:43:43.0000] <domfarolino>
annevk: regarding your comment about using `getComputedStyle` on my wpt PR...wouldn't testing if the styles applied just be like testing that the browser properly downloads a regular style sheet with no media attr specified? As in, it doesn't seem to be testing what the HTML PR proposes right?

[06:44:00.0000] <domfarolino>
Though I guess it would be a little stronger than "document.styleSheets.length == 1" hm

[06:45:12.0000] <annevk>
domfarolino: you basically don't want to assume a particular impl

[06:45:35.0000] <annevk>
domfarolino: e.g., browsers could accidentally lie about document.styleSheets or it could reflect the second stylesheet being applied and not the first

[06:45:50.0000] <annevk>
domfarolino: so more assertions is better, if you can make them

[06:45:58.0000] <annevk>
domfarolino: and getComputedStyle is an obvious one we can

[06:47:39.0000] <domfarolino>
annevk: Ok sounds good

[07:46:04.0000] <domfarolino>
annevk: Also you mentioned "What requires it to be loaded eventualy?"

[07:46:24.0000] <domfarolino>
I guess it is a tad racy right?

[07:47:54.0000] <domfarolino>
Ideally it would be loaded by the three seconds in, but there's no guarantee :(

[10:24:56.0000] <bradleymeck>
is there something like URL.createObjectURL that lets me "reserve" a URL, but that I don't have the body for yet (without using a ServiceWorker)

[10:30:57.0000] <wanderview>
bradleymeck: I don't think so... but I would like to see us be able to use Response or ReadableStream in places that take a url string... like `img.srcobj = new Response(stream)`

[10:31:23.0000] <bradleymeck>
wanderview: I need a string URL for my use case

[10:31:42.0000] <bradleymeck>
which is trying to instrument ESM using browser APIs

[10:32:01.0000] <bradleymeck>
ESM can have circular dependencies which createObjectURL can't create

[10:34:09.0000] <jgraham>
bradleymeck: I assume ESM is not the European Stability Mechanism or Ejection Systolic Murmur, but I have no idea what else it might be

[10:34:18.0000] <bradleymeck>
EcmaScript Modules

[10:36:19.0000] <gsnedders>
can we write a glossary somewhere? probably not the wiki given it's so flaky…

[10:56:07.0000] <bradleymeck>
basically I want to be able to generate `my-url` => `import "my-url"` somehow, but can't figure out how to make the body w/ the circular reference to a URL coming out of `URL.createObjectURL`

[11:39:58.0000] <Domenic>
annevk has some reasons why object URLs in general are a bad design and might want to talk to you about alternatives for your use case, I dunno. E.g. have you investigated data: URLs

[11:40:35.0000] <bradleymeck>
Domenic: data: URLs would place same text modules in the same slot of the module map

[11:40:44.0000] <Domenic>
Yes, I'd hope so

[11:40:44.0000] <bradleymeck>
which is not workable

[13:38:04.0000] <jimklo>
I've got a question regarding the TextTrack.activeCues.  Is there an immutable way to get the activeCues?  I'm having a problem in that I cannot seem to process the cues fast enough such that I'm dropping cues that I should have handled. For ref: https://html.spec.whatwg.org/multipage/media.html#dom-texttrack-activecues


2017-10-17
[17:29:54.0000] <jwalden>
turf hot potato!  the tc39/test262 people think that all tests involving document.all should go in w-p-t, but pretty much the entirety of https://github.com/jswalden/test262/commit/3eacab9399a6e500c3f1dd5df0fa450788306882 is testing ecma262 goo; is it actually likely that if I massaged that into w-p-t format, it would be accepted in a PR?

[17:30:30.0000] <jwalden>
(assume that the behavior of the goofy function being used there is just to return |document.all|)

[17:59:40.0000] <t3soro>
Who do I complain to about deficiencies in the EventSource API?

[18:01:23.0000] <t3soro>
It is like a first draft, cant set request headers, can't handle an error properly, or get HTTP status

[18:22:59.0000] <Domenic>
jwalden: definitely acceptable in WPT

[18:23:55.0000] <jwalden>
mm

[18:25:20.0000] <jwalden>
so, where to put these tests then

[18:26:23.0000] <jwalden>
shadow-dom/leaktests/html-collection.html html/infrastructure/common-dom-interfaces/collections/htmlallcollection.html html/obsolete/requirements-for-implementations/other-elements-attributes-and-apis/document-all.html html/dom/historical.html html/dom/interfaces.html are the existing document.all test locations, and none of them seem apropos

[18:33:58.0000] <jwalden>
maybe the (misspelled) js/behaviours

[18:34:13.0000] <Domenic>
Yeah I'd think anywhere under js/

[18:41:00.0000] <jwalden>
boo, you didn't respond to my spelling trolling :-)

[18:55:51.0000] <MikeSmith>
t3soro: file issues at https://github.com/whatwg/html I guess

[18:58:14.0000] <t3soro>
Thanks @MikeSmith

[18:58:20.0000] <MikeSmith>
cheers

[18:58:40.0000] <MikeSmith>
jimklo: foolip might be able to help you when he’s around

[19:00:02.0000] <jimklo>
MikeSmith: thanks, I think I figured out a way, but it was definitely awkward.  Required overwriting the prototype for TextTrack.addCue

[19:00:47.0000] <MikeSmith>
oh

[19:01:08.0000] <MikeSmith>
well I guess you rightly shouldn’t have to resort to that

[19:02:14.0000] <MikeSmith>
your use case sounds like it might merit you taking time to raise an issue at https://github.com/whatwg/html/issues

[19:03:37.0000] <jimklo>
MikeSmith: I understand why TextTrack.oncuechange does what it does, It just would be nice if instead of the track being the event target, an immutable list of active cues were available. The mutable live list just causes problems, since as time progresses the contents of the list changes

[19:04:15.0000] <jimklo>
so if you're trying to itterate the contents of TextTrack.activeCues  - you can't exactly do that

[19:04:31.0000] <MikeSmith>
I see yeah

[19:06:55.0000] <jimklo>
I got what I needed done by adding a listener to the VTTCue.onstart/onfinish at the track level; so one doesn't need to individually listen to each individual cue event.

[19:07:58.0000] <jimklo>
basically what I need is the VTTCue.onstart/onfinish events available at the TextTrack level

[19:10:42.0000] <MikeSmith>
jimklo: so yeah that specifically sounds worthy of raising an issue, to see if you could get some browser-implementor interest in adding that

[19:11:22.0000] <jimklo>
I think the way I currently handle is probably the right approach, it's just the current API is a bit cumbersome.  Sounds reasonable... I'll add an issue in GH

[19:11:28.0000] <MikeSmith>
but that said, if you do raise an issue, I recommend first describing what problem you’re trying to solve, and the propose a possible solution

[19:11:36.0000] <MikeSmith>
jimklo: super

[21:36:19.0000] <annevk>
domfarolino: ideally I think you would not be required to fetch such stylesheets at all

[21:37:58.0000] <annevk>
domfarolino: though maybe they do need to be fetched once the media starts matching; that would make sense and require more testing…

[23:57:16.0000] <domfarolino>
annevk: Hm i'm a little confused? Isn't the test to see if the browser only blocks rendering on the stylesheets that match the env, even though it fetches all?

[00:00:42.0000] <annevk>
domfarolino: yeah, but if you no longer block, that kinda begs the question what the behavior is instead

[00:01:18.0000] <domfarolino>
annevk: ohhhh...good point

[00:01:21.0000] <annevk>
domfarolino: I'm not entirely sure if figuring that out should block this PR though, but we should maybe have a follow-up issue of sorts

[00:05:58.0000] <domfarolino>
annevk: Ok that makes sense. Maybe it could be specified further in spec or something idk

[00:08:25.0000] <annevk>
domfarolino: I'm wondering if bz would consider changing the current setup in Firefox blocked on that

[00:08:59.0000] <annevk>
domfarolino: it seems that browsers that don't block scripts on loading all stylesheets, will have to start loading them as soon as there's a match of sorts, e.g., when the window is resized

[00:09:32.0000] <annevk>
domfarolino: though in other cases, e.g., "aural" as medium, you likely never have to fetch it

[00:21:53.0000] <domfarolino>
annevk: Hm wouldn't it be ideal if they loaded all sheets at once, just didn't block rendering on non-matching? If it didn't start "loading" until a match then you could resize the screen and not have styles applied, and thus have bad non-responsive looking site for as long as the network would take. Or am I missing something

[00:25:29.0000] <annevk>
domfarolino: well, but if the user never resizes you end up wasting bandwidth

[00:28:14.0000] <annevk>
domfarolino: anyway, it's worth looking into what UAs that don't block do for such a scenario

[00:30:25.0000] <MikeSmith>
annevk: I’m surprised the Chrome team hasn’t seen fit to fix their spec violation about sending TLS client certs in preflights

[00:30:32.0000] <MikeSmith>
as discussed at https://bugzilla.mozilla.org/show_bug.cgi?id=1019603

[00:30:48.0000] <MikeSmith>
do you know if they even have an open bug for it?

[00:31:20.0000] <domfarolino>
annevk: True. But since browsers like firefox take that bandwidth by default now (by blocking on all sheets) users are probably more used to taking that bandwidth hit since that's all they've known, in exchange for a webapp that when resized, snaps into responsive styles immediately.

[00:31:21.0000] <domfarolino>
Yeah, I know chrome and safari don't block, and requests for the non-matching sheets are made at the same time as the matching ones

[00:31:45.0000] <domfarolino>
annevk: which I personally like but it's worth looking into deeper

[00:32:14.0000] <MikeSmith>
annevk: somebody else on stackoverflow ran into that and posted a question today https://stackoverflow.com/questions/46783506/why-is-the-tls-client-certificate-not-being-included-in-preflight-request-on-mos

[00:34:47.0000] <annevk>
MikeSmith: could you file a bug against Chrome?

[00:35:07.0000] <annevk>
MikeSmith: and maybe mention it in the Firefox bug?

[00:35:34.0000] <annevk>
MikeSmith: web-platform-tests doesn't have the chops to test this unfortunately

[00:35:57.0000] <annevk>
domfarolino: aah okay, so they have that behavior

[00:36:59.0000] <domfarolino>
annevk: Indeed, yeah sorry if that was unclear! Yeah they do that now :)

[00:38:49.0000] <annevk>
domfarolino: still gives the possibility of unstyled content when resizing early, but probably not that bad

[00:39:09.0000] <annevk>
domfarolino: do they avoid loading stylesheets that can never match?

[00:39:34.0000] <MikeSmith>
annevk: yeah will file it later today

[00:39:43.0000] <annevk>
MikeSmith: great thanks

[00:40:17.0000] <domfarolino>
annevk: yep that possibility exists for sure. That’s a good question hm I have no idea I may look into that in the next day or so given time allows. Interesting

[02:03:26.0000] <MikeSmith>
annevk: https://bugs.chromium.org/p/chromium/issues/detail?id=775438

[02:28:28.0000] <annevk>
Ta!

[04:39:20.0000] <tobie>
What's the accepted antonym of blocklist?

[04:41:48.0000] <tobie>
annevk: ^ you're generally of good advice for these things

[04:42:11.0000] <tantek>
tobie, followings?

[04:42:40.0000] <Ms2ger>
allowlist?

[04:43:44.0000] <annevk>
tobie: safelist

[04:45:09.0000] <tobie>
yeah, I've see both allowlist and safelist, while some people claim whitelist is OK, only blacklist isn't (which seems weird, but the etymology might be completely different—see master branch vs master/slave db)

[04:45:21.0000] <tobie>
tantek: ?

[04:46:42.0000] <tantek>
tobie hard to suggest more nuance absent context

[04:48:12.0000] <tobie>
tantek: yeah, sorry: https://github.com/w3c/web-platform-tests/issues/7781#issuecomment-337205846

[04:51:21.0000] <annevk>
tobie: HTML uses safe/block

[04:52:49.0000] <tantek>
tobie, wow that was quite a different context than I expected. interesting

[04:53:08.0000] <tobie>
tantek: heh

[04:53:11.0000] <tobie>
annevk: ty

[05:03:43.0000] <jgraham>
safe doesn't make sense in a non-security context

[05:40:21.0000] <tantek>
indeed, "safe" seems quite overloaded

[08:03:57.0000] <TabAtkins>
authlist/denylist has the nice property that the two words are the same length.

[08:04:21.0000] <TabAtkins>
I like allowlist/blocklist for the same reason. ^_^

[08:44:47.0000] <bathos>
I am super guilty of choosing variable names with this property in mind in code all the time

[09:40:55.0000] <Mek>
annevk: any thoughts on https://github.com/w3c/web-platform-tests/pull/7848?

[09:45:26.0000] <wanderview>
Mek: I think he's on PTO for a few weeks

[09:46:32.0000] <Mek>
wanderview: ah, okay. he seemed active earlier, but in that case I won't bug him

[09:46:56.0000] <wanderview>
Mek: oh, I guess he was

[09:47:12.0000] <wanderview>
he works too much :-)

[12:14:50.0000] <KiChjang>
does anyone know if the fetch spec or the HTTP cache RFC specifies which headers to not cache?

[12:15:00.0000] <KiChjang>
and if so, where is it located?

[12:41:28.0000] <wanderview>
anyone here have Edge 16 yet?

[12:48:58.0000] <jsbell>
wanderview: I have it via browserstack

[12:51:47.0000] <wanderview>
jsbell: ah, interesting... thanks

[12:52:23.0000] <wanderview>
not sure I want to install an extension for the free trial

[13:02:42.0000] <jsbell>
wanderview: I forget what the extension adds, but I don't use it

[13:07:54.0000] <TabAtkins>
Do we have a server somewhere that is actually running the wpt test runner?

[13:08:56.0000] <wanderview>
jsbell: I have the windows update running... so I guess I'll get it soon

[13:41:13.0000] <wanderview>
/me wonders if windows will ask him to reboot or just cut him off mid-typing...

[13:54:26.0000] <TabAtkins>
Anyone around who can answer questions I have about slurping w-p-t metadata?

[13:54:44.0000] <gsnedders>
probably?

[13:54:48.0000] <TabAtkins>
I'm adding some Bikeshed feature for listing tests inline, and I want to:

[13:55:16.0000] <TabAtkins>
(a) verify that a given folder/testname exists (and hopefully do some levenshtein distance fixups to help with typos)

[13:55:32.0000] <TabAtkins>
(b) get the title and/or assertion for the test

[13:55:39.0000] <TabAtkins>
(c) link to a live version of the test

[13:55:43.0000] <TabAtkins>
(d) link to source of the test

[13:56:24.0000] <TabAtkins>
Happy to have to do some pulling/munging on my own (automatically) and just upload it somewhere in a more useful form for Bikeshed to consume.

[13:57:04.0000] <Mek>
maybe also link to results of the test on wpt.fyi?

[13:57:25.0000] <Mek>
(which itself already has links to source and live version of the test)

[13:57:35.0000] <nox>
TIL wpt.fyi

[13:58:10.0000] <TabAtkins>
Yes, that too.

[13:59:08.0000] <gsnedders>
TabAtkins: a) if you want to know if a given path is a test you need the manifest somewhere

[13:59:14.0000] <wanderview>
Mek: I wish it would atomically update... this stuff is confusing: https://wpt.fyi/service-workers/service-worker

[13:59:26.0000] <gsnedders>
TabAtkins: b) I don't think we store those anywhere at the momemt?

[13:59:40.0000] <wanderview>
I mean, I assume firefox has 0 passing because its updating results currently, etc

[14:00:04.0000] <TabAtkins>
gsnedders: k, if I can get the source address I can parse on my own and munge it into a datafile

[14:00:23.0000] <gsnedders>
wanderview: updating results should be atomic

[14:00:40.0000] <gsnedders>
TabAtkins: you run `./wpt manifest` and you get a MANIFEST.json somewhere

[14:00:48.0000] <wanderview>
gsnedders: then why do sometimes different browsers have zero results or clearly wrong results?

[14:01:15.0000] <gsnedders>
wanderview: there was some discussion about this somewhere recently, uh

[14:01:42.0000] <gsnedders>
wanderview: note Firefox's results for serviceworkers are all TIMEOUT

[14:01:59.0000] <gsnedders>
wanderview: (i.e., it's not missing results, it's accurately display the results it got)

[14:04:01.0000] <wanderview>
ok.... but we pass large numbers of the tests... so the TIMEOUT results seem incorrect to me

[14:05:05.0000] <gsnedders>
yeah, we're randomly getting a few too many TIMEOUT and ERROR in some browsers on some tests, and I don't know if we know why exactly.

[14:05:25.0000] <gsnedders>
TabAtkins: (see ./wpt manifest --help for more)

[14:07:45.0000] <gsnedders>
wanderview: https://github.com/w3c/wptdashboard/issues/162

[14:08:23.0000] <wanderview>
thanks

[14:09:32.0000] <wanderview>
gsnedders: do you know if the test config sets any cookie related prefs?

[14:09:41.0000] <gsnedders>
TabAtkins: stepping back though, what's the goal here? how does this fit into the existing <link rel=help> stuff?

[14:10:05.0000] <gsnedders>
wanderview: it does the same as whatever wptrunner does

[14:10:13.0000] <wanderview>
ok

[14:16:01.0000] <TabAtkins>
gsnedders: The goal is that marking the *tests* to point to segments of the *spec* doesn't help with reviewing what parts of the spec need more testing. (It also requires a lot of inline markup anyway to add more anchors.) When reviewing a test to see if it's tested well, seems more useful to have the *spec* point to *tests* instead.  (Was talking about this with fantasai over lunch - currently, she has to manually

[14:16:02.0000] <TabAtkins>
annotate things in reverse anyway when reviewing specs.)

[14:22:33.0000] <gsnedders>
TabAtkins: what makes that better than the current views we have based on the spec ToC? it sounds like it would add a lot of work onto the spec editor to maintain?

[14:26:14.0000] <TabAtkins>
gsnedders: Spec ToC-based isn't fine-grained enough, and still requires flipping back and forth between spec and the wpt view. Want to get these inline.

[14:27:07.0000] <TabAtkins>
The hope is also that it serves as an built-in reminder to write tests for things, so that a paragraph without tests following it looks obviously "wrong" in the source.

[14:30:26.0000] <TabAtkins>
(Requiring myself to remember to check a completely different view, unlinked by anything close to the spec, and then manually detangle how many tests are in each section and what they correspond to, to see if anything is currently untested, is not going to happen, and is a lot of work even if it does happen. Listing a few tests locally is something I can do *while writing tests*, and then it's there for me

[14:30:26.0000] <TabAtkins>
automatically and easy to review when editting.)

[14:31:37.0000] <manu>
TabAtkins gsnedders: Do either of  you know a) Macros Caceres IRC nick (or if he's on here), b) how to inject polyfill code into web platform test stuff before the tests start running.

[14:31:49.0000] <TabAtkins>
It's `marcos`

[14:31:55.0000] <TabAtkins>
But he's not on here right now.

[14:32:10.0000] <manu>
k thx

[14:32:49.0000] <TabAtkins>
But as for "injecting", you can just put it into the test itself?  No in-built way to, like, conditionally do that, I think.

[14:33:48.0000] <manu>
TabAtkins: well, we're trying to not modify the tests themselves... didn't know if there was a test setup phase in WPT where you could inject polyfill before the tests took over.

[14:34:10.0000] <TabAtkins>
Each test is just a separate HTML page that gets loaded and executed.

[14:36:08.0000] <manu>
TabAtkins: taaz knows more of the details on this as he's currently trying to work through it... he said the issue has more to do with waiting for the body to be ready, injecting the polyfill (because the Web Payments polyfill needs the body to be ready), and then allowing the promises in the test to then fire... it's a timing issue and we were wondering if anyone else had hit a problem like this writing polyfills that would pass WPT tests. (or if

[14:36:08.0000] <manu>
someone else had written a blog post about their experiences doing so).

[14:37:11.0000] <manu>
I'm guessing Marcos knows the magic incantations to make it work... we're trying the "edit the page HTML" approach now, but even then, you have to delay the test script being fired until after the polyfill is loaded.

[14:37:16.0000] <taaz>
there are some mentions of people doing polyfills, but it seems unclear if there's an easy way to insert such code for a whole dir of tests vs editing each file

[14:38:06.0000] <taaz>
so i was just trying to get one manually edited file to work

[14:38:44.0000] <Mek>
you could maybe modify your testharnessreport.js (which every test includes right after testharness.js), but you'd still have the problem of how to delay the actual tests...

[14:39:49.0000] <Mek>
maybe adding a start callback would do it, but then there is no guarantee that any particular test even has a body element...

[14:41:30.0000] <taaz>
the body issue is related to some internals in an rpc lib this polyfill is using.  adding a dialog child node i think.  i'm not sure how critical it is that that be done like that

[14:43:22.0000] <taaz>
just playing with payment-request/interfaces.https.html at the moment. seems the tests are run before DOMContentLoaded fires, which is causing the issue.

[14:44:14.0000] <taaz>
i can start wrapping tests to wait on things, but that's not really an option when trying to run all the test files

[15:03:44.0000] <TabAtkins>
gsnedders: Is the wpt manifest file format documented anywhere?

[15:05:18.0000] <TabAtkins>
(The "Writing Your Own Runner" section says to use `wpt manifest`, but doesn't explain how to read the output, and the JSON file is non-obvious.)

[15:06:07.0000] <gsnedders>
TabAtkins: no :)

[15:06:14.0000] <gsnedders>
TabAtkins: look at tools/manifest/manifest.py

[15:06:31.0000] <gsnedders>
TabAtkins: though even that isn't that clear

[15:06:37.0000] <TabAtkins>
I'm already looking at that, yeah.

[15:06:43.0000] <TabAtkins>
It does not illuminate.

[15:07:34.0000] <gsnedders>
basically you have obj['items'][testtype][path] = (tests: Array)

[15:07:54.0000] <gsnedders>
except testtype now also includes things like "support"

[15:09:17.0000] <TabAtkins>
Is it possible to write this down someplace.

[15:09:33.0000] <gsnedders>
tools/manifest/item.py it probably also useful here

[15:09:38.0000] <TabAtkins>
(If I can get shamed for not writing tests, others can get shamed for not writing docs.)

[15:10:08.0000] <gsnedders>
yeah, someone needs to actually document it somewhere

[15:12:44.0000] <TabAtkins>
It looks like all I maybe need is the `paths` array, because it contains all the names I want (and I can manually parse/reassemble those into the URLs I want)?

[15:14:14.0000] <TabAtkins>
(Also, I'd never seen that particular formatting for a dict comprehension before. Confused me for a second, but clever.)

[15:17:44.0000] <gsnedders>
(it's when it gets nested it becomes a mess)

[15:17:56.0000] <gsnedders>
(also I can't guarantee I understand all of this, fwiw)

[15:18:12.0000] <gsnedders>
like, idk what the paths array is :)

[15:23:08.0000] <TabAtkins>
So right now there are 7 "testtype" values. I have no idea what they mean.

[15:24:27.0000] <TabAtkins>
Maybe I can just pretend they're all equivalent, iterate them for their paths, and call it a day.

[15:25:10.0000] <TabAtkins>
(Types are "manual", "reftest", "reftest_node", "stub", "support", "testharness", and "wdtest".)

[16:06:30.0000] <Domenic>
TabAtkins: if it helps here is what I came up with for manipulating the manifest for my own purposes. https://github.com/tmpvar/jsdom/blob/master/test/web-platform-tests/wpt-manifest-utils.js

[16:07:25.0000] <Domenic>
(hmm, that value[[0]] looks wrong... I guess it works anyway because JavaScript)

[16:08:18.0000] <TabAtkins>
Ahahaha, I was just squinting at that and tabbed back to here to ask you about that. ^_^


2017-10-18
[06:21:34.0000] <wanderview>
JakeA: looks like Edge 16 shipped abortable fetch() first... sadly the glitch demo doesn't work since they don't support TextDecoder()

[06:47:22.0000] <wanderview>
JakeA: I remixed it to work... https://fetch-abort-demo-edge.glitch.me/

[06:47:30.0000] <wanderview>
I also had to drop the pre.append() stuff

[07:11:14.0000] <gsnedders>
did someone not have a semi-maintained fork of Anolis somehwere?

[07:12:34.0000] <gsnedders>
Ah, Ms2ger, at https://bitbucket.org/ms2ger/anolis

[08:07:17.0000] <JakeA>
wanderview: ohhh cheers! Will tweet that when I'm back from holidays

[08:11:12.0000] <wanderview>
JakeA: oh, right... enjoy your family not-chrome-dev-summit event!

[10:32:34.0000] <wanderview>
and safar TP 42 seems to have initial bits landing for fetch() abort as well

[10:32:36.0000] <wanderview>
safari

[11:23:54.0000] <jsx>
Many docs in MDN lists type as DOMString where the specs says USVString. Are they interchangeable since they both indicate a JavaScript String?

[11:30:51.0000] <TabAtkins>
jsx: Technically a USVString doesn't allow unpaired surrogate codepoints, so it's not the full value space of DOMString.

[11:31:40.0000] <TabAtkins>
But for all strings you're ever going to construct for actual text, yeah, they're equivalent. (Only when you're using JS strings as a byte-storage type, or have some weirdness like a text stream that got interrupted partway thru, will you see an unpaired surrogate show up.)

[11:35:29.0000] <jsx>
TabAtkins: Hmm, ok. So I'll leave it be.

[11:35:32.0000] <jsx>
Thanks!

[11:36:38.0000] <TabAtkins>
(CSSOM is currently using CSSOMString, which is defined as `(DOMString or USVString)`, because we want to use USVString for all "real text", but some engines currently don't have good optimizations for applying that restriction (while others do).)

[11:37:48.0000] <gsnedders>
jsx: also USVString is a relatively new thing

[11:38:08.0000] <jsx>
Excuse the noob question: So is USVString a subset of DOMString?

[11:38:15.0000] <TabAtkins>
Yes.

[11:38:33.0000] <TabAtkins>
Like I said, it's a DOMString that just doesn't allow unpaired surrogates in itself.

[11:38:57.0000] <jsx>
Ok..

[11:38:58.0000] <TabAtkins>
(Aka only allows actual unicode codepoints, not arbitrary bytes.)

[11:39:08.0000] <Mek>
not sure "allow" is the right word. You can still pass strings with unpaired surrogates to methods accepting USVStrings for example, they just get removed before the underlying algorithms handle the strings

[11:39:58.0000] <TabAtkins>
Ah, I couldn't remember if violating the restriction threw an error or just converted.

[11:40:36.0000] <Mek>
https://heycam.github.io/webidl/#dfn-obtain-unicode is how a DOMString is converted to a USVString, no throwing in there

[12:26:06.0000] <Domenic>
+1 Mek

[12:26:43.0000] <Domenic>
I found https://infra.spec.whatwg.org/#strings but to be fair I did have a large hand in helping write it


2017-10-19
[00:28:18.0000] <nox>
annevk: How dare you make overt declarations of war?

[00:34:40.0000] <Ms2ger>
/me throws a spear at nox's temple

[00:34:48.0000] <nox>
:)

[07:36:54.0000] <nox>
This is amazing.

[07:37:57.0000] <jgraham>
nox: Glad you think so

[07:38:37.0000] <nox>
"Only Chrome" "Ok Chrome and minor input from others" "Ok browsers but what about the rest"

[07:38:59.0000] <nox>
Goalposts moving faster in space than Usain Bolt.

[07:40:12.0000] <jgraham>
nox: You might have to tell me what the context is

[07:40:14.0000] <jgraham>
:)

[07:40:54.0000] <nox>
jgraham: I understand your confusion now,

[07:41:03.0000] <nox>
you live in an universe where people find new windmills,

[07:41:09.0000] <nox>
but they don't in ours: https://github.com/whatwg/url/issues/118#issuecomment-337742987

[07:41:22.0000] <nox>
Good old URL drama

[07:54:44.0000] <nox>
Ah ah I only now noticed "https://///url.spec.whatwg.org/ writes that the goal of the WHATWG is to"

[07:54:49.0000] <nox>
With the ////

[07:59:36.0000] <annevk>
nox: magcius is correct btw, address bar is UX

[08:00:18.0000] <nox>
annevk: I don't remember disagreeing with that, so maybe I miswrote something.

[08:00:32.0000] <annevk>
Not sure where all the anger is coming from with the others

[08:00:43.0000] <annevk>
Why waste time on failed standards?

[08:01:16.0000] <nox>
annevk: Oh yes, for me the address bar isn't part of the Web platform.

[08:01:37.0000] <nox>
annevk: So I wasn't disagreeing with that part of it, I was just also writing down that it's not just about the HTML source.

[08:01:53.0000] <annevk>
Fair

[08:02:01.0000] <nox>
But it wasn't very clear indeed.

[08:02:57.0000] <nox>
annevk: That Safari copes with /// from JS but not from the address bar is quite unfortunate, TBH.

[08:29:33.0000] <annevk>
nox: why?

[08:37:01.0000] <nox>
annevk: Am just weirded out by the fact that it somehow ends up looking up localhost from the address bar.

[09:08:58.0000] <annevk>
oh

[10:19:09.0000] <Domenic>
Hmm I was hoping to counteract the Safari narrative using https://wpt.fyi/url but the old version of Safari used there doesn't help our case. The new version should be very green though.

[10:21:48.0000] <jgraham>
Domenic: Yes, so getting OSX at all is a pain. And getting OSX with a non-default Safari is an even bigger pain. It currently uses Sauce

[10:23:52.0000] <jgraham>
Safari 10 is the latest avaiable

[10:23:56.0000] <jgraham>
On sauce

[10:26:06.0000] <Bakkot>
am I reading https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#HTMLAllCollection-call correctly as implying `document.all() === null`?

[10:26:37.0000] <Bakkot>
both Chrome and Safari give undefined, not null, is why I ask

[10:26:50.0000] <Bakkot>
And Firefox throws with “too few arguments"

[10:30:10.0000] <Bakkot>
actually, I see safari has switched to returning null sometime between stable and tech preview

[10:39:21.0000] <Bakkot>
ah, yes, I see that’s tested. https://github.com/w3c/web-platform-tests/blob/41f06d4c660aa97ba9ec08be03723460bdfd6c96/html/infrastructure/common-dom-interfaces/collections/htmlallcollection.html#L218

[11:24:36.0000] <Domenic>
Bakkot: yeah, there hasn't been great interop, but things are getting better.

[11:43:07.0000] <jsx>
If a browser is using USVString for one API which asks for CSSOMString (say for FontFace), is it guaranteed that it will be using USVString for all instances for CSSOMString?

[12:47:58.0000] <TabAtkins>
jsx: Yes. https://drafts.csswg.org/cssom/#cssomstring-type (The definition is actually that it's one or the other, not (DOM or USV).)

[12:49:13.0000] <jsx>
Ok, I just wanted to confirm that the the choice is universal across all APIs in that browser

[12:51:26.0000] <TabAtkins>
Per spec, yes it is.

[12:52:27.0000] <jsx>
Ok, thanks.


2017-10-20
[23:04:30.0000] <yhirano__>
annevk: yt?

[23:06:06.0000] <yhirano__>
annevk: I would appreciate if you could review https://github.com/w3c/web-platform-tests/pull/7671.

[23:54:36.0000] <annevk>
yhirano__: I suggest asking JakeA; I'm technically on leave and only plan to work on a couple things during that time

[23:54:54.0000] <annevk>
yhirano__: I'll have more time starting next month and back to full-time December most likely

[23:55:36.0000] <yhirano__>
annevk: thanks!

[00:16:31.0000] <JakeA>
annevk: yhirano__: I'm on leave until Wednesday, but will catch up then

[00:17:59.0000] <yhirano__>
JakeA: thank you.

[06:22:26.0000] <mounir>
annevk: hey, about user activation delegation, I was wondering if you could have a look about my latest comments

[06:23:40.0000] <nox>
annevk, Domenic: You both are so patient.

[06:24:11.0000] <annevk>
mounir: heya, I can have a look

[06:25:45.0000] <annevk>
nox: I try, it's not worth it to get upset

[06:25:58.0000] <Domenic>
annevk sets a good example for me

[06:26:07.0000] <nox>
Domenic: Actually,

[06:26:11.0000] <nox>
when I'm on whatwg,

[06:26:30.0000] <nox>
my first thought is "if I get angry, will that make annevk's and Domenic's job harder having to clean up my shit",

[06:26:35.0000] <nox>
and then I calm myself down. :P

[06:28:32.0000] <annevk>
keep it up 😊

[06:30:14.0000] <nox>
"And it worries me greatly that you apparently haven't even read the RFCs while trying to replace them." Oh my

[06:31:53.0000] <gsnedders>
nox: where is this?

[06:33:06.0000] <nox>
gsnedders: https://github.com/whatwg/url/issues/118#issuecomment-338206323

[06:33:39.0000] <nox>
gsnedders: Not much value reading it, except for Friday afternoon popcorning.

[06:38:54.0000] <gsnedders>
nox: oh I got that from the quote ;P

[06:39:18.0000] <mounir>
annevk: thanks :)

[06:39:39.0000] <nox>
gsnedders: Here is something more interesting: https://twitter.com/goldengateblond/status/920785613003087872

[06:40:14.0000] <mounir>
Domenic, annevk: I'm hoping we can resolve than name problem given that it's one of the two open issues

[06:40:23.0000] <mounir>
annevk: no update on #8?

[06:40:35.0000] <mounir>
ie. https://github.com/WICG/gesture-delegation/issues/8

[06:44:36.0000] <annevk>
mounir: patience

[06:44:44.0000] <annevk>
😃

[06:45:25.0000] <mounir>
annevk: just wanted to make sure you have it in your rader :)

[06:45:39.0000] <mounir>
annevk: thanks for your responsiveness though :)

[06:46:41.0000] <justJanne>
annevk: to avoid spamming the issue tracker further: it's just hat the RFCs are used basically everywhere, and your claim of obsoleting and replacing them has made huge waves everywhere.

[06:47:17.0000] <justJanne>
Especially because the WHATWG is known for being — due to its nature — biased towards the web, over other fields of IT

[06:47:50.0000] <justJanne>
And WHATWG replacing a spec that basically has unlimited scope and is used everywhere and was defined over many years by stakeholders from all fields,

[06:48:05.0000] <justJanne>
With a spec that has had very little external inout and publicity before it got standardized,

[06:48:21.0000] <justJanne>
Rubs a lot of people the wrong way, due to the perceived arrogance of that statement

[06:48:55.0000] <annevk>
justJanne: did you verify that it's actually used everywhere by testing the implementations? E.g., as is clear from that issue curl doesn't conform to it

[06:49:01.0000] <justJanne>
And it doesn't make working with URLs easier when we now have different standards with different scopes that both claim to be universal

[06:49:23.0000] <annevk>
justJanne: I don't think most "RFC implementations" actually conform, despite claims to the contrary

[06:49:26.0000] <justJanne>
annevk: the issue isn't with the leniency of an implementation, but the strictness.

[06:49:46.0000] <justJanne>
Most "RFC implementations" will be less strict than the RFC

[06:50:02.0000] <annevk>
justJanne: okay, could you explain to me how those are different? If you're more lenient you're less strict, no?

[06:50:08.0000] <justJanne>
Exactly,

[06:50:25.0000] <annevk>
justJanne: so how is it with either leniency or strictness? Aren't they the same?

[06:50:32.0000] <justJanne>
No, like,

[06:51:06.0000] <nox>
It's easy to have a RFC that is "used basically everywhere" when that RFC is very underspecified, vague, and special cased by pretty much everyone in different ways.

[06:51:31.0000] <justJanne>
nox: the RFC defines a very strict form of the URL that is always valid.

[06:51:31.0000] <annevk>
Well, the RFC is not vague or underspecified, it's just not compatible with deployed content and major implementations

[06:51:34.0000] <justJanne>
See appendix A

[06:51:40.0000] <nox>
Yes, from which everyone deviates.

[06:51:43.0000] <nox>
In different ways.

[06:51:48.0000] <justJanne>
Not really.

[06:52:01.0000] <justJanne>
As long as your URL matches the ABNF from appendix A, it will work everywhere

[06:52:16.0000] <justJanne>
The problem is that the WHATWG spec allows URls that the RFC spec doesn't.

[06:52:23.0000] <justJanne>
So people start using these URLs

[06:52:28.0000] <annevk>
justJanne: no we don't, as I already pointed out

[06:52:34.0000] <justJanne>
And RFC parsers suddenly all interpret them differently

[06:52:54.0000] <annevk>
justJanne: the URL Standard has a very strict definition of what's a valid URL, which matches that of IRIs

[06:53:03.0000] <justJanne>
annevk: you don't allow them, but you still define a way how to handle them (and all implementors of whatwg specs handle them without even a warning)

[06:53:08.0000] <nox>
The URL parser from the URL Standard will accept >2 slashes *BECAUSE* the real world has URLs with >2 slashes,

[06:53:13.0000] <nox>
let's not reverse causality here.

[06:53:20.0000] <justJanne>
nox: that's a problem, though

[06:53:24.0000] <annevk>
justJanne: sure, because that's required from implementations that want to consume arbitrary content

[06:53:32.0000] <justJanne>
Because in the reality, urls > 2 slashes will break at some place

[06:53:43.0000] <justJanne>
Because most implementations don't accept them

[06:53:44.0000] <nox>
The problem is writing a spec-compliant parser and not actually being able to work in real world URLs.

[06:53:49.0000] <justJanne>
Well, no.

[06:54:10.0000] <annevk>
justJanne: I think I see where you're coming from, but what you're advocating is anti-competitive

[06:54:17.0000] <justJanne>
nox: say you type a URL into an IRC client.

[06:54:23.0000] <nox>
And?

[06:54:28.0000] <justJanne>
What do you expect will the client of another user interpret?

[06:54:32.0000] <nox>
Texgt.

[06:54:34.0000] <annevk>
justJanne: it basically disadvantages new URL software over existing URL software that deals with existing content

[06:54:35.0000] <justJanne>
Will they use the RFC parser?

[06:54:46.0000] <justJanne>
Will they use the whatwg parser?

[06:54:51.0000] <nox>
I have no idea why you are focused on URLs in plain text.

[06:55:04.0000] <annevk>
justJanne: which is very bad from the perspective of keeping the web a healthy competitive ecosystem

[06:55:09.0000] <justJanne>
I write IRC clients that support autolinking

[06:55:18.0000] <justJanne>
And I get frequently bug reports.

[06:55:25.0000] <nox>
Yes because the RFCs are bad.

[06:55:37.0000] <justJanne>
Both in the direction of "this link works in other clients, but not in yours"

[06:55:48.0000] <nox>
Cf. annevk's example of trailing dots.

[06:55:49.0000] <justJanne>
And in "this link works in your client, but not others"

[06:55:57.0000] <justJanne>
I get both of these reports.

[06:56:00.0000] <nox>
So?

[06:56:06.0000] <justJanne>
And it's getting a lot worse recently

[06:56:16.0000] <justJanne>
Because web-based clients startvusing the whatwg url parser

[06:56:24.0000] <justJanne>
And as result, they deviate from all other clients

[06:56:27.0000] <justJanne>
And other software.

[06:56:55.0000] <nox>
I had linkify issues in 2000 already, before the WHATWG URL Standard was a thing.

[06:57:02.0000] <justJanne>
And as result, users copy-paste URLs that are increasingly broken

[06:57:05.0000] <nox>
Not sure how that's an argument against or for that standard.

[06:57:10.0000] <nox>
"broken"

[06:57:11.0000] <annevk>
justJanne: do you have examples? I think it would be nice if there was a decent text-to-URL specification, but nobody has written one yet

[06:57:25.0000] <annevk>
justJanne: hmm, that can't really happen

[06:57:29.0000] <nox>
I remember lots of issues with parens in URLs, for example.

[06:57:36.0000] <annevk>
justJanne: at the point URLs are exposed to users they're already normalized

[06:57:55.0000] <annevk>
justJanne: so e.g. a space would be converted to %20 at that point

[06:58:03.0000] <justJanne>
nox: ' is tbe most annoying part

[06:58:04.0000] <annevk>
justJanne: so maybe that's a different problem

[06:58:16.0000] <justJanne>
annevk: they're not always normalized the same way

[06:58:31.0000] <annevk>
justJanne: across browsers?

[06:58:34.0000] <justJanne>
I've seen browsers normalize ' away, or leave it i.

[06:58:35.0000] <justJanne>
*in

[06:59:12.0000] <annevk>
justJanne: sure, that's what we're trying to fix, in part (although again, the address bar is somewhat out of this, but also shouldn't really violate the RFC as far as I know)

[06:59:38.0000] <justJanne>
Well, the problem is also that URLs aren't always normalized

[06:59:53.0000] <justJanne>
Users copy-paste URLs from other sources, too.

[06:59:54.0000] <annevk>
justJanne: if you run into issues like this feel free to file them against whatwg/url and we can figure out how to best solve them

[07:00:04.0000] <annevk>
justJanne: I'd love concrete feedback like that

[07:00:09.0000] <justJanne>
And if a browser accepts them, every other software has to accept them, too

[07:00:51.0000] <annevk>
So what do you think about the example I gave?

[07:00:58.0000] <annevk>
https://example.com.

[07:01:07.0000] <annevk>
Is the trailing dot part of the URL or not?

[07:01:10.0000] <justJanne>
That's the worst example you could pick.

[07:01:19.0000] <gsnedders>
How much of this is down to what the browser exposes in the address bar or "copy link" or similar UI pieces? Because neither the RFC nor the WHATWG spec define behaviour there.

[07:01:30.0000] <annevk>
Edge cases is what standards are all about

[07:01:39.0000] <justJanne>
That's not an edge case.

[07:01:55.0000] <justJanne>
example.com evaluates to example.com. due to DNS resolution

[07:02:04.0000] <annevk>
gsnedders: it sounds like copying into the address bar vs copying into IRC client from a random source is also problematic

[07:02:05.0000] <justJanne>
They are identical domajns

[07:02:11.0000] <justJanne>
And as result, identical URLs

[07:02:21.0000] <annevk>
justJanne: that really depends on your local DNS configuration

[07:02:27.0000] <justJanne>
Nope

[07:02:31.0000] <annevk>
justJanne: yes it does

[07:02:35.0000] <justJanne>
That is the very definition of the DNS standard.

[07:02:39.0000] <justJanne>
nowadays

[07:02:48.0000] <annevk>
justJanne: example.com might be short for example.com.mycorp.internal

[07:02:51.0000] <justJanne>
Because every browser does DNS resolution wrong.

[07:02:59.0000] <justJanne>
annevk: yes, exactly.

[07:03:06.0000] <justJanne>
Except, browsers ignore that.

[07:03:09.0000] <annevk>
justJanne: so it's not at all identical to example.com.

[07:03:19.0000] <justJanne>
And then are surprised that example.com gets a cert for example.com.internal.corp

[07:03:43.0000] <justJanne>
Browsers today only work if a relative domain resolves to the same as an absolute domain

[07:03:52.0000] <annevk>
That doesn't relate to DNS resolution though

[07:03:56.0000] <annevk>
That's how certificates work

[07:04:02.0000] <justJanne>
Although some webservers, about 2%, refuse to allow relative domains

[07:04:11.0000] <justJanne>
whatwg.org. is broken, for example

[07:04:19.0000] <justJanne>
google.com. and my own sites work

[07:04:37.0000] <annevk>
We could probably fix that

[07:04:41.0000] <justJanne>
As nginx, haproxy, GCP, AWS, CloudFlare, IIS, Apache implement this correctly,

[07:04:50.0000] <justJanne>
I assume you are using traefik or caddy

[07:05:14.0000] <justJanne>
Edge cases.

[07:05:35.0000] <annevk>
https://github.com/whatwg/whatwg.org/issues/100

[07:05:59.0000] <justJanne>
And almost every edge case I find that breaks things is when some web developers suddenly think that reinventing the wheel is a good idea.

[07:06:08.0000] <justJanne>
Including reinventing URL standards.

[07:06:36.0000] <annevk>
You haven't really addressed my feedback on that your approach is anti-competitive

[07:06:47.0000] <justJanne>
That's not a problem.

[07:06:49.0000] <annevk>
It makes it harder to write a new browser if browsers have to reverse engineer each other

[07:06:59.0000] <justJanne>
And they don't have to.

[07:07:07.0000] <justJanne>
The long term goal is increasing strictness.

[07:07:58.0000] <justJanne>
Over the past decades, we went from ignoring certificate errors to TLS chain validation, to dropping SHA1 certs, to HSTS and HPKP, all increasing strictness. In many other parts, the same happened

[07:08:21.0000] <gsnedders>
They have to if they want any success of in the market. We've from time to time had browsers that have followed specs more strictly than others and ultimately failed to get marketshare in part becaues of sites not working.

[07:08:27.0000] <justJanne>
Increasing strictness improves interoperability, and allows new vendors to easier comepte

[07:08:30.0000] <justJanne>
*compete

[07:09:05.0000] <justJanne>
gsnedders: and yet increasing strictness in the TLS parts hasn't harmed marketshare at all.

[07:09:17.0000] <justJanne>
Nor did dropping flash piece by piece.

[07:09:19.0000] <annevk>
I don't think we managed to deprecate quite as much outside TLS

[07:09:23.0000] <justJanne>
Nor addons.

[07:09:24.0000] <annevk>
That's a rather unusual case

[07:10:13.0000] <justJanne>
Dropping HTML5 apis for pages not loaded via TLS (geolocation, etc)

[07:10:24.0000] <justJanne>
By now it's more than a dozen APIs that got dropped

[07:10:31.0000] <justJanne>
Increasing strictness is possible.

[07:10:46.0000] <justJanne>
And it reduces the complexity of developing a web browser.

[07:11:11.0000] <justJanne>
Which in turn improves interoperability, and makes it easier to compete

[07:11:24.0000] <annevk>
Euh, not really

[07:11:34.0000] <annevk>
Restricting a feature to a secure context doesn't simplify it

[07:11:49.0000] <gsnedders>
The things that have been dropped are mostly things where security or privacy concerns make it easier to justify to end users breaking sites they currently use, whereas things like parsing where a significant percentage of content doesn't match any strict subset is much harder to justify to users.

[07:12:04.0000] <Domenic>
Increasing strictness does not inherently improve interoperability.

[07:12:06.0000] <annevk>
But it's also vastly different from changing the syntax of something

[07:12:13.0000] <Domenic>
What improves interoperability is coordinated movement toward a goal.

[07:12:24.0000] <justJanne>
Domenic: but you're not doing that either.

[07:12:31.0000] <justJanne>
URLs are used everywhere

[07:12:31.0000] <gsnedders>
Restricting a feature to a secure context increases complexity given you now have more forks in your code that depend on whether the document was loaded over a secure context.

[07:12:44.0000] <annevk>
Indeed

[07:12:45.0000] <Domenic>
We definitely are; we've made great strides in URL unification across browsers, Node.js, Rust, Go, etc.

[07:12:47.0000] <justJanne>
Whatwg isn't coordinating with most stakeholders outside of browsing on that.

[07:13:03.0000] <Domenic>
I've laid out a path for improving interoperability that also increases strictness at https://github.com/whatwg/url/issues/118#issuecomment-218323801

[07:13:11.0000] <justJanne>
Yes, great. Rust and Go are both written by browser vendors.

[07:13:12.0000] <Domenic>
But nobody has started working on it.

[07:13:13.0000] <annevk>
justJanne: you still haven't answered my question about who else you need us to reach out to

[07:13:22.0000] <justJanne>
And node.js literally uses a browser JS engine

[07:13:36.0000] <justJanne>
That's still at zero external stakeholders.

[07:13:46.0000] <gsnedders>
The browser JS engine doesn't include any URL parser…?

[07:13:56.0000] <justJanne>
It does nowadays actually

[07:13:58.0000] <annevk>
Yeah, pretty sure they wrote their own URL parser

[07:14:07.0000] <annevk>
justJanne: no it doesn't

[07:14:07.0000] <justJanne>
The standard specifies a JS URL interface, and parser.

[07:14:22.0000] <justJanne>
The URL object's API is defined in the standard,

[07:14:22.0000] <annevk>
justJanne: no browser implements that in the JS engine

[07:14:25.0000] <gsnedders>
And Go is a very different part of Google to anything web facing.

[07:14:28.0000] <justJanne>
And how it should parse it.

[07:14:39.0000] <annevk>
justJanne: different layer of the system, just like it's a different layer in Node.js

[07:14:57.0000] <gsnedders>
justJanne: It doesn't appear in ECMA-262, and isn't implemented in any browser JS VM. There's a DOM URL object that browsers implement, but that's a host object implemented outwith the JS VM.

[07:15:13.0000] <gsnedders>
justJanne: JS VMs implement very, very little that isn't in ECMA-262

[07:15:30.0000] <justJanne>
so, did you ever check what other RFCs reference the URL RFCs, and discussed with those what the deprecation of the URL RFC would mean?

[07:16:21.0000] <justJanne>
If you say that replacement of a widely used standard is a goal, I'd expect that you'd have made a study determining the impact of this, and determining who would be affected.

[07:16:27.0000] <annevk>
justJanne: in most cases there's not much impact as far as I can tell

[07:16:31.0000] <justJanne>
Or at least some kind of discovery

[07:16:50.0000] <annevk>
justJanne: RFCs that build upon URLs build upon the data model

[07:16:54.0000] <justJanne>
Little impact yet, many of these effects ripple down over years.

[07:17:03.0000] <annevk>
justJanne: there's one RFC that tries to modify the syntax, but that's a very controversial one

[07:17:04.0000] <justJanne>
annevk: many also build upon the syntax.

[07:17:25.0000] <justJanne>
For example, by saying "... Shall be a URI as defined in RFC ..."

[07:17:45.0000] <justJanne>
For these, minor changes in the URL syntax might lead to changes in how their parser works

[07:18:08.0000] <justJanne>
And if users come to expect more lenient URL parsing due to browsers, that might ripple down.

[07:18:24.0000] <annevk>
justJanne: sure, I don't see that as a problem

[07:18:56.0000] <justJanne>
Did you determine which standards, languages and libraries do this, and might be affected by this?

[07:19:20.0000] <annevk>
justJanne: every library that implements URLs is in some sense affected already

[07:19:56.0000] <justJanne>
Good. So you know who you'd have to ask before publishing and finishing the spec.

[07:19:56.0000] <annevk>
justJanne: the moment someone tries to use it to scrape web content that library will find itself in the position where it has to figure out how to deal with U+0020 in a URL

[07:20:28.0000] <justJanne>
Everyone that ever parses URLs, from any content, anywhere.

[07:20:28.0000] <annevk>
justJanne: I would expect those people to read uri⊙wo and have seen the various requests for feedback

[07:20:37.0000] <annevk>
justJanne: and indeed there has been some of that

[07:20:57.0000] <annevk>
justJanne: more would be great, but I suspect they're all strapped for time too and rather not look at their URL parser too often

[07:21:03.0000] <justJanne>
Correct.

[07:21:17.0000] <justJanne>
So did you make an effort to enumerate and contact such projects and standards?

[07:21:30.0000] <justJanne>
Before standardizing your spec, ideally?

[07:21:55.0000] <annevk>
This issue was raised repeatedly with the IETF back in 2011 or so or maybe even earlier

[07:21:59.0000] <annevk>
I'm sure they're all aware

[07:22:18.0000] <justJanne>
I'll ask again, did you try to enumerate and contact them?

[07:22:19.0000] <annevk>
It's just that nobody really wanted to work on it within the IETF so it went elsewhere

[07:22:43.0000] <justJanne>
Because that sounds like a no.

[07:23:01.0000] <annevk>
For sure it's a no, I'm happy with incremental adoption

[07:23:18.0000] <annevk>
And I think there's been enough outreach to the various standardization places around URLs that exist

[07:23:20.0000] <justJanne>
It sounds to me like you tried obsoleting and replacing a stabdard without even determining who would be affected by this,

[07:23:28.0000] <justJanne>
Or trying to contact them.

[07:24:08.0000] <annevk>
If that's what you take away from the above, that's your prerogative

[07:24:14.0000] <Domenic>
One of the wonderful things about standards is that they are used by many people across the community

[07:24:16.0000] <justJanne>
Because most projects that deal with this never even heard of your spec, and those that did, mostly because of the huge outrage that was on HN when your spec was already finished and people discovered what happened.

[07:24:27.0000] <Domenic>
Not all of them, indeed the majority of them, are not known to the authors

[07:24:39.0000] <Domenic>
Certainly when we make a change to, e.g., HTML, we don't contact every site that uses HTML!

[07:24:45.0000] <justJanne>
Correct.

[07:24:57.0000] <justJanne>
But in industry standards, this is expected.

[07:25:32.0000] <justJanne>
If you'd redefine the size of ISO/EN/DIN A4 paper, you certainly would have to first contact every manufacturer of paper, of paper producing machines, cutters, orinters, and co.

[07:25:36.0000] <annevk>
HTML is not an industry standard?

[07:25:36.0000] <justJanne>
And that's what you'd do.

[07:25:39.0000] <justJanne>
*printers

[07:25:43.0000] <annevk>
Is JavaScript an industry standard?

[07:25:54.0000] <Domenic>
Hah, we definitely don't contact all users of JavaScript when making changes to the JS spec.

[07:25:59.0000] <justJanne>
They're standards in an entirely different way.

[07:26:08.0000] <Domenic>
I don't find this line of reasoning that you need to contact all users of a spec when you change it convincing at all.

[07:26:10.0000] <justJanne>
They're expected to change frequently, vague,

[07:26:14.0000] <justJanne>
etc.

[07:26:22.0000] <annevk>
o_O

[07:26:28.0000] <Domenic>
Can you cite a vague part of the JS spec?

[07:26:47.0000] <justJanne>
The URL spec is used in standards that are required by law in some jurisdictions

[07:27:00.0000] <justJanne>
That's where this really becomes a different situation

[07:27:27.0000] <Domenic>
So are HTML and JS

[07:27:33.0000] <justJanne>
There's jurisdictions where the law requires for certain situations a certain standard, which requires some oarts to be serialized using the URL RFC

[07:28:02.0000] <justJanne>
When a serialization format is defined in laws, and the underlying spec starts to change, that has a lot different implications

[07:28:04.0000] <annevk>
Yeah that goes for most standards

[07:28:17.0000] <annevk>
And yet somehow they all get to change and laws adapt

[07:28:28.0000] <justJanne>
That's your mindset?

[07:28:33.0000] <justJanne>
Break the world?

[07:29:05.0000] <justJanne>
We don't want to make URLs strict to avoid breaking some hobbyists blog, but breaking legsl definitions is fine?

[07:29:16.0000] <annevk>
That seems like hyperbole

[07:29:47.0000] <justJanne>
Well, that's what I read out of "somehow they all get laws to adapt"

[07:30:24.0000] <Domenic>
I'd love to hear more about how the WHATWG has broken some country's legal codes. That is an amount of power I never knew we had.

[07:30:27.0000] <justJanne>
Which sounds like breaking someone's blog was given more consideration with this spec than downstream specs and legal definitions.

[07:30:34.0000] <Domenic>
What crimes can I commit now, in what jurisdictions?

[07:30:58.0000] <annevk>
Domenic: I'd hope they file an issue

[07:31:03.0000] <justJanne>
Probably nothing, but the standardized APIs some banks have to provide might now not work anymore.

[07:31:22.0000] <annevk>
justJanne: if you could stop it with the straw mans that'd be appreciated

[07:31:27.0000] <Domenic>
I'd love to hear how changing a document on whatwg.org broke bank APIs

[07:31:39.0000] <Domenic>
concrete examples are, I think, more helpful than strawpersons.

[07:32:14.0000] <justJanne>
I haven't yet fully read the HBCI standard yet, it's 800 pages of german text, written in prose, defining a SOAP api

[07:32:23.0000] <justJanne>
So I can't link it right now

[07:32:48.0000] <annevk>
justJanne: first you claim we have a failed standard and now you claim we break the world

[07:32:53.0000] <annevk>
justJanne: it comes across a little nutty

[07:33:06.0000] <annevk>
justJanne: I'd love to work with you on interoperability issues you hit

[07:33:07.0000] <justJanne>
annevk: well, I'm saying that maybe your goals are defined wrongly.

[07:33:16.0000] <annevk>
justJanne: both with respect to your IRC client and with respect to any laws

[07:33:21.0000] <justJanne>
If you define your goals as replacing a globalky used standard,

[07:33:27.0000] <justJanne>
Then either you do break the world,

[07:33:28.0000] <annevk>
justJanne: but I think I'll restrict it to that from now on

[07:33:32.0000] <justJanne>
Or, if you don't break the world,

[07:33:35.0000] <justJanne>
You've failed.

[07:33:38.0000] <annevk>
justJanne: as we're not making progress here

[07:33:54.0000] <justJanne>
annevk: maybe just make the introduction of the spec a little less universal?

[07:34:06.0000] <justJanne>
Maybe just write defining URLs in the context of ...?

[07:34:34.0000] <justJanne>
If you write obsoleting every other URL spec, that has some kind of arrogance that comes across a bit nutty.

[07:36:58.0000] <annevk>
I don't want to leave any room for systems to think they need two different URL parsers, that way lies madness

[07:37:01.0000] <Domenic>
Yeah, I agree with annevk, the most productive way forward is to open individual issues on interoperability problems or ways in which we have broken the legal code of specific countries, with details; trying to deal with these strawpersons is not helpful without concrete issues.

[07:39:37.0000] <justJanne>
Okay, that's an interesting solution, but okay

[07:40:59.0000] <justJanne>
Domenic: the basic problem, though, is the sheer arrogance of redefining such a widely used standard without even determining whom it might affect. This is the farthest reaching change afaik the WHATWG has ever done.

[07:41:59.0000] <justJanne>
This is going to get real fun, dealing with broken URLs everywhere.

[07:42:17.0000] <justJanne>
I hate it already.

[07:45:55.0000] <justJanne>
annevk: direct, concrete question: could the changed node.js, rust or go URL APIs potentially serialize a URL, that an RFC-compliant parser can not parse?

[07:46:39.0000] <annevk>
justJanne: yeah, something like http://test/?%test could be serialized as is

[07:47:29.0000] <justJanne>
That's a potential issue then, isn't it, if one client serializes content with such a library, and another endpoint tries to deserialize it with an RFC parser?

[07:48:16.0000] <annevk>
justJanne: yeah, it might be worth going through those kind of differences and see what we can accomplish

[07:48:35.0000] <justJanne>
I'll try and find examples of standards using this.

[07:48:46.0000] <annevk>
justJanne: I suspect there's a couple like that, but % is definitely the easiest one (and I think long interoperable across browsers unfortunately)

[07:49:16.0000] <Domenic>
which brings us back to  https://github.com/whatwg/url/issues/118#issuecomment-218323801 :)

[07:49:30.0000] <justJanne>
I know that OpenID Connect defines endpoints by a json at a specified point that contains the endpoints, potentially including queries, as URL

[07:49:53.0000] <justJanne>
And that there are OIDC clients in Java, and identity providers written in node.js,

[07:50:20.0000] <justJanne>
Both using the language's URL subsystem for serialization/deserialization

[07:50:36.0000] <justJanne>
I'll try to build an example that leads to issues

[07:51:30.0000] <justJanne>
I also know that the FinTS banking API does the same for endpoints, but in XML, but I think all servers there are stil using the RFC serialization

[07:52:10.0000] <justJanne>
Domenic: the problem is that these things should have happened before publishing the spec

[07:52:26.0000] <justJanne>
So the people that might be affected could have a voice in defining yhe spec

[07:52:40.0000] <annevk>
This was already a problem with or without this spec

[07:52:58.0000] <annevk>
This spec just puts it in the sunlight, making it more visible and maybe possible to fix

[07:52:58.0000] <justJanne>
By now it might end up either breaking the web, or breaking the rest of tech that relies on URLs, if we have incompatible standards

[07:53:36.0000] <justJanne>
annevk: the whole point of a spec is to define an interoperable formst that is guaranteed to be supported by anyone and everyone for decades.

[07:53:38.0000] <annevk>
Lots of straw manning again justJanne

[07:53:49.0000] <justJanne>
annevk: well, that's the potential worst case scenario

[10:14:52.0000] <TabAtkins>
jgraham, gsnedders, other people interested in WPT stuff: https://github.com/tabatkins/bikeshed/issues/1116 is my plan for adding inline test annotations to Bikeshed. Review and comments welcome!

[10:16:04.0000] <nox>
There are a lot of websites out there that don't work anymore if you put a dot after the hostname.

[10:16:14.0000] <nox>
And that's not really considered a bug AFAIK.

[10:20:57.0000] <jgraham>
TabAtkins: Oh, interesting idea. It cleanly solves a lot of problems I think. It will be interesting to see if it works :)

[10:21:21.0000] <jgraham>
Uh, imagine I had a broad enough vocabulary not to use interesting twice in two sentences.

[10:23:55.0000] <gsnedders>
/me will look shortly

[10:25:04.0000] <jgraham>
Imagine if I could count to three

[10:26:14.0000] <TabAtkins>
That'd be the day.

[10:26:42.0000] <gsnedders>
/me is having one of those days where he feels motivated to bother reporting minor hate crime

[10:27:15.0000] <gsnedders>
(I'm totally fine, don't worry!)

[11:24:43.0000] <justJanne>
nox: less than 2% of the alexa top million

[11:24:49.0000] <justJanne>
nox: And that’s out of spec

[11:24:57.0000] <nox>
2% is a damn lot.

[11:25:06.0000] <justJanne>
That’s their problem

[11:25:12.0000] <justJanne>
I use .s at the end by default

[11:25:22.0000] <justJanne>
if that doesn’t work with sites, users can file bugs with the sites

[11:25:34.0000] <justJanne>
Or I file bugs with the sites and their webservers

[11:25:45.0000] <justJanne>
although caddy refuses to support absolute DNS names to this day

[11:26:20.0000] <justJanne>
generally this should be handled by web browsers, and they should simply always resolve the absolute name and send the relative hostname,

[11:26:48.0000] <justJanne>
but it’s easier to change laws than to change webbrowsers, as browser devs are the most stubborn people there are

[11:29:17.0000] <justJanne>
nox: also, 2% is nothing. Google Chrome dropped SHA1 just a year after 19.5% of Alexa top million sites still used it

[11:29:43.0000] <nox>
Because that was for security reasons.

[11:29:56.0000] <justJanne>
That changes nothing.

[11:29:59.0000] <nox>
Chrome doesn't chrome Web features that have no security implications even at 0.01% usage.

[11:30:05.0000] <justJanne>
It shows it is possible.

[11:30:06.0000] <nox>
s/chrome/drop/ hah

[11:30:27.0000] <justJanne>
it doesn’t? That’s interesting, because it has done that previously

[11:30:58.0000] <justJanne>
and Google does the reverse, Google today runs major products that don’t work at all on up to 30% of browsers.

[11:31:04.0000] <justJanne>
Including Google Earth and Google Allo Web

[11:31:09.0000] <nox>
That's unrelated.

[11:31:33.0000] <justJanne>
And Google dropped other features previously too at far higher usage

[11:31:47.0000] <justJanne>
such as allowing JS to start audio/video playback

[11:31:52.0000] <justJanne>
which had no security impact

[11:32:29.0000] <nox>
How is that related?

[11:32:39.0000] <justJanne>
It was a functionality dropped from a browser,

[11:32:43.0000] <justJanne>
which was used by many sites,

[11:32:49.0000] <justJanne>
without security implications

[11:32:56.0000] <justJanne>
which broke user experience on many sites

[11:32:59.0000] <nox>
Yeah and users didn't like that.

[11:33:04.0000] <justJanne>
And yet it happened

[11:33:09.0000] <justJanne>
and was forced through, to this date

[11:33:13.0000] <nox>
On the other hand, users don't like the browser exploding when a redirection to http:///blabla fails.

[11:33:38.0000] <nox>
What's the benefit for the end user to reject such redirections?

[11:33:55.0000] <justJanne>
Long-term benefits for the web?

[11:34:00.0000] <Domenic>
What benefits?

[11:34:02.0000] <justJanne>
By having less of a clusterf**k?

[11:34:09.0000] <Domenic>
See topic

[11:35:13.0000] <justJanne>
I mean, why do many of the recent web standards exist? Many exist to improve reliability of the sites that are written, and to reduce edge cases.

[11:35:42.0000] <justJanne>
reducing edge cases is often mentioned as goal for specific changes, and it should be reason enough to do non-destructive changes

[11:37:03.0000] <nox>
You can't reduce edge cases of old features without breaking a lot of websites that will most probably never get fixed.

[11:37:48.0000] <justJanne>
That was why the W3C back in the day introduced versioning, so that newer sites could have less edge cases to deal with, but compatibility with old sites could be kept.

[11:38:37.0000] <nox>
That didn't go very well, did it?

[11:38:48.0000] <justJanne>
It worked everywhere else.

[11:39:16.0000] <justJanne>
Changing standards to reduce edge cases takes time, but it certainly is possible.

[11:40:28.0000] <justJanne>
I’m not sure why you think that your standardization effort won’t be able to do so, when even the metric system managed to replace all those tiny different versions over decades.

[11:40:32.0000] <nox>
Well clearly it wasn't working for the Web, the W3C spec of HTML was mostly useless for vendors.

[11:40:56.0000] <nox>
I don't see how that's related to the metric system.

[11:40:58.0000] <Domenic>
Yep, it's certainly possible. See the concrete plan at  https://github.com/whatwg/url/issues/118#issuecomment-218323801 and get working on it if you're interested!

[11:41:11.0000] <justJanne>
The WHATWG specs have the opposite issue, nox

[11:41:36.0000] <justJanne>
they’re written almost exclusively for implementors of user agents, and not for people trying to generate input

[11:41:40.0000] <nox>
The WHATWG specs drop things when they can get dropped.

[11:41:53.0000] <nox>
And they don't change for no reason once something has reached convergence.

[11:42:05.0000] <justJanne>
They’re descriptivist, yes.

[11:42:07.0000] <nox>
Authors contribute to the spec too.

[11:42:14.0000] <justJanne>
But standards should be prescriptivist.

[11:43:14.0000] <justJanne>
The only descriptivist standards outside of WHATWG that ever got popular are the Office Open XML standards, and they’re just as much of a clusterf**k

[11:43:39.0000] <nox>
Well, it did get popular, right?

[11:43:46.0000] <TabAtkins>
(CSS has quite a lot of descriptivist stuff in its specs, recognizing what happens after-the-fact and adjusting the spec to match.)

[11:44:02.0000] <justJanne>
nox: yes, the .docx formats got popular, but that was before the standard,

[11:44:08.0000] <nox>
I mean the Web.

[11:44:29.0000] <justJanne>
Well, the WHATWG standards are closely resembling the MS Office Open XML standard story

[11:44:39.0000] <nox>
How so?

[11:45:29.0000] <justJanne>
Well, both got popular before standardization, the standards are just descriptions of the 1-3 largest implementations' behaviour, and they're impossible to implement for a new vendor

[11:45:44.0000] <nox>
And how does people make a new browser if there is absolutely no document that actually represents the state of art of the real world?

[11:45:59.0000] <TabAtkins>
(For a big recent one, see the Tables spec.)

[11:46:09.0000] <justJanne>
Standards aren’t generally written like that, nox

[11:46:25.0000] <nox>
How is having no spec at all, or a spec that doesn't work for real websites, be able to let anyone make a new browser?

[11:46:25.0000] <justJanne>
standards are written as a spec that authors adhere to if they want theirs to work everywhere

[11:46:36.0000] <nox>
So what do we do about existing websites?

[11:46:46.0000] <justJanne>
Existing websites support the spec, or stop working

[11:46:52.0000] <justJanne>
my A4 printer also can’t load letter.

[11:47:04.0000] <justJanne>
even though lots of companies might still use US letter paper.

[11:47:04.0000] <nox>
Sounds like a great plan.

[11:47:12.0000] <justJanne>
it’s how most standards are done

[11:47:29.0000] <justJanne>
When socket standards are changed, you buy new plugs.

[11:48:17.0000] <justJanne>
Almost every standard is written first, then implemented, and authors write in adherence to the spec – or produce paper in adherence to it, or plugs, or even build monitor holders – and the other side also builds towards that spec

[11:48:21.0000] <nox>
Sockets are created by a way smaller number of people than web pages.

[11:48:29.0000] <nox>
That applies to most other standards in existence.

[11:48:36.0000] <justJanne>
And?

[11:48:55.0000] <justJanne>
Every standard drops what exists before.

[11:49:04.0000] <justJanne>
Most standards even drop significant amount of existing technology

[11:49:08.0000] <nox>
And never has something on that scale be dropped.

[11:49:13.0000] <justJanne>
Yes it has.

[11:49:18.0000] <justJanne>
When metric units were introduced

[11:49:26.0000] <justJanne>
and everything had to be remeasured, or redesigned

[11:49:40.0000] <nox>
There are way less people making physical rules and whatever than there are people making Web pages.

[11:49:54.0000] <justJanne>
It’s not about making rulers.

[11:50:13.0000] <justJanne>
when metric units were introduced, everything had to change – from your grandmas recipes to your shoe sizes

[11:50:30.0000] <justJanne>
(as often products in the new system were only available in slightly different sizes than before)

[11:50:35.0000] <justJanne>
and yet, it worked.

[11:51:09.0000] <nox>
Switching to the metric system doesn't break my old grandma recipe.

[11:51:17.0000] <nox>
I don't even know my foot size in centimetres.

[11:51:26.0000] <justJanne>
It doesn’t? Okay, what’s 2 1/3rd cups in metric?

[11:51:32.0000] <nox>
I can look it up.

[11:51:42.0000] <justJanne>
Correct.

[11:51:55.0000] <justJanne>
There is a new standard, and a published system for converting the legacy into the new system.

[11:52:00.0000] <nox>
End user can't look up that his redirection failed because there were 3 slashes.

[11:52:09.0000] <justJanne>
No, but that’s not an issue.

[11:52:13.0000] <nox>
It is.

[11:52:16.0000] <justJanne>
You can define a new spec,

[11:52:21.0000] <justJanne>
which all new sites should adhere to,

[11:52:26.0000] <justJanne>
and a translation for old ones

[11:52:37.0000] <nox>
What's the definition of the old ones?

[11:52:54.0000] <nox>
How do you get authors to update, given you know the great majority of them won't?

[11:53:09.0000] <justJanne>
Well, I have a translation table for metric units that were in my country replaced 2 centuries ago

[11:53:22.0000] <justJanne>
nox: show a visible error, or worse, in developer mode?

[11:53:32.0000] <nox>
What?

[11:53:39.0000] <justJanne>
What what?

[11:53:52.0000] <nox>
Why would the user use your browser then, instead of staying on the older one where the website continues to work?

[11:54:03.0000] <justJanne>
nox: the sites continue to work,

[11:54:12.0000] <nox>
No they don't, they show a visible error.

[11:54:17.0000] <justJanne>
in developer mode

[11:54:19.0000] <justJanne>
as I specified

[11:54:31.0000] <nox>
So when do you actually reject the 3 slashes URL?

[11:54:31.0000] <justJanne>
which would be for example visible in beta/canary versions, or with dev tools open

[11:54:42.0000] <justJanne>
You reject 3 slashes whenever you feel like it.

[11:54:47.0000] <justJanne>
that’s up to implementors.

[11:54:53.0000] <nox>
So never, right.

[11:55:01.0000] <justJanne>
That’s your choice to make.

[11:55:04.0000] <nox>
So what's the point of the strict separate standard?

[11:55:08.0000] <justJanne>
Some deprecate such things quite quickly

[11:55:20.0000] <nox>
That sounds like XHTML and nobody cared.

[11:55:28.0000] <justJanne>
Google’s Android manages to deprecate API changes within of 1 year.

[11:55:41.0000] <nox>
How is that related?

[11:55:53.0000] <nox>
There are way fewer people making Android apps than there are people making Web pages.

[11:56:00.0000] <justJanne>
Yet it’s the closest there is.

[11:56:05.0000] <justJanne>
In terms of people affected.

[11:56:24.0000] <nox>
Not even close in terms of who many people need to act upon the deprecation.

[11:56:24.0000] <justJanne>
And Google doesn’t drop APIs when 2% of people use them on Android

[11:56:28.0000] <justJanne>
or 5%

[11:56:43.0000] <justJanne>
Google drops APIs even when 100% of people rely on them on Android.

[11:56:46.0000] <nox>
And they won't under a way lower percentage for Web features.

[11:56:55.0000] <justJanne>
And that’s a problem.

[11:57:08.0000] <justJanne>
Because this way, the web will forever be stuck where it is today.

[11:57:10.0000] <nox>
We are going in circles so let's just stop, I guess.

[11:57:20.0000] <justJanne>
The web is going in circles, too.

[11:57:39.0000] <justJanne>
you need to deprecate things someday, the only question is when.

[11:58:02.0000] <nox>
When the time is right, that already happened and will continue to happen in the future.

[11:58:16.0000] <justJanne>
mhm

[12:01:42.0000] <justJanne>
nox: actually, I found another good example. If there is something like a #whatwg-offtopic, I’d love to continue to discuss it there.

[12:06:05.0000] <justJanne>
(the example would be changing languages by committee, as is happening all the time)


2017-10-21
[18:49:28.0000] <MikeSmith>
in JavaScript, given a Content-Type header, is there some convenient way I’m not aware of for getting just the charset from that?

[18:50:01.0000] <MikeSmith>
I mean other than doing it manually through string manipulation

[21:49:57.0000] <annevk>
MikeSmith: no, but I want to add an API for that; not gonna help you now, except that in the issue there are some libraries linked

[22:17:20.0000] <MikeSmith>
annevk: k

[22:18:59.0000] <MikeSmith>
context was about using TextDecoder with the fetch API btw

[22:19:20.0000] <MikeSmith>
nice too see that’s in all current engines except Edge

[22:19:31.0000] <MikeSmith>
and I guess Edge is working on it

[23:15:07.0000] <annevk>
MikeSmith: see issue against mimesniff with API in the title

[23:31:05.0000] <MikeSmith>
annevk: ah nice thanks

[00:34:42.0000] <domfarolino>
annevk: When I construct a new request object with an invalid `mode`, we default to `cors`. However when I use an invalid `referrerPolicy`, a TypeError is thrown. They are both enums, yet when they don't match a valid value, one throws the other doesn't. Is this because of `fallbackMode` in the constructor?

[01:01:56.0000] <annevk>
domfarolino: an invalid mode would throw too

[01:02:07.0000] <annevk>
domfarolino: e.g., "whatever" would throw

[06:09:12.0000] <fxhp>
Hello, is there any tutorials on creating a custom html5lib Filter? I need one that prevents <script> tags from running, with the exception of a certain MathJax script.

[06:09:56.0000] <fxhp>
I know I can "bust" script tags by changing < to the hexcode

[06:45:36.0000] <domfarolino>
annevk: Hm I could be missing something but I cannot get it to throw in chrome `x = new Request("https://domfarolino.com", {mode: "whatever"})`

[06:45:48.0000] <domfarolino>
But it does throw in FF

[06:45:51.0000] <domfarolino>
I guess that's a bug

[07:23:39.0000] <annevk>
domfarolino: yeah, file and add a test if there is none?

[07:41:18.0000] <domfarolino>
annevk: Filed. Will look for tests

[07:48:01.0000] <annevk>
domfarolino++

[08:39:26.0000] <domfarolino>
annevk: should this be its own file w/ -historical suffix?

[08:42:02.0000] <domfarolino>
or maybe not historical hmm

[10:48:16.0000] <annevk>
domfarolino: yeah, it's not historical, it's just testing mode

[10:48:40.0000] <annevk>
domfarolino: http://web-platform.test:8000/fetch/api/basic/ is probably the place

[10:53:38.0000] <annevk>
Seeing all the JavaScript module arguments on Twitter it is somewhat strange that we went from "1JS" to two different parse entry points that effectively require an out-of-band identifier.


2017-10-22
[18:17:15.0000] <domfarolino>
tobie: just letting you know I will be getting to the wpt issue of adding namespace support to idlharness, just school is a bit busy right now etc

[18:17:56.0000] <domfarolino>
annevk: I've confirmed that this is an issue with the `mode`, `credentials`, `cache`, and `redirect` properties in Chrome. Issue hath been filed but I'll add all of these to the test I create

[18:18:12.0000] <domfarolino>
"this" = no-throw with invalid values

[21:39:38.0000] <Domenic>
wow, good catch, dang

[22:07:56.0000] <annevk>
domfarolino++ I guess assuming IDL binding impls are solid is bogus still

[22:46:49.0000] <domfarolino>
annevk: Yeah how does that work? Is that an automatic thing that is supposed to happen or....

[23:16:58.0000] <annevk>
domfarolino: in theory

[23:17:46.0000] <annevk>
domfarolino: maybe Chrome has issues around enums

[23:18:41.0000] <annevk>
domfarolino: in theory impls generate the C++/Rust that follows from IDL requirements

[23:23:03.0000] <domfarolino>
annevk: and each vendor creates their own impl of webidl then?

[23:24:01.0000] <annevk>
domfarolino: yeah, most have custom IDL too for optimizations

[23:35:30.0000] <domfarolino>
annevk: ah yes I’ve seen that. Is there a typical language implementors choose to write their implementation of webidl in? Or what that is common across many vendors

[01:37:08.0000] <annevk>
domfarolino: dunno, Firefox has something in Python I believe

[01:40:14.0000] <MikeSmith>
I htink Blink does too

[03:58:37.0000] <xfq>
yeah it's also in Python

[03:59:14.0000] <nox>
There is also Edge's stuff that supports more than WebIDL specifies.

[04:20:39.0000] <sangwhan>
Last time I heard Edge's IDL thingie was in Perl. WebKit was in Perl last time I looked but that was years ago

[04:24:43.0000] <nox>
https://github.com/whatwg/html/issues/775#issuecomment-190848268 is what I had in mind.

[04:24:50.0000] <nox>
legacycaller getter (HTMLCollection or Element)? item((unsigned long or DOMString) nameOrIndex);

[04:25:05.0000] <nox>
Apparently their WebIDL stuff cope with that just fine.

[04:38:36.0000] <annevk>
domfarolino: note that nobody is required to impl IDL directly either, but it does make it easier

[06:06:03.0000] <annevk>
Presto for the longest time did it all in C/C++, maybe forever

[07:48:14.0000] <domfarolino>
annevk: Ok cool thanks for the info

[10:35:29.0000] <IZh>
Domenic: Hi! I've finally published my scripts: https://github.com/izh1979/makepdf :-) FWIW.

[10:35:49.0000] <Domenic>
IZh: awesome, I saw your email! I'm excited to check it out, probably during the week :)

[10:37:51.0000] <IZh>
Domenic: It took more time than expected, hence 1 month delay. :-)

[14:19:57.0000] <GPHemsley>
I can't believe you're all still entertaining url#118


2017-10-23
[02:25:49.0000] <smaug____>
clearly microtasks are too hard to understand :/

[05:34:43.0000] <Domenic>
This feels like an appropriate time for 👏

[05:34:50.0000] <Domenic>
WHENEVER 👏 THE 👏 STACK 👏 IS 👏 EMPTY

[05:36:19.0000] <nox>
Domenic: Could be worse, at least they aren't defined in an RFC!

[05:36:45.0000] <Domenic>
^_^

[05:36:47.0000] <nox>
GPHemsley: I don't even need to go check which issue it is to know what you mean.

[06:05:52.0000] <GPHemsley>
/me sighs

[06:10:14.0000] <GPHemsley>
in sort-of-related news, I got schooled on the WHATWG a few weeks ago: https://en.wikipedia.org/wiki/Template_talk:Glossary_link_internal#Reverted_recent_major_changes

[06:10:41.0000] <GPHemsley>
(look for "Long digression on why else to not take WHATWG seriously")

[06:47:20.0000] <annevk>
GPHemsley: o_O

[06:47:52.0000] <annevk>
GPHemsley: this person should meet up with the Google-conspiracists

[06:47:52.0000] <nox>
"and is notably missing Microsoft and Google"

[06:47:53.0000] <nox>
wat

[06:48:10.0000] <nox>
annevk: Wouldn't they annihilate each other, like matter and anti-matter?

[06:53:25.0000] <annevk>
nox: https://www.youtube.com/watch?v=zGxwbhkDjZM

[06:54:26.0000] <nox>
Hah.

[07:11:01.0000] <GPHemsley>
yeah, I just threw my hands up at that point

[07:50:17.0000] <freesamael>
annevk: Domenic: I wrote a document about Firefox's session history implementation with a few examples, and some questions that I'm willing to find out from other browsers. Does it look enough to initiate a discussion?

[07:50:17.0000] <freesamael>
https://docs.google.com/document/d/1PDMf2NEaxf94ap26SREcM3DaZjk6dvq0jfsg983SPx0/edit?usp=sharing

[09:00:08.0000] <nox>
freesamael: ajeffrey_ did session history stuff and such comparisons too IIRC, when cleaning that stuff in Servo.

[09:03:23.0000] <ajeffrey_>
nox freesamael: indeed I did, cbrewster and I wrote https://arxiv.org/abs/1608.05444 largely to keep our head straight while trying to implement session history.

[09:09:29.0000] <freesamael>
nox: ajeffrey_: Yes I'm aware of that :) What I'm trying to find out is what to do with history of nested browsing contexts when the top-level browsing context has navigated away to a different document and the browser doesn't want to keep non-active documents (and child browsing contexts of that) in memory. I'm trying to push

[09:09:29.0000] <freesamael>
https://github.com/whatwg/html/issues/1454

[09:12:21.0000] <nox>
Inb4 a second paper gets written.

[09:20:13.0000] <ajeffrey_>
freesamael: adding comments to the google doc, mostly about how Servo does things since that

[09:20:23.0000] <ajeffrey_>
's what I know :)

[09:21:27.0000] <ajeffrey_>
freesamael: it looks like our pretty pictures were helpful btw, I like yours!

[09:22:42.0000] <freesamael>
ajeffrey_: Thx for the comments! Yes I stole the representation from your paper :P

[09:23:17.0000] <annevk>
nox: ajeffrey_: freesamael, smaug____, and I had a discussion here earlier and we reached a tentative conclusion that the spec and Servo might be too far from contemporary implementations to align with 😟

[09:23:42.0000] <annevk>
I see now that's ambiguous; read that as "nox, ajeffrey_"

[09:24:19.0000] <ajeffrey_>
annevk: Servo is essentially the current spec :)

[09:24:23.0000] <annevk>
freesamael: please ping me again if I haven't gotten to it by Wednesday or so

[09:24:48.0000] <ajeffrey_>
freesamael: imitation === flattery :)

[09:25:03.0000] <freesamael>
annevk: Take your time. I may post it on the github issue later

[09:37:08.0000] <annevk>
littledan: is there a plan for <script type=wasm> still? Some issue I can track?

[09:59:00.0000] <littledan>
annevk: I think it's a little far out, but I guess this is the bug: https://github.com/WebAssembly/design/issues/1087

[09:59:45.0000] <annevk>
littledan: ta, subscribed

[10:31:31.0000] <Domenic>
It's on my plate

[10:31:40.0000] <Domenic>
It'll be <script type=module> probably with MIME type distinguishing

[10:32:09.0000] <Domenic>
https://docs.google.com/presentation/d/11tHsNh2U9oEJD4lvV7XX2M22JnyeyyCHj1ncmspXjBU/edit?usp=sharing

[10:32:27.0000] <smaug____>
ajeffrey_: the current spec isn't the web

[10:32:47.0000] <smaug____>
and the spec doesn't deal with difficult cases

[10:33:19.0000] <smaug____>
FWIW, looks like chromium is fixing their issues, and sounds like they will behave even closer to gecko and edge

[10:46:24.0000] <ajeffrey_>
smaug____: indeed, there is a discrepancy between the spec and implementations.

[10:47:02.0000] <smaug____>
and session history happens to be probably the most regression prone code we have, at least in Gecko

[10:47:24.0000] <smaug____>
basically any change to any behavior will cause some regression bug(s)

[10:47:49.0000] <smaug____>
of course on of the reasons for that is that there is no spec to follow

[10:47:55.0000] <smaug____>
s/on/one/


2017-10-24
[20:47:10.0000] <annevk>
Domenic: looks nice, though that means we might want a different Accept header for these requests; perhaps we should have modulescript as a destination…

[00:18:31.0000] <KiChjang>
does anyone know what the URL is for an online version of WPT?

[00:18:59.0000] <KiChjang>
where you can visit with your local browser and test whether it passes those tests/

[00:26:49.0000] <xfq>
KiChjang: do you mean http://w3c-test.org/

[00:27:04.0000] <KiChjang>
maybe, not quite i think

[00:27:15.0000] <KiChjang>
i recall it's linked from some w3c spec

[00:29:08.0000] <xfq>
there's also a dashboard

[00:29:09.0000] <xfq>
http://wpt.fyi/

[00:37:28.0000] <annevk>
KiChjang: w3c-test.org is the hosted instance of web-platform-tests

[00:38:00.0000] <xfq>
I think CSSWG also has a tool where you can "visit with your local browser and test whether it passes those tests"

[00:38:21.0000] <xfq>
for example, you can try clicking "start" in http://test.csswg.org/harness/suite/css-grid-1_dev

[00:38:57.0000] <annevk>
ah, maybe KiChjang meant that

[00:39:16.0000] <KiChjang>
yeah, i think it was something like that

[02:11:23.0000] <annevk>
I found a resource on the UTF-8 vs UTF-16 question: https://annevankesteren.nl/2009/09/utf-8-reasons

[02:11:51.0000] <annevk>
Which points to https://lists.w3.org/Archives/Public/www-style/2009Feb/0087.html among other reasons

[02:16:29.0000] <MikeSmith>
annevk: :)

[02:16:33.0000] <MikeSmith>
nice find

[04:19:17.0000] <nox>
annevk: Are you joking, or did you actually stumbled upon your very own blog while looking for something?

[04:21:16.0000] <annevk>
nox: the latter

[04:21:32.0000] <nox>
annevk: Nice. :D

[04:21:41.0000] <nox>
annevk: "I don't know who wrote that but he is very smart".

[05:16:01.0000] <annevk>
heh

[07:24:19.0000] <annevk>
mkwst: where does discussion take place about that localhost thing? Mildly curious about the DNSSEC arguments

[07:24:36.0000] <annevk>
mkwst: also, why don't IETF drafts point to the discussion place?

[11:26:28.0000] <miketaylr>
annevk: should i file a bug on this? https://cloudup.com/c283DRNBdAV

[11:26:46.0000] <miketaylr>
(or is it a known issue)

[11:27:14.0000] <miketaylr>
make remote seems p happy

[11:28:35.0000] <KiChjang>
can someone shed some light on how the origin of a request is set?

[11:28:49.0000] <KiChjang>
from the fetch spec, i can see that it really only gets set in 2 places

[11:30:43.0000] <KiChjang>
one whe performing a fetch at step 1.2, and another at http-redirect fetch step 10

[11:33:18.0000] <KiChjang>
so in other words, the origin of a request is always going to be client's origin, until you get to http-redirect fetch step 10

[11:50:16.0000] <annevk>
miketaylr: maybe update bikeshed first? But if latest, yes

[11:50:28.0000] <miketaylr>
oh, that might be it.

[11:50:40.0000] <miketaylr>
i had to get on my old machine to work around this python crash in 10.13


2017-10-25
[23:39:23.0000] <mkwst>
annevk: The two prongs of https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-00#section-4.2 are the fundamental disagreement.

[23:39:31.0000] <mkwst>
annevk: The latest round of the discussion starts at https://www.ietf.org/mail-archive/web/dnsop/current/msg20963.html.

[23:40:37.0000] <mkwst>
annevk: The discussion group question is probably answered in https://tools.ietf.org/html/rfc7322. :)

[00:37:46.0000] <mkwst>
annevk, tobie: Ping! I haven't actually run https://github.com/mikewest/tc39-proposal-literals/blob/master/README.md by V8/TC39 folks yet to see if their heads explode, but WDYT about it from a WebIDL perspective?

[01:06:43.0000] <tobie>
mkwst: would that create a new WebIDL string type?

[01:07:23.0000] <mkwst>
tobie: I think that'show we'd need to do it. I'm very open to other options, though, if you have different ideas!

[01:09:36.0000] <tobie>
mkwst: so we'd be able to tighten security requirements for DOMString for new APIs. But not do much for old ones unless folks opted in via CSP or what not, right?

[01:11:05.0000] <tobie>
mkwst: do `strings` fall in the literal category too (I imagine not)?

[01:16:57.0000] <tobie>
mkwst: might also be worth talking to the React folks who've been working around this space with https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml

[01:19:54.0000] <tobie>
mkwst: that said, it seems this is quite restrictive in its application, no? It's basically strings that are part of the UI layer on apps that aren't designed to be translated, right?

[01:33:42.0000] <annevk>
mkwst: would "x" + "x" also throw?

[01:34:18.0000] <annevk>
mkwst: if TC39 would add such a language feature I see no reason for us not to accommodate

[01:47:06.0000] <mkwst>
(Sorry, ran off to get a flu shot)

[01:48:09.0000] <mkwst>
tobie: It is restrictive. That's more or less the idea. *shrug* Google's security team tells me that the majority of `SafeHtml` instantiations in Google's production code is string literals.

[01:48:58.0000] <mkwst>
It surprises me, but I don't have much reason to doubt them. :)

[01:49:39.0000] <mkwst>
annevk: Closure's compiler deals with `"x" + "x"`. If we can do the same, great. If that turns out to be hard, I'm sure we could live without it.

[01:51:00.0000] <tobie>
mkwst: just to be clear, this implies these strings are statically analysed to be safe?

[01:51:52.0000] <tobie>
mkwst: (I think I'm not super clear as to what threat we're trying to mitigate against.)

[01:51:56.0000] <mkwst>
tobie: In some cases, yes (e.g. HTML strings are statically determined to be valid HTML without dangling markup).

[01:52:07.0000] <mkwst>
In other cases, reviewers will look at them with their eyeballs.

[01:52:43.0000] <mkwst>
Either way, analyzing a static string is simpler than analyzing an HTML sanitizer, and we can make reasonable decisions about the risk a given string literal presents.

[02:07:02.0000] <annevk>
mkwst: I guess I'm more curious about the TC39 proposal than the IDL one

[02:07:16.0000] <annevk>
mkwst: since that seems potentially far more controversial

[05:20:41.0000] <domfarolino>
annevk: Request domintro nit addressed

[05:23:49.0000] <Domenic>
mkwst: my prediction is that you'll get pushback of the form "this should be solved by a static analysis tool like TypeScript"

[05:24:28.0000] <mkwst>
annevk: Ah, sorry I missed this earlier. Yes. I imagine the TC39 side will be harder. I'm hoping to convince the V8 team to fall on that particular sword for me. :)

[05:24:43.0000] <annevk>
domfarolino: landed

[05:24:58.0000] <mkwst>
Domenic: That pushback is reasonable, it's what Google does today.

[05:24:59.0000] <annevk>
(and thanks!)

[05:25:29.0000] <mkwst>
But it would be significantly more effective if we built it into the platform. *shrug* I'm happy to have that discussion.

[05:25:39.0000] <annevk>
I wonder how many people realized wasm came with non-detachable ArrayBuffer objects

[05:25:44.0000] <annevk>
That seems like a fairly major change

[05:26:58.0000] <Domenic>
mkwst: was there a plan to use a template string tag for trusted types? I thought I saw that, and it seemed so nice.

[05:27:24.0000] <mkwst>
Domenic: Yeah. That's on the list somewhere. I think koto built a prototype, even.

[05:27:29.0000] <mkwst>
It does look really nice.

[05:27:50.0000] <Domenic>
Cool, looking forward to seeing more of that

[15:48:32.0000] <KiChjang_>
how many ways can you supply credentials when performing a fetch?

[15:49:11.0000] <KiChjang_>
i know that using the URL works, username:password⊙ec

[15:49:18.0000] <KiChjang_>
there's also the Authentication header

[16:44:02.0000] <MikeSmith>
KiChjang_: TLS client certificates

[16:44:31.0000] <MikeSmith>
and username:password⊙ec won’t work with the fetch API

[16:44:41.0000] <KiChjang>
huh


2017-10-26
[07:01:58.0000] <JakeA>
wanderview: can you remember why we have the concept of reserved clients, rather than just having clients.get(resultingClientId) resolve once the client is real?

[07:02:55.0000] <wanderview>
JakeA: if the FetchEvent handler wants to postMessage() it... maybe that would deadlock?

[07:03:11.0000] <wanderview>
but I've paged a lot of the reserved client stuff out at the moment

[07:04:45.0000] <wanderview>
JakeA: also... wouldn't that still require the concept of a reserved client?  I mean, some state must be stored to make the  browser delay resolving the get() instead of returning null instead

[07:11:06.0000] <JakeA>
wanderview: yeah, we'd need some concept internally, but I'm doubting whether we should expose them

[07:11:27.0000] <JakeA>
wanderview: I'll write up an issue

[07:11:43.0000] <wanderview>
I guess we at least have one thing to talk about at TPAC

[07:11:52.0000] <JakeA>
:D

[07:12:09.0000] <JakeA>
btw I'm going to do my usual sweep through the issues next week

[07:21:22.0000] <wanderview>
JakeA: maybe n8s has a use case for get(reservedId)

[07:21:56.0000] <JakeA>
wanderview: will ping him in the issue

[07:55:10.0000] <JakeA>
wanderview: https://github.com/w3c/ServiceWorker/issues/1216

[12:41:58.0000] <wanderview>
JakeA: this makes me very happy (if I am reading chrome behavior correctly): https://github.com/whatwg/fetch/pull/146#issuecomment-339778444

[12:50:03.0000] <wanderview>
its nice to be able to easily test edge service workers now


2017-10-27
[18:07:19.0000] <MikeSmith>
mounir: is there any document that actually defines gesture=media ?

[18:08:32.0000] <MikeSmith>
since https://github.com/WICG/gesture-delegation/blob/master/explainer.md doesn’t, I’m wondering where it actually came from

[18:10:29.0000] <MikeSmith>
because I see getsure=media mentioned at https://developers.google.com/web/updates/2017/09/autoplay-policy-changes#iframe and https://www.chromium.org/audio-video/autoplay

[18:14:04.0000] <MikeSmith>
ah I see https://github.com/WICG/gesture-delegation/issues/1#issuecomment-330721082

[18:14:23.0000] <MikeSmith>
> The wiki page is using a placeholder name. We will update it when the final name has launched.

[01:08:46.0000] <mounir>
MikeSmith: the intent to ship will be sent any time soon

[01:41:21.0000] <MikeSmith>
mounir: you don'

[01:42:55.0000] <MikeSmith>
mounir: you don’t need to provide an actual spec when doing an intent to ship?

[02:23:30.0000] <mounir>
MikeSmith: we have the explainer which defines things well enough IMO

[02:24:19.0000] <mounir>
MikeSmith: given the triviality of the feature, a proper spec would be very procedural

[02:30:35.0000] <MikeSmith>
mounir: not sure others would say that explainer defines things well enough

[02:31:21.0000] <MikeSmith>
especially given it says absolutely nothing about an HTML attribute with the name “gesture”

[02:49:49.0000] <mounir>
MikeSmith: because 'gesture' isn't the name of the attribute

[02:59:12.0000] <MikeSmith>
mounir: it’s not the name of the HTML content attribute?

[02:59:52.0000] <MikeSmith>
and if not, then what is the name and how is anybody else supposed to know what it might be?

[03:00:39.0000] <mounir>
MikeSmith: https://github.com/WICG/gesture-delegation/blob/master/explainer.md

[03:00:52.0000] <MikeSmith>
and why do you have somebody posting at https://developers.google.com/web/updates/2017/09/autoplay-policy-changes#iframe with a <iframe src="myvideo.html" gesture="media"> code example

[03:01:05.0000] <MikeSmith>
yeah I have read that, multiple times

[03:01:27.0000] <mounir>
MikeSmith: because that was last month and Domenic and annevk wanted another attribute name

[03:01:38.0000] <mounir>
MikeSmith: I wasn't going to say no because of our devrel article :)

[03:01:42.0000] <mounir>
we will update it

[03:02:01.0000] <mounir>
will update the explainer to make things clear

[03:02:15.0000] <MikeSmith>
OK

[03:02:21.0000] <MikeSmith>
thanks for clarifying ehre

[03:03:16.0000] <annevk>
hard to resist a good bikeshed

[03:03:43.0000] <mounir>
MikeSmith: what bringed you to look at this if I may ask?

[04:05:53.0000] <MikeSmith>
mounir: https://stackoverflow.com/questions/46934039/what-is-the-gesture-media-html-attribute

[04:06:41.0000] <MikeSmith>
please consider posting an answer or comment there yourself

[04:06:53.0000] <MikeSmith>
or else lemme know and I can update the one I posted

[04:55:45.0000] <mounir>
MikeSmith: I think it would be better if you could modify your answer instead of someone from my team pilling up with corrections

[05:13:01.0000] <MikeSmith>
mounir: I’m happy to modify it. What specifically would you suggest I add or change?

[05:29:33.0000] <mounir>
MikeSmith: mention the attribute name that is in the spec

[05:29:54.0000] <mounir>
MikeSmith: and say that 'gesture' was meant as a placeholder

[05:32:22.0000] <MikeSmith>
mounir: there is no spec..

[05:32:33.0000] <MikeSmith>
you mean the Explainer document?

[05:32:46.0000] <MikeSmith>
if so, there is no HTML content attribute name in that document

[05:33:20.0000] <MikeSmith>
there is nothing in that entire document about any declarative markup mechanism

[05:33:40.0000] <MikeSmith>
that document only describes a scripting interface

[05:39:19.0000] <mounir>
MikeSmith: I've updated the explainer this morning to mention the content attribute

[05:39:34.0000] <MikeSmith>
ah OK

[05:39:34.0000] <mounir>
it was kind of implicit as they are usually named the same

[05:40:11.0000] <MikeSmith>
um

[07:23:10.0000] <Domenic>
Yeah.... not at all implicit.

[08:04:05.0000] <MikeSmith>
still not sure if planning to do an Intent to Ship with a new HTML content attribute named “delegatestickyuseractivation” is some kind of deliberate troll or what

[10:23:17.0000] <annevk>
MikeSmith: it’s not; just hard to find a good name that’s also short for niche things

[10:23:45.0000] <MikeSmith>
Yeah well

[10:24:22.0000] <MikeSmith>
that that is pretty obviously a non-starter in reality

[10:24:49.0000] <MikeSmith>
or else the overall feature is

[13:33:29.0000] <Domenic>
I think I speak for all of us when I say this is the future of the web https://twitter.com/domenic/status/924010078444965888


2017-10-28
[23:17:31.0000] <MikeSmith>
> MikeSmith: given the triviality of the feature, a proper spec would be very procedural

[23:17:48.0000] <MikeSmith>
I somehow didn’t notice that statement til now

[23:19:30.0000] <MikeSmith>
kind of once again leaves me at a loss for words

[23:23:07.0000] <MikeSmith>
gonna be fun to read the Interoperability and Compatibility section of that imminent Intent to Ship

[07:51:39.0000] <annevk>
MikeSmith: why so mean-spirited?

[08:18:55.0000] <MikeSmith>
annevk: yeah I was out of line

[08:19:12.0000] <MikeSmith>
not been in the best of spirits

[08:20:08.0000] <MikeSmith>
mounir: sorry for my comments

[08:20:43.0000] <MikeSmith>
not meant to denigrate the work

[08:38:36.0000] <mounir>
MikeSmith: np

[11:31:10.0000] <othermaciej>
mounir, MikeSmith: what's the "6.3 Activation" that explainer refers to?

[11:35:32.0000] <othermaciej>
I guess that it's referencing the HTML spec (probably correctly)

[13:24:29.0000] <annevk>
MikeSmith: 👍❤️

[15:21:59.0000] <MikeSmith>
othermaciej: yeah https://html.spec.whatwg.org/multipage/interaction.html#activation though it’s not clear to me how what’s described in https://github.com/WICG/gesture-delegation/blob/master/explainer.md#new-html-concept would actually fit into that section

[15:23:06.0000] <othermaciej>
MikeSmith: it would require defining a new notion of "sticky activation"

[15:23:34.0000] <MikeSmith>
ok

[15:23:38.0000] <othermaciej>
I am not sure any of this quite makes sense though, because other browsers do not have an autoplay policy that works like Chrome's

[15:23:54.0000] <othermaciej>
Safari does not grant sticky autoplay permission until you navigate outside the current eTLD+1

[15:24:00.0000] <othermaciej>
nor do we intend to

[15:24:35.0000] <othermaciej>
this whole "explainer" is designed around Chrome's very specific autoplay behavior which is not anyone else's

[15:25:37.0000] <MikeSmith>
oh

[15:26:09.0000] <MikeSmith>
might be worth (re)stating that as an issue at https://github.com/WICG/gesture-delegation/issues

[15:28:58.0000] <othermaciej>
I am not sure how seriously to take a WICG explainer document. Easier to comment when there's actual spec language proposed for a real spec.

[15:29:46.0000] <othermaciej>
I should check if I am a member of WICG. Can't remember any more.

[15:32:18.0000] <othermaciej>
wow there is a lot of stuff up in WICG github

[15:49:37.0000] <MikeSmith>
othermaciej: yeah, and at least a couple things that have moved on to working groups, like IntersectionObserver

[15:50:06.0000] <MikeSmith>
oh, and the PaymentRequest API started out in the WICG repo

[16:10:09.0000] <Domenic>
othermaciej: well there is a Chrome intent to ship based on this explainer so, I guess semi-seriously.

[16:12:27.0000] <othermaciej>
I don't think what is described in the explainer would work for Safari, the one other browser that I know of having autoplay restrictions. Also the attribute name is horrific. But we do need a similar feature for our similar (but not identical) autoplay policy.

[16:12:40.0000] <othermaciej>
Is an issue against the Explainer the best way to communicate this?

[16:14:27.0000] <othermaciej>
I'm not even sure our user-action-to-play policy is sticky per page, I will have to ask (we changed it a few times)

[16:19:51.0000] <MikeSmith>
othermaciej: either an issue against the Explainer or a comment at https://discourse.wicg.io/t/proposal-for-a-gesture-delegation-api/2340 I guess

[16:23:15.0000] <MikeSmith>
or reply to the Intent to Ship at https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/F4h7sdBdiBM

[16:24:29.0000] <othermaciej>
Chromium intent to ship is definitely not my circus or my monkeys

[16:24:58.0000] <othermaciej>
I asked the folks who worked on this to remind me of Safari's exact behavior, so I'll try to file an issue

[16:30:14.0000] <othermaciej>
In the meantime I filed name bikeshed issues


2017-10-29
[02:02:33.0000] <GPHemsley>
Domenic: Does jsdom/url not fail tests with file:// bases and windows drive letters since the spec change? I'm trying to track down where/whether I'm going wrong...

[03:42:11.0000] <GPHemsley>
Domenic: Nevermind, I am indeed an idiot.

[10:05:17.0000] <benjamingr_>
Hey, I can't figure out why `e.total` gets set on a ProgressEvent HEAD request - I'm looking at https://xhr.spec.whatwg.org/#interface-progressevent

[10:37:41.0000] <annevk>
benjamingr_: https://github.com/whatwg/fetch/issues/284

[10:37:48.0000] <annevk>
benjamingr_: tl;dr; bug

[10:39:38.0000] <benjamingr_>
Thanks

[10:42:23.0000] <benjamingr_>
FWIW, I think it's useful and I like the Chrome behavior better :D

[10:43:38.0000] <benjamingr_>
It enables you to see the content-length of things that are behind CORS and doesn't expose the header directly - I can use it in order to use HEAD to get the content length of CORS content and make decisions about how/if I want to download it - for example I can HEAD a resource and only download it if it's smaller than X bytes in a way that benefits the user.

[10:44:58.0000] <annevk>
benjamingr_: that's an argument for safelisting Content-Length, if indeed all user agents already leak it that way

[10:45:09.0000] <annevk>
benjamingr_: could you file an issue since it seems like something that should be fixed either way

[10:45:21.0000] <annevk>
benjamingr_: or at least something folks should be aware of

[10:45:41.0000] <benjamingr_>
Sure, do I file it against `fetch`?

[10:46:06.0000] <annevk>
benjamingr_: yeah

[10:46:13.0000] <benjamingr_>
Thanks, as always you've been a great help :)

[10:52:42.0000] <benjamingr_>
https://github.com/whatwg/fetch/issues/622 Thanks again annevk

[11:10:29.0000] <annevk>
👍


2017-10-30
[06:21:03.0000] <wanderview>
did es modules end up requiring CORS?

[06:22:14.0000] <wanderview>
I guess so... although I remember some push back on it

[07:22:39.0000] <smaug____>
annevk: hrm, so event.composedPath

[07:23:14.0000] <smaug____>
that returns different values if dom is modified between two calls to it

[07:23:19.0000] <smaug____>
if I read the spec right

[07:28:54.0000] <smaug____>
https://github.com/whatwg/dom/issues/525

[07:30:45.0000] <nox>
smaug____: Edited the issue to add some formatting (in case you wonder why it says "edited by nox").

[07:31:10.0000] <smaug____>
k

[08:24:26.0000] <annevk>
smaug____: hmm yeah, operating on the internal list would be way cleaner

[09:47:15.0000] <gsnedders>
Yay, Google Docs is broken here. Won't let me change to anything but the first logged in account.

[09:48:04.0000] <jyasskin>
gsnedders: Try switching to the account you want within gmail first. Docs not being able to re-authenticate is a long-standing bug.

[09:49:41.0000] <gsnedders>
well that's a totally obvious workaround

[09:50:51.0000] <gsnedders>
jyasskin: it'd be nice if https://support.google.com/docs/answer/6239515?co=GENIE.Platform%3DDesktop&hl=en documented that

[09:56:17.0000] <jyasskin>
gsnedders: I've left feedback by clicking 'no' on that page. The instructions currently there should actually work, but they're overkill.


2017-10-31
[18:19:21.0000] <Krinkle>
JakeA: Found an odd not-so-funny IE script loading bug. https://phabricator.wikimedia.org/T178943

[18:19:48.0000] <Krinkle>
TL;DR: onreadystate fires before script has actually executed, in IE 10, if and only if a certain strange <link rel=stylesheet> is on the page.

[18:19:54.0000] <Krinkle>
(after the <script async src>)

[18:20:22.0000] <Krinkle>
I was hoping your depressing article https://www.html5rocks.com/en/tutorials/speed/script-loading/ would cover this, but unfortunately not (as far as I can see)

[18:20:27.0000] <Krinkle>
Only IE10+ is required.

[18:20:51.0000] <Krinkle>
I think I'll get rid of the onreadystate as starting point, to make sure it really is that one that is the issue and not script.onload

[22:32:44.0000] <annevk>
Edge will have URL’s toJSON soonish

[00:53:07.0000] <smaug____>
hayato: commented on the composedPath issue. Do you still see there to be some performance issue?

[00:53:10.0000] <smaug____>
since I don't

[01:01:58.0000] <smaug____>
annevk: does my suggestion there for composedPath sound somewhat reasonable?

[01:03:15.0000] <hayato>
smaug____:  I commented in the issue.

[01:03:21.0000] <smaug____>
thanks

[01:33:03.0000] <annevk>
smaug____: I suspect I don't have time to look into it soonish unless it's high priority

[01:33:20.0000] <smaug____>
annevk: well, I need to implement something

[01:33:49.0000] <annevk>
smaug____: ah okay, I'll have a look

[01:33:58.0000] <smaug____>
great thanks

[01:35:25.0000] <rniwa>
smaug____, annevk: i guess the change is to just pre-compute the composed path upfront?

[01:35:34.0000] <smaug____>
annevk: btw, it is hard to know what all you spec authors are busy with.  Like you and Domenic are dealing with so many different spec issues

[01:35:43.0000] <rniwa>
smaug____, annevk: that seems fine with your proposed optimization.

[01:36:26.0000] <annevk>
smaug____: I'm mostly busy with a baby at the moment 😊

[01:36:27.0000] <smaug____>
rniwa: I wouldn't call it precomputation. Just annotate the tuples so that the composed path can be calculated later

[01:36:54.0000] <smaug____>
annevk: oh sure. I thought you'd be mostly offline, but since you aren't ... ;)

[01:38:19.0000] <rniwa>
smaug____: so the challenge here is that we'd still have to compute which tree is visible to which tree

[01:38:27.0000] <rniwa>
smaug____: that could be expensive

[01:39:17.0000] <annevk>
rniwa: yeah, I'm not entirely sure how smaug____'s model works

[01:39:49.0000] <rniwa>
annevk: you'd remember which tree is visible to which tree upfront

[01:39:56.0000] <annevk>
If we stored a reference to the root of the item in event's path for instance I don't think we'd have enough information

[01:39:57.0000] <rniwa>
annevk: and then store that information along with event path

[01:40:24.0000] <rniwa>
annevk: right, because a shadow host can be moved from one tree to another

[01:40:48.0000] <rniwa>
annevk: so you'd have to remember the entire tree relationship :(

[01:41:01.0000] <rniwa>
now that i think about it, we probably don't want to make this change.

[01:41:10.0000] <rniwa>
it'd make event dispatching a lot more expensive...

[01:41:27.0000] <annevk>
Yeah, it seems you'd basically have to do that ancestor check during dispatch instead

[01:41:35.0000] <smaug____>
I'm strongly against the current model

[01:41:54.0000] <rniwa>
smaug____: okay but we've already shipped with the spec behavior

[01:41:54.0000] <smaug____>
since one can't rely on composedPath to return the path

[01:42:04.0000] <rniwa>
smaug____: of re-computing which node is visible to which node

[01:42:10.0000] <rniwa>
smaug____: we don't have the blink bug, for example

[01:43:04.0000] <annevk>
I wonder how expensive it would be though to calculate during dispatch

[01:43:08.0000] <annevk>
Since we have to do some traversal

[01:43:50.0000] <rniwa>
annevk: to do this, we'd have to remember the current/old "parent" tree for each shadow root.

[01:44:38.0000] <rniwa>
annevk: i've specifically designed webkit's event dispatching code not having to do those kinds of expensive computations or storing of information

[01:44:46.0000] <rniwa>
so I'd be very much against changing the status quo

[01:48:06.0000] <rniwa>
it's really annoying that event dispatching code keeps getting more complex & expensive

[01:48:36.0000] <rniwa>
at some point, we ought to start care about perf of these things...

[01:48:43.0000] <smaug____>
event path already remembers the old parent

[01:48:59.0000] <smaug____>
event path knows the dispatch time DOM structure

[01:49:23.0000] <rniwa>
smaug____: old parent node, sure, not old parent node's shadow tree's parent tree

[01:49:25.0000] <smaug____>
I do care about performance a lot

[01:50:15.0000] <smaug____>
it knows the path through shadow trees

[01:50:21.0000] <smaug____>
what am I missing here

[01:50:36.0000] <rniwa>
smaug____: so the problem is that let's say a path contains n1 > n2

[01:50:50.0000] <rniwa>
where n1 and n2 are nodes

[01:50:59.0000] <rniwa>
if they belong to two different trees, say, t1, and t2

[01:51:13.0000] <rniwa>
the relationship between t1 and t2 may have changed.

[01:51:24.0000] <smaug____>
sure, and we don't care about that change

[01:51:32.0000] <rniwa>
t1 and t2 could belong to two completely disjoint shadow trees

[01:51:46.0000] <smaug____>
right. I don't want to keep that in mind at all

[01:51:49.0000] <annevk>
smaug____: if we don't isn't there a possibility that we end up revealing something that should be hidden?

[01:51:59.0000] <rniwa>
smaug____: well, you should. otherwise, how do we decide whether n1 is visible to n2 or not?

[01:52:12.0000] <annevk>
smaug____: if I move a node into a closed tree during dispatch for instance

[01:52:30.0000] <smaug____>
Oh, you're worried about moving something from an open shadow dom to a closed one?

[01:52:38.0000] <rniwa>
smaug____: yeah, that can totally happen

[01:52:41.0000] <smaug____>
I'm not worried about that all

[01:52:54.0000] <smaug____>
that is a case which is totally fine. The node was already in path

[01:53:02.0000] <smaug____>
which exposed it to the outside world

[01:53:03.0000] <rniwa>
smaug____: you can move n1 into n2 or vice versa as well

[01:53:13.0000] <smaug____>
so hiding it then suddenly doesn't really matter

[01:53:50.0000] <rniwa>
smaug____: well, it totally matters depending on when the change was made

[01:54:07.0000] <rniwa>
smaug____: the very DOM mutation that just happened may have been done to hide those nodes

[01:54:22.0000] <smaug____>
composedPath should be able to answer to the question which all event targets will handle the event

[01:54:45.0000] <rniwa>
smaug____: except it shouldn't disclose nodes in the closed shadow trees

[01:55:09.0000] <smaug____>
right. But that modification happens after event path is created

[01:55:09.0000] <rniwa>
smaug____: i'd be opposed to any API change that results in a node inside a closed shadow tree to be exposed to the outside world

[01:55:17.0000] <rniwa>
smaug____: that would break the very important encapsulation invariant

[01:55:54.0000] <smaug____>
if one can move non-closed node to be inside closed shadow root, there is already some leak happening

[01:56:40.0000] <smaug____>
it is similar to having random node in non-shadow dom, keeping js ref to it, and then just move it to closed shadow dom

[01:56:54.0000] <smaug____>
you definitely give access to the internals of the closed shadow dom there

[01:57:05.0000] <smaug____>
so I'm missing to see the issue here

[01:57:08.0000] <rniwa>
smaug____: sure, it's not really a security threat model we're talking about here

[01:57:35.0000] <rniwa>
smaug____: the whole point of event retargeting and composedPath() is there to hide nodes in the shadow tree at the time of the event dispatching

[01:58:15.0000] <smaug____>
exactly. at the time of event dispatching

[01:58:19.0000] <smaug____>
not later

[01:58:33.0000] <rniwa>
smaug____: when I say dispatch I mean when we call event listener on each node

[01:59:28.0000] <rniwa>
smaug____: as in https://dom.spec.whatwg.org/#concept-event-listener-invoke

[01:59:41.0000] <smaug____>
and when I say event dispatching, I mean the time when event is actually dispatched.

[02:00:17.0000] <smaug____>
and if one moves open nodes to be suddenly inside closed trees, they are already having issues with encapsulation

[02:00:19.0000] <annevk>
smaug____: I don't understand why a leak is acceptable in this small edge case

[02:00:31.0000] <smaug____>
small?

[02:00:42.0000] <smaug____>
having a composedPath() which lies is totally nuts

[02:01:14.0000] <annevk>
smaug____: having it violate encapsulation seems equally wrong

[02:01:39.0000] <smaug____>
I see it so that one has already exposed the node

[02:01:44.0000] <smaug____>
since it wasn't in a closed tree

[02:02:08.0000] <annevk>
Okay, I guess I can buy that

[02:02:34.0000] <annevk>
I am somewhat sympathetic to your point of view, I guess the question is figuring out a model that satisfies rniwa

[02:05:04.0000] <rniwa>
annevk, smaug____: i don't think the visibility of a node should be computed upfront.

[02:05:20.0000] <smaug____>
why?

[02:05:21.0000] <rniwa>
annevk, smaug____: it should be computed each time composedPath() is called

[02:05:33.0000] <rniwa>
smaug____: to keep the encapsulation invariant valid

[02:05:47.0000] <smaug____>
I'd prefer a fast composedPath

[02:06:03.0000] <rniwa>
smaug____: I like fast event dispatching.

[02:06:09.0000] <rniwa>
smaug____: since most people won't be using composedPath

[02:06:19.0000] <smaug____>
my model doesn't slow down event dispatching

[02:06:29.0000] <rniwa>
smaug____: i don't want to increase the cost of dispatching an event

[02:06:33.0000] <rniwa>
smaug____: it absolutely would

[02:06:39.0000] <smaug____>
no

[02:06:46.0000] <smaug____>
well, sure, some flags

[02:06:53.0000] <rniwa>
smaug____: storing the extra tree scope information & its parent tree scope

[02:06:59.0000] <rniwa>
smaug____: is quit expensive

[02:07:02.0000] <smaug____>
you don't need that all

[02:07:08.0000] <smaug____>
you play with the path only

[02:07:14.0000] <rniwa>
smaug____: we would totally need that in our implementation

[02:07:26.0000] <smaug____>
I don't see why the encapsulation need to work that way

[02:07:40.0000] <rniwa>
smaug____: Reverse computing the tree path computation from the event path would be insanely complicated

[02:07:47.0000] <annevk>
smaug____: I think the problem is that rniwa doesn't agree with you on composedPath() revealing previously non-closed nodes

[02:07:58.0000] <smaug____>
yup

[02:08:03.0000] <smaug____>
and I don't understand why

[02:08:37.0000] <smaug____>
any listener in the path may have taken references to such nodes already and revealing the nodes anyhow

[02:08:39.0000] <rniwa>
smaug____: here's a question. if you think moving a node from one tree to another is not really a serious concern

[02:08:44.0000] <rniwa>
smaug____: then why do you care about this behavior at all?

[02:08:53.0000] <rniwa>
smaug____: no. that's not at all true

[02:09:03.0000] <smaug____>
I care about API sanity

[02:09:14.0000] <rniwa>
smaug____: you can move a node from one tree to another before any other node would have received the event

[02:09:16.0000] <smaug____>
right now we have API which doesn't return the value one would expect

[02:09:16.0000] <annevk>
rniwa: what smaug____ cares about is that composedPath() reflects the true event path

[02:09:23.0000] <rniwa>
smaug____: it totally does.

[02:09:32.0000] <rniwa>
annevk: and it does that

[02:09:47.0000] <smaug____>
it does not

[02:09:55.0000] <rniwa>
smaug____, annevk: event path itself is computed upfront

[02:10:41.0000] <rniwa>
smaug____, annevk: the only thing that's dynamically computed is whether a given node is visible to the current event target or not

[02:11:13.0000] <smaug____>
which is weird

[02:11:17.0000] <rniwa>
smaug____, annevk: i don't see why that affects anything about event path

[02:11:21.0000] <rniwa>
smaug____: it's not weird at all

[02:11:27.0000] <smaug____>
and doesn't let us optimize composePath calls

[02:11:32.0000] <rniwa>
smaug____: everywhere else in the DOM API where we support shaodw tree

[02:11:48.0000] <rniwa>
smaug____: we hide nodes whenever the node is closed-shadow-hidden from another node

[02:12:00.0000] <rniwa>
smaug____: you can totally optimize composedPath.

[02:12:25.0000] <rniwa>
smaug____: the only thing you need is detect a case where a shadow tree gets moved from one tree to another and becomes visible

[02:12:40.0000] <rniwa>
smaug____: since such a DOM mutation is very rare, you can keep using the cached composed path in most cases

[02:12:42.0000] <annevk>
smaug____: do we expect frequent composedPath() calls? (It seems there's some opportunity to optimize in any case though.)

[02:13:11.0000] <rniwa>
smaug____: just like you'd do for live node lists like getElementsByTagName.

[02:13:28.0000] <smaug____>
rniwa: tracking whether some particular tree is moved around isn't exactly fast

[02:13:45.0000] <smaug____>
live node lists are horrible for the performance

[02:13:48.0000] <rniwa>
smaug____: sure it is. you'd have to already update the value of isConnected for every node.

[02:14:23.0000] <smaug____>
yes. and that code is very hot

[02:14:25.0000] <rniwa>
smaug____: so your engine already needs to be aware when a node gets removed from the tree

[02:14:32.0000] <smaug____>
adding more stuff there makes it slower

[02:14:58.0000] <rniwa>
smaug____: well, adding stuff to event dispatch also makes things slower

[02:15:08.0000] <rniwa>
smaug____: event dispatching is also quite hot.

[02:15:36.0000] <rniwa>
smaug____: storing extra 2-3 objects in our event path code would end up introducing more dependent loads & writes

[02:16:21.0000] <smaug____>
and I wouldn't want to sure more objects there

[02:16:31.0000] <smaug____>
but we disagree with encapsulation here

[02:16:37.0000] <rniwa>
smaug____: it seems so

[02:16:53.0000] <rniwa>
smaug____: i really don't understand why you think it's okay to leak nodes in this case

[02:17:03.0000] <smaug____>
this isn't much different to leaking closed shadow via event.target or so

[02:17:29.0000] <smaug____>
first event.target is in open tree, one takes a ref to event, then target is moved to a closed tree

[02:17:29.0000] <rniwa>
smaug____: that's why event.target gets re-targeted not to do that

[02:17:35.0000] <smaug____>
you leak closed shadow

[02:18:04.0000] <rniwa>
smaug____: if you get to have access to it first, yes

[02:18:13.0000] <rniwa>
smaug____: but you can't always do that

[02:19:19.0000] <smaug____>
adding capturing listener to window is quite effective

[02:19:41.0000] <rniwa>
smaug____: unless the target is already in another closed shadow tree

[02:20:16.0000] <smaug____>
well, in my example target was in open tree

[02:20:35.0000] <rniwa>
smaug____: you can be in open tree inside a closed shadow tree

[02:21:31.0000] <smaug____>
oh sure. composedPath wouldn't leak that case, since it was initially hidden too from light dom

[02:22:00.0000] <rniwa>
smaug____: it would leak to the open trees of that closed shadow tree

[02:22:56.0000] <annevk>
smaug____: I think to make useful progress you'd have to make a more detailed proposal that rniwa can then critique

[02:23:02.0000] <smaug____>
but you leak that already if you move anything from open to closed.

[02:24:17.0000] <rniwa>
smaug____: that's not really true.

[02:24:22.0000] <rniwa>
smaug____

[02:24:33.0000] <rniwa>
 smaug____: if you're talking about the security level of leak, then yes

[02:24:45.0000] <rniwa>
smaug____: but you're talking about accidental leaks, then no

[02:25:34.0000] <smaug____>
easily. If you just happen to keep the reference to the originally open node

[02:25:41.0000] <rniwa>
smaug____: since shadow tree in its current form isn't a security feature, i don't think making an observation that something is technically possible isn't even useful

[02:25:46.0000] <smaug____>
and then start to play with it when it has been moved to closed tree

[02:26:10.0000] <rniwa>
smaug____: well, it's totally okay for a node to be in an open tree for a brief moment of time

[02:26:12.0000] <smaug____>
rniwa: right. So then I don't get your point here :)

[02:26:32.0000] <rniwa>
smaug____: also, JS keeping a reference to a node isn't really a serious concern to me since this is not really a security model

[02:26:51.0000] <rniwa>
smaug____: so let's say you have some component which moves child nodes of a shadow host into its own tree

[02:26:55.0000] <rniwa>
smaug____: and it does this lazily

[02:27:30.0000] <rniwa>
smaug____: and that lazily movement may happen when it detects that an event got dispatched on its host element

[02:27:44.0000] <rniwa>
smaug____: with the event target being one of the child nodes of the host

[02:27:58.0000] <rniwa>
smaug____: in that case, if this component moves the nodes into its closed shadow tree

[02:28:15.0000] <rniwa>
smaug____: then the outside observer who is listening to this event shouldn't be able to see these nodes as target's

[02:28:57.0000] <smaug____>
except if the outside observer is capturing listener, and would handle the event before the listener in the host

[02:29:25.0000] <rniwa>
smaug____: again, this is not a security model

[02:29:27.0000] <smaug____>
why would the composedPath be different for capturing vs. bubble listener

[02:29:33.0000] <smaug____>
sure

[02:29:40.0000] <smaug____>
I'm talking about API consistency

[02:29:48.0000] <rniwa>
smaug____: well, the component might be moving nodes at the capturing phase

[02:30:07.0000] <rniwa>
smaug____: the API is consistent to the extent nodes inside a closed shadow tree is always hidden

[02:30:35.0000] <rniwa>
smaug____: I agree that the list of nodes inside a composed event path shouldn't change

[02:30:58.0000] <rniwa>
smaug____: in fact, composedTree as currently spec'ed would always return the same event path if there are no closed shadow trees

[02:31:33.0000] <rniwa>
smaug____: however, there is a very important invariant for closed shadow trees, which is that no node inside a closed shadow tree is exposed to the outside DOM tree.

[02:32:11.0000] <smaug____>
but the node has been exposed to the outside world already... this is going circles or how does one say it in English

[02:32:21.0000] <rniwa>
smaug____: going in circles