2020-06-02
[21:36:22.0000] <domfarolino>
Ugh, we need to implement async iterators

[21:36:38.0000] <domfarolino>
It kinda fell off the priority wagon last year (for Chrome at least)

[21:51:25.0000] <Domenic>
Plzzz

[02:37:02.0000] <Ms2ger>
/me tries to remember if this is a good time to catch MikeSmith 

[03:39:14.0000] <MikeSmith>
/me Ms2ger here now

[03:53:51.0000] <MikeSmith>
botie: inform Ms2ger remind to me to follow up

[03:53:51.0000] <botie>
will do

[04:18:37.0000] <MikeSmith>
PSA https://www.w3.org/TR/cors/ now redirects to https://fetch.spec.whatwg.org/

[04:19:31.0000] <MikeSmith>
PSA2 https://www.w3.org/TR/notifications/ now redirects to https://notifications.spec.whatwg.org/

[04:21:09.0000] <annevk>
MikeSmith: cool, maybe Fetch no longer needs to say it replaces CORS

[04:21:54.0000] <MikeSmith>
annevk: yeah I guess it’s no longer necessary

[04:24:07.0000] <MikeSmith>
oh, that reminds me — one more: https://www.w3.org/TR/progress-events/ » https://xhr.spec.whatwg.org/

[05:03:55.0000] <botie>
Ms2ger, at 2020-06-02 10:53 UTC, MikeSmith said: remind to me to follow up

[05:04:31.0000] <Ms2ger>
botie, inform MikeSmith reminder

[05:04:32.0000] <botie>
will do

[05:29:49.0000] <MikeSmith>
about https://github.com/whatwg/xhr/pull/279#issuecomment-636987348 — can I resolve this by adding a note to https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/send#Syntax saying that no browsers actually yet implement support for XMLHttpRequest.p.send(body) with a ReadableStream?

[05:29:49.0000] <botie>
MikeSmith, at 2020-06-02 12:04 UTC, Ms2ger said: reminder

[05:31:54.0000] <annevk>
MikeSmith: I see two issues there; it doesn't clearly allow for null as a value

[05:32:02.0000] <MikeSmith>
OK

[05:32:20.0000] <annevk>
MikeSmith: and ReadableStream could just be removed, I don't think we need a note as it was never implemented and won't be added per this decision

[05:32:38.0000] <MikeSmith>
yeah now looking at https://github.com/whatwg/fetch/pull/1029 I see the plan there

[05:38:28.0000] <MikeSmith>
annevk: OK how does https://wiki.developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/send#Parameters look now?

[05:40:04.0000] <annevk>
MikeSmith: seems good; I think for developer documentation we could do more to unpack USVString and BufferStream and such, but that's a more global issue I suspect

[05:40:17.0000] <MikeSmith>
yeah

[06:30:04.0000] <annevk>
Domenic: define browsing session as the new 7.7.1? At the start of Session history and navigation

[06:30:26.0000] <annevk>
And what, I mean a glorified XXX entry

[06:30:38.0000] <annevk>
And with that* wow

[06:34:39.0000] <Domenic>
annevk: seems reasonable. The other thing would be as the new 7.1 since it's conceptually "larger" than a browsing context, but, I think your idea is probably better.

[06:35:54.0000] <annevk>
It's larger than a top-level browsing context, and smaller or larger than a BCG, depending

[06:36:08.0000] <annevk>
Good times in browsing * land

[07:05:34.0000] <domfarolino>
Domenic: ping on https://github.com/whatwg/html/pull/5573 in case you wanted to merge

[07:05:55.0000] <Domenic>
Ah thank you

[08:09:49.0000] <domfarolino>
When did PR preview stop showing the yellow highlights and arrows in the diff view?

[08:13:10.0000] <Domenic>
I noticed that too...

[08:31:57.0000] <domfarolino>
It makes the diff so hard to read for HTML PRs because the pages are so big usually :/

[08:42:43.0000] <Domenic>
Worth filing an issue... https://github.com/tobie/pr-preview/issues

[08:43:08.0000] <annevk>
Is it only the styling that is lost?

[08:43:31.0000] <annevk>
I still see <ins> plus class in the source, but it's not highlighted as much as it used to be

[08:44:22.0000] <annevk>
Oh I see

[08:44:36.0000] <annevk>
I think we broke it when we moved out <style>

[08:45:22.0000] <annevk>
I didn't realize how much this script modified our output

[08:45:31.0000] <annevk>
It also tries to load https://w3c.github.io/htmldiff-nav/index.js

[08:49:31.0000] <annevk>
It also forces quirks mode

[08:52:53.0000] <annevk>
https://github.com/tobie/pr-preview/issues/66


2020-06-03
[20:22:26.0000] <Domenic>
annevk: would you be able to find someone from Mozilla to comment on https://github.com/whatwg/streams/pull/1035 for implementer interest?

[22:11:04.0000] <annevk>
Domenic: I pinged some people from the WebVM team

[01:02:20.0000] <Ms2ger>
> * ignores issue for four years

[01:02:28.0000] <Ms2ger>
> it's unfortunate [browser] implemented this change without noticing that this open issue existed

[01:07:03.0000] <annevk>
Ms2ger: that's a very selective quote given what follows, please do better 😉

[01:07:54.0000] <Ms2ger>
Well, the ignoring bothers me more than the comment anyway

[01:09:42.0000] <annevk>
There's not many specifications without that problem unfortunately

[01:10:09.0000] <annevk>
Although usually the problems are a bit more involved if they are older

