2019-03-01
[21:08:09.0000] <cybai>
hi there, I'd like to ask, when using keyboard "Up arrow" key and "Down arrow" key to <input type=date>, which part of spec should I refer to? I didn't find similar things in https://html.spec.whatwg.org/multipage/input.html#date-state-(type=date)

[21:08:11.0000] <cybai>
thanks!

[22:27:13.0000] <MikeSmith>
cybai: the spec intentionally doesn’t prescribe any requirements for that

[22:28:30.0000] <MikeSmith>
cybai: it is up to the browser to present the appropriate UI depending on the device and input method (e.g., on mobile you’re not gonna be using up/down arrow keys there anyway)

[22:30:03.0000] <cybai>
MikeSmith: Ah! I see! (the mobile case makes sense to me!) and thanks answering to me! btw, I asked because when I tried to use keyboard to add date on <input type=date>, I can add to 2/31

[22:30:27.0000] <MikeSmith>
ah

[22:30:37.0000] <MikeSmith>
that is a browser bug I guess

[22:30:58.0000] <cybai>
I tried on Chrome and Firefox and both of them did the same trick

[22:31:12.0000] <cybai>
(I'm on macOS)

[22:31:28.0000] <cybai>
Should I file a bug for it?

[22:31:33.0000] <MikeSmith>
I would yeah

[22:31:39.0000] <cybai>
ok! thanks!

[22:31:44.0000] <MikeSmith>
cheers

[22:31:58.0000] <cybai>
:D

[22:36:04.0000] <cybai>
MikeSmith: hmm, sorry, please let me ask a dummy question 🙇 Should I file the issue for both bugzilla and crbug? Or it's fine to file it at whatg/html GitHub repo? Thanks

[22:38:56.0000] <MikeSmith>
cybai: for both Mozilla’s bugzilla and crbug for Chrome, yeah

[22:39:05.0000] <cybai>
MikeSmith: thanks!

[22:49:33.0000] <cybai>
https://bugzilla.mozilla.org/show_bug.cgi?id=1531652

[22:49:42.0000] <cybai>
https://crbug.com/937192

[22:49:45.0000] <cybai>
here they are :)

[22:54:04.0000] <MikeSmith>
cybai: thanks ー Cc’d myself on both

[22:54:33.0000] <cybai>
:+1:

[03:24:13.0000] <Ms2ger>
annevk, wanna review https://github.com/heycam/webidl/pull/668 too? :)

[04:24:57.0000] <annevk>
Ms2ger: it works, but it seems a little weird to me to use an ECMAScript object for an internal data structure

[04:25:07.0000] <annevk>
Ms2ger: it makes me worried about that leaking somehow

[04:25:17.0000] <annevk>
Ms2ger: but maybe this is how implementations do it as well? 😃

[04:42:51.0000] <Ms2ger>
annevk, Gecko certainly, yeah

[04:43:44.0000] <annevk>
Ms2ger: I guess it makes sense

[04:44:23.0000] <Ms2ger>
annevk, a Record could probably have worked too, but that would've meant duplicating all the "define the attributes" stuff

[04:45:40.0000] <annevk>
Ms2ger: some things would have to be parameterized, indeed

[04:46:13.0000] <Ms2ger>
annevk, maybe I could add a note that the object will never escape

[04:47:29.0000] <annevk>
Ms2ger: I did think of that, but either way is fine

[05:30:47.0000] <annevk>
Domenic: if you could direct whoever contacted you about attending the "Web Components" meeting to comment on https://github.com/w3c/webcomponents/issues/786 that'd be great

[05:31:29.0000] <annevk>
Domenic: I'll ensure they get in and have a say, assuming nobody objects to Mozilla hosting

[07:58:10.0000] <SimonSapin_>
Hi annevk. Re https://github.com/servo/rust-url/issues/488, do you think the spec should change to support path only (no authority) URLs with "://" ?

[08:01:45.0000] <annevk>
SimonSapin: what would that mean?

[08:02:36.0000] <SimonSapin>
such that indexeddb://foo/bar can parse without the cannot-be-a-base flag

[08:02:59.0000] <SimonSapin>
and without a host name

[08:03:05.0000] <SimonSapin>
("foo" is part of the path)

[08:03:08.0000] <annevk>
SimonSapin: but how would we decide the schemes to apply that to?

[08:03:22.0000] <annevk>
SimonSapin: seems rather incompatible with a generic URL parser

[08:03:33.0000] <SimonSapin>
yeah that’s a good point

[11:28:40.0000] <annevk>
Domenic: so apparently .close() queues a task to discard a bc, but .closed knows about it directly

[11:29:02.0000] <annevk>
Domenic: this stuff is...

[11:29:39.0000] <Domenic>
Was that for all BCs or just auxiliary ones

[11:31:05.0000] <annevk>
Domenic: top-level I suppose (you can .close() a non-aux too in certain cases)

