2019-05-01
[04:08:52.0000] <annevk>
Soni: does https://whatwg.org/faq#adding-new-features help?

[04:09:07.0000] <annevk>
Soni: there's also https://whatwg.org/working-mode

[15:14:31.0000] <domfarolino>
Anyone know if beidson (https://github.com/beidson) represents WebKit in W3C repos? Only evidence I can find is his approval of https://github.com/web-platform-tests/wpt/pull/8898

[15:15:18.0000] <domfarolino>
I ask is because I'm trying to determine if https://github.com/w3c/IndexedDB/issues/255#issuecomment-470255862 is a public signal for Safari to impl a small feature


2019-05-02
[23:00:09.0000] <annevk>
domfarolino: yup

[23:00:44.0000] <annevk>
domfarolino: see also @bradeeoh

[03:38:58.0000] <Ms2ger>
In https://w3c.github.io/ServiceWorker/#run-service-worker-algorithm , step 4.13 says "If callbackSteps is provided, run them with evaluationStatus on the original thread that invoked this algorithm, while continuing in parallel with these steps."

[03:39:01.0000] <Ms2ger>
How does that work?

[05:54:37.0000] <annevk>
Ms2ger: that doesn't seem entirely correct, it'd have to queue on the original thread

[05:54:56.0000] <Ms2ger>
That sounds more like something that could work, certainly

[05:55:03.0000] <Ms2ger>
Could you file it?

[05:56:26.0000] <annevk>
not right now

[05:59:28.0000] <Ms2ger>
https://github.com/w3c/ServiceWorker/issues/1403

[09:32:13.0000] <annevk>
Ta

[11:21:39.0000] <Borewit>
I have question regarding Readable​Stream

[11:21:39.0000] <Borewit>
 as part of the Web API, is this the right place? Is someone available to look into my question?

[11:34:12.0000] <Borewit>
Anyone reading?

[11:38:35.0000] <Mek>
you're more likely to get a useful answer by asking your question, rather than by asking if you should ask your question....

[11:48:31.0000] <Borewit>
Aight, I try to release the lock of a Reader (ReadableStreamDefaultReader). I do not manage to synchronize for the read to be out of the way. Of I use the promise, returned from the read, I get an error the read is not settled.

[12:05:55.0000] <Borewit>
So I try to cancel a Readable stream. Therefor I need to release the reader first. I I try to unlock the reader I get an error there is read going on. So I wait until the read promise resolves, I unsure no other read will done. Then I get an error the read has not settled yet. I can go arround the problem by setting a timeout (works for Chrome, Safari, Edge, not for Firefox).

[12:07:11.0000] <Borewit>
This where the error is thrown: https://github.com/Borewit/readable-web-to-node-stream/blob/891285d073ecb77f8537d02d96feb4ae050b2157/src/index.ts#L76

[12:08:25.0000] <Borewit>
If I increase time ¨sleep timer¨ one line before, from 1 msec to 1 sec, it becomes more likely to pass: https://github.com/Borewit/readable-web-to-node-stream/blob/891285d073ecb77f8537d02d96feb4ae050b2157/src/index.ts#L76

[12:32:31.0000] <Borewit>
So the expect error is: ¨TypeError: Cannot release a readable stream reader when it still has outstanding read() calls that have not yet settled¨


2019-05-03
[05:45:00.0000] <annevk>
Have Travis timeouts shortened? HTML isn't building successfully on master for unclear reasons

[06:07:16.0000] <Domenic>
annevk: Maybe the new validator.jar fetching location?

[06:11:49.0000] <annevk>
Domenic: well, but it's only affecting commits as of an hour ago

[06:12:07.0000] <annevk>
And it seems to be failing in random places

[06:12:09.0000] <Domenic>
Hmm yeah I guess we did do some commits after that, true.

[06:14:40.0000] <Domenic>
Yeah that is weird. Error code 28 is not documented anywhere.

[06:15:06.0000] <Domenic>
Just re-run them and hope it's a temporary error somewhere in the pipeline?

[06:15:31.0000] <annevk>
I can try again, but really gotta go now

[06:16:03.0000] <Domenic>
I can take care of it

[08:34:50.0000] <Domenic>
Seemed like a temporary error, although interesting to note that if you try to re-deploy something that's already deployed, our build appears to hang at the rsync step.

[09:28:54.0000] <annevk>
Ta

[09:29:29.0000] <annevk>
foolip: how long do IDL changes take to get reflected on WPT?

[09:31:13.0000] <foolip>
annevk: about a day if reffy is working and if Luke or I see reviewing https://github.com/web-platform-tests/wpt/pulls/autofoolip

[09:31:25.0000] <foolip>
I haven't this week, is it one of those PRs?

[10:39:25.0000] <annevk>
foolip: no, html

[10:41:32.0000] <annevk>
foolip: thanks for explaining


2019-05-06
[12:05:51.0000] <oliverdunk>
Would someone be able to clarify what is meant by "the field of web technologies" in the contributor agreement?


2019-05-07
[08:18:26.0000] <Ms2ger>
Domenic, hey, where were you planning to use IDL modules?

[08:31:38.0000] <Domenic>
Ms2ger: kv-storage. I'm thinking at least a PR there that uses 3-4 of your Web IDL PRs.

[08:39:43.0000] <Ms2ger>
Domenic, feel free to start from https://github.com/WICG/kv-storage/compare/master...Ms2ger:idl?expand=1

[08:40:06.0000] <Domenic>
Oh :)

[08:41:05.0000] <Ms2ger>
(I don't have time to work on it today)

[08:41:22.0000] <Domenic>
Is there, uh, much left to work on

[08:41:50.0000] <Domenic>
The async iterator I guess

[09:04:18.0000] <Domenic>
annevk: https://github.com/web-platform-tests/wpt/pull/15818 is not waiting on me, right? There's some spec work to do before it's merge-ready?

[12:10:05.0000] <annevk>
Domenic: we could consider landing if all browsers pass

[12:10:47.0000] <Domenic>
annevk: looks like Firefox has a 3/4 pass https://github.com/web-platform-tests/wpt/pull/15818/checks?check_run_id=77530288

[12:11:05.0000] <annevk>
Domenic: but yeah, need to decide on an approach


2019-05-08
[17:57:11.0000] <MikeSmith>
Domenic: about https://freenode.logbot.info/whatwg/20190506#c2160727

[17:57:44.0000] <MikeSmith>
> oliverdunk: Would someone be able to clarify what is meant by "the field of web technologies" in the contributor agreement?

[17:58:26.0000] <MikeSmith>
do you know if that person ended up submitting a PR or raising an issue?

[17:58:59.0000] <MikeSmith>
or did they just go away without us hearing anything more from them?

[18:01:56.0000] <MikeSmith>
OK, I find https://github.com/oliverdunk

[18:39:05.0000] <Domenic>
MikeSmith: yep, being discussed in the long thread

[18:48:41.0000] <MikeSmith>
OK

[18:49:09.0000] <MikeSmith>
/me needs to catch up on GitHub notifications

[18:55:53.0000] <MikeSmith>
https://jameshfisher.com/2019/04/27/the-inception-bar-a-new-phishing-method/

[18:57:27.0000] <MikeSmith>
Firefox has the same problem

[18:58:08.0000] <MikeSmith>
is there even a “don’t ever hide the address bar” user option?

[08:34:32.0000] <Domenic>
annevk: ping on Infra reviews (for tomorrow)

[08:37:10.0000] <Ms2ger>
Domenic, for synthetic modules, do you think IDL would be a good spec to put them in?

[08:38:13.0000] <Domenic>
Ms2ger: yeah, I think for now at least, maybe with a "this may be upstreamed to 262 as part of the JS standard library proposal" note. And maybe eventually it may be the right place for it anyway, if we end up specifying that the JS spec's built-in modules also should use Web IDL.

[08:39:03.0000] <Ms2ger>
Ok, I'll see if I have time tomorrow

[08:40:14.0000] <Domenic>
Awesome, thank you!

[12:26:08.0000] <zcorpan_>
Domenic: can you review https://github.com/web-platform-tests/wpt/pull/16734 ? I don't think I have the right domain knowledge for this one

[12:27:00.0000] <Domenic>
zcorpan_: for sure, will do tomorrow

[12:27:09.0000] <zcorpan_>
thx

[13:41:42.0000] <annevk>
Have had a bit of a backlog for a while, but can prioritize those Infra PRs. They look interesting 😊

[14:19:49.0000] <Domenic>
I've surveyed the landscape of focus stuff. Expect a brain dump on an initial plan tomorrow.


2019-05-09
[00:17:04.0000] <annevk>
Oooh, exciting

[05:34:32.0000] <annevk>
zcorpan++ for requestSubmit() tests review

[06:04:10.0000] <ondras>
class MyEventTarget extends EventTarget { constructor(stuff) { super(); } }   <--- is this correct?

[06:04:33.0000] <ondras>
because Safari says "function is not a constructor (evaluating 'super()')"

[07:00:23.0000] <annevk>
ondras: if it runs in Firefox I'd say it is

[07:00:31.0000] <annevk>
(not the best answer, granted)

[07:01:23.0000] <ondras>
:)

[07:01:29.0000] <ondras>
yeah, it works in FF and Chrome

[07:17:45.0000] <annevk>
ondras: might wanna search bugs.webkit.org for EventTarget

[07:17:57.0000] <ondras>
annevk: okay, will try

[07:31:19.0000] <ondras>
perhaps this is somewhat relevant: https://bugs.webkit.org/show_bug.cgi?id=67312

[07:31:24.0000] <ondras>
will issue a new bug probably

[07:33:08.0000] <annevk>
ondras: https://bugs.webkit.org/show_bug.cgi?id=174313

[07:33:35.0000] <annevk>
/me searched for EventTarget, then inline search for constructor

[08:02:43.0000] <Domenic>
Gah why does the W3C stylesheet still do terrible things to tables. https://pr-preview.s3.amazonaws.com/heycam/webidl/pull/722.html#synthetic-module-records

[08:08:42.0000] <ondras>
annevk: ah. I searched for "EventTarget super"

[08:08:44.0000] <ondras>
:/

[08:26:38.0000] <Domenic>
TabAtkins: if you could provide some sort of quick fix for https://github.com/w3c/tr-design/issues/104#issuecomment-490950952, for specs which don't need to conform to pubrules (e.g. EDs, community group reports, IDEA status) that would be much appreciated.

[08:37:14.0000] <TabAtkins>
Domenic: Looking into it again. The problem is that the styling issue we're trying to solve is hard. :(

[08:37:38.0000] <Domenic>
TabAtkins: I mean it would be good enough for me if tables just weren't wrapped in overlarge, or if overlarge didn't do any centering at all.

[08:38:26.0000] <Domenic>
Thanks for looking at it though. It is like my number one problem reading specs these days. (Probably other people have many other problems...)

[08:38:40.0000] <TabAtkins>
The point of overlarge is to provide a scrolling wrapper, so a wide table doesn't screw up the entire spec when reading on mobile.

[08:41:30.0000] <Domenic>
Does it need to be a centered scrolling wrapper?