[02:31:05.0000] <yhirano>
annevk: hi, I have some questions about cachestorage (realted to https://github.com/w3c/ServiceWorker/pull/1516).

[02:31:26.0000] <annevk>
yhirano: sure

[02:31:57.0000] <yhirano>
annevk: Is https://w3c.github.io/ServiceWorker/#dfn-relevant-request-response-list the persisted requests and responses?

[02:38:26.0000] <annevk>
yhirano: my knowledge about the Cache API is a bit limited unfortunately; maybe JakeA can help

[02:38:55.0000] <annevk>
yhirano: on the face of it that definition doesn't make any sense to me

[02:40:30.0000] <annevk>
yhirano: I guess I can sorta see what it's getting it and I think you're right about the intent, but this isn't how this ought to be worded

[02:41:16.0000] <yhirano>
annevk: I see. After thinking about this a bit more I come to think we should rely on response, not the request, because web authors can select arbitrary request and response for cache.put arguments.

[02:42:14.0000] <yhirano>
annevk: web deves can call cache.put(cors-request, opaque-response) so we shouldn't trust the mode on request for the CORP check.

[02:43:32.0000] <annevk>
yhirano: I tend to agree

[02:43:48.0000] <annevk>
yhirano: the CORP algorithm I looked it was mostly looking at the request though

[02:44:41.0000] <annevk>
I suspect in part because the response's URL list wouldn't have been updated yet, but maybe there's a better way to do this

[02:44:56.0000] <yhirano>
annevk: that's why I'm resetting mode at https://pr-preview.s3.amazonaws.com/w3c/ServiceWorker/1516/0aceaac...yutakahirano:23a4317.html#cross-origin-resource-policy-check-for-cached-resource-algorithm

[02:45:26.0000] <yhirano>
annevk: For origin request.origin can be "client" and we don't want to use the string.

[02:46:03.0000] <annevk>
yhirano: I don't see how resetting mode helps with the CORP algorithm not looking at the response

[02:48:41.0000] <yhirano>
annevk: https://github.com/whatwg/fetch/pull/1030 adds  'Assert: request.mode either "no-cors" or "navigate"'.

[02:49:03.0000] <annevk>
yhirano: sure, but there's a larger issue

[02:49:47.0000] <yhirano>
annevk: The CORP check looks at url, mode, origin and coep (via client) on request.

[02:50:32.0000] <annevk>
Yes

[02:51:05.0000] <yhirano>
annevk: For origin and client I thin the relevant settings object works.

[02:51:24.0000] <yhirano>
annevk: For mode we cannot trust request and I'm using response.type instead.

[02:52:51.0000] <annevk>
yhirano: I mean, URL is the problem, right?

[02:53:48.0000] <annevk>
yhirano: but also, I'm wondering if we can restructure the CORP check somehow to make it easier for the Cache API to use, rather than having to more or less abuse a request

[02:54:04.0000] <yhirano>
annevk: in the fetch spec?

[02:54:09.0000] <annevk>
yhirano: yes

[02:54:44.0000] <yhirano>
annevk: i see

[02:54:59.0000] <yhirano>
annevk: For url I think we can use https://fetch.spec.whatwg.org/#concept-response-url

[02:55:27.0000] <annevk>
yhirano: yeah, though at that point you shouldn't really clone the bogus request, you should just construct your own, but it ends up looking really weird

[02:58:18.0000] <yhirano>
annevk: ok I'll modify https://github.com/w3c/ServiceWorker/pull/1516 again. We may want to move the CORP-for-cache algorithm to the fetch spec (https://github.com/whatwg/fetch/pull/1030/). Does that sound OK?

[03:03:31.0000] <annevk>
yhirano: I think we should take a closer look at what algorithm Fetch should define here

[03:04:37.0000] <yhirano>
annevk: I'm thinking about having CORP-check-for-cached-response which takes a response and and environment settings object and returns allowed/blocked.

[03:04:56.0000] <yhirano>
annevk: a response and an environment settings object

[03:09:22.0000] <yhirano>
annevk: (url, mode, origin, client) is calculated as (response's url, "no-cors", settings object's origin, settings object)

[03:15:24.0000] <annevk>
yhirano: basically, I think the CORP check is also bogus for responses coming from a service worker

[03:15:38.0000] <annevk>
yhirano: since you can fake the request there as well

[03:19:41.0000] <yhirano>
annevk: ah you're right.

[03:21:29.0000] <yhirano>
annevk: what do you think about giving (url, origin, mode, coep, response) instead of (request, response) to the CORP check?

[03:22:22.0000] <yhirano>
annevk: ah we need two urls, current url and original url for reporting.

[03:29:53.0000] <annevk>
yhirano: I would prefer looking into whether response should get a URL sooner

[03:30:09.0000] <annevk>
yhirano: or URL list, for that matter

[03:30:55.0000] <yhirano>
annevk: sorry I don't understand your last comment. Can you rephrase it?

[03:31:33.0000] <annevk>
yhirano: in main fetch step 9 we set a response's URL list, if we do that before we do the CORP check, we don't need to pass it so many things and can instead rely on the response for most of it

[03:32:30.0000] <yhirano>
annevk: i see thanks

[03:33:13.0000] <annevk>
yhirano: another I thing that seems weird is that we check response tainting before invoking the CORP check, but how would we ever invoke it with mode being navigate then? Does HTML invoke it directly?

[03:33:28.0000] <yhirano>
annevk: yes

[03:35:21.0000] <yhirano>
annevk: please see the 6th step of https://whatpr.org/html/5454/browsing-the-web.html#process-a-navigate-fetch.

[03:36:44.0000] <annevk>
yhirano: that doesn't check it for redirects

[03:38:03.0000] <annevk>
yhirano: that also seems to have the problem of the request URL not being the correct source of authority

[03:40:42.0000] <yhirano>
Redirects are handled in the above while loop, right?

[03:41:11.0000] <annevk>
yhirano: if a redirect response lacks CORP, it would still continue, afaict

[03:42:48.0000] <yhirano>
annevk: yeah so we need to move the block to somewhere in the step 5.

[03:43:02.0000] <annevk>
I'll comment on the PR

[03:44:36.0000] <yhirano>
annevk: regarding the request url vs response url the navigation case is more difficult than cachestorage

[03:46:47.0000] <annevk>
yhirano: I think we could use the response URL list as well, but I forgot what document URL a request for /foo that gets a response for /bar ends up with, so I'm not entirely sure

[03:50:58.0000] <yhirano>
annevk: i'll work on the PRs tomorrow. Thank you very much for your thoughtful comments!

[03:52:35.0000] <annevk>
yhirano: sounds good, take care

[05:28:14.0000] <domfarolino>
annevk: can you help me understand your iframe lazyload comment about nondeterminism and the sandbox attr? Do you mean the value of the sandbox attribute could change after load deferral, therefore it’s “snapshot” is taking arbitrarily later?

[05:31:51.0000] <annevk>
domfarolino: yes

[05:32:44.0000] <annevk>
domfarolino: see also https://github.com/whatwg/html/issues/4926

[05:33:06.0000] <annevk>
domfarolino: (it seems that for referrer policy the right thing would happen in your PR)

[05:34:28.0000] <domfarolino>
annevk: that and the URL, since it is parsed relative to the node doc before navigating

[05:34:50.0000] <annevk>
domfarolino: right, that helps with blobs

[05:35:00.0000] <domfarolino>
annevk: hmm ok interesting. Do you have an idea on what other state could be problematic?

[05:35:33.0000] <annevk>
domfarolino: any kind of policy that is mutable

[05:35:56.0000] <annevk>
(this is one of the reasons to oppose <meta http-equiv> policies)

[05:36:52.0000] <domfarolino>
annevk: I guess a solution could be to defer the load much later (in the navigation algorithm) but I’m not sure how clean that’d be

[05:37:03.0000] <annevk>
domfarolino: so CSP, base URL

[05:37:48.0000] <annevk>
domfarolino: yeah, we discussed that last time, that might work, but would also trigger some new issues

[05:37:53.0000] <annevk>
domfarolino: oh, though I guess we have those here too

[05:38:10.0000] <annevk>
domfarolino: what if someone navigates the frame while there's a navigation queued in this manner?

[05:40:08.0000] <domfarolino>
annevk: I think that’s not too problematic. The navigation algorithm would be invoked again, the decision to lazy load, if still true, would just re-observe the element (which is no-op), and when the resumption steps are invoked the navigation continues

[05:40:55.0000] <domfarolino>
annevk: “so CSP, base URL”. Hmm didn’t we say base URL is fine?

[05:42:14.0000] <annevk>
domfarolino: we did for images, because we already parsed, but frames can inherit things

[05:42:54.0000] <annevk>
domfarolino: at least, I think a blob URL frame might do something with the base URL and srcdoc certainly will

[05:43:13.0000] <annevk>
domfarolino: now for blobs I guess you could make the argument that it should be copied when you create the blob URL

[05:43:26.0000] <annevk>
so maybe blob URLs don't count as much

[05:43:30.0000] <annevk>
or at all

[05:45:38.0000] <domfarolino>
annevk: I don’t think I follow. Independently, I don’t actually know anything about blob URLs, which probably isn’t helping. But I was referring to your comment above “right, that helps with blobs” in response to mine about snapshotting the resolved URL before the navigation algorithm

[05:51:04.0000] <annevk>
domfarolino: I'm not sure what you mean

[05:57:31.0000] <domfarolino>
annevk: if an element’s loading gets deferred before its src is parsed relative to the node document’s base URL, and the base URL changes, then the load is subject to those base URL changes which is not good. We solve that with images by first parsing the src relative to the document, then deferring after. I think we do the same for iframes, since we parse the url and set up the request before deferring

[05:58:09.0000] <domfarolino>
So therefore the resolved URL is known before load deferral, which I think is what we want

[06:07:32.0000] <annevk>
domfarolino: correct

[06:08:29.0000] <annevk>
domfarolino: the tricky aspect is that a base URL can also been as a policy as it "inherits" into the framed document in certain cases; that's unique to the iframe scenario

[06:10:59.0000] <domfarolino>
annevk: I see so you’re saying that by parsing the src early on like the PR does, we don’t solve *all* the problems yet, because the base URL is also taken into account later...hmm

[06:11:24.0000] <annevk>
correct

[06:13:33.0000] <annevk>
domfarolino: I do think that some of these nondeterminism issues we could maybe just accept, but need to think a bit more carefully if doing so would prevent any future cleanups

[06:14:02.0000] <annevk>
domfarolino: in the sense that it's not too different from the user doing an unexpected navigation

[06:15:41.0000] <domfarolino>
annevk: OK makes sense. I think it’s fine to accept them, but will take a closer look at the navigation algorithm earlier. I’d like to avoid touching it a lot as I think the currently solution is pretty clean, but we’ll see.

[06:15:59.0000] <domfarolino>
I guess either way I’ll be touching it a little to ensure that delayed iframes don’t delay the load event

[10:07:13.0000] <annevk>
domfarolino: thanks; I'll try to think a bit more about what a good minimum viable product would be here and discuss with others at Mozilla; perhaps srcdoc and perfect policy enforcement are indeed too much

[10:07:55.0000] <domfarolino>
annevk: If you'd like to have a VC with myself and some mozilla folks I'd be happy to do that (partially so I could understand the issues better myself)

[10:12:47.0000] <annevk>
domfarolino: it's still a bit in the planning phase internally, but I'll keep that in mind, thanks; (happy to chat 1:1 earlier if that can help)

[10:14:26.0000] <domfarolino>
👍

[15:21:47.0000] <gregwhitworth>
hey folks, I may be missing something but is there something in the spec that defines events that should/shouldn't be fired for an <option> element as I'm getting a different result between gecko/webkit for click event: https://jsfiddle.net/3uh6nfsr/

[15:22:04.0000] <gregwhitworth>
Looking here: https://html.spec.whatwg.org/multipage/form-elements.html#the-option-element

[15:23:16.0000] <gregwhitworth>
it inherits the Iface of HTMLElement which has the element and the global events so I'd assume they'd work. I may be missing a note or link however to limitations or UA allowance of support given the interop issues of <select>

[15:53:25.0000] <Domenic>
gregwhitworth: what's on the prototype chain doesn't govern what events are fired; you need normative text saying "fire an event". Let me look for some...

[15:54:26.0000] <gregwhitworth>
Domenic: thanks - I figured this must be defined somewhere

[15:54:36.0000] <Domenic>
gregwhitworth: ah, click event. It turns out there's nothing in all of web specs that says "when the user clicks their mouse, fire a click event". Much less details tricky questions like hit-testing and whether clicking an option counts as clicking the option or its select or...

[15:54:49.0000] <Domenic>
So basically this is undefined :(

[15:54:55.0000] <gregwhitworth>
Domenic: ahhh, ok - cool

[15:55:58.0000] <gregwhitworth>
thanks

[16:02:13.0000] <Domenic>
No problem; just wish I had better news for you

[16:02:55.0000] <gregwhitworth>
Domenic: I'm adding in the event mapping for <select> in Open UI and while this spec of course is about documenting what to tie to "options" (whether HTML Platform or JS impl) I found the interop interesting

[16:03:11.0000] <gregwhitworth>
Domenic: for what it's worth, gecko isn't consistent - it doesn't fire mouseover for options for example


2020-06-04
[17:35:14.0000] <gregwhitworth>
Domenic:  even though that ended up not being the case for option, mind sending me an event example for another element so I know what to look for. Thanks :)

[20:50:24.0000] <MikeSmith>
annevk: I edited https://wiki.developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts to make a number of refinements to align it with the Secure Contexts spec. Please review and let me know if it looks OK or if you have suggestions for further refinements or corrections.

[21:02:37.0000] <annevk>
gregwhitworth: it could be some kind of activation behavior I suppose; but yeah, mouse events are not really defined, hit testing is not defined, and the select popup box is not defined

[21:06:00.0000] <annevk>
MikeSmith: it might be better to say top-level document as the browsing context can contain both secure and insecure contexts; it strikes me that “context” was a poor word choice for this feature

[21:06:31.0000] <annevk>
MikeSmith: also maybe make mitm say monster-in-the-middle

[21:14:40.0000] <annevk>
MikeSmith: thanks for fixing it up!

[22:12:17.0000] <MikeSmith>
annevk: so I actually replaced some instances of “top-level document” which had been in that article — because neither HTML nor Secure Contexts defines “top-level document”

[22:12:57.0000] <MikeSmith>
so now I’m unsure how to word it in order to align it with how the specs actually define things

[22:13:05.0000] <annevk>
MikeSmith: you could also top-level browsing context's active document

[22:13:16.0000] <MikeSmith>
ah yeah

[22:13:24.0000] <annevk>
MikeSmith: but the thing to keep in mind is that a browsing context doesn't have authority

[22:13:39.0000] <MikeSmith>
oh really?

[22:13:39.0000] <annevk>
(even though HTML sometimes incorrectly makes it look like it does)

[22:14:03.0000] <annevk>
MikeSmith: it doesn't have an origin, it represents a sequence of documents that can all have different origins

[22:14:04.0000] <MikeSmith>
well that’s hard to tell from the Secure Contexts spec as well

[22:14:11.0000] <MikeSmith>
aha yeah

[22:14:26.0000] <annevk>
I'm not surprised

[22:15:04.0000] <MikeSmith>
yeah you were able to explain it clearly in a couple sentences

[22:15:37.0000] <MikeSmith>
so I wish the Secure Contexts spec could be refined to state it in similar terms

[22:16:09.0000] <MikeSmith>
anyway for now I’ll make another update to the MDN article

[22:31:06.0000] <gregwhitworth>
annevk: thanks. "select popup box is not defined" This is something we're actively looking into however, which is one way in which this was interop gap difference was found

[22:37:27.0000] <annevk>
gregwhitworth: makes sense, filing an issue against whatwg/html for the click/activation behavior on option might be worth doing

[22:38:51.0000] <gregwhitworth>
sounds good - let me get the Open UI group aligned a bit on the event mapping so it's a bit more clear. Also, I'd like to extend the invite because the Open UI discussions will propagate to WHATWG for web platform changes at some point

[22:41:17.0000] <gregwhitworth>
https://github.com/WICG/open-ui/

[08:13:31.0000] <Domenic>
Is PR preview just broken for all Bikeshed specs now, or only WHATWG ones, or...?

[08:17:05.0000] <annevk>
Domenic: all Bikeshed it seems

[08:17:44.0000] <annevk>
https://github.com/tobie/pr-preview/issues/67

[09:01:51.0000] <annevk>
noamr: I'd like to talk to heycam a bit; it might actually be better if EXIF wasn't exposed for opaque images at all (or treated as if not present); because making each caller do the correct origin check seems like a recipe for disaster

[09:02:58.0000] <noamr>
annevk: I see a risk there... people would enable CORS on image just for the sake of getting them to display correctly, exposing the image content to canvas

[09:03:47.0000] <noamr>
and what's the harm in making EXIF affect the orientation/resolution, if there's no CSS/markup way to override it?

[09:05:03.0000] <annevk>
noamr: I don't think we can guarantee there will never be such features, right? Would each such feature need to get a security check?

[09:06:50.0000] <noamr>
annevk: I think so, if the alternative is to cripple features that in themselves don't pose a security risk...

[09:07:33.0000] <annevk>
That doesn't really seem acceptable

[09:07:47.0000] <noamr>
I think the opaque image restrictions should be on the "overriding" features - like HTML attributes / CSS properties / JS, rather than on how images are handled by default

[09:08:57.0000] <annevk>
That's an extremely brittle design and will likely fail

[09:09:51.0000] <noamr>
(sorry for the inappropriate "cripple" colloquialism btw)

[09:12:29.0000] <noamr>
annevk: so are you suggesting to do the same re. EXIF orientation, and make it so that only same-origin/CORS-enabled images can use that feature?

[09:14:44.0000] <annevk>
Yeah

[09:21:25.0000] <annevk>
Domenic: sorry about that, my commit had a green checkmark so I assumed it was in order

[09:21:41.0000] <annevk>
Domenic: it seems Travis is kinda lagging or something

[09:34:08.0000] <noamr>
thanks for the clarifications and patience, annevk. waiting to see what more people have to say on https://github.com/w3c/csswg-drafts/issues/5165 :)

[09:40:15.0000] <annevk>
noamr: you should share your concern as well, though I hope we can avoid a Cross-Origin-Expose-Image-Metadata

[09:40:36.0000] <annevk>
ah you did already

[10:35:31.0000] <TimothyGu>
yay, class strings on interfaces finally got fixed on every browser https://wpt.fyi/results/WebIDL/ecmascript-binding/class-string-interface.any.html?label=experimental&label=master&aligned

[10:45:14.0000] <andreubotella>
annevk, Domenic: I'm working on the conversion algorithms between token queues (a.k.a "Encoding streams") and strings/byte sequences, and I'm not sure what to do with the dfns

[10:45:34.0000] <andreubotella>
I can't have four algorithms named <dfn for="token queue">convert</dfn>

[11:01:18.0000] <Domenic>
andreubotella: quick answer between meetings without me looking at the spec to confirm in makes sense: you can put arbitrary strings in for="", so you could have for="token queue to X", for="token queue to Y", etc. It's not reader-visible (except maybe in the autogenerated IDs)

[11:02:16.0000] <andreubotella>
Yeah, that might work

[11:02:17.0000] <andreubotella>
thanks

[11:05:34.0000] <annevk>
TimothyGu: cool, I guess that means we can check it in idlharness now

[11:06:01.0000] <annevk>
Yeah, for=“” is the best

[11:06:09.0000] <TimothyGu>
Indeed, though iterator objects are still inconsistent


2020-06-05
[09:12:56.0000] <annevk>
Domenic: Travis seems to have lost track of whatwg/html again and I cannot seem to debug it as logging into Travis fails repeatedly

[09:42:23.0000] <annevk>
I finally got Travis to recognize things again and it is doing some things anew

[09:45:28.0000] <domfarolino>
SVG <script>s are not the same as https://html.spec.whatwg.org/multipage/scripting.html#the-script-element right? I don't think they are, since they use href instead of src, and there's no mention of these in the HTMLScriptElement processing model

[09:46:15.0000] <annevk>
domfarolino: they should be mostly the same and there's probably an open issue on adding some kind of abstraction for that

[09:47:20.0000] <domfarolino>
Like if I make a change to #prepare-a-script, I'm wondering if that applies to svg scripts. I guess it doesn't, unless the intention is to have it apply to some currently-missing abstraction like you mentioned

[09:48:27.0000] <annevk>
I guess I'm saying that I'm pretty sure it should, but that we haven't really done our due diligence there

[09:48:36.0000] <domfarolino>
Right, makes sense

[13:51:55.0000] <TimothyGu>
Domenic: do you know what ObservableArray is going to be used for?

[13:54:04.0000] <Domenic>
TimothyGu: https://wicg.github.io/construct-stylesheets/#using-constructed-stylesheets is the biggest target. Most frozen arrays that can change over time are other targets. General discussion with other examples in https://github.com/heycam/webidl/issues/796.

[13:55:12.0000] <TimothyGu>
ah cool, got it


2020-06-06
[20:07:08.0000] <TimothyGu>
Sometimes I think the algorithms for async iteration etc. need a machine-checked proof for consistency

[20:07:46.0000] <TimothyGu>
The human mind is yet too weak

[20:08:14.0000] <TimothyGu>
Or maybe just my mind

[20:11:30.0000] <TimothyGu>
That would sound like a cool intern project hmm

[22:04:12.0000] <annevk>
TimothyGu: that’d be cool for all algorithms 😊

[22:10:48.0000] <mitchell>
[ANN] Come use The Speakeasy Solution Stack Rust engine: Torchbear for fast, safe, simple, and complete® scripting

[22:10:48.0000] <mitchell>
https://github.com/naturallymitchell/announcements/issues/1

[07:20:40.0000] <ondras>
so, is there a way to find out whether a randomly encountered <script> is already loaded? even if its onload was alteady executed, i.e. i am visiting it post-load?

[07:20:47.0000] <ondras>
*already


2020-06-07
[07:57:47.0000] <ondras>
;3B/w 50

[07:57:51.0000] <ondras>
dammit sorry


2020-06-08
[01:21:19.0000] <PiersW>
domfarolino: Our SVG <script>s use #prepare-a-script. It seemed logical that they behave the same as HTML, so the code is common to both. I think we just assumed other browsers did the same.

[01:21:57.0000] <domfarolino>
Chrome does the same

[01:24:38.0000] <annevk>
Yeah, I think the main difference is 1) the HTML parser and 2) the public API (xlink:href vs src for instance)