[11:31:44.0000] <annevk>
Domenic: Safari does keep opener/closed sync (in that closed will be false after close(), but true once discard happens

[11:33:01.0000] <annevk>
Domenic: and in Firefox at least named targeting is also affected by the internal bit .closed looks at

[11:33:14.0000] <annevk>
what nightmare is this

[13:02:39.0000] <annevk>
Domenic: for tests, when you have multiple arrays that signify parameters, is there a better pattern than nested forEach?

[13:03:30.0000] <Domenic>
Don't think so. Maybe declaring the two arrays up-front instead of [.......].forEach() style. Also I prefer for-of to forEach myself.

[13:10:35.0000] <annevk>
It’s so common I’d almost abstract it somehow

[13:12:03.0000] <annevk>
I guess with for-of I’d have to use a variable for the array

[13:25:27.0000] <Domenic>
Yeah, I find that a bit clearer

[13:25:38.0000] <Domenic>
Like, here's the matrix of test data, then here's the test


2019-03-03
[03:23:15.0000] <MikeSmith>
annevk: maybe it’s time to lock https://github.com/whatwg/xhr/issues/20 (Abandon hope of removing sync XHR from the web platform?) from further comments

[03:23:55.0000] <MikeSmith>
it is hard to imagine anybody coming along with new information to add as a comment there

[03:26:18.0000] <MikeSmith>
but it’s easy to imagine N more commentors showing up to repeat the same subjective argument that others there have already said

[03:57:27.0000] <annevk>
MikeSmith: feel free

[04:08:16.0000] <MikeSmith>
annevk: OK, done

[04:10:49.0000] <MikeSmith>
annevk: btw about CORS questions on Stack Overflow, one of the most-common questions by far is the case where the OP has gotten a 4xx or 5xx response but thinks they have a CORS problem due to the fact that browser reports the response as lacking the Access-Control-Allow-Origin header

[04:11:40.0000] <MikeSmith>
I don’t know how to prevent that but I wonder if you’d thought about it all

[04:12:22.0000] <MikeSmith>
obviously one way would be for browsers to not report any CORS-related errors in the devtools console for 4xx and 5xx responses

[04:12:25.0000] <annevk>
I don’t think too much about CORS, but devtools would reveal this pretty quickly?

[04:12:56.0000] <annevk>
Well that’d be bad, since it is a CORS error

[04:12:57.0000] <MikeSmith>
devs don’t seem to be able to figure it out on their

[04:13:05.0000] <MikeSmith>
right sure it would be bad

[04:13:37.0000] <MikeSmith>
just saying outside of suppressing the error, I don’t have good ideas

[04:13:53.0000] <annevk>
Devtools could be more explicit perhaps

[04:14:12.0000] <MikeSmith>
yeah maybe I’ll raise some browser issues for it

[04:14:20.0000] <annevk>
Your server returned a 410 without ACAO header

[04:14:35.0000] <MikeSmith>
yeah something more like that maybe

[04:14:48.0000] <MikeSmith>
anyway, see https://stackoverflow.com/questions/54795541/503-return-from-server-is-branded-as-cors-violation-by-chrome for an meta-report about it at SO

[04:15:04.0000] <MikeSmith>
> The reason this is bad is because it misled our developers and wasted some time hunting down a CORS problem that wasn't really there.

[04:16:17.0000] <MikeSmith>
it is not uncommon to see reports on SO from people who say they have literally spent hours trying to figure out what was wrong with their CORS config, when it turns out they never had CORS-config problem at all but instead a 4xx or 5xx problem

[04:17:58.0000] <annevk>
Hmm but the tools clearly say it’s 5xx

[04:18:24.0000] <MikeSmith>
yeah I know but they still often miss it

[04:18:36.0000] <MikeSmith>
or they don’t understand that is the real problem

[04:18:57.0000] <MikeSmith>
..or they think their CORS config has caused the 4xx or 5xx error

[04:18:59.0000] <annevk>
The problem with fixing it the way you suggest is that some might try to expose that error to content

[04:19:12.0000] <MikeSmith>
yeah


2019-03-04
[03:43:02.0000] <jgraham>
nox: Yes, the manifest is a good RIIR candidate and I started doing that (in a half-hearted way) at some point. But jdm's point is also true; we would either need to keep the Python stuff working or have a really good story for how to make it work for users (and projects) without rustc

[03:43:23.0000] <nox>
Does the manifest file format change often?

[03:43:37.0000] <nox>
It's not documented, though.

[03:43:39.0000] <jgraham>
If you are still seeing dozens of seconds to work out it has nothing to do then give us a profile please because dozens seems high; it should be under 5

[03:43:56.0000] <jgraham>
(on reasonable but not exceptional hardware)

[03:44:36.0000] <jgraham>
nox: Not often but ocasionally. gsnedders is doing some (Python) perf work on it at the moment

[03:46:05.0000] <jgraham>
nox: (although based on the rest of your timeline I guess really if we'd just written it in lisp that would have solved all our problems)

[03:46:13.0000] <nox>
LOL

[03:46:41.0000] <nox>
jgraham: Yeah I had not realised it's way faster than it used to be now, I checked that a few days after my initial tweet and forgot to follow-up.

[03:51:25.0000] <jgraham>
nox: OK. I am kind of hoping we find time to replace the HTML parsing parts with html5ever at some point, so we might need to figure out the rust dependency thing anyway (but that can probably be a binary wheel, which I hope porjects can cope with). But yeah it's generally accepted that the performance of that tool is bad and also important

[03:52:26.0000] <nox>
jgraham: AFAIK TabAtkins doesn't think we can use html5ever given they want to mix HTML and Markdown parsing in one pass and whatnot.

[03:53:10.0000] <jgraham>
nox: Yeah, for Bikeshed it's probably harder than for the manifest itself

[03:53:27.0000] <nox>
Ah right, I'm mixing stuff.

[03:53:35.0000] <MikeSmith>
what’s a binary wheel?

[03:53:38.0000] <jgraham>
(but the distribution requirements on bikeshed are also pretty different since no one is using it in CI afaik)

[03:54:00.0000] <jgraham>
MikeSmith: A Python thing for distributing precompiled binaries

[03:54:08.0000] <MikeSmith>
ah OK

[04:31:50.0000] <annevk>
littledan: since we were talking about PR habits earlier, why do you force push a lot?

[04:32:03.0000] <littledan>
annevk: Oh, sorry about this, would you prefer a follow-on PR?

[04:32:26.0000] <littledan>
I guess it's because, in TC39, they don't end up squashing the patches, and it shows up poorly in the commit history if I don't squash them in advance

[04:32:34.0000] <littledan>
annevk: What would you prefer to make it easy to review?

[04:32:49.0000] <littledan>
not follow-on PR, but rather a stacked patch

[04:33:19.0000] <annevk>
littledan: in WHATWG land we squash (or rebase & merge in exceptional cases) and generally do "feedback/nit/typo" commits following the initial one

[04:33:33.0000] <annevk>
littledan: in the PR, so that the reviewer can review deltas

[04:33:43.0000] <littledan>
right, makes sense, I'll switch to that

[04:33:46.0000] <littledan>
thanks for explaining

[04:33:52.0000] <littledan>
and sorry for the noise

[04:34:00.0000] <annevk>
no worries

[04:34:23.0000] <gsnedders>
jgraham, nox: also manifest regen isn't a huge deal, IMO, because we rarely do a full rebuild of the manifest, and that's what's really slow

[04:34:31.0000] <annevk>
I really wonder why they prefer merge commits. Linear history is so nice...

[04:34:35.0000] <annevk>
(in TC39)

[04:35:09.0000] <littledan>
yeah, I don't really know who "they" is there; the editor group has its calls very late, and they don't seem to be publishing their notes or rationale anywhere. They've pushed back against people who raised these kinds of concerns.

[04:35:23.0000] <littledan>
we used to do that

[04:36:20.0000] <gsnedders>
jgraham, nox: and html5ever still has the problem of being UTF-8 only

[04:38:23.0000] <annevk>
gsnedders: sounds like a feature to me

[04:38:40.0000] <annevk>
gsnedders: though I guess not for parsing tests if that's the goal here 😃

[04:38:53.0000] <gsnedders>
annevk: as long as web-platform-tests needs to test documents in other encodings, which it likely does as long as we support other encodings…

[04:39:05.0000] <gsnedders>
annevk: and probably not great for web compat in Servo either :)

[04:39:20.0000] <annevk>
littledan: okay, hopefully they'll elaborate in response to your question; if not I'll try to help out by prodding too

[04:40:05.0000] <nox>
gsnedders: Yeah it needs some rework to be able to cope with other encodings :(

[04:40:39.0000] <littledan>
yeah, thanks

[06:42:09.0000] <annevk>
/me notices "document family" in HTML

[07:16:36.0000] <annevk>
Domenic: so a Window object needs to hold a reference to a WindowProxy object

[07:16:47.0000] <Domenic>
This seems likely

[07:16:56.0000] <annevk>
Domenic: otherwise someWindowObject.self crashes (it currently does in the spec)

[07:17:14.0000] <annevk>
(can crash, when browsing context is null)

[07:18:18.0000] <Domenic>
I think at least some browsers will return null or undefined for that.

[07:19:11.0000] <annevk>
Domenic: right you are

[07:19:23.0000] <Domenic>
I guess there's a bigger question of what happens to someWindowObject's [[Window]] internal slot on BC discard

[07:19:32.0000] <Domenic>
In some browsers I think they null it out and start returning undefined/null all over the place

[07:19:38.0000] <Domenic>
But in others not so much

[07:19:50.0000] <annevk>
Domenic: nulling that seems fine since there should be no way to get to it?

[07:20:12.0000] <Domenic>
Well if you null [[Window]] then e.g. someWindowObject.Array is undefined

[07:20:13.0000] <annevk>
oh wait, no, that's not fine

[07:20:23.0000] <Domenic>
Which might be the case in Safari IIRC

[07:20:44.0000] <Domenic>
But this is treading close to an area where I recall Edge saying that it was web-interop-pain for them being over-aggressive on cutting references.

[07:20:58.0000] <annevk>
I guess that warrants further testing

[07:21:20.0000] <annevk>
I'm now -1 on adding a ref from Window to WindowProxy though; I'd like to see Firefox return null for self/frames/window

[07:21:51.0000] <Domenic>
Seems nice, although unclear how much it helps in general

[07:22:17.0000] <Domenic>
Because if you have someOtherWindowObject you're holding on to the WindowProxy anyway.

[07:23:29.0000] <annevk>
yeah, it's just one pointer less

[11:56:23.0000] <Domenic>
annevk: so what is stopping us from saying `fetch("https://example.com/", { credentials: "omit" })`, i.e. no-credentials HTTPS fetches, can return non-opaque responses with no CORS needed?

[12:50:15.0000] <zcorpan>
Domenic: secrets in intranets with IP-based access?

[12:50:28.0000] <Domenic>
That are accessible over https://?

[12:51:20.0000] <zcorpan>
Not sure

[13:25:52.0000] <annevk>
Domenic: maybe nothing eventually, depends a bit on how things play out and whether that is indeed as secure as I hope it is

[13:26:20.0000] <Domenic>
That'd be crazy... all these years making developers deal with CORS and they could have just done that...

[13:26:43.0000] <annevk>
Domenic: well, it’s complicated


2019-03-05
[22:03:47.0000] <MikeSmith>
annevk: Domenic is there some github issues that was the context for the CORS discussion?

[23:39:03.0000] <MikeSmith>
annevk: “document family” seems like the wrong/misleading term for what it’s defining it

[23:40:23.0000] <MikeSmith>
seems like that wrong analogy

[23:40:37.0000] <MikeSmith>
but I guess I can’t think of a better one

[02:27:30.0000] <annevk>
Yeah dunno either, it'll probably go away whenever someone rewrites history...

[04:40:45.0000] <zcorpan_>
annevk: re https://github.com/web-platform-tests/wpt/pull/15669 , for <iframe onload=w(1) src="http://ghjkghj">, chrome fires load but safari and firefox don't

[04:43:55.0000] <annevk>
zcorpan_: ah, I tried http://test:test/ and there they all did load

[04:44:04.0000] <annevk>
zcorpan_: network errors are hard :/

[04:44:14.0000] <annevk>
(also the spec sucks)

[04:44:25.0000] <zcorpan_>
that's a URL parse error right?

[04:44:35.0000] <annevk>
yeah

[04:45:00.0000] <annevk>
and yeah, I realized that too

[04:46:12.0000] <zcorpan_>
yep. looks like that navigates to about:blank per spec https://html.spec.whatwg.org/multipage/iframe-embed-object.html#otherwise-steps-for-iframe-or-frame-elements

[04:49:09.0000] <zcorpan_>
https://html.spec.whatwg.org/multipage/browsing-the-web.html#process-a-navigate-response step 1 doesn't say to fire load, so chrome has a bug

[04:55:18.0000] <zcorpan_>
https://bugs.chromium.org/p/chromium/issues/detail?id=938279

[04:57:35.0000] <zcorpan_>
as for contentDocument http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6736

[05:01:49.0000] <zcorpan_>
but also http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6737

[05:05:27.0000] <annevk>
zcorpan_: 6736 reads contentDocument too quickly

[05:06:35.0000] <zcorpan_>
ah yes

[08:38:53.0000] <Domenic>
Are there cases where .parentElement !== null and .parentElement !== .parentNode

[08:50:38.0000] <Domenic>
littledan: in case it's quick to answer, does your modules PR handle cases like `module "std:x" { interface Node { }; interface Foo { void op(Node n); } }`? In particular how do we know which `Node` `op()` takes, the global one or the module-local one?

[08:50:48.0000] <Domenic>
If it's not quick to answer I'll ask on the issue tracker.

[08:51:16.0000] <littledan>
Domenic, That's a good question. It doesn't have any text about that

[08:51:34.0000] <Domenic>
Cool, will raise it on the tracker for discussion.

[09:05:26.0000] <annevk>
Domenic: I thought parentElement returned parentNode if an Element and null otherwise

[09:05:43.0000] <Domenic>
I think you are right

[09:06:06.0000] <Domenic>
I just got turned around

[09:06:22.0000] <Domenic>
So in that case I declare parentElement a "slightly bad part" of DOM.

[09:06:41.0000] <annevk>
heh


2019-03-06
[05:48:33.0000] <littledan>
is this a good place to bikeshed about whether we should use the term "module script" for how we want to generalize to JSON module scripts, CSS module scripts, etc or something else? I share Domenic's uncertainty, but I also can't think of a better name. I'm thinking "module script" for the whole category, and then within that, JavaScript module script, WebAssembly module script, JSON module script.

[05:48:53.0000] <Domenic>
This is a good place.

[05:48:57.0000] <littledan>
re https://github.com/whatwg/html/pull/4407

[05:48:58.0000] <Domenic>
Terminology wise I think module script is good

[05:49:29.0000] <Domenic>
I'm a little uncertain infrastructure-wise whether "JSON module script" should be a type of the "script" struct

[05:49:47.0000] <littledan>
I don't think anyone uses the fetch options or base URL, but we definitely do need a settings object as you suggested

[05:49:49.0000] <Domenic>
But probably it would end up poorly to try to have two separate things that could be in the module map/returned by "fetch a module script"/etc.

[05:50:51.0000] <littledan>
can we say, JSON module scripts and CSS module scripts are script modules which always have fetch options, base URL, and error to rethrow null?

[05:51:04.0000] <littledan>
*are script modules which...

[05:51:07.0000] <Domenic>
Yeah I was thinking that too

[05:51:39.0000] <Domenic>
Or we could introduce a new thing, "JavaScript module script", which has those three fields, and leave them out of the base "script" struct.

[05:51:43.0000] <Domenic>
But that refactoring is probably too early

[05:51:50.0000] <littledan>
well, then we'd have to re-add them to classic scripts, right?

[05:52:36.0000] <littledan>
anyway, the rename idea was a really good once, since it lets us introduce a general "module script" concept, which should be applied some of the time, and not other times

[05:53:14.0000] <Domenic>
Right, the hierarchy would be script -> {JSON module script, JavaScript script -> { JavaScript module script, classic script } } or something like that. I think that works?

[05:53:37.0000] <littledan>
well, then there's some things that are in common to all module scripts

[05:53:59.0000] <littledan>
at least algorithm-wise, maybe not storage wise

[05:54:11.0000] <Domenic>
Ah I see, yeah, I was only looking at storage wise

[05:54:22.0000] <littledan>
anyway, thanks for the detailed review; I think it makes sense from here

[05:54:27.0000] <Domenic>
Cool

[05:59:18.0000] <annevk>
Perhaps we should drop "script" from "module script"?

[05:59:34.0000] <Domenic>
I think the reasoning still stands; they're still introduced through <script> elements

[05:59:55.0000] <annevk>
And then we'd have "script" and "modules"

[06:00:23.0000] <annevk>
At some point the <script> element is quite far removed though. E.g., a service worker JavaScript module

[06:00:24.0000] <Domenic>
We'd also need a term for the unified concept, since several places in the spec operate on (what are currently called) "scripts" generically

[06:00:38.0000] <annevk>
"script or module" (I realize this is not great given ECMAScript)

[06:01:11.0000] <Domenic>
It feels weird to define a struct named with a space :)

[06:02:38.0000] <annevk>
I could also live with "script" -> { "module" -> { "JavaScript module", ... }, "classic script" }

[06:03:13.0000] <Domenic>
I guess I just find retaining the script suffix clearer in that case

[06:03:17.0000] <annevk>
The "script" suffix feels very redundant and somewhat wrong in the non-JavaScript cases

[06:04:57.0000] <annevk>
Also minor nit: probably "style sheet" rather than CSS given precedent? Or maybe precedent is bad here...

[06:06:06.0000] <Domenic>
Interesting question

[06:16:17.0000] <littledan>
"module document" for JSON, "module sheet" for CSS? no, that's a joke

[06:17:36.0000] <littledan>
yeah, looks like we should be talking about "style sheet modules"

[06:18:16.0000] <littledan>
or "style sheet module scripts"

[06:18:43.0000] <littledan>
unfortunately, if we use "CSS modules" we run into a naming ambiguity...

[06:19:57.0000] <Domenic>
We do?

[06:22:03.0000] <littledan>
referring to those CSS specs

[06:23:12.0000] <Domenic>
Oh lol

[07:06:02.0000] <astearns>
I wouldn't worry too much about a naming collision with spec terminology, but "style module" seems good

[07:09:04.0000] <annevk>
Domenic: I haven't really bothered to setup a package thing locally yet to be able to install new Python modules

[07:09:34.0000] <Domenic>
OK, well, I can try to do so myself I suppose to review

[07:10:09.0000] <annevk>
Domenic: that'd be great, thanks; I did try in with Github and their Markdown would mess up links coming after explicit markup

[07:10:42.0000] <Domenic>
Hmm, I wonder if it's even worth converting to Markdown then, if it won't display on GitHub properly...

[07:10:48.0000] <annevk>
Domenic: GitHub Markdown did show I got the indentation correct for multiple paragraphs in a list item, though I don't know how stable that notation is across versions

[07:11:20.0000] <annevk>
Domenic: that's a fair point, or maybe we should do the classes differently somehow

[07:12:05.0000] <annevk>
Domenic: https://github.com/whatwg/sg/blob/ae3d8b6ca82ec3013b7eb29c085800cd83b1b01b/Working%20Mode.md

[07:12:32.0000] <Domenic>
Ah right, yeah, I think per CommonMark if you're inside a HTML block you can't use Markdown

[07:12:56.0000] <Domenic>
Although the rules might be different for `<p class="note">\n ... stuff  \n</p>` vs. `<p class="note"> ... stuff</p>`

[07:14:47.0000] <annevk>
I want to get to https://github.com/whatwg/sg/issues/78 though I suppose I could give that a go in parallel given how far along we are now

[07:14:51.0000] <annevk>
But not today

[10:32:26.0000] <Domenic>
annevk: to confirm, window.close() queues a task to discard in Chrome and Safari too?

[10:32:57.0000] <annevk>
Domenic: yeah, they fail due to poor global obj impl

[10:33:11.0000] <Domenic>
I was hoping they might discard synchronously

[10:33:17.0000] <annevk>
Domenic: for which there are bugs on file

[10:33:37.0000] <annevk>
Domenic: Safari does not have the is closing flag

[10:33:49.0000] <annevk>
or boolean

[10:34:03.0000] <Domenic>
Yeah, but nobody does the simple thing, I guess

[10:34:10.0000] <annevk>
But it seemed safer to follow others for that

[10:35:05.0000] <annevk>
It’s rather silly given nested bcs, but yeah

[12:13:45.0000] <hober>
i keep failing to think of the right search terms for the relevant html issue on github; does anyone remember where we ended up with the "label of the enter key on a virtual keyboard during text input" thing?

[12:13:48.0000] <hober>
or just a link to the issue

[12:15:36.0000] <hober>
oh, enterkeyhint. nevermind.


2019-03-07
[03:48:58.0000] <yoav>
Hey! HTML question - I want to move the image-specific Client Hints definitions away from the Client Hints IETF draft and into one of the web specs. IMO, the natural place for that would be the HTML spec. I want to see if: a) folks here agree? b) If so, where? somewhere in https://html.spec.whatwg.org/#images? Or elsewhere?

[04:13:06.0000] <annevk>
yoav: I guess because they are to be set during image fetching?

[04:14:20.0000] <annevk>
yoav: HTML does own that at the moment so that'd probably make sense, though maybe it should move to Fetch long term as there's a bunch of specifications that need to use image fetching, HTML being one of them

[04:14:42.0000] <yoav>
The actual setting would be in Fetch, but I want to define what those features are, and HTML's image section seems to me like the best fit. There's also some interaction between Content-DPR and image density which definitely needs to be defined there

[04:15:04.0000] <yoav>
If the image loading section moves to Fetch, it makes sense for that to move with it

[04:15:47.0000] <annevk>
yoav: is image density HTML-specific?

[04:19:17.0000] <yoav>
The concept of https://html.spec.whatwg.org/#density-corrected-intrinsic-width-and-height is something I know exists in HTML and CSS, but not aware of it elsewhere

[04:19:46.0000] <yoav>
(although it seems like it could be applicable elsewhere as well)

[04:21:03.0000] <yoav>
Content-DPR will probably need to set the https://html.spec.whatwg.org/#current-pixel-density

[04:23:19.0000] <annevk>
yoav: CSS is what I'm thinking of primarily with regards to the algorithm needing abstraction, though also icon fetches and such

[04:23:49.0000] <yoav>
oh, OK

[04:23:58.0000] <yoav>
that same concept is applicable there

[04:25:15.0000] <yoav>
through image-set or through Client Hints

[04:25:42.0000] <annevk>
yoav: I guess at least through tests we can ensure both are covered, but it'd be nice if you could find someone to finally give image fetching some love overall so it's less of a neglected mess

[04:26:03.0000] <annevk>
yoav: anyway, also sounds like HTML is the place

[04:26:32.0000] <yoav>
cool, thanks!

[04:27:38.0000] <yoav>
sounds like that kind of image loading love would be something that would help the larger goal of CSS/Fetch integration, right?

[04:28:07.0000] <ondras>
9/w 42

[04:28:13.0000] <ondras>
damn sorry

[04:30:00.0000] <yoav>
that's something I discussed a bit with JakeA. Agree that it would be good to move that forward. Not sure who can take that on and when tho

[06:51:08.0000] <Ms2ger>
annevk, I'm starting to feel like we should explicitly define separate IDL and ES objects for "platform objects", what do you think?

[06:53:35.0000] <annevk>
Ms2ger: I'm not sure I fully understand, but being able to use the term for both would be good

[06:53:59.0000] <annevk>
Ms2ger: although maybe it's not needed, "is a platform object" is always correctly used

[06:54:25.0000] <annevk>
Ms2ger: it's mostly that things building on "platform object" also need to be available easily from IDL objects (or perhaps primarily)

[07:55:41.0000] <annevk>
Domenic: could you review https://github.com/web-platform-tests/wpt/pull/15649 while you're going through things?