[08:42:23.0000] <TabAtkins>
(Tangent: IDL both includes all the ED stylings manually, *and* links to the W3C ED stylesheet. It looks like this is just a result of the webplatform boilerplate doing that for some reason: https://github.com/tabatkins/bikeshed/blob/master/bikeshed/boilerplate/webplatform/header.include . I should fix that and see if anyone else copypasted that same error.)

[08:42:54.0000] <Domenic>
Yes please, I was noticing something weird going on in that vein, but didn't dig in too hard.

[08:42:58.0000] <TabAtkins>
Domenic: People really like centered tables, ¯\_(ツ)_/¯

[08:43:17.0000] <Domenic>
Citation needed? They are pretty terrible in all fixed-width specs...

[08:54:12.0000] <annevk>
I should create a filter for sheriffbot I suppose

[08:55:32.0000] <annevk>
sleevi’s claim of it actually working is thus far proven false to me

[08:58:32.0000] <Domenic>
Ms2ger: https://webassembly.github.io/spec/web-api/ does not contain the words "ArrayBufferDetachKey"

[08:59:00.0000] <Domenic>
Ah, I think it was supposed to be https://webassembly.github.io/spec/js-api/

[08:59:03.0000] <Domenic>
I'll fix

[08:59:27.0000] <annevk>
I wonder if IDL detach was only ever used by HTML

[08:59:38.0000] <Domenic>
This seems possible

[09:00:05.0000] <Ms2ger>
Domenic, yes, should be js-api

[09:00:49.0000] <annevk>
Yeah, though maybe some audio thing detaches?

[09:01:10.0000] <Domenic>
Streams detaches, but uses ES directly

[09:01:33.0000] <annevk>
Does it anticipate throwing?

[09:01:59.0000] <annevk>
I guess everything using ES directly is also problematic

[09:02:20.0000] <Domenic>
It does not

[09:03:03.0000] <Domenic>
Streams needs editorial love

[09:06:51.0000] <annevk>
You gotta write up this “I’m on the IDL train now” post 😊

[09:07:30.0000] <Domenic>
Besides https://github.com/whatwg/streams/issues/963 ?

[09:09:53.0000] <annevk>
Domenic: yeah, more like a personal journey thing

[09:10:27.0000] <Domenic>
Yeah... Just gotta re figure out how my blog works

[09:10:35.0000] <annevk>
😊

[09:28:19.0000] <TabAtkins>
lol

[09:28:53.0000] <TabAtkins>
this is why i wrote myself a composer

[11:01:52.0000] <TabAtkins>
Oh man, I think I fixed the table CSS to satisfy every single design constraint we had.

[11:02:05.0000] <TabAtkins>
Gobbless display:grid

[13:06:33.0000] <dtapuska>
can someone explain "All same-agent Window objects together represent a group of Window objects that can synchronously access each other, though sometimes only after setting the document.domain attribute (in)appropriately." in the HTML spec to me... cause it seems the definition of "same-agent Window objects" doesn't contain the domain comparison

[13:19:57.0000] <Domenic>
dtapuska: looking

[13:20:23.0000] <Domenic>
dtapuska: it does contain the domain comparison in step 6

[13:21:01.0000] <dtapuska>
that is the comparison of the host attribute in the tuple

[13:21:16.0000] <dtapuska>
host and domain are different attributes in the security origin tuple

[13:21:44.0000] <dtapuska>
See definitions of https://html.spec.whatwg.org/#same-origin

[13:21:59.0000] <dtapuska>
https://html.spec.whatwg.org/#same-origin-domain

[13:23:09.0000] <dtapuska>
and https://html.spec.whatwg.org/#isplatformobjectsameorigin-(-o-)

[13:23:51.0000] <dtapuska>
I want to rewrite isplatformobjectssameorigin as if agent windows are the same.. but I can't because the definition of same agent windows seems flawed but the note talks about it

[13:25:59.0000] <Mek>
it can't just compare domain of the security origin, since it needs to allow any two origins that could end up same-origin-domain if their domain attribute was modified in some manner

[13:26:07.0000] <Mek>
i.e. the current value of the domain attribute is irrelevant

[13:32:42.0000] <dtapuska>
Ah I get it then... because in order to modify domain it needs to be same_site


2019-05-10
[19:48:01.0000] <cybai>
Domenic: would you think https://github.com/whatwg/html/issues/4356 is somehow related to the Focus meta-bug stuff 👀?

[19:49:05.0000] <Domenic>
cybai: I guess so, in that it'll be more obvious why browsers differ and are allowed to differ. It won't solve the interop problem though, unless miraculously all browsers decide to have the same focus model independent of OSes

[19:55:04.0000] <cybai>
Domenic: yeah! thanks! I was confused what a focusable area while I filed that issue. Happy to see that meta-bug :D About the interop problem, I see; it would be great if all browsers decide to have same focus model independent of OSes 😂

[20:28:58.0000] <domfarolino>
Anyone know if CSS images have a default referrer policy of no-referrer? Trying to see if this test is asserting correct behavior: https://cs.chromium.org/chromium/src/third_party/blink/web_tests/http/tests/security/resources/referrer-policy-conflicting-policies.html

[22:06:16.0000] <annevk>
domfarolino: they don’t

[22:07:43.0000] <annevk>
domfarolino: but that seems to be testing something else

[22:09:10.0000] <domfarolino>
It seems that the document's referrer policy will be the empty string since it is unset, and https://www.w3.org/TR/referrer-policy/#referrer-policy-empty-string (the example) I think indicates that it should be treated as no-referrer-when-downgrade.

[22:09:23.0000] <domfarolino>
I guess I don't see why the request should have no referrer at all, hmm

[22:28:02.0000] <annevk>
domfarolino: the meta sets it to origin, but the fetch is cross-origin

[22:28:18.0000] <annevk>
domfarolino: I’m assuming the second bit btw

[22:29:34.0000] <annevk>
domfarolino: that the meta has taken effect assumes something about delivery of the document I think

[22:30:29.0000] <domfarolino>
annevk: Ok, I was assuming it hasn't taken effect at the time of image fetching, as per "Checks that an CSS image that was created before a referrer policy was set". I am not sure if the fetch is x-origin

[22:35:00.0000] <annevk>
domfarolino: oh hmm, perhaps localhost is special?

[22:35:17.0000] <domfarolino>
annevk: Ah, I found https://cs.chromium.org/chromium/src/third_party/blink/web_tests/http/tests/security/referrer-policy-conflicting-policies.html?g=0&l=5, which I guess explains things

[22:35:26.0000] <annevk>
domfarolino: anyway, the default is not no-referrer

[22:36:22.0000] <domfarolino>
I guess the page is loaded via https, but the image request is made to an insecure origin, and therefore no-referrer-when-downgrade kicks in and results in no-referrer

[22:38:32.0000] <annevk>
So it is cross-origin

[22:39:41.0000] <annevk>
It’s weird to me the meta can take no effect, CSS is parsed sync, but this means fetches also have to be prepared sync; maybe one day CSS will define that…

[22:39:46.0000] <domfarolino>
yes, but I think the value of, or even inclusion of the meta tag is irrelevant. i think what is being exercised is the "downgrade" part, where no referrer is included in requests from secure => non-secure

[22:40:30.0000] <domfarolino>
interesting

[23:36:01.0000] <domfarolino>
annevk: so do you think it is _defined_ that the document’s RP at the time of fetching the CSS image there is the default empty string, since meta hasn’t “taken effect” yet?

[23:38:12.0000] <annevk>
domfarolino: time of fetching or creating the request for the fetch is not defined

[23:39:23.0000] <domfarolino>
annevk: Wow I’m surprised even creating the request is not defined

[23:39:37.0000] <domfarolino>
That seems..not great lol

[23:40:14.0000] <annevk>
CSS’s interaction with non-CSS is shaky

[23:47:54.0000] <domfarolino>
I see

[23:57:59.0000] <annevk>
Domenic: I'm a little surprised https://github.com/whatwg/html/pull/4603 got landed as we still have the Streams/IDL issues, or will someone file follow-ups?

[01:07:03.0000] <annevk>
FYI: https://github.com/whatwg/sg/issues/90

[03:54:50.0000] <howdoi>
const portal = document.createElement('portal');

[03:54:50.0000] <howdoi>
portal.src = url;

[03:54:51.0000] <howdoi>
portal.activate();

[03:54:51.0000] <howdoi>
^ post this, if I need to navigate back to the parent page, what should I do?

[03:56:09.0000] <howdoi>
(might be a very silly question, but not able to find it in the explainer)

[03:57:28.0000] <oliverdunk>
I believe what you want is adoptPredecessor, defined on the portalactivate event. That returns a portal containing the website you came from.

[04:03:21.0000] <howdoi>
oliverdunk: neat, let me give it a shot, portalHost also would be useful?

[04:05:11.0000] <oliverdunk>
howdoi: Are you asking so you can communicate with it? I assume portalHost would become undefined on the context that's been activated, and become defined on the context you are coming from.

[04:06:10.0000] <howdoi>
/me oliverdunk: yes, first up trying to figure out the navigate back. (too much of a grey area)

[04:11:20.0000] <oliverdunk>
You'd want to listen to the portalactivate event, and when it fires, call adoptPredecessor on the event and store the returned element. When you're ready, you could then call activate on the element you're storing somewhere to go back. I'm not sure if you need to actually embed the portal for it to stay loaded.

[04:15:59.0000] <howdoi>
What I am trying to do is a SPA, with multiple portals and seamless navigation between them...

[04:19:03.0000] <oliverdunk>
That's definitely possible, is there something about my explanation that you're struggling to understand? Happy to elaborate.

[04:45:02.0000] <howdoi>
oliverdunk: thanks a ton, trying it now

[04:48:50.0000] <tobie>
Ms2ger I saw that you had PR Preview report an error to you recently. Was it helpful and did it let you fix the issue easily?

[04:49:03.0000] <tobie>
Ms2ger: what can be improved about it?

[04:49:28.0000] <Ms2ger>
I did?

[04:49:48.0000] <tobie>
Ms2ger: https://github.com/whatwg/html/pull/4603

[04:50:35.0000] <tobie>
Ms2ger: if you look back at the edits to the OP

[04:51:51.0000] <Ms2ger>
I think that may have been in response to Domenic's edit

[04:52:51.0000] <tobie>
Ms2ger: oh! Well, Domenic if you have comments/suggestions, you're welcome.

[06:52:55.0000] <howdoi>
oliverdunk: still around?

[06:53:03.0000] <oliverdunk>
Indeed :)

[06:53:40.0000] <howdoi>
nice, just came across portal.replaceWith()

[06:56:16.0000] <oliverdunk>
That should work, although it's a ChildNode thing, rather than a portal thing: https://developer.mozilla.org/en-US/docs/Web/API/ChildNode/replaceWith

[06:57:34.0000] <howdoi>
oliverdunk: so here is what I understood:

[06:57:34.0000] <howdoi>
0. Say, example.com, has a portal to example.xyz

[06:57:34.0000] <howdoi>
1. On click of a button in example.com, we activate the portal.

[06:57:34.0000] <howdoi>
2. If example.xyz I shall have portalactivate event and get ref to example.com from adoptPredecessor

[06:57:34.0000] <howdoi>
3. Now I can navigate back to example.xyz on need.

[06:57:34.0000] <howdoi>
Correct me if I am wrong.

[06:58:48.0000] <oliverdunk>
Yep, exactly. The only caveat is that I think you need to insert the portal returned by adoptPredecessor into the DOM. I could be wrong, but I believe that if you don't, the portal will be closed.

[06:59:03.0000] <howdoi>
/me it's the same replaceWith, heh heh, forgot that portal is also an HTMLElement

[07:00:07.0000] <howdoi>
okies, trying to make two plain html pages and emulate this use case

[07:00:55.0000] <howdoi>
or rather post these two pages on two diff ports and test

[07:02:10.0000] <oliverdunk>
It sounds like what you've got should work, let me know if you have more questions. Off topic: closing a portal sounds really sci-fi and I love it.

[07:04:11.0000] <howdoi>
oliverdunk: holy goodness, I felt the same about portal closing!

[07:05:57.0000] <howdoi>
also, where I can read more about CORS, CSP and other security concerns for portal?

[07:11:31.0000] <oliverdunk>
I believe it's still up for debate, issues like https://github.com/WICG/portals/issues/17 and https://github.com/WICG/portals/issues/22 may be worth a read. The spec has an empty section for this at the moment: https://wicg.github.io/portals/#security-considerations

[07:14:57.0000] <howdoi>
hmm, interesting

[07:15:16.0000] <howdoi>
window.addEventListener('portalactivate', () => {}) is not getting trigged, but the portal is loading

[07:16:25.0000] <Domenic>
annevk: can I get a green check mark on the JSON parse PR? Will rebase and merge if so.

[07:16:55.0000] <annevk>
Domenic: ah yes, will do that

[07:16:56.0000] <oliverdunk>
howdoi: Looks good to me. You're aware that it only fires after the activate() call?

[07:18:27.0000] <howdoi>
oliverdunk: yes, but if page-1 is loading it via <portal src="domain/page2"/> is in't like activate?

[07:19:19.0000] <oliverdunk>
Nope, at that point all you've got is window.portalHost. activate means when the portal becomes full screen, takes over the address bar etc.

[07:22:17.0000] <howdoi>
but I don't see page-1 contents, I just see page-2 the contents when I load page-1 which has the portal element in it

[07:23:55.0000] <oliverdunk>
So you're embedding page2 into page1 as a portal the same size as the viewport?

[07:24:32.0000] <howdoi>
yup

[07:25:26.0000] <oliverdunk>
So the idea is that page1 is almost like an invisible host that just manages sending you between the pages?

[07:26:42.0000] <howdoi>
Finally, I would like to have multiple portals in page1, let me reduce the the viewport and see, I get the point

[07:28:34.0000] <howdoi>
Rather for now, let me have a button which on click loads the portal, there by invoking activate

[07:28:52.0000] <oliverdunk>
Is your goal multiple portals on page1 displayed in a grid? Or multiple full size portals with only one visible at a time?

[07:28:58.0000] <oliverdunk>
Or something else entirely :P

[07:29:12.0000] <howdoi>
I was trying to gauge the difference between explicit activate call vs <portal />

[07:29:58.0000] <howdoi>
hah hah, grid of portals, that should go fullscreen on user actions

[07:34:52.0000] <howdoi>
Failed to execute 'activate' on 'HTMLPortalElement': The HTMLPortalElement is not associated with a portal context, what, but why?

[07:35:27.0000] <oliverdunk>
Is this going from page2 back to page1? It sounds like you the portal was closed because it wasn't added to the DOM.

[07:38:51.0000] <howdoi>
it wasn't added, right!

[07:39:14.0000] <howdoi>
now I am seeing an unexpectedly closed the connection.

[07:40:22.0000] <oliverdunk>
Where's that?

[07:40:22.0000] <howdoi>
localhost:3000 is the main page, localhost:3001 is the portal page; in the main page I have a button on click loads the portal

[07:42:13.0000] <oliverdunk>
howdoi: can you go through where exactly the error appears? Although it sounds like a server error rather than something wrong with your JavaScript.

[07:43:50.0000] <howdoi>
oliverdunk: both the main page and the portal page loads fine independently, from page one on button click I create a portal element, assign the src to the portal page, append it to the html and invoke activate; but after I click the button it loads a fullpage with an unexpectedly closed the connection.

[07:44:22.0000] <howdoi>
duh! my bad, `https` hmm

[07:45:26.0000] <howdoi>
https://usercontent.irccloud-cdn.com/file/kjLQUyRp/hmm%2C%20I%20had%20given%20it%20as%20https%3A%2F%2F%20instead%20of%20http%3A%2F%2F

[07:47:15.0000] <howdoi>
So, now on click the portal loads fullscreen, but portalactivate event is not getting triggered yet

[07:47:55.0000] <howdoi>
also, when the portal loads, devtools close

[07:51:02.0000] <oliverdunk>
I'm seeing the same, that looks like a bug. Not sure why the event isn't called.

[07:53:09.0000] <oliverdunk>
There's definitely a portalactivate event listener registered, and then you call activate()?

[07:56:22.0000] <howdoi>
oliverdunk: yes, should we report the devtool bug? {I am sure someone else would have}

[07:57:31.0000] <oliverdunk>
I couldn't see anything: https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component%3ABlink%3EHTML%3EPortal+. I decided not to bother, as it'll almost definitely be picked up as they work on DevTools support - no harm in doing so if you want to, though.

[07:59:15.0000] <howdoi>
okies, for now focusing on get this thing done

[08:06:34.0000] <howdoi>
oliverdunk: the `portalactivate` not triggering could be a bug too?

[08:07:02.0000] <howdoi>
let me relaunch canary, I was on 76.0.3789.3

[08:08:09.0000] <howdoi>
same

[08:08:28.0000] <oliverdunk>
It seems pretty fundamental to me and I'd be surprised if it wasn't spotted. I'm also not having any trouble on my end. Are you able to share your code?

[08:08:53.0000] <howdoi>
sure

[08:13:19.0000] <howdoi>
oliverdunk: https://gist.github.com/hemanth/ebb6a2e01f10c515162b4af7efd91474 format is screwed

[08:20:07.0000] <oliverdunk>
Huh. I guess portalactivate is being called before your event listener was registered.

[08:23:11.0000] <oliverdunk>
Not certain if that's something that should be fixed or not, probably worth making an issue for. In the meantime, you could add a delay - or for a more robust solution, have the second page post a message to the host when it's ready.

[08:28:56.0000] <howdoi>
`portalactivate` should be in portal page itself right?

[08:29:41.0000] <oliverdunk>
Yep. By issue I meant one on the spec by the way, rather than a chrome bug.

[08:37:01.0000] <howdoi>
oliverdunk: did we find a bug in spec!?!

[08:38:48.0000] <oliverdunk>
Bug is maybe pushing it, but a potential omission! It makes sense that the event is missed - but I can see other people doing what you've done, so perhaps the "default" behaviour of the browser should be overridden. Worth saying that I'm not involved in the spec at all - just a fan of portals like you.

[08:39:16.0000] <oliverdunk>
Did you want to open an issue? If not I'm happy to do so.

[08:44:43.0000] <howdoi>
oliverdunk: I am :) I just opened one with devtools

[08:48:41.0000] <howdoi>
oliverdunk: https://bugs.chromium.org/p/chromium/issues/detail?id=961740 I guess I am missing something trivial, but let us see

[08:53:56.0000] <oliverdunk>
I feel bad, but in looking for your first issue, I stumbled onto https://bugs.chromium.org/p/chromium/issues/detail?id=961142 - didn't think to look under DevTools . If you can you probably want to close yours as a duplicate. For the second it's probably better at https://github.com/WICG/portals/issues. Chrome's implementation is fine, the discussion to be had is about if the spec should have a special case for when the page hasn't

[08:53:56.0000] <oliverdunk>
 loaded yet.

[09:15:10.0000] <smaug____>
Domenic: https://github.com/web-platform-tests/wpt/blob/master/html/webappapis/scripting/processing-model-2/unhandled-promise-rejections/support/promise-rejection-events.js#L461 isn't quite right, I think

[09:16:09.0000] <smaug____>
postMessage and timers use different task sources, so any ordering between those can't be guaranteed

[09:16:38.0000] <Domenic>
Yeah, that makes sense. Can we find any DOM manipulation task source replacement for postMessageTask?

[09:17:37.0000] <smaug____>
let me try to find and fix the test (first in Gecko wpt)

[09:17:59.0000] <Domenic>
Thank you!

[09:18:18.0000] <howdoi>
oliverdunk: I got in touch with the spec authors let us see what they have to say, before we file an issue?

[09:19:09.0000] <oliverdunk>
Sure

[09:38:14.0000] <smaug____>
A simple DOM manipulation task source task: data:text/html,<script>var d = document.createElement("details"); d.ontoggle = function() { console.log("a task"); }; d.setAttribute("open", "");</script>

