2021-04-01
[05:40:16.0000] <MikeSmith>
quick poll (for those who don’t mind sharing):

[05:40:55.0000] <MikeSmith>
in a console (devtools or node, doesn’t matter which), what do you get for the following:

[05:40:59.0000] <MikeSmith>
Intl.DateTimeFormat().resolvedOptions().timeZone

[05:52:13.0000] <jgraham>
"Europe/London"

[05:52:40.0000] <ondras>
 "Europe/Prague"

[05:56:44.0000] <MikeSmith>
thanks

[05:58:26.0000] <MikeSmith>
ondras: are you actually in Prague or near, or instead somewhere else, and the system is picking that?

[05:59:15.0000] <ondras>
I am in Prague, it is correct

[05:59:17.0000] <MikeSmith>
or in other words, is that what you’d expect it to say

[05:59:21.0000] <MikeSmith>
ah OK thanks

[05:59:21.0000] <ondras>
right

[05:59:29.0000] <ondras>
(tried firefox, Chrome, and Node)

[08:23:56.0000] <Domenic>
"America/New_York", which is, indeed, where I am

[08:44:59.0000] <superkuh>
Exception: Intl is not defined

[09:04:02.0000] <nox>
Europe/Paris for me, which is correct.

[15:43:43.0000] <TabAtkins>
MikeSmith: "America/Los_Angeles" for me, and I'm def not in LA, but that *is* the standard timezone name for American Pacific time. (I'm in SF area.)

[15:44:24.0000] <TabAtkins>
(It's what I know to look for when I'm selecting timezones using this naming system.)

[16:04:22.0000] <MikeSmith>
TabAtkins: interesting — I would have assumed the IANA DB had an America/San_Francisco zone, but apparently not

[16:04:27.0000] <MikeSmith>
https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