[07:55:50.0000] <annevk>
(the failure doesn't matter apparently)

[07:56:43.0000] <Domenic>
Sure, will be a couple hours

[07:59:03.0000] <annevk>
ta

[08:00:29.0000] <Domenic>
Or, now; I misremembered my meeting time by an hour -_-

[08:14:10.0000] <Domenic>
Blocked https://github.com/zafar4u org-wide due to repeated (machine-generated?) spam

[08:23:43.0000] <annevk>
Domenic: I think you read over my comment in https://github.com/whatwg/html/pull/4415 that we cannot grab this stuff from platform objects (which are ECMAScript objects)

[08:24:03.0000] <annevk>
Domenic: it's now no longer tracked anywhere at least

[08:24:09.0000] <Domenic>
Oh, sorry about that

[08:24:19.0000] <Domenic>
My opinion is we should be OK blurring the lines, but yeah, we should track it

[08:24:24.0000] <Domenic>
I'll open a Web IDL issue in penance

[08:33:07.0000] <annevk>
Domenic: I filed https://github.com/whatwg/html/issues/4418

[08:33:22.0000] <annevk>
I forgot to look if you replied

[08:33:35.0000] <Domenic>
Hmm I filed https://github.com/heycam/webidl/issues/680

[09:06:19.0000] <annevk>
Domenic: mostly worried due it being a security boundary of sorts, so feels like we should be explicit about bridging

[09:58:43.0000] <zcorpan>
hsivonen: MikeSmith: what's the url to the parse tree tool on validator.nu ?

[09:59:09.0000] <zcorpan>
also can it be made discoverable in About?

[10:01:02.0000] <zcorpan>
found it https://parsetree.validator.nu/


2019-03-08
[00:52:14.0000] <yoav>
annevk: Hey! Another client hints related question. I want to define the `Width` CH value, which is the related img element's source-set's source-size. But if I were to call this algorithm from Fetch, I don't really have the related img element there

[00:52:31.0000] <yoav>
or do I?

[00:54:39.0000] <yoav>
Is there a way for me to find that initiating element from an ongoing Fetch? Do I need a way to pass along that value with the Fetch call from HTML's image processing model? Something else?

[01:26:31.0000] <yoav>
Also, if I want to link to the viewport definition, current HTML refs seem to point to https://drafts.csswg.org/css2/visuren.html#viewport while other places in CSS point to https://drafts.csswg.org/cssom-view/#viewport. I'm not sure which is the "right" one

[01:26:47.0000] <Ms2ger>
yoav, I guess layering-wise, passing it along explicitly sounds best

[01:44:58.0000] <yoav>
Ms2ger: makes sense

[02:23:49.0000] <annevk>
yoav: file an issue on viewport? Not sure either

[02:24:12.0000] <yoav>
ok, will do

[02:24:15.0000] <annevk>
Also, public holiday here so not really doing much work-wise

[02:24:33.0000] <yoav>
oh, didn't know. Have fun! :)


2019-03-09
[13:00:26.0000] <eeeps>
mkwst: trying to wrap my head around the basics of https://github.com/mikewest/first-party-sets. If b.com is in a.com's first party set, when the user makes a request to b.com, will b.com get all of the cookies that have been set on a.com?


2019-03-11
[06:34:14.0000] <annevk>
Ms2ger: yt?

[06:34:19.0000] <annevk>
Ms2ger: I'm looking at "To determine the value of a named property name in a Window, the user agent must return the value obtained using the following steps:"

[06:34:31.0000] <Ms2ger>
annevk, did you see the comment I made on the PR?

[06:34:34.0000] <annevk>
Ms2ger: step 2 there says "If objects contains a nested browsing context, then return the WindowProxy object of the nested browsing context corresponding to the first browsing context container in tree order whose nested browsing context is in objects."

[06:34:44.0000] <annevk>
Ms2ger: it doesn't talk about names

[06:34:51.0000] <annevk>
(of bcs)

[06:34:59.0000] <Ms2ger>
Lemme grab the spec

[06:35:30.0000] <Ms2ger>
Step one refers to "named objects", which does talk about names: https://html.spec.whatwg.org/multipage/window-object.html#dom-window-nameditem-filter

[06:36:25.0000] <annevk>
I guess the question is if "objects contains a nested browsing context" is worded poorly

[06:36:40.0000] <annevk>
Perhaps it meant to say "if objects contains a browsing context"?

[06:37:20.0000] <annevk>
That is, I was assuming step 2 did some unwrapping, but maybe it doesn't

[06:37:36.0000] <annevk>
And on reflection it wouldn't make much sense if it did

[06:38:21.0000] <annevk>
Ms2ger: okay, I guess I can fix the wording there as part of https://github.com/whatwg/html/pull/4404 or some such

[06:39:28.0000] <Ms2ger>
Yeah, step 2 looks worse every time you read it :)

[06:49:15.0000] <smaug____>
/me tries to recall how .window.js get run...

[06:50:51.0000] <annevk>
smaug____: replace .js with .html

[06:51:07.0000] <smaug____>
but keep window?

[06:51:52.0000] <annevk>
smaug____: yes

[06:54:34.0000] <smaug____>
how surprising, I don't see Event-dispatch-listener-order.window.js in mozilla-central

[07:01:36.0000] <smaug____>
need to just wait for a merge, I guess

[08:12:15.0000] <annevk>
that's weird

[08:12:24.0000] <annevk>
I thought that was automated these days

[08:13:22.0000] <annevk>
jgraham: ^^

[08:15:29.0000] <jgraham>
annevk: Yeah, it's automated, the automation has been behind for a while and some maintainance is needed to address the root causes

[09:11:40.0000] <smaug____>
 is https://wpt.fyi/ down?

[09:12:41.0000] <Ms2ger>
smaug____, it was just updating, I think

[09:13:12.0000] <smaug____>
aha

[11:43:15.0000] <jyasskin>
https://html.spec.whatwg.org/multipage/iana.html tries to register a bunch of things with IANA, but most of them haven't made it to the relevant registries, like https://www.iana.org/assignments/media-types/media-types.xhtml and https://www.iana.org/assignments/message-headers/message-headers.xhtml. How's that process supposed to work?

[11:43:51.0000] <jyasskin>
(I noticed because of https://lists.w3.org/Archives/Public/ietf-http-wg/2019JanMar/0197.html)

[11:46:06.0000] <jyasskin>
The ones that made it seem to be the ones that got copied to https://www.w3.org/TR/html/iana.html.

[12:04:51.0000] <annevk>
jyasskin: it hasn’t really been worked on post-cooperation

[12:05:18.0000] <annevk>
jyasskin: though I did try to register Refresh at one point

[12:05:18.0000] <jyasskin>
"It" being the relationship between the WHATWG and IANA?

[12:06:04.0000] <annevk>
jyasskin: IANA registry post-cooperation between W3C and WHATWG

[12:06:31.0000] <annevk>
Maybe once that is fully resolved this would be easier to pick up again

[12:07:32.0000] <annevk>
Those registries also have not been super useful generally

[12:09:23.0000] <jyasskin>
I guess MDN can replace a lot of their use.

[12:10:31.0000] <annevk>
jyasskin: and standards you can revive

[12:13:22.0000] <jyasskin>
That makes sense. Still, for standards like HTTP that are not living, it'd be useful to at least make HTML's claims about what's in the registries match the registries themselves. :)


2019-03-12
[17:50:31.0000] <MikeSmith>
jyasskin: I did the registration process for several of the media types and found it pretty unusable

[17:54:58.0000] <MikeSmith>
I recall it requiring private e-mail communication to some unarchived address, and the apparently being handled/routed through a single person

[17:57:15.0000] <MikeSmith>
...and when I suggested replacing that process with something having a public record, I remember getting a reply claiming that wasn’t possible for some reason

[19:21:39.0000] <jyasskin>
MikeSmith: I'm definitely not an expert in IETF/IANA processes, but that does sound quite plausible. I haven't seen an indication that media types are changing, but mnot is taking over HTTP headers, and that, at least, will go to a public mailing list: https://tools.ietf.org/html/draft-ietf-httpbis-semantics-04#section-4.1.1.

[03:29:36.0000] <MikeSmith>
jyasskin: glad to hear there’s a better plan for HTTP headers

[03:34:03.0000] <MikeSmith>
I went back and re-read my e-mail exchange with the media types reviewer, and my takeaway from it is that the media-types registration process is gonna remain broken by design indefinitely ー or at least until someone new eventually takes over responsibility for it and tries to bring it into the 21st century

[03:37:06.0000] <MikeSmith>
annevk: about <script> do you know if it’s the case that when a <script> has a src attribute, UAs ignore the type attribute and handle it as JavaScript regardless?

[03:41:46.0000] <annevk>
MikeSmith: I don't

[03:44:13.0000] <MikeSmith>
annevk: OK anyway well I should have just take time to test before I asked. A simple test shows that current browsers don’t handle it as JavaScript if the type attribute is some non-JavaScript type

[03:44:47.0000] <MikeSmith>
which makes sense because I assume that behavior is what the spec requires

[03:45:15.0000] <MikeSmith>
so now I wonder why we have the spec disallow something like     <script src="https://example.org/#data" type="application/vnd.data"></script>

[03:46:37.0000] <MikeSmith>
...that is, the spec requires any non-JavaScript script content to be inline rather than being an external resourse

[03:50:36.0000] <annevk>
MikeSmith: does the browser fetch the data?

[03:59:38.0000] <MikeSmith>
annevk: ah ー I see that no, it doesn’t fetch it if the type attribute specifies a non-JavaScript type

[04:00:15.0000] <MikeSmith>
I wonder if it’s worth adding a note to the spec explaining that

[04:00:37.0000] <annevk>
I mean, it's disallowed

[04:01:04.0000] <annevk>
If you want external data, why not use <link>?

[04:01:35.0000] <MikeSmith>
yeah I know it’s disallowed, but I mean a note to make it clear why

[04:02:27.0000] <MikeSmith>
I can imagine developers intuitively thinking they should be able to load external data with <script> if they can do it inline with <script>

[04:54:46.0000] <annevk>
MikeSmith: yeah, I guess that seems fine; seems like you've encountered some folks that wonder about this 😃

[08:04:10.0000] <dtapuska>
@annevk Do you think you could review https://github.com/whatwg/fetch/pull/853 ? What are your feelings of getting this merged? Right now our I2S is blocked on it getting merged.

[08:10:27.0000] <annevk>
dtapuska: I can take a look now

[08:31:17.0000] <annevk>
dtapuska: done

[08:38:41.0000] <annevk>
Also, thanks a lot JakeA for the help with that PR!

[08:46:21.0000] <annevk>
dtapuska: I haven't checked yet, but tests and impl bugs are also needed

[08:46:33.0000] <annevk>
dtapuska: filed https://github.com/mozilla/standards-positions/issues/144 to see what other Mozillians think about this

[09:29:00.0000] <dtapuska>
annevk: I've fixed your comments (I hope) and added the impl bug links.. tests are already upstreamed as tentative in wpt

[09:29:54.0000] <annevk>
dtapuska: thanks, another blocker on merging is that we need two impl that are interested; did you already talk with Apple or Mozilla folks?

[09:33:32.0000] <annevk>
dtapuska: https://whatwg.org/working-mode#changes for reference

[09:42:25.0000] <dtapuska>
annevk: everyone has been silent. The TAG review didn't have any comments really, no comments on our PR other than from you. Who from Mozilla can give us an answer if this is something they will pursue?

[09:43:40.0000] <annevk>
dtapuska: the standards-positions thing I linked above is prolly your best bet

[09:43:55.0000] <annevk>
dtapuska: though perhaps the networking folks have better contacts

[09:50:42.0000] <Domenic>
annevk: jeez this discarding windows thing is such a deep hole of sadness you've found

[09:51:58.0000] <dtapuska>
annevk: thanks... I've fixed the remaining comments you made. I hope that the mozilla standards position gets some activity.

[10:01:56.0000] <annevk>
Domenic: these latest two issues I don't mind so much, we already needed a "closed" state soonish anyway and nulling opener browsing context seems good for memory usage

[10:02:15.0000] <annevk>
Domenic: but yeah, more work

[10:02:55.0000] <annevk>
Domenic: but I've know some of this for a while, it's the "lifetime" thing I still think we do quite poorly on

[11:48:27.0000] <annevk>
At least, I suspect we’ll continue to unearth bugs around bc document creation and unloading


2019-03-13
[18:25:33.0000] <Domenic>
annevk: found this old related issue https://github.com/whatwg/html/issues/2579

[03:55:28.0000] <MikeSmith>
annevk: where does the fetch spec normatively state the requirement that CORS requests can only have the http/https protocol scheme?

[04:12:27.0000] <annevk>
MikeSmith: in main fetch it might be somewhat implicitly stated

[04:13:19.0000] <annevk>
yoav: I’d be interested in learning more about the issues with squashing

[04:13:25.0000] <annevk>
jyasskin: ^^

[04:17:10.0000] <MikeSmith>
annevk: yeah thinking about it more I realize that the protocol can‘

[04:17:15.0000] <MikeSmith>
oofs

[04:17:55.0000] <MikeSmith>
*can’t work unless the response can include HTTP headers

[04:30:11.0000] <annevk>
MikeSmith: well, Fetch does have this abstraction where all responses have headers and such

[04:30:23.0000] <annevk>
MikeSmith: so assuming there's some suitable mapping, it's all good

[04:30:52.0000] <annevk>
MikeSmith: but Fetch also safelists schemes, so it's not all good

[04:52:20.0000] <MikeSmith>
annevk: I see. But there’s no way for a non-HTTP(S) server to add an Access-Control-Allow-Origin response header to a response, right? So regardless of the abstraction the spec, and non-HTTP(S) server can’t use the CORS protocol (to get browsers to relax the same-origin policy), right?

[04:59:44.0000] <annevk>
MikeSmith: is this theoretical or practical?

[05:08:02.0000] <MikeSmith>
annevk: practical; part of the context is, until today the MDN article on XHR contained a statement saying that ftp URLs could be used with the XHR API

[05:09:48.0000] <MikeSmith>
I removed that. But it occured to me that it would be helpful to have a clear explanation of why ftp requests can’t be made cross-orgin

[05:11:03.0000] <annevk>
MikeSmith: I think that's technically possible though

[05:11:22.0000] <annevk>
MikeSmith: if you get an ftp response sniffed as an HTML document that could then execute script to fetch something from the same server

[05:11:28.0000] <annevk>
MikeSmith: no CORS needed

[05:12:11.0000] <annevk>
(now some of these things might have gotten restricted over the years, I'm not exactly sure where we are at with FTP deprecation)

[05:12:34.0000] <annevk>
Domenic: that BarProp thing turns out to be a gigantic nerd-snipe

[05:18:59.0000] <MikeSmith>
annevk: I see. But nowadays CORB would anyway block an ftp response sniffed as an HTML document, right? So in practice it seems the gist of is that a cross-origin ftp request is just not gonna work in modern browsers ー though I guess maybe it could still work in some older browsers

[05:19:48.0000] <yoav>
annevk: For smaller PRs, I don't think squashing is a major concern, but once features become larger, loss of history once they get merged can be a problem. I know jyasskin was worried about that when it comes to SXG and Fetch integration

[05:23:43.0000] <annevk>
MikeSmith: I don't see why CORB would be at play here

[05:24:29.0000] <annevk>
yoav: there's something to that concern, I suspect

[05:25:49.0000] <annevk>
yoav: in such cases we've used pointers to the incubation repo in the past

[05:49:29.0000] <yoav>
annevk: Sure, but if all incubation happens on someone's Fetch repo GH fork, that's a bit weird

[05:55:40.0000] <yoav>
Is there a way for incubation to happen elsewhere without monkeypatching? I was thinking we could land hooks into the various related algorithms before we have consensus, and then be able to keep the logic in a separate doc, while not putting any processing into the WHATWG spec that don't have 2 vendor agreement

[06:04:24.0000] <annevk>
That doesn't sound acceptable to me

[07:56:36.0000] <yoav>
annevk: what part of it doesn't sound acceptable? Adding the hooks?

[07:58:33.0000] <annevk>
yoav: yeah, that's not materially different to a change to the standard

[09:01:40.0000] <jyasskin>
yoav/annevk: I'm missing some context here, but guessing: I was worried about maintaining SXG's fetch integration as a PR because it's just difficult to maintain long-lived topic branches, both because of merges and because I want review for changes to the fetch integration.

[09:01:44.0000] <jyasskin>
Losing the history after the merge wasn't my primary concern, and actually, that history's more likely to get lost from a monkeypatch merge than a long-lived PR merge.

[09:17:10.0000] <jyasskin>
annevk: Unrelated, our loading team is looking at implementing Bundles, but I haven't yet 1) finished what I think will be the final format or 2) written down how it integrates with Fetch and Service Workers. Clearly we won't *ship* before those are done, but how sad is it going to make Mozilla if we *implement* early?

[09:20:14.0000] <annevk>
jyasskin: ship is what folks care about afaik

[09:20:25.0000] <jyasskin>
annevk: Thanks.

[09:47:50.0000] <annevk>
Unicode might move to GitHub? Or only CLDR?

[10:07:32.0000] <jyasskin>
yoav/annevk: Oh! I've found the email: https://groups.google.com/a/chromium.org/d/msg/blink-dev/rspPrQHfFkI/B5vWGNhvCQAJ. I think the question of whether not-yet-merged features should live in PRs or in monkeypatches in a separate specification document, is orthogonal to the main question in that thread, which seems to be about when to ship at all.

[10:14:27.0000] <jyasskin>
annevk: Ignoring the political question of when to ship, I think I'm making the right tradeoff in https://wicg.github.io/webpackage/loading.html to let us review changes as we refine the design.

[13:19:09.0000] <annevk>
Domenic: I don't think we can remove global object reuse

[13:19:27.0000] <Domenic>
annevk: I was hoping minimize the number of cases it shows up, e.g., maybe for iframes

[13:19:34.0000] <annevk>
Domenic: for window.open("/common/blank.html") I'm pretty sure the document changes and the global stays the same

[13:19:37.0000] <annevk>
Domenic: I see

[13:20:01.0000] <Domenic>
I guess it's debatable whether minimizing in the way I propose makes things more or less complex


2019-03-14
[19:46:40.0000] <Domenic>
foolip: wiki cert expiration fired; not sure auto-renew is working right. https://travis-ci.org/whatwg/misc-server/builds/506086299

[19:55:18.0000] <MikeSmith>
Domenic: I will also look into it myself right now

[19:55:29.0000] <Domenic>
Thank you!!

[20:07:51.0000] <MikeSmith>
hmm, “You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry” ..

[20:08:51.0000] <MikeSmith>
expiry on all the certs is June 3, 2019

[20:10:05.0000] <MikeSmith>
so now I am confused why those “certificate expiry date” errors in our Travis are saying

[20:15:00.0000] <MikeSmith>
coming from https://github.com/whatwg/misc-server/blob/master/test/certs.js#L73

[20:15:45.0000] <MikeSmith>
but that doesn’t actually seem to be throwing..

[20:26:40.0000] <MikeSmith>
ah I see, it’s just wiki.whatwg.org that it’s reporting

[20:27:04.0000] <MikeSmith>
> 1) certificate expiry date wiki.whatwg.org:Error: cert expires in less than 25 days: Apr  7 23:05:46 2019 GMT

[21:07:02.0000] <MikeSmith>
Domenic: https://travis-ci.org/whatwg/misc-server/builds/506086299 all green now

[21:08:09.0000] <MikeSmith>
I manually ran cerbot renew on the wiki.whatwg.org host. I couldn’t figure out if we have automation set up for renewing that one. Looking into that will need foolip I reckon

[06:29:53.0000] <Ms2ger>
Domenic, ping https://github.com/heycam/webidl/pull/684

[06:30:50.0000] <Ms2ger>
annevk, ping https://github.com/heycam/webidl/pull/666

[07:46:25.0000] <annevk>
ugh Domenic

[07:46:34.0000] <annevk>
browsers are not consistent between srcdoc and non-srcdoc

[07:46:39.0000] <annevk>
so much to test

[07:46:55.0000] <annevk>
How did all these features land to begin with?

[09:42:38.0000] <annevk>
Domenic: thanks for adding those comments to standards-positions \o/

[09:42:44.0000] <Domenic>
:)