[09:38:18.0000] <smaug____>
hacky, but simple

[10:11:09.0000] <Domenic>
Perfect :)

[10:52:13.0000] <eeeps>
https://w3c.github.io/ServiceWorker/#cache-addAll Under the process the response substeps -- specifically the bit about Vary --I'm guessing that "If fieldValue matches '*'" means, match the literal string '*"? So addAll wont' cache anything that has "Vary: *"? (but it will cache for other, non-wildcard values of Vary?)

[12:42:09.0000] <eeeps>
[nvm], confirmed that it's screening out `Vary: *`, which apparently people use, as a form of cache control??


2019-05-11
[11:46:50.0000] <bkardell>
hey so, I was meeting with developer friends online and we got to talking about shadow dom and a number of conversations came up for which I couldn't recall some of the rationale for answers we came up with so I began digging back in history and I think I wound up with just different questions...

[11:47:23.0000] <bkardell>
 Is the reason that we shaped a lot of the characteristics of shadow dom the way we did (you can't remove them, we throw rather than replace or something if you try to do it again) bound up in the original talks from circa 2011 where the proposals had mutple shadow roots

[11:48:50.0000] <bkardell>
or is there a real good reason why you can't specifically say 'yes, I really do intend to replace any shadow root that might exist with this one instead'

[11:52:26.0000] <bkardell>
I realize that seems to beg for a use case at some level since it seems like you could just replace the _contents_ of a shadow root, so for context it was bound up in reasoning and discussion about all sorts of aspects about 'native' shadow roots and what things would throw and why and them trying to come up with some way around challenges

[14:02:10.0000] <howdoi>
the portal is not associated with a predecessor browser context, when would this happen?

[15:28:51.0000] <howdoi>
var portal = e.adoptPredecessor();

[15:28:51.0000] <howdoi>
document.body.appendChild(portal);

[15:28:51.0000] <howdoi>
But now, I am able not able to do any actions on the appended child....am I missing something?

[15:29:56.0000] <howdoi>
also, we can't invoke `e.adoptPredecessor();` twice in `onportalactivate` ?


2019-05-12
[09:32:49.0000] <howdoi>
/me ƒ SMSReceiver() { [native code] } wow!

[10:06:24.0000] <oliverdunk>
annevk: out of curiosity, am I right in thinking that the comment you asked me to modify won't be rendered anywhere? I guess the idea is for implementors to look at the source for additional notes?

[10:47:03.0000] <annevk>
It’s mostly for those maintaining the standard

[10:47:34.0000] <annevk>
Implementers won’t view source

[11:28:58.0000] <oliverdunk>
Thanks :) I should setup ZNC, my Mac goes to sleep a lot...


2019-05-13
[23:20:11.0000] <ondras>
can anyone please point me to a RFC where the SameSite attribute is defined?

[23:20:41.0000] <ondras>
the recent Chrome cookie treatment recommends putting SameSite=None on cookies that are to be used as 3rd party, but MDN says that None is not a valid value

[23:23:29.0000] <TimothyGu>
ondras: https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-5.3.7

[23:24:28.0000] <ondras>
TimothyGu: thanks! this is only a draft, right? how does one find what draft is the proper draft? :)

[23:25:12.0000] <TimothyGu>
ondras: that's the most current one. If you click on "Tracker" at the top of the draft then you can find the history/status

[23:26:33.0000] <TimothyGu>
In particular, it's been there in some form since 2014 though the first document to call it SameSite is draft-west-first-party-cookies-05 in 2016

[23:26:42.0000] <ondras>
TimothyGu: nice, thanks. still a bit overwhelming, but I will try to understand the timeline at the top :)

[23:26:59.0000] <ondras>
my current issue is the 'None' value

[23:27:09.0000] <ondras>
that is recommended by Google

[23:27:21.0000] <ondras>
(but rejected by Chrome up to 66)

[23:28:52.0000] <TimothyGu>
ondras: https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-4.1.2.7 defines the meaning of None

[23:29:00.0000] <TimothyGu>
ondras: it was only implemented in Chrome in https://chromium-review.googlesource.com/c/chromium/src/+/1573081

[23:29:31.0000] <TimothyGu>
ondras: which per https://chromiumdash.appspot.com/commits?commit=324657c38b04e13532d952c90674bc453b634706&platform=Linux is only in 76

[23:29:41.0000] <ondras>
yes

[23:29:48.0000] <TimothyGu>
to be released in July

[23:30:10.0000] <ondras>
but support for non-{lax,strict} values was added in https://chromium.googlesource.com/chromium/src/+/5fbb75e93162093522879e707a13295b7452ef06%5E%21/#F2

[23:30:27.0000] <ondras>
so if I start sending samesite=none, chrome66 and older will reject those

[23:31:35.0000] <TimothyGu>
ondras: do you have any idea how much market share Chrome <66 has?

[23:31:40.0000] <ondras>
no

[23:32:08.0000] <ondras>
but i suppose that might include older android devices/browsers

[23:32:17.0000] <ondras>
that are extremely popular here in Czech Republic :/

[23:32:57.0000] <TimothyGu>
ah…

[23:33:31.0000] <ondras>
my initial plan was to start adding somesite=none to our cookies that are to be used in a 3rd party manner

[23:33:42.0000] <ondras>
but I will have to re-consider

[23:35:44.0000] <TimothyGu>
ondras: I suppose some telemetry would be useful for your case

[23:40:53.0000] <ondras>
perhaps

[23:41:32.0000] <ondras>
or, well, not forcing the None value when it even is not yet accepted as a RFC? :)

[23:43:13.0000] <TimothyGu>
ondras: I would strongly encourage looking at implementation status rather than RFC approval as if a feature is ready

[23:43:43.0000] <ondras>
:/ okay

[23:44:11.0000] <TimothyGu>
it's pretty common for a standardized feature to get hung up on approval due to bureaucratic matters

[23:46:19.0000] <ondras>
is this the case?

[23:46:29.0000] <TimothyGu>
that, I don't know :)

[23:50:12.0000] <ondras>
the draft we are talking about, https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-5.4, it defines a storage model

[23:50:21.0000] <ondras>
I might not be good at reading RFCs

[23:50:36.0000] <ondras>
but it looks to me like the model says "samesite=none" equals to no samesite attribute

[23:51:00.0000] <ondras>
(step 13)

[23:51:09.0000] <ondras>
do I interpret this correctly?

[23:51:16.0000] <TimothyGu>
I think so

[23:51:35.0000] <ondras>
okay. so this is the behavior chrome76 is not going to follow?

[23:52:55.0000] <TimothyGu>
ondras: Why do you say Chrome 76 isn't going to follow that behavior?

[23:53:18.0000] <ondras>
TimothyGu: because they are going to implement "no samesite attribute equals to samesite=lax"

[23:53:30.0000] <ondras>
or that is what I understood

[23:56:17.0000] <TimothyGu>
ondras: implementing ≠ enabling by default

[23:56:48.0000] <TimothyGu>
ondras: from https://web.dev/samesite-cookies-explained/ it just seems like 76 adds a flag. there's probably going to be a bit of time before Lax is made the default

[23:58:25.0000] <TimothyGu>
ondras: also, the proposed change to make lax default is captured in https://tools.ietf.org/html/draft-west-cookie-incrementalism-00#section-3.1

[23:59:03.0000] <TimothyGu>
I expect it to be quite a while before these changes to the default are implemented

[00:01:10.0000] <ondras>
TimothyGu: okay, thanks for explanation

[03:21:46.0000] <oliverdunk>
@ondras What do you mean by rejected? From the article: "any clients that do not recognize SameSite=None as of yet should ignore it and carry on as if the attribute was not set." - by which it means, the browser hasn't been updated so still uses the less secure default, which will work third party.

[03:24:40.0000] <ondras>
oliverdunk: well Chrome up to 66 ignores (does not store) cookies with SameSite=xyz (or None or any other non-Lax non-Strict value)

[03:26:16.0000] <ondras>
https://medium.com/compass-security/samesite-cookie-attribute-33b3bfeaeb95

[03:26:33.0000] <ondras>
this article describes the behavior; probably with chrome 62 or 63

[03:26:47.0000] <ondras>
my further testing on browserstack confirmed the said behavior up to 66

[03:37:20.0000] <oliverdunk>
ondras: Gotcha, so Chrome didn't have that behaviour until the patch you linked. You should get in touch with the article's authors as it seems like an important thing to note :)

[03:51:29.0000] <ondras>
oliverdunk: okay, why not

[05:05:28.0000] <annevk>
oliverdunk: please ping me once the agreement thing is sorted and I'll get back to the DOM PR, leaving it for now

[07:36:14.0000] <oliverdunk>
No worries, will do!

[07:49:27.0000] <bkardell>
he did anyone see this q -> https://freenode.logbot.info/whatwg/20190511#c2171308 - maybe @annevk or @Domenic knows?

[07:49:48.0000] <Domenic>
bkardell: I had a really hard time understanding that... could you try something more brief?

[07:50:30.0000] <bkardell>
sure... so, back in original proposals Dimiti and team worked out complex multi-shadow root ideas

[07:50:49.0000] <bkardell>
then at some point the decision was 'nah, let's just have one and it would throw if you did another'

[07:51:38.0000] <bkardell>
but there's also no way to remove it and native ones can look like they have none but throw (iirc)

[07:53:43.0000] <bkardell>
there was some discussion about how you would go about trying several things and the question was asked 'why is it that way' and.. I honestly couldn't recall beyond what I just said.  Why can you not delete or remove a shadow root?

[07:55:15.0000] <bkardell>
I looked, but I couldn't find anything beyond those early discussions which never asked _this_ question, but were based on you can only have one, not many

[07:55:40.0000] <bkardell>
any better?

[08:02:53.0000] <Domenic>
"why can you not delete or remove a shadow root", is the question?

[08:03:01.0000] <Domenic>
Are you asking about your own shadow root, or someone else's?

[08:09:38.0000] <bkardell>
can you help me understand the distinction?

[08:10:11.0000] <bkardell>
how do I know about ownership? unless you mean author defined (any author) vs native?

[08:27:36.0000] <Domenic>
I mean custom element author vs. custom element user.

[08:29:56.0000] <annevk>
bkardell: a lot of this boils down to more choices meaning more complexity

[08:30:20.0000] <annevk>
bkardell: and cutting down on complexity that wasn't justified to the extent people needed it to be

[08:31:34.0000] <annevk>
bkardell: it's not really "nah", it's that doing it requires answering "how" and that not necessarily being straightforward

[08:34:04.0000] <bkardell>
no I just meant 'nah' was the decision on multi-root designs for the time being - those discussions I recall - but I don't recall why there is no corresponding way to detach/remove one

[08:34:27.0000] <annevk>
bkardell: that was not a "nah" decision, there were a lot of complexity arguments put forward

[08:35:17.0000] <bkardell>
I think maybe something is getting lost/overread... 'nah' is just intended as 'we decided not to for now' and nothing more

[08:35:33.0000] <annevk>
"nah" makes it sound like it wasn't duly considered

[08:35:36.0000] <bkardell>
I see

[08:35:49.0000] <bkardell>
ok, sorry, didn't intend to give that impression, was trying to be brief

[08:35:52.0000] <annevk>
Whereas there are good reasons not to go there

[08:36:17.0000] <bkardell>
yeah, no I agree - there was a lot of complexity in those proposals

[08:36:55.0000] <bkardell>
but I don't recall one about whether you could remove the one we decided to have - but you can't

[08:37:12.0000] <bkardell>
that is what I am asking about - do you recall discussions on that? I can't find any

[08:37:19.0000] <bkardell>
and I can't recall

[08:38:11.0000] <annevk>
I can see issues, e.g., it's no longer clear how ShadowRoot.prototype.innerHTML works

[08:38:46.0000] <annevk>
A ShadowRoot not having a host would likely complicate other algorithms too

[08:39:13.0000] <bkardell>
but wouldn't removing it just cause it to be freed?

[08:39:35.0000] <annevk>
bkardell: that doesn't sound like JavaScript

[08:40:56.0000] <bkardell>
hmm... I am confused by the appropriate level of detail I should be providing to be clear possibly

[08:42:40.0000] <bkardell>
like element.removeShadowRoot() (or better name) could return no ref to the removed root - are you saying that doesn't sound like JavaScript?

[08:46:48.0000] <annevk>
Yes, because it already has a ref

[08:49:08.0000] <bkardell>
got it

[08:49:18.0000] <bkardell>
sorry, I see what you mean now

[08:53:30.0000] <Ms2ger>
Domenic, hey, did you end up working on IDL/kv-storage?

[09:11:08.0000] <Domenic>
Ms2ger: no, after seeing you'd already done most of the work, it felt less urgent... I guess it'd still be worthwhile for one of us to factor out the module pieces that could land sooner, leaving the rest in prose? I dunno.

[09:11:38.0000] <Domenic>
bkardell: I wasn't around for early discussions, so if the question is "do you recall such discussions" I don't. (What I meant by brevity is mostly stating concrete questions.)

[09:12:21.0000] <Domenic>
bkardell: if the question is "why can you not delete or remove a shadow root", it depends on you. A custom element user removing a shadow root is an encapsulation violation. A custom element author removing a shadow root doesn't seem to add much over allowing them to just replace the contents with whatever they want.

[09:13:37.0000] <bkardell>
"A custom element author removing a shadow root doesn't seem to add much over allowing them to just replace the contents with whatever they want." - yeah, I agree

[09:13:55.0000] <bkardell>
thanks

[09:23:43.0000] <bkardell>
@Domenic on asking concrete questions, will try to do so in the future :)

[09:41:01.0000] <Domenic>
TabAtkins: $ bikeshed update / Updating via manifest... / Local data is already up-to-date (2019-05-06 04:51:06.668829). Done!