[16:07:32.0000] <MikeSmith>
there are 8 different America/Indiana/* zones — but I guess those must all have some quirks related to most of Indiana being on US/East offset

[16:11:26.0000] <MikeSmith>
I am trying to document some of this for MDN

[16:14:27.0000] <MikeSmith>
from a user point of view, it’s a bit surprising if, for example, you went into the Date & Time: Time Zone widget in System Settings, and it asked you to pick the closest city, and you picked San Franciso ... but then your system ends up with its timezone set to America/Los_Angeles rather than America/San_Francisco

[16:33:03.0000] <Domenic>
Yeah these are definitely programmer-facing names, not user-facing names


2021-04-03
[05:04:38.0000] <MikeSmith>
new Date('2021-03-29').toISOString()

[05:04:41.0000] <MikeSmith>
"2021-03-29T00:00:00.000Z"

[05:04:51.0000] <MikeSmith>
new Date('2021/03/29').toISOString()

[05:04:52.0000] <MikeSmith>
"2021-03-28T15:00:00.000Z"

[05:05:07.0000] <MikeSmith>
fun stuff

[06:50:59.0000] <fales[m]>
hello good people, I'm currently the maintainer of the HTML5/wasm export of Godot Engine. We've been recently bitten by CORS headers limitations in `fetch`.

[06:50:59.0000] <fales[m]>
I know there are security implications with CORS, but I'm wondering if there is one specifically for why `Content-Length` is whitelisted while `Content-Encoding` is not. And if it would make sense to open an issue on the whatwg/fetch github for that.

[06:50:59.0000] <fales[m]>
To give some context we were using `Content-Length` to improve memory allocation when `Content-Encoding` was not set (so we knew that Content-Length reflected the acutal bytes to be read). You can read some more in this PR: https://github.com/godotengine/godot/pull/47597

[09:51:16.0000] <Domenic>
fales[m]: you'd probably get a good answer by filing on whatwg/fetch and waiting for annevk to come back from his OOO time. However I'll note in general that the allowlist is just legacy exceptions and if anything we'd want to reduce it over time (i.e. remove Content-Length) instead of expand it.

[09:51:34.0000] <Domenic>
s/I'll note that/my impression is that/ (annevk would be better to confirm)

[12:50:25.0000] <fales[m]>
Domenic: thanks for your reply. I'll think about opening an issue then, but I see the point in reducing the allowlist instead of expanding it.

[14:36:45.0000] <EveryOS>
Does the spec expect all UAs to support Ecmascript? If not, what do UAs that do not support Ecmascript generally do when the specs make mentions to things like Javascript Realms?

[14:41:47.0000] <andreubotella>
My understanding is that the spec only needs to keep track of realms because callbacks must be associated to some realm, and so you don't have to care about them if you don't support scripts

[14:42:09.0000] <EveryOS>
Ok, thanks


2021-04-07
[06:36:59.0000] <smaug____>
does coop or coep require https?

[06:38:14.0000] <JakeA>
smaug____: yeah, step 2 https://html.spec.whatwg.org/multipage/origin.html#obtain-coop

[06:38:40.0000] <smaug____>
ah, there, thanks

[06:40:06.0000] <zcorpan>
smaug____: both do. for coep, step 2 in https://html.spec.whatwg.org/multipage/origin.html#obtain-an-embedder-policy

[06:40:45.0000] <zcorpan>
wpt tests to verify this exist

[08:41:34.0000] <noamr>
Hi Domenic! thanks for the quick response on HTML/NavigationTiming. Navigation Timing is ready to merge, but right now it shows errors as it waits for ReSpec to be synced with the new changes in HTML. I am not sure how it works in terms on when ReSpec catches up with HTML, but I think it happens daily. I can merge it in the moment it does... /cc yoav

[08:52:44.0000] <yoav>
I *think* respec is using specref, which seems to update multiple times a day: https://github.com/tobie/specref/commits/master

[08:54:06.0000] <yoav>
it's claiming to be run hourly: https://github.com/tobie/specref#hourly-auto-updating

[08:54:52.0000] <yoav>
tobie would know more

[08:56:53.0000] <noamr>
ah yes seems like specref does it, which should happen hourly-ish. I'll wait for the next specref push to verify navigation timing

[13:23:37.0000] <tobie>
noamr: have your issue been fixed?


2021-04-08
[21:15:30.0000] <MikeSmith>
Can anybody think of any methods or properties that return Boolean objects rather than just a true/false boolean primitive?

[21:16:20.0000] <MikeSmith>
Context is that in MDN we have many cases of web-platform APIs where we have them documented as returning Boolean objects

[21:17:36.0000] <MikeSmith>
...and it seems like that is wrong in almost all the cases where we have it documented that way, because the relevant methods and properties actually return true/false boolean primitives

[21:18:13.0000] <MikeSmith>
tracking bug is https://github.com/mdn/content/issues/3898

[22:02:11.0000] <noamr>
tobie: no, seems like specref is still not up to date with latest HTML... the documentation says it updates hourly, specref.org says it updated around 24 hours ago. it's unclear to me what to do in this case... thanks :)

[02:15:14.0000] <noamr>
ok, seems to be caught up now. thanks!

[08:21:11.0000] <Domenic>
MikeSmith: no, Boolean objects are evil and are never to be used (and it's impossible to return them in IDL)

[11:09:54.0000] <zcorpan>
I recall someone sharing on Twitter (probably) interesting cases with history back/forward that aren't interoperable, like removing iframes and then clicking back. Can't find it now. Does it ring a bell? Domenic?

[11:10:10.0000] <Domenic>
That's JakeA... it's a mess. Let me find his latest.

[11:10:31.0000] <Domenic>
Well, most of the recent issues in https://github.com/whatwg/html/issues/created_by/jakearchibald are of that flavor

[11:11:02.0000] <Domenic>
https://www.youtube.com/watch?v=nZb0U3rFQXw is a good watch

[11:11:23.0000] <zcorpan>
Domenic: thanks

[11:14:56.0000] <zcorpan>
context is https://github.com/web-platform-tests/wpt/issues/16359

[11:39:57.0000] <JakeA>
zcorpan: there's also https://youtu.be/W6lvQvdeF8U

[11:40:42.0000] <zcorpan>
JakeA: yeah HTTP 203 was probably what I had seen :)

[11:41:38.0000] <JakeA>
zcorpan: been trying to figure out what to do with cancelled beforeunload prompts today 😞

[11:41:45.0000] <JakeA>
It's tricky

[11:44:04.0000] <zcorpan>
JakeA: is it interoperable?

[11:49:45.0000] <JakeA>
zcorpan: oh absolutely not. It isn't even consistent within a single browser 😀 https://github.com/whatwg/html/issues/6446

[11:50:08.0000] <zcorpan>
JakeA: fun!


2021-04-09
[22:15:30.0000] <MikeSmit1>
Domenic: thanks for feedback about Boolean objects

[22:15:36.0000] <MikeSmit1>
will get MDN updated

[22:18:56.0000] <MikeSmith>
oh wow I just now accidentally discovered that in GitHub comments you can surround a range of text into backticks just be selecting it and typing `

[22:19:26.0000] <MikeSmith>
pretty sure that’s not documented

[23:53:08.0000] <JakeA>
MikeSmith: they added some formatting stuff in the past couple of months. Eg, now if you start a list, and press enter, it automatically inserts the start of the next list item. Eg `- `

[23:53:56.0000] <JakeA>
Although, I don't like that it does it for numbered lists. In markdown I prefer starting each list item with `1. `, rather than giving it the proper number. That means I can rearrange items without manually updating the numbers.

[23:56:13.0000] <MikeSmith>
JakeA: yeah I had accidentally discovered the list auto-bulleting thing a while back

[23:56:47.0000] <MikeSmith>
and yeah for numbered lists it would be better if it didn’t try to be quite so smart

[01:47:45.0000] <JakeA>
annevk: did we change it so <embed> and <object> are always navigation requests now?

[01:51:26.0000] <JakeA>
Oh, I see it https://github.com/whatwg/fetch/pull/948

[07:51:25.0000] <Domenic>
JakeA: so currently I guess a session history is definitely BCG scoped. After your work though it'll span BCGs, right? For app history we only want to show the current-BCG subset, so will there be a way to differentiate which session history entries are in the current BCG?

[07:57:20.0000] <JakeA>
Domenic: why do we want to scope it like that? I thought the BCG was for protecting resources in memory like images etc from meltdown/spectre attacks

[07:57:58.0000] <Domenic>
JakeA: well, good question; csreis seemed to prefer that and I didn't really question it... I'll move this to GitHub.

[07:59:10.0000] <Domenic>
JakeA: well, the history state seems kind of like sensitive data too in that regard?

[07:59:34.0000] <Domenic>
Like if one BCG is not-COI and thus untrusted/Spectre-able, it should not be able to read app history state from a COI BCG that is otherwise protected from Spectre

[07:59:47.0000] <JakeA>
Domenic: is it any more sensitive than what can be exchanged in IDB?

[07:59:58.0000] <Domenic>
Fair...

[08:01:19.0000] <JakeA>
Domenic: I currently have the concept of a "session" which limits history visibility & session storage, but it can span BCGs. The session changes when a cross-origin navigation happens outside the control of the page (url bar, selecting a bookmark etc etc)

[08:01:58.0000] <JakeA>
If a session changes, it must change BCG, but a session can span many BCGs

[08:18:21.0000] <JakeA>
(fwiw I keep having to remind myself that isolation is there to protect no-cors data)

[10:52:38.0000] <hober>
MikeSmith: teeny tiny wattsi PR https://github.com/whatwg/wattsi/pull/142

[10:53:30.0000] <MikeSmith>
hober: will take a look

[10:53:52.0000] <hober>
MikeSmith: thanks! :)

[10:58:51.0000] <hober>
oh, you don't need to! Domenic just merged it. thanks, Domenic!

[10:59:14.0000] <Domenic>
Oh, no problem! I was just monitoring my inbox and saw it pop up...

[11:00:36.0000] <MikeSmith>
hober: I could still build fine in my environment prior to that patch, with macOS 11.2.3 (20D91)

[11:03:09.0000] <MikeSmith>
but anyway I can also still build fine with the patch merged

[11:03:14.0000] <MikeSmith>
so it’s all good

[11:07:44.0000] <Domenic>
Thanks for checking MikeSmith

[14:10:46.0000] <hober>
great. thanks again, both of you.


2021-04-10
[11:02:51.0000] <axiomatik>
Hi

[11:10:07.0000] <dyvyzokj>
Hi


2021-04-12
[01:49:09.0000] <andreubotella>
annevk: Would you mind merging https://github.com/web-platform-tests/wpt/pull/26740 ?

[02:07:14.0000] <annevk>
andreubotella: you got it

[02:07:39.0000] <annevk>
Oh, I see now that it was marked as needs spec decision, but maybe that happened while I was away?

[02:10:03.0000] <andreubotella>
annevk: There wasn't a lot of work done on this while you were OOO, but it seemed like there was some consensus in doing things that way

[02:16:19.0000] <yoav>
I'm messing around with the render blocking status of resources, and confused by the "non-blocking" script flag in HTML: https://html.spec.whatwg.org/multipage/scripting.html#non-blocking

[02:16:20.0000] <yoav>
It seems like when dynamically adding script resources and setting their async attr to true, their non_blocking is unset

[02:18:52.0000] <yoav>
and I'm trying to understand why that would be the case..

[02:19:32.0000] <yoav>
^^ JakeA

[02:20:23.0000] <JakeA>
from memory, that bit of the spec is really confusing

[02:20:44.0000] <JakeA>
I think it's kind of overloaded as a bit of bookkeeping, and the non_blocking flag is set later

[02:30:07.0000] <yoav>
It doesn't in our impl as far as I can tell

[02:30:26.0000] <yoav>
(or maybe it's set after I report the render blocking status)

[02:31:14.0000] <yoav>
I guess my question is: should dynamic scripts with async=true be materially different than dynamic scripts with no async attribute?

[02:31:34.0000] <yoav>
in terms of execution order, priority, etc

[02:36:27.0000] <noamr>
welcome back annevk! when you have time I want to tie loose ends with FETCH/RT (https://github.com/whatwg/fetch/pull/1202 for now)

[02:45:17.0000] <JakeA>
@yoav I don't think they should be different

[02:46:10.0000] <yoav>
JakeA: ok, so there's no way to "turn off" the blocking nature of a dynamic script once you touched it?

[02:46:27.0000] <yoav>
once you touched its async attribute

[02:46:48.0000] <JakeA>
yoav: I don't think so. async=false is still non-blocking, but it changes execution order

[02:47:27.0000] <yoav>
it may be "non-blocking" but its non-blocking flag is unset

[02:47:40.0000] <yoav>
(which caused me some confusion)

[02:47:53.0000] <JakeA>
yeah, I get confused by that too

[04:46:55.0000] <noamr>
JakeA: when you get a chance, https://github.com/w3c/ServiceWorker/pull/1575 is ready for another look

[07:28:47.0000] <annevk>
noamr: hey, I hope I'll get to it by Wednesday, maybe tomorrow; there's a lot

[07:29:17.0000] <noamr>
annevk: sure, whenever you get to it. thanks.

[08:13:46.0000] <Domenic>
annevk: thoughts on https://github.com/WICG/app-history/issues/71 would be much appreciated; JakeA and I seem to have different ideas from creis about the boundaries of cross-origin isolation and extra perspective would be great.

[08:19:16.0000] <annevk>
Domenic: I guess these URLs would not leak with the current history API because the parent process manages them?

[08:19:25.0000] <annevk>
Domenic: and they are not directly exposed?

[08:19:41.0000] <Domenic>
annevk: yeah, it seems like the question is whether same-origin URLs are sensitive

[08:19:43.0000] <annevk>
Domenic: if so, creis has a point

[08:20:35.0000] <Domenic>
Like, should we have some sub-origin concept where URLs that are same-origin but COI are considered sensitive from the non-COI parts of the origin...

[08:22:20.0000] <annevk>
Domenic: so say you are on example.com/sensitive-id and the navigate to example.com/ which includes an ad, and the former protects itself with COOP+COEP and also prevents referrer leaking, then the latter would now be able to obtain something new

[08:22:59.0000] <Domenic>
annevk: yes. If we consider example.com/sensitive-id and example.com to be in an adverserial relationship then indeed something leaks. I just kind of thought we never did that, because the origin was our security boundary.

[08:23:31.0000] <annevk>
Domenic: well example.com includes an ad, perhaps via <script> and doesn't use COOP+COEP so it can be Spectre-read

[08:24:17.0000] <Domenic>
annevk: so is the idea that in general same-origin sites need to be protected from reading each other now, i.e. origin is no longer the security boundary but instead agent cluster key is?

[08:24:22.0000] <annevk>
Domenic: so example.com/ itself is not the adversary, but the ad is, I guess the ad is generally problematic for read access to history

[08:24:45.0000] <Domenic>
Well if the ad is cross-origin it can't access parent.appHistory.entries()

[08:24:47.0000] <annevk>
Domenic: I don't think so, I'm just trying to make sense of what information is being exposed

[08:25:03.0000] <Domenic>
I guess it could Spectre parent.appHistory.entries() though in non-OOPIF browsers.

[08:25:09.0000] <annevk>
Domenic: a lot of ads get included through <script>, but yeah, a lot of stuff would be vulnerable then

[08:26:10.0000] <annevk>
Domenic: I think there is something to be said for willing to be excluded from history, similar to referrer, I don't think it necessarily ties to COOP+COEP

[08:27:29.0000] <Domenic>
Yeah that makes a bit more sense to me...

[08:28:37.0000] <JakeA>
appHistory.entries() can only be Spectre'd if it's possible with low res timers

[08:30:12.0000] <JakeA>
We could have a header that forces a new session on navigation (as defined in https://github.com/whatwg/html/issues/6356). That would limit app history

[08:30:27.0000] <JakeA>
But it all seems risky without true sub-origins

[08:57:56.0000] <annevk>
I left a summary of sorts in a comment

[09:09:23.0000] <annevk>
Domenic: Google Docs at least doesn't seem to care about leaking the URL to itself

[09:09:57.0000] <Domenic>
annevk: yeah, in general I'd be surprised if same-origin pages were trying to prevent other parts of the origin within a single user's history from learning their URLs...

[09:11:30.0000] <annevk>
Domenic: I can see how it's more concerning though as depending on how much the user browses around on your origin it could be quite some interesting data you normally might not keep client-side


2021-04-13
[05:24:39.0000] <noamr>
annevk: I'm working on several FETCH follow ups (the PR that's already up, service-workers, transfer-size etc). would it be better to put them up gradually by topic or to do one bigger one with all of them? either way works for me.

[05:25:22.0000] <annevk>
noamr: if they can be reasonably split that's easier

[05:25:32.0000] <annevk>
noamr: if you feel like you need to merge that works as well though

[05:26:11.0000] <noamr>
annevk: they can, but then dependencies between them are a little iffy. maybe I'll merge them together

[05:27:17.0000] <noamr>
annevk: how would you suggest to deal with the circular dependency? Service worker defines a struct, but we associate it with a response in FETCH... it's like a forward-declaration of sorts.

[05:28:40.0000] <annevk>
noamr: maybe define the struct in a SW PR, define the member in a Fetch PR, use them in a SW PR

[05:29:36.0000] <annevk>
noamr: there's a similar setup for referrer policy

[05:30:08.0000] <annevk>
noamr: the other thing you could do is add some kind of hardcoded links section in bikeshed and then remove that in a Meta PR

[05:30:52.0000] <noamr>
annevk: I prefer the multiple PR approach for now, if JakeA is ok with that

[05:50:47.0000] <JakeA>
noamr: works for me. I'll take another pass at your PR tomorrow if that's ok

[06:10:31.0000] <noamr>
JakeA: sure, np

[06:25:35.0000] <annevk>
noamr: I think I got through all issues and PRs I was mentioned on or participated in, let me know if I missed something

[06:25:49.0000] <annevk>
(related to RT, to be clear)

[06:31:52.0000] <noamr>
annevk: there is also https://github.com/whatwg/xhr/pull/319

[06:32:16.0000] <noamr>
annevk: otherwise, the ball is in my court. I'm following up on all the cross-repo issues here: https://docs.google.com/document/d/1c9q0frGeIuhINTr7k6IiR1oLb6oDkkCTbRn0sk1mmdE/edit?usp=sharing

[06:32:26.0000] <noamr>
thanks!

[06:32:57.0000] <annevk>
noamr: ah yeah, so that has an issue too with network errors that I forgot to describe (it's what caused me to raise the other issue)

[06:33:06.0000] <annevk>
I'll note that down now

[06:36:31.0000] <annevk>
done

[06:40:54.0000] <noamr>
annevk: there's also https://github.com/whatwg/fetch/issues/1208, which I haven't started working on, but early input would help

[06:44:06.0000] <annevk>
noamr: is that a new feature or preserving the existing feature set? I didn't spot any obvious problems with it when I read it the first time and still don't

[06:44:56.0000] <annevk>
noamr: I guess the one subtlety there is the time coarsening

[06:46:16.0000] <annevk>
noamr: I guess we need to know if the SW had cross-origin isolation and if we don't, we coarsen at that point, otherwise we take values as-is

[06:46:24.0000] <annevk>
I'll note that in the issue

[06:57:46.0000] <noamr>
annevk: the problem is that SW might have connection info attached to the response, but we override it with the original request's connection info (which is probably null). I'll try to tackle it more in detail after the other issues are resolved.

[06:59:11.0000] <annevk>
noamr: yeah, I'm just wondering if exposing that is new for implementations or not

[08:47:20.0000] <noamr>
annevk: Implementations expose this.

[09:00:03.0000] <noamr>
annevk: regarding CORS, I'm proposing to remove the CORS bit from FETCH for now, and proceed with the other issues until there's some consensus about it. WDYT?

[09:00:16.0000] <noamr>
(... and open a new issue specifically for this)

[09:40:24.0000] <annevk>
noamr: yeah, I think that's reasonable if CORS was indeed an exception and network errors are generally ignored

[09:41:16.0000] <noamr>
annevk: what's generally ignored (spec-wise) are errors that come before CORS. errors that come afterwords pass through fetch-finale and create an RT entry.

[09:43:36.0000] <annevk>
noamr: how could you get a network error afterwards?

[09:44:10.0000] <annevk>
CSP rejecting a CORS response from a service worker or some such?

[09:47:01.0000] <noamr>
annevk: yea, anything that goes through "fetch finale" should have an RT entry. I believe some of the network errors go through "fetch finale". but it's a bit tricky to decipher

[09:47:50.0000] <noamr>
annevk: but I believe it requires further investigation, so maybe for now leaving it out and treating as a separate issue.

[09:55:00.0000] <Domenic>
annevk: if you have a chance to re-review https://github.com/whatwg/html/pull/6565 I'd appreciate it so as to unblock that chain of CLs

[09:59:24.0000] <annevk>
Domenic: done

[09:59:45.0000] <annevk>
noamr: sounds reasonable, I'll try to prioritize the PR for tomorrow morning

[10:00:15.0000] <Domenic>
Thanks!

[10:15:41.0000] <noamr>
annevk: great, thanks!

[11:32:17.0000] <croraf>
Does WHATWG deal with "mailto" protocol?

[12:52:18.0000] <Krinkle>
croraf: I think it does to a limited extent. The URLs using the mainto: scheme should presumably comform to, and be interpreted based on the URL spec. https://url.spec.whatwg.org/ For the most part I imagine it's like most externally handled protocols in that it is browser/OS-defined. But in the specific case of mailto there appear to be actually a few nomimal refererences and special cases for it in the HTML spec:

[12:52:18.0000] <Krinkle>
https://duckduckgo.com/?q=mailto+site%3Awhatwg.org

[12:52:46.0000] <Krinkle>
the protocol itself is defined via IETF however, https://tools.ietf.org/html/rfc6068


2021-04-14
[17:28:34.0000] <Domenic>
There's somewhat of an open question about how to parse mailto and similar cases: https://github.com/whatwg/url/issues/385

[08:18:34.0000] <Domenic>
annevk: should we continue with https://github.com/whatwg/html/pull/6510 ?

[08:22:11.0000] <annevk>
Domenic: if you have a clear handle on the cases we need to consider that would help, but it's on my list of things to get to still

[08:22:50.0000] <Domenic>
Hmm OK, I mean the PR looked good to me from a normative perspective, but maybe I should try to think through all the cases harder.

[08:23:51.0000] <annevk>
I thought it would use more examples as there's a lot more logic than examples so I wonder if all the logic is justified

[08:24:13.0000] <Domenic>
Yeah that's fair

[10:32:26.0000] <annevk>
Domenic: FWIW, if you can land the HTML side of the imperative slot API today, hopefully everything is indexed for DOM to land tomorrow

[10:32:44.0000] <Domenic>
annevk: oh OK, I wasn't sure all the discussions were settled, nice.

[10:32:44.0000] <annevk>
Domenic: assuming you don't spot any novel issues that is

[10:33:15.0000] <annevk>
Domenic: I settled the remaining issue with rniwa this morning on the DOM side and mfreed7 reviewed just now

[10:33:43.0000] <annevk>
(I only ended up making editorial changes and mfreed and I convinced rniwa of the design)


2021-04-15
[23:10:11.0000] <annevk>
yoav: noamr: I was looking at https://github.com/w3c/resource-timing/pull/266/files and noticed "<<<<<<< HEAD" in there

[23:11:25.0000] <noamr>
oops, fixing

[23:12:24.0000] <annevk>
So is transferSize the only place where we expose something is in the cache? I guess it's less problematic now we have partitioned caches, but it still doesn't seem ideal.

[23:15:33.0000] <noamr>
I'm not a fan of that either, but it's a reflection of current implementations. IMO it should be more explicit

[23:17:54.0000] <noamr>
there are a few metrics in resource/navigation timing are used to extrapolate information like "cache mode" and "total worker time" implicitly, I think one of the next challenges for performance WG, now that the models are beginning to be integrated with HTML/FETCH, is to define them more explicitly.

[23:18:41.0000] <noamr>
yoav: https://github.com/w3c/resource-timing/pull/270 fixes the stray <<< thingy

[23:20:16.0000] <noamr>
annevk: in the meantime, when you get a chance, https://github.com/whatwg/fetch/pull/1202 is ready for another look, and I'm trying to understand what you mean in https://github.com/whatwg/xhr/pull/319#discussion_r612452423 :)

[23:37:00.0000] <yoav>
RE cache exposure, it's been an explicit use case. I agree that a more direct boolean would be nicer (or enum to cover the case of revalidations)

[23:37:48.0000] <yoav>
The input we got from security folks over the years is that it can already be considered exposed (hence cache partitioning)

[02:59:12.0000] <annevk>
I guess that's true, though there was never interest to have response.fromCache somehow

[03:50:12.0000] <noamr>
JakeA: hola, reminding you re. https://github.com/w3c/ServiceWorker/pull/1575 when you get a chance

[04:04:23.0000] <annevk>
noamr: in reverting responseObject -> response you also reverted actual responseObject vars

[04:05:06.0000] <annevk>
noamr: "Let <var>timingInfo</var> be <var>response</var>'s <a for=response>timing info</a>." can also be removed now

[04:32:10.0000] <JakeA>
noamr: cheers, I'll do that now

[04:37:23.0000] <noamr>
annevk: ok!

[05:16:21.0000] <noamr>
annevk: fixed

[05:29:44.0000] <annevk>
noamr: I still see the unused timingInfo

[05:38:30.0000] <JakeA>
noamr: done!

[06:01:25.0000] <noamr>
JakeA: thanks! changes applied, ready for another round (with a TODO, since finishing this would depend on a FETCH change)

[06:04:22.0000] <JakeA>
noamr: one minor nit, but LGTM. I guess it makes sense to wait until the fetch PR is ready, then remove that comment before merging?

[06:05:23.0000] <noamr>
JakeA: the TODO is there because it's a circular dependency... we need this to be in as it contains the struct definition, in order to pass the FETCH PR

[06:05:42.0000] <noamr>
(in lieu of "forward declarations" in specs)

[06:06:38.0000] <noamr>
https://github.com/w3c/ServiceWorker/pull/1575#discussion_r612402054

[06:07:17.0000] <annevk>
noamr: wasn't the idea to copy-and-paste the struct into its own PR?

[06:07:36.0000] <JakeA>
that would work

[06:07:38.0000] <annevk>
noamr: then merge that, then merge the Fetch bits, then this one

[06:08:10.0000] <noamr>
I can do that if that's better than putting the "associate" part in a TODO

[06:08:41.0000] <JakeA>
It would create cleaner history

[06:08:59.0000] <noamr>
gotcha. on it

[06:11:55.0000] <JakeA>
I'll merge that new PR once it lands

[06:12:58.0000] <JakeA>
noamr: can you join the service worker group for ipr?

[06:13:05.0000] <JakeA>
https://labs.w3.org/repo-manager/pr/id/w3c/ServiceWorker/1581

[06:13:34.0000] <noamr>
will do

[06:13:44.0000] <JakeA>
sorry about the churn here

[06:15:06.0000] <noamr>
yea I'm used to it :) no problem

[07:03:26.0000] <annevk>
Domenic: so part of my confusion reading OP https://github.com/whatwg/html/issues/6509#issue-835244786 is that _host_ is not defined

[07:04:14.0000] <Domenic>
Hmm that is confusing, what did I mean...

[07:05:59.0000] <Domenic>
annevk: I think it's "Let host be the result of parsing hostSuffixString."

[07:06:16.0000] <annevk>
ok

[07:06:20.0000] <Domenic>
i.e. I think this is meant to replace step 4

[07:12:40.0000] <annevk>
Domenic: hmm, but this doesn't seem to deal with the IP address scenario at all

[07:13:30.0000] <annevk>
Domenic: at least the current text returns true if are on an IP address and you set document.domain to the same IP address

[07:13:43.0000] <Domenic>
annevk: hmm yeah. Can we just keep 4.1? I dunno, this was just sleevi hacking something together over DM, we should be more rigorous as you are being...

[07:56:52.0000] <annevk>
Domenic: I pushed it forward a fair bit, but I'd like sleevi to give me more examples :-)

[07:57:48.0000] <Domenic>
We can try, although I don't think he works on this stuff these days so it's mostly a question of if we can nerd snipe him :)

[08:00:33.0000] <annevk>
Yeah, it seems that PSL is largely unowned, which isn't great

[08:17:47.0000] <hober>
I've been thinking about how to put the PSL on firmer ground lately

[08:18:44.0000] <hober>
we could follow the WPT model and stand up some lightweight governance etc, and get each browser vendor to put some engineering time toward it

[08:19:15.0000] <hober>
though ultimately the PSL is basically a registry, so maybe we should treat it as such and stand it up as a registry at W3C, IANA, or here at the WHATWG

[08:19:39.0000] <hober>
I know singer has been trying to improve W3C process around registries; I dunno how far along that is though

[08:35:41.0000] <annevk>
hober: it's somewhat unique in that it needs to be ingested by browsers directly, but yeah

[10:14:39.0000] <Domenic>
annevk: tobie: I think PR preview is having problems (not wattsi-server) since it's happening for Bikeshed specs, e.g. https://github.com/whatwg/dom/pull/969


2021-04-16
[01:00:03.0000] <domfarolino>
annevk: It seems awkward that URL's host registrable domain algorithm returns null if the host == PublicSuffixAlgo(host), particularly because I think the only users of the registrable domain algorithm are in HTML, and always seems to have to null check, falling back to host in this case. Wouldn't it be simpler to just have the rd algo not return null in this case?

[01:00:35.0000] <domfarolino>
Although I'd understand returning null (even if it feels awkward to consumers) if we're trying to maintain semantic clarity

[01:01:06.0000] <annevk>
domfarolino: well, there's no registrable domain in that case so it seems safer to not claim there is one

[01:01:36.0000] <domfarolino>
annevk: Right, so it is more about the semantics and clarity there I guess. that makes sense

[01:01:59.0000] <domfarolino>
I was just curious if there were users of registrable domain that actually relied on values being null in that case

[01:02:13.0000] <annevk>
domfarolino: that is a good question, looking at the same site definition

[01:02:27.0000] <domfarolino>
And that didn't appear to be the case, though I agree it could be confusing if it just fell-back to the PSL value

[01:03:23.0000] <annevk>
domfarolino: well, it would also have to fallback to being an IP address and such

[01:04:34.0000] <domfarolino>
annevk: Ah yeah that's right, I forgot that those URL algorithms just return null when the host is not a "domain"

[01:07:06.0000] <annevk>
For document.domain we use public suffix primarily (though it's currently broken); not aware of other usage

[01:07:53.0000] <domfarolino>
Yeah I don't think there are any that rely on it being null when PSuffix(host) == host, but like you said, it wouldn't matter anyways. Thanks

[01:10:32.0000] <annevk>
domfarolino: I think Firefox might do this internally and call it baseDomain, but not a 100% sure

[01:10:57.0000] <annevk>
domfarolino: if we did something like this in the spec we could call it "base host" or some such, we could no longer call it registrable domain

[01:11:47.0000] <domfarolino>
Makes sense 👍

[01:14:41.0000] <domfarolino>
It seems that we could simplify the same site and schemelessly same site algorithms by utilizing "obtain a site"...

[01:16:00.0000] <domfarolino>
or at least simplify schemelessly same site

[01:16:23.0000] <annevk>
domfarolino: https://github.com/whatwg/html/pull/5955

[01:17:23.0000] <domfarolino>
Hah :(

[01:21:57.0000] <domfarolino>
Although I guess we could get away without defining "equals" and just explicitly comparing the two site components...it would at least get us out of doing the registrable domain dance in the schemelessly algorithm.. at least I think..but I'm also nearly asleep

[04:34:45.0000] <MikeSmith>
oh wow, accidentally discovered that double-clicking a heading name in a README.md or other markdown doc at the GitHub site folds/collapses the entire contents of the section and its subsections, into an outline view

[04:35:48.0000] <MikeSmith>
and so if you double-click the title of the document, it folds the whole doc into an outline view/ToC

[04:36:30.0000] <ondras>
wow!

[04:36:57.0000] <annevk>
MikeSmith: I cannot reproduce on https://github.com/whatwg/fetch/blob/main/README.md, example?

[04:37:01.0000] <Rik`>
I don't see that behaviour

[04:37:14.0000] <ondras>
neither do i

[04:37:26.0000] <ondras>
looks like MikeSmith got abtested

[04:38:36.0000] <Rik`>
they've just released https://github.blog/changelog/2021-04-13-table-of-contents-support-in-markdown-files/ though

[04:41:54.0000] <MikeSmith>
hmm yeah I guess I must be an AB target

[04:42:40.0000] <MikeSmith>
hope they don’t untarget me and make it stop working

[04:43:24.0000] <MikeSmith>
it’s better than the separate ToC thing in Rik`’s link

[04:43:57.0000] <Rik`>
stop teasing us! :)

[04:44:04.0000] <MikeSmith>
heh

[11:23:07.0000] <Domenic>
TabAtkins: annevk: https://github.com/whatwg/html/pull/6360#issuecomment-821406855 is quite frustrating... will migrating away from Shepherd and toward xref allow us to stop being under plinss's control on how the HTML xref database gets assembled?

[11:23:46.0000] <TabAtkins>
it's a different parser, so sure

[11:24:30.0000] <Domenic>
Really looking forward to it...


2021-04-18
[15:44:04.0000] <ianlovejoy>
hello all, i would like to quickly sanity check a potential proposal before submitting an issue on github. i believe i have done my homework. is this an appropriate forum for that? (if not, sorry for the noise.)


2021-04-19
[04:59:42.0000] <annevk>
In case anyone is interested in historical trivia about innerHTML and <script>: https://bugzilla.mozilla.org/show_bug.cgi?id=155146#c10

[07:16:18.0000] <Domenic>
That *is* fun to know

[12:05:57.0000] <ianlovejoy>
hello all, would anyone here be willing to give a 1 minute sanity check on a potential proposal? i feel certain it must either already exist, or it did exist but was rejected, but i couldn't find it. i could also just proceed to file a github issue but i didn't want to create noise with a dup.

[12:23:38.0000] <annevk>
ianlovejoy: just post it here and check the logs later

[12:24:00.0000] <annevk>
ianlovejoy: you could also float it past WICG first

[12:26:43.0000] <ianlovejoy>
it's pretty simple to describe, so i think i'll just post it here, thanks! my apologies in advance if this has been discussed already.

[12:32:58.0000] <ianlovejoy>
i'm building a browser-based application with locally persistent state (IndexedDB) that talks to a server (via WebSockets) but is also intended to be resilient to temporary network failure. SharedWorker is a great help in keeping multiple tabs/windows in sync, but even so maintaining a messaging layer is adding more complexity than i'd like. so what i'd really like is to be able to have the page opt in to a single event loop / memo

[12:32:58.0000] <ianlovejoy>
ce across all tabs/windows, as would happen if one opened all the others. this is, of course, the way most native desktop and mobile apps work, and it allows sharing an in-memory model as well as a persistent model, without the need for a messaging layer.

[12:42:45.0000] <annevk>
ianlovejoy: I’m afraid no browser will want to change that. You’re stuck with messages of some kind

[12:43:57.0000] <ianlovejoy>
ok, thank you for the feedback! i was afraid of / expecting that answer… can i ask why they would not want to change that?

[12:44:34.0000] <ianlovejoy>
i mean, it's already implemented for the case where one tab opens another… "all" that is missing is the opt-in capability for independently opened tabs.

[12:45:51.0000] <ianlovejoy>
(i wouldn't ask except that i feel like this is a significant burden on all complex, stateful web based apps)

[12:49:32.0000] <annevk>
Poses challenges for responsiveness, back-forward cache. In general we want to enable more parallelism and reduce the issues popups brought

[12:50:35.0000] <annevk>
ianlovejoy: https://whatwg.org/faq#adding-new-features might of interest too; perhaps there are other solutions

[12:50:45.0000] <ianlovejoy>
ok, thank you for the feedback, much appreciated.

[12:52:48.0000] <ianlovejoy>
i have searched fairly extensively for other solutions, SharedWorker is the best i have found.

[12:54:02.0000] <ianlovejoy>
i've now taken up much more of your time than the promised one minute, so i will bug you no more, thangs again

[12:59:24.0000] <annevk>
ianlovejoy: there’s also BroadcastChannel (and service workers and storage events…)

[14:53:29.0000] <ianlovejoy>
annevk: yes indeed, thank you! and also of course IndexedDb transactions can be used to ensure data consistency in a multithreaded access scenario. the message / transactional store pattern is quite familiar to me (no doubt to all of us) from server development, but it does involve a fair amount of complexity.

[14:53:42.0000] <ianlovejoy>
when building a native client, given that there is only a single user at a time, i usually find it much simpler (no doubt we all do) to pass all access to local persistent state through a shared layer, which being a singleton can easily cache data in memory with complete accuracy, including complex derived data such as summary data.

[14:55:35.0000] <ianlovejoy>
also any changes to the data can be reflected in the interested view(s) through the observer pattern without worrying about race conditions that can occur in asynchronous messaging

[14:56:47.0000] <ianlovejoy>
i find this naturally reflects the user's conception of multiple windows as different views on the same underlying data

[14:57:31.0000] <ianlovejoy>
however, you have very nicely explained that i'm not going to get that for this project! so i'll take the messaging path. :)


2021-04-20
[21:49:38.0000] <annevk>
No <hr> in <select> support on iOS it seems

[23:56:26.0000] <annevk>
Oh nice, GitHub no longer uses the logo as tweet "artwork" https://twitter.com/fetchstandard/status/1384399222313730050

[23:57:47.0000] <annevk>
It does seem that has a different length limit than the default GitHub UI

[04:07:46.0000] <noamr>
hi annevk, anything missing from https://github.com/whatwg/fetch/pull/1202? I think we've deferred the open questions to other issues and I believed I handled the nits

[04:10:12.0000] <annevk>
noamr: there was some feedback I left here on IRC, e.g., that the timingInfo change isn't needed

[04:10:35.0000] <annevk>
noamr: we also need to update the cache state note

[04:11:29.0000] <noamr>
annevk: ah ok, I missed those notes

[04:11:30.0000] <noamr>
thanks

[05:09:13.0000] <annevk>
noamr: one more thing, cache state isn't passed on anymore

[05:26:29.0000] <noamr>
annevk: oops, amending

[05:27:25.0000] <noamr>
done

[07:44:12.0000] <noamr>
does anyone know where bikeshed gets its w3c spec info from? is it from https://github.com/w3c/browser-specs/ ? Trying to make it recognize resource-timing

[07:49:24.0000] <TabAtkins>
@noamr It's currently from a private DB that I have access to, please file an issue asking for a spec to be added.

[07:49:48.0000] <noamr>
TabAtkins: file an issue in which repo?

[07:49:57.0000] <noamr>
bikeshed?

[07:51:40.0000] <noamr>
https://github.com/tabatkins/bikeshed/issues/2024


2021-04-21
[23:57:40.0000] <annevk>
zcorpan_: did you see https://github.com/whatwg/html/pull/4816#discussion_r616848116?

[23:58:08.0000] <annevk>
zcorpan_: I think we should have some kind of resolution for that, no? Or at least make it very clear it's still an open issue

[01:59:34.0000] <zcorpan_>
annevk: I had missed your comment. I opened a new issue though, https://github.com/whatwg/html/issues/6473

[02:01:28.0000] <zcorpan_>
annevk: I'm not sure I follow your suggestion. What is the requirement for <ol> that applies to all UAs?

[02:09:53.0000] <zcorpan_>
annevk: for the question on which number an AT should use, is not tracked by that issue. I can create a separate issue

[03:25:56.0000] <annevk>
zcorpan_: the number derived from the rendering rules

[03:26:03.0000] <annevk>
zcorpan_: or index, for that matter

[03:51:37.0000] <annevk>
noamr: yoav: I suspect this is due to ReSpec or both TR/ and the editor's draft being indexed or some such, but https://whatpr.org/fetch/1202.html now talks about RESOURCE-TIMING and RESOURCE-TIMING-2 in the references section and sometimes the editor's draft is linked and sometimes the TR/ draft

[03:52:30.0000] <annevk>
TabAtkins: see line above, maybe that's something Bikeshed can solve, but I guess not really as it's somewhat fundamentally broken

[04:58:08.0000] <annevk>
MikeSmith: is https://github.com/w3c/webappsec-secure-contexts on your list?

[05:15:18.0000] <gsnedders>
is https://github.com/w3c/htmldiff-nav what whatpr uses (at least for HTML?)

[05:19:01.0000] <gsnedders>
(this is essentially "if I want to change that, should I be modifying that?")

[05:19:51.0000] <annevk>
gsnedders: https://github.com/w3c/htmldiff-ui I suspect

[05:20:24.0000] <annevk>
gsnedders: that looks like it's the script it includes for some additional functionality

[05:21:21.0000] <gsnedders>
annevk: right, that's the thing that creates the clickable/keyboard next/previous links

[05:22:04.0000] <annevk>
I kinda wish that were optional as I don't like us including scripts from other places, even on whatpr

[05:24:38.0000] <gsnedders>
could just rehost it on whatpr?

[05:31:04.0000] <annevk>
Yeah, there are solutions, but the problem is that this kinda appeared out of nowhere. I guess that's what you get when using mostly-free services though 🙂

[08:18:36.0000] <Domenic>
annevk: noamr: yoav: I'm really surprised with the approach you've all been taking on resource-timing. In the past when dealing with ReSpec specs we've just added a giant anchors block to the head so that we can guarantee to always link to the ED despite it being ReSpec-ey. Instead you've been linking to TR drafts and waiting for things to get published to TR so you can do so...

[08:21:16.0000] <annevk>
Domenic: oh we have? I might not have had that experience

[08:21:49.0000] <Domenic>
Yeah e.g. https://github.com/whatwg/dom/blob/f346858acfdb5ce30dfbad4c1383db2245b7f5ff/dom.bs#L23-L30

[08:21:52.0000] <annevk>
Domenic: what I remember from the past is that ReSpec wasn't in Shepherd at all

[08:22:16.0000] <Domenic>
I mean ReSpec EDs aren't in Shepherd at all and we generally only link to EDs

[08:24:14.0000] <annevk>
Seems fine to make that change

[08:24:34.0000] <annevk>
That would be better than the status quo, I hadn't really thought of it tbh

[10:14:58.0000] <hober>
Is it possible to change a username on the whatwg wiki?

[10:15:18.0000] <hober>
I just (re?)discovered that my username is... rather outdated.

[10:19:00.0000] <Domenic>
hober: it looks like it's not possible out of the box and we need an extension?? https://superuser.com/questions/1394701/how-to-change-a-username-in-mediawiki

[10:19:35.0000] <Domenic>
hober: but we're working this quarter to get the wiki onto a new hosting platform with reproducible builds (instead of just a server we maintain by hand) so we should be able to fold in things like installing very basic plugins as part of that

[10:19:43.0000] <Domenic>
Maybe we can do something sooner though

[10:20:11.0000] <Domenic>
GPHemsley: ^

[10:20:14.0000] <TabAtkins>
Domenic, annevk: The only reason Fetch refers to both Resource Timing 1 and 2 is because all the links are going to 2, but it has several biblio refs explicitly pointing to 1.

[10:21:12.0000] <Domenic>
TabAtkins: the problem is that [RESOURCE-TIMING] generates a biblio entry pointing to the ED but with a title "Resource Timing 1": https://whatpr.org/fetch/1202.html#biblio-resource-timing

[10:21:17.0000] <Domenic>
I think I've filed this issue before.

[10:23:31.0000] <hober>
Domenic: thanks :)

[10:25:51.0000] <TabAtkins>
Ahhh, right, *that's* because RESOURCE-TIMING is explicitly listed as an alias of RESOURCE-TIMING-1 in SpecRef currently https://www.specref.org/?q=resource-timing

[10:26:02.0000] <TabAtkins>
A PR to SpecRef can maybe fix that?

[10:26:54.0000] <TabAtkins>
And then Resource Timing 1's ED is listed as the live github file, which is *also* used for RT2, so that's just all sorts of confusion.

[10:27:09.0000] <TabAtkins>
But it's not something I think I can deal with generically. The underlying data source is just confused. :/

[10:28:03.0000] <TabAtkins>
Ah, but I guess if you're preferring the ED url then it is confusing, and collapsing those together should be doable.

[10:28:09.0000] <TabAtkins>
You might indeed have filed this issue before.

[10:28:57.0000] <TabAtkins>
But still, the underlying issue is in SpecRef due to that alias; Bikeshed can maybe paper over it with some auto-collapsing of entries with the same preferred url.

[10:32:44.0000] <Domenic>
Makes sense; I suspect in the past we've resolved such issues with specref PRs indeed.

[10:46:54.0000] <jugglinmike>
Hey there Domenic, do you think it's worthwhile to change step 3 from "if" to "while" and remove step 3.4? https://html.spec.whatwg.org/multipage/parsing.html#the-end

[10:47:27.0000] <Domenic>
jugglinmike: yes, that'd be a great cleanup.

[10:47:58.0000] <jugglinmike>
Cool, thanks for the confirmation. I'll write a patch

[15:15:42.0000] <MikeSmith>
annevk: about https://github.com/w3c/webappsec-secure-contexts you mean for setting up autopublishing?


2021-04-22
[21:39:36.0000] <annevk>
MikeSmith: not having to run Bikeshed yourself mainly

[21:43:31.0000] <MikeSmith>
annevk: OK, I can set it up today

[05:27:40.0000] <wCPO>
I'm a bit confused by this part of the URL spec: https://url.spec.whatwg.org/#fragment-state. You are not expected to encode [] as they aren't part of the https://url.spec.whatwg.org/#fragment-percent-encode-set, but they aren't part of the https://url.spec.whatwg.org/#url-code-points either, so you would get a validation error.

[05:29:47.0000] <annevk>
wCPO: not all URL records, when serialized, are valid URLs

[05:30:21.0000] <annevk>
wCPO: in this case if you wanted to use [ and ] in a URL fragment you'd have to encode them before handing the thing to the URL parser

[05:31:14.0000] <annevk>
(we could consider making them valid, but valid currently matches RFC3986 iirc so that'd be a somewhat big change)

[05:49:29.0000] <wCPO>
annevk: that is a bit confusing. Why doesn't "fragment percent-encode set" include all non-"URL code points"?

[05:51:32.0000] <annevk>
wCPO: because that's not what implementations do and that might not be compatible with the web

[05:52:45.0000] <annevk>
wCPO: if we started from scratch it'd be different, but implementations not aligning with the various URL specifications over the years and the ecosystem coding towards those implementations doesn't give a lot of wiggle room for a clean design

[06:12:10.0000] <wCPO>
Thanks for the explanation :) I got a bit wiser

[08:00:01.0000] <Domenic>
FWIW I also would prefer validation to match the serializer. https://github.com/whatwg/url/issues/379 is the tracking issue.

[16:15:53.0000] <GPHemsley>
wiki has been updated to MediaWiki 1.31.14 and Renameuser extension has been enabled

[16:16:25.0000] <GPHemsley>
hober, Domenic: what would you like to do next?

[16:19:36.0000] <Domenic>
Oh awesome, thanks GPHemsley! I'll let hober take it from here.

[16:21:20.0000] <GPHemsley>
ftr, any sysop now has permissions to rename users

[16:21:29.0000] <GPHemsley>
(in case I'm not around)

[16:25:15.0000] <GPHemsley>
sysop = administrator in the UI

[16:25:21.0000] <GPHemsley>
though users cannot rename themselves


2021-04-23
[20:53:25.0000] <MikeSmith>
we have two specs that define the Keyboard object?

[20:53:30.0000] <MikeSmith>
https://wicg.github.io/keyboard-map/#keyboard-interface

[20:53:37.0000] <MikeSmith>
https://wicg.github.io/keyboard-lock/#keyboard-interface

[20:53:48.0000] <MikeSmith>
neither is marked partial

[02:05:11.0000] <jgraham>
MikeSmith: Well WCIG things aren't specs :) But they also have the same editor so maybe they should talk to themselves

[02:15:22.0000] <MikeSmith>
jgraham: maybe it’s just a coincidence that the editors have exactly the same name

[02:15:32.0000] <MikeSmith>
and both work for google

[02:15:41.0000] <MikeSmith>
it’s a big company

[02:27:28.0000] <jgraham>
Giving them the same email address seems like an innovative solution to the problem that two people at a company sharing a name will have to spend roughly 10% of their waking hours redirecting email intended for the other one.

[03:21:57.0000] <milesrout>
the living standard page lags like hell

[03:22:07.0000] <milesrout>
not a good sign tbh

[07:30:45.0000] <Domenic>
JakeA: https://www.youtube.com/watch?v=CY-Zv0bmmRk wtffff

[07:31:02.0000] <Domenic>
There are parts of the spec that state this is impossible I am pretty sure

[07:31:41.0000] <JakeA>
Domenic: yeahhhh but if you follow those parts of the spec a load of good stuff breaks I think

[07:32:51.0000] <JakeA>
From memory, the spec says, when replacing a document in a history entry, other history entries using the same document should also be replaced. That's cool, as it makes reload work in a sensible way.

[07:33:55.0000] <JakeA>
What's less clear is doing a bunch of in-page navigations, navigating away, then going back. I think, in that case, the spec suggests each history entry will end up with its own document, as they're no longer associated by a single document. That seems bad.

[07:33:58.0000] <Domenic>
Well, it says contiguous entries, because it can't conceive if non-contiguous document sharing...

[07:34:23.0000] <JakeA>
There's nothing to make them contiguous if their document becomes null

[07:34:32.0000] <JakeA>
(in the current spec))

[07:35:07.0000] <Domenic>
Yeah

[07:35:16.0000] <Domenic>
Also the explicit use of "contiguous" is about window.name actually...

[07:36:18.0000] <JakeA>
In my PR, I've given session history entries a "document state", which can be shared between entries even if the document becomes null https://whatpr.org/html/6315/history.html#session-history-entry

[07:36:34.0000] <JakeA>
It's also where we can put stuff like "this was a srcdoc" and "this was created with a POST request"

[07:38:04.0000] <JakeA>
I guess the "document state" becomes the definition of "contiguous" (even though it doesn't need to be contiguous)

[07:39:41.0000] <Domenic>
Yeah, that sounds nice... well, perhaps not nice, but an elegant way of speccing current behavior...

[07:40:41.0000] <JakeA>
haha yeah. I think that's the best we can hope for.

[07:41:03.0000] <Domenic>
I'm very excited about getting the POST case interoperable... that's a super user-visible source of divergence.

[07:42:46.0000] <JakeA>
Yeah, although folks might not run into it much since sites tend to redirect to avoid the prompt later. But the spec has to say something :D

[07:43:17.0000] <JakeA>
I still don't really know why `document.open()` downgrades it to GET, but I'm just going to roll with that

[07:50:09.0000] <Domenic>
document.open() is like a history.pushState(), it does a same-document URL update.

[07:52:18.0000] <JakeA>
I guess I didn't know that, since it's always to the same URL (yeah?)

[07:54:19.0000] <Domenic>
No it's the URL of the caller

[07:55:23.0000] <JakeA>
ohh wait, when is that different to the current URL?

[07:55:35.0000] <Domenic>
So if you do `const iframe = document.createElement('iframe'); document.body.append(iframe); frames[0].document.open('<img src="foo.jpg">');` the `open()` call changes the URL from `about:blank` to the parent's URL, so that foo.jpg resolves as expected.

[07:56:22.0000] <JakeA>
hah!

[07:56:23.0000] <JakeA>
TIL

[07:56:29.0000] <Domenic>
Perhaps even more common is `const w = window.open(); w.document.open('...');`

[07:56:47.0000] <Domenic>
document.open() is the worst.

[07:57:03.0000] <JakeA>
haha yeah. But at least that bit makes sense to me now

[07:57:09.0000] <JakeA>
Thanks!


2021-04-25
[06:56:41.0000] <smaug____>
What does "Let result be « »." mean?

[06:57:07.0000] <smaug____>
aha, « » is defined in the infra

[06:57:11.0000] <andreubotella>
The empty list

[07:00:28.0000] <smaug____>
not very obvious syntax

[14:05:24.0000] <smaug____>
Am I missing something here, or is Chrome shipping something very different variable of imperative slotting API than what is in the spec

[14:05:35.0000] <smaug____>
https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/html/html_slot_element.idl;l=35 vs https://html.spec.whatwg.org/#htmlslotelement

[14:24:40.0000] <smaug____>
s/variable/variant/

[14:38:45.0000] <Domenic>
smaug____: that does seem really borked


2021-04-26
[00:36:07.0000] <MikeSmith>
Does anybody have any idea where SVGImageElement.prototype.decode() comes from?

[00:36:32.0000] <MikeSmith>
I can’t find it specified in either the SVG2 or SVG1.1 spec

[00:40:34.0000] <MikeSmith>
ah https://html.spec.whatwg.org/multipage/canvas.html#htmlorsvgimageelement

[00:42:44.0000] <MikeSmith>
in WebIDL what does "typedef (HTMLImageElement or SVGImageElement) HTMLOrSVGImageElement" mean?

[00:44:18.0000] <MikeSmith>
I mean, what does it say about inheritance?

[03:40:29.0000] <annevk>
MikeSmith: it says nothing about inheritance

[03:40:52.0000] <annevk>
MikeSmith: it just means that things taking HTMLOrSVGImageElement, take both those objects

[03:41:08.0000] <annevk>
(same when used as return value)

[03:42:18.0000] <annevk>
MikeSmith: maybe someone added it to SVGImageElement because HTMLImageElement has it and didn't bother to update the spec? That seems to become more common somehow :/

[10:43:35.0000] <wroathe>
Say someone wanted to write a standard compliant HTML parser... Do you guys know of any reliable sources of information on commonly used character encodings by region?

[10:45:38.0000] <wroathe>
I'm wondering if it's even worth the effort to support more than utf-8/16

[11:15:34.0000] <Domenic>
wroathe: seems like something hsivonen would have data on. Perhaps even in the posts on https://hsivonen.fi/


2021-04-27
[17:55:39.0000] <MikeSmith>
wroathe: https://w3techs.com/technologies/overview/character_encoding has some data

[17:56:27.0000] <wroathe>
MikeSmith: Thanks

[04:24:40.0000] <domfarolino>
annevk: I can take one more pass over the policy container PR if you wanna hold off on landing just a bit

[04:25:52.0000] <annevk>
domfarolino: sure, didn't see antosart reply yet so

[04:26:30.0000] <domfarolino>
Yeah I just wanted to let you know in case he replies before I get to it

[04:33:27.0000] <annevk>
Turns out that was good timing 🙂


2021-04-28
[05:48:49.0000] <annevk>
zcorpan: for https://github.com/whatwg/html/pull/4816 I guess I should also add a line that gives you credit, right?

[05:49:09.0000] <annevk>
zcorpan: ah, it already suggests Co-authored-by: Simon Pieters <zcorpan⊙gc> so I'll keep that

[05:49:25.0000] <zcorpan>
annevk: sounds good

[05:49:27.0000] <annevk>
zcorpan: and I'll keep the issue open for now and hopefully that can be sorted independently?

[05:49:51.0000] <zcorpan>
annevk: yeah, i'll look into it

[05:51:56.0000] <annevk>
zcorpan: ta!

[05:52:08.0000] <zcorpan>
thx

[06:44:13.0000] <MikeSmith>
How do I figure out which spec defines a "memory" member for the Performance object?

[06:46:36.0000] <zcorpan>
MikeSmith: you look in chromium's idl files https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/timing/performance.idl;l=66

[06:48:53.0000] <MikeSmith>
zcorpan: aha

[06:48:56.0000] <MikeSmith>
thanks

[06:51:01.0000] <jgraham>
MikeSmith: https://github.com/mozilla/standards-positions/issues/85#issuecomment-426382208

[06:55:24.0000] <JakeA>
Domenic: You were right, some history stuff is 'contiguous' and it leads to weirdness https://github.com/whatwg/html/issues/6628

[06:55:25.0000] <jgraham>
I can't find the metrics about usage

[06:57:21.0000] <jgraham>
I think https://www.chromestatus.com/metrics/feature/timeline/popularity/3139 is measureUserAgentSpecificMemory which is https://wicg.github.io/performance-measure-memory/#dom-performance-measureuseragentspecificmemory


2021-04-29
[23:13:22.0000] <noamr>
Hey, does anyone know how FETCH gets ServiceWorker refs? https://w3c.github.io/ServiceWorker/#service-worker-service-worker-timing-info is exported but I can't see it in bikeshed for FETCH.

[23:14:31.0000] <noamr>
JakeA / annevk when you're up and about :) ^^^

[23:17:06.0000] <annevk>
noamr: have you updated bikeshed?

[23:17:52.0000] <noamr>
annevk: using the online bikeshed API, do I need to update something?

[23:18:00.0000] <noamr>
(the Makefile in FETCH)

[23:19:09.0000] <annevk>
noamr: in that case it should work; you're using the relevant for attribute? If it's all good, file a bug against bikeshed, perhaps Shepherd (the indexing tool) got stuck again

[23:19:59.0000] <noamr>
annevk: I believe so, I'm using for=/ as it's a struct that's not associated with something. I'll file a bikeshed bug :/ thanks

[23:20:10.0000] <annevk>
noamr: looking at that <dfn> it seems kinda bogus btw, it shouldn't be for="service worker", only the member on a service worker pointing to it should be for="service worker"

[23:20:27.0000] <annevk>
noamr: yeah so it's wrong in the service workers spec

[23:20:34.0000] <noamr>
ah

[23:21:30.0000] <noamr>
in the spec though it just says "<dfn export>service worker timing info</dfn>"

[23:21:30.0000] <annevk>
noamr: perhaps they have some kind of global for attribute that the <dfn> ended up inheriting?

[23:21:52.0000] <noamr>
maybe, I guess it's ok though and I need <a for="service worker"> in FETCH

[23:22:09.0000] <annevk>
noamr: I think we should fix it

[23:24:22.0000] <noamr>
I just wish there was a way to do this without another week of IPR cycle for a 6-character fix

[23:24:35.0000] <noamr>
it's a lot of beurocracy for very small fixes

[23:26:43.0000] <noamr>
... but if that's what's required, sure

[23:28:38.0000] <noamr>
https://github.com/noamr/ServiceWorker/pull/new/fix-struct

[23:29:06.0000] <MikeSmith>
noamr: IPR part should be OK now

[23:29:43.0000] <noamr>
thanks MikeSmith!

[23:30:05.0000] <MikeSmith>
cheers

[23:47:53.0000] <annevk>
https://blog.whatwg.org/update-from-the-steering-group (most of this concluded a while back, so this might not be news to any of you)

[01:12:00.0000] <JakeA>
noamr: I've replied to the PR. The definition is in the wrong section. Sorry I didn't catch this first time around. I'll land it as soon as you update it

[01:12:10.0000] <JakeA>
https://github.com/w3c/ServiceWorker/pull/1590#issuecomment-829028609

[02:49:16.0000] <JakeA>
noamr: merged

[03:00:47.0000] <noamr>
Thanks JakeA!

[07:31:29.0000] <annevk>
andreubotella: hey so just to be clear, <textarea> is broken either way right and this PR doesn't materially change that?

[07:33:17.0000] <andreubotella>
annevk: it's not that textarea is broken, but that the wrapping algorithm normalizes to CRLF when in Firefox and Safari it's to LF

[07:33:44.0000] <andreubotella>
so the change in that algorithm would go together with removing the newline normalization when constructing the entry list

[07:36:55.0000] <andreubotella>
just removing the normalization without changing the textarea wrapping algorithm would give the wrong result for textarea while fixing the rest

[07:37:10.0000] <annevk>
andreubotella: I guess I still fail to see how <textarea> is not already broken

[07:38:06.0000] <andreubotella>
if we consider Firefox/Safari's behavior the right thing, then yeah, it's broken

[07:38:07.0000] <annevk>
Not disagreeing that we shouldn't fix it though

[07:38:45.0000] <annevk>
Hmm, do Firefox/Safari do the <textarea> thing across all platforms?

[07:39:03.0000] <annevk>
If not, status quo might be preferable


2021-04-30
[19:12:11.0000] <alystair>
Just posted this - I'm new to WHATWG so triage would be appreciated: https://github.com/whatwg/dom/issues/976 (":active pseudo-class specification doesn't account for children of disabled form elements")

[23:15:21.0000] <alystair>
thanks for triage annevk

[23:29:17.0000] <annevk>
domfarolino: any ETA for the policy container review?

[02:42:29.0000] <annevk>
Now that Twitter supports logging into multiple accounts, I'll make @WHATWG retweet assorted commit tweets from the various standards. Let me know if there are other things it should be tweeting about.

[06:45:14.0000] <domfarolino>
annevk: Sorry I lost track of it. I'll review it today

[08:56:39.0000] <MikeSmith>
https://test262.report/ timing out

[08:57:34.0000] <MikeSmith>
zcorpan: any idea if that’s just some temporary outage, or not?