[09:55:20.0000] <nox>
que

[09:55:31.0000] <nox>
Utter focus fail, disregard me.

[10:24:03.0000] <annevk>
nox: do you know why https://github.com/web-platform-tests/wpt/pull/15844 removed a test? No rationale in upstream PR

[10:25:01.0000] <nox>
annevk: No damn clue.

[10:56:56.0000] <annevk>
nox: interested in chasing that? That reminds me. Your stuff should really get some attention. I want that script queue thing in

[10:57:26.0000] <annevk>
/me sets a reminder to look at that again

[10:59:07.0000] <nox>
annevk: Domenic commented and Manish replied, on the Servo PR.

[10:59:22.0000] <annevk>
Ah

[10:59:25.0000] <nox>
annevk: I was too absorbed by some fancy Rust stuff I did last week and didn't come back to the spec stuff.

[10:59:31.0000] <nox>
Will try to do that next week.

[10:59:37.0000] <Domenic>
I guess I should have said anything, but I'm never sure when you European folk sleep

[10:59:48.0000] <Domenic>
s/anything/something/

[11:00:04.0000] <Domenic>
(So, I thought I'd just comment myself and save you the trouble.)

[11:00:07.0000] <nox>
Domenic: Don't worry, if you ping me and I don't want to reply, I'll just ignore the ping with all my French smugness.

[11:00:26.0000] <Domenic>
something something baguettes

[11:01:48.0000] <nox>
Domenic: That actually highlights me too. 😂

[13:33:34.0000] <annevk>
Domenic: if you have time it'd be nice if you could give a final look at https://github.com/w3c/FileAPI/pull/118

[13:33:47.0000] <annevk>
Domenic: last round of nits was just addressed

[13:34:28.0000] <Domenic>
Sure

[14:06:24.0000] <Mek>
thanks for all the quick and thorough reviews

[14:10:24.0000] <Domenic>
Thank you for the heroic maintenance

[14:21:21.0000] <annevk>
Indeed, fishd will be happy

[14:27:17.0000] <Mek>
Domenic: any samples of specs that properly use internal slots for their interface attributes? I keep wanting to do so, but I'm never sure what the canonical way to define them is, so I just keep waiting for the webidl PR that makes it easier to land but that seems to keep stalling as well...

[14:29:21.0000] <Domenic>
Mek: https://dom.spec.whatwg.org/#interface-abortcontroller and the nearby AbortSignal are pretty solid.

[14:30:21.0000] <Mek>
Ah, yes. That's pretty straight forward. Thanks.


2019-03-15
[01:26:29.0000] <yoav>
annevk: Hey! Trying something out to see if we can reasonably show long-standing PR diffs in a reasonable way. Is there a way to "auto collapse" the commit-snapshot warning?

[01:41:52.0000] <annevk>
yoav: no

[01:42:13.0000] <yoav>
It is OK if I add something like that?

[01:42:27.0000] <annevk>
I don't think so, that design is quite intentional

[01:44:55.0000] <yoav>
I understand why that design is the way it is, but want to show the diff in a concise way, so want iframes showing bits and pieces of it

[01:45:15.0000] <yoav>
having to click collapse on every iframe would defeat the purpose

[01:46:23.0000] <annevk>
If we provided a workaround, how would that not open us to abuse?

[01:46:34.0000] <yoav>
I guess I could drive the same with JS

[01:46:46.0000] <yoav>
nm

[02:49:16.0000] <yoav>
annevk: would you be comfortable with a postMessage based mechanism that tells the preview to scroll to a certain anchor?

[02:49:43.0000] <yoav>
changing the src from the outside seems to trigger a new navigation

[02:50:03.0000] <yoav>
(at least in my initial testing. Maybe there's a way around that)

[02:51:41.0000] <yoav>
that's wasteful + after a certain point I'm getting 403s, presumably for requesting the same preview too many times

[02:52:44.0000] <annevk>
yoav: it'd be helpful to have an issue somewhere with a problem description or some such

[02:53:22.0000] <yoav>
sure, but wondered what your initial thoughts would be before I go to fully document it

[02:55:36.0000] <annevk>
yoav: somewhere between maybe and wondering if we need X-Frame-Options: deny 😊

[02:56:07.0000] <yoav>
my immediate goal is to make PRs like https://github.com/whatwg/fetch/pull/773 and https://github.com/whatwg/html/pull/3774 more comprehensible to casual reviewers

[02:57:06.0000] <yoav>
So I won't need to create a separate monkey patching document

[02:58:26.0000] <yoav>
so I'm trying to create a document which frames the PR preview, talks about what each change in it does and when the user clicks on a link, I want the PR preview to scroll to the relevant section

[02:59:08.0000] <yoav>
I can open an issue, but not 100% sure where that issue should go to. Fetch? HTML? PR preview?

[02:59:51.0000] <annevk>
yoav: https://github.com/whatwg/whatwg.org I suspect

[03:00:27.0000] <yoav>
ok

[03:00:39.0000] <annevk>
yoav: it's not possible to explain the set of changes and link to them?

[03:01:25.0000] <yoav>
It's possible, but will force the person doing the casual reviewing to hop back and forth between the explanation and the spec language

[03:01:48.0000] <yoav>
having both side by side seems better

[03:16:35.0000] <yoav>
annevk: https://github.com/whatwg/whatwg.org/issues/241

[06:58:08.0000] <annevk>
nox: so for <script> Chrome and Firefox presumably only disagree on details?

[06:58:21.0000] <annevk>
nox: as both have the defer mechanism

[06:58:40.0000] <nox>
annevk: Seems like a huge detail to me.

[06:58:54.0000] <annevk>
nox: I guess I can run the tests

[06:59:03.0000] <nox>
annevk: If you insert 2 scripts and modify the second from the first,

[06:59:12.0000] <nox>
the second will be executed at the time it is modified in Chrome,

[06:59:31.0000] <nox>
whereas in Firefox it will not execute immediately.

[06:59:40.0000] <nox>
annevk: I described what FIrefox does in a comment, let me find it.

[06:59:51.0000] <nox>
annevk: https://github.com/whatwg/html/pull/4354#issuecomment-463566900

[10:08:00.0000] <annevk>
nox: okay, is either solution better in some way?

[10:08:26.0000] <annevk>
nox: the Firefox solution seems a little cleaner in that original ordering is preserved

[10:09:33.0000] <nox>
annevk: I personally prefer the Chrome behaviour because it’s more in line with what I expected.

[10:10:45.0000] <annevk>
nox: are there any tradeoffs you see?

[10:11:00.0000] <annevk>
nox: if it's just edge cases I don't care strongly I suppose

[10:11:06.0000] <annevk>
nox: maybe I should run your stuff in Safari

[10:11:20.0000] <nox>
annevk: It’s only ever exhibited in rare edge cases yeah.

[10:12:23.0000] <nox>
annevk: Safari doesn’t defer anything AFAIK, especially with fragments given it inserts children separately as if you had called insertBefore repeatedly yourself.

[10:13:55.0000] <annevk>
Yeah, Safari seems out there with these tests

[10:14:59.0000] <annevk>
nox: a problem I have with reviewing is that the alternatives are not written down in one place, so it's hard to judge things

[10:15:07.0000] <nox>
annevk: I’m also not sure what happens if you insert two scripts and the first removes the second in Firefox

[10:15:16.0000] <annevk>
nox: tkent wrote some changes down, but they don't really concern what Chrome does with respect to script insertion

[10:15:36.0000] <annevk>
nox: I'd epxect the second to not execute based on what I know

[10:15:37.0000] <nox>
Specifically, is the already-started flag reset?

[10:16:36.0000] <nox>
Ah never mind yeah it will be cleared out ultimately given it’s not removed from the queue of deferred things.

[10:29:42.0000] <annevk>
nox: so is "text content changed" misleadingly named? What you set node.data only?

[10:30:29.0000] <nox>
I don't understand the second question and it's Friday evening so I don't really want to think about the first one hah.

[10:31:53.0000] <annevk>
It's not misleadingly named, it's also called when you set node.data

[10:32:05.0000] <devsnek>
interesting api from node: https://github.com/nodejs/node/pull/26686

[10:32:17.0000] <annevk>
Could still be a single "children changed" callback though

[10:40:25.0000] <nox>
annevk: AFAIK inserting non-Text nodes in a style doesn't reset the stylesheet.

[10:42:14.0000] <annevk>
Yeah, I think Domenic tested this too perhaps; I wonder what browsers do in that case, have some kind of filter

[10:42:50.0000] <annevk>
A thing they might do is simply compare input to the parser to previous input and return early, though it seems somewhat wasteful to keep all of that around

[10:43:17.0000] <annevk>
/me goes to look for tests

[10:49:39.0000] <annevk>
Hmm, so when the concept was added to DOM no tests were added because only textarea was considered at the time

[10:49:52.0000] <annevk>
So whether node.normalize() affects <style> is unclear

[10:52:44.0000] <annevk>
And per https://github.com/whatwg/html/pull/3024 we did not add tests when this was also adopted by <style>

[10:52:46.0000] <devsnek>
what is importing html supposed to do

[10:53:01.0000] <annevk>
Okay, at least that makes it clear what needs to be done

[10:53:02.0000] <devsnek>
from the explainer it looks like content is an element and default is a vdom?

[10:53:20.0000] <annevk>
devsnek: HTML modules?

[10:53:25.0000] <devsnek>
yeah

[10:53:40.0000] <annevk>
devsnek: it's a fancy xhr.responseXML

[10:54:02.0000] <devsnek>
aha

[10:54:04.0000] <devsnek>
thank you

[10:54:29.0000] <annevk>
I'm surprised that worked 😊

[10:55:51.0000] <devsnek>
annevk: i was just trying to figure out if html modules would be affected by the (non)existence of top level await

[11:05:46.0000] <annevk>
nox: I created the most basic test

[11:05:55.0000] <annevk>
nox: inserting a comment node into a <style>

[11:06:00.0000] <annevk>
nox: sheet changed

[11:08:37.0000] <nox>
Ah, then I don't remember why I kept the distinction.

[11:09:24.0000] <annevk>
https://github.com/web-platform-tests/wpt/pull/15871

[11:09:34.0000] <nox>
annevk: Oh, the opposite.

[11:09:59.0000] <annevk>
I might add some more tests next week, but I'm convinced now that we should only have "children changed" and not both of these concepts

[11:12:39.0000] <nox>
I'm pretty sure I kept it for a reason but I could be wrong.

[11:14:09.0000] <nox>
annevk: Ah now I remember.

[11:14:24.0000] <nox>
annevk: The text content changed stuff is also called when changing Text nodes' contents and whatnot,

[11:14:37.0000] <nox>
annevk: changing the contents of a Text node in a script element doesn't do anything to the script element.

[11:15:56.0000] <nox>
script doesn't define any "child text content change steps", but it does say to prepare it whenever "The script element is connected and a node or document fragment is inserted into the script element, after any script elements inserted at that time."

[11:18:05.0000] <annevk>
nox: interesting, I want to see if we can change that if true or perhaps we can make that a parameter

[11:18:32.0000] <nox>
annevk: Meh, I would rather avoid ad-hoc use-once boolean parameters.

[11:19:23.0000] <annevk>
nox: I’d much rather avoid two subtly different callbacks with one only used once

[11:19:39.0000] <nox>
I wouldn't call the difference subtle at all.

[11:20:28.0000] <nox>
Not sure what you mean by "used only once" though.

[11:21:40.0000] <annevk>
nox: for scripts

[11:21:55.0000] <annevk>
nox: it’d be good to see that test though

[11:23:31.0000] <annevk>
And please don’t cite the current spec in support of anything as impls are all over 😊

[11:34:08.0000] <nox>
I'm pretty sure I verified the thing about changing a text child, but yeah didn't write a test.

[11:34:45.0000] <TabAtkins>
Where's the statement in HTML that UAs are allowed to fail due to resource constraints whenever they want?

[11:38:38.0000] <TabAtkins>
Eh, nm, I just cited it as a general principle instead.

[12:17:41.0000] <Domenic>
TabAtkins: https://html.spec.whatwg.org/#killing-scripts at least if you're talking about running scripts

[12:21:46.0000] <TabAtkins>
That is indeed what I was looking for, but I didn't realize it was so limited to just scripts.

[12:23:56.0000] <Domenic>
Yeah I couldn't find anything more general. It might be hiding, but I Ctrl+F'ed "constraints" and "resources" and didn't see anything early in the spec

[12:25:03.0000] <TabAtkins>
Asking here too, as w3c#testing is quiet right now: how do you test something that's just "don't let me do X enough times to make the browser crash"?

[12:26:39.0000] <TabAtkins>
(Context is a Billion-Laughs attack via CSS variables; the spec now mandates that browsers must protect themselves from it, but doesn't specify a specific maximum length.)

[12:28:31.0000] <Domenic>
TabAtkins: I think you write a test with no asserts and if it crashes the harness/infra will call that a failure. If it doesn't crash then a no-assert test is a pass.

[13:14:26.0000] <annevk>
TabAtkins: Infra might say that? About resource limits

[14:30:50.0000] <TabAtkins>
Domenic: Thanks, https://github.com/web-platform-tests/wpt/pull/15875 is committed now, and does indeed crash/fail in Chrome. ^_^

[14:31:23.0000] <Domenic>
Amazing

[14:31:37.0000] <astearns>
that's a good test :)

[15:43:19.0000] <TabAtkins>
Domenic: FYI, apparently a vacuous test without an assert is *not* a pass; it just times out and counts as a failure.

[15:45:43.0000] <Domenic>
TabAtkins: I said "without asserts", not "without tests" :)

[15:45:52.0000] <Domenic>
(I certainly could have been clearer)

[15:45:54.0000] <TabAtkins>
Bah!

[15:45:56.0000] <TabAtkins>
^_^

[15:50:47.0000] <Mek>
well, you don't need explicit tests or asserts, you just need to call done() if you have neither (https://web-platform-tests.org/writing-tests/testharness-api.html#single-page-tests)


2019-03-17
[12:12:53.0000] <innovati>
Other than the rules for parsing, and which characters must be escaped, is there any difference between using double-quoted, single-quoted, or unquoted attribute values in HTML?

[12:29:29.0000] <gsnedders>
innovati: no

[12:38:39.0000] <innovati>
thanks <3

[12:39:15.0000] <innovati>
is any one of those the the initial way it's attempted to be parsed, or is that up to implementors what order they might try those?

[12:40:24.0000] <gsnedders>
innovati: there's no initial attempt, it's a single parse with no lookahead: the first non-whitespace character after the = determines it (if it's " it's double quoted, if it's ' it's singled quoted, otherwise it's unquoted)

[12:41:24.0000] <innovati>
thanks! that makes sense


2019-03-18
[02:41:11.0000] <annevk>
JakeA: did bypassing the SW go anywhere yet?

[02:41:27.0000] <annevk>
JakeA: I'm a little worried about its interaction with CSP and Fetch

[02:41:35.0000] <annevk>
JakeA: did you'll think that through?

[02:41:55.0000] <annevk>
Aside: is you all even you'll? I guess not.

[02:42:45.0000] <annevk>
Ah, y'all

[03:16:36.0000] <Ms2ger>
Ah, what a weird set of contractions we've.

[03:20:42.0000] <Ms2ger>
annevk, do you have a moment to review https://github.com/heycam/webidl/pull/688 ? It should avoid the confusing "Parsing grammar in JS-format failed: %%" errors

[03:24:45.0000] <annevk>
Ms2ger: done

[03:26:10.0000] <Ms2ger>
annevk, thx

[03:30:17.0000] <Ms2ger>
(I really don't want to look at that curlbikeshed shell script :))

[05:36:07.0000] <annevk>
Ms2ger: it handles a bunch of cases this doesn’t

[06:34:13.0000] <annevk>
JakeA: in particular, https://github.com/mikewest/sec-metadata/issues/16#issuecomment-473911568 is what I'm concerned about

[07:03:03.0000] <annevk>
nox: I created a bunch more tests for script insertion

[07:03:11.0000] <annevk>
nox: browsers are a lil weird

[07:16:22.0000] <annevk>
nox: I also feel like I'm losing grip on the correct solution the more I think about edge cases 😟

[07:16:49.0000] <annevk>
nox: the separate queue really creates a bunch of weird cases

[07:16:55.0000] <nox>
Like what?

[07:17:26.0000] <annevk>
nox: you insert script1 and script2, script1 modifies script2 by inserting script3

[07:17:40.0000] <annevk>
nox: and then maybe script3 removes script1 from the tree or some such

[07:18:01.0000] <nox>
[ script1 [ script3 [ script2 ] ] ]

[07:18:10.0000] <nox>
I don't find that weird.

[07:18:28.0000] <annevk>
I'm not sure I get the visual representation

[07:18:41.0000] <annevk>
Removing script1 from the tree would be a no-op, come to think of it

[07:18:48.0000] <nox>
[ /* script1 starts here */ script1 /* script1 stops here */ ]

[07:19:21.0000] <nox>
script1 inserts script3 which immediately gets prepared, which modifies script2 which immediately gets prepared after the modification, control goes back to script3, control goes back to script1

[07:21:08.0000] <annevk>
nox: so Chrome does script2 first, then script3

[07:21:39.0000] <annevk>
nox: Safari does [script1] [script2] [script3]

[07:21:41.0000] <nox>
Do you have a Live DOM Viewer link to exhibit that? I thought I had checked that case but apparently I didn't. :(

[07:21:55.0000] <annevk>
nox: https://github.com/web-platform-tests/wpt/pull/15886 last test

[07:22:41.0000] <nox>
ETOOMANYPUNCTUATIONSIGNS

[07:23:01.0000] <annevk>
nox: I was trying to figure out what primitives the DOM needs to provide per my comment on the DOM PR

[07:23:20.0000] <annevk>
nox: I still think it's feasible to only offer "children changed" without modifying parameter

[07:25:36.0000] <nox>
annevk: Mmh…

[07:25:48.0000] <nox>
annevk: I see script3 before script2 in Safari.

[07:25:57.0000] <nox>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6774

[07:26:13.0000] <nox>
Damn,

[07:26:14.0000] <annevk>
nox: are you using Safari TP?

[07:26:15.0000] <nox>
wrong link.

[07:26:29.0000] <nox>
annevk: Ah, no.

[07:26:35.0000] <nox>
And it was the correct link nevermidn.

[07:26:38.0000] <annevk>
nox: doesn't matter for me

[07:26:50.0000] <nox>
annevk: I see script3 before script2 in Firefox too.

[07:27:04.0000] <annevk>
In Safari I have "Gotten order: 1,3,2,4"

[07:27:10.0000] <nox>
And in Chrome.

[07:27:15.0000] <nox>
Yes, same here.

[07:27:19.0000] <annevk>
In Chrome I have "Gotten order: 1,2,4,3"

[07:27:23.0000] <nox>
I don't.

[07:27:30.0000] <annevk>
Chrome Canary?

[07:27:39.0000] <nox>
Chrome 72

[07:27:50.0000] <annevk>
This is 75

[07:28:17.0000] <nox>
So Chrome got broken is what you mean :)

[07:29:14.0000] <annevk>
nox: I don't see why that means script3 before script2 though

[07:29:31.0000] <nox>
Not sure what you mean.

[07:29:42.0000] <annevk>
nox: 4 is from "script3"

[07:29:59.0000] <nox>
script3.textContent = 'w(3); script2.textContent += "w(4)";';

[07:30:38.0000] <nox>
Ah I see what you mean, just a sec.

[07:30:43.0000] <annevk>
Oh, you're talking about your test

[07:31:13.0000] <annevk>
For your test Chrome and Safari do not differ indeed

[07:31:28.0000] <annevk>
Seems like it's not an equivalent test

[07:32:19.0000] <nox>
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=6776

[07:33:02.0000] <nox>
This ends with "log: script3 ends" in my Chrome, I don't have Canary, will install it later.

[07:34:30.0000] <annevk>
nox: same here, but not in Safari

[07:36:25.0000] <annevk>
Firefox and Safari seem equal for that one though...

[07:40:32.0000] <annevk>
nox: I guess if you re-insert script2 during script1 it'll run at that point too? and then because it's already-run flag or whatever is set it won't execute when it's dequeued from the initial queue?

[07:41:10.0000] <nox>
annevk: Yeah that's what Chrome does, whereas Firefox sets already-started at queue time, so later mutations don't requeue it.

[07:41:35.0000] <annevk>
nox: but Firefox does not do that when the contents are the empty string

[07:41:37.0000] <annevk>
okay

[07:42:16.0000] <annevk>
Chrome also does something weird for append() vs append(new Text())

[07:45:03.0000] <annevk>
nox: okay, so we need to make a decision on 1) when do we set already-started 2) how many children change variants do we distinguish between