[09:41:06.0000] <Domenic>
Where are my updated dfns :((

[09:41:57.0000] <TabAtkins>
Oh jeez, my computer just have fallen over at work.

[09:42:36.0000] <TabAtkins>
And between vacation, IO, and sick wife, I haven't been to the office since then

[09:43:04.0000] <TabAtkins>
I need to figure out how to put this on something external. 😑

[09:46:13.0000] <TabAtkins>
I should be able to run it manually from my laptop tho, I'll check on that in a sec

[09:53:18.0000] <Domenic>
haha I see

[09:55:42.0000] <TabAtkins>
Domenic: Okay, data should be pushed up now.

[09:57:15.0000] <TabAtkins>
(Remember that you can always run `bikeshed update --skip-manifest`, if you want to force a full update manually without relying on the manifest data.)

[09:57:59.0000] <TabAtkins>
(But thank you for the ping anyway.)

[09:58:38.0000] <Domenic>
Ah, I did not know that, although I suppose I could have checked the docs

[10:01:24.0000] <TabAtkins>
Or `bikeshed update -h` ^_^

[14:16:47.0000] <ecobos>
TabAtkins: btw, the more I touch specs, the more I appreciate bikeshed, it's really nice :)

[14:16:54.0000] <TabAtkins>
<3

[16:05:26.0000] <domfarolino>
Is there a way in spec land to determine whether an image was created/inserted by the parser as opposed to by script etc? I know <script>a have a parser inserted flag, but seems images do not.

[16:09:42.0000] <domfarolino>
<script>s*

[16:38:11.0000] <zcorpan>
domfarolino: no

[16:52:27.0000] <domfarolino>
zcorpan: One thing with Chromium’s LazyLoad impl is that scripts created in any way that’s not by the parser naturally (i.e., by some script) will never be lazy loaded when loading=auto. I’m wondering if it is reasonable to express this in spec by saying something to the effect of “if the image was not created by the parser, set loading attr to eager”.

[16:53:16.0000] <domfarolino>
This may help address some of JakeA’s concerns, but would introduce the concept of being able to determine how the img was created

[16:53:51.0000] <zcorpan>
domfarolino: would it be good enough to make new Image() set the loading attribute?

[16:54:01.0000] <zcorpan>
similar to new Audio()

[16:55:32.0000] <zcorpan>
but if web compat needs document.createElement('img') to be eager, but parsed <img> not, then sure


2019-05-14
[17:02:51.0000] <domfarolino>
Personally I’d be fine with just new Image() doing so, but would like to know Jake’s thoughts as he’s had the most feedback in that realm. Good call

[06:38:29.0000] <dtapuska>
annevk: where in the spec is the opaque origin assigned based on the sandbox flags?

[06:49:14.0000] <annevk>
dtapuska: it's bad speccing, but "If the Document's active sandboxing flag set has its sandboxed origin browsing context flag set"

[06:50:11.0000] <annevk>
Once we get to the point where we know when to allocate a Document given a bunch of state, we should be doing this origin assignment there

[06:54:11.0000] <dtapuska>
annevk: because the determination of the agent cluster needs to be after that point..

[06:55:02.0000] <dtapuska>
That is why I have it in those steps after the application of the sandbox

[06:55:59.0000] <annevk>
dtapuska: well, the current setup is wrong

[06:56:49.0000] <Domenic>
annevk: ping for https://github.com/whatwg/html/pull/4473 green checkmark and/or opinions on multiplication operator typography

[06:57:17.0000] <annevk>
dtapuska: we should not be able to allocate a document without an agent and we should be able to determine an origin for an upcoming agent/global/document without creating a document first

[06:57:31.0000] <dtapuska>
annevk: I agree, and I like your approach, but the question is how do we really get there. Chrome has a DocumentInit that we pass into the Document constructor, it really seems we need to specify that... and that the agent would be assigned in the construction of the DocumentInit..

[06:57:38.0000] <dtapuska>
as well as the opaque origin

[06:58:38.0000] <annevk>
Domenic: I guess I wonder if there is any style guide that other graphic specs use, but I'm prolly about to be disappointed

[07:00:24.0000] <annevk>
dtapuska: yeah, I discussed this other thing with Ian Clelland that I'm also running into now that we have this bunch of inherited state (CSP list, referrer policy, feature policy, base URL) that we really ought to copy when navigation begins (from whoever initiated) and then use when we create the document to default things that are not overridden

[07:00:24.0000] <annevk>
explicitly in case it's a document created by about:blank, srcdoc, blob:, data:, etc.

[07:00:44.0000] <annevk>
dtapuska: which is vaguely related, but different

[07:01:26.0000] <annevk>
Domenic: I'll r+ given fserb said okay and it's an improvement

[07:01:53.0000] <Domenic>
\o/

[08:51:35.0000] <annevk>
dtapuska: Domenic: perhaps allocating the agents at the wrong point in time is an improvement indeed over waiting for proper documents, I'll have to think about that suggestion some more

[08:52:28.0000] <annevk>
dtapuska: Domenic: I hadn't really considered it so far since it doesn't help Cross-Origin-Opener-Policy, which requires replacing the browsing context

[09:14:28.0000] <Domenic>
Ah yeah, that makes sense. To me it's all just a long backlog, and the more incremental progress we can make the better.

[09:27:18.0000] <cybai>
Domenic: I have a question about `fetch a module script graph`

[09:28:10.0000] <cybai>
I found the step 23 in https://html.spec.whatwg.org/multipage/#prepare-a-script said "Let settings object be the element's node document's relevant settings object." and pass it to `fetch a module script graph` in step 24.6 for both classic and module scripts

[09:29:07.0000] <cybai>
However, in step 2 of https://html.spec.whatwg.org/multipage/#fetch-a-module-script-tree, we pass two `setting object` to `internal module script graph fetching procedure`

[09:30:02.0000] <annevk>
dtapuska: one thing that struck me is that it does not remove the same-site agent stuff, it seems it should be possible to remove that as agents are now explicitly allocated/selected, but admittedly I did not study in detail yet

[09:30:10.0000] <cybai>
We can know from the description of `internal module script graph fetching procedure`, the first setting object is `fetch client settings object` and the second one is `module map settings object`

[09:30:38.0000] <cybai>
Should we pass two different setting object from "prepare a script" step 24.6 instead?

[09:30:47.0000] <cybai>
Thanks 🙇

[09:33:24.0000] <cybai>
(will it be good to file an issue for this?)

[09:36:37.0000] <dtapuska>
annevk: ya I didn't know if we wanted to store the agent somewhere and that would make it easier.. I "Obtain" an agent but I don't stash it somewhere.. A same-agent window can just be defined as if the agent is the same object...

[09:40:40.0000] <annevk>
dtapuska: aah I see, I think we need to stash it as the same-site thing is broken when the browsing context is discarded or some such

[09:41:39.0000] <annevk>
dtapuska: though basically if you put it in the agent cluster you can always get it from there as it’ll be the only agent for that key

[09:41:50.0000] <annevk>
dtapuska: only window agent

[09:44:19.0000] <dtapuska>
annevk: My idea is that there may be agent clusters not in the shared agent cluster table though

[09:44:44.0000] <dtapuska>
annevk: consider a policy as I proposed, a "document-access" policy basically puts a document in its own agent

[09:44:56.0000] <dtapuska>
so it doesn't need to go into the table.

[09:45:12.0000] <annevk>
dtapuska: those should not matter here as the lookup path is diff?

[09:45:34.0000] <dtapuska>
Nor does the table contain the correct agent cluster.. if I look it up based on domain it might return something else

[09:46:09.0000] <dtapuska>
Why would the lookup path be diff.. it isn't an opaque origin

[09:46:57.0000] <annevk>
I was assuming that if there is a policy we would alter the key or look elsewhere

[09:47:12.0000] <annevk>
Otherwise you end up with the same cluster

[09:49:08.0000] <dtapuska>
Right I was thinking the policy could be implement as "if policy set, return a new AgentCluster{ new Agent()}" instead of looking at the table.. ie; basically a step inserted into "obtain similar-origin window agent"

[09:50:07.0000] <dtapuska>
that was why I called it "shared agent clusters" as opposed to "list of all agent clusters"

[09:50:35.0000] <Domenic>
cybai|leave: for those cases, they are the same. The worker cases are where they are different.

[09:51:00.0000] <Domenic>
cybai|leave: it's fine to file issues for questions like that, or ask here :).

[09:53:48.0000] <annevk>
dtapuska: sure, but when there’s no policy getting the agent from the bcg’s agent clusters seems fine

[09:56:49.0000] <dtapuska>
annevk: Yes it would be, but if we implemented a policy then it would be problematic, we'd need to stash it somewhere. Also a lookup might be expensive if we consider adding a rule around IsPlatformObjectSameOrigin to check that they are same-agent windows.

[09:59:03.0000] <annevk>
dtapuska: I suspect I can leave more considered design feedback tomorrow, but I don’t really see why that is yet. Getting to an agent from a global should be really cheap and does not require a lookup

[09:59:56.0000] <dtapuska>
annevk: Sounds good.. have a good evening

[10:00:20.0000] <annevk>
dtapuska: I was missing that as well, allocating globals in the agents rather than out-of-band


2019-05-15
[17:35:35.0000] <cybai|leave>
Domenic: I see! Thanks!

[00:35:00.0000] <hsivonen>
annevk: does the Web Platform have support for identity encode into Uint8Buffer?

[00:35:22.0000] <hsivonen>
annevk: i.e. take the low 8 bits of each code unit in a JS string and put them into an array buffer?

[00:35:44.0000] <hsivonen>
(assuming the high half of each UTF-16 code unit is zero)

[00:36:56.0000] <TimothyGu>
hsivonen: there's https://infra.spec.whatwg.org/#isomorphic-encode, which unfortunately has an assert against having non-zero high half

[00:38:27.0000] <annevk>
TimothyGu: did you need something like that in a spec without the assert?

[00:39:00.0000] <TimothyGu>
hsivonen: (uhm) ^^

[00:39:14.0000] <annevk>
hsivonen: ByteString, but nothing exposed "raw"

[00:39:41.0000] <annevk>
hsivonen: ByteString throws for > U+0255

[00:39:50.0000] <annevk>
euhm

[00:40:15.0000] <annevk>
> U+00FF

[00:40:28.0000] <annevk>
I need more sleep

[00:40:48.0000] <hsivonen>
TimothyGu: I meant: Is that exposed as a JS API?

[00:41:59.0000] <annevk>
hsivonen: nope, we had some requests for "true iso-8859-1" but nothing came of that thus far

[00:42:00.0000] <hsivonen>
that is, do we have a story for piece-wise migration from JS strings as containers for binary data to Uint8Array?

[00:42:07.0000] <hsivonen>
annevk: thanks

[00:42:29.0000] <annevk>
hsivonen: I think in part because you strongly opposed some of this early on

[00:42:42.0000] <hsivonen>
oh?

[00:43:06.0000] <annevk>
hsivonen: well, maybe not distinct APIs, but putting them in TextEncoder/TextDecoder

[00:43:23.0000] <hsivonen>
that's different

[00:44:24.0000] <annevk>
Okay, so I've seen requests for "true ascii" and "true iso-8859-1", not sure about ignoring the non-significant bits though

[00:44:50.0000] <annevk>
And there've been requests for TextEncoder/TextDecoder-style APIs around base64

[00:45:25.0000] <annevk>
It's not entirely clear to me what the right approach is as I'm not sure they're worth that much additional classes

[00:46:28.0000] <annevk>
And putting first-class support for these in JS and not putting first-class support for UTF-8 in JS could also give the wrong incentive to folks

[00:46:53.0000] <hsivonen>
at this time, I'm not asking for anything to be added

[01:03:21.0000] <annevk>
hsivonen: okay, curious what made you consider this; did you see a bunch of JS strings containing "binary data"?

[01:09:58.0000] <hsivonen>
annevk: Thunderbird

[01:10:29.0000] <hsivonen>
so not a Web use case

[01:28:45.0000] <annevk>
ta

[06:24:03.0000] <Ms2ger>
Script experts! In https://html.spec.whatwg.org/multipage/scripting.html#execute-the-script-block , can currentScript ever not be null if the script is a module script?

[06:24:12.0000] <Ms2ger>
Domenic, zcorpan ^

[06:25:44.0000] <Domenic>
Ms2ger: depends on what you mean. That step will set it to null. But if you then synchronously insert a <script>, maybe it can overwrite it... not sure if that's possible though since we disallow top-level document.write, and inserting a script from script will make it async...

[06:26:54.0000] <zcorpan>
it is both null and not null until you observe it

[06:27:19.0000] <Domenic>
Probably though any top-level code that runs inside a <script type=module> or its dependencies will see document.currentScript === null. My guess is there are not any tricks to break that, without going back to the event loop in some way.

[06:27:22.0000] <Ms2ger>
No, I mean, I think it should already be null at the start of the algorithm, since module scripts never execute sync (right?)

[06:27:32.0000] <Domenic>
Oh

[06:28:27.0000] <Domenic>
Wow, interesting, I think you are correct. That's a nice simplification...

[06:34:33.0000] <zcorpan>
Domenic: Ms2ger: the only caller i'm unsure about whether it is free of bugs is https://html.spec.whatwg.org/multipage/xhtml.html#parsing-xhtml-documents:execute-the-script-block

[06:35:08.0000] <zcorpan>
(I mean, I'm not sure any other part is free of bugs, but you know what I mean)

[06:35:35.0000] <Ms2ger>
Can a module script be the pending parsing-blocking script?

[06:35:53.0000] <annevk>
Even with import() you cannot dictate when execution happens?

[06:36:22.0000] <Ms2ger>
import() returns a promise

[06:36:47.0000] <Domenic>
It cannot be a pending parsing-blocking script, I just traced it

[06:36:58.0000] <Domenic>
(Wow, that XML <script> section is scary.)

[06:37:09.0000] <zcorpan>
Ms2ger: no. I think this part of the spec is fine, upon closer thought. "Prepare" is the same as for text/html parsing

[06:37:21.0000] <annevk>
Ms2ger: it's the other thing that it does that's important, but I guess it queues a task to execute and resolve the promise

[06:37:48.0000] <annevk>
(and not give you a handle on something you get to execute)

[06:38:42.0000] <annevk>
Ms2ger: can Wasm be an escape hatch?

[06:39:44.0000] <Domenic>
"execute a script block" is only for <script>s

[06:40:27.0000] <Domenic>
A more explicit name would probably be something like "run a script created by a script element"

[06:41:20.0000] <annevk>
ah yeah

[06:55:11.0000] <Ms2ger>
https://github.com/whatwg/html/pull/4627

[10:09:25.0000] <annevk>
nox: I have a fun test

[10:09:58.0000] <annevk>
nox: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/6910

[15:10:03.0000] <Domenic>
Ms2ger who hopefully reads scrollback: littledan: I think we should be able to merge JSON modules into the spec tomorrow-ish, I don't recall any blockers besides maybe some nits, and the tests M2ger has done seem good enough to get us started until an implementer gets involved to add more alongside their implementation. The PRs to merge are Web IDL synthetic modules, then HTML + WPT. I'll try to do that tomorrow.

[15:20:33.0000] <littledan>
Domenic: 🍾

[15:21:10.0000] <littledan>
Your test suggestions seemed good to me; agree there is still a bit more to do there


2019-05-16
[08:24:17.0000] <annevk>
Domenic: hey, could you look at https://github.com/whatwg/html/issues/4604 today?

[08:56:20.0000] <Domenic>
annevk: ugh now I have to understand all that :-/. If the claim is it's an editorial change, it's harder to prioritize, but I'll try...

[08:59:29.0000] <Domenic>
annevk: BTW I think the issue template is working out really well and I already want it on other repos.

[10:01:31.0000] <annevk>
Domenic: it seems diff from editorial given the change from weak set to set, but I could not quite understand it

[10:05:28.0000] <annevk>
As for the template, should be easy to copy; cross-repo files would be neat

[10:49:29.0000] <annevk>
Domenic: the other context for that issue is that we have a Fx impl and want to ensure it’s correct

[10:51:43.0000] <Domenic>
My understanding was that the proposal was just to use a different implementation strategy to achieve the same result, but I will investigate further.

[10:52:56.0000] <annevk>
Yeah, but Edgar wants to be sure that is actually correct


2019-05-17
[01:38:44.0000] <Ms2ger>
  - RESOLVED: Add a new url function that accepts only <string>, name tbd (Issue #451: Add url() alias that does not accept unquoted URLs)

[01:40:47.0000] <annevk>
I'm pretty sure they thought they had already resolved this

[01:41:19.0000] <annevk>
/me whispers something about tests, reviewed PRs, and implementer signoff

[01:52:09.0000] <annevk>
Domenic: any idea why https://pthatcherg.github.io/web-transport/ invents new stream types?

[06:09:49.0000] <Domenic>
annevk: not really sure... I think they have the feedback that it's bad and won't get far, but I haven't seen much movement on the spec level.

[06:11:24.0000] <annevk>
kk

[16:14:33.0000] <hyspace>
Hello everyone

[16:14:55.0000] <hyspace>
I have a question about html tokenization

[16:16:09.0000] <hyspace>
In https://html.spec.whatwg.org/multipage/parsing.html#decimal-character-reference-state, we need to Multiply the character reference code by 10. Add a numeric version of the current input character (subtract 0x0030 from the character's code point) to the character reference code.

[16:16:55.0000] <hyspace>
The spec did not say what if the range is beyond range of int32

[16:17:48.0000] <hyspace>
if we keep multiply, it is possible that the character reference code will go back to Unicode range

[16:20:06.0000] <hyspace>
For example, if we use Int32 type for character reference code, we can craft a input as &#x1000000050; which will beyond the range of Int32 and goback to Unicode range and become 'P' character

[16:46:00.0000] <Domenic>
hyspace: I haven't looked at this particular instance, but in general the spec operates on mathematical numbers, so there's no wrapping.

[16:47:28.0000] <Domenic>
Thus you end up in the "If the number is greater than 0x10FFFF" state

[16:49:37.0000] <hyspace>
Domenic: In https://html.spec.whatwg.org/multipage/parsing.html#hexadecimal-character-reference-state chapter we do not check range, so when we are in Numeric character reference end state, we will end up using overflowed number

[16:49:55.0000] <Domenic>
hyspace: there is no such thing as an overflowed number, in the spec

[16:50:08.0000] <Domenic>
I understand you might be implementing this in a language that has finite storage, but the spec does not :)

[16:54:59.0000] <hyspace>
Domenic: Thanks


2019-05-20
[02:17:43.0000] <smaug____>
wanderview: FWIW, you might be interested in https://bug1507508.bmoattachments.org/attachment.cgi?id=9065280 Google Maps relies on Chrome janking badly on setTimeout(,0)

[02:57:08.0000] <jochen__>
smaug____: re this promise stuff

[02:57:32.0000] <smaug____>
jochen__: yup

[02:57:33.0000] <jochen__>
smaug____: my main point is that a Promise is an ES object, so no operation can happen on it without a realm

[02:57:42.0000] <smaug____>
jochen__: sure

[02:58:06.0000] <smaug____>
but the spec relies on having a script from which 'muted errors' flag can be read

[02:58:34.0000] <smaug____>
https://html.spec.whatwg.org/#the-hostpromiserejectiontracker-implementation

[02:59:32.0000] <smaug____>
jochen__: and what that 'running script' is in different cases if unclear to me

[03:00:33.0000] <jochen__>
hum

[03:00:43.0000] <jochen__>
as defined in the spec?

[03:00:56.0000] <jochen__>
the realm should have a pointer to a script in ScriptOrModule

[03:01:50.0000] <jochen__>
https://html.spec.whatwg.org/#running-script

[03:03:15.0000] <smaug____>
jochen__: ok, so when https://w3c.github.io/ServiceWorker/#serviceworkercontainer-ready-promise, what is the script?

[03:03:38.0000] <smaug____>
s/, what/is run, what/

[03:04:34.0000] <smaug____>
do we need something in the specs to explicitly forcing Promise creation to happen only when there actually is a script running

[03:07:42.0000] <smaug____>
but then, rejection can anyhow happen when there isn't a script running ,so I'm not sure what 'muted  errors' behavior we want.

[03:28:26.0000] <annevk>
smaug____: should match the script used to create the promise I suppose

[03:28:54.0000] <annevk>
smaug____: but yeah, if the UA creates it…

[03:46:24.0000] <jochen__>
if a spec require a promise to be created without a realm then the spec should be fixed, yes

[03:46:38.0000] <jochen__>
rejection requires a script

[03:46:50.0000] <jochen__>
it's an ES operation, it always requires a realm

[04:51:31.0000] <annevk>
jochen__: it's not so much a realm, it's a script in this case, which has a mute errors flag

[05:05:39.0000] <hsivonen>
annevk: https://bugs.chromium.org/p/chromium/issues/list?can=2&q=getAllResponseHeaders suggests there isn't even a bug on file about sorting XHR headers in Chrome

[05:05:56.0000] <hsivonen>
annevk: how are they passing any test cases?

[05:06:49.0000] <annevk>
hsivonen: they're not passing the relevant getAllResponseHeaders test as I noted?

[05:06:58.0000] <hsivonen>
annevk: ah, ok

[05:07:35.0000] <hsivonen>
out of order IRC and Bugzilla reading for me

[05:07:35.0000] <annevk>
hsivonen: this was quite an old change though so some of the testing and bug filing was likely subpar

[05:07:41.0000] <annevk>
hsivonen: ah

[05:07:55.0000] <annevk>
at least, I think it's old

[05:08:03.0000] <hsivonen>
ok

[05:29:25.0000] <littledan>
I'm trying to trace where in the specs origin checks happen. I can see how it works for method calls from WebIDL, or the special checks for Document and Location, but I'm having trouble finding the checks for ordinary objects. Does anyone know where these are specified?

[05:38:58.0000] <annevk>
littledan: what kind of object are you thinking of?

[05:39:31.0000] <annevk>
littledan: are you specifically asking about infrastructure Fx has that no other browser has?

[05:40:05.0000] <littledan>
no, I think all browsers have this. Or at least V8 has it.

[05:40:11.0000] <littledan>
I'll write a test case, just a minute

[05:41:16.0000] <Ms2ger>
I thought the idea was that it was impossible to get your hands on such an object?

[05:44:21.0000] <annevk>
Ms2ger: khan.gif, alt: Khan screaming DOCUMENT.DOMAIN

[05:44:34.0000] <Ms2ger>
Ha

[05:44:41.0000] <annevk>
euh, Khan isn't the one screaming, but you got it

[05:44:53.0000] <Ms2ger>
For a moment there I managed to forgot about it

[05:45:50.0000] <Ms2ger>
Way to ruin my day :)

[06:39:01.0000] <littledan>
right, I was mistaken; sorry for the noise


2019-05-21
[15:22:34.0000] <smaug____>
https://html.spec.whatwg.org/#posting-messages:posted-message-task-source

[15:22:48.0000] <smaug____>
Queue a task where?

[15:23:40.0000] <smaug____>
source or target (if those aren't similar origin )

[15:24:15.0000] <Domenic>
smaug____: target

[15:24:49.0000] <smaug____>
Domenic: how do you extra that information from the algorithm?

[15:25:05.0000] <Domenic>
smaug____: very few of the steps work if you use source

[15:26:20.0000] <smaug____>
I don't see what

[15:26:40.0000] <smaug____>
in general, when not making too many assumptions on implementations

[15:26:47.0000] <smaug____>
but ok, target

[15:27:30.0000] <Domenic>
Like, how would you get the event to targetWindow if you were in source's event loop

[15:27:44.0000] <Domenic>
I agree this should be stated explicitly, PR welcome.

[15:27:50.0000] <smaug____>
just access it

[15:28:04.0000] <Domenic>
But if you're just asking a question, the answer is target

[15:28:08.0000] <smaug____>
but ok, thanks


2019-05-22
[22:16:42.0000] <TimothyGu>
Domenic: for <virtual-scroller>, is some sort of find-in-page integration no longer being considered?

[06:51:08.0000] <Domenic>
TimothyGu: have you seen the latest readme?

[08:43:09.0000] <innovati>
is it specified in HTML that multiple adjacent whitespace characters collapse into one?

[08:44:34.0000] <innovati>
There's the white-space property in CSS that seems to affect this, is it a CSS-only thing and not related to HTML at all?

[08:45:32.0000] <Ms2ger>
If you can make them appear again with white-space: pre;, they were never collapsed in the first place

[08:47:29.0000] <innovati>
visually, by default they seem to be don't they

[08:47:38.0000] <innovati>
so this is 100% a CSS thing?

[08:50:06.0000] <gsnedders>
yes

[09:06:16.0000] <innovati>
thanks :D

[12:00:05.0000] <TimothyGu>
Domenic: yeah I was just wondering

[12:00:16.0000] <Domenic>
TimothyGu: well, the idea is find-in-page should just work now

[16:14:10.0000] <TimothyGu>
Domenic: ah okay

[16:15:15.0000] <TimothyGu>
I guess I didn't read carefully enough


2019-05-23
[17:46:35.0000] <jwalden>
encoding peoples, what is a nice web encoding I can specify that has the characteristic that some invalid UTF-8 will be valid in that encoding?

[17:47:32.0000] <jwalden>
ideally one that's sort of ASCII-ish, because I need to be able to write a JS script that contains a multi-line comment that contains invalid UTF-8 bytes in it, and I'd rather not learn too much intricacy to do it

[17:51:42.0000] <jwalden>
I guess I don't *really* need that, I can just pick something that doesn't equal ASCII in the 00-7F range, can't I

[17:56:03.0000] <gsnedders>
jwalden: I mean, most of the single byte encodings are valid for any byte sequence

[17:56:08.0000] <gsnedders>
jwalden: e.g. Windows-1252

[17:56:19.0000] <gsnedders>
(i.e., what ISO-8859-1/Latin1 is aliased to)

[17:56:55.0000] <jwalden>
gsnedders: so I think Gecko is not correctly implementing the requirement that worker scripts be only UTF-8 based on code inspection, but for the life of me I can't get it to fail

[17:57:42.0000] <jwalden>
specifically, I think we do the UTF-8 requirement as a "hint charset" that is applied only after BOM sniffing and content charset inspection (fairly sure from the HTTP header)

[17:57:50.0000] <gsnedders>
ISO-2022-JP, UTF-16BE, and UTF-16LE are the non-ASCII encodings supported, FWIW

[17:58:20.0000] <jwalden>
so if I make the worker script contain *mostly* UTF-8 but put a UTF-8 encoding error in a comment, the script's text should be interpreted differently

[17:58:25.0000] <gsnedders>
jwalden: well that sounds fun

[17:59:22.0000] <jwalden>
I swear I'm not even trying to fix this, I'm trying to do something else, but odds are if I push this to bz he's going to say "why are we doing all this extra nonsense when workers are always UTF-8" and hypothetical-bz seems right except practical testing says there isn't a problem and boo

[17:59:39.0000] <jwalden>
(the original "this" being a largely unrelated fix that happens to touch DOM worker code)

[18:00:11.0000] <gsnedders>
jwalden: https://github.com/web-platform-tests/wpt/tree/master/workers/semantics/encodings maybe?

[18:01:03.0000] <gsnedders>
004.worker.js seems to be this

[18:01:21.0000] <jwalden>
we have that test in our tree...

[18:01:22.0000] <gsnedders>
https://wpt.fyi/results/workers/semantics/encodings/004.worker.html has it passing everywhere? (rejecting invalid UTF-8)

[18:01:49.0000] <gsnedders>
oh, wait, you think it's something more subtlely wrong

[18:02:56.0000] <gsnedders>
oh god, these are zcorpan's self-hosting Worker tests

[18:03:04.0000] <jwalden>
gsnedders: if 004.worker.js.headers existed containing "Content-Type: text/html; charset=windows-1252" as its content my code-reading says we should fail it

[18:03:14.0000] <gsnedders>
jwalden: see 001.html/002.html, which do have this

[18:03:16.0000] <jwalden>
assuming .headers support works the intuitive way

[18:04:30.0000] <jwalden>
hrm

[18:04:35.0000] <jwalden>
I don't get it

[18:04:44.0000] <jwalden>
our code looks nuts, but it passes that test

[18:05:30.0000] <jwalden>
oh, that's why

[18:05:40.0000] <gsnedders>
is the expectation wrong?

[18:05:46.0000] <gsnedders>
Firefox is the only one to pass this

[18:05:49.0000] <jwalden>
we pointlessly pass in a field that looks like it means something, but earlier in this function we nulled it out

[18:06:11.0000] <jwalden>
so our code looks stupid but is not, at least in that manner

[18:06:22.0000] <gsnedders>
no, the test is right provided the spec says what you said

[18:07:39.0000] <jwalden>
sorry -- not saying the test is wrong, I'm saying our code does a thing that *looked* like it would lead us astray, but if you look more carefully it is passing in an always-null value and so we end up using the hint charset always

[18:08:57.0000] <gsnedders>
I hadn't read your last comment before my last comment, and I was being paranoid given everywhere but Firefox fails it

[18:10:03.0000] <jwalden>
specifically if you look here https://searchfox.org/mozilla-central/source/dom/workers/ScriptLoader.cpp#1134 we pass in |aLoadInfo.mChannel| which in https://searchfox.org/mozilla-central/source/dom/script/ScriptLoader.cpp#3108 is the second thing tested for picking an encoding...but if you scroll upward to https://searchfox.org/mozilla-central/source/dom/workers/ScriptLoader.cpp#1050 you...

[18:10:04.0000] <jwalden>
...can see |aLoadInfo.mChannel| is definitely null, so either we pick up UTF-8 from the ForBOM test, or we would use the "UTF-8" hint which would get us UTF-8 too

[18:10:47.0000] <jwalden>
there's a reason for this complexity because in the *general* case this function handles so-called classic scripts, but in the worker caller it's pointless

[18:11:13.0000] <jwalden>
but there certainly is no reason the worker code should be passing in a field that is always null, rather than passing nullptr directly

[18:11:43.0000] <jwalden>
"this has been another scintillating episode of Gecko Guts with jwalden"

[18:12:29.0000] <gsnedders>
who doesn't love browser code?

[18:12:52.0000] <gsnedders>
/me tries to remember what they were looking at before getting nerd sniped into this much more interesting drama

[18:14:46.0000] <jwalden>
I got into all this by wanting to have a ScriptLoader::ConvertToUTF8, and there's enough noisy in the ConvertToUTF16 algorithm I could either template that up so both algorithms could be defined by one template function (...and some helpers), or I could define them separately with some algorithmic duplication possibly undesirably

[18:15:01.0000] <jwalden>
for workers, simplifying the algorithm would probably be the right thing to do

[18:15:26.0000] <jwalden>
except this ConvertToUTF8 may end up used outside workers, so I guess I don't know whether duplication or not is proper yet

[18:23:10.0000] <jwalden>
https://paste.rs/poQ.sh for anyone who wants to see what my testcase looks like (loaded in a server where ^headers^ is like the .headers thing in the wpt tests, looks like) -- should see replacement-characters, Firefox displays them, other browsers display &yuml;

[03:07:11.0000] <annevk>
hah, workers/semantics/encodings/001.html is fun

[03:07:32.0000] <annevk>
A similar one with <script> and Worker loading the same thing might lead to surprises too


2019-05-24
[06:18:34.0000] <dtapuska>
annevk: How is the origin on a document generally assigned? I see it only as through document construction, in https://html.spec.whatwg.org/multipage/browsers.html#creating-browsing-contexts. I'm trying to match the spec to Chromium's code. When we create a document we already know the origin and I was trying to enforce that.  I think the problem stems from the fact that Chromium doesn't follow..

[06:18:34.0000] <dtapuska>
https://html.spec.whatwg.org/multipage/browsing-the-web.html#read-html  and a new document object is created with the origin when a page is loaded so we go into that.    So how is the origin set correctly when using https://html.spec.whatwg.org/multipage/browsing-the-web.html#read-html ?

[06:20:15.0000] <annevk>
dtapuska: the whole document creation process is defined very poorly

[06:21:08.0000] <annevk>
dtapuska: origin is therefore defined with action-at-a-distance: https://html.spec.whatwg.org/#origin:document-2

[06:23:04.0000] <dtapuska>
annevk: We can't define it in that fashion for agent.. because an agent shouldn't change as the page loads... ie; the agent needs to be fixed at document creation.. So fundamentally we need to adjust the navigation algorithms to force a load of the document with the origin predetermined.

[06:23:36.0000] <dtapuska>
My process was... determine the origin of the document, create the agent associated, create the execution context, create the document

[06:24:19.0000] <dtapuska>
determining the origin of the document requires us to determine the sandbox flags first.. as well, but I think that makes it clear how you want feature policy sandbox flags to work

[06:24:24.0000] <annevk>
dtapuska: a document's origin shouldn't change either, but yes, agreed

[06:25:37.0000] <dtapuska>
I do need to remove that other section about determining if two windows are the same agent.. basically it should be if the realm's execution content's agent is the same then they are the same..

[06:25:44.0000] <annevk>
(I'm also not trying to hold this up as an example of good design; my goal is that eventually we have "create a document" that takes various parameters)

[06:26:38.0000] <annevk>
(I guess I'm trying to say, please don't take inspiration from this setup)

[06:26:47.0000] <dtapuska>
I agree.. I think my latest patch is far better than the last attempt..  Are you really confused by it? I thought it was clearer.

[06:28:03.0000] <annevk>
dtapuska: I am, as I don't quite see how it works when you navigate an existing browsing context

[06:28:32.0000] <annevk>
dtapuska: at that point you might end up in a different agent cluster, but how that works if determining an origin only really works for popups is not very clear to me

[06:31:22.0000] <annevk>
dtapuska: one other nit, you should make "obtain a" part of the <dfn> in various places

[06:32:20.0000] <dtapuska>
Yes so that is certainly broken. Do we have a response in these pieces of code: https://html.spec.whatwg.org/multipage/browsing-the-web.html#read-html

[06:32:39.0000] <dtapuska>
Because "create a Document" really should be passing in the origin.

[06:33:26.0000] <annevk>
It's called from code that has a response and can do the right thing

[06:33:33.0000] <annevk>
Untangling it however is another matter

[06:35:13.0000] <dtapuska>
ie; can we change https://html.spec.whatwg.org/multipage/browsers.html#creating-a-new-browsing-context to also take an optional resource origin?  And change those spots to pass a resource origin?

[06:35:21.0000] <annevk>
It's on my list of things to do, but email/GitHub/admin/review ends up taking so much time I never really get to it

[06:35:46.0000] <annevk>
dtapuska: creating a browsing context isn't really the complicated piece

[06:36:18.0000] <annevk>
dtapuska: that already has an origin (opaque) or its creator origin (whatever its value)

[06:36:28.0000] <annevk>
dtapuska: that covers about:blank

[06:36:38.0000] <annevk>
dtapuska: then there's navigation

[06:36:53.0000] <annevk>
dtapuska: that keeps the browsing context around, but changes what is displayed

[06:37:02.0000] <annevk>
dtapuska: that's where things get hairy

[06:38:33.0000] <annevk>
(and it might also not be that complicated since in the abstract it's not, but the way the spec is written just ...)

[06:51:04.0000] <dtapuska>
I guess I'm confused why:  "the user agent must queue a task to create a Document object, mark it as being an HTML document, set its content type to "text/html", initialize the Document object"..  Could we define new steps for "initialize a browsing context with a new document" ? ie; the separate "create a Document" and "initialize the document object" create this issue that the origin is not defined on document creation.

[06:51:36.0000] <dtapuska>
or that it transitions from oqaque origin -> actual origin

[06:51:43.0000] <dtapuska>
which creates issues for defining the agent cluster

[06:53:25.0000] <annevk>
That, and the fact that we create the document before we create the global it's created in

[06:55:37.0000] <annevk>
dtapuska: so the actual change to the browsing context happens later

[06:55:57.0000] <annevk>
dtapuska: there's two callers of "set the active document"

[06:56:30.0000] <annevk>
dtapuska: one is during browsing context creation and the other is in history traversal, which is what navigate bottoms out to

[07:19:50.0000] <dtapuska>
Ok; so perhaps "initialize a browsing context with a new document" is a poor name, it could be simply "create a document and execution context" algorithm... does that approach make sense?

[07:34:23.0000] <annevk>
dtapuska: ah yeah, I see what you mean, something like that would make sense


2019-05-27
[07:57:35.0000] <dtapuska>
annevk: I've pushed a change where it adjusted the "initialize document" to a "create and initialize" document on https://github.com/whatwg/html/pull/4617

[08:27:37.0000] <annevk>
dtapuska: btw, it'd greatly appreciate if you could instead push fixup commits

[08:28:20.0000] <annevk>
dtapuska: we can squash using GitHub tooling in the end, but meanwhile fixup commits help a lot with understanding the delta between whatever I looked at last time around

[08:29:29.0000] <dtapuska>
annevk: do you want me to force push a commit that has since last time you reviewed then?

[08:29:35.0000] <dtapuska>
I should have the history locally

[08:33:23.0000] <annevk>
dtapuska: yeah, that would be nice

[08:34:00.0000] <annevk>
dtapuska: skimming through it it seems quite a lot changed, not sure if I can get to this today

[08:34:48.0000] <annevk>
dtapuska: one thing I noticed is that "determine an origin" now makes reference to the navigate algorithm, which seems a lot less clean

[08:35:11.0000] <dtapuska>
annevk: I agree. that is the one part I struggled with

[08:35:31.0000] <dtapuska>
I was trying to take all the cases of where a document origin is magically specified

[08:35:53.0000] <dtapuska>
and make them formally specified.. and I ended up copying some text from the definition of "origin"

[08:36:34.0000] <dtapuska>
but I have no idea if I'm wasting my time on this or not

[08:36:40.0000] <annevk>
dtapuska: I don't know how much work it is for you to split things, but perhaps navigate giving more context to the various "create and initialize a document" algorithms could be done separately

[08:37:05.0000] <annevk>
dtapuska: something like that needs to be done either way and it'd be easier to review apart from also changing the way we do agents

[08:37:48.0000] <annevk>
dtapuska: yeah understood, that's always how I feel when trying to refactor this mess as well

[08:37:54.0000] <annevk>
dtapuska: not sure if that helps

[08:38:33.0000] <dtapuska>
Ok I can likely pull the refactoring of navigation apart into a separate pull request first.. cause agent clusters doesn't need to be in there for that

[08:39:10.0000] <annevk>
thanks!

[08:39:12.0000] <dtapuska>
I start a separate PR for that now then (instead of doing the forced push with the history)

[08:39:20.0000] <annevk>
sg

[08:39:55.0000] <annevk>
Hopefully Domenic has some cycles as well to look at this as he's closer to your timezone, though maybe he'll be in Europe soon for JSConf (this weekend)

[08:40:05.0000] <annevk>
and TC39 is meeting next week I think...

[08:40:12.0000] <dtapuska>
today is a holiday in US

[08:40:18.0000] <dtapuska>
(not canada)

[08:40:21.0000] <annevk>
ah yeah, there's that too

[08:57:18.0000] <dtapuska>
annevk: https://github.com/whatwg/html/pull/4664

[16:45:57.0000] <GPHemsley>
there is a lot of talk about HTML doing things here, but I have yet to see anyone responsible for HTML in the discussion: https://github.com/w3c/rdf-dir-literal/issues/3

[16:46:18.0000] <GPHemsley>
s/HTML doing things/making changes to HTML/

[16:49:34.0000] <GPHemsley>
(this may also be of interest to people involved in i18n and L10n)

[16:51:41.0000] <GPHemsley>
other keywords: language tags, text direction, Unicode

[16:53:17.0000] <GPHemsley>
RDF, JSON-LD


2019-05-28
[23:29:34.0000] <jochen__>
annevk: re script vs realm - my understanding of how ES is embedded in HTML is that every realm has a script or module

[23:48:03.0000] <annevk>
jochen__: that is probably true; with n:m

[23:49:22.0000] <annevk>
jochen__: I think the problem is that promises are not always allocated with the appropriate context? If I can guess what this is about without context

[23:53:06.0000] <jochen__>
the question from smaug about host promise resolver thing

[23:53:30.0000] <jochen__>
where to get the mute error flag from

[23:53:36.0000] <jochen__>
the spec says "from the script of the context"

[23:53:50.0000] <jochen__>
which I claim is always defined (module implementation bugs)

[00:04:08.0000] <annevk>
If the current script is passed across the IDL boundary so it can use that to create promises, right?

[00:04:22.0000] <annevk>
Not sure how it is without that

[00:16:19.0000] <jochen__>
passing the IDL boundary doesn't change the ES execution context stack

[00:34:12.0000] <annevk>
jochen__: if that stack is global and that is what Chrome uses when a spec algorithm creates a promise that might be good

[00:48:19.0000] <jochen__>
i mean, what else would you do?

[00:48:45.0000] <jochen__>
a promise is an ES object, so it needs to be constructed via a call to its constructor which is part of a realm

[00:49:15.0000] <jochen__>
in any implementation it should be impossible to construct a promise without a realm

[00:51:42.0000] <annevk>
jochen__: I'm guessing Gecko has some C++ equivalent, as most implementations do for non-promise objects. And for those implementations do often vary on what realm is used.

[00:52:19.0000] <jochen__>
ok, that's possible

[00:52:38.0000] <jochen__>
the spec however only knows one kind of promise

[00:54:53.0000] <annevk>
In theory it only knows one kind of document, yet it creates one before a global exist

[00:55:06.0000] <annevk>
Anyway, all I'm saying is that there's plenty of opportunity for confusion here

[00:55:48.0000] <jochen__>
yep :/

[00:56:01.0000] <annevk>
And if there's indeed a simple stack to look at for creating promises we should clarify that in the issue and hopefully eventually promise creation will be explicit enough that it's also clear there

[00:57:58.0000] <jochen__>
https://tc39.github.io/ecma262/#execution-context-stack

[00:59:05.0000] <annevk>
jochen__: ooh also, reading https://github.com/whatwg/html/issues/4637 about the lazy allocation that does seem very weird

[01:01:14.0000] <jochen__>
well, that's blink's code being funky

[01:01:17.0000] <jochen__>
don't blame me for it

[01:01:26.0000] <jochen__>
the spec is clear, it says it wants "a new promise" https://www.w3.org/2001/tag/doc/promises-guide/#a-new-promise

[01:01:54.0000] <jochen__>
(should whatwg html link to this in all the algorithms that mention "let p be a new promise"?)

[01:07:05.0000] <Ms2ger>
fwiw, there's a long term plan to merge that into IDL: https://github.com/heycam/webidl/issues/490

[01:07:41.0000] <jochen__>
ah, cool

[01:12:21.0000] <annevk>
yeah, it should be merged

[01:12:49.0000] <annevk>
I mean, lazy allocation + cache is probably okay, as long as we add a test for it

[06:38:48.0000] <roelal>
Hi there. Could any "autoconfirmed user" add a user account for me (roel.arents⊙le) on wiki.whatwg.org? Because I'd like to propose "application-version" as a Meta Name Extension.

[06:52:44.0000] <annevk>
roelal: username?

[06:56:29.0000] <roelal>
roelal is my preferred username for the wiki

[06:57:06.0000] <annevk>
roelal: you'll get an email

[06:58:09.0000] <roelal>
received it, thx!

[07:54:18.0000] <Domenic>
jochen__: annevk my guess is that Blink/V8 associate promises with realms, and use that to figure out the muted error checks. Whereas the error reporting parts of the spec use "the current script", instead of "the promise's realm". Probably the spec should be more like the Blink/V8 model since it's more straightforward and well-defined at all times. But then we get into the issue where we have the same problem for sync errors,

[07:54:18.0000] <Domenic>
and that's a whole big mess...

[07:58:28.0000] <annevk>
yeah, the lazy getting is also weird, but if defined I guess I don't mind it so much

[13:58:02.0000] <gsnedders>
is it intended that given s' = URL serializer(URL parser(s)), s' will parse without validation errors?

[15:23:43.0000] <TimothyGu>
Domenic: https://bugzilla.mozilla.org/show_bug.cgi?id=1554014 :(

[15:30:06.0000] <Domenic>
Waugh


2019-05-29
[00:27:28.0000] <annevk>
littledan: I'm not entirely following https://github.com/whatwg/html/pull/4352#issuecomment-496498523

[00:27:46.0000] <annevk>
littledan: as I see it service workers relies on some functionality in HTML today

[00:28:10.0000] <annevk>
littledan: if you change that functionality as per the PR, service workers either ends up broken or we change things for them they are not comfortable with

[00:28:19.0000] <annevk>
littledan: is that an incorrect understanding of the situation?

[00:28:29.0000] <littledan>
Annevk, it seems like they are uncomfortable with the feature overall

[00:28:40.0000] <annevk>
littledan: sure

[00:29:01.0000] <littledan>
Yes, I agree this can't land without the plumbing change on their side. I will write that change after this TC39 meeting if it gets to Stage 3

[00:29:06.0000] <annevk>
littledan: but either way, given that they directly plug into an HTML algorithm, it seems we need to take their needs into account somehow

[00:29:38.0000] <annevk>
littledan: that is, we care quite strongly about preserving downstream "invariants"

[00:29:59.0000] <littledan>
Yes, so, right now, the JS spec doesn't cleanly expose whether you encountered a TLA. The API is Promise-based. And now SW is asking to stick with a sync API

[00:30:39.0000] <littledan>
The JS spec API was based on Domenic's suggestion that I mentioned upthread, and I agree with the advice

[00:30:56.0000] <littledan>
So, I am not sure where to go from here

[00:31:31.0000] <littledan>
I would prefer to just say, "too bad SW, you have TLA anyway" but I don't know enough about that world to do so

[00:31:32.0000] <annevk>
This reminds of me of audio worklets rather not having all kinds of new JS APIs either

[00:31:48.0000] <littledan>
Hmm good analogy

[00:32:03.0000] <annevk>
I suspect they wouldn't want some of this either necessarily

[00:32:28.0000] <annevk>
Audio worklets probably only wants some flavor of wasm, really

[00:33:00.0000] <littledan>
Maybe they want to disable the Wasm instruction for Atomics.wait as well!

[00:33:14.0000] <annevk>
I'm surprised this doesn't come up from those embedding JS into microcontrollers and such

[00:33:19.0000] <littledan>
Or the instruction to grow memory

[00:34:05.0000] <annevk>
I hope Wasm's Atomics.wait pays attention to the Agent record, though of course none of that is properly layered

[00:34:20.0000] <littledan>
Well, we can go to TC53 and ask them, I suppose. We can start with rwaldron and Moddable at TC39. I don't know that world well.

[00:35:11.0000] <annevk>
It seems weird that browsers would be the first to raise the concern of the minimal JavaScript runtime being too big or having features that are incompatible with certain code architectures

[00:42:54.0000] <littledan>
Well, when embedded people come to TC39 historically, they used to ask for even more minimalism than this, leaving out some language features for simplicity and size. I think neither TC39 nor web standards are sympathetic to the idea of creating embedded profiles. There are lots of partial implementations of the web platform that just aren't seen as that interesting for standards (and I can't think of a better way to handle

[00:42:55.0000] <littledan>
it).

[00:46:19.0000] <annevk>
littledan: I see, yeah, profiles end up failing (see all the (X)HTML profiles back in the day). Hmm...

[00:46:29.0000] <littledan>
Step 6 of Atomics.wait checks the https://tc39.github.io/ecma262/#sec-atomics.wait , reading [[CanBlock]] from the "agent record", whereas HTML sets [[CanBlock]] in the "agent". It almost matches! https://html.spec.whatwg.org/#integration-with-the-javascript-agent-formalism

[00:48:01.0000] <littledan>
So it makes sense that restricted profiles start from the browser end, where it's about giving the capability to do work for the first time and getting interop there, rather than server or embedded use cases, where the motivation for using standards is more like compatibility with the web (which doesn't have the restrictions)

[00:48:21.0000] <annevk>
littledan: yeah, I guess I'll wait until agents are refactored to also account for Wasm

[00:48:40.0000] <littledan>
Anyway now that we got here maybe we should go back and ask them what they need

[00:48:42.0000] <annevk>
littledan: it's also not really clear to me the agent <> agent record <> agent signifier separation is worth it

[00:49:07.0000] <littledan>
Yeah I don't understand either. I will talk with Shu to understand better

[00:49:57.0000] <annevk>
Shu's reasoning seemed to be that you can only pass integers between agents or some such, but then if that were true it would mean that the whole structured serializing and deserializing specification is broken

[00:50:35.0000] <annevk>
So it seems better to accept the fact that there's need for sharing records across agents and at that point you might as well reconcile them all and make agent a record

[00:51:32.0000] <littledan>
Well, this is my intuition as well. I am not sure where the requirements on notation come from.  I don't think we should adopt this notation in structured serialization.

[00:51:46.0000] <TimothyGu>
in general ES seems to like having some actual thing and something Record

[00:52:16.0000] <TimothyGu>
like the properties of a realm are captured in a Realm Record, but a Realm Record isn't really a realm, which is an abstract thing

[00:53:08.0000] <littledan>
TimothyGu: What do you make of the agent signifier?

[00:54:16.0000] <TimothyGu>
littledan: I feel like that's an unfortunate consequence of the fact that ES has this distinction between the thing and the Record

[00:54:35.0000] <TimothyGu>
I also don't think this impacts Structured Serialization/Deserialization in anyway

[00:55:01.0000] <TimothyGu>
because for that, the records are the only thing being transferred – there's no underlying entity like a realm or an agent

[00:56:36.0000] <annevk>
Interesting observation, maybe the problem is the abstract thing indeed

[01:28:15.0000] <littledan>
oh yeah, I guess this is based on the idea that only objects have internal slots, whereas records have fields, and other things don't use this notation (though I guess we softened on this for Symbol's [[Description]]?). The . notation was initially pretty restricted, and then later generalized

[01:58:43.0000] <gsnedders>
annevk: is it intended that given s' = URL serializer(URL parser(s)), s' will parse without validation errors? (I note for example most but not all non-URL code points are percent encoded in the query state.)

[02:34:35.0000] <annevk>
gsnedders: I don't think so

[02:35:12.0000] <annevk>
gsnedders: e.g., https://example.com/% should not change afaik

[03:43:41.0000] <gsnedders>
https://wiki.whatwg.org/wiki/DOM_XPath — should we create some spec for this somewhere?

[03:43:58.0000] <gsnedders>
or put it in a PR for DOM, that will probably hang around for ages because nobody will actually work on it? :/

[03:44:51.0000] <gsnedders>
But it seems kinda bad having the actual IDL people are implementing only on the wiki

[04:10:31.0000] <annevk>
gsnedders: DOM is the place and someone doing the work is the problem

[04:11:01.0000] <annevk>
gsnedders: a good next step might be to write up an issue with the TODO list for this

[04:12:20.0000] <gsnedders>
hah, https://github.com/whatwg/dom/issues/67

[04:12:31.0000] <gsnedders>
that's… a while ago

[04:14:17.0000] <annevk>
meh, "16:24, 12 September 2011‎ Annevk (talk | contribs | block)‎ . . (538 bytes) (+538)‎ . . (notes for a future XPath spec)"

[04:15:11.0000] <annevk>
And even that doesn't seem that long ago 😛

[04:39:06.0000] <gsnedders>
It's super annoying having WebIDL that's not covered by any of the auto-extraction tools though. Dunno. :/

[05:08:11.0000] <annevk>
gsnedders: I could see making a policy exception if we also add the appropriate XXX block

[05:08:40.0000] <annevk>
gsnedders: in particular as having the IDL shared and in WPT is better than not having that indeed

[05:08:54.0000] <annevk>
gsnedders: would you be willing to drive that?

[05:17:38.0000] <gsnedders>
Yeah, it seems a bit different given it's one of the few interfaces we have that isn't actually in a spec yet is implemented everywhere.

[05:17:48.0000] <gsnedders>
annevk: bit marginal as to whether it's in scope for what I'm paid to do, though :/

[05:19:11.0000] <annevk>
maybe foolip can take it on

[05:20:19.0000] <foolip>
annevk: is it xpath IDL you'd like to have tested?

[05:20:47.0000] <gsnedders>
foolip: we have them tested, but having them somewhere where they're found by automatic tools would be good

[05:21:12.0000] <foolip>
gsnedders: interfaces/xpath.idl doesn't exist though

[05:21:15.0000] <annevk>
foolip: the idea is to take the DOM XPath wiki page and put it in the DOM Standard with a policy exception for detailed processing model and testing due to it already existing and have a XXX block explaining that situation

[05:21:40.0000] <annevk>
foolip: this would a) make it clearer DOM XPath is in fact a (problematic) part of the platform and b) help with getting some test coverage in WPT

