2018-09-01
[19:53:40.0000] <domfarolino>
annevk: did there used to be a concept-request-context?

[20:18:59.0000] <domfarolino>
Ah, seems that it was the old request-destination

[08:47:36.0000] <nox>
Would you people be against patching tests which use named properties on Window (e.g. the getter that relies on id and name content attributes) so they explicitly call getElementById etc?

[08:47:50.0000] <nox>
We have various tests failing in Servo because of that, the tests ultimately time out and that takes time.

[08:53:59.0000] <annevk>
nox: yeah, I’d rather not have that effect blame and potential coverage

[08:54:43.0000] <nox>
annevk: I'm not sure if that's a yes or a no, and even if you reply with yes or no my question was formulated in such a convoluted way I'm not sure you are against me making the changes or not. :P

[08:56:39.0000] <annevk>
nox: against change

[08:56:50.0000] <nox>
annevk: Ok fair enough.

[08:57:26.0000] <nox>
annevk: Unrelated, can I mark http://w3c-test.org/css/css-transitions/transitions-animatable-properties-01.html as timeout=long?

[08:57:58.0000] <nox>
It times out in Servo, which is no good reason to do it, but it seems to time out elsewhere too (just tried on Safari and Firefox).

[08:58:40.0000] <nox>
(The indentation is so wild in that file hah.)

[09:03:50.0000] <nox>
annevk: https://github.com/servo/servo/blob/master/tests/wpt/web-platform-tests/css/css-values/support/vh_not_refreshing_on_chrome_iframe.html#L81-L89 What about this kind of test, where it uses both the named getter *and* getElementById for the same element?

[09:06:40.0000] <annevk>
I’d rather not have unneeded changes; the timeout one sounds reasonable though

[09:06:46.0000] <nox>
annevk: Ack.


2018-09-03
[10:52:22.0000] <Krinkle>
Hm.. today I learned that sessionStorage is limited to a single tab. I've always treated it like a best-practice alternative to session cookies that are only needed within JS, and strongly preferring it over localStorage due to lack of TTL and due to iteration/lazy-garage collection being very I/O expensive on mobile.

[10:52:34.0000] <Krinkle>
But it looks like I got it all wrong.

[13:45:49.0000] <devsnek>
do any browsers implement queueMicrotask

[13:51:51.0000] <devsnek>
I don't even see it in mdn

[13:59:25.0000] <TimothyGu>
devsnek: https://crbug.com/864900 if you wanna be updated

[14:00:05.0000] <devsnek>
TimothyGu: is there any precedence for moving an api from whatwg to ecma262

[14:01:03.0000] <TimothyGu>
devsnek: I don't think so though TypedArray was initially standardized through Khronos IIRC. In this case it wouldn't make too much sense to keep the name as "microtask" isn't defined in ECMA-262

[14:01:18.0000] <devsnek>
we can rename job to microtask ez

[14:02:00.0000] <TimothyGu>
...good luck

[14:03:01.0000] <devsnek>
lel

[14:03:29.0000] <devsnek>
in the big picture, it does seem like something 262 is missing out on

[14:04:54.0000] <TimothyGu>
devsnek: what are you gonna do with ScriptJob if you rename Job to microtask

[14:05:05.0000] <devsnek>
ScriptMicrotask

[14:05:18.0000] <devsnek>
ScriptTask

[14:05:20.0000] <TimothyGu>
but what is a microtask if there isn't the concept of a task

[14:05:26.0000] <TimothyGu>
in 262

[14:05:48.0000] <devsnek>
leave the name bikeshedding to the committee


2018-09-04
[18:51:45.0000] <Domenic>
262 is not a good place for event loop APIs. The current job infrastructure is terribly broken due to lack of desire to engage with realistic execution environments like the browser and node. The committee is specifically uninterested in getting this right.

[18:52:00.0000] <Domenic>
queueMicrotask is in Chrome and Safari masters, I believe

[19:00:14.0000] <Domenic>
Hmm maybe stalled in Chrome :-/

[19:10:36.0000] <devsnek>
i think i'm going to pr it to node then

[19:50:13.0000] <annevk>
Domenic: wait that PR to fix jobs is stalled in committee?

[19:59:49.0000] <devsnek>
i really want that pr to land

[19:59:58.0000] <devsnek>
i have this stupid RunJobs thing sitting around in engine262 but i don't use it

[20:34:56.0000] <Domenic>
annevk: well, it was when i first pushed it; haven't tried recently

[01:03:01.0000] <hsivonen>
is there a way for Web content to see what file name the browser parsed out of a Content-Disposition header?

[03:49:00.0000] <MikeSmith>
hsivonen: not seeing anything in https://html.spec.whatwg.org/multipage/links.html#downloading-resources:as-a-download-2 at least that would cause it to be exposed somehow

[04:38:45.0000] <nox>
annevk: So I was looking at Window's getters,

[04:38:55.0000] <nox>
annevk: did the indexed one become prose somewhere outside the IDL definition?

[04:55:29.0000] <annevk>
nox: it's part of WindowProxy per impl feedback from Fx and maybe others

[04:55:43.0000] <nox>
Ok!

[04:56:14.0000] <annevk>
nox: this was changed whenever we defined WindowProxy properly, which I think is quite a while ago now

[05:01:19.0000] <Ms2ger>
Yeah, certainly years

[05:40:15.0000] <annevk>
ugh

[06:40:49.0000] <nox>
Oh, they back.

[08:11:11.0000] <Domenic>
We may need to stay +r forever? :-/

[08:13:56.0000] <annevk>
That's requiring registered accounts? I think that's okay

[08:14:10.0000] <annevk>
I've done something similar for #content on Mozilla IRC

[08:16:03.0000] <Domenic>
It definitely feels less friendly. We'd need to update https://whatwg.org/irc at least. I didn't register for a long time, and then only because I wanted to get Domenic-with-no-underscores.

[08:25:38.0000] <annevk>
https://github.com/whatwg/meta/issues/108

[08:52:07.0000] <MikeSmith>
I thought Freenode now requires registered accounts for all channels

[08:54:16.0000] <MikeSmith>
recently when I restarted botie and tried to rejoin, I got a message from Freenode saying the nick needed to be registered

[09:42:29.0000] <gsnedders>
MikeSmith: it has at a few times temporarily when the spam has been at its worst


2018-09-05
[23:34:49.0000] <hsivonen>
MikeSmith: thanks

[06:35:54.0000] <wanderview>
annevk: I wonder if it would be possible to spec a test interface that WPT could use to verify things like "protected worker" blocking GC-triggered shutdown of a worker

[06:36:08.0000] <wanderview>
since we make it so hard to observe its difficult to construct a test with just the public APIs

[06:54:12.0000] <zcorpan>
wanderview: wouldn't that just test that interface? seems to me that kind of test should be outside wpt

[06:55:12.0000] <wanderview>
zcorpan: well, when we add new things to the "protected worker" case, the test interface would not change... so we could in fact test that the new conditions are being met

[06:55:19.0000] <wanderview>
but yes, it depends on the infrastructure being correct

[08:26:18.0000] <annevk>
wanderview: in theory that should be possible at least, but depends on webdriver integration and interest in making it happen

[08:26:43.0000] <annevk>
As you already concluded 😊

[08:29:45.0000] <wanderview>
it just seems if we care about making GC not-observable, we should have a way of writing tests to verify that

[08:46:58.0000] <jgraham>
It doesn't depend on WebDriver

[08:47:04.0000] <jgraham>
Or at least doesn't have to

[08:47:49.0000] <jgraham>
Some specs like WebUSB define testing interfaces which are DOM APIs only exposed when a test configuration is active

[08:48:12.0000] <jgraham>
WebDriver support has a considerable advantage in that it allows developers of webapps to perform the same kind of testing

[10:09:44.0000] <devsnek>
Domenic: why can't lock names start with a hyphen

[12:07:34.0000] <Domenic>
devsnek: is this about web locks? I dunno, jsbell is the person to ask there

[12:08:08.0000] <devsnek>
Domenic: kk

[12:08:21.0000] <devsnek>
also i'm working on asyncIterator on ReadableStream

[12:08:29.0000] <devsnek>
gonna just open a new pr

[12:09:42.0000] <Domenic>
Oh awesome, ok, thanks good sir.


2018-09-06
[18:19:12.0000] <TimothyGu>
annevk: is https://github.com/web-platform-tests/wpt/blob/master/xhr/open-url-multi-window-4.htm a legit test? The referenced pull request was closed without being merged, no browser other than Safari passes it, and it times out (like Firefox) when I fix https://crbug.com/879620

[18:21:09.0000] <TimothyGu>
In particular I don't think the test for `error` event is kosher, as discard a Document aborts the document, and should only fire `abort` event

[18:24:55.0000] <TimothyGu>
(by "it" times out, I mean Chrome times out when I fix the linked bug, which is what Firefox currently does)

[20:15:17.0000] <annevk>
TimothyGu: some xhr tests are really old and could prolly use a fresh look

[20:16:09.0000] <annevk>
TimothyGu: I can take look later

[20:16:21.0000] <TimothyGu>
annevk: that'd be appreciated, thanks

[20:29:30.0000] <TimothyGu>
annevk: the main issue here seems to be that in Chrome and Firefox, XMLHttpRequest objects in an inactive document go "dead" and will not fire any events, period. not sure if that behavior is spec'd anywhere though

[20:41:26.0000] <annevk>
TimothyGu: xhr does spec a fully active check iirc

[20:41:54.0000] <annevk>
TimothyGu: the weird thing is that we don’t have it for similar APIs

[20:41:54.0000] <TimothyGu>
annevk: it's only in open() though

[20:42:07.0000] <annevk>
True

[20:42:20.0000] <TimothyGu>
from the impl side it looks like it should really be in fetch

[20:42:34.0000] <TimothyGu>
(by impl I mean Blink and probably WebKit and Gecko)

[20:43:33.0000] <annevk>
And what does the caller get? Network error?

[20:43:50.0000] <TimothyGu>
probably?

[20:44:16.0000] <annevk>
Given that’s async it could change over time too

[20:44:21.0000] <TimothyGu>
either that or an aborted request

[20:44:47.0000] <annevk>
But I guess we terminate fetches when docs go inactive

[20:45:13.0000] <annevk>
Fetch groups are still poorly specced unfortunately

