2022-05-01
[13:08:38.0690]
I may have gotten emails working from wiki.whatwg.org, if anyone wants to test the "forgot my password" link. (I cannot test it for another 24 hours...)
[13:38:38.0014]
why on earth is getGamePads on Navigator
[15:17:12.0732]
There is some superstition about putting things on the global so people started using navigator as a dumping ground
[15:17:22.0927]
I try to discourage it when possible but hard to catch everything
[15:57:26.0462]
so weird
[16:14:10.0294]
Hi, I am reading HTML living standard. I do not quite understand the syntax used here. https://html.spec.whatwg.org/multipage/images.html#source-size-list
[16:14:58.0392]
Where can I find explainations about these syntax?
[16:15:29.0167]
krave: that's CSS syntax: https://drafts.csswg.org/css-syntax/
[16:18:40.0760]
For example, the brackets, sharp, comma, and question mark in `[ # , ]? `
[16:20:39.0622]
> <@emilio:mozilla.org> krave: that's CSS syntax: https://drafts.csswg.org/css-syntax/
Thank you emilio . That looks like a very big document though.
[16:21:03.0958]
Any hint about this specific sentance? `[ # , ]? `
[16:42:54.0045]
krave: I guess https://drafts.csswg.org/css-values-4/#value-defs is the document that actually defines those combinators
[16:43:00.0215]
What about that specific bit?
[16:43:23.0729]
`#` is a multiplier as per https://drafts.csswg.org/css-values-4/#component-multipliers
[16:43:51.0815]
so that means, "optionally, ``s separated by commas, then one mandatory ``"
[16:43:53.0798]
* so that means, "optionally, ``s separated by commas, then one mandatory ``"
2022-05-02
[08:38:07.0226]
> <@tabatkins:matrix.org> zcorpan: Yeah, looks like the server wedged itself yesterday morning. Kicking it now.
Seems like it's still failing - LINK ERROR: No 'dfn' refs found for 'expose legacy touch event apis'.
[10:08:47.0699]
WTF is a popsicle?
[10:14:44.0164]
zcorpan: could it be because it's not a generated document? ReSpec tends to have issues
[10:16:00.0652]
zcorpan: hardlinking from DOM might be the way to go, same as we do for DOMHighResTimeStamp and friends
[10:16:31.0890]
annevk: ah yeah maybe that's the issue. ok
[10:16:48.0906]
I wish folks would stop using ReSpec, but then we still have Wattsi so...
[10:17:22.0413]
wattsi ReSpec
[10:17:59.0836]
Maybe bikeshed could use Webref instead of scraping?
[10:18:32.0558]
There's an issue for that somewhere
[11:10:52.0188]
Yes, last time I worked on it I got 99% of the way thru but WebIDL was suddenly causing weird biblio entries that I *coudl not* figure out, so I stalled. Working on tangential code-quality stuff in the area instead right now, but it's in my OKRs for the quarter.
[11:12:03.0730]
emilio, krave: Yes, the CSS Values & Units spec is the defining doc for CSS's value grammar. (The Syntax spec just adds some additional bits for defining *whole rules*, which aren't covered by the V&U stuff since it's not needed.)
[11:13:51.0418]
zcorpan: Tho moving to WebRef is the correct idea, I'll note that Bikeshed subtly encouraging ReSpec users to *actually publish a formatted document instead of inflicting the rest of us with the flash-of-plain-text spec* is a Good Thing imo
[11:45:52.0723]
TabAtkins: agreed
[12:29:31.0140]
TabAtkins: filing issues on such specs might be more effective though, in this case the editors of the spec aren't the ones to feel the pain
[15:07:10.0303]
annevk or Domenic: the maplike/setlike @@iterator and forEach have text detailing where the methods live, depending on whether the interface is [Global] or not. The rest of the methods don't; they're defined to just live on the interface prototype object. It looks like this *might* get handled generically instead by the "interface prototype object" text but the details of the algo confuse me so I'm not sure. Do y'all know if the distinctions in spec text are intentional, or just editorial slippage that should be aligned?
[15:08:44.0467] <짜요>
hello!
I had a question while developing.
I'm using title attribute related html5, but the number of characters seen by each browser is different. Chrome and edge are the same and safari shows more, I wonder Do you know how much the title attribute can show by browser?
[15:10:58.0898]
> <@tabatkins:matrix.org> annevk or Domenic: the maplike/setlike @@iterator and forEach have text detailing where the methods live, depending on whether the interface is [Global] or not. The rest of the methods don't; they're defined to just live on the interface prototype object. It looks like this *might* get handled generically instead by the "interface prototype object" text but the details of the algo confuse me so I'm not sure. Do y'all know if the distinctions in spec text are intentional, or just editorial slippage that should be aligned?
I think this is semi-intentional in that it reflects the incomplete transition to imperativizing everything. If you are imperativizing the installation of those properties then it shouldn't be necessary. But right now I think they are not added imperatively anywhere, it is just "they must exist" and that text is the only normative text saying that they must exist and when they must exist.
[15:11:33.0696]
Some previous PRs linked from https://github.com/whatwg/webidl/issues/467
[15:11:36.0101]
Okay, I'm not touching the imperativeness yet, so I'll just leave it as-is.
2022-05-03
[00:08:04.0184]
짜요: all I know is that there's no standardized limit
[02:39:44.0189]
annevk: Can we move https://github.com/w3c/preload/issues/115 to HTML, now that the HTML integration is complete? I'm trying to archive the old rep
[02:39:45.0876]
o
[02:40:37.0411]
Actually, same question for the various "enhancement" issues
[02:47:18.0412]
Yoav Weiss: that seems reasonable, we should maybe have a label for them then
[02:59:52.0129]
SG!
[07:53:12.0263]
Yeah I've been using "topic: link" for preload etc. but maybe something dedicated is helpful. "topic: resource hints"?
[08:46:39.0438]
Is "topic: resource hints (preload)" too wordy? Would also be nice to add "topic: timing" to HTML
[09:17:16.0464]
Well resource hints also includes preconnect
[09:24:50.0543]
Yeah I realize and maybe prefetch? It's just that preload comes up a lot and it would be nice to be able to search for one of them. Could make it (inc. preload) if wordy isn't a problem
[09:25:11.0762]
* Yeah I realize and maybe prefetch? It's just that preload comes up a lot and it would be nice to be able to search for one of them. Could make it (inc. preload) if wordy isn't a problem
[10:55:20.0262]
annevk: how about `topic: resource hints/preload`
[11:41:49.0314]
Domenic: hi, I want to try to find a good direction for the link header/element refactor
[11:43:30.0134]
The way I was going was that all links are converted to the same "options" struct, either from a header or from an element, and then there is no need for each rel to do special header processing
[11:45:13.0096]
... but I can also go with having different "process header" and "process element" algorithms that end up funneling to functions like "preload" or "preconnect"
[12:26:54.0007]
Noam Rosenthal: so my main concern is the clarity of reading a given element's section. I am hoping: (a) it can be clear at a glance whether it supports elements/headers/early hints; (b) we move away from a defaults-and-overrides structure; (c) there is minimal duplication/maximal shared infrastructure.
[12:30:52.0914]
Domenic: ok, for (c) - I think it would be good if the common "Process link headers" extracted something like the options struct from the headers, before sending it to the different `rel` sections
[12:31:21.0673]
+1
[12:31:34.0873]
Options structs are good
[12:31:44.0739]
Just commented on the thread too
[12:32:48.0207]
(b) is mostly about fixing a preexisting problem but I think if we're doing (a) and (c) at the same time it's worth tackling (b)
[12:33:51.0803]
ok, but without (b) and with options struct, how would you spell out the "process early hints" -> "handle headers for this type of link" transition?
[12:34:29.0110]
at some points we went through a list of headers, and for each item we did something if it's defined for its `rel`
[12:34:37.0567]
* at some points we went through a list of headers, and for each item we did something if it's defined for its `rel`
[12:35:34.0545]
I guess by having "to handle headers for this type of link, do nothing" for each unsupported `rel` type?
[12:37:14.0311]
Yes exactly
[12:37:38.0355]
I think that's nice and super-obvious
[12:38:00.0310]
But we could also do something like "supported processing types"
[12:38:24.0650]
sure I can go with that. Sometimes my natural tendency is more minimalistic (defaults) but it's not always the most obvious for readers
[12:39:01.0151]
I think the "do nothing" duplication would be better than a list of supported types. It allows us to add new types without maintaining it in separate places
[12:39:14.0025]
Noam Rosenthal: probably-unrelated question, do I correctly recall you had some PR which removed "process response end of body" from navigation params?
[12:39:40.0874]
* Noam Rosenthal: probably-unrelated question, do I correctly recall you had some PR which removed "process response end of body" from navigation params?
[12:42:15.0324]
Domenic: it was a PR that had many iterations (https://github.com/whatwg/html/pull/7531) and I believe you're referring to one of the iterations of the PR where we removed it and brought it back
[12:42:34.0565]
Hmm OK
[12:43:05.0884]
(I'm trying to make sure https://github.com/whatwg/html/pull/6315 stays up to date)
[12:43:39.0621]
That navigation param was the cleanest way we found to report the iframe resource timing to the parent. There's no pending open PR that removes it (at least not one that I'm working on)
[12:44:06.0973]
Yeah I couldn't find one, so just wanted to double-check. No problem with keeping it.
[12:46:06.0728]
Domenic: re the editorial I think I have enough to go on for tomorrow. If you think more comments add them to the issue and I'll see them in the morning?
[12:49:08.0021]
Sounds good, will leave any if I do! I think we have a good path.
2022-05-04
[23:39:44.0206]
annevk: Added a label to all remaining issues in https://github.com/w3c/preload/issues but it seems like I can't transfer this issue to a repo in another org
[23:40:13.0762]
Not sure if this is a permissions thing, and if e.g. I give you permissions on the preload repo, you'd be able to get them transferred
[23:40:43.0068]
Yoav Weiss: oh sorry, I'm pretty sure you cannot transfer issues across organizations
[23:40:59.0245]
hmm.
[23:41:24.0430]
In that case, it may be easiest for me to open new ones, pointing at these (by then archived) ones
[23:41:56.0191]
Yeah, the alternative would be transferring the repository, but that doesn't seem great
[23:42:18.0125]
yeah, agree
[23:44:15.0153]
zcorpan: hgroup styles removed is a nice cleanup
[23:51:52.0569]
annevk: Can you add a "preload" label on https://github.com/whatwg/html/issues/7887 https://github.com/whatwg/html/issues/7888 and https://github.com/whatwg/html/issues/7889?
[00:08:59.0781]
I've added the label I suggested yesterday to a bunch of issues, including those (not entirely sure it's the best name as "resource hints" is not a term we use in HTML; so if anyone has something better let me know)
[03:50:43.0446]
I think "resource hints" is the best name, as it describes the adjacent spec (https://w3c.github.io/resource-hints/) which some of those still link to. The term Is used in HTML when linking to that spec
[05:02:08.0494]
Ah okay, I wasn't sure, though it seems that over time that specification might get fully integrated
[05:13:51.0102]
> <@annevk:mozilla.org> Ah okay, I wasn't sure, though it seems that over time that specification might get fully integrated
I hope we will integrate the whole thing, in which case it's good that the label would be consistent with the then-historic title
[06:25:44.0149]
PSA for anybody interested in committer/issue/PR metrics for repos you manage or contribute to…
A few things I want to have stats/numbers for but which aren’t provided by any existing tools:
- At what rate is the project gaining new contributors?
- At what rate is the list of open issues increasing or decreasing?
- At what rate is the list of open PRs increasing or decreasing?
- How many commits are getting merged each month?
- How many contributors are actually active each month?
…so, I wrote a tool that generates data and graphs to answer those questions.
https://github.com/git-pulse/tools
[06:25:59.0956]
* PSA for anybody interested in committer/issue/PR metrics for repos you manage or contribute to…
A few of the things I’ve wanted to have some stats/numbers for but which aren’t provided by any existing tools:
- At what rate is the project gaining new contributors?
- At what rate is the list of open issues increasing or decreasing?
- At what rate is the list of open PRs increasing or decreasing?
- How many commits are getting merged each month?
- How many contributors are actually active each month?
…so, I wrote a tool that generates data and graphs to answer those questions.
https://github.com/git-pulse/tools
[06:26:22.0813]
* PSA for anybody interested in committer/issue/PR metrics for repos you manage or contribute to…
A few things I want to have stats/numbers for but which aren’t provided by any existing tools:
- At what rate is the project gaining new contributors?
- At what rate is the list of open issues increasing or decreasing?
- At what rate is the list of open PRs increasing or decreasing?
- How many commits are getting merged each month?
- How many contributors are actually active each month?
…so, I wrote a tool that generates data and graphs to answer those questions.
https://github.com/git-pulse/tools
[06:26:30.0399]
* PSA for anybody interested in committer/issue/PR metrics for repos you manage or contribute to…
A few things I want to have stats/numbers for but which aren’t provided by any existing tools:
- At what rate is the project gaining new contributors?
- At what rate is the list of open issues increasing or decreasing?
- At what rate is the list of open PRs increasing or decreasing?
- How many commits are getting merged each month?
- How many contributors are actually active each month?
…so, I wrote a tool that generates data and graphs to answer those questions.
https://github.com/git-pulse/tools
[06:31:16.0766]
annevk: Regarding https://github.com/whatwg/html/issues/6364, we've got feedback from Google, Facebook and Zoom who all seem to agree that the COOP: Popups proposal would work for them. Do you have any other group you'd like to verify that solution works for? Given the complexity of the topic and the length of the discussion, I don't really know how to get smaller entities feedback.
[07:23:20.0112]
Arthur Hemery: I guess auth0 might be good to ask? Perhaps a way to get some attention from the login community would be a short email to https://lists.w3.org/Archives/Public/public-fed-id/?
[07:34:10.0894]
Thanks for the pointers, doing that now :)
[13:42:01.0874]
Domenic: DefaultValue is also used for dictionary members, which can't be undefined 🙄
[13:45:16.0226]
peterv: sure, not everything that's disallowed must be grammatically disallowed.
[13:45:40.0008]
yeah, I know, just that we'll need some more prose
[13:45:58.0045]
I thought this would be trivial grammar change
2022-05-05
[03:39:05.0707]
I'm looking at WPT's update_html5lib_tests.py and I don't see a way to point it to a local (and modified) instance of https://github.com/html5lib/html5lib-tests . What am I missing?
[04:20:23.0859]
I'm not sure you are missing something
[04:30:03.0792]
Yeah, confirmed elsewhere that what I wanted to do isn't a supported action.
[07:21:12.0327]
hsivonen: it needs a rewrite I think, see https://github.com/web-platform-tests/wpt/issues/27868
[07:25:47.0982] element is blocked on that issue :(
[07:29:23.0861]
annevk: ping on https://github.com/whatwg/html/pull/7876 , hoping to get that in so I can work on import maps spec
[10:29:00.0361]
Okay, I was hoping to get to it, but given the size it'll have to be tomorrow; hopefully done by the time you get up
2022-05-06
[01:17:41.0815]
Hmm, cssom-view spec broke? https://drafts.csswg.org/cssom-view/
[01:18:02.0019]
That gives only the directory listing
[01:18:56.0650]
TabAtkins: ^
[01:19:41.0688]
drafts.csswg.org breaks sometimes
[01:19:46.0360]
I have a mirror at https://andreubotella.com/csswg-auto-build/cssom-view
[10:51:00.0277]
Hi all!
[10:51:45.0675]
I have an interesting idea to make the web safer, I would like everyone's opinion!
[10:53:15.0505]
Here ``````
[10:53:51.0712]
What if we had a new attribute in the input field for passwords?
[10:54:15.0625]
An attribute to encrypt passwords?
[10:54:35.0939]
Wouldn't you then have to have the RSA key in plain text in the page's code?
[11:04:35.0442]
My idea is... that... so everything stays in localStorage - data stored here continues to exist even after being closed and reopened. This would not be saved in plaintext! ... Localstorage allows for example to manage some things in session... So good question.
[11:04:55.0819]
* My idea is... that... so everything stays in localStorage - data stored here continues to exist even after being closed and reopened. This would not be saved in plaintext! ... Localstorage allows for example to manage some things in session... So good question.
[11:05:46.0809]
* My idea is... that... so everything stays in localStorage - data stored here continues to exist even after being closed and reopened. This would not be saved in plaintext! ... Localstorage allows for example to manage some things in session... So good question.... I hope I helped answer this question or clarified something about it.
[11:06:14.0645]
* My idea is... that... so everything stays in localStorage - data stored here continues to exist even after being closed and reopened. This would not be saved in plaintext! ... Localstorage allows for example to manage some things in session... So good question.... I hope I helped answer this question or clarified something about it...
[11:09:50.0961]
* My idea is... that... so everything stays in localStorage - data stored here continues to exist even after being closed and reopened. This would not be saved in plaintext! ... Localstorage allows for example to manage some things in session... So good question.... I hope I helped answer this question or clarified something about it... Another option that I think of to solve this problem... if localstorage is something insecure, we can generate a qrcode... that way the user can have access to their encrypted passwords on each site without necessarily having saved something in the browser or without having necessarily use a program that generates things like rsa
[11:10:38.0663]
* My idea is... that... so everything stays in localStorage - data stored here continues to exist even after being closed and reopened. This would not be saved in plaintext! ... Localstorage allows for example to manage some things in session... So good question.... I hope I helped answer this question or clarified something about it... Another option that I think of to solve this problem... if localstorage is something insecure, we can generate a qrcode... that way the user can have access to their encrypted passwords on each site without necessarily having saved something in the browser or without having necessarily use a program that generates things like rsa - reference: https://github.com/w3c/csswg-drafts/issues/6544
[11:11:09.0723]
* My idea is... that... so everything stays in localStorage - data stored here continues to exist even after being closed and reopened. This would not be saved in plaintext! ... Localstorage allows for example to manage some things in session... So good question.... I hope I helped answer this question or clarified something about it... Another option that I think of to solve this problem... if localstorage is something insecure, we can generate a qrcode... that way the user can have access to their encrypted passwords on each site without necessarily having saved something in the browser or without having necessarily use a program that generates things like rsa - reference: https://github.com/w3c/csswg-drafts/issues/6544 ... There is a discussion of creating an html element for qrcode
[11:11:20.0212]
* 1. My idea is... that... so everything stays in localStorage - data stored here continues to exist even after being closed and reopened. This would not be saved in plaintext! ... Localstorage allows for example to manage some things in session... So good question.... I hope I helped answer this question or clarified something about it... Another option that I think of to solve this problem... if localstorage is something insecure, we can generate a qrcode... that way the user can have access to their encrypted passwords on each site without necessarily having saved something in the browser or without having necessarily use a program that generates things like rsa - reference: https://github.com/w3c/csswg-drafts/issues/6544 ... There is a discussion of creating an html element for qrcode
[11:12:08.0473]
* Hi!
1. My idea is... that... so everything stays in localStorage - data stored here continues to exist even after being closed and reopened. This would not be saved in plaintext! ... Localstorage allows for example to manage some things in session...
2. So good question.... I hope I helped answer this question or clarified something about it...
3. Another option that I think of to solve this problem... if localstorage is something insecure, we can generate a qrcode... that way the user can have access to their encrypted passwords on each site without necessarily having saved something in the browser or without having necessarily use a program that generates things like rsa - reference: https://github.com/w3c/csswg-drafts/issues/6544 ... There is a discussion of creating an html element for qrcode
[11:12:30.0631]
* @Hi!
1. My idea is... that... so everything stays in localStorage - data stored here continues to exist even after being closed and reopened. This would not be saved in plaintext! ... Localstorage allows for example to manage some things in session...
2. So good question.... I hope I helped answer this question or clarified something about it...
3. Another option that I think of to solve this problem... if localstorage is something insecure, we can generate a qrcode... that way the user can have access to their encrypted passwords on each site without necessarily having saved something in the browser or without having necessarily use a program that generates things like rsa - reference: https://github.com/w3c/csswg-drafts/issues/6544 ... There is a discussion of creating an html element for qrcode
[11:12:40.0056]
1. My idea is... that... so everything stays in localStorage - data stored here continues to exist even after being closed and reopened. This would not be saved in plaintext! ... Localstorage allows for example to manage some things in session...
2. So good question.... I hope I helped answer this question or clarified something about it...
3. Another option that I think of to solve this problem... if localstorage is something insecure, we can generate a qrcode... that way the user can have access to their encrypted passwords on each site without necessarily having saved something in the browser or without having necessarily use a program that generates things like rsa - reference: https://github.com/w3c/csswg-drafts/issues/6544 ... There is a discussion of creating an html element for qrcode
[11:13:12.0029]
> <@abotella:igalia.com> Wouldn't you then have to have the RSA key in plain text in the page's code?
* 1. My idea is... that... so everything stays in localStorage - data stored here continues to exist even after being closed and reopened. This would not be saved in plaintext! ... Localstorage allows for example to manage some things in session...
2. So good question.... I hope I helped answer this question or clarified something about it...
3. Another option that I think of to solve this problem... if localstorage is something insecure, we can generate a qrcode... that way the user can have access to their encrypted passwords on each site without necessarily having saved something in the browser or without having necessarily use a program that generates things like rsa - reference: https://github.com/w3c/csswg-drafts/issues/6544 ... There is a discussion of creating an html element for qrcode
[11:15:44.0194]
```html
```
[11:15:52.0565]
* ```html
```
[11:16:14.0804]
* ```html
```
[11:16:22.0284]
* ```html
```
[11:21:00.0515]
4. I deleted the message... because I didn't know it had a reply option. So, sorry
[11:21:37.0976]
* 4. I deleted the message... because I didn't know it had a reply option. Sorry then
[11:21:47.0167]
* 4. I deleted the message... because I didn't know it had a reply option. So, sorry
[11:22:48.0595]
5. I read about it, here is my bibliographic references: https://www.tomsguide.com/news/dont-let-web-browsers-save-passwords, https://www.techrepublic.com/article/why-you-should-never-allow-your-web-browser-to-save-your-passwords/ , https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API/Using_the_Web_Storage_API , https://www.techadvisor.com/feature/security/safe-store-passwords-in-browser-3813506/ , https://discourse.wicg.io/t/proposal-webcrypto-argon2-curve-448-25519-secp256k1-chacha20-poly1305/5132
[11:39:58.0681]
**I want you to criticize my argument with positive and negative points**
***Argument:***
1. Many systems and internet sites are still old stuff, some of them don't use encryption... and even if they did, the user usually creates easy passwords...
2. My objective in proposing the encrypted attribute would be to tell browsers that they manage the passwords of the users...
3. I argue about this... because for you to be on the internet you usually have to have a browser... in part the passwords should be managed by the website providers, by the browsers and by the users... but the reality is different ...
4. Usually users put easy passwords and generally some sites do not have encryption or security policy ...
5. I think that this change in information security ... could be changed ... if browsers or the internet itself had a new attribute to html to make this possible
6. Every change is something to think about... I just had this idea and I want to hear all sides
7. This new attribute wouldn't be for plaintext... it should somehow be managed by localstorage if possible or maybe create a qrcode with that information
[11:43:28.0980]
Note: Please don't think of this sentence as arrogance, my wish is to know if the argument is valid or not
[11:53:35.0742]
* Note: Please don't think of this sentence as arrogance, my wish is to know if the argument is valid or not. more reference: https://www.w3.org/TR/WebCryptoAPI/
[11:54:24.0678]
I think https://whatwg.org/faq#adding-new-features , especially step 1, is probably valuable here
[12:20:00.0274]
> <@domenicdenicola:matrix.org> I think https://whatwg.org/faq#adding-new-features , especially step 1, is probably valuable here
thank for feedback
[12:20:13.0467]
> <@domenicdenicola:matrix.org> I think https://whatwg.org/faq#adding-new-features , especially step 1, is probably valuable here
* thank for feedback
[12:20:59.0701]
* thank for feedback... looking at it now, i think this idea is bad. Thank you so much for everyone's attention
2022-05-07
[17:21:19.0845]
On https://html.spec.whatwg.org/multipage/dom.html#global-attributes:
>While these attributes apply to all elements, they are not useful on all elements. For example, only media elements will ever receive a volumechange event fired by the user agent.
Why does it need to exist there then? That paragraph does not explain why, maybe just a legacy reason?
[11:00:38.0477]
hello
[15:23:42.0300]
> <@krosylight:mozilla.org> On https://html.spec.whatwg.org/multipage/dom.html#global-attributes:
>
> >While these attributes apply to all elements, they are not useful on all elements. For example, only media elements will ever receive a volumechange event fired by the user agent.
>
> Why does it need to exist there then? That paragraph does not explain why, maybe just a legacy reason?
Bubbling, for many of them. Probably consistency, for the rest.
2022-05-08
[17:24:14.0455] <•ʟᴜᴄɪғᴇʀ•>
Hello
2022-05-09
[00:54:45.0992]
Happy birthday Jake Archibald! 🧁
[08:09:58.0588]
annevk: I am trying to determine if I have any next steps on this PR. If not, I'd like to see if I can get this moved forward to unblock implementers that are waiting on the approval/merge.
https://github.com/whatwg/html/pull/7678
2022-05-10
[02:45:51.0427]
annevk: thank you!
[13:44:47.0425]
are document navigation, workers, and worklets the only way environments or environment settings can be created?
[13:45:03.0568]
* are document navigation, starting workers, and starting worklets the only way environments or environment settings can be created?
2022-05-11
[00:42:53.0372]
Doug Conmy: can you ping me again next week maybe? I have some other things I need to tackle first
[00:43:32.0014]
wanderview: yeah
[01:02:01.0778]
Wiki's dead?
[04:07:39.0570]
Can infra tuples be destructured? Ie:
Set (body, type) to the result of extracting init.
Where "extracting init" returns a tuple of (body, type)
[04:08:47.0046]
Luca Casonato: I think I saw someone do that without objection, but technically it's not defined in Infra
[04:08:55.0776]
* Luca Casonato: I think I saw someone do that without objection, but technically it's not defined in Infra
[04:10:23.0678]
ok, i'll just do it the normal way then. i should go open a PR for this to infra
[04:10:25.0154]
thanks!
[04:28:02.0996]
Luca Casonato: that'd be great
[04:30:16.0139]
annevk: On that note, I split out the "body with type" changes from fetch#1392 into https://github.com/whatwg/fetch/pull/1439. It's purely editorial, so should be relatively easy to land :)
[07:52:40.0549]
is `encodeURI()` something folks are recommended to use? it seems to escape things differently than the URL spec
[07:58:38.0365]
wanderview: depending on what you need it's okay; I don't think we should build things on top of it though
[07:59:40.0507]
in this case someone filed a urlpattern-polyfill bug because they expected `[]` in pathname to be encoded like `encodeURI()` does, but we follow URL spec and do not encode that
[08:16:23.0480]
Oh interesting, I've never seen a request like that for the URL standard
[08:16:46.0472]
Speaking of which, when is URLPattern getting standardized?
[08:21:11.0437]
> <@annevk:mozilla.org> Speaking of which, when is URLPattern getting standardized?
it is standardized: wicg.github.io/urlpattern
[08:21:44.0968]
Luca Casonato: WICG is not a standards body
[08:23:00.0916]
Ah sorry - I misinterpreted that question then. Was the intention that it ends up in the URL spec? Or a as a separate WHATWG spec?
[08:23:04.0318]
At least in Mozilla when we talk about "standardized" it's roughly what's written down at https://wiki.mozilla.org/ExposureGuidelines#Ensure_that_the_feature_is_standardized
[08:23:46.0255]
I think either could work, but wanderview at some point expressed an interest in a separate spec, could be the same Workstream though
[08:24:52.0498]
If there is interested from Mozilla on implementation btw, it might make sense to hop on a call. We have a fully compliant, pluggable implementation in Rust already that could be used as a baseline for Gecko.
[08:25:08.0397]
https://crates.io/crates/urlpattern
[08:26:53.0098]
It hasn't directly come up, but it was something in the back of my mind that we eventually want to get to; nice to know it might be mostly free though 🙂
[10:39:10.0926]
I still want to move it to the whatwg workstream, but its not a high priority at the moment... if another browser was intending to implement soon it would be a higher priority to move it
[10:45:36.0322]
> <@annevk:mozilla.org> Doug Conmy: can you ping me again next week maybe? I have some other things I need to tackle first
Sure. I'll reach out next week. I think I have all you need in the PR to move forward. Thanks.
[13:37:34.0248]
> <@wanderview:matrix.org> are document navigation, starting workers, and starting worklets the only way environments or environment settings can be created?
Seems like "create a new browsing context" also creates an environment settings object prior to navigation
2022-05-12
[01:24:44.0618]
annevk: I've created a separated PR for the safelist update proposal, so that we can discuss each new protocol separately, as it was somehow suggested in the Mozilla standard position issue. I hope this new approach is seeing as positive and doesn't add more confusion to an already complex issue. If that's the case, I'm happy to continue the discussion in the PR that tries to add all the dweb schemes altogether.
https://github.com/whatwg/html/pull/7911
[15:44:17.0621]
If a worker is created from a data URL by https://example.com, will that worker be considered a secure context?
[15:49:45.0005]
Per [1] it seems the data URL would be potentially trustworthy, although the worker would have an opaque origin [2] which wouldn't be trustworthy per [3]
[1] https://w3c.github.io/webappsec-secure-contexts/#is-url-trustworthy
[2] https://html.spec.whatwg.org/multipage/workers.html#set-up-a-worker-environment-settings-object
[3] https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy
[15:57:02.0612]
but maybe all that matters is that the document creating the worker is a secure context? \[4\]
\[4\] https://html.spec.whatwg.org/multipage/webappapis.html#secure-contexts
[15:57:25.0082]
* but maybe all that matters is that the document creating the worker is a secure context? \[4\]
\[4\] https://html.spec.whatwg.org/multipage/webappapis.html#secure-contexts
2022-05-13
[19:51:48.0268]
Noam Rosenthal: I am fixing https://github.com/web-platform-tests/wpt/blob/cff0ff1898/resource-timing/SO-XO-SO-redirect-chain-tao.https.html#L56-L61 for Firefox. I wonder which redirect should cause the TAO check to fail?
[19:53:06.0306]
is it because the last redirect from `cross-origin` to `same-origin`?
[19:53:52.0072]
I am asking because in Firefox, the TAO check is done by always againsting the origin that started the load
[19:55:49.0423]
which is probably wrong I guess. I am still not familiar with the FETCH spec, is it supposed to be done by against the current origin?
[19:58:19.0883]
Does emitting the token happen regardless of the previous if-otherwise?
[19:58:41.0036]
* Does emitting the token happen regardless of the previous if-otherwise?
[21:20:25.0347]
sefeng: It's because the request's origin becomes redirect-tainted (https://fetch.spec.whatwg.org/#concept-request-tainted-origin), and the TAO check accesses that origin which is serialized to `null` (https://fetch.spec.whatwg.org/#ref-for-serializing-a-request-origin%E2%91%A0). This part is a bit hard to follow in the fetch spec IMO.
[21:20:47.0068]
* sefeng: It's because the request's origin becomes redirect-tainted (https://fetch.spec.whatwg.org/#concept-request-tainted-origin), and the TAO check accesses that origin which is serialized to `null` (https://fetch.spec.whatwg.org/#ref-for-serializing-a-request-origin%E2%91%A0). This part is a bit hard to follow in the fetch spec IMO.
[23:56:35.0043]
Andrew Williams: that's a very good question, I think it's closely related to https://github.com/whatwg/html/issues/5254
[23:57:12.0939]
Andrew Williams: my inclination would be yes, as the entire chain is HTTPS
[00:01:31.0629]
It's somewhat unfortunate the entire world went with application/json rather than text/json.
[00:19:43.0555]
> <@everyos:matrix.org> Does emitting the token happen regardless of the previous if-otherwise?
I'd read that as "yes". Maybe two paragraphs would be clearer
[06:00:29.0584]
Ok. Thank you!
[08:36:16.0556]
Noam Rosenthal: thanks. So say have a `A->B->A` redirect chains, when should the tainted origin returns true?
[08:36:29.0322]
the spec says `If url’s origin is not same origin with lastURL’s origin and request’s origin is not same origin with lastURL’s origin, then return true`
[08:38:09.0153]
I'd assume we want it to return true when doing the`last redirect`, but doesn't `last redirect` which is A have the same origin as the `lastURL's origin`?
[08:38:43.0735]
at this point, `url` is `B`, `lastURL` is `A`, and `request's origin` is 'A'
[08:38:47.0408]
what do I miss?
[08:38:55.0388]
* what do I miss?
[08:46:55.0028]
oh perhaps the `URL list` contains the `last redirect` already before doing the TAO check of the `last redirect`, so I can continue the loop to make `lastURI=B`, `url=A` and `request=A`?
[08:56:10.0041]
sefeng: I don't remember exactly, but I think you can't make TAO succeed for redirect-tainted origins, even A->B->A, just like CORS can't. annevk / Yoav Weiss perhaps have more context about this
[09:01:36.0278]
sefeng: in A -> B -> A, when this check happens request's URL list will contain [A, B, A] because otherwise it can't request the final A
[09:02:16.0119]
The underlying security problem is https://en.wikipedia.org/wiki/Confused_deputy_problem
[09:03:15.0366]
(I also have to re-read this algorithm each time to see if it works, if someone would be willing to add some examples underneath that'd be much appreciated!)
[11:06:23.0303]
annevk: ok, so IIUC, for CORS it protects from CSRF amongst other things, where e.g. a POST to another site would redirect you to a different authenticated POST in the original site. And we added that limitation to TAO to align with CORS. The attack vector on TAO is a bit less clearer to me in this case but the alignment makes some sense.
[11:06:27.0969]
sefeng: ^^
[12:29:15.0943]
A question someone has surely asked before... if I, a subresource host, have already granted cross-origin read access with `Access-Control-Allow-Origin: *`, why would I ever *not* want to grant embed access via `Cross-Origin-Resource-Policy: cross-origin`?
[12:31:03.0091]
Which is to say, why do I have to set both? Why doesn't ACAO:\* imply CORP:cross-origin? I get that it doesn't right now because ACAO is for CORS, and CORP is for cross-origin isolation, and those are different... but like, read permission is ≥ embed permission, I think?
[12:31:43.0033]
* Which is to say, why do I have to set both? Why doesn't ACAO:\* imply CORP:cross-origin? I get that it doesn't right now because ACAO is for CORS, and CORP is for cross-origin isolation, and those are different... but like, read permission is ≥ embed permission, I think?
[12:48:02.0910]
If you squint, both headers say, "this resource doesn't contain any private data"
[13:13:42.0979]
ah interesting, thanks for the link and feedback annevk
2022-05-14
[18:30:51.0299]
> <@etportis:matrix.org> A question someone has surely asked before... if I, a subresource host, have already granted cross-origin read access with `Access-Control-Allow-Origin: *`, why would I ever *not* want to grant embed access via `Cross-Origin-Resource-Policy: cross-origin`?
IIRC it has to do with how CORS also impacts the requests. (Which you can most easily see when preflights are required.) If you do a "no-cors" request (e.g. , not ) and get back ACAO: *, what does that mean? Saying that it roughly means CORP: cross-origin is a bit strange/maybe broken in some more specific way I can't think of right now.
[23:49:24.0796]
Eric Portis (he/him): ACAO/CORS allows you to make a decision of what data to send based on the origin of the request. e.g. you can send a different response if your data is requested by `origin-a.com` and `origin-b.com`, because CORS requests contain the `Origin` header. CORP is more like a fallback to still allow embedding the content even without knowing the origin.
[23:51:13.0057]
Having `Access-Control-Allow-Origin: *` doesn't mean that you send all/the same data to every origin, while `Cross-Origin-Resource-Policy: *` kind of does, but for the latter the use of the resource is limited (showing the image, using it in timing-attack-prone situations but not read the data directly)
[23:54:02.0261]
Having both without extra checks means "If I know the origin of the request then allow reading this data, and also allow embedding it even if I don't know the origin". It's not *too* redundant
2022-05-15
[00:18:29.0779]
Eric Portis (he/him): one difference is that the former only works for non-credentialed requests and the latter works for all requests
[00:19:16.0600]
Eric Portis (he/him): and the former only works for requests that include an `Origin` header
[00:22:15.0129]
These differences will shrink over time as cross-site credentials disappear, but they'll remain relevant to the origin-vs-site distinction as well as the `Origin` header aspect
[11:46:57.0393]
I am not an IT person. But somehow some site changed my physical from one city to another, thus I et emails intended for the wrong city. I don't know how to change it.
2022-05-16
[21:56:50.0326]
Anybody got a site that sends `Accept-Ranges: none`? Need one for an example in MDN https://github.com/mdn/content/issues/16073
[01:12:01.0646]
Anyone know where the parsing of "video", "audio" and "picture" are handled in the HTML spec?
[01:15:33.0292]
If you search for "video", "audio" and "picture" in multipage/parsing.html you get nothing, so I'm assuming under "any other start tag" in body
[01:15:35.0436]
https://html.spec.whatwg.org/multipage/parsing.html#parsing-main-inbody:reconstruct-the-active-formatting-elements-16
[01:18:59.0466]
Interesting. I assumed that every valid element would be explicitly mentioned, but I guess not.
[01:32:27.0835]
Most "inline" elements don't need special rules; others often need to imply `
` and such which is why they get mentioned by name
[02:19:31.0885]
> <@sideshowbarker:mozilla.org> Anybody got a site that sends `Accept-Ranges: none`? Need one for an example in MDN https://github.com/mdn/content/issues/16073
https://www.paypal.com/xoplatform/logger/api/logger
(From BigQuery: SELECT url FROM `httparchive.summary_requests.2022_04_01_mobile` WHERE resp_accept_ranges="none" LIMIT 1000, can probably play with it yourself for better results)
[02:20:17.0848]
> <@annevk:mozilla.org> Most "inline" elements don't need special rules; others often need to imply `` and such which is why they get mentioned by name
🎉 Thanks much
[02:41:48.0521]
Ahh, that makes sense, thank you!
[03:07:52.0086]
I'm guessing Mike wanted to reply to Noam? 🙂
[03:42:33.0500]
oops yeah, sorry
[05:55:12.0480]
zcorpan: https://ijmacd.github.io/rfc3339-iso8601/ (via https://twitter.com/bradfitz/status/1524448788290568192)
[07:26:33.0105]
annevk: wow
[07:34:59.0872]
zcorpan: you know what you signed up for right? PR it for Ecma-262 😛
[07:37:11.0453]
Sounds like we should fix the ISO spec first
[07:38:16.0082]
and when I say we, I don't mean I :P
[07:40:39.0932]
At least this one you can leave to Temporal :)
[07:53:54.0115]
I mean maybe, I believe Temporal doesn't take all valid HTML inputs, which kinda sucks
[07:55:01.0584]
Do you know if there's an issue about that?
[08:45:21.0945]
annevk: found https://github.com/whatwg/html/issues/6163, heh
[08:54:39.0710]
Domenic: ah, I'll add another comment to Capability Delegation to mention that
[08:56:26.0918]
Context: https://github.com/WICG/capability-delegation/issues/9#issuecomment-1127845526
[16:48:54.0401]
Hi... so... I've been searching for like... DNS records like you'd find from a DNS server or ipconfig /displaydns - is it an absurd thing to be trying to find? Does it have to be obtained thru REST API or something?
[16:49:18.0174]
been looking for a couple hours now... it's about to drive me crazy
[16:49:51.0368]
Do I have to go thru each top level domain registrar and get their records one by one?
[16:50:03.0549]
if they even make them available for free...
2022-05-17
[00:59:56.0399]
Andreu Botella: https://andreubotella.com/csswg-auto-build/ doesn’t seem to mirror https://drafts.csswg.org/scroll-animations/ …
[01:01:20.0429]
as far as I can tell, that’s the only CSS spec that it’s not mirroring
[01:27:27.0954]
> <@sideshowbarker:mozilla.org> Andreu Botella: https://andreubotella.com/csswg-auto-build/ doesn’t seem to mirror https://drafts.csswg.org/scroll-animations/ …
it's on https://andreubotella.com/csswg-auto-build/scroll-animations-1/ and on the index as "scroll-linked animations"
[01:27:39.0307]
but weird that the shortname https://andreubotella.com/csswg-auto-build/scroll-animations doesn't link to it
[01:27:45.0344]
aha
[01:29:28.0227]
That's of course because the shortname in the bikeshed metadata is given as `scroll-animations-1`, of course: https://github.com/w3c/csswg-drafts/blob/main/scroll-animations-1/Overview.bs#L10
[01:29:56.0507]
I've had to special case some shortnames so they show up linked in the index, I guess I missed this one because it has a single level
[01:33:45.0972]
it is easy to fix/workaround on your side?
[01:33:57.0508]
I just did
[01:34:05.0170]
give it a few minutes so it builds
[01:34:06.0781]
ah cool — thanks
[01:34:09.0628]
hai
[01:56:40.0367]
Mattias Buelens: hey, do we have some kind of "peek" primitive yet for streams?
[01:58:19.0616]
Mattias Buelens: I'm guessing I might be stuck with some kind of transform stream?
[02:00:23.0173]
> <@annevk:mozilla.org> Mattias Buelens: hey, do we have some kind of "peek" primitive yet for streams?
No, we don't have that yet.
[02:01:38.0064]
Andreu Botella: so in my https://github.com/w3c/mdn-spec-links/ build automation, I’m trying to replace requests to https://drafts.csswg.org/ URLs with requests to https://andreubotella.com/csswg-auto-build/ URLs — but what I’m finding is that a lot of the documents at the URLs I’m requesting actually just have client-side redirects — e.g., `` — which the documents at the equivalent https://drafts.csswg.org/ URLs don’t seem to have. Instead the documents at the https://drafts.csswg.org/ URLs seem to be copies…
[02:01:58.0548]
Thanks; for ORB I need to look at the first 1024 bytes of a response, so I guess I essentially have to replace the underlying stream with a transform stream where I collect the first 1024 bytes, scan them, and then forward them
[02:02:35.0220]
sideshowbarker: Github Pages doesn't let you do server-side redirects, so I'm making all of them client-side
[02:03:00.0002]
if you link to the actual level of a spec, it shouldn't redirect
[02:03:17.0935]
yeah I can’t link to the leveled versions
[02:03:54.0211]
for MDN and BCD we have a policy of intentionally not linking to the leveled versions
[02:05:07.0280]
> <@annevk:mozilla.org> Thanks; for ORB I need to look at the first 1024 bytes of a response, so I guess I essentially have to replace the underlying stream with a transform stream where I collect the first 1024 bytes, scan them, and then forward them
That's correct. I did something similar for streaming AES-CBC decryption in https://github.com/MattiasBuelens/crypto-aes-stream/blob/08f28cebbd02f9feb9d0e8d6d2ae9135cbe27ce2/src/aes-cbc-stream.ts#L39-L47
[02:09:07.0039]
I will also have another place where I need to look at the full response before forwarding it. Might look at whether that makes it worth abstracting somehow.
[02:10:09.0246]
with jsdom, anybody know if I can get it to follow a `
Andreu Botella: OK I reckon I’ll try grabbing out the redirect URLs with jsdom, and re-requesting with those URLs. I think it should work.
Because it’ll be making additional requests, I guess it’ll end up being a bit slower than using drafts.csswg.org — but today after the Nth time of drafts.csswg.org unreliability completely breaking my build, it’s worth the added effort and time to have something else that’ll actually work reliably rather than totally break every week
[04:06:08.0657]
Andreu Botella: OK, with https://github.com/w3c/mdn-spec-links/commit/18de692 my build tooling is now switched over to making requests to your mirror rather than to drafts.csswg.org — and it seems to be working as expected. Dunno if GitHub has request/bandwidth limits for Pages content, but anyway that part of the build normally only runs once a day, so I don’t think it will generate a huge amount of extra traffic
[04:06:23.0335]
sounds good
[04:06:44.0546]
thanks much for providing that mirror
[07:54:56.0318]
Noam Rosenthal: could you perhaps triage the issues here that are filed by me: https://github.com/WICG/background-fetch/issues? Now that HTML depends on some of this stuff, it would be good to know if we should move some of these definitions to Fetch
[07:55:37.0116]
Noam Rosenthal: my interest atm is mainly with "validate a partial response" which ORB needs, but all of it seems important
[07:56:42.0569]
annevk: I don't know much about the background-fetch spec but would be happy to give it a go
[07:59:27.0871]
Noam Rosenthal: this is mainly about the range thingies that media elements now depend in part on
[08:00:29.0273]
annevk: ah yes, I originally used some of the definition from background-fetch with small but important modifications
[08:13:14.0494]
It seems HTML only has "extract content-range values", so maybe I'm on my own
[08:14:05.0214]
Well maybe not, "validate a partial response" depends on that
[08:18:20.0173]
yea the validation bit is semi-duplicated between HTML and background-fetch with minor differences and both depend on "extract content-range values" IIRC
[08:24:08.0893]
I see, if you could it would be great to have some follow-up issues documenting what would make things more usable for HTML
[08:24:50.0212]
I suspect that in implementations these don't have different code paths per se so might also be good to test
[08:29:08.0282]
annevk: sure, will get to it soon-ish
[08:57:03.0831]
annevk: I wanted to finish with https://github.com/whatwg/html/pull/7782 before the next steps with range-responses though, waiting for a final merge
[09:40:07.0174]
Noam Rosenthal: added a comment
[09:48:34.0707]
Noam Rosenthal: annevk sorry for coming back with another TAO check question. For a simple redirect, A->B, when doing the `serializing a request origin` check for B, Should it return...`null`?
[09:51:52.0999]
sefeng: I was surprised with this as well about a month ago :)
[09:52:58.0172]
Noam Rosenthal: yeah I mean..it looks like B has to have `*` specified to make TAO passes, it can't just have A's origin
[09:53:31.0598]
sefeng: so request's URL list is [A, B], what's request's origin?
[09:53:45.0555]
annevk: B
[09:54:05.0233]
Yeah then it's tainted
[09:54:19.0818]
sefeng: It can theoretically have the string "null" though I don't think that's tested or implemented
[09:54:22.0065]
If it wasn't A could make requests on B with the authority of B
[09:54:54.0166]
If request's origin was A, it would end up saying A to B
[09:57:29.0698]
annevk: maybe I misunderstanding something. So when an redirect like this, I should use A as the origin?
[09:58:35.0763]
sefeng: in the scenario you described a website B does a fetch to A and A redirects to B, right?
[10:01:03.0307]
annevk: I think it's just website A fetches B
[10:01:36.0908]
I am looking at this particular test https://searchfox.org/mozilla-central/source/testing/web-platform/tests/resource-timing/TAO-match.html#21-24
[10:03:40.0190]
sefeng: I'm not familiar with those tests, but in that case request's origin would be A and request's URL list would be [B]; so looking at https://fetch.spec.whatwg.org/#concept-request-tainted-origin ...
[10:04:31.0940]
sefeng: we'd end up returning false since after we set lastURL to B we continue and thus exit the loop as there are no more URLs
[10:04:58.0940]
sefeng: and returning false means there's no tainting thus `Origin` becomes A
[10:08:10.0428]
annevk: so request origin should always be the origin of who started the request?
[10:13:30.0757]
sefeng: yeah, it typically gets set based on the global involved in creating the request
[10:22:39.0442]
thanks!
[10:25:01.0375]
sefeng: I guess an important thing to understand here is that request's origin is essentially immutable (these days anyway) and request's URL list gets updated as you come across redirects
[12:59:55.0438]
Hmm, why is test_driver.bless called bless?
[13:00:13.0559]
Couldn't have guessed it has something to do with user interaction
[14:08:09.0224]
it took me time to figure that out as well
2022-05-18
[22:16:59.0754]
about the Node `URL` implementation, anybody know if there’s a way to prevent it from percent-encoding Unicode characters?
[22:18:55.0985]
it’s taking fragments like `ref-for-dom-abortcontroller-abortcontroller①` and changing them to `ref-for-dom-abortcontroller-abortcontroller%E2%91%A0`
[22:20:46.0578]
(I realize I can probably use `decodeURIComponent()` to fix them, but would prefer they don’t get encoded to begin with…)
[23:30:11.0675]
sideshowbarker: that behavior is part of the URL parser and the URL Standard at least doesn't offer an option for it
2022-05-19
[22:51:17.0261]
Hi everyone. I have a suggestion for the DOMTokenList interface. Given `class="a b c"`, the conditional statement `if (classList.contains("a")) {classList.replace("a", "d")} else {classList.replace("d", "a")};` could be encapsulated by a function, call it `switch()`. For example, `switch("a", "d");` returns `"d b c"`; next, `switch("a", "d");` returns `"a b c"`. I would find this useful for something like Tailwind utilities. For example, if I want to expand/collapse an element, I could use this on the height utility.
[22:51:58.0790]
* Hi everyone. I have a suggestion for the DOMTokenList interface. Given `class="a b c"`, the conditional statement `If classList.contains("a") then replace("a", "d") else replace("d", "a")` could be encapsulated by a function, call it `switch()`. For example, `switch("a", "d")` returns `"d b c"`; next, `switch("a", "d")` returns `"a b c"`. I would find this useful for something like Tailwind utilities. For example, if I want to expand/collapse an element, I could use this on the height utility.
[22:52:24.0483]
* Hi everyone. I have a suggestion for the DOMTokenList interface. Given `class="a b c"`, the conditional statement `if classList.contains("a") then replace("a", "d") else replace("d", "a")` could be encapsulated by a function, call it `switch()`. For example, `switch("a", "d")` returns `"d b c"`; next, `switch("a", "d")` returns `"a b c"`. I would find this useful for something like Tailwind utilities. For example, if I want to expand/collapse an element, I could use this on the height utility.
[22:53:05.0248]
* Hi everyone. I have a suggestion for the DOMTokenList interface. Given `class="a b c"`, the conditional statement `if (classList.contains("a")) { replace("a", "d") } else { replace("d", "a") }` could be encapsulated by a function, call it `switch()`. For example, `switch("a", "d")` returns `"d b c"`; next, `switch("a", "d")` returns `"a b c"`. I would find this useful for something like Tailwind utilities. For example, if I want to expand/collapse an element, I could use this on the height utility.
[22:53:21.0235]
* Hi everyone. I have a suggestion for the DOMTokenList interface. Given `class="a b c"`, the conditional statement `if (classList.contains("a")) {replace("a", "d")} else {replace("d", "a")}` could be encapsulated by a function, call it `switch()`. For example, `switch("a", "d")` returns `"d b c"`; next, `switch("a", "d")` returns `"a b c"`. I would find this useful for something like Tailwind utilities. For example, if I want to expand/collapse an element, I could use this on the height utility.
[22:53:53.0231]
* Hi everyone. I have a suggestion for the DOMTokenList interface. Given `class="a b c"`, the conditional statement `if (classList.contains("a")) {replace("a", "d")} else {replace("d", "a")};` could be encapsulated by a function, call it `switch()`. For example, `switch("a", "d")` returns `"d b c"`; next, `switch("a", "d")` returns `"a b c"`. I would find this useful for something like Tailwind utilities. For example, if I want to expand/collapse an element, I could use this on the height utility.
[22:54:03.0283]
* Hi everyone. I have a suggestion for the DOMTokenList interface. Given `class="a b c"`, the conditional statement `if (classList.contains("a")) {replace("a", "d")} else {replace("d", "a")};` could be encapsulated by a function, call it `switch()`. For example, `switch("a", "d");` returns `"d b c"`; next, `switch("a", "d");` returns `"a b c"`. I would find this useful for something like Tailwind utilities. For example, if I want to expand/collapse an element, I could use this on the height utility.
[22:55:01.0445]
* Hi everyone. I have a suggestion for the DOMTokenList interface. Given `class="a b c"`, the conditional statement `if (classList.contains("a")) {classList.replace("a", "d")} else {classList.replace("d", "a")};` could be encapsulated by a function, call it `switch()`. For example, `switch("a", "d");` returns `"d b c"`; next, `switch("a", "d");` returns `"a b c"`. I would find this useful for something like Tailwind utilities. For example, if I want to expand/collapse an element, I could use this on the height utility.
[22:59:22.0031]
* Hi everyone. I have a suggestion for the DOMTokenList interface. Given `class="a b c"`, the conditional statement `if (classList.contains("a")) {classList.replace("a", "d")} else {classList.replace("d", "a")};` could be encapsulated by a function, call it `switch()`. For example, `switch("a", "d");` returns `"d b c"`; next, `switch("a", "d");` returns `"a b c"`. I would find this useful for something like Tailwind utilities. For example, if I want to expand/collapse a `div` as part of a custom component, I could use this on the height utility.
[23:00:00.0849]
* Hi everyone. I have a suggestion for the DOMTokenList interface. Given `class="a b c"`, the conditional statement `if (classList.contains("a")) {classList.replace("a", "d")} else {classList.replace("d", "a")};` could be encapsulated by a function, call it `switch()`. For example, `switch("a", "d");` returns `"d b c"`; next, `switch("a", "d");` returns `"a b c"`. I would find this useful for something like Tailwind utilities. For example, if I want to expand/collapse a `div`, I could use this on the height utility.
[23:00:07.0760]
* Hi everyone. I have a suggestion for the DOMTokenList interface. Given `class="a b c"`, the conditional statement `if (classList.contains("a")) {classList.replace("a", "d")} else {classList.replace("d", "a")};` could be encapsulated by a function, call it `switch()`. For example, `switch("a", "d");` returns `"d b c"`; next, `switch("a", "d");` returns `"a b c"`. I would find this useful for something like Tailwind utilities. For example, if I wanted to expand/collapse a `div`, I could use this on the height utility.
[23:01:04.0512]
* Hi everyone. I have a suggestion for the DOMTokenList interface. Given `class="a b c"`, the conditional statement `if (classList.contains("a")) {classList.replace("a", "d")} else {classList.replace("d", "a")};` could be encapsulated by a function, call it `switch()`. For example, `switch("a", "d");` returns `"d b c"`; next, `switch("a", "d");` returns `"a b c"`. I would find this useful for something like Tailwind utilities. For example, if I wanted to expand/collapse a `div`, I could use this on the height utility: `switch("h-1/2", "h-full");`
[23:01:27.0279]
* Hi everyone. I have a suggestion for the DOMTokenList interface. Given `class="a b c"`, the conditional statement `if (classList.contains("a")) {classList.replace("a", "d")} else {classList.replace("d", "a")};` could be encapsulated by a function, call it `switch()`. For example, `switch("a", "d");` returns `"d b c"`; next, `switch("a", "d");` returns `"a b c"`. I would find this useful for something like Tailwind utilities. For example, if I wanted to expand/collapse a `div`, I could use this on the height utility: `classList.switch("h-1/2", "h-full");`.
[23:01:32.0269]
* Hi everyone. I have a suggestion for the DOMTokenList interface. Given `class="a b c"`, the conditional statement `if (classList.contains("a")) {classList.replace("a", "d")} else {classList.replace("d", "a")};` could be encapsulated by a function, call it `switch()`. For example, `switch("a", "d");` returns `"d b c"`; next, `switch("a", "d");` returns `"a b c"`. I would find this useful for something like Tailwind utilities. For example, if I wanted to expand/collapse a `div`, I could use this on the height utility: `classList.switch("h-1/2", "h-full");`
[23:01:56.0217]
* Hi everyone. I have a suggestion for the DOMTokenList interface. Given `class="a b c"`, the conditional statement `if (classList.contains("a")) {classList.replace("a", "d")} else {classList.replace("d", "a")};` could be encapsulated by a function, call it `switch()`. For example, `switch("a", "d");` returns `"d b c"`; next, `switch("a", "d");` returns `"a b c"`. I would find this useful for something like Tailwind utilities. For example, if I wanted to expand/collapse a `div`, I could use this on the height utility like so: `classList.switch("h-1/2", "h-full");`
[23:36:12.0344]
Ben Smyth: in principle it seems you could do the same with `toggle()` and less classes, but you could file the sugestion against whatwg/dom; it would help a lot to see Stack Overflow questions requesting similar functionality, library usage, etc. https://whatwg.org/faq#adding-new-features might also help
[00:07:40.0543]
`classList.toggle("a"); classList.toggle("d");` seems pretty good to me...
[00:15:40.0438]
Yeah, I just realized ... thanks for listening to my naive pitch anyways
[15:05:22.0449]
mek: Hasn’t the https://wicg.github.io/file-system-access/ spec been superseded by https://fs.spec.whatwg.org/ ?
If so, shouldn’t https://wicg.github.io/file-system-access/ be changed to redirect to https://fs.spec.whatwg.org/ — or else at least marked in some way to indicate it shouldn’t be used any longer?
[15:06:14.0778]
ah, nevermind, I see from https://github.com/WICG/file-system-access/issues/370 you’re on it already
2022-05-20
[20:53:09.0791]
Domenic Noam Rosenthal annevk Thank you for the answers re: CORS/CORP differences (a week ago)! Very helpful.
[20:53:40.0515]
Sounds like, for the use case I had in mind (serving a totally static, public resource), add both… and it’s overly reductive to say `ACAO:*` represents “global read access” and `CORP:cross-origin` represents “global embed access, which, worst case, escalates to read access”. The flows are different enough in at least some cases that the platform can’t always infer that `CORP:cross-origin` would be safe, given the presence of `ACAO:*`.
[20:55:00.0121]
One follow up question… Noam Rosenthal said CORP:cross-origin “kind of” means that you send all/the same data to every Origin. Which (I think) makes sense... But let’s say the resource doesn’t vary per Origin, and doesn’t vary based on Cookie or Authentication, but does vary based on other things (Accept, User-Agent… IP??) Is adding either/both headers to requests that vary in these ways dangerous? Does the "degree or type of variance" matter?
[21:35:23.0383]
* One follow up question… Noam Rosenthal said CORP:cross-origin “kind of” means that you send all/the same data to every Origin. Which (I think) makes sense... But let’s say the resource doesn’t vary per Origin, and doesn’t vary based on Cookie or Authentication, but does vary based on other things (Accept, User-Agent… IP??) Is adding either/both headers to responses that vary in these ways dangerous? Does the "degree or type of variance" matter?
[21:41:27.0525]
After some thought, my guess is it’s not dangerous because the value of those request headers doesn’t change based on origin, so they don’t reveal anything about the user’s relationship to that other origin.
[21:50:59.0270]
I'll help 10 people on how to earn $12,000 within 72 hours but you will pay me 10% of your profit when you receive it.
Note: only interested people should apply, click and drop a message let's get started
https://t.me/isheilabillyinvest
[22:31:28.0466]
Eric Portis (he/him): the question is more about whether the variations reveal something about the user only the server in question knows about and whether you are comfortable sharing that widely
[23:42:03.0415]
Eric Portis (he/him): Example: If `embedder.com` is embedding an image from `image.com`, and the served image is different per client-IP, then it's a question of - is that information that `embedder.com` should have access to?
[23:45:27.0850]
The `Origin` header answers the question: "which website is asking for this image on behalf of this user?". The only thing it reveals about the user in itself, is the fact that they are currently visiting that origin
[23:52:16.0190]
... What helps me remember the CORS/CORP essence is that when you make a server-to-server request. both don't apply. That's because a server is not a user-agent - it doesn't have the user's cookies/client-certs, and also not other anonymous-but-revealing properties like IP and user-agent. CORS/CORP are both there to protect the user from having a content site reveal to the embedding document information that only the user should know and protected by their credentials or private information like client IP. Either by having the embedder self-identify (CORS), or by allowing limited access to unidentified origins (CORP)
[09:02:21.0038]
wanderview: presumably someone at Chromium has thought about this though? E.g., the anonymous iframe proposal clearly wants the partitioned nonce for both storage and networking
[09:03:19.0800]
To me that, as well as what we've learned about the security/privacy boundary over the last couple years suggests some kind of unification is in order
[09:03:46.0932]
I'd rather not work on a solution just for storage keys if a couple months later we have to do it again for networking
[09:04:07.0436]
I think making storage partitioning block on that unification is going to delay spec'ing storage partitioning... at least I don't have bandwidth for it at the moment
[09:04:21.0913]
* I think making storage partitioning block on that unification is going to delay spec'ing storage partitioning... at least I don't have bandwidth for it at the moment
[09:04:37.0512]
and arguably I don't understand it... maybe you are the only here who knows what your vision looks like?
[09:05:28.0610]
at a minimum it would need more definition of what your final state looks like... right now it seems a bit vague to me
[09:05:54.0664]
and I hesitate to invest a lot of time trying to implement a grand vision that I don't understand and may not be what you are looking for anyway
[09:07:27.0944]
That's fair, but that also goes for the variety of Google's proposals in this area, no?
[09:08:18.0708]
I don't understand what you mean?
[09:08:52.0012]
Well, going back to https://github.com/whatwg/storage/issues/142. What's stated there is incorrect as I've shown by pointing to the anonymous iframe proposal.
[09:09:09.0546]
In that the nonce is used elsewhere.
[09:09:36.0446]
So it's also not clear to me what Google's vision is here as there are contradictory statements.
[09:09:59.0735]
"used elsewhere" means for networking in addition to storage?
[09:10:21.0860]
are we bikeshedding the word "storage"... I mean StorageKey is also used for communication APIs like broadcastchannel
[09:10:46.0821]
I don't understand why StorageKey can't be the one source of truth here
[09:10:53.0144]
Yes networking, which cannot use the storage key directly as it doesn't use the "origin" part.
[09:12:30.0707]
I'm confused.... networking would not use all of whatever this 'authority struct' is either...
[09:12:39.0758]
* I'm confused.... networking would not use all of whatever this 'authority struct' is either...
[09:12:54.0240]
why can't networking pull the nonce out of storagekey
[09:13:02.0339]
just as it would this authority struct
[09:13:03.0568]
It doesn't currently no, but that's what I'm suggesting we do over time. Unify the networking partition key and the storage key somewhat.
[09:13:20.0706]
And have them be more centrally owned, similar to origin.
[09:14:10.0276]
the "over time" does not seem consistent with the "can't make incremental improvements" position you have here
[09:14:45.0577]
I'm fine with that being the goal long term... but you seem to be saying you want it now before we do anything else
[09:14:47.0896]
I think my suggestion can be mostly backwards compatible.
[09:15:58.0962]
As in we put the state there, you'd have to adjust "obtain a storage key" slightly, but after that it would all still work.
[09:16:40.0729]
so you want to do the opposite of what I wrote in https://github.com/whatwg/storage/issues/142... I did not take that from your comment there
[09:19:03.0088]
wanderview: perhaps your comment above naming is correct; I think we should group this state on environment and give it a name that'll serve us going forward
[09:20:40.0933]
But I meant what I wrote there, I agree that it would make sense for us to store this state on environment, I just think it's wider than a storage key, especially given that with "storage" the web platform typically doesn't mean cookies or network state
[09:34:10.0489]
I gotta go, happy to discuss more on Monday; also happy to try to explain it better or work with whoever at Chromium is nominally in charge of these various keys to hash something out, let me know
[09:49:05.0917]
Noam Rosenthal annevk Thank you, again, for the explanations. Very helpful.
annevk said: “whether the variations reveal something about the user only the server in question knows…”
Ok, so… interpreted literally, that’s potentially every aspect of the request. image.com has no guarantee that the user is sending any of the same headers (or IP) to image.com vs embedder.com.
annevk said: “…and whether you are comfortable sharing that widely”
This is the part I struggle to reason through, in cases that don’t involve Cookies/Authentication (which are more obvious). Wrote up some examples and how I'm thinking about them... https://gist.github.com/eeeps/ecfbf8d554bcbdd0d92c74c7edd11d15 Am I thinking ~correctly? Any advice on the murky cases?
[10:18:34.0214]
Eric Portis (he/him): in practice these are all probably okay; it seems unlikely the two requests end up with different IP addresses though perhaps this will be more common in the future (but who is to say that image.com is getting an accurate one then)
[10:19:04.0377]
Eric Portis (he/him): the main problematic case without credentials is using the IP address of the user to authenticate them
[10:19:35.0575]
Eric Portis (he/him): so not so much revealing their IP address, but revealing who they are
[10:23:12.0351]
annevk: Huh, ok. I think I get it. Thank you!!
2022-05-22
[21:42:47.0521]
Guys, I had these ideas to help the web be better. I would like to know everyone's opinion on these drafts and ideas! https://discourse.wicg.io/u/raphaellouis/activity/topics - I would like positive or negative feedback on these ideas!
[07:16:08.0599]
raphaellouis: some of us aren't guys
[07:26:01.0209]
raphaellouis: terms like “Web 5.0” & “HTML7” are probably going to make people in here cringe; the WHATWG living standards are not versioned
[07:55:29.0913]
raphaellouis: i don't have an account there, but manually timestamping a doctype seems error-prone and can easily be lied about..
[12:02:41.0689]
Hi, I have a question about the input element, specifically the behavior of min and max when they do not apply to the current type state. It says the behavior is defined in that section, but the section for min and max doesn't seem to specify that. It says browsers should use the algorithm to convert a string to a number, but none is specified for, e.g., the Text state. I assume this just means the algorithm doesn't return a number and thus there is no minimum or maximum, but I don't see where this is specified. (I know that as an author, I cannot use these attributes where they do not apply, but I'm just wondering what exactly is supposed to happen.)
[16:22:37.0772]
amphitryon: would you mind linking to the section you're referring to?
[16:27:14.0243]
So https://html.spec.whatwg.org/multipage/input.html#do-not-apply tells me to check https://html.spec.whatwg.org/multipage/input.html#attr-input-min for the behavior. This doesn't mention when they don't apply (the way other attributes do), but it does link to https://html.spec.whatwg.org/multipage/input.html#concept-input-value-string-number, which tells me to look in https://html.spec.whatwg.org/multipage/input.html#text-(type=text)-state-and-search-state-(type=search) for the algorithm definition.
[16:33:14.0983]
Oh wait, looking at it more, I see what it says at https://html.spec.whatwg.org/multipage/input.html#common-input-element-attributes is that it must be ignored. I thought that since ones like maxlength explicitly stated "when it applies", that there would be a similar phrasing for any of them.
[16:35:52.0043]
And that is clearly linked to right next to the definition of "do not apply", so go ahead and disregard my question.
[16:36:04.0789]
* And that is clearly linked to right next to the definition of "do not apply", so go ahead and disregard my question.
[16:40:38.0299]
the only thing i might caution you about client-side input validation is that it isn't fool-proof
[16:41:20.0379]
like, absolutely be sure to validate your inputs on the back-end too
[16:49:49.0622]
Oh, for sure. My original reason for trying to understand this was just to know if I had to use type=number to get a UA's native numeric range restrictions, but I'll just do it in Javascript, since it falls under the note about consisting of numbers but not being a number.
[16:50:26.0154]
* Oh, for sure. My original reason for trying to understand this was just to know if I had to use type=number to get a UA's native numeric range restrictions, but I'll just do the client-side part in Javascript, since it falls under the note about consisting of numbers but not being a number.
[16:51:18.0481]
Is there any plan to provide a grammar for https://url.spec.whatwg.org/
2022-05-23
[23:48:44.0596]
iwan.aucamp: there have been a few attempts, see the issues; none has really made it to the point where it would seem like a clear improvement, at least to me
[02:22:01.0905]
A clear improvement as compared to not having one, or as compared to the IETF grammar?
[02:24:28.0618]
It seems to me that if the intent is indeed to obsolete RFC 3986 then a providing a grammar would be an essential part of it.
[02:24:59.0583]
I see for example mention in the one issue that it would be simple, but if it would be, why not just make it?
[02:28:26.0871]
Not all assertions on the internet happen to be true. 🙂 Likewise, you might find that not everyone is as convinced about the merit of grammars.
[02:29:08.0767]
Okay, but say I want to incorporate it into another format, like Turtle?
[02:29:29.0889]
or into another grammar?
[03:26:51.0269]
iwan.aucamp: in most cases you wouldn't want that grammar to fall over the moment this grammar is extended in some way, so usually you'd have a somewhat broader field and then define processing requirements around it
[03:28:04.0803]
(This is one of the criticisms against grammar, it alone is not sufficient to define what you actually expect to happen)
[03:41:59.0109]
foolip: so does idlharness.js not use webidl2.js underneath?
[03:42:29.0958]
foolip: cause it seems krosylight patched that in https://github.com/w3c/webidl2.js/commit/4a4be1f3436360f033a8a7efd896904ef1a52aab
[03:43:31.0713]
foolip: I suppose we want to list webidl2.js as a place to file issues on when Web IDL gets changed (that would involve two minor changes to whatwg/spec-factory and whatwg/meta), but maybe other tools as well? E.g., bikeshed?
[03:43:44.0234]
Although I guess bikeshed was fine this time around as Fetch is still building...
[03:44:23.0711]
(Maybe because they're separate IDL fragments.)
[03:50:28.0835]
> <@annevk:mozilla.org> foolip: so does idlharness.js not use webidl2.js underneath?
It does, it's just that it's completely manual to update the dependency. Perhaps it would be good to get a CI job for that
[04:09:02.0441]
I filed https://github.com/whatwg/webidl/issues/1147 to track this conversation
[06:11:17.0696]
annevk: Following up on PR, can you advise on next steps? I believe everything needed is in there.
https://github.com/whatwg/html/pull/7678
[07:57:37.0060]
Doug Conmy: thanks for the reminder, I'm checking internally with Mozilla to see if anyone has any problems with closing https://github.com/mozilla/standards-positions/issues/624 as worth prototyping; I suspect we'll know by Wednesday or so
[07:58:07.0356]
Domenic: I take it jarhar speaks for Google as a whole on this issue?
[07:59:27.0217]
annevk: I think to the extent we require in the WHATWG, yes. (The Blink API owners are always the final deciders but we don
[08:00:13.0157]
* annevk: I think to the extent we require in the WHATWG, yes. (The Blink API owners are always the final deciders but we generally assume alignment unless something's particularly controversial.)
[09:01:40.0449]
shu: https://github.com/tc39/proposal-shadowrealm/issues/353 seems to discuss cloning errors; shouldn't that follow HTML StructuredSerialize semantics?
[09:08:52.0810]
I guess I'll just raise my concern there directly, easier to keep track of it
[09:25:57.0363]
annevk: no, it's not cloning errors per se
[09:26:20.0793]
like, maybe that's one thing that you do to propagate errors across the boundary? i don't know what the intention is
[09:26:52.0856]
> <@krosylight:mozilla.org> It does, it's just that it's completely manual to update the dependency. Perhaps it would be good to get a CI job for that
It would be easy enough to that for webidl2.js I think. I would be nice if it doesn't have to be done differently for each dependency though, so https://github.com/web-platform-tests/rfcs/issues/46 comes to mind.
[09:28:26.0637]
shu: https://github.com/tc39/proposal-shadowrealm/issues/353#issuecomment-1071058577 is what made me think that, FWIW
[09:29:49.0430]
i read that as just brainstorming
[09:30:14.0473]
(and also my reading that the idea was rejected more or less by others in the discussion)
[09:30:38.0616]
another relevant thing here is that the idea of distinguishing platform-thrown errors from user-thrown errors has been floated
[09:30:52.0233]
i both think that is probably not possible and a bad idea
[09:33:27.0462]
> <@foolip:matrix.org> It would be easy enough to that for webidl2.js I think. I would be nice if it doesn't have to be done differently for each dependency though, so https://github.com/web-platform-tests/rfcs/issues/46 comes to mind.
A webidl2.js update should not break wpt in a way that each test should be adjusted (idlharness is the only thing it should affect). Not sure that applies to all dependencies
[09:34:21.0425]
shu: to some extent that's what StructuredSerialize does, but perhaps TC39 plans to adjust it somehow if/when they take it over
[09:34:29.0460]
> <@krosylight:mozilla.org> A webidl2.js update should not break wpt in a way that each test should be adjusted (idlharness is the only thing it should affect). Not sure that applies to all dependencies
It still has to happen through a PR, so I'm not sure that makes any difference in practice. Also, all changes can sometimes break something.
[09:35:17.0790]
shu: anyway, if the current proposal is to map everything to a TypeError I guess my comment doesn't apply
[09:36:58.0782]
annevk: how does StructuredSerialize distinguish platform-thrown from user-thrown errors?
[09:36:59.0820]
Noam Rosenthal: I hadn't looked at the PR text of https://github.com/whatwg/fetch/pull/1413 again; so from your comment I take it I should wait a bit until there's a fix for the issue Yutaka found, right?
[09:37:32.0791]
> <@annevk:mozilla.org> Noam Rosenthal: I hadn't looked at the PR text of https://github.com/whatwg/fetch/pull/1413 again; so from your comment I take it I should wait a bit until there's a fix for the issue Yutaka found, right?
Yes, which would probably simplify the "state" thing a lot
[09:40:00.0853]
> <@foolip:matrix.org> It still has to happen through a PR, so I'm not sure that makes any difference in practice. Also, all changes can sometimes break something.
Fair enough. But should all of the libraries be updated? Has the lack of maintenance blocked something? (Just curious)
[09:40:16.0763]
Noam Rosenthal: nice
[09:41:28.0818]
annevk: I had a related question about `request`. It seems like we save some state on it - both the `done` flag as well as things like TAO fail. Shouldn't they be moved to fetch-params/controller?
[09:42:02.0360]
shu: hmm maybe it doesn't, it just looks at [[ErrorData]] but also checks it's not a platform object... I wonder if that ends up doing the right thing for a DOMException with a stack. I guess not?
[09:43:18.0695]
`DOMException`'s serialization steps explicitly include serializing the stack IIRC
[09:43:58.0467]
Noam Rosenthal: yeah, I think that would be an improvement (although there's a bit public/private member tension there in that some state should be available to fetch callers and some shouldn't)
[09:44:43.0460]
annevk: fetch callers anyway pass along the request so they have access to its done & TAO fail
[09:45:37.0385]
Noam Rosenthal: yeah that's equally dumb, fair
[09:46:10.0421]
Noam Rosenthal: arguably URL list should be on controller too, slowly turning request back into an immutable thingie
[09:47:13.0642]
annevk: are `Request` object reusable? Seems like they are and they don't re-initialize their associated internal `request`, which means that currently in the spec there is a "bug" where e.g. if a request would fail TAO then subsequent fetches with the same request object would also fail TAO
[09:47:34.0755]
(probably similar bugs with URL-list)
[09:49:01.0918]
Andreu Botella: shu: though that combination probably means that user-thrown errors end up being treated differently? In that they won't have [[ErrorData]] or custom serialization steps
[09:49:59.0253]
Noam Rosenthal: each time you invoke `fetch()` it runs the `Request` constructor
[09:51:21.0894]
> <@annevk:mozilla.org> Noam Rosenthal: each time you invoke `fetch()` it runs the `Request` constructor
Right, but it doesn't clone the internal request. it runs `Request(prevRequest: Request)` which internally doesn't clone, but reuses the internal object (https://fetch.spec.whatwg.org/#dom-request 6.2)
[09:51:40.0663]
If a user throws a `new Error()`, it will have [[ErrorData]] – not sure if that's the distinction you meant
[09:52:35.0890]
Noam Rosenthal: but then step 12 happens
[09:53:40.0752]
annevk: ah. in that case I guess request could have also held the timing info as it's one request per fetch, and perhaps we didn't really need the controller?
[09:54:49.0744]
Andreu Botella: that's the distinction i'm imagining
[09:55:21.0996]
i can see the SES folks who raised the concern caring about that kind of distinguishing
[09:55:25.0877]
i just don't think it's possible
[09:55:30.0433]
Noam Rosenthal: we need a controller for cancelation
[09:55:55.0276]
Noam Rosenthal: and once we have a controller for that purpose, we can also it for general state changes for which "request" isn't really suitable
[09:56:01.0715]
I guess external caller can still fetch the same request twice
[09:56:12.0296]
which would have the TAO bug if any caller actually did that
[09:57:12.0642]
Yeah, it's just poor design, but fortunately it hasn't leaked to any public API
[10:00:18.0186]
annevk: ok, so to summarize: there's no current bug because callers behave even though it's not asserted, and moving this to the controller will allow us to prevent future cases of this potential design issue.
[10:12:59.0103]
annevk: uploaded a new revision, without the new states and ensures callers don't meddle with state except by terminating/aborting, as there is no need for "concluded" state. `conclude` now only reports timing.
2022-05-24
[02:50:10.0383]
Andreu Botella: if you do something like `class CustomError extends Error { name = "CustomError" }` the `name` won't get preserved (and neither will the subclass)
[02:51:42.0636]
Perhaps that's not a concern though. If they don't end up doing anything like serialization/deserialization I won't care too much.
[03:51:28.0178]
annevk: re fetch controller, the initial plan was to have it reported from within fetch, but then we wanted to allow callers to be in charge of when reporting happens, whether it happens at all, and to affect the `response end` time. The change of behavior would be mainly for scripts, because they won't be able to report timing as if it was a network error after the response has arrived, but maybe that's OK
[05:08:33.0300]
Noam Rosenthal: yeah, I guess I'm wondering whether we now know enough to invert control, but I would be okay with keeping the existing setup
[05:08:46.0732]
Noam Rosenthal: if we keep the existing setup, perhaps we shouldn't rename it to "conclude" though
[05:09:06.0550]
Noam Rosenthal: and just refactor where we keep some of the structs
[05:09:20.0997]
annevk: it doesn't really finalize anything, so perhaps "report timing" is enough
[05:09:59.0587]
annevk: What does it mean "some of the structs"?
[05:11:08.0562]
Noam Rosenthal: moving timing info from response to controller and creating body info
[05:11:48.0375]
annevk: one thing that would simplify the HTML PR a lot is if we allowed inversion of control as a default but allowed to override it like in the case of CSS and scripts
[05:12:44.0637]
like, pass on an initiator type and an auto-report boolean
[05:13:09.0381]
So 95% of callers would not need to do extra work reporting stuff
[05:20:37.0432]
... anyway, I updated the PR based on this conversation.
[05:22:33.0494]
Noam Rosenthal: yeah that would make sense; I'd also be curious to learn why CSS and scripts cannot use it, but probably best discussed in a new issue then
[06:23:54.0094]
annevk: scripts report an error for non-script mime types
[06:25:04.0109]
Noam Rosenthal: hmm, some of those checks happen before the script element so it wouldn't be able to distinguish those from a network error
[06:25:21.0368]
Noam Rosenthal: and classic scripts don't do that, they accept most types
[06:27:08.0267]
Noam Rosenthal: anyway, I gotta go for a bit (not sure if I will have time to look into this more today); could you create an issue to track this? (https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-mime-type? is the algorithm that's part of fetch that ends up blocking certain responses on the network layer which the caller would be unaware of.)
[06:34:57.0071]
> <@annevk:mozilla.org> Noam Rosenthal: hmm, some of those checks happen before the script element so it wouldn't be able to distinguish those from a network error
Thanks! For CSS I'm sure we can manage, for scripts I'll investigate. I remember that in some areas HTML sets a network error
[08:12:29.0966]
Wow https://github.com/whatwg/html/issues/7952 is fun
[09:27:04.0379]
Yeah, stuff like that is what makes the HTML Standard uniquely interesting to work on. Someone adds a bell or whistle to one part of the web platform and then HTML falls over (or not, as may be the case here) in dramatic fashion.
[16:23:25.0224]
what the
[16:24:23.0498]