[01:25:13.0000] <annevk>
And arguably 1 is a duplicate of 2

[01:28:22.0000] <PiersW>
Yeah, for 2 we haven't implemented all the attributes (async, etc) for SVG, though it'd be trivial to do so but it's not part of the SVG 2 spec.

[01:28:39.0000] <PiersW>
HTML attrs, I mean.

[04:43:29.0000] <scfe>
I have a question regarding html5lib (Python): Is there support for "diffing" two html trees? In particular I'd like to check attributes, conditional comments etc. Also I want to check generated CSS in <style>  tags - probably via a separate library but the diffing should return the style contents so I can do the diff on my own.

[04:43:32.0000] <scfe>
any pointers?

[04:44:11.0000] <scfe>
I'm not looking for a turn-key solution - just some Python API I can use without resorting to raw parsing events.

[04:52:35.0000] <annevk>
I'm only aware of tools to diff documents, but those wouldn't do what you need (sounds like you're looking at XSS?)

[04:55:30.0000] <scfe>
annevk: No, actually I want to test html generation

[04:56:04.0000] <scfe>
basically I want to make sure that my new tool outputs (roughly) the same html as some external legacy tool.

[04:57:02.0000] <scfe>
The upstream tool generates html (mostly "not crazy") with conditional comments, some embedded style tags etc.

[04:57:29.0000] <scfe>
however this is html not xml so many xml differs won't work

[04:58:43.0000] <scfe>
so basically it'd like to answer the question "is this html document (almost) the same as some other document" and I probably need some hooks to do "custom stuff" (e.g. compare CSS rules)

[04:59:12.0000] <annevk>
I guess I'd try to write something from scratch that takes two trees and compares them and outputs/breaks on differences and then modify it as I go

[04:59:20.0000] <scfe>
the library I'm looking for should take care of the html rules (e.g. disregard ordering of attributes, optional closing tags, ...)

[04:59:23.0000] <annevk>
Assuming you have two parsed trees

[04:59:41.0000] <scfe>
annevk: yes, html5lib (and others) can parse my html.

[05:00:30.0000] <scfe>
writing more or less from scratch is also one of my ideas but then I considered all the edge cases and I hope there is some library which does this. I mean comparing generated html should be a pretty common task, no?


2020-06-09
[20:45:34.0000] <MikeSmith>
wait, bz left Mozilla?

[20:47:43.0000] <MikeSmith>
oh wow, at Apple since March

[03:06:56.0000] <tobie>
A while back, a few folks at WHATWG suggested renaming master branch to something else. I pushed back (gently), arguing the metaphor was that of master copy (from the music industry/pre printing press copyists). It turns out I was wrong, and the name does comes from the master/slave metaphor, which makes it both racist and frankly, not a very good metaphor (see

[03:06:56.0000] <tobie>
https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html). So apologies for the misdirection back then.

[03:11:34.0000] <tobie>
The link is:  https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html (in case your client got mixed up with parentheses as badly as mine did).

[03:14:04.0000] <annevk>
Thanks for finding that. I guess the question now is whether to wait for the Git community to find a new recommended default or for each repository to figure out a migration story

[03:20:09.0000] <annevk>
zcorpan: ^^ you might want to follow-up with the folks who a full year after that thought they were somehow in the clear

[03:21:56.0000] <zcorpan>
tobie: thank you

[03:31:20.0000] <zcorpan>
annevk: there is also work started to change the name in git, see https://twitter.com/DEGoodmanWilson/status/1269931737515282438 and https://github.com/git-for-windows/git/issues/2674

[03:36:41.0000] <annevk>
zcorpan: I saw some of that, it's probably worth waiting a bit to see if those efforts pan out

[03:39:14.0000] <zcorpan>
annevk: I can ask Don

[09:11:09.0000] <annevk>
Domenic: it seems we somehow still have a legacy way to integrate Travis with GitHub, right? At least elsewhere the Travis results show up in some kind of GitHub tab

[09:11:51.0000] <Domenic>
annevk: yeah quite possibly; I'm rather confused by all the changes these days.

[09:12:19.0000] <annevk>
Domenic: we might have looked at this before, https://docs.travis-ci.com/user/migrate/legacy-services-to-github-apps-migration-guide/ was a purple link for me

[09:12:30.0000] <annevk>
also, yes

[09:13:15.0000] <annevk>
Ah, https://github.com/whatwg/meta/issues/96

[09:13:20.0000] <Domenic>
I think part of the issue is travis-ci.org vs. travis-ci.com

[09:14:02.0000] <Domenic>
But when I go to https://travis-ci.org/account/repositories where it prompts me to consolidate it says "Sign up for the beta" (of having everything on .com) so my instinct is to not do anything yet if it's still beta.

[09:16:32.0000] <annevk>
Okay, I'm going to reopen that issue though

[11:14:25.0000] <ondras>
please forgive me re-asking once more

[11:14:27.0000] <ondras>
so, is there a way to find out whether a randomly encountered <script> is already loaded? even if its onload was alteady executed, i.e. i am visiting it post-load?


2020-06-10
[18:01:11.0000] <nbenner>
I hope I'm not bringing up old headaches for anyone. I know that navigator.registerContentHandler() has been removed from the spec for some time due to lack of implementation/interest. The github discussion about removing them from the standard ends rather abruptly and I couldn't find any open discussion about whether a newer or perhaps better method (as part of fetch as suggested by jscinoz) was in the works? If this is not the

[18:01:11.0000] <nbenner>
right place to ask this I apologize.

[18:15:49.0000] <nbenner>
also @ondras do this solve your problem? https://developer.mozilla.org/en-US/docs/Web/API/Document/scripts it says it lists all the ones from <script> tags. I'm not sure if it includes ones added through module dynamic import or not

[19:35:24.0000] <alystair>
https://github.com/whatwg/html/issues/5625 my first issue! :D

[19:47:26.0000] <MikeSmith>
Is sandbox intended to be used on top-level browsing context? What would be the use case?

[19:49:11.0000] <MikeSmith>
The OP of https://stackoverflow.com/questions/62289103/identical-urls-yet-still-get-cross-origin-request-blocked-the-same-origin-polic has it set, via a CSP header, on the document at https://egbert.net/

[19:52:16.0000] <MikeSmith>
... and I’m wondering if they have it set for some specific reason or whether they’re instead using it due to maybe a bit of over-zealousness in attempting to specify a sort of “maximum security” CSP policy (without really understanding the consequences)

[21:40:06.0000] <annevk>
nbenner: there's some kind of proposal for file handlers somewhere, iirc

[22:44:45.0000] <ondras>
nbenner: thanks, will have a look!

[22:45:33.0000] <ondras>
nbenner: but this list may contain also scripts that are being loaded, right?

[22:45:52.0000] <ondras>
nbenner: I am looking for a way to detect whether a given particular <script> is fully loaded

[10:19:41.0000] <Domenic>
MikeSmith: I think there are valuable protections sandboxing can give even to top-level BCs, but I'm not aware of the concrete use cases...

[12:57:27.0000] <annevk>
MikeSmith: Domenic: you could use it for content you trust less, though generally I guess you should host that on another domain

[16:48:19.0000] <andreubotella>
so, I was checking the spec on <input type=file>, and saw that it says that file names must not contain path components, which are parts of a filename separated by '\\'

[16:48:34.0000] <andreubotella>
I understand the windows bias, but shouldn't that be '\\' or '/', for completeness?


2020-06-11
[22:42:10.0000] <annevk>
andreubotella: there’s a fakepath serialization that uses backslashes; is it about not confusing that perhaps? Too long ago to recall full history here

[22:43:20.0000] <annevk>
andreubotella: there’s an issue against the File API about what a name of a File can be and this does sound relevant for that; I guess I should take a look later

[23:57:01.0000] <andreubotella>
annevk: I wasn't talking about the fakepath serialization, but I guess there's some historical context with old scripts that assumed windows paths

[23:57:35.0000] <andreubotella>
annevk: it's not confusing, I just wanted to cover all the bases

[00:18:32.0000] <annevk>
andreubotella: I was correct: 'Since path components are not permitted in file names in the list of selected files, the "\fakepath\" cannot be mistaken for a path component.'

[00:19:18.0000] <annevk>
andreubotella: but I wonder if this is properly enforced now that we allow setting .files; I guess I need to check it now

[00:39:08.0000] <andreubotella>
annevk: if you haven't checked yet, the File constructor replaces '/' with ':' but somehow not '\\'

[00:39:09.0000] <andreubotella>
hmm

[00:39:22.0000] <andreubotella>
gonna file that issue

[00:40:53.0000] <annevk>
andreubotella: there's an issue for replacing / with :

[00:40:59.0000] <annevk>
andreubotella: but yeah, thanks

[00:41:06.0000] <annevk>
andreubotella: I guess this needs some changes

[00:41:58.0000] <andreubotella>
annevk: #41, right?

[00:42:11.0000] <annevk>
andreubotella: hai

[02:54:19.0000] <annevk>
domfarolino: diff view should be good again, but requires pushing a fresh commit of sorts

[07:52:31.0000] <annevk>
Domenic: I should probably file an issue on this somewhere, but the one weird thing with some of our specs not using pure Bikeshed is that PR Preview looks at the wrong thing; and I think this goes for HTML to some extent as well by it invoking wattsi rather than the build scripts

[07:53:11.0000] <annevk>
I haven't really seen it manifest in concrete issues which is why I haven't bothered with it much so far

[07:53:22.0000] <Domenic>
annevk: we have an issue for HTML. What do you mean about not using pure Bikeshed?

[07:54:35.0000] <annevk>
Domenic: e.g. Streams has some ec-markup, right? Encoding generates some other files on the side. I think one or more specs have some images that wouldn't end up being diffed

[07:54:56.0000] <Domenic>
Streams is getting fixed

[07:54:56.0000] <annevk>
(and also wouldn't be hosted on whatpr)

[07:55:06.0000] <Domenic>
Images and other files, yeah, I see

[08:07:37.0000] <Domenic>
annevk: any better ideas than "The URL(s) of the resource(s) linked is (are) given by the href or imagesrcset attributes?" :-/

[08:10:16.0000] <annevk>
"The URLs of linked resources are given by the href and imagesrcset attributes." maybe? That they're mutually exclusive comes next

[08:12:01.0000] <Domenic>
They're not mutually exclusive though...

[08:12:04.0000] <Domenic>
COmmenting.

[08:20:27.0000] <annevk>
Domenic: yeah, sorry, I meant that we should require that either, in a non-exclusive way, is present

[09:00:12.0000] <Domenic>
https://streams.spec.whatwg.org/ is now done in Web IDL \o/

[09:01:20.0000] <rmn_>
Hi all, I am confused reading a particular statement that is part of the WHATWG's HTML 5 standard specification, the one that goes "parent has an element child, child is a doctype, or child is non-null and a doctype is following child.", point 6 at https://dom.spec.whatwg.org/#concept-node-ensure-pre-insertion-validity

[09:01:20.0000] <rmn_>
As part of implementing the "ensure pre-insertion validity" procedure, I am unsure whether the statement quoted above should be understood as "(parent has an element child _and_ child is a doctype) or (child is non-null and a doctype is following child". Can anyone please assist me here?

[09:04:16.0000] <Domenic>
rmn_: I think you'll get the best answer if you file the issue on the specification issue tracker, i.e. https://github.com/whatwg/dom/issues

[09:04:43.0000] <Domenic>
Probably that text should be rewritten to be easier to tell the intended meaning

[09:05:35.0000] <rmn_>
Thank you, I will create an issue about this.

[09:41:58.0000] <aselman4>
Hello Everyone, i am encountering a scenario that im having a hard time find a solution for. the scenario is as follows. 1) browser makes simple request to backend server to login 2) backend server responds with redirect to ADFS server 3) ADFS server responds with redirect to backend server 4) backend server return user token