[05:21:49.0000] <foolip>
annevk: putting it in a spec would be good, then it'd be picked up by reffy-reports as wel

[05:21:56.0000] <annevk>
right

[05:22:26.0000] <annevk>
foolip: and I was volunteering gsnedders / you to do it 😊

[05:22:45.0000] <foolip>
annevk: aha :) alright, I'll spend 15 minutes and see what happens

[05:26:36.0000] <gsnedders>
foolip: yeah, getting it picked up by reffy-reports is basically the motivating factor, because then we keep the "spec" and WPT in sync, and tools that compare impls' IDL to the spec also get it

[05:26:51.0000] <gsnedders>
foolip: given I don't think anything is going to start crawling the current "spec" we have of WebXPath :)

[05:27:25.0000] <foolip>
gsnedders: no, I don't think setting that up would be time well spent :)

[06:14:32.0000] <foolip>
annevk: https://github.com/whatwg/dom/pull/763

[06:15:00.0000] <foolip>
Seems like I spent 52 minutes :)

[06:24:54.0000] <annevk>
foolip: thanks, it might take a while before I get to this, hope that's not a problem

[06:25:31.0000] <foolip>
annevk: I can't imagine much bad stuff happening because of XPath maintenance falling behind a bit :D

[06:45:27.0000] <gsnedders>
foolip: https://github.com/web-platform-tests/wpt/pull/17060 is what prompted this, FWIW; you up for reviewing interface/dedicated-worker.idl?