[07:46:33.0000] <nox>
annevk: So I finally know now why I think Chrome's behaviour wrt reentrancy (a script modifying another script which has been queued for preparation),

[07:46:54.0000] <nox>
it's because that's how reentrancy is handled in many Rust libs hah.

[07:47:08.0000] <nox>
I forgot a whole sentence in there,

[07:47:15.0000] <nox>
So I finally know now why I think Chrome's behaviour wrt reentrancy (a script modifying another script which has been queued for preparation) makes more sense to me,*

[07:55:34.0000] <annevk>
nox: it's still not really clear to me what the inputs are to be

[07:55:59.0000] <annevk>
nox: e.g., removing a node from the script doesn't change its execution order, but appending or changing a node might

[07:56:06.0000] <annevk>
nox: that just does not make much sense?

[08:29:13.0000] <smaug____>
annevk: dom spec doesn't have the weird case for nested form element event dispatch, right?

[08:29:16.0000] <smaug____>
or am I missing something

[08:29:38.0000] <smaug____>
hmm, perhaps it is actually in HTML spec... /me looks

[08:31:37.0000] <smaug____>
can't find

[08:37:03.0000] <annevk>
smaug____: there's a flag in the form submission algorithm that was added as part of the formdata event

[08:38:38.0000] <smaug____>
annevk: is that used also for submit event?

[08:39:02.0000] <smaug____>
so that event dispatch stops during bubble phase so that outer form element doesn't get submit

[08:39:23.0000] <smaug____>
I couldn't immediately find a spec issue, but this has been discussed somewhere

[08:41:00.0000] <annevk>
smaug____: ooh that

[08:41:39.0000] <annevk>
smaug____: that's https://github.com/whatwg/html/issues/3599

[08:41:58.0000] <smaug____>
that one, yes, thanks

[09:10:33.0000] <zcorpan>
is it intentional that :defined matches HTMLUnknownElement without dashes in the name e.g. foobar ?

[09:12:52.0000] <annevk>
zcorpan: I think so

[09:13:54.0000] <zcorpan>
annevk: ok

[16:10:11.0000] <MikeSmith>
I see Ian Fette is a Slack now

[16:10:18.0000] <MikeSmith>
https://www.linkedin.com/in/ianfette/

[16:10:31.0000] <MikeSmith>
Senior Director Of Engineering at Slack

[16:10:37.0000] <MikeSmith>
> Running the Search and Discovery team, and growing the NYC office


2019-03-19
[07:37:23.0000] <annevk>
Domenic: do you understand deliveryInProgress at https://trac.webkit.org/browser/trunk/Source/WebCore/dom/MutationObserver.cpp#L259?

[07:37:40.0000] <annevk>
Domenic: is that all compound microtasks really mean?

[08:04:32.0000] <Domenic>
annevk: it seems to prevent reentrancy

[08:04:58.0000] <Domenic>
Unclear how it maps to spec concepts

[08:05:20.0000] <annevk>
Domenic: I've done some digging and we can get rid of compound microtasks, pretty sure

[08:05:42.0000] <Domenic>
I mean I think we could but I'm unsure whether the replacement would just be the same thing in different words, or actually simpler.

[08:05:43.0000] <annevk>
Domenic: I still don't understand that deliveryInProgress entirely though as it's initialized to false and then checked if it can be true

[08:05:48.0000] <Domenic>
It's a `static`

[08:05:57.0000] <Domenic>
So it's only initialized the first time the function is called

[08:06:05.0000] <annevk>
Ah thanks

[08:06:29.0000] <Domenic>
https://www.tutorialspoint.com/cplusplus/cpp_static_members.htm second section

[08:06:50.0000] <Domenic>
wait no that's not it

[08:06:58.0000] <Domenic>
https://www.geeksforgeeks.org/static-keyword-cpp/

[08:07:44.0000] <annevk>
Thanks, removed my question from GitHub

[08:08:30.0000] <Domenic>
Also the interaction with "spin the event loop" seems complicated :/

[08:08:57.0000] <annevk>
Domenic: I suspect it directly relates to https://dom.spec.whatwg.org/#queue-a-mutation-observer-compound-microtask

[08:09:24.0000] <annevk>
Domenic: I've worked that through, that was added because of an obsolete dialog API that could spin the event loop

[08:09:33.0000] <annevk>
Domenic: as far as I can tell there's no API today that can trigger spin the event loop

[08:09:40.0000] <Domenic>
Wat

[08:09:44.0000] <annevk>
Domenic: so we don't have to worry about that, patch coming up

[08:10:22.0000] <Domenic>
I guess alert() maybe, we have a note saying that spinning the event loop is less bad than pausing IIRC

[08:11:42.0000] <annevk>
Domenic: no, that's not the case

[08:11:50.0000] <annevk>
Domenic: that'd be bad

[08:12:02.0000] <annevk>
we allow early returning

[08:12:45.0000] <Domenic>
https://html.spec.whatwg.org/multipage/webappapis.html#pause

[08:13:12.0000] <Domenic>
That was added at bz's request


2019-03-20
[05:23:26.0000] <JakeA>
annevk: Catching up on the CSP thing. I'm not sure I understand the problem. When you make a request from a page, the CSP is checked before the request goes to the service worker, but the response is also checked against the original request. The destination is taken from the original request, so service worker can't tamper with it

[05:31:00.0000] <annevk>
JakeA: the concern is about routing something into a cache

[05:47:49.0000] <JakeA>
annevk: I can't figure out the attack. <img> -> service worker -> fetch() -> cache… but if a response is later pulled from the cache it'll still be CSP checked

[05:49:38.0000] <annevk>
JakeA: so in that setup the fetch() uses SW's CSP

[05:50:13.0000] <annevk>
JakeA: but would it still consult that SW's CSP if it uses routing to bypass invoking the SW?

[05:50:56.0000] <annevk>
JakeA: I think I managed to convince myself that using the document's CSP is sufficient, since both the document and the SW can pollute the cache, but it's still a little surprising

[05:51:07.0000] <annevk>
JakeA: the referrer would also be different and there might be other subtle things going on too

[05:51:35.0000] <annevk>
JakeA: perhaps routing isn't a thing yet though, I don't really know the state of things

[05:52:42.0000] <JakeA>
annevk: as in the static routes proposal? That's a good question. Using the service worker's CSP would make things more consistent, especially with static route polyfills, but I like the idea of just using the document's CSP since it's all behind the scenes anyway. But yeah, it isn't enough of a thing yet to worry too much about