[09:44:13.0000] <aselman4>
i dont have any control over the ADFS server so i cant make it send CORS related headers but i do have control over the backend server. i was thinking that if i could manually follow the redirects then at the last step i can make a CORS request and the response body/headers would be available.

[09:45:04.0000] <aselman4>
i read though issues #601 and #763 but there doesnt seem to be way. Anyone here have any ideas?

[10:15:17.0000] <annevk>
Domenic: "The current PR, where "cleans up after running script" happens after potentially reporting errors, supports Gecko's behavior (microtask checkpoint after both error events)." I'm not sure I follow

[10:15:31.0000] <annevk>
Domenic: the error events are dispatched promise a microtask, right?

[10:15:52.0000] <annevk>
s/promise/from/

[10:16:12.0000] <Domenic>
annevk: hmm, right...

[10:16:31.0000] <Domenic>
Argh

[10:16:45.0000] <annevk>
I did try to point it out

[10:16:55.0000] <annevk>
But yeah, I myself got confused a few times as well

[10:16:56.0000] <Domenic>
You did, I just didn't understand

[10:17:00.0000] <Domenic>
OK, I'll edit

[11:21:17.0000] <Domenic>
annevk: are we ready to do the secure context refactoring now?

[11:27:17.0000] <TimothyGu>
annevk: thanks for adding me to Web IDL :)

[11:28:10.0000] <TimothyGu>
though hmm, I don't think I have access yet…

[11:30:27.0000] <TimothyGu>
ah I need to click the big green button

[11:47:59.0000] <Domenic>
Well deserved :)

[12:45:12.0000] <annevk>
Domenic: yeah

[12:45:23.0000] <annevk>
TimothyGu: all you 👍🏻

[12:45:33.0000] <Domenic>
annevk: great, I'll try to chip in after I figure out window.originIsolated

[12:46:52.0000] <TimothyGu>
annevk: how does editorship work for Web IDL? Should I just send a PR adding my name

[13:28:15.0000] <annevk>
TimothyGu: yeah


2020-06-12
[17:04:32.0000] <nbenner>
ondras: I think the accepted way to do that is to check for side effects. If the script you're attempting to check defines an object (lets say foo) and you don't know if that file has loaded yet, check to see if foo exists on the page. if it does then the script is probably done executing, or at least has yielded control...

[00:27:24.0000] <ondras>
nbenner: ok thanks

[07:58:12.0000] <domfarolino>
What's an easy way to call fetch() and have the promise resolve to a response whose type is "error" (things like 404 / CORS failures don't give me what I want)

[08:22:19.0000] <Domenic>
domfarolino: fetch("bad-url:bad")

[08:23:28.0000] <domfarolino>
Domenic: That seems to just reject the promise though, instead of resolve with an error response right?

[08:23:39.0000] <Domenic>
domfarolino: network errors always reject the promise

[08:23:47.0000] <domfarolino>
I see, that's what I wasn't sure about

[08:23:51.0000] <Domenic>
Gotcha

[08:24:00.0000] <domfarolino>
Domenic: OK so it's impossible to assert (request.type == error) in a fetch() then handler?

[08:24:07.0000] <Domenic>
Yeah

[08:24:11.0000] <domfarolino>
Cool ty

[08:24:49.0000] <Domenic>
I guess type === error is only possible for manually-constructed responses

[08:24:50.0000] <domfarolino>
Ah, yeah "If response is a network error, then reject p with a TypeError and terminate these substeps."

[08:24:56.0000] <domfarolino>
Domenic: right

[08:25:16.0000] <domfarolino>
Response.error() for example

[09:16:42.0000] <jugglinmike>
Anyone here familiar with Cross-Origin Opener Policy? I'm having some trouble understanding a document from a Chromium dev https://docs.google.com/document/d/1zWqwI8PFrezwQpBSejIMUfdtsIYl9-h8epasdrDXVIM

[09:39:18.0000] <Domenic>
annevk: double-check me... shared/service worker agents are not owned by anything in the spec? They're just allocated and kind of float freely?

[09:39:27.0000] <Domenic>
s/agents/agent clusters

[10:24:56.0000] <annevk>
Domenic: yeah, technically the user agent needs some kind of lookup table

[10:25:17.0000] <annevk>
Domenic: but they are directly owned by the user agent

[10:25:53.0000] <annevk>
although their lifetime is impacted by "related" browsing sessions closing

[10:26:14.0000] <annevk>
or documents/window agents I guess, not so much browsing sessions

[10:46:14.0000] <Domenic>
OK cool, that's about what I thought. I guess nailing that down would be a bit of a pain so leaving things as-is is OK.

[10:47:12.0000] <annevk>
Domenic: we have a lot of things today that'll make it easier to do once there's a stronger need

[10:48:13.0000] <annevk>
I think the more problematic thing with workers is that we establish an environment before we fetch

[13:36:26.0000] <jugglinmike>
Domenic: I'm a bit confused about the intention for SharedArrayBuffer and COOP/COEP

[13:37:28.0000] <jugglinmike>
I used to think SAB was to be exposed always but only allowed for transfer in crossOriginIsolated contexts

[13:37:34.0000] <jugglinmike>
Like here https://github.com/whatwg/html/pull/4734

[13:38:30.0000] <jugglinmike>
But I've recently read things that suggest that SAB will simply not be available outside of crossOriginIsolated contexts

[13:38:47.0000] <jugglinmike>
like here https://web.dev/why-coop-coep/

[13:42:43.0000] <jugglinmike>
That second source is more recent and matches Firefox's current behavior

[13:43:34.0000] <jugglinmike>
But work is proceeding on the first

[13:45:36.0000] <jugglinmike>
Ah

[13:45:48.0000] <jugglinmike>
"SharedArrayBuffer objects are in principle always available, but unfortunately the constructor on the global object is hidden, unless the two headers mentioned above are set, for compatibility with web content. There is hope that this restriction can be removed in the future. WebAssembly.Memory can still be used to get an instance."

[13:46:12.0000] <jugglinmike>
via https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer/Planned_changes

[13:48:51.0000] <jugglinmike>
So I guess the web.dev post is technically inaccurate, but explaining the distinction is unlikely to help anyone