[07:30:40.0000] <innovati>
It this new Memorandum of Understanding big news?

[07:33:15.0000] <innovati>
if I understand this correctly, this means the W3C-published text will now be the WHATWG text verbatim?

[07:38:16.0000] <dtapuska>
annevk: Any thoughts on my latest changes: https://github.com/whatwg/html/pull/4664  were you waiting on @Domenic?

[07:46:47.0000] <Domenic>
innovati: no, there will be no W3C-published text, just 302 redirects to whatwg.org

[07:47:11.0000] <innovati>
🥰 that's the most beautiful thing I've ever heard

[07:47:58.0000] <innovati>
congrats on making progress!

[09:01:59.0000] <foolip>
gsnedders: done

[09:55:00.0000] <annevk>
dtapuska: I didn't get to it today and won't until Monday at the earliest

[09:55:29.0000] <annevk>
dtapuska: if Domenic could do a pass that'd be good and maybe Domenic remembers the other person from Chrome looking at navigation, they might have good insights as well

[10:28:49.0000] <Domenic>
I can give a try, still kind of drowning in post long weekend + being sick backlog


2019-05-30
[10:19:43.0000] <jugglinmike>
Is there a normative definition for "form control"?

[10:20:01.0000] <jugglinmike>
I'm looking through 4.10 but haven't come across it yet https://html.spec.whatwg.org/multipage/forms.html#forms