[05:54:12.0000] <annevk>
JakeA: okay

[05:54:38.0000] <annevk>
thanks

[06:08:55.0000] <yoav>
annevk: I'm wondering what's the best path forward for CH and a `Sec-` prefix, which we discussed in https://github.com/whatwg/fetch/pull/880

[06:31:55.0000] <annevk>
yoav: I'm not sure, I kinda wonder what media elements do for Range when crossorigin is set

[06:32:14.0000] <annevk>
yoav: JakeA might be onto something that following Range is the way to go, but what Range does is not fully clear

[06:33:05.0000] <JakeA>
They would trigger a preflight right?

[06:33:53.0000] <annevk>
JakeA: my suspicion is that browsers don't

[06:34:14.0000] <annevk>
JakeA: and that the treat Range as privileged because they initiated the range request

[06:34:29.0000] <annevk>
JakeA: similar to EventSource's Last-Event-ID

[06:34:36.0000] <JakeA>
annevk: Interesting. I think Chrome does if it goes via a service worker, so I guess that needs fixing somehow.

[06:37:24.0000] <yoav>
JakeA: can you expand on what you had in mind? Do we want to add specific CH headers as privileged? All `Sec-` prefixed headers as privileged?

[06:37:56.0000] <yoav>
And if they are privileged, does that mean that SW can copy them from the incoming Request without breaking them?

[06:38:23.0000] <yoav>
s/copy them/forward the incoming request to fetch()/

[06:43:50.0000] <annevk>
Domenic: https://github.com/whatwg/html/issues/4400#issuecomment-474827602 what if the network hangs for multiple seconds after the first </script>?

[06:44:10.0000] <annevk>
Domenic: seems that would result in multiple tasks from the parser to manipulate the tree

[06:44:36.0000] <Domenic>
annevk: not as currently specced for HTML modules, but, maybe that's thing to raise with the MS folks about their spec?

[06:44:49.0000] <annevk>
Domenic: ooh, inside an HTML module

[06:45:01.0000] <annevk>
Domenic: my bad

[06:45:10.0000] <annevk>
Domenic: no that seems like the right semantics for HTML modules

[06:51:23.0000] <JakeA>
yoav: Is the intent that `Sec-` headers should pass through a service worker as long as the request isn't modified? And `Sec-` headers shouldn't trigger a preflight unless it was manually set by the developer (or is this forbidden?)

[06:51:43.0000] <yoav>
they are forbidden

[06:51:50.0000] <JakeA>
Is the rest correct?

[06:52:08.0000] <yoav>
yes, I want `Sec-` headers to be able to pass through

[06:52:28.0000] <yoav>
or alternatively, add CH sec headers both before and after SW

[06:53:05.0000] <yoav>
the latter might be better, as it'll add CH headers also when the request was changed

[06:53:34.0000] <yoav>
basically, SW needs to be able to observe those headers, but not modify or add them

[06:54:55.0000] <JakeA>
yoav: That's kinda how `Range` works, except `Range` will trigger a preflight for cors requests (but I think this is a bug), and `Range` can be set by the developer (in which case it should trigger a preflight)

[06:55:36.0000] <JakeA>
But the mechanism that allows `Range` to exist unless the request is modified seems useful for `Sec-`

[06:58:39.0000] <yoav>
Can Range headers survive if the request was modified?

[06:59:38.0000] <yoav>
JakeA: I think that would be desirable for CH headers, but not sure how to achieve that. Maybe we should keep a copy of all `Sec-` headers before SW is called and then restore them afterwards?

[07:05:51.0000] <JakeA>
yoav: "Can Range headers survive if the request was modified?" no

[07:07:07.0000] <JakeA>
yoav: https://github.com/web-platform-tests/wpt/blob/master/fetch/range/general.any.js

[07:08:27.0000] <JakeA>
yoav: what do you want to happen to the `sec-` headers if the request is modified? Remove them, or set them to some kind of default?

[07:10:04.0000] <yoav>
I want to set them back to what they were

[07:10:35.0000] <JakeA>
What's the difference between that and doing nothing?

[07:10:46.0000] <JakeA>
(given that developers can't set them anyway)

[07:11:12.0000] <yoav>
Let's consider `Sec-DPR: 2`. I want to set it before SW (so that SW can observe it and maybe change its response accordingly), but want to make sure it is added to requests going to the server, even if the request was modified

[07:11:43.0000] <JakeA>
Why do you need to add something that's already there?

[07:11:44.0000] <yoav>
and I want that value to not be modifiable by the developer

[07:12:20.0000] <yoav>
If `Sec-` headers gets blown off when the developer modifies the request, I want to reinstate them

[07:12:34.0000] <yoav>
if they are there, no need to add them again, obviously

[07:12:54.0000] <JakeA>
just don't blow them off then?

[07:13:01.0000] <JakeA>
ew, phrasing

[07:13:54.0000] <JakeA>
I think I'm missing something. If you don't want the headers to be removed, instead of removing them and re-adding them, just don't remove them, right?

[07:14:45.0000] <yoav>
Maybe I'm missing something. When a SW gets a Request object in its fetch event, is it immutable? Or can they change it?

[07:15:48.0000] <JakeA>
It's immutable, but once you do `const request = new Request(event.request)` then `request.headers` are mutable

[07:16:32.0000] <yoav>
oh, so devs will be able to change those request headers without killing any forbidden headers which were present in the original request?

[07:16:43.0000] <yoav>
that'd work

[07:17:29.0000] <JakeA>
Yeah. That's different to how `Range` works btw. `Range` headers are removed as soon as the developer modifies the headers.

[07:17:45.0000] <JakeA>
But it seems like `Sec-` needs to work differently

[07:34:12.0000] <yoav>
JakeA: Thanks! I'll take a look and come up with a Range-inspired proposal

[07:49:17.0000] <annevk>
Domenic: want to do a final pass and land https://github.com/whatwg/html/pull/4360?

[07:49:22.0000] <annevk>
Domenic: I gotta go soon

[08:28:25.0000] <Domenic>
Can do

[09:52:53.0000] <annevk>
Domenic: never mind, Maciej spotted a mistake

[10:26:35.0000] <annevk>
Domenic: playsinline was added in June 2016, FWIW

[10:29:00.0000] <Domenic>
Ah wow OK

[14:07:28.0000] <annevk>
I can look into when the checkpoint flag got added I suppose


2019-03-21
[02:32:49.0000] <yoav>
annevk: care to take a look at https://github.com/whatwg/fetch/pull/881? Want to get a read of general direction before I rebase the HTML PR on it

[03:12:23.0000] <yoav>
thx!

[05:57:33.0000] <lgrahl>
o/ Quick question: In WebIDL, can "readonly attribute"s contain an algorithm with "steps" like methods can?

[06:37:57.0000] <annevk>
lgrahl: yes, it's a getter

[06:38:11.0000] <annevk>
lgrahl: however, please ensure obj.attr === obj.attr

[06:42:13.0000] <lgrahl>
annevk: Do you have an example for such a check?

[06:42:57.0000] <annevk>
lgrahl: check?

[06:43:33.0000] <annevk>
lgrahl: it's a design principle: https://w3ctag.github.io/design-principles/#attributes-like-data

[06:44:40.0000] <annevk>
lgrahl: the way to write the prose is typically something like "The fooBar attribute's getter must run these steps:"

[06:45:17.0000] <annevk>
lgrahl: and then depending on what it returns you might need [SameObject] in IDL, an internal slot to store some value in, etc.

[06:46:00.0000] <lgrahl>
annevk: I wonder... do you consider a getter appropriate for a result that depends on whether or not a permission has been granted via the permission API?

[06:48:17.0000] <annevk>
lgrahl: stuff that's tied to permissions should be a promise

[06:48:38.0000] <lgrahl>
annevk: When requesting, definitely. But when just fetching the current state?

[06:48:44.0000] <annevk>
lgrahl: could be returned from a getter, but managing lifetime might be icky

[06:49:07.0000] <annevk>
lgrahl: what's the current state when you start out?

[06:49:20.0000] <annevk>
lgrahl: if it requires accessing the permission store, you introduced synchronous IPC

[06:49:40.0000] <lgrahl>
annevk: It might require accessing the permission store.

[06:49:47.0000] <annevk>
lgrahl: then you use a promise

[06:50:02.0000] <lgrahl>
annevk: Then I'm confused by the spec. https://www.w3.org/TR/permissions/#reading-current-states looks sync to me.

[06:50:11.0000] <annevk>
please no new synchronous IPC APIs 😊

[06:50:56.0000] <annevk>
lgrahl: that might need patching in some way

[06:51:12.0000] <lgrahl>
The spec?

[06:51:24.0000] <annevk>
lgrahl: yeah, it's definitely somewhat wrong

[06:51:34.0000] <lgrahl>
I'm happy to use a Promise, don't get me wrong. :)

[06:51:44.0000] <lgrahl>
Then I'll just change that to a promise.

[06:52:30.0000] <annevk>
👍🏻

[08:27:53.0000] <lgrahl>
annevk: Can you tell me what the "current realm" in the Permission API refers to? What is the scope of that realm? The domain name?

[08:33:52.0000] <annevk>
lgrahl: a realm is 1:1 with a JavaScript global

[08:34:05.0000] <annevk>
lgrahl: and it's effectively a container of sorts for one

[08:38:34.0000] <lgrahl>
annevk: So, in my head, can I map that to the "page"? :)

[08:39:24.0000] <lgrahl>
annevk: Or does it also affect other pages on the same domain? For example, when a permission storage entry has been made.