[20:45:28.0000] <TimothyGu>
:(

[20:45:41.0000] <TimothyGu>
have you looked at the test yet?

[20:45:57.0000] <TimothyGu>
it's sort-of blocking my work on Chromium making the abort event async

[20:46:27.0000] <annevk>
Stuck with my phone and a baby; I cannot take a good look for another couple hours

[20:46:39.0000] <annevk>
I guess I can peek at the source

[20:46:49.0000] <TimothyGu>
ah. it's not too terribly huge

[20:47:15.0000] <TimothyGu>
the resources/init.htm file just calls top.init() when loaded, nothing spectacular

[20:48:17.0000] <TimothyGu>
anyway I'll sleep soon and won't get to this until tomorrow, so feel free to take your time.

[20:48:57.0000] <annevk>
TimothyGu: so this depends on unspecced stuff

[20:49:21.0000] <annevk>
TimothyGu: how exactly canceling a fetch group looks

[20:50:18.0000] <annevk>
TimothyGu: if error events this would make sense, but dunno what would be best and what compat allows for

[20:50:40.0000] <annevk>
s/looks/functions/

[20:51:57.0000] <TimothyGu>
So Safari is the only one that does error events, per wpt.fyi (Edge result is missing though). A reasonable guess is that they only implemented that in order to fix this specific test.

[20:54:24.0000] <annevk>
Yeah

[20:55:28.0000] <annevk>
I guess the question is, when a doc goes inactive, how do all fetchy things behave today and does that match what we think is good

[20:56:21.0000] <annevk>
Not firing events seems weird, but if you want to stop running code in a closed tab makes sense

[20:57:46.0000] <TimothyGu>
bz would probably be a person to talk to. And also this has implication on salvageability too

[20:59:23.0000] <annevk>
Yeah

[21:00:16.0000] <TimothyGu>
anyway, for the purpose of implementing the abort event timing correctly in Chrome, I'll just change the expectation to time out instead of failing

[21:17:32.0000] <annevk>
sgtm

[21:31:04.0000] <rniwa>
annevk: yt?

[21:36:27.0000] <rniwa>
smaug____: yt?

[23:33:33.0000] <rniwa>
smaug____: ping?

[23:45:17.0000] <annevk>
rniwa: am now

[23:45:34.0000] <annevk>
If this is about web components, I haven't gotten around to looking at the latest there yet

[23:45:51.0000] <rniwa>
annevk: i have: https://github.com/whatwg/dom/issues/685

[23:46:07.0000] <rniwa>
annevk: I just wanna know if the current spec's wording is intentional

[23:46:12.0000] <rniwa>
annevk: or it's just an oversight

[23:47:37.0000] <rniwa>
annevk: I have a completely unrelated question about "submit" event though

[23:48:04.0000] <rniwa>
annevk: does HTML or DOM spec have any text about how "submit" is stopped propagation at the first form element it encounters?

[23:48:09.0000] <rniwa>
I couldn't find any normative text

[23:48:13.0000] <annevk>
That looks like it might be an oversight, I'll investigate

[23:48:52.0000] <annevk>
rniwa: you're looking for https://github.com/whatwg/html/issues/3599

[23:49:38.0000] <rniwa>
annevk: cool

[23:51:47.0000] <rniwa>
annevk: I did some investigation about that event.composedPath() seem to indicate Blink, Gecko, & WebKit all seem to simply stop the propagation instead of shrinking the event path

[23:51:53.0000] <rniwa>
annevk: it's crazy..

[23:54:32.0000] <annevk>
rniwa: the amount of changes I had to make to the event dispatch algorithm over the years to account for weird stuff browsers implemented is rather staggering

[23:54:49.0000] <rniwa>
annevk: ya, truly mind boggling.

[00:00:30.0000] <rniwa>
annevk: it looks like we're also missing a special case of disabled form controls

[00:00:44.0000] <rniwa>
annevk: as far as I can tell, Gecko stop the propagation of all events on disabled form controls...

[00:01:25.0000] <annevk>
rniwa: I always assumed disabled form controls was some hit testing special case, but I never truly investigated...

[00:01:43.0000] <rniwa>
annevk: hit testing is working

[00:01:49.0000] <rniwa>
annevk: Gecko stops propagation

[00:02:03.0000] <annevk>
Okay, we really need more people to define all this legacy shit

[00:02:06.0000] <rniwa>
annevk: WebKit & Blink simply ignores the event; doesn't call event listeners but let the event pass through to ancestors LOL

[00:02:22.0000] <annevk>
o_O

[00:05:29.0000] <rniwa>
annevk: https://gist.github.com/rniwa/bf0f1411d6b811fcb605e796498740f3

[00:05:32.0000] <rniwa>
annevk: Gecko outputs nothing

[00:05:57.0000] <rniwa>
annevk: WebKit & Blink says

[00:05:57.0000] <rniwa>
click on div

[00:05:57.0000] <rniwa>
test on button

[00:05:57.0000] <rniwa>
test on div

[00:07:39.0000] <annevk>
Well that's no fun, so much special behavior

[00:07:53.0000] <rniwa>
annevk: yeah, this is isane...

[00:07:59.0000] <rniwa>
annevk: I bet some websites rely on it though...

[00:08:23.0000] <annevk>
I like what Gecko does I guess, just return early if the target has some flag set

[00:09:02.0000] <rniwa>
annevk: i guess we'd have to check what it does if an event propagates to a disabled form controls

[00:09:09.0000] <annevk>
Although wait, that's not what it does, it goes through ancestors first

[00:09:34.0000] <annevk>
Yeah, it seems that if there's something on the path with a flag set, it returns early

[00:09:41.0000] <rniwa>
annevk: you mean like capturing?

[00:10:18.0000] <annevk>
rniwa: I mean that in your example you dispatch on <span> which is a child of a disabled element, so the path is span -> disabled element (ignoring other ancestors)

[00:10:59.0000] <rniwa>
annevk: i guess I should add event listeners to span

[00:11:20.0000] <annevk>
ooh, yes

[00:11:28.0000] <rniwa>
annevk: ok, so it dispatches to span!

[00:11:31.0000] <rniwa>
annevk: but then it stops

[00:12:00.0000] <annevk>
I guess that's similar to the <form> scenario? But it doesn't care about the event name here

[00:12:21.0000] <rniwa>
annevk: Blink & WebKit cares about event being a mouse event

[00:12:23.0000] <rniwa>
annevk: but Gecko doesn't

[00:14:03.0000] <rniwa>
annevk: okay, so capturing also only happens on span

[00:14:45.0000] <rniwa>
annevk: I think Gecko's behavior makes most sense here. it's truncating the composed path to 1.

[00:15:05.0000] <rniwa>
for some definition of "makes sense"

[00:15:19.0000] <annevk>
Ah okay, I was about to say that I don't understand how that would work, but if the path is very short I guess it does

[00:15:30.0000] <rniwa>
so maybe 1. restrict this behavior to mouse event & then truncate the event path at the first disabled form control

[00:15:36.0000] <rniwa>
might be good

[00:15:41.0000] <annevk>
That would argue for changing "get the parent" somehow

[00:15:46.0000] <rniwa>
ya

[00:15:56.0000] <annevk>
So form controls can have their own "get the parent" that sometimes returns null

[00:16:11.0000] <annevk>
No wait, that doesn't work

[00:16:34.0000] <annevk>
HTMLElement would need its own "get the parent" that special cases form controls

[00:16:40.0000] <rniwa>
oh no :(

[00:17:03.0000] <rniwa>
annevk: maybe modifying the dispatching algorithm in DOM is better.

[00:17:06.0000] <annevk>
Hmm, actually, probably Element, if we mix namespaces

[00:17:11.0000] <annevk>
Yeah

[00:17:25.0000] <rniwa>
annevk: scattering these quirks throughout different specs make it really hard to find out these edge cases

[00:23:29.0000] <rniwa>
annevk: my goodness. https://github.com/whatwg/html/issues/3599 goes through all elements during the capturing phase

[00:23:48.0000] <rniwa>
annevk: so these two quirks have completely distinct behaviors :(

[00:23:57.0000] <rniwa>
even within each browser!

[00:29:44.0000] <annevk>
Good times

[00:30:00.0000] <annevk>
rniwa: did you file an issue for the disabled control event path quirk?

[00:30:30.0000] <annevk>
rniwa: I agree that it makes some sense to not spread out quirks too much btw, but if they can be defined in terms of a generic mechanism that could be nice, but it seems that get the parent is not it

[00:31:16.0000] <annevk>
rniwa: we could also make the generic "get the parent" check for a [[Nope]] internal slot

[00:31:55.0000] <rniwa>
annevk: it's https://github.com/whatwg/html/issues/2368

[00:32:32.0000] <rniwa>
annevk: I think I'm a bit worried about implementing Gecko's behavior given how permissive WebKit & Blink are.

[00:32:56.0000] <rniwa>
annevk: not firing event listeners sound crazy may not be the end of the world given we'd have to add some quirk somewhere

[00:33:14.0000] <rniwa>
annevk: i was hoping to get away by truncating/shrinking event path for both cases but it seems like we can't due to capturing phase

[00:33:48.0000] <annevk>
Okay, I don't care too much what we end up doing; I guess I'll wait and see what smaug____ says

[00:33:51.0000] <rniwa>
annevk: at that point, maybe we should go with whatever gets us compat with least effect

[01:22:28.0000] <smaug____>
/me looks up

[01:22:59.0000] <smaug____>
something about disabled form elements

[01:23:33.0000] <smaug____>
blink was changing and planning to change the behavior recently

[01:27:58.0000] <smaug____>
oh, about the issue I filed

[05:52:56.0000] <annevk>
Hmm, I'm getting "The requested URL returned error: 400 Bad Request" from Bikeshed again

[13:51:07.0000] <TimothyGu>
annevk: is there a way for me to file bugs on bugzilla.mozilla.org without being given the default template?

[15:36:15.0000] <MikeSmith>
TimothyGu: you need to add &format=__default__ to the query params for the enter-bug URL

[15:36:23.0000] <MikeSmith>
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&format=__default__

[15:36:33.0000] <TimothyGu>
ahh

[15:36:37.0000] <TimothyGu>
how interesting

[15:36:54.0000] <MikeSmith>
heh yeah “interesting” is a good word for it


2018-09-07
[19:56:09.0000] <annevk>
I guess whatwg/meta should link that

[01:07:53.0000] <annevk>
smaug____: https://github.com/whatwg/dom/issues/685#issuecomment-419353747

[02:20:04.0000] <smaug____>
annevk: how is legacy-pre-activation behavior related to clearTargetsTuple?

[02:20:19.0000] <smaug____>
I don't understand the discussion on the pr

[02:20:42.0000] <annevk>
smaug____: I changed where eventPhase is initialized

[02:21:17.0000] <annevk>
smaug____: rniwa pointed out you can observe eventPhase at that point through legacy-pre-activiation behavior and that it differs between browsers

[02:23:08.0000] <smaug____>
hmm, they dispatch change event at wrong time?

[02:34:04.0000] <annevk>
smaug____: re https://github.com/whatwg/dom/issues/685#issuecomment-419376808 the proposal is to always call capture listeners before bubble listeners, not just on hosts

[02:36:59.0000] <annevk>
smaug____: and no, they dispatch it at the same time, compare output of https://software.hixie.ch/utilities/js/live-dom-viewer/saved/6198

[11:34:42.0000] <devsnek>
Domenic: finally finished this: https://github.com/whatwg/streams/pull/954

[11:34:48.0000] <devsnek>
well not "finished" but...

[11:35:02.0000] <Domenic>
devsnek: sweet, I will look at it very soon

[11:43:12.0000] <zcorpan>
...interesting http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6203

[11:47:39.0000] <devsnek>
i often use https://astexplorer.net/

[11:47:51.0000] <devsnek>
it even has webidl

[11:48:14.0000] <zcorpan>
no browser does anything sane with that test

[11:56:17.0000] <Domenic>
devsnek: why did getIterator() disappear

[11:56:46.0000] <Domenic>
Oh what it's still on reader

[11:56:51.0000] <devsnek>
huh

[11:56:59.0000] <Domenic>
Wait no it's gone

[11:57:03.0000] <Domenic>
I was looking at the wrong tab

[11:57:13.0000] <devsnek>
do we still want the alias

[11:57:24.0000] <Domenic>
Yeah I think so

[12:03:20.0000] <devsnek>
Domenic: thanks for the quick review 👍

[12:03:43.0000] <Domenic>
I try... I often fail, but this time I succeeded.

[12:19:56.0000] <devsnek>
Domenic: how do i unwrap the close promise

[12:25:06.0000] <devsnek>
the behaviour i think we want is `return ReadableStreamReaderGenericCancel(reader, value).then(ReadableStreamCreateReadResult)` but i don't know how to write that in spec

[12:30:10.0000] <Domenic>
devsnek: "Return the result of transforming ! ReadableStreamReaderGenericCancel(reader, value) by a fulfillment handler that returns ! ReadableStreamCreateReadResult(value, true, true)"

[12:30:21.0000] <devsnek>
prose ftw

[12:30:23.0000] <devsnek>
thanks

[12:30:33.0000] <Domenic>
"transforming" has a promises-guide pseudo-definition

[12:31:08.0000] <devsnek>
it would be cool if stuff like that was somehow linked

[12:31:12.0000] <devsnek>
like with the locks api earlier

[12:31:36.0000] <Domenic>
It is

[12:31:39.0000] <Domenic>
<a>transforming</a>

[12:46:02.0000] <zcorpan>
is "The rules for parsing tokens in foreign content" not an insertion mode?

[13:07:41.0000] <rniwa>
annevk, smaug____: I used to think event dispatching part of the spec was pretty clean.... not anymore :(

[13:08:01.0000] <smaug____>
it is very complicated

[13:08:02.0000] <rniwa>
annevk, smaug____: all sorts of craziness lurks in there. it's just not well spec'ed...

[13:08:05.0000] <smaug____>
thanks to shadow DOM

[13:08:22.0000] <smaug____>
it is reasonable well spec'ed but just hard to read

[13:08:35.0000] <rniwa>
smaug____: yeah... at least we don't have multiple-generations of shadow tree craze anymore

[13:08:47.0000] <smaug____>
yeah, that was super complicated

[13:09:23.0000] <rniwa>
smaug____: yeah, when each host has multiple generations of shadow roots with distribution happening in each

[13:09:26.0000] <rniwa>
smaug____: with shadow element

[13:09:30.0000] <rniwa>
smaug____: and then those things are nested

[13:09:45.0000] <rniwa>
smaug____: all bets are off as to comprehending what the heck is happening to an event being dispatched


2018-09-08
[20:48:43.0000] <annevk>
rniwa: https://github.com/whatwg/dom/issues/685#issuecomment-419551665 is untrue

[20:49:16.0000] <annevk>
rniwa: the proposed behavior flips the listener invocation order for my example

[20:50:16.0000] <annevk>
rniwa: the capture listener would be invoked first; smaug____ was indicating Gecko already has this behavior sometimes

[20:51:13.0000] <annevk>
rniwa: i.e., even without shadow trees there would be a subtle change, but we need to make it as otherwise we expose shadow trees

[22:07:32.0000] <rniwa>
annevk: which example?

[23:01:16.0000] <annevk>
rniwa: https://github.com/whatwg/dom/issues/685#issuecomment-419355034

[23:02:00.0000] <rniwa>
annevk: yeah don't have a different behavior between Gecko vs WebKit/Blink, right?

[23:02:06.0000] <rniwa>
that* don't

[23:02:39.0000] <rniwa>
ugh... that* doesn't*

[23:02:54.0000] <annevk>
rniwa: per smaug____ for <input> there would be a difference

[23:03:04.0000] <rniwa>
annevk: I don't think so

[23:03:17.0000] <annevk>
rniwa: and with the PR there would be a difference

[23:03:29.0000] <rniwa>
annevk: how?

[23:03:44.0000] <annevk>
rniwa: capture listeners run first

[23:03:52.0000] <rniwa>
annevk: yeah but that has always been the case

[23:04:17.0000] <annevk>
No, for target the listeners would run in register order

[23:04:29.0000] <rniwa>
annevk: the only difference here is that capturing event listeners on the target that exists within a shadow tree gets invoked AFTER all capturing event listeners on ancestors of a shadow host were invoked

[23:04:38.0000] <annevk>
So bubble if registered first would run first

[23:04:48.0000] <rniwa>
annevk: right but only within shadow trees

[23:05:17.0000] <annevk>
rniwa: the PR affects the normal case too, no?

[23:05:22.0000] <rniwa>
annevk: i don't think so

[23:05:36.0000] <rniwa>
annevk: i'm pretty certain it wouldn't

[23:05:42.0000] <rniwa>
annevk: what happens is that in the world without a shadow tree

[23:06:01.0000] <rniwa>
annevk: the target's capturing event listener is the last thing we invoke in the capturing phase

[23:06:32.0000] <rniwa>
annevk: what breaks down in shadow DOM is that there could be multiple even targets on which event listeners are invoked with AT_TARGET

[23:06:57.0000] <rniwa>
annevk: as long as there is a single target, this odd capturing event listener ordering won't be happening

[23:07:37.0000] <rniwa>
annevk: it's true that capturing event listeners within UA shadow trees are happening after capturing event listeners of ancestors of those UA shadow hosts but I doubt any UA is exposing that kind of detail to the user land

[23:07:53.0000] <rniwa>
annevk: since most of events fired within a shadow tree aren't even exposed to the user land

[23:08:38.0000] <annevk>
I think we are still talking past each other

[23:08:53.0000] <rniwa>
ya

[23:09:14.0000] <annevk>
If a target has first a non-capture listener added and then a capture listener

[23:09:28.0000] <rniwa>
annevk: could you post an example in which event listeners will be invoked in different orders before/after your change / on Gecko vs. WebKit/Blink

[23:09:42.0000] <annevk>
The invocation order today is non-capture, then capture

[23:09:57.0000] <annevk>
Per PR it is capture, then non-capture

[23:10:09.0000] <rniwa>
annevk: oh I see.

[23:10:23.0000] <annevk>
In Gecko it depends on the target element type

[23:10:29.0000] <rniwa>
annevk: you're saying that on the target element, we'd invoke event listeners in the order they were registered

[23:10:41.0000] <annevk>
Today, yes

[23:10:46.0000] <rniwa>
annevk: as opposed to in the capturing then bubbling

[23:10:52.0000] <annevk>
Yes

[23:11:08.0000] <rniwa>
annevk: yeah, i'm a lot less concerned about that.

[23:11:13.0000] <annevk>
Ok

[23:11:18.0000] <annevk>
Good

[23:11:25.0000] <rniwa>
annevk: what's concerning is the event listeners on different elements getting invoked in different orders

[23:11:43.0000] <rniwa>
annevk: that's a lot likely to cause havocs in scripts that rely on particular ordering for stopping propagation, etc...

[23:12:04.0000] <annevk>
Yeah, I agree there is real risk for WebKit/Chromium here

[23:12:19.0000] <annevk>
I hope the experiment works out

[23:14:30.0000] <rniwa>
annevk: ya, i hope so too because what we have today is nuts

[23:17:59.0000] <rniwa>
annevk: so apparently ea.com and a bunch of other EA properties are using Polymer & web components in real

[23:18:02.0000] <rniwa>
smaug____: ^

[08:31:12.0000] <GPHemsley>
oh my word, what is this?? https://tools.ietf.org/html/rfc2396.html#section-3.3

[08:31:32.0000] <GPHemsley>
allowing parameters within each segment of a URL path??

[08:33:43.0000] <GPHemsley>
wait, what ever are parameters

[08:33:48.0000] <GPHemsley>
*even

[10:18:22.0000] <TabAtkins>
The "newer" URI syntax still allows those, but only references them obliquely; they're not reified in the grammar itself.

[10:18:38.0000] <TabAtkins>
https://tools.ietf.org/html/rfc3986#section-3.3

[12:34:39.0000] <zcorpan>
this <p> doesn't get a foster parent http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6210


2018-09-09
[16:27:50.0000] <GPHemsley>
methinks the Python urllib needs some expert attention


2018-09-11
[21:29:23.0000] <domfarolino>
annevk: Under the "setter" section of https://html.spec.whatwg.org/multipage/webappapis.html#event-handler-idl-attributes, what type is the "given value" in the case elem.onclick = function(e) {...}...I imagine it is a callback object, not a raw uncompiled handler?

[21:56:24.0000] <domfarolino>
annevk: I believe it is, I'm just trying to find out when an event handler's value will ever be created as an internal raw uncompiled handler. That seems to be in the attribute change steps, but I expected to see these steps being called from the parser or something

[22:05:26.0000] <annevk>
domfarolino: setAttribute

[22:12:24.0000] <domfarolino>
annevk: Hm, that's for when call from script right? How about when no script is running, and the browser is just parsing <link ... onload="whereDoesThisGetParsed?"> I kinda expect something like DOM's set-attribute and set-an-attribute-value to be called at some point?

[22:18:54.0000] <annevk>
domfarolino: that will do so per the parser

[22:19:06.0000] <annevk>
domfarolino: might not all be linked up

[22:24:22.0000] <domfarolino>
annevk: Ok thanks

[22:29:46.0000] <domfarolino>
annevk: One more (unrelated to event handlers) question: in https://html.spec.whatwg.org/multipage/semantics.html#interactions-of-styling-and-scripting, we have a list of conditions that, if met, make a style sheet one that "blocks scripts".

[22:30:17.0000] <domfarolino>
annevk:  I'd expect after a script-blocking style sheet is obtained, one of those conditions would definitely not hold, so that we can effectively decrement the number of script-blocking ss's. Is that what the purpose of the `style sheet ready` flag is?

[22:31:19.0000] <annevk>
 Dunno offhand

[22:31:38.0000] <annevk>
Can check in ~2h

[22:32:24.0000] <domfarolino>
annevk: Regardless, it seems that if those conditions are used to determine whether a style sheet is script-blocking, it's hard to distinguish a style sheet that has successfully loaded, and thus is no longer script-blocking, from one that is.

[22:32:32.0000] <domfarolino>
Sure sure no worries, sorry to ping so early

[22:42:25.0000] <annevk>
Hmm yeah, maybe; Emilio also mentioned (somewhat related) that matching the environment requires layout for iframes and such and is therefore more fuzzy than one might expect

[23:48:21.0000] <domfarolino>
annevk: I'll add a comment to https://github.com/whatwg/html/pull/3544 in the morning about maybe explicitly making a style sheet non-script-blocking after it has been obtained. Yeah it would be nice to have "matching" defined (is it?) somewhere...that's a good point. Should we file an issue to harden that?

[23:49:54.0000] <domfarolino>
Oh, wait it is defined whoops. But yeah if that's more fuzzy than expected it might be nice to clean that up? Not sure how to though

[00:09:51.0000] <annevk>
Yeah, not sure either

[04:43:11.0000] <lgrahl>
https://discourse.wicg.io/ <-- why was I not aware of this awesome place

[08:51:46.0000] <domfarolino>
Domenic: Oh sorry, didn't see your latest comment on https://github.com/whatwg/html/issues/3610 before posting mine :)

[08:58:38.0000] <domfarolino>
(Question in my comment may help me write a test under https://github.com/web-platform-tests/wpt/tree/master/html/semantics/document-metadata/interactions-of-styling-and-scripting testing that script-blocking style sheets have their events fired before script execution)

[09:01:42.0000] <hoishin>
:disconnect chat.freenode.net

[09:07:21.0000] <annevk>
domfarolino: it seems it isn’t really defined when that flag gets set

[09:07:56.0000] <annevk>
domfarolino: I’d expect it to be set as part of the task dispatching the load event

[09:08:43.0000] <annevk>
(Forgot to look at it earlier, sorry)

[09:10:31.0000] <domfarolino>
annevk: Agreed, I think it could be (potentially renamed to "style sheet resolved" and) and used in https://html.spec.whatwg.org/multipage/semantics.html#obtaining-a-resource-from-a-link-element:critical-subresources to remove the given resource from the set of script-blocking resources

[09:11:18.0000] <annevk>
domfarolino: reason to rename?

[09:11:58.0000] <domfarolino>
"style sheet ready" very much indicates that it obtained successfully (IMO). I think it'd be nice to be more general, since even resources that were failed to obtain are at least no longer script-blocking

[09:12:35.0000] <annevk>
domfarolino: ah, prefer “done” then due to promises

[09:12:43.0000] <domfarolino>
+1

[09:14:04.0000] <domfarolino>
annevk: Also if you happen to have an answer for https://github.com/whatwg/html/issues/3610#issuecomment-420322487 that would help me file a chrome bug :)

[09:21:07.0000] <domfarolino>
If we make the setting of the “style sheet ready/done” flag part of the task that gets fired, then of course script execution will be blocked on both obtaining the resource _and_ firing the event. But since it isn’t entirely clear (to me) when a resource becomes non-script-blocking, I can’t tell if the ordering of the fired event and script script execution is well-specified (though IMO it should be)

[09:21:41.0000] <annevk>
domfarolino: it depends on specifying that flag

[09:22:06.0000] <annevk>
domfarolino: so once that is done it’ll be the first option

[09:23:21.0000] <domfarolino>
thank you very much!

[09:57:08.0000] <zcorpan>
anyone know how to get hard line wrapping to work well in Sublime Text?

[10:17:35.0000] <TabAtkins>
zcorpan: You mean automatically inserting a hard line break when it auto-wraps at some column?

[10:32:59.0000] <zcorpan>
That would be nice, or just a keyboard shortcut to wrap the selection would be ok as well. The built-in one seems kinda broken; it doesn't collapse the indentation to a single space and it preserves existing newlines

[10:33:52.0000] <zcorpan>
hard wrap in TextWrangler/BBEdit worked better

[10:41:35.0000] <Domenic>
zcorpan: for HTML I always copy and paste text through https://output.jsbin.com/maferi . Should work on turning that logic into a Sublime plugin.

[10:52:49.0000] <zcorpan>
Domenic: thanks. I'll try making a plugin some day

[16:43:32.0000] <zcorpan>
is there something that has replaced https://wiki.whatwg.org/wiki/sanitization_rules ?

[16:45:55.0000] <zcorpan>
alternatively, known-good html sanitizers that follows the spec for how to parse html

[16:46:54.0000] <Domenic>
I think the canonical answer is https://github.com/cure53/DOMPurify

[16:51:52.0000] <zcorpan>
thanks


2018-09-12
[17:23:13.0000] <MikeSmith>
would it make sense for the Web Locks API to be incorporated into the HTML spec, or is it better for it to be managed as a separate spec?

[17:23:17.0000] <MikeSmith>
https://wicg.github.io/web-locks/

[17:24:05.0000] <MikeSmith>
it doesn’t do any monkey patching of algorithms in HTML or DOM

[19:37:28.0000] <Domenic>
I was wondering about storage.spec.whatwg.org

[19:37:34.0000] <Domenic>
Its own spec might be fine though

[09:40:11.0000] <MikeSmith>
why is that when I do Object.getOwnPropertyNames(Window) I get essentially next to nothing

[09:40:48.0000] <MikeSmith>
compared to Object.getOwnPropertyNames(window)

[09:41:53.0000] <MikeSmith>
in browsers, where do all those properties of the window instance originally come from

[09:42:03.0000] <jgraham>
MikeSmith: Are the properties on Window.prototype?

[09:42:22.0000] <jgraham>
/me doesn't remember enough webidl to answer this question

[09:42:24.0000] <MikeSmith>
no

[09:42:48.0000] <MikeSmith>
at least there not there if you inspect Window.prototype in devtools

[09:43:19.0000] <MikeSmith>
so if they are not from Window.prototype where are they from

[09:44:10.0000] <MikeSmith>
I guess it’s just that the Window/window case is some kind of very special case?

[12:43:13.0000] <annevk>
MikeSmith: it is

[12:45:38.0000] <annevk>
MikeSmith: they are on the instance, but you also can never really get there due to WindowProxy (in a worker you can though); named properties are on the prototype chain though and likely EventTarget

[15:05:37.0000] <MikeSmith>
annevk: I see

[15:06:39.0000] <MikeSmith>
so for MDN, this makes me wonder how the properties should rightly be documented

[15:08:29.0000] <MikeSmith>
e.g., I would think the title of https://developer.mozilla.org/en-US/docs/Web/API/Window/closed should rightly be window.closed instead of Window.closed

[15:10:04.0000] <MikeSmith>
and MDN should make it more clear that window is the special global object

[15:12:01.0000] <MikeSmith>
but since MDN article paths seem to be case-insensitive, https://developer.mozilla.org/en-US/docs/Web/API/window and https://developer.mozilla.org/en-US/docs/Web/API/Window are the same article


2018-09-13
[17:03:29.0000] <Domenic>
Yeah, it's a good point that the prototype mechanism is not in use for Window and a couple other things (e.g. Location's properties)

[17:03:48.0000] <Domenic>
You could still do something like "Window's close() method" or "Window: close() method"

[17:04:14.0000] <Domenic>
But it would indeed be a bit different, as its every instance of Window having its own individual close() method, not Window.prototype sharing it between all of them

[18:43:53.0000] <MikeSmith>
Domenic: yeah as far as documenting it, it doesn’t fit neatly with other documentation

[18:45:05.0000] <MikeSmith>
but maybe the difference is not something that matters in practice to developers, so not worth bending over backwards in the documentation to be very precise about it

[18:46:22.0000] <MikeSmith>
I guess writing good documentation for web-platform features can be as difficult as writing good specs for them

[20:48:21.0000] <annevk>
Not possible to get multiple instances though

[20:54:54.0000] <MikeSmith>
right

[20:56:52.0000] <Domenic>
You can get multiple instances... e.g. iframe.contentWindow

[20:57:09.0000] <Domenic>
(Yes, it's a WindowProxy, but it transparently passes through Window properties in the same-origin case.)

[21:02:52.0000] <MikeSmith>
so that’s a nice concrete case to look at the MDN docs for

[21:03:08.0000] <MikeSmith>
https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement/contentWindow

[21:03:46.0000] <MikeSmith>
> This attribute is read-only, but its properties can be manipulated like the global Window object.

[21:06:50.0000] <MikeSmith>
that seems to kind of assume the reader already knows that iframe elements have a separate Window instance

[21:07:39.0000] <MikeSmith>
which is not really clearly stated even in https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe

[21:08:28.0000] <MikeSmith>
but I guess you learn that quickly if you ever try to actually do anything with an iframe from code

[01:05:31.0000] <annevk>
rniwa: if capture listeners, then bubble listeners is not web-compatible, I think if we want to avoid detection of shadow trees, we'd need to keep the current spec

[01:05:53.0000] <annevk>
rniwa: really appreciate that detailed write-up on your composedPath() patch btw

[01:07:07.0000] <rniwa>
annevk: yeah, we'd see.

[01:08:40.0000] <rniwa>
annevk: haha, the algorithm is so clever i would have filed a patent if it weren't for a spec'ed text.

[01:08:54.0000] <rniwa>
annevk: but once you see it, you can't unsee it. it's so simple!

[01:09:38.0000] <annevk>
rniwa: yeah, just need to translate it to spec text now

[01:16:53.0000] <rniwa>
annevk: I do have a webkit patch for the event listener now: https://bugs.webkit.org/show_bug.cgi?id=174288

[01:16:57.0000] <rniwa>
annevk: so we'll see how it goes.

[01:17:27.0000] <annevk>
thanks, hoping for the best

[01:18:05.0000] <annevk>
rniwa: did you consider combining the composedPath() thing with the bit you need to hide window.event from shadow trees?

[01:18:17.0000] <annevk>
rniwa: e.g., depth +2 for closed and +1 for open shadow trees

[01:18:59.0000] <annevk>
anyway, prolly keeping them as separate bits in the spec

[01:19:22.0000] <rniwa>
annevk: oh, we could do that but it's probably cleaner as two separate things

[01:20:55.0000] <annevk>
Yeah, I got too excited there

[05:50:45.0000] <annevk>
Making a patch for that was still rather involved

[09:03:51.0000] <JakeA>
annevk: Any idea who should I talk to at Moz about interest in https://wicg.github.io/background-fetch/?

[09:22:36.0000] <Domenic>
MikeSmith: annevk: did we have a plan for the "impacts documentation" label? E.g. are we supposed to ping some MDN folks, or are they watching the label, or...?

[09:22:42.0000] <Domenic>
About to merge https://github.com/whatwg/html/pull/3829

[09:24:12.0000] <annevk>
JakeA: I'm gonna nominate mdaly and asuth (both @mozilla.com)

[09:24:20.0000] <annevk>
JakeA: you can copy me I suppose

[09:24:39.0000] <annevk>
Domenic: https://github.com/whatwg/meta/pull/89

[09:24:39.0000] <JakeA>
Ta!

[09:25:12.0000] <Domenic>
annevk: OK, so nothing for us to do necessarily

[09:25:32.0000] <annevk>
Domenic: no, I guess it remains to be seen if it's helping

[09:35:16.0000] <MikeSmith>
Domenic: I watch that label at least, and I can let other people on #mdn know about specific PRs like https://github.com/whatwg/html/pull/3829

[09:38:35.0000] <Domenic>
Awesome, ok.

[09:43:03.0000] <zcorpan>
MikeSmith: should we have a bot to report issues for mdn when the label is added?

[09:43:27.0000] <MikeSmith>
zcorpan: that would be good yeah

[10:59:09.0000] <Domenic>
devsnek: what are your plans for the async iterable streams PR?

[10:59:26.0000] <devsnek>
Domenic: do whatever those comments say

[10:59:34.0000] <Domenic>
:)

[10:59:38.0000] <Domenic>
Thoughts on implementation/tests?

[10:59:52.0000] <devsnek>
oh yeah that too lol

[11:00:05.0000] <devsnek>
i can bang out an impl but i'm absolutely terrible at tests

[11:00:15.0000] <Domenic>
They're not too bad I promise

[11:00:27.0000] <Domenic>
And they help a lot with all these edge cases people are pointing out

[11:00:34.0000] <zcorpan>
/me wakes up

[11:00:39.0000] <zcorpan>
anyone want help with tests?

[11:01:05.0000] <Domenic>
Haha. This would be for https://github.com/whatwg/streams/pull/954

[11:01:27.0000] <devsnek>
i'm gonna get to it again this weekend so eh you can go back to sleep :P

[11:02:13.0000] <zcorpan>
Domenic: should i add Streams for 2019?

[11:02:56.0000] <Domenic>
zcorpan: probably not, I think we've got a decent handle on things, just sussing out whether devsnek's up for extending his first-time contribution past the spec into tests as well, or whether the editors should help :)

[11:03:11.0000] <zcorpan>
okie

[11:03:34.0000] <devsnek>
i can write some basic tests, i'm just really bad at imagining how people will misuse things

[11:04:28.0000] <zcorpan>
I think I'm not terrible at that, would be happy to help whip up a list of interesting cases to test

[11:04:29.0000] <Domenic>
Maybe we can work out a test plan together on the issue

[11:04:31.0000] <Domenic>
Yeah

[11:04:51.0000] <devsnek>
what if people just never made bugs

[11:06:39.0000] <zcorpan>
https://i.imgflip.com/wu987.jpg

[11:13:36.0000] <zcorpan>
I'm not too familiar with testing JS stuff, but https://github.com/tc39/test262/search?q=asynciterator&unscoped_q=asynciterator might be a good start to look at. I've also asked my colleagues who have written tests for async iterators to chime in

[11:14:07.0000] <devsnek>
thx

[11:33:24.0000] <Domenic>
Alrighty, I made https://github.com/whatwg/streams/pull/954#issuecomment-421107013 , we'll see what people say

[11:36:10.0000] <devsnek>
Domenic: you're too pro

[12:15:59.0000] <zcorpan>
Domenic: why isn't streams a tc39 spec btw?

[12:18:21.0000] <Domenic>
zcorpan: tc39's working mode is not very compatible with streams. Ask me more offline :)

[14:31:13.0000] <MikeSmith>
Domenic: about the “impacts documentation” label, sheppy points out there’s no way to subscribe to github labels (so can’t get notifications that are filtered to just that label)

[14:32:10.0000] <MikeSmith>
I guess that’s part of the reaason we have teams for some other cases where we want to make sure specific set of people get notified

[14:32:46.0000] <MikeSmith>
so maybe we should add a “documentation” team?

[14:53:06.0000] <Domenic>
+1, sounds good to me

[15:00:19.0000] <MikeSmith>
Domenic: thanks


2018-09-14
[18:10:16.0000] <Domenic>
MikeSmith: I think we could also unblock the MDN work by temporarily reverting to URL segments instead of titles. Then the blocker is "just" review bandwidth.

[18:13:49.0000] <MikeSmith>
Domenic: good point, yeah

[18:14:28.0000] <MikeSmith>
and that’s a relatively easy revert, so I can do it right now and push it soonish

[18:17:07.0000] <Domenic>
Great. I *hope* to make time to review tomorrow in that case, but this week has been really crammed, so I can't promise.

[18:20:58.0000] <MikeSmith>
no worries, since it’s just an enhancement change and lack of it’s not blocking anybody else’s work

[18:21:36.0000] <MikeSmith>
and I should say thanks much for the review you’ve done so far ー I really appreciate it

[20:54:02.0000] <MikeSmith>
Domenic: OK, wattsi code switched back to using the URL segment, and output pushed to https://arcane-cove-57093.herokuapp.com/

[22:18:27.0000] <domfarolino>
annevk: https://github.com/whatwg/html/pull/3656 Also changes the default classic worker credentials mode correct?

[22:19:07.0000] <domfarolino>
I believe it does, just didn't see it mentioned in the thread

[22:43:50.0000] <domfarolino>
annevk: Nope it doesn't nvm

[00:38:46.0000] <MikeSmith>
annevk: about https://developer.mozilla.org/en-US/docs/Web/API/WorkerLocation

[00:38:53.0000] <MikeSmith>
> https://developer.mozilla.org/en-US/docs/Web/API/WorkerLocation

[00:38:55.0000] <MikeSmith>
oofs

[00:39:01.0000] <MikeSmith>
> The WorkerLocation interface doesn't inherit any property, but implements properties defined in the URLUtilsReadOnly interface.

[00:39:10.0000] <MikeSmith>
is the above true?

[00:40:10.0000] <MikeSmith>
if so I don’t see where it’s specified that it inherits properties defined in URLUtilsReadOnly

[00:41:18.0000] <MikeSmith>
https://html.spec.whatwg.org/multipage/workers.html#worker-locations doesn’t state anything about that

[00:42:07.0000] <MikeSmith>
oh, or is it because WorkerGlobalScope inherits?

[00:48:59.0000] <Ms2ger>
MikeSmith, that used to be true, but not anymore

[00:49:10.0000] <MikeSmith>
ah

[00:49:14.0000] <Ms2ger>
Does URLUtilsReadOnly even exist anymore?

[00:49:32.0000] <MikeSmith>
hmm, no

[00:49:45.0000] <MikeSmith>
I see that it actually does not exist anymore

[00:53:56.0000] <Ms2ger>
Well there we are :)

[00:57:13.0000] <MikeSmith>
Ms2ger: btw I’m curious what the WPT interface test for the Window object does, as far as checking the IDL from the spec

[00:57:48.0000] <Ms2ger>
Can you elaborate? :)

[00:58:57.0000] <MikeSmith>
/me looks at https://web-platform-tests.live/html/browsers/the-window-object/window-prototype-chain.html

[00:59:54.0000] <MikeSmith>
Ms2ger: I mean in that the properties aren’t exposed from the prototype the way they are for other IDL interfaces/objects

[01:01:35.0000] <MikeSmith>
yesterday Domenic and annevk clarified for me a bit about how it works, but I still don’t understand how we could test what was described to me

[01:01:38.0000] <Ms2ger>
MikeSmith, there's branches like this one: https://github.com/web-platform-tests/wpt/blob/8a062c149e4581de0cd92cb51f316247e9514e5d/resources/idlharness.js#L2117

[01:02:22.0000] <MikeSmith>
/me looks

[01:02:36.0000] <MikeSmith>
aha

[01:02:43.0000] <MikeSmith>
OK, that makes sense

[01:03:12.0000] <annevk>
MikeSmith: you can only observe it through WindowProxy

[01:04:14.0000] <annevk>
MikeSmith: so I guess you can study how that behaves (it's well defined)

[01:04:39.0000] <annevk>
MikeSmith: and if you then study the behavior for global objects in IDL you should have an idea how "window" works

[01:04:50.0000] <annevk>
(and how to poke at it)

[01:05:03.0000] <MikeSmith>
annevk: OK

[01:05:29.0000] <annevk>
MikeSmith: that leaves some complicated cases still, e.g., https://github.com/whatwg/html/issues/3997

[01:05:33.0000] <MikeSmith>
annevk: OK yeah I started to understand that from what you had pointed out yesterday. Was mostly left wondering how WPT idlharness handled it

[01:05:48.0000] <MikeSmith>
/me looks at https://github.com/whatwg/html/issues/3997

[01:06:00.0000] <annevk>
MikeSmith: ah okay, I'm not sure about idlharness unfortunately

[01:06:11.0000] <MikeSmith>
god this stuff is so messy

[01:06:21.0000] <MikeSmith>
e.g., teh https://github.com/whatwg/html/issues/3997 things

[01:06:26.0000] <MikeSmith>
*thing

[01:06:32.0000] <annevk>
uhuh

[01:07:27.0000] <annevk>
folks must have been really worried about their job 20 years ago, but then they moved on and left us with their job security/technical debt

[01:07:32.0000] <MikeSmith>
I can’t imagine any other runtime comes close to this in terms of complications like this, and quirks

[01:07:38.0000] <MikeSmith>
hahah

[01:07:51.0000] <annevk>
I hear Windows is pretty bad

[01:08:15.0000] <MikeSmith>
ah yeah maybe only that is anywehre close to being in the same class

[01:10:11.0000] <MikeSmith>
but I guess with development of most other runtimes, after the people who dumped all the bad designed stuff in there have moved on, the others who come in after can still (with enough time ane work) rip it out and replace it with something better

[01:10:21.0000] <MikeSmith>
and break some legacy APIs I guess

[01:11:25.0000] <MikeSmith>
I suppose that’s what it comes downto, other runtimes developers have the luxury of being able to break backward compat

[01:15:16.0000] <MikeSmith>
but what’s also depressing to think about it is that, rightly, all the web platform’s messiness should be clearly documented, along with being specced

[01:15:45.0000] <MikeSmith>
and there is nobody who gets up in the morning looking forward to writing good documentation for that kind of stuff

[01:15:58.0000] <Ms2ger>
Anne does!

[01:16:03.0000] <MikeSmith>
hahah

[01:16:09.0000] <Ms2ger>
Or I choose to believe that

[01:16:17.0000] <MikeSmith>
thank heavens we got Anne

[01:16:43.0000] <MikeSmith>
maybe we can talk Anne into writing docs along with speccing everything

[01:17:14.0000] <MikeSmith>
but short of that, at least reviewing

[01:17:51.0000] <Ms2ger>
Do we really need these intricacies documented outside the spec, though?

[01:17:58.0000] <Ms2ger>
/me would be fine with "here be dragons"

[01:18:02.0000] <MikeSmith>
I dunno

[01:18:11.0000] <MikeSmith>
yeah maybe so

[01:18:34.0000] <Ms2ger>
Might be worth putting a stack of motivating examples in the spec, if we don't have them yet

[01:19:01.0000] <MikeSmith>
well partly that’s what we have MDN for

[01:19:26.0000] <MikeSmith>
I personally don’t think loading the spec itself down with yet more non-normative stuff is the optimal solution

[01:20:29.0000] <MikeSmith>
but the particular problem that concerns me right now is that after we add MDN annotations to the spec, readers following the links in the annotations and reading the MDN content are going to expect that it clarifies their understanding

[01:20:46.0000] <MikeSmith>
and the vast majority of cases, the MDN docs do that, quite well

[01:21:25.0000] <MikeSmith>
but the existing MDN docs for these cases like Window are a different matter

[05:45:38.0000] <gsnedders>
MikeSmith: by way of contrast, I'm in favour of adding non-normative text to the spec if it helps people who don't already know the area intimately be able to read it

[06:35:30.0000] <JakeA>
https://heycam.github.io/webidl/#idl-dictionaries - The identifier is the key name of the key–value pair. If the Type is an identifier followed by ?, then the identifier must identify an interface, enumeration, callback function or typedef. If the dictionary member type is an identifier not followed by ?, then the identifier must identify any one of those definitions or a dictionary.

[06:35:45.0000] <JakeA>
I keep reading this, but I have no idea what it means :D

[06:36:02.0000] <JakeA>
Can anyone help? What does ? mean in a dictionary?

[06:43:43.0000] <zcorpan>
JakeA: if you use a ? you can't use a dictionary type

[06:45:53.0000] <JakeA>
zcorpan: As in a dictionary within a dictionary? What's the benefit of ? then, other than asserting the type isn't a dictionary?

[06:46:20.0000] <zcorpan>
right

[06:46:25.0000] <zcorpan>
the ? means that null is allowed

[06:46:34.0000] <JakeA>
Riiiiight!

[06:46:38.0000] <zcorpan>
but you can't use nullable together with a dictionary

[06:47:08.0000] <zcorpan>
since dictionaries are implicitly present if you say null

[06:47:18.0000] <JakeA>
I think it'd have taken me a few months of reading that paragraph over and over again to figure that out

[06:47:39.0000] <JakeA>
Thanks for clearing that up

[06:47:54.0000] <zcorpan>
happy to help. I'll send you the bill :-P

[06:47:59.0000] <JakeA>
\o/

[07:20:31.0000] <Domenic>
annevk: TabAtkins: any remaining concerns about "htmlsvg-global/nonce" for https://github.com/whatwg/html/pull/4032 ? Would like to merge if not.

[07:21:07.0000] <annevk>
Domenic: I'm pushing a nit

[07:21:19.0000] <TabAtkins>
Nah go for it

[07:21:22.0000] <annevk>
(autowrapping tooling would be really nice)

[07:22:01.0000] <JakeA>
/me grumbles something about soft wrapping being better

[07:22:40.0000] <Domenic>
3... 2... 1...

[07:22:51.0000] <Domenic>
(that's my countdown for TabAtkins telling us how semantic wrapping is better.)

[07:23:40.0000] <TabAtkins>
:bursts in, gasping and out of breath:

[07:23:59.0000] <annevk>
(spaces)

[07:24:07.0000] <Domenic>
(oh nooooo)

[07:24:24.0000] <TabAtkins>
:somehow bursts in a second time:

[07:24:32.0000] <annevk>
🍿

[07:34:51.0000] <astearns>
(rgb is the best way to specify colors)

[07:36:58.0000] <annevk>
/me papayawhips astearns

[07:46:21.0000] <nox>
astearns: #rgb only of course, no one needs #rrggbb.

[07:51:19.0000] <annevk>
zcorpan: do we have tests for a fieldset with multiple legend elements where the first legend element is floated or positioned?

[07:51:30.0000] <annevk>
zcorpan: no need for a pointer, just curious

[07:52:50.0000] <zcorpan>
annevk: yes. also with dynamically changing the style

[07:53:02.0000] <annevk>
zcorpan: good times were had I'm sure

[07:53:24.0000] <zcorpan>
I didn't find any bugs with that test actually

[07:53:31.0000] <zcorpan>
surprisingly

[08:29:27.0000] <Domenic>
If we make <ul> support type="", should it also support start=""? /cc TabAtkins

[08:29:43.0000] <Domenic>
Firefox apparently supports the content attribute but not the IDL attribute

[08:29:49.0000] <domfarolino>
annevk: Is the total reach of changing default classic script fetch options in https://github.com/whatwg/html/pull/3656 just making imports from classic workers be same-origin credentials, or is that inaccurate

[08:30:22.0000] <TabAtkins>
Meh, no opinion

[08:30:44.0000] <TabAtkins>
Start comes with value on the li, of course

[08:31:25.0000] <annevk>
domfarolino: it shouldn't affect class workers as they were same-origin bound anyway

[08:31:31.0000] <annevk>
classic workers*

[08:33:26.0000] <Domenic>
domfarolino: this is mainly about <script type=module>

[08:35:03.0000] <domfarolino>
Indeed, but I noticed `fetch a classic worker script` uses same-origin credentials (of course), but returns a script made from default classic script fetch options (omit creds). Is this the options that "referencing script" will have, when import()ing?

[08:36:00.0000] <domfarolino>
If so, I'm wondering if changing that will change the credentials mode that these imports() will be fetched with? (sorry, I could easily be getting lost in the cross-linking)

[09:03:52.0000] <domfarolino>
Domenic: would that apply if a classic worker has a cross-origin import?

[09:08:15.0000] <Domenic>
Hmm I aww

[09:08:18.0000] <Domenic>
*Hmm I see

[09:08:36.0000] <Domenic>
It seems like it would impact import()s from workers too, yeah

[09:08:38.0000] <Domenic>
But it should

[09:08:47.0000] <Domenic>
The idea is to just have same-origin credentials mode everywhere

[09:09:36.0000] <Domenic>
Unless changed via <script type=module crossorigin="use-credentials"> or new Worker(url, { credentials: "include" })

[09:15:40.0000] <domfarolino>
Domenic: the latter actually wouldn’t have an effect I think, since the credentials member is only used for module workers IIRC. But yes that makes sense, I was just trying to see if we’ll need another intent for chrome, since changing default classic worker creds is different from changing <script type=module>.

[09:18:37.0000] <domfarolino>
s/default classic worker creds/default classic script fetch options (and therefore classic worker descendent imports)

[09:31:28.0000] <domfarolino>
We'll also probably need descendent worker credentials tests (they seem missing)

[09:41:15.0000] <annevk>
domfarolino: aah well spotted, it does affect that and maybe importScripts()? That used to use “include” like regular scripts. Hmm

[09:44:11.0000] <domfarolino>
importScripts() yes

[09:45:00.0000] <domfarolino>
Oh interesting. Also I guess it’s a little odd that descendant classic worker scripts can’t be fetched with “include” credentials

[09:48:40.0000] <domfarolino>
Ugh, descendant classic worker imports**

[10:33:01.0000] <annevk>
That also goes for some other fetch options, but perhaps this one is particularly annoying…

[10:34:21.0000] <annevk>
Perhaps we need to change classic back to include

[10:35:28.0000] <annevk>
I might not have considered “subfetches” carefully enough, sigh

[10:36:26.0000] <annevk>
Why all this infrastructure is to be managed by only a couple people is beyond me, it could really use more attention

[10:50:40.0000] <domfarolino>
annevk: I'll write a comment on the PR attempting to summarize all of the changes introduced, and link to whatever tests exists, and whatever tests need written etc.

[10:51:09.0000] <domfarolino>
Yeah, it's very "gnarly" infra. Cool though

[11:54:10.0000] <annevk>
domfarolino: that’s great, thanks!


2018-09-15
[07:18:17.0000] <sjamaan>
I'm having some trouble getting bikeshed to work

[07:19:01.0000] <sjamaan>
[Errno 2] No such file or directory: u'/home/sjamaan/src/bikeshed/venv/lib/python2.7/site-packages/bikeshed/spec-data/readonly/version.txt'

[07:19:13.0000] <sjamaan>
I installed it with "pip install ." and also tried setup.py install

[07:20:43.0000] <sjamaan>
Copying the spec-data dir manually gives me another error when trying "make local" in the url repo:

[07:20:47.0000] <sjamaan>
FATAL ERROR: Couldn't find an appropriate include file for the defaults inclusion, given group='whatwg' and status='None'.

[11:59:26.0000] <annevk>
sjamaan: sounds like an old version; you can use make remote to avoid installing it though

[13:16:05.0000] <sjamaan>
annevk: I just cloned bikeshed, and master is up to date

[13:16:12.0000] <sjamaan>
Same for url

[13:40:22.0000] <TimothyGu>
sjamaan: did you follow the official installation guide

[13:40:43.0000] <TimothyGu>
https://tabatkins.github.io/bikeshed/#install-common

[13:41:53.0000] <TabAtkins>
Also you don't have a Status, which should be reported in another error.

[13:43:08.0000] <TabAtkins>
But yeah, follow the installation instructions as written, sounds like you're trying to wildcat it. 😀

[13:51:15.0000] <sjamaan>
hm, seems to work now

[13:51:41.0000] <sjamaan>
I suppose the --editable is what did the trick

[13:51:52.0000] <sjamaan>
Now I feel silly :)

[13:51:53.0000] <sjamaan>
Thanks

[14:33:37.0000] <devsnek>
Domenic: for tests, i should pr to wpt and then once that's merged run it against the reference impl right?

[14:34:21.0000] <Domenic>
devsnek: that's the idea, although it can be easier to develop locally. See https://github.com/whatwg/streams/tree/master/reference-implementation#tests

[14:34:50.0000] <devsnek>
yeah i'll make sure its all working before i pr

[15:26:22.0000] <innovati>
okay…who wrote the 3rd example under here, <nav> with prose: https://html.spec.whatwg.org/#the-nav-element

[16:45:22.0000] <Domenic>
Almost certainly Hixie


2018-09-16
[18:55:10.0000] <innovati>
<3 what a fun example

[19:10:43.0000] <domfarolino>
annevk: Do you know of a bug on bugzilla for the <script type=module> credentials change?

[21:34:08.0000] <annevk>
domfarolino: nothing linked from the issue/PR/tests PR?  Anyway, not offhand

[21:34:43.0000] <domfarolino>
I don’t think there was anything linked from there. I’ll file

[22:00:10.0000] <annevk>
Perhaps from the Fetch PR if we made that cover all somehow

[00:47:09.0000] <domfarolino>
Ah. I’ll check

[02:25:50.0000] <sjamaan>
Where does bikeshed get its references from?  I added [[!STD68]] and it "just worked"

[02:38:38.0000] <sjamaan>
ah, found biblio-st.data

[05:31:37.0000] <sjamaan>
I have a question about the Participation Agreement.  The "signing as an individual" says "I represent that I do not work in the field of web technologies as an employee, contractor, or agent of another person or legal entity, and make this Agreement in my personal capacity only."

[05:31:56.0000] <sjamaan>
What exactly does this mean?

[08:30:42.0000] <devsnek>
is there anything i should do to mark the async iterator test as needing Symbol.asyncIterator

[08:37:32.0000] <devsnek>
do i have to make an html file for this?

[09:46:12.0000] <Domenic>
devsnek: no need to mark, and you need to run the html file wrapper generator script

[09:46:28.0000] <devsnek>
so html files are required?

[09:46:51.0000] <devsnek>
what happened to putting things that only need js in js files :(

[09:47:41.0000] <Domenic>
devsnek: https://github.com/web-platform-tests/wpt/issues/10597

[09:48:36.0000] <devsnek>
so the runner just needs to be updated?

[09:49:15.0000] <Domenic>
And probably some of the boilerplate in each test needs fixing, and all the test files need renaming

[09:49:41.0000] <Domenic>
domenic/wpt-runner being updated is only necessary if you want to run the tests without a browser

[09:49:46.0000] <devsnek>
i guess i'll just do .html for now

[09:50:55.0000] <Domenic>
yeah probably best to avoid shaving that yak

[09:51:08.0000] <devsnek>
much sad

[10:33:33.0000] <TabAtkins>
sjamaan: Ultimately it gets its reference data from SpecRef.org

[10:35:45.0000] <TabAtkins>
sjamaan: If you work for a browser or other "web technologies" company, then you're in the domain of W3C membership, and can only "participate" as a W3C member (unless you get an exception to be an Invited Expert or the like).

[10:43:25.0000] <sjamaan>
TabAtkins: I work for a company that creates web applications, I suppose that doesn't fall under this clause?

[10:43:32.0000] <TabAtkins>
I have no idea!

[10:43:43.0000] <sjamaan>
The wording isn't exactly crystal clear

[10:44:01.0000] <TabAtkins>
Having always worked either as an IE or for a W3C-member company, I don't actually know the boundaries of this. ;_;

[10:44:40.0000] <sjamaan>
I'd appreciate if someone could clarify

[14:32:42.0000] <JKingWeb>
I'm a bit confused about the EUC-JP decoder. According to the Encoding specification, byte 5C should decode to a reverse solidus, and this is what Firefox and Vivaldi both do. The test suite, on the other hand, affirms that it should decode to a yen sign like happens with Shift_JIS---and yet both Firefox and Vivaldi claim to pass the test.

[14:32:42.0000] <JKingWeb>
And to pile on more uncertainty, per the specification the encoder is supposed to encode a yen sign into the single byte 5C. I'm at a loss.


2018-09-17
[17:45:56.0000] <MikeSmith>
TabAtkins: I think sjamaan was referring to the WHATWG Participant Agreement

[17:46:13.0000] <TabAtkins>
Ah!

[17:48:51.0000] <MikeSmith>
TabAtkins: btw given a particular spec, if there were a (relatively) easy way to get data about MDN articles that have links to parts of that spec, would be be supportive of adding a mechanism to to Bikeshed that inserted MDN annotations in spec output?

[17:49:08.0000] <TabAtkins>
Yes. Same as the caniuse data.

[17:49:15.0000] <MikeSmith>
cool

[17:50:39.0000] <MikeSmith>
the bad news is that there currently is no easy way to get the data; MDN doesn’t expose any API for it (nor really any APIs at all)

[17:51:10.0000] <MikeSmith>
the better news is that I raised https://discourse.mozilla.org/t/proposal-have-mdn-api-provide-data-for-all-specs-linked-to-in-specifications-tables/31768 to propose that something be added

[17:52:07.0000] <MikeSmith>
sjamaan: see the discussion at https://github.com/whatwg/sg/issues/84

[17:53:19.0000] <MikeSmith>
from Google’s rep on the WHATWG steering group, latest comment (from a month ago) is at https://github.com/whatwg/sg/issues/84#issuecomment-413366864

[17:53:33.0000] <MikeSmith>
> The SG is considering this issue and we will, at the least, work on a detailed FAQ that would clarify the language and help make quicker decisions in such situations. We are getting legal counsel and will report back on this, as soon as possible.

[23:33:41.0000] <davedoesdev>
hi

[23:34:54.0000] <davedoesdev>
I'm trying to pass a ReadableStream as the body of a fetch POST request

[23:36:07.0000] <davedoesdev>
(Chrome) However, nothing is read from the stream and "[object Object]" is sent

[23:40:30.0000] <davedoesdev>
Regarding the API, should this work?

[23:40:48.0000] <davedoesdev>
https://www.irccloud.com/pastebin/jh8rOYve/

[23:53:08.0000] <davedoesdev>
I see it's not supported yet in browsers (https://developer.mozilla.org/en-US/docs/Web/API/Request/Request)

[23:56:47.0000] <sjamaan>
MikeSmith: Thanks for the link. Seems it isn't exactly clear yet :S

[02:05:18.0000] <annevk>
sjamaan: basically, when in doubt, try to get your employer to sign it, as it'll be less hassle

[02:05:36.0000] <annevk>
sjamaan: less of a waiting period anyway

[02:05:50.0000] <sjamaan>
hm, ok, I'll ask around

[02:06:02.0000] <annevk>
sjamaan: we're trying to get it clarified, but I'm not expecting things to change around quickly

[02:06:13.0000] <annevk>
sjamaan: it took 1.5y to get this thing off the ground to begin with...

[02:06:19.0000] <sjamaan>
yikes

[02:11:02.0000] <Ms2ger>
And that was after what, nine years of trying to avoid setting it up? :)

[02:11:22.0000] <sjamaan>
heh

[02:31:23.0000] <MikeSmith>
'']

[02:31:26.0000] <MikeSmith>
']]'

[02:31:29.0000] <MikeSmith>
\'

[02:32:59.0000] <MikeSmith>
\

[02:33:17.0000] <MikeSmith>
\A

[02:56:57.0000] <MikeSmith>
\A[=]

[03:06:52.0000] <lgrahl>
Dropping this here for you to perhaps share (because I know some of you've already added their two cents): https://discourse.wicg.io/t/streams-for-the-proposed-webrtc-quic-api/3035

[07:11:33.0000] <devsnek>
isn't quic dead by http2 and tls 1.3

[07:18:59.0000] <lgrahl>
Perhaps for serving web pages. But none of them are usable for RTC.

[07:20:01.0000] <Ms2ger>
Can anyone merge https://github.com/heycam/webidl/pull/577 ?

[07:20:07.0000] <Ms2ger>
TimothyGu?

[07:20:10.0000] <Ms2ger>
Domenic?

[07:20:42.0000] <Ms2ger>
annevk?

[07:23:43.0000] <annevk>
Ms2ger: as rebase & merge?

[07:24:06.0000] <Ms2ger>
annevk, yes please, and thank you

[07:24:18.0000] <annevk>
Hmm, it doesn't quite meet the commit message guidelines...

[07:25:55.0000] <annevk>
And I don't know if those are enforced for IDL

[07:26:08.0000] <annevk>
I'll ping Domenic

[07:55:15.0000] <Ms2ger>
"Allow edits from maintainers." is on if so

[08:14:48.0000] <annevk>
Ms2ger: if there's still nobody caring tomorrow I'll make it happen (maybe after another ping)

[08:14:59.0000] <Ms2ger>
Thanks

[13:54:20.0000] <Domenic>
lgrahl: this kind of thing should come up in TAG review; not sure if those people have filed for that yet or not

[14:26:35.0000] <JKingWeb>
Okay, I see what's going on with the EUC-JP decoder test now, at least: the test harness uses the expectations in the test data only for display, with the actual expectations being the output of a reference implementation. That explains with browsers pass, and it just means that the test data are a bit stale.

[14:34:17.0000] <lgrahl>
Domenic: Found an issue: https://github.com/w3ctag/design-reviews/issues/303

[14:45:53.0000] <lgrahl>
Domenic: Martin Thomson already mentioned the streams API in that issue. Hopefully they'll pick it up in a review.

[14:46:27.0000] <lgrahl>
Thanks for mentioning TAG. (I actually didn't know anything about them...)


2018-09-18
[09:36:32.0000] <smaug____>
Is it possible to see who has registered to come to TPAC?

[09:36:50.0000] <smaug____>
MikeSmith: you might know

[09:40:58.0000] <MikeSmith>
smaug____: yeah, gimme a minute

[09:43:41.0000] <MikeSmith>
smaug____: https://www.w3.org/2002/09/wbs/35125/TPAC2018/registrants shows registrants by group

[09:44:03.0000] <MikeSmith>
(member-only)

[09:44:19.0000] <smaug____>
Nice url. 2002 ... 2018 ;)

[09:44:58.0000] <smaug____>
Thanks

[09:45:18.0000] <MikeSmith>
cheers

[09:58:21.0000] <gsnedders>
(MO though)


2018-09-19
[01:07:14.0000] <MikeSmith>
https://stackoverflow.com/questions/52390368/array-state-will-be-cached-in-ios-12-safari-is-bug-or-feature

[16:09:58.0000] <devsnek>
what if there were a feature where a website could say "make all future links open in this same tab"

[16:10:13.0000] <devsnek>
maybe even like register a history push state handler

[16:10:19.0000] <TimothyGu>
window.open()?

[16:10:30.0000] <TimothyGu>
and <a target="abc">

[16:10:31.0000] <devsnek>
for instance music.youtube.com links

[16:10:41.0000] <devsnek>
would navigate music.youtube.com ui

[16:10:45.0000] <devsnek>
instead of opening a new tab

[16:11:30.0000] <TimothyGu>
for (const el of $$('a[href]')) { a.addEventListener('click', () => {...}); }

[16:11:30.0000] <TimothyGu>
?

[16:11:38.0000] <TimothyGu>
s/a/el

[16:11:40.0000] <devsnek>
no the links come from outside the tab

[16:11:51.0000] <TimothyGu>
ah

[16:11:54.0000] <devsnek>
like i click on a music.youtube.com link from discord or my email or something

[16:12:09.0000] <TimothyGu>
pretty sure <a target> is what you're looking for then

[16:12:55.0000] <devsnek>
no

[16:13:47.0000] <devsnek>
so you know how websites can register scheme handlers

[16:15:22.0000] <TimothyGu>
yeah?

[16:15:55.0000] <devsnek>
that but instead of registering the protocol, it registers the origin

[16:16:04.0000] <TimothyGu>
sounds like something Android has

[16:16:10.0000] <TimothyGu>
and probably iOS

[16:16:14.0000] <devsnek>
yeah

[16:18:03.0000] <devsnek>
https://gist.github.com/devsnek/931aa7bb1fdcb384c60d830805b5fba5


2018-09-20
[18:25:54.0000] <MikeSmith>
devsnek: what if the user doesn’t want all navigations to that to open in the same tab

[18:26:35.0000] <devsnek>
MIkeSmith: i dunno

[18:26:48.0000] <devsnek>
i think the general point is that it would improve the quality of use of the app

[18:28:32.0000] <MikeSmith>
I wonder how it would work on mobile

[18:33:30.0000] <devsnek>
MikeSmith: same way it does on desktop?

[18:35:29.0000] <MikeSmith>
devsnek: mobile doesn’t really have a tabbed UI, does it?

[18:35:52.0000] <devsnek>
MikeSmith: well i think in most cases this would result in fewer tabs

[18:35:58.0000] <MikeSmith>
ah

[18:36:06.0000] <devsnek>
i'm thinking of like

[18:36:14.0000] <MikeSmith>
yeah that would be useful

[18:36:17.0000] <devsnek>
how native apps can register protocol handlers e.g. spotify://

[18:36:22.0000] <MikeSmith>
right

[18:36:24.0000] <devsnek>
where it doesn't open a new instance of the app each time

[18:36:33.0000] <devsnek>
it just triggers a callback in the open app

[18:36:40.0000] <MikeSmith>
yup

[18:36:48.0000] <devsnek>
same thing but for web apps

[18:37:02.0000] <devsnek>
and using origin instead of protocol

[18:37:54.0000] <MikeSmith>
yeah still though it seems like this could just be handled by a user pref in the browser preferences

[18:38:02.0000] <MikeSmith>
for users who want that behavior

[18:38:13.0000] <devsnek>
how

[18:38:39.0000] <devsnek>
like the website needs to handle it somehow

[18:39:55.0000] <devsnek>
i mean it would make sense to prompt the user "website wants to handle all these urls" like asking for notification access

[20:30:41.0000] <TimothyGu>
devsnek: tbh I think URL prefix is better than origin, but that's semantics

[00:06:33.0000] <annevk>
Web manifest has something like that, but it's not sorted all the way through

[00:52:27.0000] <Domenic>
I think this is mostly a browser UI thing? E.g. Chrome is trying to do it for installed PWAs?

[01:02:52.0000] <MikeSmith>
Domenic: seems like that to me too, but maybe I’m missing something

[01:22:25.0000] <annevk>
Domenic: MikeSmith: seems to me you'd want an event for an incoming navigation as well so you can update content rather than replace the whole document

[01:32:02.0000] <MikeSmith>
oh, I didn’t realize “update content rather than replace the whole document” was a requirement

[01:34:38.0000] <annevk>
Well, that seems like a logical extension to me; not sure who determines the requirements though

[01:52:51.0000] <Ms2ger>
annevk, ping https://github.com/heycam/webidl/pull/577

[01:55:36.0000] <annevk>
Ms2ger: ta

[02:03:41.0000] <annevk>
Ms2ger: done

[02:04:02.0000] <Ms2ger>
annevk, bedankt

[05:13:47.0000] <annevk>
JakeA: we have some interested in moving further with CORB

[05:13:50.0000] <annevk>
JakeA: just so you know

[05:14:09.0000] <annevk>
JakeA: I pinged https://github.com/whatwg/fetch/issues/681#issuecomment-423159300 about getting the sniffing bits defined in detail

[09:28:44.0000] <MikeSmith>
https://stackoverflow.com/questions/52422662/how-to-get-file-upload-progress-with-fetch-and-whatwg-streams

[09:30:08.0000] <MikeSmith>
is there an example anywhere of how you would observe file-upload progress for a fetch+PUT request?

[09:56:13.0000] <annevk>
MikeSmith: nobody implements "upload streams"

[11:08:11.0000] <TabAtkins>
devsnek: I like the idea fine, so long as only "normal" navigations get intercepted; if you explicitly Ctrl-click or right-click=>open in new tab, it should skip the intercept and just open a new window.

[11:08:34.0000] <devsnek>
TabAtkins: sounds good to me


2018-09-21
[17:34:08.0000] <MikeSmith>
I wish Github had an option for showing issue-tracker comments in reverse chronological order

[18:39:44.0000] <JakeA>
annevk: happy to do reviews of the CORB stuff

[22:19:40.0000] <domfarolino>
annevk: Are you planning on revising the your module script credentials PR given https://github.com/whatwg/html/pull/3656#issuecomment-421991203. Just curious

[00:07:50.0000] <annevk>
JakeA: I was more hoping you'd poke the relevant folks, since Chrome has shipped something non-standard

[00:08:09.0000] <annevk>
domfarolino: no plans

[00:08:53.0000] <annevk>
domfarolino: I can put some effort into it though if someone will do the tests...

[04:17:27.0000] <domfarolino>
Sounds good

[07:35:16.0000] <annevk>
domfarolino: were you still looking at rel=stylesheet loading?

[07:35:23.0000] <annevk>
Or am I mixing up names?

[07:36:57.0000] <annevk>
Anyway, I created https://github.com/web-platform-tests/wpt/pull/13144 and the results thereof should be incorperated somehow

[07:37:07.0000] <annevk>
I guess the one thing remaining is all these variants with quirks mode

[07:37:15.0000] <annevk>
That should be easy to add...

[08:31:12.0000] <domfarolino>
annevk: Yeah I am. I'll check that PR out. btw have you seen https://github.com/whatwg/html/pull/4031

[09:25:40.0000] <annevk>
domfarolino: I did, but I didn't review in detail due to WIP

[09:26:12.0000] <annevk>
Oh, I missed your questions, sorry

[11:45:14.0000] <smaug____>
jgraham or anyone, what is the current support for native event handling in wpt, especially key events

[11:51:31.0000] <jgraham>
smaug____: https://web-platform-tests.org/writing-tests/testdriver.html

[11:51:58.0000] <jgraham>
Although I notice that page doesn't actually tell you enough to write a test :/

[11:52:45.0000] <jgraham>
smaug____: So I guess use GitHub search to find an example

[11:52:51.0000] <jgraham>
/me getting off the train now

[11:54:46.0000] <smaug____>
thanks

[11:54:48.0000] <smaug____>
https://searchfox.org/mozilla-central/search?q=test_driver.send_keys&path=

[12:24:41.0000] <domfarolino>
No worries!

[12:25:26.0000] <domfarolino>
Will revise the WIP style loading PR

[16:26:26.0000] <MikeSmith>
CORS support apparently broken in iOS v12 https://stackoverflow.com/questions/52434011/how-to-fix-ios-12-safari-cors-preflight-error/52445503#52445503

[16:26:43.0000] <MikeSmith>
> The problem is that iOSv12 WebKit preflight OPTIONS calls don't leave the device. I've run WireShark and the iOSv12 simulator to confirm this.

[16:28:47.0000] <rniwa>
MikeSmith: oh no.

[16:29:43.0000] <rniwa>
MikeSmith: oh, it's fixed in 12.1. yeah, i do recall this bug.

[16:29:54.0000] <MikeSmith>
oh hey rniwa

[16:30:08.0000] <MikeSmith>
yeah, hope the fix goes out soon

[16:30:15.0000] <MikeSmith>
or has it already? 12.1?

[16:30:32.0000] <MikeSmith>
rniwa: also see https://bugreport.apple.com/web/?problemID=44621834

[16:30:34.0000] <rniwa>
MikeSmith: 12.1 hasn't been released yet

[16:30:41.0000] <MikeSmith>
ah OK

[16:31:16.0000] <MikeSmith>
well I can’t view that bug but the OP for that Stack Overflow question raised it

[16:31:34.0000] <MikeSmith>
I guess somebody made it non-public for some reason

[16:32:08.0000] <MikeSmith>
rniwa: is there another public bug for it? resolved one I mean

[16:32:17.0000] <MikeSmith>
webkit bug I guess

[16:32:35.0000] <MikeSmith>
I mean in webkit bugzilla

[16:32:37.0000] <rniwa>
MikeSmith: https://trac.webkit.org/changeset/234626/webkit

[16:32:42.0000] <MikeSmith>
/me looks

[16:33:23.0000] <MikeSmith>
rniwa: thanks!


2018-09-22
[10:39:03.0000] <devsnek>
why does instantiateStreaming accept Response instead of a ReadableStream

[11:53:55.0000] <annevk>
Needs a URL and MIME type, iirc


2018-09-23
[04:34:22.0000] <kriti>
Hi. I am an outreachy aspirant and wish to contribute to the project -- Standardization of Web Application APIs. I wish to know the initial steps for getting started with the task . Thanks!

[09:06:29.0000] <innovati>
In this section of MDN it describes the transformation between kebab-cased-attributes and their camelCaseEquivalents, does anybody know of good code implementations of this? https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/dataset#Name_conversion

[09:07:16.0000] <innovati>
Is that transformation something that's made available in the browser that other people could send strings through, or would that have to be implemented in JS?

[09:10:13.0000] <devsnek>
there's probably something in jsdom

[09:10:41.0000] <innovati>
I whipped up my understanding, but I'm not sure if it's correct: https://codepen.io/tomhodgins/pen/zJXPNb

[09:11:03.0000] <devsnek>
basically just str.replace(/[A-Z]/, '-$1').toLowerCase()

[09:14:39.0000] <innovati>
nice

[14:00:33.0000] <GPHemsley>
is w3c-test submissions broken? http://w3c-test.org/submissions/

[14:00:45.0000] <GPHemsley>
nothing new since #11169

[14:01:06.0000] <gsnedders>
not implausible.

[14:01:27.0000] <GPHemsley>
(which was May 25

[14:01:28.0000] <GPHemsley>
)

[14:01:35.0000] <GPHemsley>
did the project move break it, perhaps?

[14:01:54.0000] <GPHemsley>
and if so, where do I file the bug?

[14:35:48.0000] <MikeSmith>
GPHemsley: you can file a bug at https://github.com/web-platform-tests/wpt/issues


2018-09-24
[17:24:29.0000] <GPHemsley>
MikeSmith: Filed https://github.com/web-platform-tests/wpt/issues/13180

[02:35:40.0000] <MikeSmith>
GPHemsley: thanks

[07:14:41.0000] <Domenic>
annevk: regarding better stylesheet processing, see my semi-abandoned https://github.com/whatwg/html/pull/3544

[08:00:09.0000] <annevk>
Domenic: aaah, I see that also stopped where I stopped, subresources

[08:00:39.0000] <annevk>
Domenic: I haven't written it down, but I was thinking that I really ought to test how @import ... deals with nosniff et al too

[08:01:07.0000] <annevk>
Domenic: if it's just @import maybe I can just do that tomorrow, might not actually be that many subresources

[08:02:38.0000] <Domenic>
I mean I stopped there because it's unclear whether it's nothing, or imports, or backgrounds or fonts or ... :/

[08:05:53.0000] <annevk>
Domenic: that multi-level @import demo from bz seems pretty bad

[08:06:29.0000] <annevk>
Domenic: it seems like you need two buckets, delays load and fails top-level fetch

[08:07:17.0000] <annevk>
But also more tests across browsers...

[08:07:43.0000] <annevk>
I doubt I'll get to this though, unless it impacts Content-Type / MIME Sniffing


2018-09-25
[08:01:19.0000] <annevk>
Domenic: https://twitter.com/brokencodebot/status/1044491810834448384 I noticed this too, but forgot to report it; known?

[08:01:34.0000] <annevk>
E.g., I'm not seeing an icon on https://dom.spec.whatwg.org/

[08:10:04.0000] <Domenic>
annevk: ricea also noticed and filed on whatwg/streams. It's a service worker bug. I can fix now I Think.

[11:00:54.0000] <annevk>
cool

[14:30:54.0000] <MikeSmith>
TabAtkins: https://github.com/w3c/mdn-spec-links has data that can be used to generate MDN annotations for any given spec

[14:31:06.0000] <MikeSmith>
I just created it a few hours ago

[14:31:44.0000] <MikeSmith>
currently has data for 218 specs

[14:33:08.0000] <MikeSmith>
please lemme know if you think the JSON format of the files would work for the purposes of adding a new MDN-annotating feature to Bikeshed

[14:35:23.0000] <MikeSmith>
the data for each spec ID is an array of arrays with the MDN url fragment, MDN article title, and MDN article summary ーfor each MDN article that has a link to that spec ID

[14:36:34.0000] <MikeSmith>
could change the format to have "mdn_url", "mdn_title", and "mdn_summary" keys instead of just an array

[14:37:14.0000] <MikeSmith>
but that seems like overkill, and a bit wasteful, given the overall size of the collective data

[14:37:50.0000] <MikeSmith>
but still if you think it would work better to have keys there, I could easily change it to that

[14:38:46.0000] <MikeSmith>
also published/exposed at https://w3c.github.io/mdn-spec-links/

[14:39:30.0000] <MikeSmith>
e.g., https://w3c.github.io/mdn-spec-links/css-logical-props.json

[14:40:35.0000] <MikeSmith>
and https://w3c.github.io/mdn-spec-links/SPECMAP.json maps each spec (base) URL to the corresponding *.json file for it

[14:47:07.0000] <domfarolino>
Domenic: Could you help me find where it is specified that a link should try and obtain resources whenever its `href` is changed?

[14:47:59.0000] <domfarolino>
For images, we have https://html.spec.whatwg.org/multipage/images.html#relevant-mutations, and I'm wondering if there is a corresponding dfn for links

[14:48:29.0000] <domfarolino>
s/that last link/https://html.spec.whatwg.org/multipage/images.html#when-to-obtain-images

[15:01:24.0000] <Domenic>
domfarolino: https://html.spec.whatwg.org/multipage/semantics.html#obtaining-a-resource-from-a-link-element

[15:02:25.0000] <Domenic>
with an override for rel=modulepreload, and in theory an override for rel=stylesheet per https://github.com/whatwg/html/issues/968 but that part of the spec is rather borked

[15:03:43.0000] <domfarolino>
Domenic: Ah, right but is it specified when those "obtain" algorithms should be called? For example it seems to be called whenever `href` is updated at the very least, and I'm wondering if that is spelled out somewhere

[15:05:11.0000] <Domenic>
It's per rel, e.g. https://html.spec.whatwg.org/multipage/links.html#link-type-stylesheet or https://html.spec.whatwg.org/multipage/links.html#link-type-modulepreload . (The latter seems like it should do more cross-linking... in general probably there should be a central definition for "appropriate times to obtain the resource" and then the individual rels should refer to that...)

[15:08:43.0000] <domfarolino>
Oh, wow, yep I totally missed those "appropriate times to..." sentences

[15:10:35.0000] <domfarolino>
Yeah a more centralized "appropriate times..." dfn would be nice I think

[15:13:47.0000] <Domenic>
PR welcome, if you want to shave that yak :)

[15:22:19.0000] <domfarolino>
I'm interested; will attempt after working on `imagesrcset` and `imagesizes` for link, and updating preload spec

[15:48:26.0000] <eeeps>
domfarolino: is there an issue about preloading imgsrcset and imgsizes? Can't find one.

[15:48:59.0000] <eeeps>
wait dang https://github.com/w3c/preload/issues/120

[15:49:01.0000] <eeeps>
nm


2018-09-26
[06:17:58.0000] <MikeSmith>
annevk: https://stackoverflow.com/questions/52518370/transparent-movement-of-cors-enabled-resources-with-cross-origin-redirect

[06:18:16.0000] <MikeSmith>
> I'd need to be able to tell the browser to send credentials to old.example.com but once it redirects you to new.example.com, request it without credentials / in no-cors mode. As far as I know that's not possible -- the initial request and all following redirects get the same fetch options. Am I missing something? Is there another way to accomplish this?

[06:32:40.0000] <annevk>
MikeSmith: replied

[06:33:28.0000] <MikeSmith>
thanks!

[07:39:54.0000] <lgrahl>
o/

[07:40:19.0000] <lgrahl>
Quick question for WebSocket: When calling .close, the 'close' event should not fire as a result, right?

[07:41:32.0000] <nox>
lgrahl: https://html.spec.whatwg.org/multipage/web-sockets.html#dom-websocket-close It depends.

[07:44:26.0000] <lgrahl>
nox: Ok... what if I'm connected, I call .close and once the closing handshake completes, the 'close' event fires. What close code will I get in that event?

[07:47:56.0000] <lgrahl>
What I'm on about: How would I know whether the close code came from me initiating the closing handshake or from the server?

[07:50:26.0000] <lgrahl>
Also: "The code attribute must return the value it was initialized to. It represents the WebSocket connection close code provided by the server."

[08:21:02.0000] <domfarolino>
Does anyone else experience this? When I paste this exact link into Chrome's URL bar and hit enter, it google searches for the link, instead of navigating to the page: https://w3c.github.io/preload/ (but without the trailing `/`, it navigates fine)

[08:23:58.0000] <gsnedders>
domfarolino: doesn't repro here?

[08:25:32.0000] <domfarolino>
and of course it isn't for me anymore. It did like 10 times in a row though, odd.

[08:41:02.0000] <gsnedders>
hah!

[08:41:11.0000] <gsnedders>
yeah, I've definitely seen weirdness like this in multiple browsers.

[09:10:47.0000] <lgrahl>
Ugh, still stubbornly ignore the streams API... https://github.com/w3c/webrtc-quic/issues/63

[13:41:02.0000] <domfarolino>
eeeps: how will the HTML example in the issue you replied on only load a single image?

[13:42:58.0000] <domfarolino>
The rel=preload shouldn’t know about any other elements in the page. It’s job is just to load what it describes. And the first link described a potentially-media-matching image derived from a source set, and the second describes an always-media-marching image from a source set right?

[13:48:33.0000] <eeeps>
When both <source>s are wrapped within a <picture>, the second one is ignored if the first one matches. Here's a non-normative part of the spec that says as much -- https://html.spec.whatwg.org/multipage/images.html#introduction-3:art-direction-3 -- zcorpan would know better than I where to find it normatively

[13:50:07.0000] <eeeps>
So, yeah, in order to preload just one, you'd have to modify your <link media>s to make them mutually exclusive, because as you say, the <link>s wouldn't know about the <picture> context

[13:53:39.0000] <eeeps>
If we figure out some way for the `<link>`s to know about that context, it saves authors from having to modify their `media`s, and would allow preloading resources for image-format based selection (`<picture><source type>`). Not sure if those use cases are worth the complexity this would add to <link> though.

[13:56:26.0000] <domfarolino>
Btw the normative part you’re looking for is https://html.spec.whatwg.org/multipage/images.html#updating-the-source-set

[13:56:50.0000] <eeeps>
👍

[13:57:41.0000] <domfarolino>
Ok so you’re saying we’d preload two images, when that might not be necessary at all

[13:59:22.0000] <eeeps>
Right -- if you just copy the medias from the <source>s in the example to <link>s, you sometimes preload both resources. But the <picture> on its own would only ever load one.

[14:03:05.0000] <domfarolino>
That makes sense. I was confused by “HTML in the example will load only one image”. Makes sense you were referring to the <picture> HTML tho. I agree that is an awkward problem hmm

[14:06:48.0000] <eeeps>
Asking authors to modify medias to be mutually exclusive might not be a terrible solution? Again, not sure what to do about type, other than add some mechanism so that the <link>s are grouped and processed together somehow, as the <source>s will be later.

[15:03:49.0000] <domfarolino>
eeeps: Ahh, the confusion earlier (my bad!) was that we were talking about two different HTML snippets it seems. Hmm, yeah asking authors to do that might not be too bad. I wonder how bad it would be if they took no action though, and every preload loaded (aka how many image requests on average would be wasted)

[15:18:13.0000] <eeeps>
I mean, if that number is significant, preloading useless resources is an unconscionable crime against performance, and if it's insignificant, why are you art directing in the first place?

[15:19:25.0000] <eeeps>
and I assure you, if there was any confusing communication going on, it was almost certainly my bad (:

[16:15:09.0000] <domfarolino>
We’ll have to consider ways to make certain preloads not load then. Interesting, since right now preloads are “mandatory” fetches.


2018-09-27
[19:26:04.0000] <Krinkle>
I ran into a similar situation trying to make rel=preload work for high-dpi images

[19:26:13.0000] <Krinkle>
Ended up having to hack it with stuff like <= 1.9999

[19:26:21.0000] <Krinkle>
because each media has to be mutually exclusive

[19:26:31.0000] <Krinkle>
as opposed to where in CSS it cascades naturally

[19:28:14.0000] <Krinkle>
This is what I ended up with for Wikipedia's logo preload:

[19:28:15.0000] <Krinkle>
https://github.com/wikimedia/mediawiki/blob/809d9b684517dee2f1d3cc2082cea662ff65d135/tests/phpunit/includes/resourceloader/ResourceLoaderSkinModuleTest.php#L222-L237

[19:28:38.0000] <Krinkle>
link: </static/images/project-logos/enwiki.png>;rel=preload;as=image;media=not all and (min-resolution: 1.5dppx),</static/images/project-logos/enwiki-1.5x.png>;rel=preload;as=image;media=(min-resolution: 1.5dppx) and (max-resolution: 1.999999dppx),</static/images/project-logos/enwiki-2x.png>;rel=preload;as=image;media=(min-resolution: 2dppx)

[19:29:01.0000] <Krinkle>
It's certainly code I'd love to get rid of somehow

[19:29:01.0000] <Krinkle>
https://github.com/wikimedia/mediawiki/blob/5d0b5a402e384897288ad569da8d534fa2e432cb/includes/resourceloader/ResourceLoaderSkinModule.php#L131-L156

[19:30:28.0000] <Krinkle>
(see also https://github.com/w3c/preload/issues/31 )

[05:13:35.0000] <hsivonen>
The canonical copy of DOM Parsing and Serialization is the W3C one, right?

[05:25:19.0000] <Ms2ger>
Afraid so

[05:58:46.0000] <annevk>
It’s also written toward Edge I think without much cross-browser input

[06:07:45.0000] <hsivonen>
Ms2ger, annevk: thanks

[07:24:12.0000] <Domenic>
I think it's written toward most browsers, but it has some bugs

[07:24:25.0000] <Domenic>
Sebmaster discovered them when implementing https://github.com/jsdom/w3c-xmlserializer

[07:24:37.0000] <Domenic>
I've been trying to get him to spec-edit

[07:26:26.0000] <Domenic>
Like I think https://github.com/jsdom/w3c-xmlserializer/commit/313aeb3583ff67cf731866381b979d2e9462498b was a fix to the spec

[15:28:55.0000] <Mek>
anybody know how to setup things to get bikeshed to auto-run on commits to a github repository? The bikeshed docs mostly just seem to link to whatwg docs, but neither of those seem to have actual instructions on how to set it up; instead they just have a bunch of files you're supposed to somehow use to make it happen...


2018-09-28
[18:59:42.0000] <MikeSmith>
Web Share API shipped in Safari Technology Preview 66

[18:59:48.0000] <MikeSmith>
https://developer.apple.com/safari/technology-preview/release-notes/

[19:00:59.0000] <MikeSmith>
Mek: about bikeshed to auto-run on commits to a github repo, I would tell you how if I knew myself, but I have never set it up

[19:52:34.0000] <annevk>
Mek: you have to write scripts of sorts, WHATWG has some shared infrastructure for this, all shared (except for keys)

[20:00:02.0000] <Mek>
eventually I found very helpful step-by-step instructions at https://github.com/rtoy/auto-deploy-spec

[20:13:39.0000] <annevk>
👍🏻

[00:29:16.0000] <MikeSmith>
Mek: FWIW a link to that https://github.com/rtoy/auto-deploy-spec should be getting added to https://w3c.github.io/ soonish

[00:33:17.0000] <MikeSmith>
as far as W3C publishing goes, that https://w3c.github.io/ is meant to be the central place where editors and WGs can look to for info about related tooling

[00:35:41.0000] <MikeSmith>
(there’s already a Automatic Publication from GitHub section on the page, but the current info there applies only to aut-publishing to https://w3.org/TR/ space)

[04:13:57.0000] <ivaror>
Does anyone want to hear a joke?

[04:14:43.0000] <ivaror>
What is an abnormal HTMLSlotElement?

[04:16:37.0000] <ivaror>
anyone?? )

[04:21:50.0000] <ivaror>
a normal HTML element

[10:06:03.0000] <TabAtkins>
???

[10:23:45.0000] <domfarolino>
RT^

[10:31:21.0000] <TabAtkins>
Mek: And I've now linked to rtoy's steps in Bikeshed's docs. (Sorry, last time I learned of these steps, they weren't yet ready for public consumption.)

[13:39:44.0000] <domfarolino>
zcorpan: Is http://web-platform-tests.live/ basically the new http://w3c-test.org?

[13:55:21.0000] <TabAtkins>
domfarolino: I think so, yes.

[14:11:40.0000] <Domenic>
Oh cool

[14:11:45.0000] <Domenic>
Does it have submissions though

[14:30:22.0000] <TabAtkins>
I dunno. It's just the same code running on a different server.

[16:08:30.0000] <Domenic>
TabAtkins: dumb question, is there a reason why fieldset/legend couldn't be redone in terms of shadow DOM too?

[16:08:56.0000] <TabAtkins>
The obvious reason is that it has a bizarre rendering.

[16:09:20.0000] <TabAtkins>
But if we isolate that, I'm not sure - I *think* there's sufficient legacy issues to make it troublesome, but I'm not certain about that. It might be doable.

[16:09:27.0000] <TabAtkins>
Would have to consult with zcorpan.

[16:09:38.0000] <TabAtkins>
(Not a dumb question, btw.)

[16:12:18.0000] <Domenic>
Yeah, my impression of zcorpan's work was that interop was all over the place on edge cases, so I was wondering what the observable effects of shadow DOM vs. magic CSS boxes was. Apparently it affects ::before/::after, but unsure what else.

[16:12:54.0000] <Domenic>
(And maybe ::before/::after is enough of a reason, i.e. if that works interoperably currently in a way that's not compatible with shadow DOM, then maybe we couldn't change it.)

[16:13:18.0000] <TabAtkins>
Yeah, magic CSS boxes can do *whatever they want* re: ::before/::after. Shadow DOM has a single common way to do this. (Tho, uh, I think it's not actually specified...)

[16:14:36.0000] <TabAtkins>
The thing with fieldset::before is, I think, that it goes before all content *inside* the fieldset, but it's technically after the rendered legend (which got lifted up into the border).

[16:15:14.0000] <TabAtkins>
So whether that violates Shadow DOM's treatment or not depends on how much of the "rendered legend" behavior is CSS-layout magic, and how much is CSS-box-tree magic.

[16:16:03.0000] <TabAtkins>
I'd prefer to consider it a magical CSS `display` value that's not author-exposed, in which case the rendering *is* consistent with Shadow DOM, unless there's some weirder edge cases I'm not aware of.

[16:16:48.0000] <TabAtkins>
But to the best of my knowledge that's correct: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6238


2018-09-29
[17:24:51.0000] <MikeSmith>
domfarolino: Domenic yeah we are working on basically decommissioning http://w3c-test.org ーeventually just 301 redirecting it to http://web-platform-tests.live/

[17:25:25.0000] <MikeSmith>
but... http://web-platform-tests.live/ does not have a /submissions equivalent yet

[17:25:49.0000] <MikeSmith>
in spite of that I think we are going ahead with the move -

[17:26:17.0000] <MikeSmith>
because even on http://w3c-test.org, /submissions has been broken for months now

[17:27:23.0000] <MikeSmith>
and the sky hasn’t fallen because of that, so even if we move, we’re not going to be worse off than the status quo, as far as that goes

[17:28:38.0000] <Domenic>
yeah, fair

[17:29:40.0000] <MikeSmith>
we do plan to recreate the submissions feature at http://web-platform-tests.live/ eventually

[17:37:34.0000] <MikeSmith>
TabAtkins: https://freenode.logbot.info/whatwg/20180925#c1730109

[17:37:37.0000] <MikeSmith>
about https://github.com/w3c/mdn-spec-links

[18:37:12.0000] <TabAtkins>
Yeah, I saw. Mind opening an issue on me so I can track it?

[18:40:47.0000] <MikeSmith>
TabAtkins: sure, will do

[20:13:18.0000] <GPHemsley>
/me drops a piece of the sky

[01:07:52.0000] <MikeSmith>
GPHemsley: apologies, I didn’t mean to be dismissive about that issue

[01:08:41.0000] <MikeSmith>
at this point the tool we have deployed currently on w3c-test.org seems to not be the best way to handle it

[01:09:57.0000] <MikeSmith>
and it’s been difficult to troubleshoot problems with the wpt tooling on the w3c-test.org environment separate from other (file)system-related issues on w3c-test.org

[01:11:28.0000] <MikeSmith>
the w3c-test.org server is running on openstack at MIT in a way that gives me very little control over the system

[01:13:48.0000] <MikeSmith>
for one thing, I’m told they’re using really cheap disk storage ー certainly not SSD ー and whether or not that’s the cause, I have no way to really ever find out

[01:13:57.0000] <MikeSmith>
there are too many mysteries there

[01:15:50.0000] <MikeSmith>
but the http://web-platform-tests.live/ is hosted in way that provides more control, and it also has the advantage of multiple savvy people other than me as maintainers

[01:16:40.0000] <MikeSmith>
anyway, I will try to raise the priority of getting a /submissions equivalent set up there

[01:16:58.0000] <MikeSmith>
it’s clearly a really useful thing to have


2018-09-30
[17:53:58.0000] <GPHemsley>
MikeSmith: thanks :)

[17:54:48.0000] <GPHemsley>
I don't generally have an established setup for wpt tests like I suspect a lot of people do, so having submissions available on the web makes it easier for me to do drive-by testing

[17:55:23.0000] <GPHemsley>
and for url stuff in particular, it's very convenient to be able to point my code at a JSON URL to run the tests against it

[17:55:37.0000] <GPHemsley>
which then makes it easy for me to review

[18:56:12.0000] <MikeSmith>
GPHemsley: yup, understood

[18:59:12.0000] <MikeSmith>
annevk: please review the paragraphs about default request mode https://developer.mozilla.org/en-US/docs/Web/API/Request/mode#Default_mode and let me know if any of it’s inaccurate

[19:12:13.0000] <domfarolino>
MikeSmith: fwiw it checks out to me

[19:14:41.0000] <Domenic>
MikeSmith: I think not all those markup cases are always no-cors

[19:15:31.0000] <Domenic>
E.g. <script type=module> and <link rel=modulepreload> are cors. Also I think <track> is cors, although you didn't list that and I'm only 60% sure.

[19:25:51.0000] <MikeSmith>
domfarolino: thanks!

[19:26:08.0000] <MikeSmith>
Domenic: ah OK, as far a script and link, maybe if I qualify it by adding “except when used with modules”?

[19:26:09.0000] <domfarolino>
^ good distinction

[19:26:46.0000] <Domenic>
Yeah. Oh and also all the others if you use the crossorigin="" attribute, I think?

[19:28:05.0000] <domfarolino>
^ true, however since the para is under the "Default" section wonder if its worth enumerating all of the possibilities

[19:29:00.0000] <MikeSmith>
yeah it starts to be a bit of a case of pulling at at thread

[19:29:32.0000] <MikeSmith>
but it should at least also mention crossorigin=""

[19:29:39.0000] <MikeSmith>
so I’ll at dd that

[19:33:36.0000] <Domenic>
Yeah I dunno, or just soften to "usually" or "by default" or similar

[19:46:35.0000] <MikeSmith>
OK

[19:47:20.0000] <MikeSmith>
Domenic: as far a <track> I can’t find anything in https://html.spec.whatwg.org/multipage/media.html#the-track-element nor in the WebVTT about fetches for text tracks being made with cors mode

[19:47:25.0000] <MikeSmith>
/me looks further

[19:49:13.0000] <Domenic>
Hmm yeah I think they are fetched in https://html.spec.whatwg.org/multipage/media.html#start-the-track-processing-model and I am wrong

[19:49:56.0000] <MikeSmith>
Domenic: yeah actually in there I find https://html.spec.whatwg.org/multipage/media.html#sourcing-out-of-band-text-tracks:attr-media-crossorigin

[19:50:03.0000] <Domenic>
Although https://html.spec.whatwg.org/multipage/media.html#security-and-privacy-considerations is something

[19:50:05.0000] <MikeSmith>
>  If the track element's parent is a media element then let corsAttributeState be the state of the parent media element's crossorigin content attribute. Otherwise, let corsAttributeState be No CORS.

[19:50:35.0000] <MikeSmith>
/me reads https://html.spec.whatwg.org/multipage/media.html#security-and-privacy-considerations

[19:51:00.0000] <Domenic>
So no impact on your docs, just slightly more interesting processing model if you do opt in to cors mode with crossorigin="", is my reading

[19:51:25.0000] <MikeSmith>
yup

[20:06:49.0000] <domfarolino>
'tis also what I gather

[20:19:35.0000] <annevk>
I think track is same-origin restricted, so could have defaulted to CORS

[20:57:21.0000] <MikeSmith>
annevk: thanks I added some language to https://developer.mozilla.org/en-US/docs/Web/HTML/Element/track to indicate it’s same-origin-restricted unless the parent has the crossorigin attribute

[23:50:06.0000] <MikeSmith>
mkwst: For CSP is there any guidance somewhere which states that nonces should be used when possible, rather than hashes? And if so, which explains what the rationale is for preferring the use of nonces?

[23:50:40.0000] <MikeSmith>
I vaguely recall reading an explanation somewhere, but can’t find it now

[23:51:16.0000] <MikeSmith>
neither https://csp.withgoogle.com/docs/strict-csp.html nor https://csp.withgoogle.com/docs/faq.html says it explicitly at least

[23:54:06.0000] <MikeSmith>
and I’ve read the “CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future of Content Security Policy” paper too ー which recommends nonces ー but nowhere in it does it directly state what properties of nonces make them a better solution than hashes

[01:20:38.0000] <zcorpan>
MikeSmith: as for submissions/ I'm thinking if it would be a good idea to spin up a subdomain and separate wptserve instance for each PR

[01:22:18.0000] <zcorpan>
and maybe only provide the syncing on request in a github comment

[01:23:52.0000] <MikeSmith>
zcorpan: please talk to jugglinmike :)

[01:24:10.0000] <MikeSmith>
he wrote down some ideas about it already somewhere

[01:24:17.0000] <zcorpan>
aha

[01:24:29.0000] <MikeSmith>
I think it was in a github issue but I can’t remember

[01:27:42.0000] <zcorpan>
Domenic: TabAtkins: two reasons. it's not implemented using shadow DOM anywhere today (AFAIK), and the ::before issue.

[01:28:24.0000] <zcorpan>
and I guess that the rendering is so special that it needs CSS magic anyway

[01:42:04.0000] <MikeSmith>
when uses <details> and <summary>, there’s no way to control the spacing after the disclosure triangle and before the summary text, right?

[01:46:15.0000] <MikeSmith>
nm figure out a way

[01:46:21.0000] <MikeSmith>
*figured

[06:59:26.0000] <annevk>
MikeSmith: I’d think hashes are better?

[07:02:19.0000] <TabAtkins>
zcorpan: Yeah, afaict fieldset doesn't *need* to use Shadow Dom for anything, it's just a messy CSS layout thing.

[07:03:42.0000] <TabAtkins>
But also: what ::before issue?

[07:06:57.0000] <MikeSmith>
annevk: I would think so too, but https://csp.withgoogle.com/docs/strict-csp.html seems to imply  otherwise

[10:34:23.0000] <zcorpan>
TabAtkins: if it used shadow dom, i think ::before would appear before the legend

[10:34:32.0000] <TabAtkins>
HOw?

[10:34:52.0000] <TabAtkins>
Or in other words: if you're thinking of fieldset's *entire functionality* being implemented via shadow DOM... how?

[10:35:38.0000] <TabAtkins>
(The "render in the border of another element" seem to clearly point to this being a CSSish thing, not a DOMish thing.)

[10:35:50.0000] <zcorpan>
I don't really know, I thought that was a thing for details/summary?

[10:36:45.0000] <TabAtkins>
Yes, because you can actually implement details/summary purely with shadow dom (and existing CSS). And then the result is that details::before is before the summary. Shadow DOM is a non-sequitur with fieldset, tho; you can't reproduce its functionality by just rearranging children.

[10:37:08.0000] <zcorpan>
Yeah

[10:39:37.0000] <TabAtkins>
If fieldset's rendering was *just* "first legend gets pulled up to be first child", then yeah, we could do it with shadow dom, and ::before would go before the legend. But the functionality as it exists works on a totally different level, with no meaningful interaction with ::before.

[10:41:07.0000] <zcorpan>
So I guess the main reason it doesn't use shadow dom is just that it doesn't help with anything 🙂

[10:43:22.0000] <zcorpan>
My flight is about to takeoff. See you in A Coruña

[10:44:16.0000] <zcorpan>
(You being whoever is also there)

[12:19:45.0000] <MikeSmith>
botie: inform zcorpan https://github.com/bocoup/web-platform-tests.live/issues/2 is the issue about a /submissions replacement

[12:19:46.0000] <botie>
will do

[12:21:05.0000] <MikeSmith>
GPHemsley: see https://github.com/bocoup/web-platform-tests.live/issues/2 for discussion about a /submissions equivalent for web-platform-tests.live