[10:20:29.0000] <jugglinmike>
In particular, I'm curious if `<meter>` is a form control

[10:33:24.0000] <MikeSmith>
jugglinmike: there is not

[10:33:32.0000] <MikeSmith>
but I guess there rightly should be

[10:34:00.0000] <MikeSmith>
the closest is “labelable element”

[10:34:04.0000] <MikeSmith>
https://html.spec.whatwg.org/multipage/forms.html#category-label

[10:34:17.0000] <jugglinmike>
I initially assumed there to be some notion of "input", which tended to disqualify elements like "progress" and "meter"

[10:34:47.0000] <jugglinmike>
but a more accurate interpretation is probably more like, "controls the data which is submitted"

[10:35:14.0000] <jugglinmike>
Since that would more logically include "meter"

[10:35:26.0000] <MikeSmith>
right

[10:36:37.0000] <jugglinmike>
so maybe a form control is "a labelable element or a hidden input"

[10:36:57.0000] <MikeSmith>
well <output> does not fit

[10:36:59.0000] <MikeSmith>
right?

[10:37:08.0000] <MikeSmith>
<output> is not a form control

[10:37:36.0000] <jugglinmike>
In the sense of "controls the data which is submitted"?

[10:37:47.0000] <MikeSmith>
yeah in that sense

[10:37:50.0000] <MikeSmith>
btw there is also “form-associated elements”

[10:37:54.0000] <jugglinmike>
I don't know :)

[10:37:58.0000] <MikeSmith>
https://html.spec.whatwg.org/multipage/forms.html#form-associated-element

[10:37:59.0000] <jugglinmike>
yeah, I'm looking at those, too

[10:38:44.0000] <jugglinmike>
It might not be useful to define "form control" in terms of "labelable element"

[10:39:32.0000] <MikeSmith>
right

[10:39:51.0000] <MikeSmith>
I think we really need to define “form control”

[10:40:25.0000] <MikeSmith>
but then it’s still not clear if <meter> is a “form control”

[10:42:00.0000] <jugglinmike>
I'll file an issue

[10:44:39.0000] <MikeSmith>
jugglinmike: thanks yeah please

[10:44:43.0000] <MikeSmith>
btw https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#mutability

[10:44:54.0000] <MikeSmith>
> A form control can be designated as mutable.

[10:45:26.0000] <MikeSmith>
so I guess implicitly, if soemthing cannot be designated as mutable, then it is not a form control

[10:45:50.0000] <jugglinmike>
there's also https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attributes-common-to-form-controls

[10:46:32.0000] <MikeSmith>
ah yeah

[10:47:41.0000] <MikeSmith>
https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#a-form-control's-value too

[10:47:54.0000] <MikeSmith>
> Most form controls have a value and a checkedness.

[10:49:06.0000] <jugglinmike>
Not the most satisfying definition :P

[10:49:09.0000] <MikeSmith>
but anyway, yeah, https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attributes-common-to-form-controls seems to already normatively constrain “form control” to a specific set of element

[10:50:21.0000] <MikeSmith>
jugglinmike: tehre is probably a motto lurking there

[10:50:41.0000] <MikeSmith>
We Aim for Precision, Not Satisfaction

[10:51:04.0000] <MikeSmith>
well, though in this case we don’t even yet have precision

[10:53:09.0000] <jugglinmike>
That's okay, we only aim for it

[10:59:33.0000] <MikeSmith>
heh

[10:59:58.0000] <MikeSmith>
new motto: We Fail Sometimes

[11:00:21.0000] <MikeSmith>
or maybe that could be even more concise:

[11:00:24.0000] <MikeSmith>
We Fail

[11:04:05.0000] <jugglinmike>
haha

[11:04:08.0000] <jugglinmike>
I like it

[11:04:29.0000] <jugglinmike>
So nothing is a form control

[11:04:33.0000] <jugglinmike>
according to Firefox and Chrome

[11:08:26.0000] <MikeSmith>
We Fail Interoperably

[11:12:03.0000] <jugglinmike>
Well I'm probably wrong

[11:12:40.0000] <jugglinmike>
MikeSmith: I guess part of the problem is that our working definition is based on a non-observable trait

[11:13:05.0000] <jugglinmike>
for instance, no element has a `maxlength` property

[11:13:18.0000] <MikeSmith>
oh

[11:13:31.0000] <jugglinmike>
many expose that attribute through `maxLength`

[11:13:39.0000] <MikeSmith>
ah

[11:13:56.0000] <jugglinmike>
but "has `maxLength`" isn't the same as "has maxlength"

[11:17:31.0000] <jugglinmike>
MikeSmith: "Form submission" might be misplaced

[11:17:40.0000] <MikeSmith>
misplaced?

[11:17:57.0000] <jugglinmike>
since it describes "Attributes for form submission can be specified both on form elements   and on submit buttons "

[11:18:19.0000] <jugglinmike>
i.e. not "Attributes for form submission can be specified both on form elements   and on submit buttons "

[11:18:26.0000] <jugglinmike>
pardon me

[11:18:37.0000] <jugglinmike>
I mean,  not "Attributes common to form controls"

[11:21:51.0000] <jugglinmike>
oh, how about this https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#control's-data

[11:22:32.0000] <jugglinmike>
That implies a complete list of "kind of control"

[11:22:45.0000] <jugglinmike>
input, textarea, select

[11:23:22.0000] <jugglinmike>
so, not progress or meter or input

[11:23:28.0000] <jugglinmike>
but not button, either...

[11:24:04.0000] <jugglinmike>
correction: "so, not progress or meter or **output**"

[11:39:59.0000] <jugglinmike>
MikeSmith: another candidate: "submitable elements" https://html.spec.whatwg.org/multipage/forms.html#category-submit

[11:40:46.0000] <MikeSmith>
jugglinmike: embarrassment of riches

[11:42:26.0000] <jugglinmike>
That's probably closest to our earlier definition of  "controls the data which is submitted"

[11:42:43.0000] <jugglinmike>
but once again does not include meter

[11:44:46.0000] <Domenic>
What does having a formal definition of "form control" impact?

[11:45:05.0000] <Domenic>
The actual element categories should be used for any normative text.

[11:48:39.0000] <jugglinmike>
Domenic: css-ui, at least

[11:48:53.0000] <Domenic>
They should use the actual element categories :)

[11:49:02.0000] <jugglinmike>
yeah, that makes sense, too

[11:49:33.0000] <jugglinmike>
But do you think there's any value in formally defining the term "form control"?

[11:49:40.0000] <jugglinmike>
Since HTML uses it frequently

[11:51:03.0000] <Domenic>
Not particularly; I think more discrete categories are more useful. If any uses of "form control" cause confusion for either implementers or readers we should replace them with one of the categories.

[11:52:25.0000] <jugglinmike>
How about "4.10.18 Attributes common to form controls"

[11:52:57.0000] <jugglinmike>
working backwards from there, "form controls" are only input and textarea elements

[11:54:02.0000] <Domenic>
If it's unclear to what elements those attributes apply, then yeah, we should be more precise (by using one of the named categories)

[11:54:55.0000] <jugglinmike>
It might be best to just name it "Common attributes"

[11:55:15.0000] <Domenic>
I mean, they're not common to div.

[11:55:48.0000] <jugglinmike>
that is true, but the context might be sufficient to communicate the limited scope

[11:56:07.0000] <Domenic>
Well, I'm doubtful that would reduce confusion instead of increasing it. But, I GTG for now :)

[11:56:11.0000] <jugglinmike>
because the sub-section "Form submission" clearly describes "form elements and [...] submit buttons"

[11:56:34.0000] <jugglinmike>
got it; thanks for the input

[11:57:17.0000] <jugglinmike>
I could have avoided that pun but I chose not to