[13:57:54.0000] <Domenic>
Right, it kind of depends on whether you're talking about SharedArrayBuffer, or "shared array buffers"

[14:01:32.0000] <jugglinmike>
ah, yeah, that's subtle

[14:02:55.0000] <jugglinmike>
This one uses the term "threaded SharedArrayBuffer" https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k/edit#

[14:04:32.0000] <jugglinmike>
"SharedArrayBuffer sharing" would likely raise some eyebrows

[14:07:27.0000] <jugglinmike>
Stage 0 proposal: "Rename SharedArrayBuffer to PotentiallyShareableArrayBuffer"


2020-06-14
[18:59:35.0000] <gsnedders>
does anyone recall why we resolved <p><table> in favour of having a parser-quirk rather than changing Acid2? Because we'd had interop on that for four years since Acid2?

[22:31:05.0000] <annevk>
gsnedders: https://lists.w3.org/Archives/Public/public-html/2008Mar/0025.html touches it

[01:40:53.0000] <annevk>
domfarolino: could you please look into https://github.com/whatwg/console/issues/152?

[09:29:49.0000] <domfarolino>
annevk: will do later


2020-06-15
[06:53:54.0000] <annevk>
domfarolino: thanks!

[06:56:43.0000] <noamr>
Hi annevk! I'm not seeing responses on the cross-origin EXIF concern (https://github.com/w3c/csswg-drafts/issues/5173), so I'm feeling blocked with EXIF resolution (https://github.com/whatwg/html/pull/5574). any suggestions?

[07:00:40.0000] <annevk>
noamr: reach out to implementers?

[07:01:38.0000] <noamr>
annevk: Chrome and WebKit said yes on github. I'm planning to write the patches for both.

[07:03:03.0000] <annevk>
noamr: to my solution for addressing the cross-origin leak?

[07:03:28.0000] <annevk>
noamr: or how to reorganize how we deal with images?

[07:03:47.0000] <noamr>
ah, no. they responded to the EXIF-resolution thingy.

[07:08:17.0000] <noamr>
oh ok I see - you wanted to have the issue more blocked on the general "images on the web" issue rather than on the cross-origin issue. I got those two issues mixed up. I'll see if I can ping some people at Blink/webkit to pitch in on https://github.com/w3c/csswg-drafts/issues/5173

[07:10:45.0000] <annevk>
noamr: well both are important, but the security one we should have an answer one at least as that impacts tests and impl and observable behavior

[07:12:28.0000] <noamr>
annevk: I believe it doesn't impact observable behavior, tests and implementation for EXIF-resolution, as it's not yet exposed/overridable (until we implement CSS image-resolution).

[07:13:08.0000] <annevk>
noamr: but we couldn't add that point decide on a change of model

[07:13:15.0000] <annevk>
at that point*

[07:19:49.0000] <noamr>
you mean for the cross-origin issue? Seems like there was some consensus on that, at least between the three people that commented on the issue.

[07:19:49.0000] <noamr>
I'm not sure how to put it into the spec though - currently the EXIF resolution proposal doesn't expose that metadata, unlike https://github.com/whatwg/html/pull/5603, so I don't know how to add a clause that says that that information should not be exposed for opaque resources...

[07:20:45.0000] <annevk>
noamr: fair; I guess what I'm looking for is agreement from WebKit/Blink on the model

[07:21:21.0000] <annevk>
noamr: well, and it does impact orientation so it does impact existing implementations and they might want something else therefore; which is why having this be a bit more explicit would help

[07:21:46.0000] <annevk>
It's important to keep the whole picture in mind

[07:22:13.0000] <noamr>
it affects future implementation as currently orientation is also an implementation detail (not exposed via CSS or attributes)

[07:23:06.0000] <noamr>
(CSS image-orientation is not a thing yet)

[07:23:13.0000] <annevk>
noamr: image-orientation:none is a thing afaik

[07:24:24.0000] <noamr>
hmm ok then. thanks annevk

[09:24:06.0000] <rosenjcb>
So I was reading over the first version of the DOM spec and I notice that the entire thing is defined with interfaces and an "object oriented" approach. Though in the article "What is the Document Object Model?", it says that "[The DOM] can be implemented in any computing environment and does not requrie the object binding runtimes generally associated with such IDLs." Does that mean we don't even necessarily need to use an OO

[09:24:07.0000] <rosenjcb>
approach? Could my DOM just be data structures and free functions?

[09:35:32.0000] <domfarolino>
annevk: Could you give a review for the iframe lazyload PR? I think it's ready to be thoroughly reviewed, and personally I'd like to get it in soon if at all possible

[09:44:14.0000] <annevk>
domfarolino: not sure about this week, but next week starting Tuesday is probably doable

[09:44:20.0000] <domfarolino>
Thanks

[09:47:17.0000] <Domenic>
annevk: any thoughts on https://github.com/WICG/origin-isolation/issues/24#issuecomment-643507493 ? I'm unsure myself.

[09:48:03.0000] <annevk>
Domenic: continuing to return false seemed reasonable to me, despite the slight complexity increase

[09:48:28.0000] <Domenic>
OK, sounds good, so sticking with (2).

[09:49:54.0000] <annevk>
In particular given the idea that we only want to convey differences to the agent cluster boundary and document.domain (neither of which would change)

[09:52:18.0000] <Domenic>
Yeah, I mean the alternative with (3) is conveying "did you send the header and not get it overwritten by a previous header in the BCG". But probably conveying differences in agent cluster boundary is more useful.

[10:04:23.0000] <annevk>
Domenic: I ran my window.find() test in Chrome and it works there

[10:04:36.0000] <annevk>
Domenic: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A...test%0A%3Cscript%3E%0Aw(window.getSelection())%0Awindow.find(%22test%22)%3B%0Aw(window.getSelection())%0A%3C%2Fscript%3E

[10:04:36.0000] <Domenic>
annevk: oh no, is it platform-dependent too?

[10:04:39.0000] <Domenic>
I wish I had my Mac

[10:05:16.0000] <annevk>
Domenic: could be, but it works in Chrome/Firefox/Safari

[10:05:27.0000] <Domenic>
annevk: ah I see, I think focusing devtools changes window.getSelection() in Chrome but not in Firefox

[10:05:39.0000] <annevk>
Domenic: first logs Selection "", then Selection "test"

[12:23:26.0000] <domfarolino>
Domenic: regarding https://github.com/whatwg/html/pull/5579#issuecomment-644308355, did you mean changing the “referrerpolicy” attr shouldn’t cause a refetch

[12:23:49.0000] <Domenic>
domfarolino: ugh yes, I got it backward again. Will edit...

[12:24:47.0000] <Domenic>
Interesting, I guess that makes it slightly more consistent with iframes...

[13:01:44.0000] <domfarolino>
Domenic: Gotcha. I think I said it will cause a refetch because chrome’s memory cache also uses the referrerpolicy as a memory cache key (but technically that’s not specified)

[15:00:04.0000] <domfarolino>
Domenic: if you want we can hold off on merging

[15:00:17.0000] <domfarolino>
Domenic: If you want to add notes that point to the spec discussoin around the parser document checks

[15:00:28.0000] <domfarolino>
I'm fine either way though

[15:00:52.0000] <Domenic>
domfarolino: nah, I like merging; no need to present the historical context there I think.

[15:00:59.0000] <domfarolino>
Cool

[15:03:19.0000] <Domenic>
Very excited to close that off!

[15:03:33.0000] <Domenic>
Less cross-document script execution is better for everyone...


2020-06-16
[18:02:33.0000] <domfarolino>
Yeah, that resolved some pretty old stuff it seems!

[03:26:39.0000] <zcorpan>
What's an example of a feature shipping in one browser, web content using it, then second implementer finds a bug, but the bug can't be fixed because of web compat?

[03:36:31.0000] <Ms2ger>
The Web

[03:38:13.0000] <zcorpan>
Sorry, not specific enough. A somewhat recent (past 10 years) example where there was a specification before the first browser shipping

[03:42:43.0000] <ondras>
"border-radius" ?

[03:44:53.0000] <jgraham>
There are plenty of examples where there was a spec, an implementation shipped, the spec then underwent dramatic changes, and the first implementation continued shipping the old behaviour for web compat reasons (Shadow DOM, Web RTC, etc.)

[04:12:04.0000] <zcorpan>
jgraham: thanks!

[04:12:17.0000] <zcorpan>
ondras: what was the issue with border-radius?

[04:17:59.0000] <ondras>
zcorpan: well it should have been named "corner-radius"

[04:20:37.0000] <zcorpan>
ondras: ah, yeah, but not really the scenario I was looking for. it was shipping as -moz-border-radius and -webkit-border-radius and then border-radius

[04:21:01.0000] <ondras>
yeah true.

[04:21:31.0000] <ondras>
so the proper solution was found long after the non-prefixed version shipped :)

[04:22:06.0000] <zcorpan>
yeah

[04:38:19.0000] <Ms2ger>
Something with gradients? But I guess those were prefixed too

[04:38:42.0000] <Ms2ger>
And WebSockets probably eventually converged on the latest and greatest

[08:43:16.0000] <Domenic>
Any ways to get an opaque origin besides sandbox?

[08:45:46.0000] <annevk>
Domenic: data: URL at least

[08:46:32.0000] <Domenic>
Nice

[08:47:09.0000] <annevk>
Domenic: and once you have one from either, you can create another with a blob URL

[08:47:32.0000] <annevk>
Domenic: although I guess that's going to be the very same opaque origin

[08:47:57.0000] <Domenic>
It'll still have "obtain a site"(origin) = origin, so I should test it

[08:48:05.0000] <Domenic>
(for window.originIsolationRestricted)

[08:48:36.0000] <annevk>
Makes sense

[09:01:34.0000] <Domenic>
annevk: where in the spec does it say data: URL pages are secure contexts?

[09:02:35.0000] <annevk>
Domenic: welcome to my life circa 4 months ago https://github.com/w3c/webappsec-secure-contexts/commit/b3f7d5cc2a2ecb50903efb922a8edfefbe1c5f34

[14:08:46.0000] <MikeSmith>
Domenic: createDocument() will also give you an opaque origin

[14:08:58.0000] <Domenic>
MikeSmith: nice one!


2020-06-17
[21:02:52.0000] <superkuh>
So now that we're saved from strict xhtml and single errors making everything not display can we disband whatwg now? Because now whatwg is worse than the cure pushing dom that's so integrated with JS that a single JS error makes all page contents not display.

[21:03:15.0000] <superkuh>
You've become the thing you were created to stop.

[21:03:49.0000] <superkuh>
And worse, it's all co-opted by mega-corps. At least the w3c never had that happen fully.

[03:33:09.0000] <PiersW>
That's certainly one point of view... But I don't quite understand how a single JS error makes all the page not display, unless JS is dynamically creating the page. Which isn't all that common really, and has been possible for way longer than whatwg has existed.

[05:31:08.0000] <lilltiger>
superkuh: It's in the topic.

[05:31:22.0000] <lilltiger>
"Please leave your sense of logic at the door, thanks!"

[05:31:31.0000] <lilltiger>
=D

[10:05:07.0000] <annevk>
So I ran into two separate cases today where people confused user agent and agent. Should probably link user agent more now that have it defined...

[10:05:17.0000] <annevk>
we have*

[12:08:02.0000] <Domenic>
It seems like if you do iframe.src = iframe.src + "#foo" in browsers this does not cause a second navigation. But I can't find where the spec would bail out early...

[12:18:39.0000] <jgraham>
Domenic: https://html.spec.whatwg.org/#navigating-across-documents:scroll-to-fragid