[08:40:02.0000] <annevk>
lgrahl: I guess you can consider it roughly analogous to document (which I guess means page, that's not really a term we use)

[08:40:14.0000] <annevk>
(except for printing)

[08:40:26.0000] <lgrahl>
Heh, document is alright.

[08:44:43.0000] <lgrahl>
annevk: Let me rephrase that question then: If a permission storage entry has been made, will that be effective immediately to other documents? Furthermore, will it affect any other documents but those shipped from hat precise domain (such as subdomains)?

[08:45:21.0000] <annevk>
lgrahl: I think that depends on the implementation and the permission

[08:46:55.0000] <lgrahl>
annevk: Hrm, I haven't seen any spec defining that (or I missed something).

[08:51:55.0000] <annevk>
lgrahl: I mean, ISSUE 1 under https://www.w3.org/TR/permissions/#reading-current-states hints at it and that algorithm basically doesn't describe any scoping or keying

[08:55:06.0000] <lgrahl>
annevk: I see. Thanks for your help so far! I'm working on a use case neutral permission request for WebRTC.


2019-03-22
[00:29:09.0000] <annevk>
littledan: so this nested event loop investigation I’m doing might influence the way we split the runtime between ES and hosts a bit

[00:30:34.0000] <annevk>
littledan: at least some UAs have the ability to pause a job, execute the remaining ones, and then execute the remainder of the paused job (simplified)

[00:32:32.0000] <littledan>
Annevk, yeah, I have been watching this thread with some interest. Do you have a test case?

[00:33:18.0000] <littledan>
This can happen while processing multiple mutationobserver callbacks?

[00:33:59.0000] <annevk>
littledan: any microtask really, no test yet

[00:34:43.0000] <annevk>
littledan: I guess another way of putting it is that some privileged callers have direct access to the queue

[00:35:12.0000] <littledan>
Well, for the potential layering change, I would imagine that, at most, the microtask queue is in JS, and the rest of the event loop remains in HTML

[00:36:43.0000] <littledan>
So, it would help to understand how the access is privileged with respect to the microtask queue specifically

[00:37:02.0000] <littledan>
I saw wording about the incumbent settings object as well

[00:38:03.0000] <annevk>
And active document iirc

[00:39:04.0000] <littledan>
Annevk: well, thanks for the investigation and summary, this is helpful for my presentation to TC39 to codify HTML's role in the willful violation layering

[00:39:20.0000] <littledan>
Which has confused folks in the past

[01:27:48.0000] <annevk>
littledan: I think part of that was being able to land text in the JS spec without much review

[01:28:30.0000] <annevk>
littledan: from the beginning Hixie asked for a diff archirecture and pointed out issues with what was put in

[03:02:00.0000] <littledan>
Well, I am not a big fan of the JS spec's current text at all. I would imagine something much simpler, without using the word implementation-defined, and without trying to outline how the event loop works

[03:02:36.0000] <littledan>
(that is, if we want to go with something other than the current HTML text, and I am happy with the current text)

[03:04:07.0000] <littledan>
annevk: in a recent call with some framework authors, we got a lot of interest in discussing HTML topics. See https://docs.google.com/document/d/1vvL357Z6r9IYTItvNwBf0wRH-uT4J_bAFIqnbQb-13I and grep for HTML to see the list

[03:04:28.0000] <littledan>
I'd welcome WHATWG folks to the next call to discuss these topics

[03:04:34.0000] <littledan>
Several DOM things too

[03:04:45.0000] <littledan>
Let me know if you want me to send an invite

[03:06:24.0000] <annevk>
littledan: please do

[07:57:13.0000] <annevk>
Domenic: https://github.com/web-platform-tests/wpt/pull/15769 should be good now btw

[08:19:30.0000] <Domenic>
annevk: I want to pull down locally and debug in Chrome; those errors are still very surprising.

[08:22:34.0000] <annevk>
Domenic: presumably that shouldn't affect the test though given results in Firefox and Safari?

[08:23:03.0000] <annevk>
anyway, seems fine I guess

[08:27:46.0000] <Domenic>
My suspicion is another Chrome bug/interop problem with e.g. onload is preventing the test from actually testing named property behavior.

[08:29:19.0000] <annevk>
Speaking of which, it'd be really nice if we got toward a world with consistent load events

[09:04:17.0000] <Domenic>
Yes... it is surprising that we mostly run into this in tests, instead of web developers running into it all the time and being mad.

[11:15:07.0000] <jyasskin>
lgrahl/annevk: I can confirm that I wasn't thinking about the permission store itself being behind an IPC when I wrote https://www.w3.org/TR/permissions/#reading-current-states. It's possible it needs a note like in https://www.w3.org/TR/permissions/#requesting-more-permission warning spec authors to only call it in parallel. I *think* that all the uses already obey that, but I haven't checked them all.

[11:16:45.0000] <annevk>
jyasskin: that doesn't work though, there's no settings objects there

[11:22:06.0000] <jyasskin>
annevk: Hmm. https://www.w3.org/TR/permissions/#requesting-more-permission has that problem too, and talks about the "current realm", which also isn't accessible from "in parallel". We only use the settings object to call https://w3c.github.io/webappsec-secure-contexts/#is-settings-object-contextually-secure, which I think relies only on immutable bits of the settings object? So, is there actually a race condition here, or

[11:22:06.0000] <jyasskin>
just some need to make the immutable parts of a settings object available from asynchronous contexts?

[11:23:39.0000] <annevk>
jyasskin: what if the settings object has gone away?

[11:23:58.0000] <annevk>
jyasskin: "current" definitely doesn't work so you'd require to pass it in

[11:24:14.0000] <annevk>
jyasskin: but it seems safer to require someone passing the bits in they need

[11:24:40.0000] <annevk>
jyasskin: and it seems safer still to provide some kind of "in parallel" wrapper for specs to use

[11:25:07.0000] <annevk>
That was a bit unclear, require passing the bits of a settings object that your algorithm needs

[11:25:25.0000] <jyasskin>
Is https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-for-spec-authors the only place we actually say that you can't use settings objects from "in parallel"?

[11:25:28.0000] <annevk>
And then abstract from there to make it still reasonable to call

[11:26:01.0000] <annevk>
jyasskin: could be, we have very little documentation around "in parallel" and as we discussed in the past "in parallel" isn't the greatest

[11:29:45.0000] <jyasskin>
(Noting that I don't really mind having the permissions algorithms taking the few bits of a settings object that they actually need explicitly...) There's a natural meaning for the "current realm" in a parallel context: it's just the current realm of whatever step fired off the parallel task. I'd want to handle tasks that are running after the settings object has "gone away" in the same way we handle anything else using

[11:29:45.0000] <jyasskin>
something that has gone away: the garbage collector must not create that situation.

[11:32:50.0000] <annevk>
jyasskin: that's an interesting argument

[11:33:26.0000] <annevk>
jyasskin: it's also a fair amount of magic that I'm hoping won't backfire in some way

[11:34:23.0000] <annevk>
jyasskin: with event loops we're fairly conservative as to what can cross the boundary (tasks)

[11:36:55.0000] <jyasskin>
We do have problems around users closing windows, which should neuter some objects, and I don't think we have the terminology we need to talk about that well. But document objects already survive past that user action.

[11:38:45.0000] <jyasskin>
I think "queue a task" has some of its own problems if settings objects die in the middle of parallel steps. Where the task gets queued and the "current realm" of that task is totally implicit.

[11:39:51.0000] <jyasskin>
I should get a *really good* intern to spend a summer figuring all of this out.

[12:18:58.0000] <annevk>
Isn’t it up to senior folks to sort tech debt so interns can do something new or some such?

[13:01:34.0000] <jyasskin>
annevk: That would be awesome.


2019-03-23
[13:44:07.0000] <smaug____>
do we have any usage numbers of fetch() vs. xhr

[13:44:38.0000] <smaug____>
based on various performance profiles, fetch is very rarely used

[14:03:11.0000] <Domenic>
Fetch https://www.chromestatus.com/metrics/feature/timeline/popularity/675

[14:03:15.0000] <Domenic>
XHR https://www.chromestatus.com/metrics/feature/timeline/popularity/677

[14:13:40.0000] <smaug____>
thanks

[14:15:57.0000] <smaug____>
so async XHR is ~70% and fetch 20%

[14:16:33.0000] <smaug____>
and sync XHR 5%

[14:26:25.0000] <gsnedders>
and those are % of page loads, and I expect there will be some overlap.

[14:30:47.0000] <smaug____>
sure


2019-03-24
[02:44:24.0000] <Lcfvs>
hi all

[02:45:53.0000] <Lcfvs>
is there any plan to add a new input[type="abort"]/button[type="abort"] type to abort a sending request, please?

[02:47:07.0000] <Lcfvs>
a few like the [type="reset"] but for a request abortion, as a AbortController

[02:47:30.0000] <annevk>
Lcfvs: there are no plans that I know of

[02:47:52.0000] <Lcfvs>
seems an interesting proposal to write?

[02:48:03.0000] <annevk>
Lcfvs: this might be something you could discuss at https://discourse.wicg.io/ to see if there's something there

[02:48:30.0000] <Lcfvs>
annevk: ok, thanks :)

[02:48:39.0000] <annevk>
Lcfvs: well, <form> is roughly equivalent to <a>, the moment you submit the browser initiates navigation, you'd have to be quite quick to hit something to abort before the document is replaced

[02:49:25.0000] <Lcfvs>
annevk: yeah, I know, as for the AbortController, the requirements are the same

[03:10:02.0000] <Lcfvs>
done https://discourse.wicg.io/t/proposal-button-type-abort-input-type-abort/3449 :)

[03:10:41.0000] <Lcfvs>
annevk: thanks again


2019-03-25
[00:02:01.0000] <hsivonen>
annevk: Given https://github.com/whatwg/fetch/commit/4b9bb073426578c2c7c270340b526b309ea8ae09 , what's the expectation for Client-Hints WPTs for this?

[00:02:44.0000] <hsivonen>
(it seem inappropriate to me that tests have landed in WPT for Client-Hints Fetch integration bits that weren't in the spec even)

[00:24:35.0000] <ondras>
7/w 49

[00:24:38.0000] <ondras>
sorry

[00:33:10.0000] <annevk>
hsivonen: they should be .tentative.

[00:34:02.0000] <annevk>
hsivonen: I should have checked WPT…

[00:39:06.0000] <hsivonen>
annevk: are you going to mark them, or should I file an issue? Does Gecko's wpt CI run .tentative. tests by default?

[00:52:01.0000] <annevk>
hsivonen: I will take a look now

[00:52:10.0000] <hsivonen>
annevk: thanks

[00:52:12.0000] <annevk>
hsivonen: I don't know about Gecko and .tentative.; jgraham?

[01:14:42.0000] <TimothyGu>
MikeSmith: UTR39 should really be UTS39… updated in https://github.com/tobie/specref/pull/522

[01:16:51.0000] <annevk>
TimothyGu: ooh nice

[01:17:00.0000] <MikeSmith>
TimothyGu: oh wow, thanks for doing all that

[01:17:13.0000] <TimothyGu>
npnp

[01:19:25.0000] <MikeSmith>
/me is reviewing and testing now

[01:19:53.0000] <TimothyGu>
MikeSmith: is there a way to test that no spec key ever disappears

[01:20:14.0000] <annevk>
hsivonen: I looked and I only find hits in fetch/api/headers/headers-no-cors.window.js but those are testing that Client Hints headers get no special treatment

[01:20:43.0000] <MikeSmith>
TimothyGu: dunno will look through the scripts to see

[01:20:44.0000] <annevk>
hsivonen: there is also a client-hints/ dedicated folder with more tests

[01:20:53.0000] <annevk>
hsivonen: but that seems easy enough for us to ignore?

[01:21:04.0000] <annevk>
hsivonen: it's outside the fetch/ folder to be clear, it's parallel

[01:23:04.0000] <MikeSmith>
TimothyGu: hmm no, there’s nothing I can see there which would check that

[01:27:36.0000] <annevk>
hsivonen: ooh, I found a message from Thomas pointing out there's some in cors/

[01:27:43.0000] <annevk>
/me goes to take another look

[01:29:14.0000] <MikeSmith>
TimothyGu: should we squash the commits, or do you prefer it gets merged as a series of commits?

[01:29:31.0000] <hsivonen>
annevk: yeah, https://github.com/web-platform-tests/wpt/blob/master/cors/simple-requests.htm and https://github.com/web-platform-tests/wpt/blob/master/cors/client-hint-request-headers.htm

[01:29:51.0000] <TimothyGu>
MikeSmith: I'd go with series of commits, but either works

[01:30:15.0000] <MikeSmith>
OK I’ll keep it as-is

[01:41:10.0000] <annevk>
hsivonen: there's https://github.com/web-platform-tests/wpt/pull/16048 now; yoav perhaps you want to review it?

[01:48:45.0000] <yoav>
currently at the IETF. I'll try to review later today...

[01:49:29.0000] <annevk>
ta

[01:54:40.0000] <hsivonen>
annevk: thanks

[02:42:04.0000] <annevk>
MikeSmith: hey, who can sort out the legal stuff around https://github.com/w3c/DOM-Parsing/pull/49?

[02:42:23.0000] <annevk>
MikeSmith: I guess the other question is what the status of that work in general is

[02:42:41.0000] <annevk>
MikeSmith: I think there was some tentative agreement to merge it into HTML?

[02:46:41.0000] <jgraham>
hsivonen: We don't have any special handling for .tentative. it's basically a hint that says "developer beware". Given that we sometimes write .tentative. tests for things we think should be specced, I'm not sure what CI behaviour would be more appropriate than ignoring it (making such tests opt-in seems appealing, but would certainly lead to cross bugs when people failed to enable their tests that

[02:46:47.0000] <jgraham>
subsequently silently regressed)

[03:03:36.0000] <hsivonen>
jgraham: ok. thanks

[03:26:01.0000] <MikeSmith>
annevk: I’ve asked Wendy about that PR

[03:26:25.0000] <MikeSmith>
annevk: as far as the general status I don’t recall where we were at with that

[03:36:22.0000] <MikeSmith>
annevk: actually in the relevant agreement doc it seems to already be assumed that it will be folded back into the HTML spec. That is how I read it at least

[04:52:45.0000] <annevk>
MikeSmith: ok, I guess we should start looking into that


2019-03-26
[02:50:49.0000] <lgrahl>
annevk: o/ Can I store an "internal slot" on the realm?

[02:51:50.0000] <annevk>
lgrahl: settings object or global object please

[02:52:01.0000] <annevk>
lgrahl: at least, I think that's our strategy mostly

[02:52:16.0000] <annevk>
lgrahl: leaving the Realm to JavaScript

[02:53:32.0000] <lgrahl>
annevk: Fine by me. :) Do you have a link to a spec that makes use of this?

[02:54:10.0000] <annevk>
lgrahl: HTML does a lot of this 😃

[03:11:41.0000] <lgrahl>
annevk: I don't think I fully understand the difference between the current settings object and the environment settings object.

[03:14:29.0000] <annevk>
lgrahl: the former is an instance of the latter

[03:14:43.0000] <annevk>
iirc

[03:16:27.0000] <lgrahl>
annevk: So, can I say "Let the current settings object have a [[Foo]] internal slot." and then "Store x in the current settings object [[Foo]] internal slot."?

[03:18:37.0000] <annevk>
lgrahl: no, you'd have to modify the environment settings object (the class) and then you manipulate its state using some instance

[03:19:50.0000] <lgrahl>
annevk: "Let the environment settings object have a [[Foo]] internal slot." then?

[03:21:06.0000] <annevk>
lgrahl: more like "The environment settings object has a [[Foo]] internal slot."

[03:21:32.0000] <annevk>
lgrahl: https://ln.hixie.ch/?start=1140242962&count=1 might help

[03:23:40.0000] <lgrahl>
annevk: Phew, don't read the WebRTC spec then. ^.^ It's full of that.

[03:24:55.0000] <annevk>
That's too bad, hopefully they'll fix it one day

[03:25:24.0000] <annevk>
"Let" is really only used for initializing variables within an algorithm

[03:26:51.0000] <lgrahl>
Agree. But "The environment settings object has a [[Foo]] internal slot." is also kind of an implicit definition if it's in the middle of a spec.

[03:29:40.0000] <annevk>
lgrahl: ideally at some point you'd also add a note to the HTML Standard or some such saying environment settings objects are patched in this manner

[03:29:59.0000] <annevk>
lgrahl: you're right that we don't really have a good way of handling extensions to those objects though

[03:30:49.0000] <lgrahl>
annevk: So, I guess since it's not scoped it's probably a good idea to prefix it, for example: [[WebRTCPCFoo]]?

[03:33:00.0000] <annevk>
lgrahl: yeah, though also, typically these kind of extensions are stored on global objects (or document)

[03:33:29.0000] <lgrahl>
annevk: To elaborate: I want to register an intent (read: permission request, but jib really wants to avoid prompting, so this API should encourage to not prompt) and then, if granted at some point, an event should fire on all RTCPeerConnection instances of that realm.

[03:35:11.0000] <annevk>
lgrahl: hmm, shouldn't that be origin-based? if you create an instance in an <iframe> it wouldn't work?

[03:36:23.0000] <lgrahl>
annevk: Mhh... well, ideally, yes.

[03:38:17.0000] <lgrahl>
annevk: jib's idea for Firefox is that there's a toggle button like currently planned for the autoplay audio mute feature. But others should still be able to prompt.

[03:39:40.0000] <lgrahl>
So, I guess it should affect all windows of the same origin.

[03:41:07.0000] <lgrahl>
annevk: What would be the appropriate way to share an "internal slot" across same origin (and later, firing an event for all windows of the same origin)?

[03:44:43.0000] <annevk>
lgrahl: the permission store?

[03:45:03.0000] <annevk>
afaik that has most of the architecture

[03:47:14.0000] <lgrahl>
annevk: Yeah, that might work.

[06:11:18.0000] <Domenic>
annevk: apologies in advance for disappearing; I dropped that output review right before boarding a flight. Thanks so much for taking that on.

[06:14:01.0000] <annevk>
Domenic: heh, safe travels

[08:05:49.0000] <bkardell>
should any markup in html realistically become just Element? I didn't think so, but I want to be sure

[08:07:43.0000] <bkardell>
like, as in should it be plausble to put markup in the document which winds up where a ref to that element's .constructor is Element itself

[08:20:21.0000] <Ms2ger>
I'm not going to claim it's impossible, but I'd be surprised

[08:28:25.0000] <bkardell>
Ms2ger: I would have been yesterday too :)

[08:29:15.0000] <bkardell>
It seemed strange to me and probably like it shouldn't be but I wanted some advice from folks here about whether that seemed probably strange/bad too

[08:46:28.0000] <annevk>
bkardell: depending on where you are going with this https://github.com/whatwg/html/issues/4436#issuecomment-476632809 might be relevant

[08:47:24.0000] <annevk>
bkardell: but also, <!-- ... --> does not become an Element, but that's probably not what you mean

[08:53:28.0000] <bkardell>
https://codepen.io/bkardell/pen/EMJqYz

[08:54:24.0000] <bkardell>
I am seeing the constructor there as Element in FF, chrome and webkit

[08:54:56.0000] <bkardell>
that surprised me and I guess it causes a number of issues actually

[08:56:09.0000] <bkardell>
it feels weird that that is what is happening and I just wanted to see what you all thought... agree that is weird?  IT's underspecified atm

[08:57:07.0000] <annevk>
bkardell: oh for MathML

[08:57:17.0000] <annevk>
bkardell: I think that's fine

[08:57:46.0000] <annevk>
bkardell: though maybe MathML should have something like MathMLElement for shared stuff

[08:57:53.0000] <annevk>
bkardell: e.g., this way it won't have .style I guess

[08:57:55.0000] <bkardell>
it means that currently you don't have .style or access to custom properties and so on

[08:58:07.0000] <bkardell>
yeah, this is where I was going

[08:58:16.0000] <annevk>
bkardell: okay, I agree that seems worth fixing

[08:58:23.0000] <annevk>
bkardell: it's mostly an issue with MathML

[08:58:29.0000] <bkardell>
exactly... just wanted to see if that made sense before I suggested going down that path

[08:58:35.0000] <annevk>
bkardell: some folks restarted doing some work on that, perhaps file an issue there?

[08:58:57.0000] <bkardell>
yeah, there is where I am

[08:59:05.0000] <bkardell>
that*

[08:59:12.0000] <annevk>
the alternative is to uplift stuff to Element

[08:59:18.0000] <annevk>
we've done that for className/id/slot

[09:00:09.0000] <bkardell>
thoughts?

[09:00:41.0000] <bkardell>
tbh, that caused me some confusion because I saw a lot on Element that I didn't think would be there

[09:00:58.0000] <bkardell>
it seemed strange to see all that but not .style, for example

[09:01:45.0000] <bkardell>
you tell me which way to pursue you think

[09:01:57.0000] <annevk>
I guess having MathElement or MathMLElement makes sense, to avoid putting too much on Element