[14:42:43.0000] <jugglinmike>
botie: tell MikeSmith https://github.com/w3c/csswg-drafts/issues/3990

[14:42:43.0000] <botie>
will do

[16:29:21.0000] <MikeSmith>
jugglinmike: heya

[16:29:21.0000] <botie>
MikeSmith, at 2019-05-30 21:42 UTC, jugglinmike said: https://github.com/w3c/csswg-drafts/issues/3990

[16:29:30.0000] <MikeSmith>
/me looks at https://github.com/w3c/csswg-drafts/issues/3990

[16:30:11.0000] <MikeSmith>
/me adds thumbs up

[16:31:14.0000] <jugglinmike>
:)

[16:32:12.0000] <jugglinmike>
Good question from Brian about `<details>`


2019-05-31
[04:29:04.0000] <MikeSmith>
botie, inform zcorpan when you have some time, I wanted to ask you about <picture> test cases

[04:29:04.0000] <botie>
will do

[07:14:17.0000] <JakeA>
If I want to return an interface like { foo, bar } where foo & bar are readonly arrays of strings, what type should I use? FrozenArray? Array? https://heycam.github.io/webidl/#idl-sequence says I shouldn't use a sequence.

[07:16:04.0000] <JakeA>
To make the example real: the object is a user contact, and the properties are `email` and `tel`, but a user can have many emails and tel numbers

[07:16:32.0000] <jenny-m>
pretty sure FrozenArray is the answer

[07:19:51.0000] <JakeA>
jenny-m: https://html.spec.whatwg.org/multipage/comms.html#messageevent uses `FrozenArray` for `ports`, so that confirms it I think. Ta!

[10:43:15.0000] <TabAtkins>
JakeA: If you're *returning* a value like that, you can use `sequence<>` (and probably should).

[10:43:25.0000] <TabAtkins>
You just can't use sequence for an attribute.

[10:44:08.0000] <JakeA>
TabAtkins: it'd be returning an object that has arrays as properties

[10:44:25.0000] <TabAtkins>
An object as in an interface, or a record?

[10:44:50.0000] <JakeA>
Hmm, I'd need to look up the difference

[10:45:08.0000] <TabAtkins>
Did you type it out as `interface Foo {...}`?

[10:45:23.0000] <TabAtkins>
(or a dictionary)

[10:46:08.0000] <JakeA>
I recommended interface, but that can change

[10:47:00.0000] <JakeA>
I don't think I'd use dictionary/record unless the keys were potentially different each time. Wdyt?

[10:47:44.0000] <JakeA>
Eg, `JSON.parse` would return a dictionary/record in idl land

[10:48:23.0000] <JakeA>
But if I was always returning a thing that had keys "email" and "tel", that feels like an interface

[10:56:11.0000] <TabAtkins>
Usually interface is the right thing yeah, but sometimes, if you're just returning some raw information, a plain-ol-JS-object (aka a dictionary or record) is appropriate. Are there methods on the thing?

[10:56:24.0000] <TabAtkins>
(Dictionaries always have the same keys too, that's not a differentiator from interfaces.()

[10:56:27.0000] <TabAtkins>
)

[11:03:34.0000] <Mek>
and records have the same type for all their values, so probably wouldn't be what JSON.parse returns either. It probably would just return a plain `object` in IDL land...

[11:04:17.0000] <JakeA>
No methods on it. Hmm, can't decide.

[11:05:30.0000] <Mek>
I think I would just return a dictionary in that case? Presumably it's not live-updating attributes, but returning a snapshot of state when the object was created?

[11:06:47.0000] <JakeA>
Yeah, it's just a snapshot

[11:13:42.0000] <JakeA>
Yeah, I'll go with a dictionary then

[11:17:42.0000] <TabAtkins>
Yeah, dict is appropriate if it's just a snapshot of some state with no methods on it. (And no plans to add methods in the future.)

[11:17:49.0000] <JakeA>
When I create a instance of an IDL type, when is the equivalent platform object created? Is the platform object 1:1 with the IDL type instance?

[11:18:11.0000] <TabAtkins>
(Later upgrading a dictionary to an interface is possible, but technically has behavior differences that might be exercised. They're very minor tho.)

[11:18:16.0000] <TabAtkins>
Yes, 1:1.

[11:18:25.0000] <JakeA>
Good, phew

[11:18:56.0000] <TabAtkins>
Your internal algorithms should be operating on IDL or Infra values, and just assume that they *are* the platform objects.

[11:19:28.0000] <JakeA>
I don't think we should assume infra values are platform objects

[11:19:41.0000] <JakeA>
They might live entirely "in parallel"

[11:19:54.0000] <JakeA>
Where platform objects cannot exist, right?

[11:20:29.0000] <TabAtkins>
Oh wait, by "platform" do you mean the JS objects that authors use?

[11:20:35.0000] <TabAtkins>
Or the internal objects that the browser uses?

[11:20:51.0000] <JakeA>
Ah, I meant JS I objects

[11:21:01.0000] <JakeA>
Wrong term?

[11:21:05.0000] <TabAtkins>
dunno

[11:21:37.0000] <TabAtkins>
Anyway, the JS objects are magically created from IDL at the moment you pass the IDL value to author code, via a return value. (And vice versa via a method argument)

[11:21:54.0000] <TabAtkins>
(where "return value" and "argument" also cover the attribute getter/setters)

[11:22:20.0000] <TabAtkins>
And yeah, Infra objects never become JS, they have to be laundered into IDL first.

[11:22:21.0000] <JakeA>
So if I return the same IDL instance twice, I'm not guaranteed the same JS object twice?

[11:22:39.0000] <TabAtkins>
The algo should be clear on whether it's the same or not.

[11:22:46.0000] <JakeA>
How?

[11:22:53.0000] <TabAtkins>
Specify caching or not.

[11:23:04.0000] <JakeA>
What would I cache?

[11:23:08.0000] <TabAtkins>
IDL doesn't really have object identity, so it's not obvious from principles.

[11:23:27.0000] <TabAtkins>
Heh, gimme a concrete example and I can help more.

[11:24:34.0000] <JakeA>
Eg a `.loaded` getter that returns the same promise unless the "src" changes

[11:24:56.0000] <TabAtkins>
Okay, so then you create an IDL object, and cache it.

[11:25:27.0000] <JakeA>
But I thought there was no guarantee that returning the same IDL object would map to the same JS object?

[11:25:33.0000] <TabAtkins>
Plz don't read too much into my "magically created", I just meant you don't need to do anything special to make the JS object happen.

[11:25:45.0000] <TabAtkins>
JS<->IDL is understood to be 1:1

[11:26:13.0000] <TabAtkins>
You, the spec author, just never ever touch the JS object unless you ahve a *very* good reason and a smart person holding your hand (not me).

[11:26:48.0000] <JakeA>
Just to confirm, if I pass the same IDL instance back twice, the two JS objects at the other end will be `===`, right?

[11:26:53.0000] <TabAtkins>
yes

[11:27:12.0000] <TabAtkins>
But you do have to be explicit that it's the same IDL instance which was cached between calls. ^_^

[11:27:49.0000] <JakeA>
Gotcha! Phew, I thought for a moment there my whole understanding of specs was coming crashing down

[11:28:32.0000] <TabAtkins>
hehehe

[11:28:59.0000] <JakeA>
One last one… can I create instances of IDL types "in parallel"?

[11:29:30.0000] <JakeA>
(Assuming that the JS object creation happens later, when I return it on the main thread)

[11:29:31.0000] <TabAtkins>
Yes, you can *create* them. You just can't cause an author-observable update to anything while "in parallel".

[11:29:53.0000] <TabAtkins>
(pretty sure, but Domenic should confirm)

[11:30:03.0000] <TabAtkins>
(just in case there's actually some state dependency I'm not aware of)

[11:30:54.0000] <JakeA>
Gotcha. My (wrong) assumption that JS objects are created at the same time led me to only create IDL instances on the main thread

[11:31:28.0000] <JakeA>
But it wouldn't be observable, so fine

[11:40:16.0000] <JakeA>
I think was confused me was seeing instances of interfaces created in a given realm.

[11:40:50.0000] <JakeA>
That made it feel like JS object creation happened then, and it must therefore be on the JS thread.

[11:41:09.0000] <JakeA>
I think what confused me*

[11:42:12.0000] <TimothyGu>
JakeA: hmm I remember it to be the exact opposite

[11:42:25.0000] <TimothyGu>
IDL object is defined to be identical to the JS object

[11:43:13.0000] <TimothyGu>
numbers, etc. are probably fine

[11:44:29.0000] <JakeA>
Not sure I understand. I'm talking more about instantiation than definition

[11:44:54.0000] <TimothyGu>
as in "create a … object"?

[11:45:58.0000] <JakeA>
Yeah "Let |whatever| be a new {{Whatever}}"

[11:47:14.0000] <TimothyGu>
I'm not 100% sure but from what I remember this shouldn't be allowed

[11:48:12.0000] <JakeA>
If I wanted to create an instance of {{Whatever}}, how should I do that?

[11:50:21.0000] <JakeA>
In order for, say, the `window.navigator` getter to return an instance of `Navigator`, and instance of the IDL interface `Navigator` must be created somewhere.

[11:50:34.0000] <JakeA>
an instance*

[11:51:10.0000] <TimothyGu>
JakeA: hmm for that generally you could do something like "Each {{Window}} object has an associated <dfn>navigator</dfn>, which is a {{Navigator}} object."

[11:52:09.0000] <TimothyGu>
and then at the same time as when the Window object is instantiated the Navigator object would be too

[11:52:30.0000] <TimothyGu>
/me reads up on the log

[11:52:33.0000] <JakeA>
TimothyGu: but that's just handwaving around creating an instance of Navigator, right?

[11:53:44.0000] <TimothyGu>
JakeA: well, not really. This construct is supposed to parallel something like `class Window { Navigator navigator; }` in C++

[11:54:09.0000] <TimothyGu>
i.e., the Navigator is created at the same time as the Window, because a window _has_ a navigator

[11:56:00.0000] <TimothyGu>
an implementation might actually hold off on creating the Navigator object until it is first accessed, but that's considered an implementation detail

[11:56:57.0000] <JakeA>
TimothyGu: so step 29 and 31 of https://fetch.spec.whatwg.org/#dom-request is incorrect?

[11:58:00.0000] <JakeA>
Or step 8 of https://url.spec.whatwg.org/#dom-url-url to go for a smaller example

[11:58:26.0000] <TimothyGu>
JakeA: they are fine, but also different from the navigator example

[11:58:52.0000] <TimothyGu>
for example the "has an associated ... object" pattern is used for https://url.spec.whatwg.org/#concept-url-query-object

[11:59:08.0000] <JakeA>
TimothyGu: but 100% like my "let |whatever| be a new {{Whatever}}" example, right?

[11:59:28.0000] <TimothyGu>
JakeA: yeah but I thought you were asking about "in parallel"?

[11:59:40.0000] <TimothyGu>
the constructors don't run in parallel

[12:00:15.0000] <JakeA>
TimothyGu: but not all interfaces have constructors

[12:01:03.0000] <Mek>
(probably unrelated to this discussion, but) they generally should have constructors

[12:01:30.0000] <TimothyGu>
okay I feel like we are talking about something different

[12:01:45.0000] <TimothyGu>
"new {{…}}" don't run the constructor, at least in most cases

[12:03:27.0000] <JakeA>
I guess I'm still in the dark on whether instances of IDL types can be created while "in parallel" 😀

[12:04:13.0000] <Mek>
I don't think you can create a new instance of an IDL type in parallel, no

[12:04:31.0000] <Mek>
but also agree that running of constructors is more or less unrelated

[12:04:43.0000] <JakeA>
Gotcha. Good to know I haven't been doing that unnecessarily 😀

[12:06:25.0000] <TimothyGu>
I feel like this is sufficiently confusing to warrant some guidance in HTML

[12:06:50.0000] <Mek>
probably webidl rather than html, but yes

[12:07:11.0000] <JakeA>
Either. HTML defines "in parallel"

[12:07:13.0000] <TimothyGu>
Mek: "in parallel" is defined in HTML though, and IDL doesn't really know about parallelism

[12:07:18.0000] <Mek>
one issue is how idl objects are associated with realms, for which for now idl says " The mechanisms for associating objects with Realms are, for now, underspecified"

[12:07:48.0000] <TimothyGu>
Mek: that's really only an issue for non-platform objects

[12:07:53.0000] <JakeA>
Yeah, that's what got me thinking that the JS object is created when the IDL object is created

[12:08:16.0000] <TimothyGu>
for platform objects there's always a [[Realm]] slot

[12:08:26.0000] <TabAtkins>
I was pretty sure you could create IDL objects in parallel. I'd be somewhat surprised if that wasn't the case.

[12:08:47.0000] <TimothyGu>
/me files issue

[12:08:58.0000] <JakeA>
TimothyGu: but if you're creating an instance, how does it know what realm to put it in?

[12:09:04.0000] <Mek>
https://heycam.github.io/webidl/#es-platform-objects seems to be the section that we're talking about, right?

[12:09:16.0000] <Mek>
that defines the algorithms you should call when creating a new object for some IDL interface

[12:09:36.0000] <TimothyGu>
JakeA: that is https://github.com/heycam/webidl/issues/135

[12:10:17.0000] <Mek>
ah yes, the third bullet point there is pretty explicit that creating them in parallel is okay, as long as you're explicit about the realm

[12:10:52.0000] <JakeA>
TimothyGu: but if you've gone parallel, then queued a task, does that association hold?

[12:11:25.0000] <TimothyGu>
JakeA: what association?

[12:11:37.0000] <JakeA>
Ah yes the third bullet point answers my question too

[12:11:43.0000] <Mek>
(but later discussion in that thread seems to also ask if we really should allow creating objects from in parallel)

[12:12:19.0000] <JakeA>
TimothyGu: there's no longer a "this" if you've queued a task

[12:13:01.0000] <JakeA>
Unless you kinda handwave it as being "the context object from which the parent steps were called"

[12:13:11.0000] <TimothyGu>
JakeA: I think that handwaving is fine

[12:13:27.0000] <TimothyGu>
bc specs already assume all "local variables" are captured anyway

[12:14:11.0000] <JakeA>
Fair

[12:14:23.0000] <Mek>
well, for queueing a task it probably makes more sense to somehow derive the realm from where the task is queued on, rather than who queued the task (i.e. postmessage posting a task to a different global)

[12:14:50.0000] <JakeA>
Also true

[12:14:52.0000] <Mek>
so https://github.com/heycam/webidl/issues/135#issuecomment-286789309 seems pretty reasonable to me... But I guess if one thing is clear from that thread it is that currently there are no well defiend semantics...

[12:16:23.0000] <JakeA>
Good to know my questions aren't stupid, at least

[12:22:06.0000] <TimothyGu>
Ah there's more. https://html.spec.whatwg.org/multipage/infrastructure.html#parallelism has an example with rejecting promises with a new TypeError object in parallel, but in https://github.com/whatwg/notifications/issues/113#issuecomment-349292187 annevk explicitly says resolving a promise in parallel isn't allowed

[12:26:02.0000] <TabAtkins>
Right, that's because it's observable - it enqueues promise callbacks, and their ordering wrt other timing-based callbacks is author-observable (and thus can't be done while in parallel).

[12:26:08.0000] <TabAtkins>
So yeah that's an error.

[12:39:37.0000] <TimothyGu>
Filed https://github.com/whatwg/html/issues/4669 to hopefully sort out this mess

[12:44:40.0000] <annevk>
Thanks TimothyGu