[12:20:21.0000] <Domenic>
Dangit, it was right there. Thank you jgraham


2020-06-18
[23:06:23.0000] <annevk>
Was it ever discussed to add a then method to IDBRequest?

[06:53:32.0000] <substan[e>
sup

[06:55:00.0000] <annevk>
/me finds https://github.com/inexorabletash/indexeddb-promises/issues/7

[06:55:25.0000] <substan[e>
how are you folks

[06:55:50.0000] <substan[e>
im looking at xhr.spec.whatwg.org - reading abuot using xmlHTTPreq

[06:55:58.0000] <substan[e>
isnt this all redone, better, in jquery???

[06:57:11.0000] <annevk>
substan[e: how do you think jQuery works?

[06:57:20.0000] <substan[e>
I know its based off xmlhttpreq

[06:57:25.0000] <substan[e>
isnt it a 'front end' to doing it the old way?

[06:57:28.0000] <substan[e>
/me is kinda new to this. sorry

[06:57:47.0000] <substan[e>
didnt jq summarizse alot of work with this stuff with like gets() puts() ???

[06:57:58.0000] <annevk>
Although I suppose jQuery could use fetch() these days, I don't really know

[06:58:07.0000] <substan[e>
How do you code socket stuff

[06:58:13.0000] <substan[e>
do you do it using xmlHTTPreq?

[06:58:15.0000] <substan[e>
or with jq?

[06:58:26.0000] <substan[e>
(my friend told me forget about xmlhttpreq and only learn jq)

[06:58:28.0000] <substan[e>
is that wrong?

[06:58:52.0000] <annevk>
substan[e: what do you want to learn?

[06:58:59.0000] <substan[e>
basically.

[06:59:09.0000] <substan[e>
im learning nodeJS on the side.  but i want to learn client side JS first

[06:59:22.0000] <substan[e>
. i want ot understand how to open a socket for reading or a RESTful API call or something

[06:59:25.0000] <substan[e>
to another one of my servers

[06:59:35.0000] <substan[e>
.. i understand XML or json is how i would send/format the data. right?

[07:00:32.0000] <annevk>
substan[e: you could learn jQuery for that I suppose, but you might as well start with https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch and avoid a dependency on a library

[07:00:43.0000] <substan[e>
really?

[07:01:07.0000] <substan[e>
.. i totally will. i want to understand how its workin fully, before using something that makes it work w/o knowin whats happening rihgt?

[07:02:20.0000] <Domenic>
annevk: for "_bc_'s WindowProxy's [[Window]] value", do you prefer "active window", "active `Window`", "current window", or "current `Window`"? Or other?

[07:02:54.0000] <substan[e>
annevk: you seem like you know whats up. i wrote my page https://tranceattic.com in vim/notepad++ with jquery.. if you let it load and inspect element i cant figure out where or how to fix these console errors

[07:03:16.0000] <substan[e>
there is only like 2 main ones.. Uncaught Type error cant acces prop "defaults"

[07:03:29.0000] <substan[e>
but to the right . its not listing a file i am fam. with it says :  line 1 > scriptElement

[07:03:45.0000] <substan[e>
.. i have a feeling this has to do with the ordering of loading my JQ/BS js / css scripts.

[07:03:46.0000] <annevk>
Domenic: I suppose active window, though I'm not sure why active document isn't enough

[07:05:26.0000] <annevk>
substan[e: I recommend using StackOverflow or some IRC equivalent

[07:06:20.0000] <substan[e>
kk will do. im readin that doc now. i appreciate it

[07:06:22.0000] <substan[e>
mind if i idle here?

[07:06:57.0000] <annevk>
subz: not at all

[07:07:16.0000] <subz>
thx.. id like to actaully hang in an irc channel where people discuss code [and the topic of the channel[

[07:07:30.0000] <subz>
and not like efnet. where everychannel is #polotics or #whatihadforbreakfast ;p

[07:08:03.0000] <subz>
annevk: are you into any nodeJS?

[07:20:47.0000] <andreubotella>
annevk: So in encoding#215 it was bugging me a bit that token queues were defined as simple data structures with no reference to I/O, and I think I've come up with a simple-ish way to make the definition reflect reality

[07:21:51.0000] <annevk>
andreubotella: that sounds interesting

[07:22:13.0000] <andreubotella>
annevk: Have each token in a token queue be one of "immediate" or "blocking", specifying that reading blocking tokens might block, and say something like "all tokens created by this spec are immediate, but blocking tokens can be created through implementation-defined ways"

[07:22:32.0000] <andreubotella>
And now we can define "wait" (as in BOM sniff)

[07:23:28.0000] <annevk>
andreubotella: and read would also have to wait?

[07:23:57.0000] <andreubotella>
there's a comment in the source saying that read would block, and to blame SimonSapin if that was a problem

[07:24:51.0000] <annevk>
andreubotella: heh, that was written a long time ago, but other than that HTML issue that you largely solved it hasn't really come up I think

[07:25:06.0000] <annevk>
so maybe it was not a problem

[07:26:12.0000] <andreubotella>
I don't think there are any cases where implementations can't make read async

[07:26:31.0000] <SimonSapin>
andreubotella: source for what?

[07:26:35.0000] <annevk>
andreubotella: but yeah, it might make sense for the queue to return "nothing available" and "end-of-stream" as distinct in certain cases

[07:26:43.0000] <andreubotella>
SimonSapin: the encoding spec

[07:27:04.0000] <andreubotella>
https://github.com/whatwg/encoding/blob/master/encoding.bs#L110

[07:27:17.0000] <annevk>
I suspect this was written when we shared an open office space SimonSapin, git blame can prolly verify

[07:27:48.0000] <SimonSapin>
I have no memory of this ^^'

[07:28:13.0000] <annevk>
Seems it was committed six years ago and 3 years ago I changed curse to blame :p

[07:28:47.0000] <SimonSapin>
haha

[07:29:17.0000] <annevk>
Hmm, PR Preview is not picking up changes

[07:29:23.0000] <SimonSapin>
Yeah March 2014 is when we were in the same office I think

[07:31:06.0000] <andreubotella>
in any case, I'm gonna have to take a good look at every time that read is called just in case

[07:51:21.0000] <subz>
its great to see acitivty in an irc channel ;p

[07:51:25.0000] <subz>
(efnet = ded)

[08:04:28.0000] <andreubotella>
subz: this channel isn't quite dead, but usually there isn't a lot of activity, especially on the weekends and European late nights and mornings

[09:51:58.0000] <annevk>
tobie: if you're around, https://github.com/whatwg/url/pull/518 is not getting updated by PR Preview and I've noticed this in several PRs now; we have switched to GitHub Actions but that's not something that PR Preview should be concerned with, right?


2020-06-19
[02:01:08.0000] <yhirano>
annevk: do you have further comments on https://github.com/whatwg/html/pull/5454?

[09:58:34.0000] <Domenic>
annevk: I think we could merge COOP + COEP today if you're available :)


2020-06-20
[15:34:12.0000] <innovati>
Is there a way in HTML to declare buttons or other elements to act as controls for an Audio or Video tag?


2020-06-22
[14:21:17.0000] <domfarolino>
Does removing a content attribute set an element's enumerated attr back to the default state? I.e., if there's an image whose loading=lazy, and I removeAttribute('loading'), does https://html.spec.whatwg.org/multipage/embedded-content.html#the-img-element:attr-img-loading-2 get triggered?

[14:22:26.0000] <domfarolino>
I think it does, but want to be sure

[14:39:40.0000] <Domenic>
domfarolino: it changes it to the missing value default state

[14:39:59.0000] <domfarolino>
Domenic: perfect, thanks


2020-06-23
[21:04:27.0000] <domfarolino>
annevk: if there's any chance you'd have time for the lazy load PR review today that'd be great

[00:09:42.0000] <MikeSmith>
TabAtkins: FYI and FWIW, out of the 275 specs for the web platform that have documentation in MDN, 216 of them are published using Bikeshed

[00:23:58.0000] <ondras>
~/w 36

[00:24:01.0000] <ondras>
sorry

[01:01:21.0000] <annevk>
domfarolino: tomorrow at the earliest, taking some time off

[01:32:59.0000] <MikeSmith>
TabAtkins: oops, that count was off a bit; it’s actually 158 published-using-Bikeshed specs, out of 275 total


2020-06-24
[23:29:20.0000] <MikeSmith>
very nice to see a lot of new activity going on for implementing streaming upload support in Blink

[23:29:23.0000] <MikeSmith>
https://bugs.chromium.org/p/chromium/issues/detail?id=688906

[06:20:23.0000] <annevk>
So localhost gives a secure context, but can you use HTTP/2 and up with localhost without a certificate? I guess not?

[06:36:36.0000] <superkuh>
Oof. That'd be a huge oversight.

[07:38:41.0000] <annevk>
I'm not sure it's an oversight, but it's certainly inconvenient and makes the use (.)localhost domains for testing story a bit flawed

[07:40:06.0000] <superkuh>
Reflects the commercial-centric nature of whatwg spec ignoring other uses.

[07:44:09.0000] <annevk>
I don't think any of that is really defined in WHATWG standards, although there's a PR against HTML to define some aspects of secure contexts there (though not these bits)

[08:18:50.0000] <annevk>
domfarolino: I think it looks good, modulo srcdoc; ecobos: could you maybe take a look at https://github.com/whatwg/html/pull/5579 too? It's not too long

[08:19:55.0000] <domfarolino>
whoah did github massively overhaul its UI like overnight?

[08:19:59.0000] <domfarolino>
annevk: Thanks!!

[08:21:11.0000] <annevk>
domfarolino: I can confirm that things look different from before the weekend

[08:22:23.0000] <domfarolino>
annevk: I agree with your comment about srcdoc, I just think we need to figure out whether we want the spec to support it or not. I guess you're leaning towards spec'ing it to work there though?

[08:23:34.0000] <annevk>
domfarolino: I could see it being a follow-up I suppose if it's indeed much more impl work; need ecobos's expertise

[08:23:50.0000] <domfarolino>
Gotcha

[08:25:56.0000] <ecobos>
annevk: hmm, do subresources in a srcdoc document already block the embedder document's load event?

[08:27:05.0000] <ecobos>
annevk: As in, if I load a slow stylesheet after the srcdoc's load event fires, but before the embedder's load event fire, will it block the embedder's load event?

[08:27:10.0000] <ecobos>
annevk: that sounds unexpected to me

[08:27:40.0000] <ecobos>
annevk: and otherwise I don't see why we shouldn't support srcdoc

[08:28:08.0000] <ecobos>
annevk: domfarolino: It's the same as for data: uris, it doesn't save bandwidth, but it is consistent with everything else

[08:28:57.0000] <domfarolino>
ecobos: Makes sense, I can add support for that to the spec

[08:30:37.0000] <annevk>
ecobos: I would expect srcdoc="<img src=thisblocks>", post srcdoc document load event I would not expect any blocking

[09:12:46.0000] <Domenic>
annevk: so we can land COOP (https://github.com/whatwg/html/pull/5334)?

[09:14:11.0000] <annevk>
Domenic: with caveats, yes

[09:15:36.0000] <Domenic>
OK, great.

[09:15:51.0000] <Domenic>
After my next meeting I will work on merging and rebasing everything around it and filing followups for those

[09:24:42.0000] <annevk>
I'll get to COEP tomorrow I suspect

[10:28:18.0000] <Domenic>
annevk: when going to merge COOP I found the list of potentially-closed issues. Do you know which of 4921, 5168, and 5198 we should leave open?

[10:41:04.0000] <alystair>
I'm wondering, with <template> why wasn't a pure HTML usage method done that uses shadow DOM, similarly to SVG's symbol/defs/g

[10:41:39.0000] <alystair>
something like a <use template="id"> void element :D

[10:42:12.0000] <annevk>
Domenic: looking

[10:43:39.0000] <alystair>
there are definite use cases for static, yet repeated elements, such as social media links in head/footer.

[10:44:29.0000] <annevk>
Domenic: I guess I'd leave the latter two open for additional review

[10:44:50.0000] <annevk>
which will be easier to do once things are merged

[10:44:52.0000] <Domenic>
annevk: OK cool, that's where I landed

[10:45:03.0000] <Domenic>
annevk: on HTTPS state... it seems like we should move that up to environment?

[10:45:10.0000] <Domenic>
It's currently on environment settings object :(

[10:46:09.0000] <annevk>
Domenic: it can't be on environment, you only know it after you have a connection, which I guess is arguably before you have a response, but I'm not sure implementations distinguish the two at the app level (and I'm not sure we should)

[10:46:27.0000] <Domenic>
Hmm OK

[11:33:55.0000] <Domenic>
The new GitHub UI makes our "topic" label color contrast terrible :(.

[11:40:33.0000] <jugglinmike>
Domenic: I'm having trouble understanding the implications of a change to Fetch for CORP/COEP https://github.com/whatwg/fetch/pull/1030/files#diff-e8c7e042697e1e48e4466c612dda6a3bR4617

[11:43:21.0000] <Domenic>
jugglinmike: probably best to ask the PR author?

[11:44:53.0000] <jugglinmike>
Definitely. Time zones will make for a delay, but I can be patient :)

[11:47:40.0000] <Domenic>
So far I've mostly managed to understand the HTML side of things, treating Fetch as more of a black box...

[11:49:12.0000] <jugglinmike>
I'd appreciate understanding either side--this is a pretty complicated feature

[11:54:41.0000] <Domenic>
Well, happy to help with any questions about the HTML side---except for where they call into Fetch :)

[11:54:51.0000] <Domenic>
(or Fetch calls into them)

[11:55:14.0000] <jugglinmike>
Thanks! I may take you up on that

[11:55:43.0000] <jugglinmike>
I'm trying to draw out the testing surface for COOP/COEP and reconcile it with what's already been done in WPT


2020-06-25
[00:17:09.0000] <annevk>
jugglinmike: https://github.com/web-platform-tests/wpt/issues/18354 might help, though it hasn't been maintained so maybe it's not that useful...

[03:05:29.0000] <annevk>
littledan: Looking at https://html.spec.whatwg.org/#fetch-a-single-module-script the logical place to enforce the type is before you create a module script. What HTML PR 5658 seems to do is to always respect the server in terms of what to create, which creates the problem that if I import something as JSON and it declares itself as JavaScript, it'll get to fetch further subresources. Or am I misunderstanding something?

[03:08:31.0000] <annevk>
Ah no, I guess the further fetching doesn't happen

[03:08:50.0000] <annevk>
But the parsing did, which seems weird

[03:23:40.0000] <littledan>
annevk: right, I guess since the failure is in "fetch a single module script", it won't recurse until that succeeds. the intention was to be equivalent to just caching the result of the first fetch without interpreting it (so that it wouldn't be retried if the first type supplied was wrong); I agree that we shouldn't let subresources to be fetched in this case.

[03:23:56.0000] <littledan>
so, no subresource fetching or linking happens until the right type is provided

[03:24:15.0000] <annevk>
The parse itself seems concerning as well though

[03:24:20.0000] <littledan>
another way to word this would be to just cache the MIME type and response body, but it turned out that that was observably equivalent to parsing it and storing it in the map eagerly

[03:24:39.0000] <littledan>
we could rephrase it that other way. i was thinking it might be enough to just write a note explaining that engines could delay the parse if they want to

[03:25:29.0000] <littledan>
or maybe this is observable because you can see the difference between a parse error and a type check error?

[03:26:57.0000] <annevk>
It's a little hard to tell for me what the various observable bits are today and also what they might become as add more parsers into the mix

[03:27:26.0000] <annevk>
as we add*

[03:27:26.0000] <tobie>
annevk: looking into the PR Preview issue.

[03:27:45.0000] <tobie>
annevk: seems to be some authentification issue between the app and GitHub.

[03:27:57.0000] <annevk>
tobie: I tried looking into it myself, but I couldn't really find any recent change that might have done this

[03:28:21.0000] <tobie>
annevk: yeah, it's something that change for an auth perspective.

[03:28:31.0000] <annevk>
tobie: that makes sense as it basically doesn't seem to be picking up anything, despite being authorized in the WHATWG org

[03:28:56.0000] <tobie>
annevk: yes, I'm getting bad credentials all over the place.

[03:29:07.0000] <littledan>
annevk: That makes sense ,thanks for raising this issue

[03:29:21.0000] <tobie>
annevk: a bug in the logger hasn't logged those as errors, which is why I didn't hear about them.

[03:30:09.0000] <annevk>
tobie: a beautiful cascade

[03:30:19.0000] <tobie>
annevk: right?

[03:31:47.0000] <tobie>
annevk: https://developer.github.com/changes/2020-04-15-replacing-create-installation-access-token-endpoint/

[03:31:56.0000] <tobie>
This might be the issue.

[03:32:17.0000] <tobie>
annevk: but they're way ahead of their plans if that's the case

[03:34:22.0000] <annevk>
tobie: yeah, that'd be weird

[03:34:59.0000] <tobie>
annevk: that's what the error I'm getting points to, though.

[03:35:47.0000] <annevk>
tobie: I guess update and maybe let GitHub know? Though you'd think they have a working log themselves

[03:36:11.0000] <tobie>
annevk: yeah, testing first to see if this fixes it.

[03:38:10.0000] <tobie>
annevk: so I'm clearly onto something here.

[03:39:56.0000] <tobie>
annevk: can you give it a spin?

[03:40:03.0000] <tobie>
annevk: please?

[03:40:33.0000] <tobie>
annevk: seems like it's working for me here.

[03:44:18.0000] <annevk>
tobie: will do

[03:44:25.0000] <tobie>
annevk: ty

[03:45:25.0000] <annevk>
tobie: will it pick up PRs without PR Preview annotations if I edit OP?

[03:45:37.0000] <annevk>
I made an edit to https://github.com/whatwg/html/pull/5668 just now

[03:45:42.0000] <tobie>
yes

[03:45:45.0000] <annevk>
Ah, there it is

[03:45:55.0000] <annevk>
😊

[03:45:59.0000] <annevk>
❤️

[03:46:12.0000] <annevk>
Thanks tobie!

[03:46:32.0000] <tobie>
annevk: https://twitter.com/tobie/status/1276103795940958209

[03:46:49.0000] <tobie>
annevk: np

[03:47:04.0000] <tobie>
annevk: filing a couple of bugs to improve the logging for this.

[03:47:53.0000] <tobie>
annevk: and also automate pr-preview going over failed updates when such a problem occurs.

[03:53:26.0000] <tobie>
annevk: https://github.com/tobie/pr-preview/issues/74 and https://github.com/tobie/pr-preview/issues/75

[03:54:29.0000] <annevk>
littledan: note that if you don't cache the parse, you end up parsing redundantly

[05:14:58.0000] <littledan>
annevk: Yeah, the idea is that, if the type mismatches, you cache the response body + MIME type, and the first time it's imported with the type matching, then you replace the cache entry with the parsed module

[05:17:45.0000] <annevk>
littledan: I suppose that might work, even if it's a bit complex; what's the reason to reject Domenic's idea?

[05:20:00.0000] <littledan>
annevk: The core reason is, we've heard from some JS developers that it'd be confusing to "clone" a module just because it's imported with different attributes; some people have the intuition that there's a 1:1 mapping module specifier <-> module.

[05:20:28.0000] <littledan>
in the case of `type`, we in fact have no reason to "clone". So it makes sense to use an import condition, which is just a check.

[05:22:26.0000] <littledan>
so, the intuitions are directly opposite; we just have to choose whether we consider the import conditions to be part of the extended module specifier or not. TC39 got to Stage 2 based on the explicit agreement that they're not part of it, but we could revisit that if needed.

[05:34:09.0000] <littledan>
you can see the concerns expressed, e.g., in this thread https://github.com/openjs-foundation/standards/issues/91

[05:34:39.0000] <littledan>
as well as this one https://github.com/tc39/proposal-import-attributes/issues/30

[05:35:16.0000] <littledan>
we're open to a separate proposal which would provide attributes which *do* form part of the extended specifier; it just seems like a semantically separate feature, and not one that we'd use for non-JS module types

[05:44:58.0000] <littledan>
to me it seems weird to do multiple fetches that are exactly the same, just because the condition applied differs

[05:46:49.0000] <annevk>
littledan: are they exactly the same or do we use Accept in some way?

[05:47:13.0000] <littledan>
the current PR doesn't use Accept in any way. Should we use it?

[05:47:25.0000] <littledan>
this was something I wanted to ask to people who know more about fetch than me

[05:47:35.0000] <littledan>
in various issue threads, people proposed various HTTP headers that would be affected

[05:48:07.0000] <annevk>
littledan: it seems like it might be useful for the server, although on the other hand now that it's effectively managed client-side anyway there's not much need for negotiation

[05:48:14.0000] <littledan>
I can see that that would be a reason to consider it part of the specifier. But I don't see how it's motivated by the initial security issue.

[05:48:25.0000] <annevk>
it's not

[05:48:55.0000] <annevk>
I think it's more something we hadn't really considered about modules in general

[05:49:08.0000] <annevk>
Since it's only fairly recently that we decided to go beyond JS

[05:49:27.0000] <littledan>
if we passed in an Accept header, it would seem important to consider the type part of the specifier, since the server may override the URL to support multiple different module types, and you wouldn't want caching to block access to that.

[05:49:53.0000] <littledan>
however, this may be confusing to JS developers, if they expect the same specifier to always point to the same module

[05:50:47.0000] <annevk>
There's https://wiki.whatwg.org/wiki/Why_not_conneg to not do it

[05:51:17.0000] <littledan>
oh I wasn't aware of that, thanks for the reference

[05:51:44.0000] <littledan>
this is also interesting with respect to the ideas about passing more locale information to the server...

[05:52:06.0000] <annevk>
But there's a lot of push from CDNs around various other formats to do something with conneg... E.g., all of client hints

[05:52:14.0000] <annevk>
Not necessarily Accept though

[07:13:51.0000] <annevk>
domfarolino: https://github.com/w3c/webappsec-referrer-policy/pull/137

[07:38:08.0000] <domfarolino>
annevk: commented

[07:39:28.0000] <annevk>
domfarolino: thanks

[07:39:48.0000] <annevk>
domfarolino: so maybe the problem is that document.referrer isn't currently defined as following Referrer Policy, which seems like a bug

[07:40:10.0000] <annevk>
or, hmm

[07:40:25.0000] <domfarolino>
annevk: Yeah, me and Domenic had a discussion about this recently..i think we determined it's not a problem?

[07:40:54.0000] <Domenic>
I have vague memories of this...

[07:42:17.0000] <annevk>
domfarolino: for initial about:blank we copy the creator URL: "If browsingContext's creator URL is non-null, then set document's referrer to the serialization of it."

[07:43:09.0000] <annevk>
For navigation it does seem to account for it

[07:44:45.0000] <domfarolino>
annevk: I think from the follow-up section in this doc (https://docs.google.com/document/d/18qOHKpUJ1N1GBxfls4XoBfeen09fxrCW0XV4Zs_FWiE/edit?ts=5ea75424#heading=h.hiccz7joqxl0) I determined about:blank iframes should inherit their creator doc's referrer policy too? memory is a bit fuzzy here though

[07:45:21.0000] <domfarolino>
annevk: Or no, the spec apparently says they should, but maybe they don't?

[07:48:42.0000] <annevk>
domfarolino: document.referrer is not the policy, but something else; but in browsers it does seem to align with Referer more than it does in the spec

[07:49:18.0000] <annevk>
e.g., if I open an about:blank popup with no-referrer, then document.referrer reflects that whereas the spec says something else

[07:51:44.0000] <annevk>
/me files https://github.com/whatwg/html/issues/5677

[07:53:59.0000] <domfarolino>
annevk: So the issue is that the referrer is the creating document's creator URL, but not censored by its referrer policy?

[07:55:19.0000] <annevk>
domfarolino: yeah

[07:56:23.0000] <domfarolino>
annevk: FWIW I added https://github.com/web-platform-tests/wpt/blob/master/referrer-policy/generic/inheritance/iframe-inheritance-about-blank.html

[07:56:54.0000] <domfarolino>
As a result of filing https://crbug.com.1075729

[07:57:09.0000] <domfarolino>
sorry, "." should be "/"

[07:57:15.0000] <annevk>
that's good to test too, yes; I think the spec handles that reasonably well, except for the part where our policy inheritance is a big mess

[07:59:42.0000] <domfarolino>
annevk: Right, so if we make any changes to the spec here to censor document.referrer by the creator document's referrer policy, we'll need to change the expectation here https://github.com/web-platform-tests/wpt/blob/master/referrer-policy/generic/inheritance/iframe-inheritance-about-blank.html#L48-L54

[08:01:11.0000] <domfarolino>
but yeah, referrer policy inheritance would be cool

[08:06:47.0000] <annevk>
domfarolino: isn't it censored though? It seems to be in Fx at least

[08:07:16.0000] <domfarolino>
annevk: I think impls censor it, but the test expects it to not be

[08:07:34.0000] <domfarolino>
annevk: So if we change the spec to match impls, we'll need to change that test

[08:07:51.0000] <annevk>
I see, add a comment to the issue I filed?

[08:07:54.0000] <domfarolino>
annevk: The chrome bug I filed basically says "Chrome censors document.referrer for about:blank iframes, but it shouldn't"

[08:07:57.0000] <domfarolino>
annevk: Just did

[09:01:12.0000] <annevk>
domfarolino: I also found out today that Chrome and Safari have a "site"-like referrer policy for anti-tracking purposes

[09:01:40.0000] <annevk>
domfarolino: whereby https://test.example.com/test?page becomes https://example.com/

[09:02:15.0000] <domfarolino>
annevk: How is this RP triggered / used? surely it isn't exposed as a real value for use in `referrerpolicy=...` etc

[09:03:06.0000] <annevk>
domfarolino: yeah, there's no public API, but maybe there should be

[09:03:50.0000] <domfarolino>
annevk: When do you see this referrer policy getting used?

[09:04:15.0000] <annevk>
domfarolino: https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/

[09:05:14.0000] <annevk>
domfarolino: it might be useful for sensitive-343242.registrable-domain.com

[09:05:36.0000] <devsnek>
if an abort controller is signaled after a request finishes successfully but before the promise resolves

[09:05:49.0000] <devsnek>
fetch rejects right

[09:06:37.0000] <domfarolino>
annevk: Do you see chrome mentioned in that or something?

[09:06:53.0000] <annevk>
domfarolino: I'm not sure I understand

[09:07:10.0000] <annevk>
devsnek: https://fetch.spec.whatwg.org/#dom-global-fetch

[09:07:44.0000] <domfarolino>
annevk: You said "Chrome and Safari have a...", and pointed me to the Safari release notes, but I don't see a mention of Chrome anywhere in that article

[09:07:58.0000] <annevk>
domfarolino: oops, Fx and Safari 🙂

[09:08:32.0000] <domfarolino>
annevk: I see. For Fx at least, is that policy only used for document.referrer redaction, or elsewhere too?

[09:09:18.0000] <annevk>
domfarolino: I'm not sure, though I did just suggest internally that we should be consistent across .referrer and Referer

[09:09:30.0000] <domfarolino>
annevk: Gotcha, makes sense

[09:09:33.0000] <annevk>
(ideally)

[09:55:11.0000] <Domenic>
Alright, let's merge COEP!

[10:03:05.0000] <annevk>
I suspect I won't get to cross-origin isolated this week, but maybe

[10:26:16.0000] <Domenic>
https://github.com/WICG/origin-isolation/issues/31 would also be appreciated

[10:26:49.0000] <annevk>
Domenic: I have no strong opinions

[10:27:13.0000] <Domenic>
annevk: me neither. Charlie's seem pretty strong, so I guess maybe we should move back to (1)

[10:27:46.0000] <annevk>
Domenic: seems fine, also no good ideas on naming

[10:27:59.0000] <annevk>
gotta go

[11:00:29.0000] <Krinkle>
Hm.. is OI (or COI) another addition to the list of origin-related accronyms? (CORS, COEP, COOP)

[11:00:49.0000] <Krinkle>
(or COPI, for cross-origina process isolation)

[11:01:51.0000] <Krinkle>
(or COACI, given the term agent cluster is used in spec language)

[11:03:31.0000] <Krinkle>
maybe the specs can be merged into larger one, we can call it Big O.

[11:17:27.0000] <Domenic>
If you feel a need to abbreviate "origin isolation", I would suggest "OI"

[16:17:51.0000] <MikeSmith>
TabAtkins: r? on https://github.com/tabatkins/bikeshed/pull/1711 when you got time


2020-06-26
[17:20:23.0000] <TabAtkins>
MikeSmith: ooh looks nice, will review tomorrow, thanks

[17:20:46.0000] <TabAtkins>
(was on vacation last week and am having trouble getting back into the swing this week, sorry)

[17:43:31.0000] <MikeSmith>
TabAtkins: no rush, thanks much!

[09:51:12.0000] <annevk>
Domenic: what's the remaining problem with littledan's scheme for import-attributes?

[09:52:57.0000] <Domenic>
annevk: all of my comments at https://github.com/whatwg/html/issues/5640#issuecomment-648906833 stand still

[09:53:21.0000] <annevk>
Domenic: I don't think so?

[09:53:55.0000] <Domenic>
annevk: the contortions they're layering on to avoid using the spec's existing infrastructure are still not really acceptable to me.

[09:55:35.0000] <annevk>
Domenic: it seems pretty straightforward to me; you store the response in the map, if the type matches, you store the parsed module; no poisoning, no problems with parallel (there's a single fetch), no problems with deduplication (still happens)


2020-06-27
[14:08:16.0000] <alystair>
I think I found a problem in implementation of event.isTrusted, where 'natural' follow up events are set to true, even if initial trigger event was false. I made a POC here: https://codepen.io/alystair/pen/pogwGba?editors=1010

[14:09:03.0000] <alystair>
There's nothing in the spec that requires it, wouldn't it make sense?


2020-06-28
[16:10:17.0000] <jerryitt>
Hey all

[16:23:21.0000] <jerryitt>
Is there an example showing how to read and play .mp3 files from a local file system?


2020-06-29
[17:56:44.0000] <Krinkle>
jerryitt: I found this example and simplified it a bit: https://codepen.io/Krinkle/pen/jOWGqGw

[17:57:04.0000] <Krinkle>
you can drag an MP3 from your system's file explorer/finder and drop it in to play and work with

[17:58:17.0000] <jerryitt>
@Krinkle  oh thats very neat, tank you.

[02:12:27.0000] <annevk>
GitHub getting unreliable?

[02:25:17.0000] <MikeSmith>
annevk: yeah

[02:25:55.0000] <MikeSmith>
mathiasbynens: congrats on String.prototype.replaceAll finally landing in the ES spec

[02:28:40.0000] <mathiasbynens>
MikeSmith: yay! thanks :)

[02:29:14.0000] <mathiasbynens>
only took 2.5 years 🙄

[02:32:17.0000] <annevk>
Wow, what was the holdup?

[02:36:54.0000] <annevk>
shu: I'm fine with unconditionally wrapping module scripts in promises

[03:01:40.0000] <MikeSmith>
annevk: https://stackoverflow.com/questions/62634803/why-is-the-origin-header-sent-for-same-origin-requests if you care to comment or answer

[03:06:22.0000] <MikeSmith>
annevk: so the new/current IDL way is for the literal `constructor();` like that?

[03:06:28.0000] <MikeSmith>
[Exposed=Window]

[03:06:28.0000] <MikeSmith>
interface DataTransfer { constructor();

[03:06:37.0000] <MikeSmith>
..

[03:06:52.0000] <MikeSmith>
well, with the linebreak that got ate by teh paste

[03:07:36.0000] <MikeSmith>
anyway, I can’t recall having seen that before

[03:09:41.0000] <MikeSmith>
OK I see https://github.com/whatwg/html/issues/5685 but I think we still have a lot of cases of IDL using the Constructor attribute

[03:09:54.0000] <MikeSmith>
we need to change all those?

[03:11:07.0000] <annevk>
MikeSmith: in HTML?

[03:12:18.0000] <MikeSmith>
in other specs

[03:13:54.0000] <annevk>
MikeSmith: yeah, they would have to update

[03:14:00.0000] <annevk>
MikeSmith: I replied to the question

[03:14:24.0000] <annevk>
I think Kagami rewrote most specifications automatically btw, but there could be some left

[03:15:16.0000] <MikeSmith>
ah OK

[03:27:49.0000] <MikeSmith>
annevk: https://github.com/whatwg/whatwg.org/pull/338#partial-pull-merging now stuck at “Checking for ability to merge automatically…Hang in there while we check the branch’s status”

[03:28:16.0000] <MikeSmith>
never seen tha happen

[03:28:23.0000] <annevk>
MikeSmith: https://www.githubstatus.com/ is a Christmas tree

[03:29:52.0000] <annevk>
MikeSmith: I've seen that message, but usually it's a quick operation; with the API server down though...


2020-06-30
[01:33:55.0000] <annevk>
littledan: hey, I'm still trying to get my head around incumbent and wanted to ask about https://github.com/whatwg/html/issues/5213#issuecomment-575612202

[01:35:02.0000] <annevk>
littledan: with postMessage, an arbitrary cross-origin window object could be passed to bind, but maybe that doesn't trigger the issue as that just causes the message to be delivered there?

[05:30:06.0000] <gsnedders>
Ms2ger: FWIW given the Bitbucket shutdown, I've thrown together https://github.com/gsnedders/anolis which contains the history for both of our Mercurial repos

[05:31:40.0000] <Ms2ger>
Good call

[05:31:58.0000] <Ms2ger>
I've just gotten around to cloning my repos locally today :)

[05:32:39.0000] <gsnedders>
Anolis is the only repo I'm bothering to do anything like this for, given I suspect it's the only public one anyone cares about :P

[05:33:08.0000] <gsnedders>
and, well, when the latest release of the project was from your repo…

[07:08:31.0000] <MikeSmith>
so would CompressionStream and DecompressionStream end up going into the HTML spec? if not, where?

[15:41:46.0000] <MikeSmith>
Domenic: inspired by the distroless thing you did for the Docker image for Wattsi, I did similar for HTML checker image, and it reduced the size down from 130MB to 60MB