[09:02:08.0000] <annevk>
and then some kind of HTMLElementOrSVGElementOrMathMLElement mixin

[09:02:17.0000] <annevk>
defined in HTML, for all the shared stuff

[09:02:39.0000] <annevk>
and then we only put on element what is truly globally useful

[09:04:01.0000] <bkardell>
ok

[09:04:30.0000] <annevk>
bkardell: thanks for potentially driving this, I know it's been bugging people

[09:04:46.0000] <bkardell>
let me start with posting to the math refresh group and then I expect we'll at some point have to do the HTMLElementOrSVGElementOrMathMLElement stuff

[09:26:46.0000] <annevk>
bkardell: could you post here if you've done so? I'd like to follow along

[09:35:09.0000] <bkardell>
https://github.com/mathml-refresh/mathml/issues/83

[09:37:57.0000] <annevk>
bkardell: fwiw, CSSOM should use that very long name HTML mixin too

[09:38:19.0000] <bkardell>
oh it is not implied, let me re-read

[09:39:29.0000] <bkardell>
updated - better?

[09:39:56.0000] <annevk>
Ta

[09:40:03.0000] <bkardell>
I guess I am trying to say there are at least 3 specs we need to get moving on here so we better get started :-p

[09:40:14.0000] <annevk>
Heh

[09:51:55.0000] <bkardell>
if you want to weigh in on the comment that came in already that might be good in steering?

[10:05:52.0000] <annevk>
Seems Frédéric got it covered

[11:50:07.0000] <bkardell>
hey wait... sorry, I am confused about something. So  some stuff was moved up to element from HTMLElement and now element defines .innerHTML, but not .innerText?

[11:55:07.0000] <bkardell>
I was trying to find some issue in the gh but 'element' is hard to search for there and HTMLElement didn't seem to turn up something on this

[12:41:44.0000] <annevk>
bkardell: these are not necessarily principled decisions

[12:42:26.0000] <bkardell>
I'm just curious why not move innerText along with innerHTML/outerHTML?

[12:42:40.0000] <annevk>
bkardell: you could start with what you think makes sense and then see if it’s worth the effort to get there

[12:43:11.0000] <annevk>
bkardell: innerText is quite special and somewhat legacy

[12:43:20.0000] <bkardell>
ah... interesting

[12:43:27.0000] <bkardell>
textContent?

[12:43:36.0000] <annevk>
bkardell: we could move it perhaps, but it’s work

[12:43:47.0000] <annevk>
bkardell: that’s on Node

[12:43:58.0000] <bkardell>
yeah

[12:44:08.0000] <bkardell>
ok makes a little more sense now


2019-03-27
[09:09:23.0000] <devsnek>
is there any web api to parse a data url correctly

[09:09:52.0000] <devsnek>
e.g. `new URL('data:text/javascript,a ? b : c')` would cut out the `? b : c` from pathname

[09:55:38.0000] <grumble>
devsnek: what about XHR or fetch on the data url?

[10:01:22.0000] <devsnek>
grumble: could work I guess, I'd rather something synchronous though

[10:38:09.0000] <Domenic>
devsnek: no there is not. Use https://github.com/jsdom/data-urls or probably some variant of it that doesn't have a whatwg-url dependency (and uses native URL instead).

[10:38:25.0000] <Domenic>
cf. https://github.com/jsdom/data-urls/issues/7 by TimothyGu

[10:38:48.0000] <devsnek>
aw i was hoping i wouldn't need to pull in deps or something to add data uris to node's esm resolver

[10:39:08.0000] <devsnek>
thanks though

[10:40:10.0000] <Domenic>
It's surprisingly complicated

[10:40:18.0000] <Domenic>
You need two dependent parsers: forgiving-base64, and MIME type

[10:40:30.0000] <Domenic>
Not to mention URL, I suppose

[10:40:40.0000] <Domenic>
Once you have those the actual code is smallish. https://github.com/jsdom/data-urls/blob/master/lib/parser.js

[11:50:41.0000] <devsnek>
Domenic: do you know if node's buffer base64 is "forgiving"? I can't find anything informative online

[11:51:18.0000] <Domenic>
devsnek: no idea. Check against https://infra.spec.whatwg.org/#forgiving-base64 or the tests in web platform tests.


2019-03-28
[17:15:00.0000] <TimothyGu>
devsnek: the "forgiving" algorithms are essentially atob() and btoa(). Because there are packages that implement those things, I'd assume Node.js is diff

[17:17:29.0000] <devsnek>
TimothyGu: to be fair https://git.coolaj86.com/coolaj86/atob.js/src/branch/master/node-atob.js

[17:17:42.0000] <devsnek>
this is the most popular polyfill

[17:18:24.0000] <devsnek>
so i'm thinking its probably safe

[17:18:27.0000] <TimothyGu>
devsnek: hah

[17:18:44.0000] <devsnek>
a little unicode never hurt anyone

[08:46:44.0000] <Domenic>
Why does <script> require contenteditable for `display: block` to work? Hrm.

[08:58:04.0000] <TabAtkins>
Domenic: It doesn't? I just loaded up a `<body><script style="display: block">foo bar</script>` test page and it showed the script just fine.

[08:58:48.0000] <Domenic>
TabAtkins: you're right, I must have been doing something else wrong

[08:59:23.0000] <TabAtkins>
Possibly you didn't have a body-forcer in your test, so the <script> was in <head>, which is still display:none?

[09:03:01.0000] <Domenic>
Ah yeah probably that

[11:42:03.0000] <bkardell>
I dont recall conversations but I am relatively sure they exist and I can't find anything on this so will try asking for any pointers to get me started here... We have elements which have, basically, native shadow roots which then can't have user defined ones and so we have basically a list of tags that will not throw if you try to add a shadow root on them and then say 'mostly anything that looks like a custom element too'

[11:42:31.0000] <annevk>
I guess that prolly runs the script Domenic if you paste it? Sounds like fun

[11:43:03.0000] <Domenic>
annevk: nah child text content change doesn't re-execute script I am pretty sure. Only on first being-connected.

[11:43:11.0000] <annevk>
bkardell: what is the question?

[11:43:19.0000] <bkardell>
yeah, sorry I am getting to it :)

[11:43:29.0000] <annevk>
Domenic: it does in Fx if it’s empty

[11:43:46.0000] <Domenic>
Hmm yeah I do kinda remember something about a transition from empty string to not

[11:44:12.0000] <bkardell>
so, mathml elements are basically unspecified and we have a lot of things to work out there but... should some of them maybe allow shadowroots and wind up in our whitelist or... that list is pretty short, idk

[11:45:24.0000] <bkardell>
and then, these again wind up in a weird place in histrory because it's possible the native implementation might want a shadow root for some of them, but maybe we need to polyfill it too :(

[11:45:31.0000] <annevk>
bkardell: I think for MathML we mostly want to work towards less maintenance, so no…

[11:46:06.0000] <annevk>
bkardell: esp as long as it’s unclear what the primitives are

[11:46:28.0000] <bkardell>
that is what we are working on

[11:46:35.0000] <annevk>
bkardell: this is also why most HTML elements do not work

[11:47:53.0000] <bkardell>
Like... my first instinct, still knowing very little, is that if I was implementing natively one of these elements I think I would give it a shadow dom because currently they basically replace one set of elements with another in the polyflls, but they are both math ones - one is just a shorthand

[11:48:25.0000] <annevk>
bkardell: if something really boils down to span/div with a different style, then maybe, but even then it’s work to make it work

[11:49:15.0000] <bkardell>
annevk: can you explain with a few more words? sorry I didn't follow

[11:50:31.0000] <annevk>
If a math element has a CSS-only implementation in all engines, then maybe, but even that would come at a cost that doesn’t feel clearly justified

[12:02:58.0000] <bkardell>
annevk: got it, thanks

[14:13:36.0000] <Domenic>
annevk: do you want review on https://github.com/whatwg/html/pull/4437 or are you still noodling over whether it's safe? (remove compound microtasks)

[14:20:45.0000] <annevk>
Domenic: pretty sure that is safe and good to go

[14:21:05.0000] <annevk>
Domenic: esp with nobody saying it is impl

[14:21:42.0000] <annevk>
Domenic: the main question is really about the remainder, post removal of that

[14:21:50.0000] <Domenic>
Gotcha

[14:26:27.0000] <annevk>
Domenic: also, that default value paragraph is in a w-nodev block

[14:26:32.0000] <annevk>
Domenic: iirc

[14:27:07.0000] <Domenic>
annevk: yep, I'm saying that's surprising, and we should consider either deleting it (since I think it is not very valuable for implementers or tools) or moving it and fixing it

[14:28:03.0000] <annevk>
K


2019-03-29
[02:55:13.0000] <Ms2ger>
So, uh

[02:55:32.0000] <Ms2ger>
W3C bug tracker is shutting down on Monday, and we haven't backed up the IDL issues

[02:56:04.0000] <Ms2ger>
MikeSmith, you know who I can poke to deal with that, like, today?

[03:16:56.0000] <annevk>
Ms2ger: will they 404 the lot?

[03:17:07.0000] <annevk>
I guess either way it's not great

[03:17:19.0000] <annevk>
We've also not dealt with the HTML backlog I think

[03:21:46.0000] <Ms2ger>
"A static copy of the contents of this service will be archived and made available in place.", allegedly

[03:21:51.0000] <Ms2ger>
But probably no search

[03:29:52.0000] <MikeSmith>
Ms2ger: yeah I'm told all the URLs will keep working

[03:30:26.0000] <MikeSmith>
but the search  feature will not

[05:50:53.0000] <Domenic>
The search feature is useful for filtering by component

[05:51:08.0000] <Domenic>
I might spend time on this today depending on what else comes up...

[05:51:16.0000] <Domenic>
(For HTML)

[05:55:09.0000] <annevk>
Domenic: are you planning on working on the Twitter integration?

[05:55:21.0000] <Domenic>
annevk: it keeps sliding off my to-do list :-/

[05:55:49.0000] <annevk>
Ah, same here

[05:56:59.0000] <annevk>
Perhaps in a couple of weeks, but I'm not very familiar with our server setup

[08:16:01.0000] <Domenic>
annevk: the last step of https://html.spec.whatwg.org/#perform-a-microtask-checkpoint unsets the performing a microtask check point flag

[08:16:45.0000] <annevk>
Domenic: it does, but the step in spin the event loop that tries to run perform a microtask checkpoint does not get it unset, because it's still set at that point

[08:19:35.0000] <Domenic>
annevk: I must be missing something. In step 1 of STEL, the flag is set. In step 5 of STEL it calls PAMT. Step 1 of PAMT sets the flag to true, redundantly. Step 5 of PAMT sets it to false. So by the time we reach step 6 of STEL it's set to false, from what I can tell.

[08:22:31.0000] <annevk>
Domenic: how do you get to step 1 of PAMT?

[08:22:38.0000] <annevk>
Domenic: you're missing step 0, which is to check the flag

[08:22:46.0000] <Domenic>
FRRRRRIG

[08:22:54.0000] <Domenic>
Please fix step 0

[08:23:24.0000] <Domenic>
My eyes go straight from bold <dfn> to the nearest 1.

[08:23:28.0000] <annevk>
Domenic: separately though?

[08:23:50.0000] <Domenic>
I mean seems reasonable to do it while here but I could fix it right now if you want. I'm really angry at that sentence at the moment :)

[08:23:51.0000] <annevk>
Domenic: that's fair, I did think about it, but I don't wanna couple too much stuff together

[08:24:00.0000] <annevk>
haha

[08:24:42.0000] <Domenic>
OK, let me re-read your comments now.

[08:27:57.0000] <Domenic>
annevk: another cleanup we should do is that we sometimes set the performing microtask checkpoint flag to true, which is weird since it's a flag.

[08:28:17.0000] <annevk>
Domenic: yeah, boolean all the things

[08:28:30.0000] <annevk>
Domenic: I'm converting flags to booleans as I touch them these days

[08:28:39.0000] <Domenic>
Yeah +1

[09:17:55.0000] <innovati_>
Does 'href' officially stand for anything like 'hypertext reference' or similar?

[09:25:50.0000] <Mek>
that's what https://www.w3.org/Provider/ServerWriter.html claims, yes

[10:33:23.0000] <innovati_>
Thanks Mek, it looks like that document is from 24 years ago‽ seems authoritative

[10:48:16.0000] <Domenic>
annevk: I have a patch I'm working on now that gives task a set of fields and makes queue a task more rigorous.

[11:23:44.0000] <annevk>
Ooh cool

[11:24:14.0000] <annevk>
HTTP Workshop is most of next week so review might drag out potentially

[11:59:10.0000] <Domenic>
No problem, I've done it to you enough times ^_^

[14:04:49.0000] <AutomatedTester>
what is the expectation of highlighting the rendered text of a web component and the next node e.g. <web component>some text</web component> <div>foo</div> so that it might look like `some text foo` when rendered. If I highlight this to say copy the text, what should be highlighted? Noticed Chrome and Firefox do different things

[14:07:29.0000] <Domenic>
AutomatedTester: translating mouse-drags into highlighting and selection is not generally covered by specs; that's a browser UI issue.

[14:07:51.0000] <Domenic>
Does anyone know where that SVG rendering profiles spec is that talks about e.g. when to execute script or not?

[14:07:53.0000] <AutomatedTester>
oh ok, I thought it might have been a DOM Range thing

[14:08:32.0000] <Domenic>
AutomatedTester: yeah that would govern what results you get back from the Range API, but not when you drag your mouse.

[14:08:48.0000] <Domenic>
OK, the spec I was looking for is https://svgwg.org/specs/integration/ . My strategy that the moment I asked for help I would figure it out myself was a great success.

[14:13:15.0000] <Domenic>
Looks like I'm on track to finish out the HTML bugs but https://www.w3.org/Bugs/Public/buglist.cgi?list_id=70355&product=WHATWG&resolution=--- still has a good amount of MIME Sniffing.

[15:22:31.0000] <Domenic>
https://www.w3.org/Bugs/Public/buglist.cgi?component=HTML&list_id=70354&product=WHATWG&resolution=--- done

[15:50:14.0000] <Domenic>
(MIME Sniffing bugs not moved, for the record. Maybe GPHemsley or annevk could help with that.)

[15:50:35.0000] <GPHemsley>
ohai, I'm actually here in realtime for a change

[15:51:42.0000] <GPHemsley>
I'll have reassociate myself with W3C Bugzilla, but IIRC I already moved all the mimesniff bugs to github back in the beginning

[15:54:37.0000] <GPHemsley>
unless I'm thinking of the ticket-moving from IETF to W3C that I also had to do

[15:56:12.0000] <GPHemsley>
aw, looks like that's what I was thinking of

[16:18:26.0000] <GPHemsley>
alright, I closed what I could; the rest will need to be handled by someone with more recent association with the spec and the plans for its expansion

[16:18:28.0000] <GPHemsley>
annevk: https://www.w3.org/Bugs/Public/buglist.cgi?component=MIME&list_id=70360&product=WHATWG&query_format=advanced&resolution=---

[16:19:00.0000] <GPHemsley>
(some things may/should have been moved to Fetch)


2019-03-30
[12:44:31.0000] <annevk>
GPHemsley: thanks, taking a look

[13:20:26.0000] <annevk>
done