2023-05-02
[11:46:22.0077] <jugglinmike>
> <@annevk:matrix.org> And it's not like we really govern `file:` fetching to begin with, it's pretty explicitly undefined

Thanks. It sounds like that issue was invalid from the start. I'll review Fetch and see about petitioning implementations to support it.


2023-05-03
[05:18:15.0786] <annevk>
Domenic: on reflection, it should probably be `Document.parseHTML()`. If we ever wanted to tackle non-HTML cases we could do a whole swath of XML-named variants.

[05:47:31.0558] <annevk>
Dominic Farolino: did you forget to push in https://github.com/w3c/csswg-drafts/pull/8759? If not, my first comment still applies I think. Please clarify if you think it doesn't.

[05:48:28.0474] <Dominic Farolino>
Oh hmmm... yeah it looks like I did. Sorry, let me fix that in a bit.

[05:49:49.0585] <Dominic Farolino>
I'm pretty sure I made the commit somewhere... maybe on a different computer & never pushed it heh


2023-05-04
[01:57:26.0408] <annevk>
Domenic: not sure I'm totally onboard yet, but it might be interesting to figure out how often `stopImmediatePropagation()` is used and whether we could make it controlled by yet another boolean controlled by the dispatcher

[09:32:35.0028] <smaug>
bkardell: oops, did I leave too early

[09:32:38.0358] <smaug>
I'll try to review the pr

[09:32:51.0821] <smaug>
ping me if I don't

[09:32:59.0479] <smaug>
(I was traveling last week)

[09:44:45.0679] <bkardell>
> <@smaug:mozilla.org> bkardell: oops, did I leave too early

nope, I just said what it was really and please have a look

[09:55:02.0283] <bkardell>
annevk: sorry about that - i think I fixed the things you mentioned last week. I expect that line wrapping bit is gonna be a general thing to fix in the other :dir PR too

[09:55:58.0870] <bkardell>
(in the silly 9088 one https://github.com/whatwg/html/pull/9088)

[10:14:21.0209] <annevk>
bkardell: it would be great if any nits are fixed ahead of general review as the nits tend to make reviews very noisy

[10:53:22.0571] <annevk>
Andreu Botella: thanks again for https://github.com/whatwg/url/pull/735#issuecomment-1441503315! I will try to find some time to write tests soon

[10:53:34.0340] <Andreu Botella>
sure!

[11:00:36.0593] <bkardell>
> <@annevk:matrix.org> bkardell: it would be great if any nits are fixed ahead of general review as the nits tend to make reviews very noisy

You mean on the dir one?

[13:08:55.0053] <bkardell>
> <@bkardell:igalia.com> You mean on the dir one?

hopefully done with my last commit!  Unless I've misunderstood, which is totally possible


2023-05-05
[18:11:57.0769] <Dominic Farolino>
Anyone been seeing some weird ref box formatting like this?

[20:30:27.0326] <Domenic>
> <@domfarolino:matrix.org> Anyone been seeing some weird ref box formatting like this?

Probably related to https://github.com/whatwg/meta/issues/271

[23:29:22.0694] <zcorpan>
annevk: I guess https://github.com/w3ctag/design-reviews/issues/392#issuecomment-510855073 has been addressed?

[23:34:12.0375] <annevk>
zcorpan: at least partially I think, but it's been a while and HTML's terminology around this changed.

[23:34:59.0884] <annevk>
zcorpan: it used to do checks on the number of top-level bcs in a bcg, I think, but again, it's been a while.

[23:43:18.0916] <zcorpan>
annevk: ok yeah, seems to be step 6 in https://wicg.github.io/scroll-to-text-fragment/#restricting-the-text-fragment

[02:24:05.0889] <sideshowbarker>
This room is now also being logged to https://archive.matrix.org/r/whatwg:matrix.org

The logs have timestamp links — but somewhat unfortunately, the links are matrix.to URLs rather than being URLs for the archive.matrix.org logs themselves.

So that means that anybody wanting to view the messages needs to have a Matrix client installed in order to read them.

That seems… suboptimal — so I’m hoping there will eventually be a way to share timestamp URLs to the archive.matrix.org logs themselves. (I’ve pinged the maintainers already to ask.)

[05:20:34.0076] <annevk>
bkardell: so `data-x="valid custom element name">` does have break opportunities as well...

[05:20:54.0798] <annevk>
bkardell: do you want to try one more time or should I take over?

[05:21:38.0495] <bkardell>
where is the break opportunities, the spaces in the attribute?

[05:21:52.0514] <bkardell>
 * where is the break opportunities, the spaces in the attribute? annevk 

[05:22:03.0126] <bkardell>
no I'd really like to understand, thanks for your patience

[05:22:52.0942] <annevk>
bkardell: yeah exactly, essentially if you put it all on one conceptual line, any space is a break opportunity (for the purposes of the HTML Standard)

[05:22:53.0051] <bkardell>
 * where are the break opportunities, the spaces in the attribute? annevk

[05:23:02.0858] <bkardell>
ok

[05:23:56.0208] <annevk>
bkardell: it's documented at https://github.com/whatwg/html/blob/main/CONTRIBUTING.md#source-formatting

[05:27:09.0031] <bkardell>
ok I _hope_ i got it submitted correctly now

[05:28:36.0443] <bkardell>
 * ok I _hope_ i got it submitted correctly now annevk 

[05:33:31.0862] <annevk>
bkardell: https://twitter.com/htmlstandard/status/1654464175890989056 \o/

[05:33:52.0908] <bkardell>
woohoo thanks

[05:34:29.0301] <bkardell>
now that we landed the super easy editorial one the realy hard directionality one should be a piece of cake :-p 

[06:04:11.0488] <sideshowbarker>
https://github.com/matrix-org/matrix-public-archive/issues/137

[14:04:15.0386] <TabAtkins>
sideshowbarker: Heya, the CSSWG drafts server now just employs an internal redirect to the github.io versions, so I've set up some redirects to ensure that anyone hitting those github URLs gets kicked over to the drafts server URL. Do you still need the timestamps.json file? At the moment I've just killed it, but I can restore it if needed.


2023-05-08
[00:11:37.0030] <sideshowbarker>
> <@tabatkins:matrix.org> sideshowbarker: Heya, the CSSWG drafts server now just employs an internal redirect to the github.io versions, so I've set up some redirects to ensure that anyone hitting those github URLs gets kicked over to the drafts server URL. Do you still need the timestamps.json file? At the moment I've just killed it, but I can restore it if needed.

Thanks for the heads-up. Yes, please, if you can restore the `timestamps.json` file, I’d much appreciated it. Without the old Last-Revised header — and with the Last-Modified header not showing the actual publication date — there’s otherwise no good way to programatically from client code to determine the dates of the published specs. (That is, without resorting to parsing or scraping the HTML from a response, or running a git command to check when the last update was made to the corresponding git source).

[00:12:23.0380] <sideshowbarker>
> <@tabatkins:matrix.org> sideshowbarker: Heya, the CSSWG drafts server now just employs an internal redirect to the github.io versions, so I've set up some redirects to ensure that anyone hitting those github URLs gets kicked over to the drafts server URL. Do you still need the timestamps.json file? At the moment I've just killed it, but I can restore it if needed.

 * Thanks for the heads-up. Yes, please, if you can restore the `timestamps.json` file, I’d much appreciated it. Without the old Last-Revised header — and with the Last-Modified header not showing the actual publication date — there’s otherwise no good way programatically, from client code, to determine the dates of the published specs. (That is, without resorting to parsing or scraping the HTML from a response, or running a git command to check when the last update was made to the corresponding git source).

[00:13:05.0992] <sideshowbarker>
 * Thanks for the heads-up. Yes, please, if you can restore the `timestamps.json` file, I’d much appreciate it. Without the old Last-Revised header — and with the Last-Modified header not showing the actual publication date — there’s otherwise no good way programatically, from client code, to determine the dates of the published specs. (That is, without resorting to parsing or scraping the HTML from a response, or running a git command to check when the last update was made to the corresponding git source).

[02:22:17.0215] <sideshowbarker>
Andreu Botella:  I don’t know you’re aware already, but the spec build for the unversioned CSS specs is currently broken. I think Tab has an idea how to fix it and may just need to make time to do that once he’s back online — but in the meantime maybe you have some insight on an elegant way to get it working again, given the current state of things.

And the current state of things appears to be that drafts.csswg.org is now just proxying w3c.github.io/csswg-drafts — while requests to w3c.github.io/csswg-drafts are now redirecting to drafts.csswg.org — but only partially. (How that setup is actually working at all, I don’t really understand yet.)

The related build changes are in https://github.com/w3c/csswg-drafts/commit/52077ef4b1b0459f2aef3179dcf47a6c3e185012 and https://github.com/w3c/csswg-drafts/commit/8523f13a005f7213c39200e24944f8549e9e5227, and what’s partial about the redirect behavior is this:
- All _versioned_ CSS spec URLs (such as https://w3c.github.io/csswg-drafts/css-backgrounds-3/) are now being redirected to their corresponding drafts.csswg.org URLs (such as https://drafts.csswg.org/css-backgrounds-3/)
- However, all _unversioned_ CSS spec URLs (such as https://w3c.github.io/csswg-drafts/css-backgrounds/) are _not_ being redirected but are instead now just 404s. And among other things, that means all the current 1000+ spec links in CSS articles in MDN are now 404s.
At https://github.com/w3c/csswg-drafts/issues/8798#issuecomment-1536775277 Tab mentions it'd be a bunch of trouble to get the redirects for the unversioned spec URLs working. But since I think you originally wrote the build code, it seems possible you might have some idea of how to do it with less trouble.

[02:23:10.0519] <sideshowbarker>
 * Andreu Botella:  I don’t know you’re aware already, but the spec build for the unversioned CSS specs is currently broken. I think Tab has an idea how to fix it and may just need to make time to do that once he’s back online — but in the meantime maybe you have some insight on an elegant way to get it working again, given the current state of things.

And the current state of things appears to be that drafts.csswg.org is now just proxying w3c.github.io/csswg-drafts — while requests to w3c.github.io/csswg-drafts are now redirecting to drafts.csswg.org — but only partially. (How that setup is actually working at all, I don’t really understand yet.)

The related build changes are in https://github.com/w3c/csswg-drafts/commit/52077ef4b1b0459f2aef3179dcf47a6c3e185012 and https://github.com/w3c/csswg-drafts/commit/8523f13a005f7213c39200e24944f8549e9e5227, and what’s partial about the redirect behavior is this:

- All _versioned_ CSS spec URLs (such as https://w3c.github.io/csswg-drafts/css-backgrounds-3/) are now being redirected to their corresponding drafts.csswg.org URLs (such as https://drafts.csswg.org/css-backgrounds-3/)
- However, all _unversioned_ CSS spec URLs (such as https://w3c.github.io/csswg-drafts/css-backgrounds/) are _not_ being redirected but are instead now just 404s.
  And among other things, that means all the current 1000+ spec links in CSS articles in MDN are now 404s.

At https://github.com/w3c/csswg-drafts/issues/8798#issuecomment-1536775277 Tab mentions it'd be a bunch of trouble to get the redirects for the unversioned spec URLs working. But since I think you originally wrote the build code, it seems possible you might have some idea of how to do it with less trouble.

[03:35:21.0002] <Andreu Botella>
> <@sideshowbarker:matrix.org> Andreu Botella:  I don’t know you’re aware already, but the spec build for the unversioned CSS specs is currently broken. I think Tab has an idea how to fix it and may just need to make time to do that once he’s back online — but in the meantime maybe you have some insight on an elegant way to get it working again, given the current state of things.
> 
> And the current state of things appears to be that drafts.csswg.org is now just proxying w3c.github.io/csswg-drafts — while requests to w3c.github.io/csswg-drafts are now redirecting to drafts.csswg.org — but only partially. (How that setup is actually working at all, I don’t really understand yet.)
> 
> The related build changes are in https://github.com/w3c/csswg-drafts/commit/52077ef4b1b0459f2aef3179dcf47a6c3e185012 and https://github.com/w3c/csswg-drafts/commit/8523f13a005f7213c39200e24944f8549e9e5227, and what’s partial about the redirect behavior is this:
> 
> - All _versioned_ CSS spec URLs (such as https://w3c.github.io/csswg-drafts/css-backgrounds-3/) are now being redirected to their corresponding drafts.csswg.org URLs (such as https://drafts.csswg.org/css-backgrounds-3/)
> - However, all _unversioned_ CSS spec URLs (such as https://w3c.github.io/csswg-drafts/css-backgrounds/) are _not_ being redirected but are instead now just 404s.
>   And among other things, that means all the current 1000+ spec links in CSS articles in MDN are now 404s.
> 
> At https://github.com/w3c/csswg-drafts/issues/8798#issuecomment-1536775277 Tab mentions it'd be a bunch of trouble to get the redirects for the unversioned spec URLs working. But since I think you originally wrote the build code, it seems possible you might have some idea of how to do it with less trouble.

I wasn't aware, I haven't really been keeping track of what was going on with the spec builds. But let me take a look

[04:12:12.0819] <timdream>
Is the event firing order on the same node spec’d anywhere? I saw a blog post saying that the language regarding event firing order (“… in their order of registration.”) was present in the UI Event level 3 draft around 2011 but removed in 2016.
It was indeed not explained in the currency UI Event spec, but the section on “changes from DOM level 2” did mention the event listeners is now ordered.
I am very confused by that blog post…

Post: https://blog.gslin.org/archives/2023/05/08/11176/
Current UI Event draft: https://w3c.github.io/uievents/#event-flow

[04:12:49.0731] <timdream>
* Is the event firing order on the same node spec’d anywhere? I saw a blog post saying that the language regarding event firing order (“… in their order of registration.”) was present in the UI Event level 3 draft around 2011 but removed in 2016.
It was indeed not explained in the currenct UI Event spec, but the section on “changes from DOM level 2” did mention the event listeners is now ordered.
I am very confused by that blog post…
Post: https://blog.gslin.org/archives/2023/05/08/11176/
Current UI Event draft: https://w3c.github.io/uievents/#event-flow

[04:15:51.0535] <Domenic>
What do you mean "event firing order"? Do you have a code example?

[04:28:30.0870] <timdream>
> <@domenicdenicola:matrix.org> What do you mean "event firing order"? Do you have a code example?

el.addEventListener(e => console.log("a")
el.addEventListener(e => console.log("b")
el.addEventListener(e => console.log("c")
el.dispatchEvent(new Event("test"))

[04:29:42.0133] <timdream>
Should console always print a,b,c per spec?

[04:31:51.0554] <Domenic>
Yes. This is specified in https://dom.spec.whatwg.org.

[04:33:15.0840] <timdream>
Domenic: could you point me the section? Sorry I couldn’t find it.

[04:34:31.0373] <Domenic>
https://dom.spec.whatwg.org/#dispatching-events

[04:35:03.0176] <timdream>
> <@domenicdenicola:matrix.org> https://dom.spec.whatwg.org/#dispatching-events

Wonderful, thank you!

[11:26:54.0615] <TabAtkins>
sideshowbarker: Both unversioned symlinks and the timestamps.json file are back in place, lmk if anything is still wonky on your end.

[15:55:57.0067] <Richard Gibson>
what happens if an author does something like this:
```
function generateBid(foo, bar, baz, setBid) {
  Promise.resolve()
    .then(() => setBid("post hoc"));
}
```
an exception?


2023-05-09
[20:17:28.0034] <sideshowbarker>
> <@tabatkins:matrix.org> sideshowbarker: Both unversioned symlinks and the timestamps.json file are back in place, lmk if anything is still wonky on your end.

Hot diggity dog 🎉 I’ll take a look now

[20:29:54.0626] <sideshowbarker>
> <@tabatkins:matrix.org> sideshowbarker: Both unversioned symlinks and the timestamps.json file are back in place, lmk if anything is still wonky on your end.

All working for me so far except for one problem: fragment IDs get don’t get handled right across the redirect; e.g., https://w3c.github.io/csswg-drafts/css-cascade-5/#layering ends up redirecting to https://drafts.csswg.org/css-cascade-5/#layering##layering — that is, the fragment part unexpectedly becomes `#layering##layering`.

I can look at the code myself this afternoon my time to try figure out why that’s happening, and patch it (if you don’t get to it first)

[20:30:29.0174] <TabAtkins>
Oh lol whoops, I tested that, weird

[20:30:49.0052] <TabAtkins>
Maybe I tested the versions before my new fragment code got built in

[20:30:53.0016] <TabAtkins>
Will fix tomorrow

[20:35:06.0370] <sideshowbarker>
Hai

[23:24:26.0204] <agnieszkamalutka12345>
  https://open.spotify.com/album/4k5cbXoFmZ5fgL06VT5tXR?si=prmDfLo5SY2eItQzgnWuYg&utm_source=copy-link https://docs.google.com/document/d/1O8UWReNENzJvCdLqQz9FMgyBPYYap_F-Sp6goCE9gS8/edit?usp=drivesdk&disco=AAAAh-Naur8

[23:28:50.0341] <agnieszkamalutka12345>
  https://open.spotify.com/album/4k5cbXoFmZ5fgL06VT5tXR?si=prmDfLo5SY2eItQzgnWuYg&utm_source=copy-link_sideshowbarker_: 

[23:29:07.0441] <agnieszkamalutka12345>
https://docs.google.com/document/d/1O8UWReNENzJvCdLqQz9FMgyBPYYap_F-Sp6goCE9gS8/edit?usp=drivesdk&disco=AAAAh-Naur8

[23:29:38.0928] <agnieszkamalutka12345>
 * https://docs.google.com/document/d/1O8UWReNENzJvCdLqQz9FMgyBPYYap_F-Sp6goCE9gS8/edit?usp=drivesdk&disco=AAAAh-Naur8


2023-05-10
[05:18:24.0901] <sideshowbarker>
> <@tabatkins:matrix.org> Maybe I tested the versions before my new fragment code got built in

So I spent some time trying to learn how the redirects are set up, and to find where the code for the redirects lives — but so I’ve not been able to find anything at all, really.

Given what I understand about what’s possible in on GitHub Pages hosting, and given that when I make requests with curl, I just get a 200s, and the index files that come back from curl requests don’t seem to have any kind of client-side redirects in them, at this point it’s kind of baffling to me how the redirects are actually work, or how they _could_ actually even work.

The only clue I have so for is the BUILTBYGITHUBCI text macro I see in the bikeshed calls in the workflow file — but grepping around for that, I don’t find anywhere that’s actually used for anything.

So I’m pretty much stumped :(

[05:18:38.0635] <sideshowbarker>
> <@tabatkins:matrix.org> Maybe I tested the versions before my new fragment code got built in

 * So I spent some time trying to learn how the redirects are set up, and to find where the code for the redirects lives — but so I’ve not been able to find anything at all, really.

Given what I understand about what’s possible in GitHub Pages hosting, and given that when I make requests with curl, I just get a 200s, and the index files that come back from curl requests don’t seem to have any kind of client-side redirects in them, at this point it’s kind of baffling to me how the redirects are actually work, or how they _could_ actually even work.

The only clue I have so for is the BUILTBYGITHUBCI text macro I see in the bikeshed calls in the workflow file — but grepping around for that, I don’t find anywhere that’s actually used for anything.

So I’m pretty much stumped :(

[05:19:36.0234] <Andreu Botella>
I actually made some progress while investigating that

[05:19:44.0119] <Andreu Botella>
https://github.com/speced/bikeshed-boilerplate/blob/main/boilerplate/csswg/abstract.include <- this is where that macro is used

[05:19:48.0460] <sideshowbarker>
 * So I spent some time trying to learn how the redirects are set up, and to find where the code for the redirects lives — but so I’ve not been able to find anything at all, really.

Given what I understand about what’s possible in GitHub Pages hosting, and given that when I make requests with curl, I just get a 200s, and the index files that come back from curl requests don’t seem to have any kind of client-side redirects in them, at this point it’s kind of baffling to me how the redirects are actually work, and however they’re set up, how they could actually even work.

The only clue I have so for is the BUILTBYGITHUBCI text macro I see in the bikeshed calls in the workflow file — but grepping around for that, I don’t find anywhere that’s actually used for anything.

So I’m pretty much stumped :(

[05:20:04.0914] <sideshowbarker>
oh — I’ll look right now

[05:20:49.0510] <Andreu Botella>
that script only redirects if the page isn't being served by drafts.csswg.org

[05:21:05.0811] <sideshowbarker>
ah, the separate bikeshed-boilerplate repo — that’s the one place I had not thought to look at so far. Now it seems obvious that’s where I should have looked 

[05:22:33.0059] <sideshowbarker>
> <@abotella:igalia.com> https://github.com/speced/bikeshed-boilerplate/blob/main/boilerplate/csswg/abstract.include <- this is where that macro is used

OK yeah so it seems the `draftUrl += "#"+location.hash` step isn’t needed at all, maybe?

[05:23:14.0295] <Andreu Botella>
yeah, shouldn't be

[05:23:22.0755] <sideshowbarker>
OK

[05:24:11.0424] <sideshowbarker>
(but even if that step were needed, it should instead be `draftUrl += location.hash`, since `location.hash already includes the `#`

[05:24:18.0280] <sideshowbarker>
 * (but even if that step were needed, it should instead be `draftUrl += location.hash`, since `location.hash` already includes the `#\`

[05:24:28.0240] <sideshowbarker>
 * (but even if that step were needed, it should instead be `draftUrl += location.hash`, since `location.hash` already includes the `#`

[05:24:51.0440] <sideshowbarker>
so I see now that‘s why we end up with the doubled `##`

[05:25:03.0605] <sideshowbarker>
e.g., https://drafts.csswg.org/css-backgrounds/#the-background##the-background

[05:26:00.0390] <Andreu Botella>
For unversioned specs, it seems like the mapping to a version is handled purely in the drafts server, and then the versioned spec is proxied from the github pages site

[05:26:31.0933] <Andreu Botella>
but since the github pages site doesn't build the index or the unversioned copies, opening those on the gihtub page

[05:26:42.0478] <Andreu Botella>
 * but since the github pages site doesn't build the index or the unversioned copies, opening those on the github pages site doesn't redirect to the drafts site

[05:34:05.0809] <sideshowbarker>
Andreu Botella: thanks, opened a PR at https://github.com/speced/bikeshed-boilerplate/pull/39 which just reverts the entire change that added the `draftUrl += "#"+location.hash` part


2023-05-11
[18:37:50.0939] <jugglinmike>
Is `toString` intentionally omitted from the Location object's IDL? https://html.spec.whatwg.org/multipage/nav-history-apis.html

[19:23:06.0941] <jugglinmike>
Actually, since `toString` could alternatively be defined in the additional creation steps but is not, I ought to ask: can someone tell me where `location.toString` is defined? (Chrome and Firefox expose it as an "own" property. Unlike what's spec'd for `location.valueOf`, the value is distinct from the corresponding property on the Object prototype.)

[19:55:53.0131] <jugglinmike>
This was the central topic of [this 2017 patch](https://github.com/whatwg/html/pull/2294), but the resolution is confusing me. The change to the specification seems to rely on prototypal inheritance of `Object.prototype.toString`, but [the corresponding tests added to WPT](https://github.com/web-platform-tests/wpt/pull/4623) expect an "own" property.

[22:26:57.0310] <bakkot>
question:

- "resolve a URL-like module specifier" takes a string https://html.spec.whatwg.org/multipage/webappapis.html#resolving-a-url-like-module-specifier
- but it calls "URL parsing", which takes a scalar value string, i.e. one with no unpaired surrogates https://url.spec.whatwg.org/#concept-url-parser

how does that... work? is it implicitly "convert"ing strings to scalar strings? https://infra.spec.whatwg.org/#javascript-string-convert

assuming yes, in which case Chrome has a bug - `import('./\ud800.js')` doesn't actually end up triggering a network request for `%EF%BF%BD.js”`, which is what it would do if it did the specified conversion (FF and Safari do trigger that request)

[22:31:32.0330] <sideshowbarker>
TabAtkins: https://github.com/speced/bikeshed-boilerplate/pull/39 is a patch for making that change to fix the fragment-preserving redirect behavior for the CSS specs

[00:19:15.0928] <annevk>
snek: I'm gonna take over your WebSockets work, hope that's okay

[00:22:40.0497] <annevk>
bakkot: it's not, you found a bug, but Fx/Safari behave as the spec should read (it should call convert before it calls the URL parser)

[06:43:40.0641] <annevk>
smaug: did you follow the discussion in https://github.com/whatwg/dom/pull/1152? Are you still okay with the PR as-is?

[06:43:57.0021] <annevk>
smaug: I'm okay with it still I think, but I'd like at least one more set of eyes

[07:20:00.0297] <snek>
> <@annevk:matrix.org> snek: I'm gonna take over your WebSockets work, hope that's okay

go for it fam

[07:24:31.0044] <annevk>
snek: shall I add you to the Acknowledgments section?

[07:25:35.0834] <snek>
oh you opened a whole separate pr

[07:25:55.0316] <snek>
yeah some form of attribution would be nice

[07:28:50.0165] <snek>
does your change make it so that the resulting .url will still be ws scheme?

[07:29:11.0749] <snek>
I'm not a huge fan but I'll take what I can get

[07:34:03.0406] <annevk>
snek: it does, I don't think it's worth supporting two sets of URLs (even though we later do rewrite back to HTTP(S)); it's unfortunate we added ws/wss, but they are what callers of `.url` expect

[08:22:10.0176] <Dominic Farolino>
Is there a way to click on a reference of a dfn in a spec, and immediately get a link to *that* reference? (Instead of having to go to the dfn, have the gray dfn box pop up, and binary search through it to find which reference I was at a second ago)

[08:45:57.0189] <zcorpan>
Dominic Farolino: inspect element, copy id

[08:46:30.0451] <Dominic Farolino>
Yikes! In at least the HTML Standard inspecting by element gives me a huge layout shift due to DevTools being popped

[08:46:43.0336] <zcorpan>
or select the link and click the file a bug link

[08:47:27.0661] <zcorpan>
Dominic Farolino: if you have devtools at the bottom there's no layout shift

[08:47:30.0218] <Dominic Farolino>
What do you mean by "select the link"? Click it? Highlight it?

[08:47:34.0591] <Dominic Farolino>
That's true

[08:47:56.0062] <zcorpan>
Highlight it

[08:48:29.0675] <smaug>
annevk: hmm, I had missed possible change to existing behavior 

[08:49:24.0950] <smaug>
but I think the new behavior is better, if original is aborted first (in that fetch test)

[08:49:35.0473] <smaug>
so, I think the pr should be fine

[09:06:34.0125] <annevk>
smaug: thanks, checking with cdumez as well and then I guess I'll merge it tomorrow or early next week

[10:06:05.0730] <jub0bs>
Is there anyone from Mozilla around? I'd like to gain access to https://bugzilla.mozilla.org/show_bug.cgi?id=1790311 (which is referenced on https://www.mozilla.org/en-US/security/advisories/mfsa2022-47/#CVE-2022-45411). The bug could presumably be made public, at this stage.

[10:07:18.0508] <jub0bs>
annevk: Am I correct in assuming that CVE-2022-45411 is what prompted you to add `X-HTTP-Method-Override` and the other two as "conditional" forbidden request-header names?

[10:07:47.0954] <jub0bs>
 * annevk: Am I correct in assuming that CVE-2022-45411 is what prompted you to add `X-HTTP-Method-Override` and the other two as "conditional" forbidden request-header names? https://github.com/whatwg/fetch/pull/1541

[10:08:39.0754] <annevk>
jub0bs: I'm not familiar with CVE numbers

[10:09:00.0216] <annevk>
 * jub0bs: I'm not familiar with specific CVE numbers

[10:09:30.0971] <annevk>
Oh, you linked something above. Seems likely?

[10:22:17.0713] <jub0bs>
> Cross-Site Tracing occurs when a server will echo a request back via the Trace method, allowing an XSS attack to access to authorization headers and cookies inaccessible to JavaScript (such as cookies protected by HTTPOnly). To mitigate this attack, browsers placed limits on fetch() and XMLHttpRequest; however some webservers have implemented non-standard headers such as X-Http-Method-Override that override the HTTP method, and made this attack possible again. Firefox has applied the same mitigations to the use of this and similar headers.

[10:23:15.0985] <jub0bs>
annevk: It has to be related, but your PR (#1541) on the Fetch standard doesn't make explicit reference to this.

[11:08:33.0387] <annevk>
jub0bs: it's not something we keep track of when doing web standard security fixes

[12:08:24.0304] <TabAtkins>
sideshowbarker: Merged, sorry for the delay.


2023-05-12
[23:45:18.0053] <annevk>
Domenic: thoughts on using "nullable" instead of "null or": https://github.com/whatwg/notifications/pull/194/files?

[23:46:08.0048] <Domenic>
Huh. I guess it's OK, but I've never done it and slightly prefer what I do...

[23:46:49.0470] <annevk>
Yeah, I similarly have mixed feelings. I guess I'll push back a bit and ask for an Infra discussion first, though even in IDL we kinda regret the ?-convention so maybe we should just not.

[00:02:26.0085] <annevk>
Adam Rice: did you see https://github.com/whatwg/websockets/pull/45?

[00:40:13.0125] <annevk>
Adam Rice: well that was embarrassing, fortunately tests and code did not make that mistake

[00:48:12.0596] <jub0bs>
Hi Simon. Sorry to bother you. Any chance you or someone else from Mozilla could make the following ticket public? https://bugzilla.mozilla.org/show_bug.cgi?id=1790311

[00:48:43.0707] <jub0bs>
It's related to CVE-2022-45411, which has since been mitigated.

[00:49:36.0038] <jub0bs>
Oh wrong thread. Sorry.

[00:49:59.0281] <jub0bs>
zcorpan: Perhaps?

[00:59:40.0663] <annevk>
Domenic: did you see my ping for review on the timer bits of https://github.com/whatwg/html/pull/4613? It's a relatively small PR, mainly JS asking HTML to run stuff at particular points in time.

[01:00:11.0720] <Domenic>
No, sorry I did not. Will flag it and get to it soon.

[01:10:49.0381] <zcorpan>
freddy: ^

[01:12:57.0429] <freddy>
Done.

[01:15:19.0175] <zcorpan>
annevk: for https://github.com/whatwg/websockets/pull/45 maybe we need new tests with multiple globals to check which one is used for the base URL?

[01:17:05.0628] <jub0bs>
Excellent. Thank you, freddy .

[01:20:37.0399] <jub0bs>
I have some thoughts about this, though I don't want to go into too much details in public yet.

[01:21:57.0874] <jub0bs>
Some servers are still vulnerable, even after Chromium's and Firefox's fixes. But the servers in question deviate from the HTTP standard, and protecting them is probably not the responsibility of browser vendors.

[01:24:04.0008] <jub0bs>
Not sure if it's worth raising an issue about that, but let me know if you're interested.

[01:26:18.0018] <freddy>
̉I think we would like to know more. A private issue in the fetch repo might be a good coordination forum, similar to how we dealt with this one. WDYT, annevk?

[01:26:33.0120] <annevk>
zcorpan: not a bad idea, want to make one?

[01:32:18.0084] <zcorpan>
annevk: sure. I found https://github.com/web-platform-tests/wpt/blob/master/html/browsers/browsing-the-web/navigating-across-documents/multiple-globals/resources/context-helper.js which seems helpful

[01:52:19.0672] <annevk>
zcorpan: that looks nice, nothing for current seemingly

[01:53:19.0179] <annevk>
zcorpan: or maybe current is what you put in `scriptToRun`?

[01:57:06.0539] <zcorpan>
annevk: I haven't understood it properly yet, but looks like current isn't covered

[02:04:21.0108] <zcorpan>
or I guess current is the test file itself

[02:14:39.0823] <zcorpan>
https://github.com/web-platform-tests/wpt/pull/39978

[02:27:45.0939] <jub0bs>
I'm not sure Anne has seen this. Matrix threads aren't ideal for visibility, it seems.

[06:19:41.0663] <annevk>
Seems fine. Or start with an email to some folks.

[06:19:54.0198] <annevk>
And yeah, Matrix is hmm...

[09:35:50.0697] <jub0bs>
annevk: Ok, thanks.

[09:35:57.0113] <jub0bs>
@fr should talk to you first. Depending on what you think, we can proceed

[09:36:32.0914] <jub0bs>
 * freddy: Perhaps I should talk to you first. Depending on what you think, we can proceed with a security advisory or do nothing.

[09:36:55.0353] <jub0bs>
If that's ok with you, let me know how I can contact you.

[09:53:06.0421] <annevk>
jarhar: belatedly noticed some minor follow-up required in https://github.com/whatwg/html/pull/9178

[09:53:19.0261] <annevk>
jarhar: see comment at the end

[09:53:50.0502] <jarhar>
woo @mention notifications are working

[09:53:54.0422] <jarhar>
thanks ill take a look

[10:15:24.0059] <annevk>
jarhar: they work vice versa as well, so feel free to ping if you feel like something is taking too long (though fair warning: my weekend has kinda started)


2023-05-13
[09:08:41.0633] <jub0bs>
annevk: 
> Or start with an email to some folks.
Did you have somebody specific in mind?


[09:08:48.0507] <jub0bs>
 * annevk:

> Or start with an email to some folks.

Did you have somebody specific in mind?


2023-05-15
[00:21:30.0535] <annevk>
Did https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/ end up regressing how Firefox deals with innerHTML in XML? C.f. https://bugs.webkit.org/show_bug.cgi?id=181642

[00:23:40.0003] <freddy>
sorry, it was already end of day for me when this thread continued. I am fbraun@mozilla.com

[09:38:27.0030] <bkardell>
Does clicking accept/commit suggestions on a PR against HTML just not work because of the size of it or something? I always get an error suggesting that there's been new commits and I need to refresh, but it's never the case

[10:25:42.0183] <annevk>
bkardell: that is correct, they won't work

[10:26:26.0572] <annevk>
They're still a very useful way to get the point across, so that's why they're still used. But yeah, it's not the best.

[11:19:01.0532] <bkardell>
> <@annevk:matrix.org> They're still a very useful way to get the point across, so that's why they're still used. But yeah, it's not the best.

It's good to know for sure, thanks annevk ... frustrating that the error is so misleading 

[13:16:27.0323] <zcorpan>
annevk: Domenic : so for WebSocket, since it's a constructor rather than a method, you can't use `.call(relevantGlobal)` and therefore relevant settings object doesn't make sense. Workers use current settings object: https://html.spec.whatwg.org/#dom-worker

[13:57:28.0641] <bakkot>
now that we ~have growable arraybuffers, thoughts on making TextEncoder's `encodeInto` able to grow the backing buffer? (probably as an opt-in option)

[13:58:07.0865] <bakkot>
e.g. if you are getting a stream of strings from somewhere and concatenating them all into a single buffer


2023-05-16
[17:47:49.0542] <Domenic>
bakkot: Seems somewhat reasonable, although I'd be especially happy if someone could do the analysis for all similar web platform methods. I think that would be: byobStreamReader.read(), textEncoder.encodeInto(), maybe crypto.getRandomValues()?

[21:40:07.0669] <annevk>
zcorpan: well, I think if we rewrote that to use "constructor steps" we'd use the relevant settings object of this, but you're correct that it'll be 1:1 with the current settings object

[23:57:36.0941] <annevk>
bakkot: how does that work, exactly? If you pass in too big a string `encodeInto()` would end up growing the buffer? Can that be overloaded or would that some new signature?

[23:58:57.0352] <annevk>
bakkot: anyway, seems worthwhile to write it down in a bit more detail in an issue. Might take a while, but it's always good to have ideas recorded in a logical place

[10:30:13.0600] <annevk>
Private fields don't work on derived classes? Am I missing something?

[10:31:34.0863] <nicolo-ribaudo>
Instance private fields work, static private fields only work if you access them using `ClassName.#priv` and not `this.#priv` (even from static methods)

[10:33:22.0093] <annevk>
nicolo-ribaudo: oh, maybe you can't declare them in the constructor? And I confused enclosing class with parent class, hmm

[10:33:33.0431] <annevk>
Ok, good if so

[10:35:52.0650] <nicolo-ribaudo>
You can only declare them outside of the constructor, using the fields syntax 

[10:36:24.0934] <nicolo-ribaudo>
If you want the inner class to have the same private fields as the outer one, that's not possible (even if you re-use the same name, it's a different "private key")

[10:48:31.0409] <jub0bs>
freddy: No problem! Thanks. I'll shoot you an email on Thursday.

[10:55:50.0830] <freddy>
Thursday is a holiday in Germany. I'll likely take a look on Monday then ;D


2023-05-17
[00:24:49.0826] <foolip>
annevk: I need your advice on algorithm invocation style. https://github.com/whatwg/fullscreen/pull/223 uses the style "Request removal from the top layer for element from its node document" and https://github.com/whatwg/html/pull/9093 uses the style "Request an element to be removed from the top layer given document and element." The first form has the arguments in the wrong order, but the second form is very wordy. What should we converge on?

[00:30:47.0281] <annevk>
foolip: I left a comment somewhere that I don't understand the need for both element and node document to be arguments

[00:32:12.0171] <annevk>
foolip: assuming a legit need, you could do something like "Request removal from the top layer given _element_ and _element_'s node document" or _element_'s node document and _element

[00:32:19.0643] <foolip>
annevk: I agree that's weird, and I haven't seen a case in review yet where the document is anything other than the element's node document.

[00:32:26.0104] <annevk>
 * foolip: assuming a legit need, you could do something like "Request removal from the top layer given _element_ and _element_'s node document" or _element_'s node document and _element_

[00:33:33.0446] <foolip>
annevk: but my question is more about writing the invocation in a style that flows more naturally, like Tab is doing. If the arguments were all right, which style would you want?

[00:34:29.0580] <annevk>
The style I double quoted above (though perhaps with the argument order reversed, depending)?

[00:37:19.0550] <foolip>
Oh, I'm a bad reader.

[00:41:18.0721] <foolip>
So in other words, use the "request removal from the top layer" form, but still "given" before the arguments, not the even more English-like variant. I agree with that.

[00:41:30.0680] <foolip>
Let me file an issue about the document arguments...

[00:49:17.0554] <sideshowbarker>
Looking at https://github.com/validator/validator/issues/1592 — it seems that bitbucket.io sites don’t allow HTTP 1.0 client requests, but apparently instead require HTTP 1.1 or greater.

Is this a thing these days? I mean, or other servers doing this? (I haven’t noticed many — as far as the HTML checker goes, I know all of them would fail with the checker.)

Is there some good reason for a Web server admin to disable HTTP 1.0 support?

[00:49:31.0975] <sideshowbarker>
 * Looking at https://github.com/validator/validator/issues/1592 — it seems that bitbucket.io sites don’t allow HTTP 1.0 client requests, but apparently instead require HTTP 1.1 or greater.

Is this a thing these days? I mean, are other servers doing this? (I haven’t noticed many — as far as the HTML checker goes, I know all of them would fail with the checker.)

Is there some good reason for a Web server admin to disable HTTP 1.0 support?

[00:54:45.0947] <foolip>
annevk: I've filed https://github.com/w3c/csswg-drafts/issues/8849

[03:39:43.0347] <Sam Sneddon [:gsnedders]>
> <@sideshowbarker:matrix.org> Looking at https://github.com/validator/validator/issues/1592 — it seems that bitbucket.io sites don’t allow HTTP 1.0 client requests, but apparently instead require HTTP 1.1 or greater.
> 
> Is this a thing these days? I mean, are other servers doing this? (I haven’t noticed many — as far as the HTML checker goes, I know all of them would fail with the checker.)
> 
> Is there some good reason for a Web server admin to disable HTTP 1.0 support?

typically wanting the `Host` header, and being able to server multiple sites from a single IP… though most HTTP/1.0 implementations support that too

[04:55:25.0147] <jub0bs>
freddy: No problem :) 

[07:57:06.0769] <jugglinmike>
> <@pvanderbeken:mozilla.org> jugglinmike: the second bullet point in https://webidl.spec.whatwg.org/#es-stringifier specifies that `toString` becomes an own property

Thanks, @peterv! I never would have found that on my own


2023-05-18
[01:09:21.0965] <annevk>
In retrospect `[SameAs=href] USVString toString();` or some such might have been better

[01:10:18.0767] <annevk>
WebKit has something like that so you can implement getters that return the same thing once and it's lovely

[05:58:46.0595] <annevk>
https://twitter.com/robpalmer2/status/1658914059578744835 made me think of a similar request I had seen for `AbortSignal` but I can't find it. Something like `AbortSignal.withAborter() -> { signal, aborter }`.

[10:02:16.0314] <Jeffrey Yasskin>
Is the advice in https://webidl.spec.whatwg.org/#idl-USVString that "Specifications should only use USVString for APIs that perform text processing .... When in doubt, use DOMString." still the state of the art? It feels like a recipe for subtle implementation bugs if an implementation round-trips a lone surrogate through UTF-8 instead of WTF-8.



[10:03:02.0975] <Jeffrey Yasskin>
 * Is the advice in https://webidl.spec.whatwg.org/#idl-USVString that "Specifications should only use USVString for APIs that perform text processing .... When in doubt, use DOMString." still the state of the art? In cases where we expect most of the input to be text instead of 16-bit numbers, it feels like a recipe for subtle implementation bugs if an implementation round-trips a lone surrogate through UTF-8 instead of WTF-8.




2023-05-19
[18:19:57.0980] <Domenic>
> <@annevk:matrix.org> https://twitter.com/robpalmer2/status/1658914059578744835 made me think of a similar request I had seen for `AbortSignal` but I can't find it. Something like `AbortSignal.withAborter() -> { signal, aborter }`.

I think AbortController is that object: it has { signal, abort } properties. Promise only wants that because it followed the revealing constructor pattern; AbortSignal is not constructible.

[18:20:58.0002] <Domenic>
> <@jyasskin:matrix.org> Is the advice in https://webidl.spec.whatwg.org/#idl-USVString that "Specifications should only use USVString for APIs that perform text processing .... When in doubt, use DOMString." still the state of the art? In cases where we expect most of the input to be text instead of 16-bit numbers, it feels like a recipe for subtle implementation bugs if an implementation round-trips a lone surrogate through UTF-8 instead of WTF-8.

The advice is state of the art. I don't understand your last point. Strings are 16-bit number collections from the JavaScript engine onward, so you're more likely to get subtle implementation bugs if you ignore that.

[21:19:47.0944] <Jeffrey Yasskin>
> <@domenicdenicola:matrix.org> The advice is state of the art. I don't understand your last point. Strings are 16-bit number collections from the JavaScript engine onward, so you're more likely to get subtle implementation bugs if you ignore that.

I'm happy to live with it given that confirmation, but I'm thinking of the fact that while strings are 16-bit sequences in Javascript, Chrome's Mojo system (https://chromium.googlesource.com/chromium/src/+/master/mojo/public/tools/bindings/README.md#primitive-types) pretty implicitly translates them to UTF-8 on their way to the browser process. 

[21:24:03.0939] <Domenic>
> <@jyasskin:matrix.org> I'm happy to live with it given that confirmation, but I'm thinking of the fact that while strings are 16-bit sequences in Javascript, Chrome's Mojo system (https://chromium.googlesource.com/chromium/src/+/master/mojo/public/tools/bindings/README.md#primitive-types) pretty implicitly translates them to UTF-8 on their way to the browser process.

Oh wow, that's kind of scary...

[21:24:19.0955] <Jeffrey Yasskin>
:-D

[21:24:36.0255] <Domenic>
https://w3ctag.github.io/design-principles/#idl-string-types is a bit related

[21:24:56.0143] <Domenic>
"or operations which can’t handle surrogates in input (such as APIs that pass strings through to native platform APIs), USVString should be used"

[21:25:17.0975] <Domenic>
But I don't think that everything-Mojo is the intent of the "native platform APIs" clause

[21:25:41.0515] <Domenic>
It's more meant, like, displaying in a Window title bar or something

[21:26:24.0234] <Jeffrey Yasskin>
Yeah. And Gecko + WebKit might be more consistent about keeping things in UTF-16, so they would be affected in different circumstances.

[21:26:59.0214] <Jeffrey Yasskin>
I did notice that URL uses USVString, when the guidance would seem to imply DOMString.

[21:27:57.0054] <Domenic>
URL uses USVString because percent encoding 

[21:28:43.0343] <Domenic>
Note also CSS just kinda decided not to do interop because it was more convenient for Gecko to use USVStrings in Stylo. And nothing has blown up yet...

[21:29:12.0121] <Domenic>
(Search for "CSSOMString")

[21:30:04.0554] <Jeffrey Yasskin>
😱

[21:31:01.0380] <Jeffrey Yasskin>
But yeah, I wouldn't expect this to be web-visible in most cases unless someone finds a way to use it maliciously.

[23:38:40.0568] <Domenic>
annevk or Dominic Farolino or anyone: some help appreciated on https://github.com/whatwg/html/issues/9310 , I feel like I'm going crazy

[00:34:08.0171] <annevk>
Domenic: I see the same thing in Gecko, but not WebKit

[00:34:27.0366] <Domenic>
Oh nooooo

[00:34:43.0291] <Domenic>
How is this possibly non-interoperable...

[00:35:34.0728] <annevk>
Probably poorly tested. 

[00:35:38.0660] <Domenic>
Like you do `let w = window.open(); w.document.innerHTML = "<img src='foo.jpg'>"` and this only loads in WebKit? Really!?

[00:36:08.0332] <Domenic>
OK well now that I know it's an interop problem, I'll approach it differently, with test cases and such... on Monday.

[00:39:35.0301] <annevk>
Yeah that works (with `document.body.innerHTML`), though when the popup is blocked it might fail, but that's expected I think

[00:39:58.0339] <annevk>
I wouldn't be terribly sad to see it go

[06:45:30.0802] <annevk>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A...%3Cscript%20type%3D%22text%2Fjavascript%E3%80%80%22%3E%0Aw(1)%0A%3C%2Fscript%3E hmmmmm

[09:59:20.0432] <Ehsan Azari>
Hi all
There's no `reconnectedCallback` exist, but I think it could be used for this condition:
When the element is disconnected from the DOM and then reconnected again

It'd be useful for handling cases where an element is dynamically removed and inserted back into the DOM, for instance, when navigating between different views or performing dynamic updates.

So, I dicided share it with you all, I think it would be useful in some areas, including virtualization techniques

[10:00:37.0156] <Ehsan Azari>
 * Hi all
There's no `reconnectedCallback` exist, but I think it could be used for this condition:
When the element is disconnected from the DOM and then reconnected again

It would be  be useful for handling cases where an element is dynamically removed and inserted back into the DOM, for instance, when navigating between different views or performing dynamic updates.

So, I decided share it with you all, I think it would be useful in some areas, including virtualization techniques

[10:02:37.0722] <Ehsan Azari>
 * Hi all
There's no `reconnectedCallback` exist, but I think it could be used for this condition:
When the element is disconnected from the DOM and then reconnected again

It would be useful for handling cases where an element is dynamically removed and inserted back into the DOM, for instance, when navigating between different views or performing dynamic updates.

So, I decided share it with you all, I think it would be useful in some areas, including virtualization techniques

[10:41:07.0223] <Burt Paulie>
Anyone out there in the WHATWG world have experience working with the backend of HTML and CSS?

[10:49:40.0844] <Dominic Farolino>
HTML has an example showing that you must not resolve a promise in parallel. Does that also imply you cannot resolve a Promise from _another_ Window event loop other than the one it was created in?

[10:53:13.0059] <Andreu Botella>
if the windows don't share an event loop, no

[10:53:39.0377] <Andreu Botella>
you'd have to queue a task in the promise's event loop

[10:54:10.0294] <Andreu Botella>
 * you'd have to queue a task in the promise's window's event loop

[10:55:51.0336] <Burt Paulie>
I'd like to understand in greater detail the process whereby HTML and CSS are implemented between the machine code and the kernel (preferably Linux). Can anyone point me towards the binaries for the HTML Standard? If there's a way for me to return them in a Linux terminal or a Code Editor, I'm all ears. Thanky kindly...

[11:04:44.0661] <Ehsan Azari>
> <@domfarolino:matrix.org> HTML has an example showing that you must not resolve a promise in parallel. Does that also imply you cannot resolve a Promise from _another_ Window event loop other than the one it was created in?

The prohibition against resolving a promise in parallel means that you shouldn't call both the `resolve` and `reject` functions of a Promise at the same time or in rapid succession. That's it

[11:06:34.0362] <Andreu Botella>
In JS you don't have access to a promise's `resolve` and `reject` from a different thread, whereas in the spec text, or when implementing browser code, you do. That's what "parallel" means in the standards.

[11:07:26.0996] <Andreu Botella>
And JS is single-threaded, and so is the implementation of JS in every engine; if you try to resolve a promise off-thread, you're likely to run into concurrency issues

[11:08:04.0062] <Andreu Botella>
 * And JS is single-threaded, and so is the implementation of JS in every engine; if you try to resolve a promise off-thread in browser code, you're likely to run into concurrency issues

[11:09:53.0778] <TabAtkins>
Ehsan Azari: that's very much not correct. "In parallel" is a spec-language term of art, which algorithms can invoke to mean "do this, potentially in another thread; we promise not to do user-observable things here so timing isn't made visible".

[11:10:19.0154] <TabAtkins>
Dominic Farolino: You can, you just have to do it via posting a task to the Promise's own event loop, same as you have to do when you're inside a parallel section.

[11:20:26.0078] <Andreu Botella>
> <@burtboy144:matrix.org> I'd like to understand in greater detail the process whereby HTML and CSS are implemented between the machine code and the kernel (preferably Linux). Can anyone point me towards the binaries for the HTML Standard? If there's a way for me to return them in a Linux terminal or a Code Editor, I'm all ears. Thanky kindly...

Okay, so the HTML, CSS, etc. standards are human-readable (or, well, engineer-readable; there's a difference 😅) descriptions of the behavior that has to happen. They're not compiled to binary (except for small machine-readable things like WebIDL).

[11:20:55.0569] <Andreu Botella>
There are programs called web browsers (like Google Chrome, Firefox, Safari...) that take those text descriptions and turn them into code that then gets compiled

[11:22:58.0954] <Andreu Botella>
Chrome and Firefox are open source, so you can browse the code – although be warned that it's a _lot_ of code. Safari isn't open source, but the part of it that actually does most of the HTML and CSS work (the browser engine) is, it's called Webkit

[11:23:31.0889] <Andreu Botella>
 * There are programs called web browsers (like Google Chrome, Firefox, Safari...) that are made up of code that implements those descriptions

[11:24:25.0815] <Andreu Botella>
> <@burtboy144:matrix.org> I'd like to understand in greater detail the process whereby HTML and CSS are implemented between the machine code and the kernel (preferably Linux). Can anyone point me towards the binaries for the HTML Standard? If there's a way for me to return them in a Linux terminal or a Code Editor, I'm all ears. Thanky kindly...

 * Okay, so the HTML, CSS, etc. standards are human-readable (or, well, engineer-readable; there's a difference 😅) descriptions of the behavior that has to happen. They're not compiled to binary (except for small machine-readable parts like WebIDL).

[11:28:36.0857] <Burt Paulie>
What I'd like to know is how each individual tag is defined for machine processing. I don't want the human (or engineer) readable standard common to most coders, I want to see the binaries processed by the machine for the implementation of each and every tag of the current (or minimally any) HTML Standard. In other words, I'd like to know how to reverse engineer the HTML language...

[11:31:58.0932] <Andreu Botella>
HTML doesn't get compiled into machine code, if that's what you're thinking

[11:32:46.0465] <Burt Paulie>
So how was it written?

[11:33:35.0025] <Andreu Botella>
A browser is written in a compiled language (C++ usually), and it parses HTML, builds an in-memory representation of the structure of a document (which you can then change using javascript), and then uses CSS to apply rules to eventually render it

[11:33:36.0603] <Burt Paulie>
Sir, I know for a fact that you are lying to me...

[11:34:29.0450] <Burt Paulie>
The HTML absolutely must call some binary relative to the display of whatever display elements it defines...

[11:34:41.0226] <Burt Paulie>
It's an absolutely true proposition...

[11:35:03.0076] <Burt Paulie>
I couldn't compile a Post Table without them...

[12:08:34.0340] <Ehsan Azari>
> <@burtboy144:matrix.org> What I'd like to know is how each individual tag is defined for machine processing. I don't want the human (or engineer) readable standard common to most coders, I want to see the binaries processed by the machine for the implementation of each and every tag of the current (or minimally any) HTML Standard. In other words, I'd like to know how to reverse engineer the HTML language...

Do you want this? [It's about languages and grammars
Some are w](https://webidl.spec.whatwg.org/) 

[12:10:23.0272] <Ehsan Azari>
Or you're talking about BNF or things like that?
https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form

[12:19:07.0773] <Burt Paulie>
Both suggestions have relevance to the context, and thanks for references by the way!! I'll give them a once over here and put them in a bookmark file for now... 

[12:22:14.0126] <Burt Paulie>
I will say though, that however tedious it sounds, I would like to know exactly what languages and environments were used to author the HTML language itself, so that if I wanted to reverse engineer the thing, I could do so by buying whatever support I needed and plugging in every last piece of syntax by hand...

[12:23:10.0750] <Burt Paulie>
The Web IDL Standard looks like something worthwhile for me to become (at least cursorily) familiar. Thanks for that...

[12:29:48.0917] <Burt Paulie>
The Backus-Naur thing looks like a generic grammar for defining the implications of human-readable punctuation and meta-language. More of a sound byte from a lazy afternoon than a specification requiring precision. IOW - I could fake it myself...

[12:44:04.0512] <TabAtkins>
If you're interested specifically in how browsers parse CSS, check <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/css/parser/;bpv=1;bpt=0> (for Chrome) or <https://github.com/servo/rust-cssparser/tree/master> (for Firefox).

[12:44:18.0597] <TabAtkins>
HTML parsers are elsewhere in the codebases, I just happened to already have those tabs open.

[12:45:07.0617] <TabAtkins>
Beyond simple parsing, the *behavior* of each HTML element or CSS property/etc is a *much* larger chunk of the code.

[12:46:11.0434] <TabAtkins>
But the specs (generally) describe the same behavior, just in a more readable form. Looking at the code can be interesting if you're wanting to write your own, but it's a huge complicated beast. 

[13:18:01.0156] <Burt Paulie>
I believe you when you tell me that understanding the behavior of parsers is important to how HTML is processed and served. And indeed, knowing how any of our more popular front-end browser engines handle languages like HTML when it is served to computer terminals around the world would be important to creating language standards that interoperate without crashing local machines or blocking regularly. What I am looking for however (which I think you understand to some extent) is not an abstraction. I'd like real word steps. Who can I go to? What can I read about? Which editors or languages should I learn? If I want to author a formal computer language comparable to HTML, how do I begin? For example, is there some company or industrial center (WHATWG or otherwise) where a student can book a tour to learn about this sort of thing? Is there a special editor that shows people the native process whereby an HTML tag can be written, even if it is only within the context of a single, local machine? If I were to attempt to author a language using the assembly specifications for a single type of computer and it's processor, what would it take to gain access to a machine in such a raw state of unprogrammed receptivity? If I built a custom machine, how deeply would I have to strip its operating system to watch myself invent the tags that served typographical elements in more well-manicured contexts?

[13:21:44.0874] <Burt Paulie>
Once again, I'd like to author either an HTML-like language that solves the bidirectional problem, or invent a plug-in module that evolves the versioning process until raw bidirectional functions are standardized and Left-To-Right (LTR) service of hypertext is no longer the rule. It will certainly take several decades, but if I don't start now, that period only grows longer by the minute...

[13:22:47.0256] <Burt Paulie>
 * Once again, I'd like to author either an HTML-like language that solves the bidirectional problem, or invent a plug-in module that evolves the HTML versioning process until raw bidirectional functions are standardized and Left-To-Right (LTR) service of hypertext is no longer the rule. It will certainly take several decades, but if I don't start now, that period only grows longer by the minute...

[13:50:34.0655] <TabAtkins>
You are asking questions at the wrong level of abstraction, as others have said. It sounds like you think HTML is somehow implemented "directly" in code, and browsers just use that? That's not the case.  Browsers load a page, they parse the page's text as HTML, they build a DOM from the parsing results, they display the DOM on the screen according to CSS's rules and react to user input; the entire thing is a complex multi-stage process. The actual "HTML" part is either a very small portion of this (if you're talking about HTML as a language, it's just the parser), or it's woven thruout the entire browser in complex ways (if you're talking about all the behaviors and interactions of how a webpage is displayed).

[13:51:40.0700] <TabAtkins>
But specifically about bidi, HTML already supports rtl and mixed (bidi) text just fine. In some aspects it *defaults* to laying out in a LTR manner, since the web was first created with english/european text and many things depended on that, but generally speaking rtl text and layouts work just fine.

[13:56:52.0286] <TabAtkins>
If you want to know how create a language that looks like HTML, read the HTML parsing spec (<https://html.spec.whatwg.org/multipage/#toc-syntax>). If you want to know how to create *a web browser*, with all that entails, you'll need to read a whole lot more. If you just want to suggest a new feature, search for details about that feature or related things to see if it has already been discussed, and maybe even already solved. If you think there is a missing ability that hasn't already been talked about, read <https://whatwg.org/faq#adding-new-features> for how new features are proposed.

[13:58:34.0282] <Andreu Botella>
If you want to get a feel for what how browsers are put together and what making a browser is like, I suggest https://browser.engineering/


2023-05-20
[01:56:39.0118] <annevk>
Ms2ger: thanks for writing many `<script type language>` tests at some point; small contribution: https://github.com/web-platform-tests/wpt/pull/40112

[02:36:15.0799] <Burt Paulie>
TabAtkins: I thank you for answering within the scope of your immediate understanding. I am certain your knowledge outstrips mine regarding the processes underlying the implementation of HTML in every' context. However, neither of your suggestions (stated in the links you posted) meet my needs...

[03:00:43.0243] <Burt Paulie>
To keep this simple (because I am leaving this forum out of my scope), if I told you that I'd like to see the binaries for the service of a Unicode character, I feel like I'd be told (once again) that I'm at the "wrong level of abstraction" or that perhaps I "should read this specification (to be found languishing within the world of Zelda's liberator no less)". I might be mistaken in this...

[03:05:00.0565] <Burt Paulie>
I am finding, however, that the overall impression I receive is that it is you refuse to confess to your own industries failure to meet a global standard of human nature in favor of the traditional practices of a single language family...

[03:08:41.0063] <Burt Paulie>
I can tell you, I have not yet looked into documentation for returning binary data for the storage of a Unicode character. I'm busy, like most people, and certainly not "brimming with knowledge" as are many administrators like yourself who choose to spend time answering student questions and posting links relevant to the documentation they help maintain...

[03:13:11.0284] <Burt Paulie>
But like anyone of adequate intelligence, I know it exists. I know whatever thread(s) define it can be specified, compiled, and analyzed until the exact sequences responsible for the appearance of the character on the screen are itemizable as a matter of a Post Table within the discipline of Algebraic Logic... 

[03:13:46.0676] <Burt Paulie>
 * But like anyone of adequate intelligence, I know it exists. I know whatever thread(s) define it can be specified, compiled, and analyzed until the exact sequences responsible for the appearance of the character on the screen are itemizable as a matter of Post Tables within the discipline of Algebraic Logic... 

[03:14:23.0710] <canadahonk>
there is no standard (binary) representation for (parsed) HTML, every engine is different. to be clear, HTML is not compiled into binary and ran, it is just parsed and that parsed interpretation is used within browser engines for their own needs.

[03:18:13.0072] <Burt Paulie>
So if I come to your forum and inquire of the standards you maintain only to be told there is no manner, no way, no process to return the valid binaries that are explicitly responsible for the service and display of HTML, CSS, Unicode, or any other screen element, I'd care to say that you are full of shit...

[03:19:24.0299] <Burt Paulie>
One f!@#ing Unicode character sure as hell has a binary, just like any other "tag". You're it!!...

[03:21:47.0835] <Burt Paulie>
According to me, the only "job" you people are doing here is posting hate mail. HaTeMaiL and CuSSes...

[04:16:34.0377] <annevk>
Oh, I was about to give them a final wording with a pointer to https://whatwg.org/code-of-conduct but this works too I guess.

[04:16:42.0957] <annevk>
 * Oh, I was about to give them a final warning with a pointer to https://whatwg.org/code-of-conduct but this works too I guess.

[10:26:39.0471] <Ehsan Azari>
I come from another industries, so we have standards, and based on those standards we normally generate OWL, RDF, and recently JSON-RD and UML shemas
So, if I want to have html tags and their related attributes in JSON or JSON-LD, is there any ready to use shema?

[10:26:56.0054] <Ehsan Azari>
 * I come from another industries, so we have standards, and based on those standards we normally generate OWL, RDF, and recently JSON-LD and UML shemas
So, if I want to have html tags and their related attributes in JSON or JSON-LD, is there any ready to use shema?

[10:27:12.0250] <Ehsan Azari>
 * I come from another industries, so we have standards, and based on those standards we normally generate OWL, RDF, and recently JSON-LD and UML schemas
So, if I want to have html tags and their related attributes in JSON or JSON-LD, is there any ready to use shema?

[10:28:47.0852] <Ehsan Azari>
 * I come from another industries, so we have standards, and based on those standards we normally generate OWL, RDF, and recently JSON-LD and UML schemas
So, if I want to have HTML elements tags and their related attributes in JSON or JSON-LD, is there any ready to use shema?

[10:29:12.0674] <Ehsan Azari>
 * I come from another industries, so we have standards, and based on those standards we normally generate OWL, RDF, and recently JSON-LD and UML schemas
So, if I want to have HTML elements tags and their related attributes in JSON or JSON-LD, is there any ready to use schema?

[10:33:28.0424] <Ehsan Azari>
 * I come from another industries, so we have standards, and based on those standards we normally generate OWL, RDF, and recently JSON-LD and UML schemas
So, if I want to have HTML elements tags and their related attributes in JSON or JSON-LD, is there any ready to use schema?
Should have a look at schema.org or somewhare?

[14:31:40.0918] <MO _ Satar>
good evening guys

[14:32:46.0922] <MO _ Satar>
😄


2023-05-22
[08:10:27.0706] <annevk>
emilio: https://github.com/whatwg/html/pull/9198 (or maybe ping cathiechen if you have a way)

[08:58:33.0270] <Ben Kallus>
What is the status of the URL reference implementation? Why was it deleted? Are there any plans to revive a reference implementation in the future?

[08:59:25.0585] <annevk>
Ben Kallus: some implementations are referenced from https://github.com/whatwg/url#tests-and-implementations


2023-05-23
[05:11:50.0106] <Ehsan Azari>
> <@ehsan.azari:matrix.org> I come from another industries, so we have standards, and based on those standards we normally generate OWL, RDF, and recently JSON-LD and UML schemas
> So, if I want to have HTML elements tags and their related attributes in JSON or JSON-LD, is there any ready to use schema?
> Should have a look at schema.org or somewhare?

I asked a wrong question? nobody answered
We have types for instance in TS/JS, but I want them as JSON schema

[05:42:52.0091] <annevk>
Ehsan Azari: I guess the TL;DR is that historically we have cared very little about schema languages; there's probably quite a bit of context in the mailing list archives


2023-05-24
[00:27:58.0201] <Kaiido>
Relatively interesting question about <link> processing (which stays a bit unclear to me): https://stackoverflow.com/questions/76319964/what-is-the-behavior-of-a-link-with-both-preload-and-stylesheet-in-rel-attribute Maybe @noamr could shed some light on this?

[00:28:13.0651] <Kaiido>


Also I noticed that https://html.spec.whatwg.org/multipage/links.html#link-type-preload has a link to [[PRELOAD]](https://html.spec.whatwg.org/multipage/references.html#refsPRELOAD) which actually redirects back to https://html.spec.whatwg.org/multipage/links.html#link-type-preload since W3C Preload has been merged to HTML. I find it kind of funny to have such a *recursive link* inside the *link.html* page, but maybe we want to do something about it? There is still value in this link since it does give credits to I. Grigorik for their work. Is it worth an issue?

[00:33:44.0094] <Kaiido>
 * Relatively interesting question about \<link> processing (which stays a bit unclear to me): https://stackoverflow.com/questions/76319964/what-is-the-behavior-of-a-link-with-both-preload-and-stylesheet-in-rel-attribute Maybe Noam Rosenthal could shed some light on this?

[00:35:23.0360] <Noam Rosenthal>
> <@kaiido:matrix.org> Relatively interesting question about \<link> processing (which stays a bit unclear to me): https://stackoverflow.com/questions/76319964/what-is-the-behavior-of-a-link-with-both-preload-and-stylesheet-in-rel-attribute Maybe Noam Rosenthal could shed some light on this?

Yes please open an isssue, should be an easy fix 

[00:38:43.0325] <Noam Rosenthal>
> <@kaiido:matrix.org> Relatively interesting question about \<link> processing (which stays a bit unclear to me): https://stackoverflow.com/questions/76319964/what-is-the-behavior-of-a-link-with-both-preload-and-stylesheet-in-rel-attribute Maybe Noam Rosenthal could shed some light on this?

Iirc you can have several rels and it would behave similarly to having two link elements with those rels the other attributes identical. In Rhys and other cases this will not create a very useful outcome 

[00:39:02.0093] <Noam Rosenthal>
S/Rhys/this

[00:40:23.0263] <annevk>
We should remove [PRELOAD] and add I. Grigorik to the acknowledgments if they aren't already there

[00:40:30.0657] <annevk>
I suspect they are there

[00:43:12.0221] <Kaiido>
Noam Rosenthal: thanks, that confirms my own thoughts then.
annevk so a PR directly would be preferable? I probably won't have the time myself to do so today so it might be better for someone else to lead this.

[00:44:43.0300] <Noam Rosenthal>
> <@kaiido:matrix.org> Noam Rosenthal: thanks, that confirms my own thoughts then.
> annevk so a PR directly would be preferable? I probably won't have the time myself to do so today so it might be better for someone else to lead this.

Feel free to do either 

[00:45:40.0587] <Kaiido>
I opened https://github.com/whatwg/html/issues/9327

[03:12:34.0454] <Noam Rosenthal>
> <@kaiido:matrix.org> I opened https://github.com/whatwg/html/issues/9327

PR: https://github.com/whatwg/html/pull/9329

[05:34:24.0561] <freddy>
Why does the policy container (https://html.spec.whatwg.org/#policy-containers) contain the CSP, referrer policy and embedder policy but not the sandbox flags?

[05:46:13.0843] <annevk>
freddy: it's very much an incremental effort, if you think things should be added, go for it

[05:55:53.0031] <freddy>
heh, I now realize there is a big red box that even says it 🫢

[06:02:04.0210] <Ms2ger>
Nothing as easy to miss as a big red box 😅

[07:40:49.0178] <Dominic Farolino>
Another promise and "parallel" question. I believe you cannot "react" to a Promise from in parallel, right? I.e., call "Upon fulfillment" on a promise from steps running in parallel.

[07:42:21.0808] <Ms2ger>
That's correct

[07:48:09.0589] <annevk>
Dominic Farolino: you gotta think bigger, you cannot manipulate JS objects in parallel to some event loop, period

[09:42:12.0601] <TabAtkins>
Nothing with observable effects can be done in parallel. (Except posting a task itself, which I suppose produces observable timing differences?)

[10:27:24.0384] <annevk>
TabAtkins: yeah, though you still get some guarantees if things go into the same task source

[10:28:16.0784] <annevk>
And yeah, exactly, you want to do state updates from steps in a task.

[10:44:40.0969] <Dominic Farolino>
Yep I just wanted to sanity check


2023-05-25
[07:39:30.0465] <annevk>
zcorpan: so weird how `naturalHeight` returns the density-corrected natural height, that's just confusing af

[08:59:44.0414] <awesomekling>
Noam Rosenthal: heyo! I'm integrating https://github.com/whatwg/fetch/pull/1645 in our fetch implementation, could you help me understand why we don't use the internal response for processResponse, and only for processResponseConsumeBody?

[09:00:39.0959] <zcorpan>
annevk: https://github.com/ResponsiveImagesCG/picture-element/issues/247 - but the irc log is no longer available and wasn't indexed in waybackmachine

[09:09:40.0921] <annevk>
awesomekling: we only use it to collect the response body, right? I think if we only passed the internal response the caller wouldn't have access to the opaque response, which could be bad as they wouldn't have sufficient information to make the correct security decision

[09:10:12.0901] <annevk>
awesomekling: e.g., whether it's CORS-same-origin

[09:11:50.0245] <Noam Rosenthal>
awesomekling: that's a good question, more for annevk. The way I see it internal response is a mechanism to make sure that invokers of no-cors fetch know that they're dealing with hot unsafe stuff. But I'm not sure it's a good mechanism for that, as the invoker probably wants the data anyway and most HTML callers hide this using "unsafe response". We relaxed it for `processResponseConsumeBody` because it's the less "advanced" callback but I'm not sure if we should keep it for the other callbacks.

[09:12:19.0281] <awesomekling>
annevk: hmm, all right. I'm trying to work out if https://github.com/whatwg/html/issues/9066 is "solvable" now, or if there are more bits needed

[09:33:07.0358] <annevk>
awesomekling: Noam Rosenthal: looking at the spec again I think we did it wrong; "internalResponse and nullOrBytes" should have been "response and nullOrBytes"

[09:33:21.0986] <annevk>
Same for the one below.

[09:34:08.0442] <annevk>
We have to use the internal response after all to actually get all the bytes, but we don't have to use the internal response for the first argument and it's safer not to.

[09:34:15.0528] <annevk>
I'll put up a PR.

[09:44:48.0272] <annevk>
awesomekling: Noam Rosenthal: https://github.com/whatwg/fetch/pull/1661


2023-05-26
[17:27:38.0788] <sideshowbarker>
If anybody sees anything conspicuously missing from https://html-now.github.io/, let me know or raise an issue at https://github.com/html-now/html-now.github.io/issues — or even a PR against the https://github.com/html-now/html-now.github.io/blob/main/specdata.json source, which is what it’s all generated from

[00:53:52.0959] <evilpie>
Is there some criteria for inclusion? I think it's missing https://w3c.github.io/clipboard-apis/

[02:40:31.0652] <sideshowbarker>
That’s one of the specs that’s excluded by default  due to only being implemented in a single engine

[02:41:56.0642] <sideshowbarker>
There are nearly 100 of those that aren’t displayed by default — to have those show up, you need to press the _“Include single-engine specifications”_ button

[02:57:05.0609] <evilpie>
That's not really true though. Unless you mean completely. (Actually I think Safari's implementation is fairly complete now)

[03:26:52.0554] <annevk>
https://w3c.github.io/PNG-spec/#11pHYs ReSpec is so infuriating

[03:28:40.0364] <Domenic>
Wow yeah clicking on that link was quite a journey

[04:03:11.0493] <Ms2ger>
TIL there's a recent PNG spec

[04:12:24.0301] <annevk>
Yeah, I guess I can't complain too much since that is actually very good; finally fixing APNG and such

[05:38:17.0642] <zcorpan>
Where is the "Engines" data coming from? For clipboard apis it looks like it doesn't match either caniuse or bcd

[07:34:35.0828] <annevk>
zcorpan: thanks for the <source media> PR! I've pinged Jer to see if he can review

[13:16:13.0986] <TabAtkins>
You can definitely complain that they're deploying the raw version rather than the built version.

[13:18:38.0421] <TabAtkins>
(at least they're still enforcing the "/TR doesn't allow raw ReSpec" rule)

[13:25:24.0176] <sideshowbarker>
The Engines data was manually copied over from BCD. But it's been a while, so it can be out of date in some cases.

[13:26:08.0567] <sideshowbarker>
PRs welcome in any cases where it's not currently up to date with what's in BCD

[16:44:41.0348] <Dominic Farolino>
Serious question: why do people use ReSpec? Is it just a preference, or are there good technical tradeoffs it makes for some cases, compared to bikeshed?


2023-05-27
[21:04:50.0500] <Domenic>
It existed before Bikeshed IIRC, so I think a good portion of it is inertia via copy-paste or people within a working group encouraging you to do the same as the rest of the working group's specs. But, I suspect it would have died out, except for Marcos Caceres's evangelism and maintenance (e.g. converting specs to ReSpec).

[12:12:02.0161] <Martell Cone>
So what happens now Agent Smith?

[12:12:58.0535] <Martell Cone>
Yall are literally bout to feel it. No vaseline. Big Celly Dicks. Lol

[12:14:15.0456] <Martell Cone>
We can be civil or very disrespectful. Lets talk like mature adults. For real. 


2023-05-29
[02:15:33.0945] <sideshowbarker>
zcorpan:  About the validator-nu/Mozilla HTML parser: It seems like either we must not have any good tests for reporting of invalid character references in html5lib-tests, or else we do but we’re just not running them in CI anywhere for the validator-nu/Mozilla HTML parser code. Otherwise I would have caught https://github.com/validator/htmlparser/issues/82 long ago.

A few years back, I did try to set up the htmlparser repo CI to run the html5lib-tests suite, but it was failing due to known issues with it not conforming to encoding handling. So in https://github.com/validator/htmlparser/pull/48 I had spent a bunch of time trying to patch it before I ended up realizing that Henri had long before that already started a branch to fix it properly (but subsequently ended up abandoning it).

But I guess what I should do at this point is to try to set up CI for it again — but have it ignore all the failing encoding tests from the html5lib-tests suite.

[02:24:00.0693] <sideshowbarker>
Maybe that’s what the Mozilla CI is actually already doing, I dunno. But if it is, then I think that CI must also not be running the error-reporting tests for invalid character references. Otherwise it would have caught the https://github.com/validator/htmlparser/issues/82 regression.

[02:26:52.0342] <sideshowbarker>
zcorpan: And the context for me mentioning this now is https://github.com/validator/htmlparser/issues/82 — which I fixed today in ttps://github.com/validator/htmlparser/pull/83.

But that needs review before merging into the main branch, and I guess it might be a while before Henri is able to review it. And I don’t know who else from Mozilla is currently able to review HTML parser patches

But anyway, after looking at the issue and the code and testing it, I realized it’s a pretty serious regression in the expected error-reporting behavior for invalid named character references.  I think it’s probably causing no error to be reported for most “normal” cases of invalid character references (not just the pathological cases like the `&ThisAmpersandShouldBeDeemedAmbiguous;` case reported in that issue) — and it’s been that way for nearly 2 years now, since https://github.com/validator/htmlparser/commit/44427c0df60ec899c52b149bba03e1abffad2f5e.

All that said, I guess this doesn’t affect Firefox behavior at all beyond the error flagging that’s shown in View Source. And for the HTML checker for now, I’m going ahead and temporarily switching back to having the HTML checker build use a feature branch rather than then main branch (until the fix can be merged). So it’s not really urgent.

But as I mentioned above, it has made me realize that we really should consider having CI set up somewhere to properly run all the right html5lib-tests — before any further changes get committed to the sources.

[02:27:08.0593] <sideshowbarker>
 * zcorpan:  And the context for me mentioning this now is https://github.com/validator/htmlparser/issues/82 — which I fixed today in ttps://github.com/validator/htmlparser/pull/83.

But that needs review before merging into the main branch, and I guess it might be a while before Henri is able to review it. And I don’t know who else from Mozilla is currently able to review HTML parser patches

But anyway, after looking at the issue and the code and testing it, I realized it’s a pretty serious regression in the expected error-reporting behavior for invalid named character references.  I think it’s probably causing no error to be reported for most “normal” cases of invalid character references (not just the pathological cases like the `&ThisAmpersandShouldBeDeemedAmbiguous;` case reported in that issue) — and it’s been that way for nearly 2 years now, since https://github.com/validator/htmlparser/commit/44427c0df60ec899c52b149bba03e1abffad2f5e.

All that said, I guess this doesn’t affect Firefox behavior at all beyond the error flagging that’s shown in View Source. And for the HTML checker for now, I’m going ahead and temporarily switching back to having the HTML checker build use a feature branch rather than then main branch (until the fix can be merged). So it’s not really urgent.

But as I mentioned above, it has made me realize that we really should consider having CI set up somewhere to properly run all the right html5lib-tests — before any further changes get committed to the sources.

[02:27:32.0919] <sideshowbarker>
 * zcorpan:  And the context for me mentioning this now is https://github.com/validator/htmlparser/issues/82 — which I fixed today in https://github.com/validator/htmlparser/pull/83.

But that needs review before merging into the main branch, and I guess it might be a while before Henri is able to review it. And I don’t know who else from Mozilla is currently able to review HTML parser patches

But anyway, after looking at the issue and the code and testing it, I realized it’s a pretty serious regression in the expected error-reporting behavior for invalid named character references.  I think it’s probably causing no error to be reported for most “normal” cases of invalid character references (not just the pathological cases like the `&ThisAmpersandShouldBeDeemedAmbiguous;` case reported in that issue) — and it’s been that way for nearly 2 years now, since https://github.com/validator/htmlparser/commit/44427c0df60ec899c52b149bba03e1abffad2f5e.

All that said, I guess this doesn’t affect Firefox behavior at all beyond the error flagging that’s shown in View Source. And for the HTML checker for now, I’m going ahead and temporarily switching back to having the HTML checker build use a feature branch rather than then main branch (until the fix can be merged). So it’s not really urgent.

But as I mentioned above, it has made me realize that we really should consider having CI set up somewhere to properly run all the right html5lib-tests — before any further changes get committed to the sources.

[02:28:26.0526] <sideshowbarker>
 * zcorpan:  And the context for me mentioning this now is https://github.com/validator/htmlparser/issues/82 — which I fixed today in https://github.com/validator/htmlparser/pull/83.

But that needs review before merging into the main branch, and I guess it might be a while before Henri is able to review it. And I don’t know who else from Mozilla is currently able to review HTML parser patches

But anyway, after looking at the issue and the code and testing it, I realized it’s a pretty serious regression in the expected error-reporting behavior for invalid named character references.  I think it’s probably causing no error to be reported for most “normal” cases of invalid character references (not just the pathological cases like the `&ThisAmpersandShouldBeDeemedAmbiguous;` case reported in that issue) — and it’s been that way for nearly 2 years now, since https://github.com/validator/htmlparser/commit/44427c0df60ec899c52b149bba03e1abffad2f5e.

All that said, I guess this doesn’t affect Firefox behavior at all beyond the error flagging that’s shown in View Source. And for the HTML checker for now, I’m going ahead and temporarily switching back to having the HTML checker build use a feature branch rather than the main branch (until the fix can be merged). So it’s not really urgent.

But as I mentioned above, it has made me realize that we really should consider having CI set up somewhere to properly run all the right html5lib-tests — before any further changes get committed to the sources.

[06:12:37.0139] <zcorpan>
sideshowbarker: thanks for the heads up. Seems like it can wait for Henri, but ideally we ought to have another reviewer :)

[06:49:49.0730] <zcorpan>
annevk or Domenic : https://github.com/whatwg/html/pull/8008 seems ready. Do either of you want to do an editorial pass? Thx


2023-05-30
[21:57:15.0404] <Domenic>
Will do!

[02:13:52.0146] <Noam Rosenthal>
Do we have current observability as to coming "from history navigation", e.g. "you came from a back navigation"? (even if just same-origin)
Seems like we don't but wanted to make sure

[02:15:59.0031] <Noam Rosenthal>
oh yes we have the navigation type in `performance.navigation`

[02:47:22.0808] <Domenic>
> <@domenicdenicola:matrix.org> Will do!

Will do... tomorrow. I have a cold and was planning to mostly do reviews, but ended up doing other things instead :(

[03:04:11.0967] <annevk>
sideshowbarker: whatwg.org build script gets a 404 for the validator: https://github.com/whatwg/whatwg.org/actions/runs/5100163889/jobs/9206311801#step:9:42

[03:10:47.0870] <sideshowbarker>
> <@annevk:matrix.org> sideshowbarker: whatwg.org build script gets a 404 for the validator: https://github.com/whatwg/whatwg.org/actions/runs/5100163889/jobs/9206311801#step:9:42

Thanks, I'll take a look

[04:42:19.0758] <sideshowbarker>
> <@annevk:matrix.org> sideshowbarker: whatwg.org build script gets a 404 for the validator: https://github.com/whatwg/whatwg.org/actions/runs/5100163889/jobs/9206311801#step:9:42

Fixed (and commented in that issue at https://github.com/whatwg/whatwg.org/pull/420#discussion_r1210148196)

[05:02:02.0266] <annevk>
TabAtkins: latest Bikeshed commit around Dark Mode made a lot of bots go red: https://github.com/speced/bikeshed/issues/2561

[06:01:25.0844] <annevk>
Splitting out SharedArrayBuffer from ArrayBuffer is not as quick of a PR as I thought it was

[08:37:22.0118] <canadahonk>
hey all, was implementing url spec change https://github.com/whatwg/url/pull/771 in Gecko and was brought up that it seems odd the issue went from inner blob -> non-http(s). it could be useful to have an origin for extension and file URIs and unsure why the issue expanded in scope like that since it seemed to be only originally for inner blobs for OOM concerns. thanks! (cc annevk from issue)

[08:48:39.0313] <annevk>
Review appreciated: https://github.com/whatwg/webidl/pull/1311

[08:49:38.0021] <annevk>
canadahonk: file: URL concern seems fair, but most other schemes are already required to be a opaque, see https://url.spec.whatwg.org/#origin

[08:49:55.0492] <annevk>
canadahonk: I don't think there's a valid use case for ws/wss/ftp

[08:50:07.0998] <canadahonk>
I agree with those yeah

[08:52:17.0160] <canadahonk>
should file be added to of nots then?

[08:52:55.0725] <canadahonk>
 * should file be added to the nots then?

[08:53:59.0327] <annevk>
nots? Anyway, adding file: seems okay to me.

[08:55:21.0205] <canadahonk>
meant adding to the list of
> is not "http" and not "https"

[08:55:30.0709] <canadahonk>
I can do a PR if that sounds good :)

[09:04:36.0260] <annevk>
canadahonk: go for it! Might wanna check you can sign https://participate.whatwg.org/agreement if you haven't already

[09:13:51.0012] <canadahonk>
thanks!

[10:58:31.0539] <TabAtkins>
annevk: Argh, sorry about that. I really need to figure out a way to version the datafiles. I'll be pushing a new pip release in a few minutes to make that work.

[11:07:00.0415] <TabAtkins>
annevk: Okay, Bikeshed 3.12.0 released which understands the Dark Mode metadata. Sorry for the hiccup.

[15:28:36.0468] <Jeffrey Yasskin>
FYI, I asked the TR-design folks to add styles for `domintro`, at https://github.com/w3c/tr-design/issues/324. I've tried to answer fantasai's question about how it's used, but I might be wrong, and folks here would know better.


2023-05-31
[20:07:42.0546] <Domenic>
Seems like it's been twisted into something not like the original, so we'll need to keep copying the domintro styles around

[20:10:36.0727] <Domenic>
 * Seems like it's being changed into something not like the original, so we'll need to keep copying the domintro styles around

[00:41:45.0927] <annevk>
Domenic: thanks for the SAB review. I'll try to understand that type nuance a bit better. Are you are the existing typedefs work though? It seems they would not allow for resizable or shared buffers in a number of places, for instance.

[00:43:05.0056] <Domenic>
annevk: yeah the existing typedefs might not work well. It's more that using "an `X` object" or "an `X`" where `X` is an IDL typedef is known-good phrasing.

[00:45:52.0685] <annevk>
canadahonk: you prodding me about other schemes made me realize what I might have been missing in my WebKit patch; maybe I'll finally manage to get all the tests to pass now 🤞

[00:46:29.0271] <Domenic>
I was honestly a bit surprised that we were rigorous about using "string types" and "numeric types" and so on, to only refer to the types and not to instances. But since we are, I figured we should probably stick to it

[00:47:45.0923] <annevk>
Yeah, maybe we shouldn't export them then though. I guess that's another thing to look at, if there are any callers.

[00:48:08.0476] <Domenic>
Hmm yeah, good point

[01:39:58.0411] <sideshowbarker>
zcorpan: FYI It seems my recent parser change regressed the handling of ampersands in URLs https://github.com/validator/validator/issues/1595. I guess I shouldn’t be surprised.

So I’ll need to revert the change — and then I suppose I rightly should go back to the parser code and try to re-figure-out how to get the parser error-reporting conforming for all cases. Which is not a lot of fun without proper test cases with the right coverage, and a working test harness for checking the error-reporting behavior

[01:40:30.0262] <sideshowbarker>
 * zcorpan: FYI It seems my recent parser change regressed the handling of ampersands in URLs https://github.com/validator/validator/issues/1595. I guess I shouldn’t be surprised.

So I’ll need to revert the change — and then I suppose I rightly should go back to the parser code and try to re-figure-out how to get the parser error-reporting behavior conforming for all cases. Which is not a lot of fun without proper test cases with the right coverage, and a working test harness for checking the error-reporting behavior

[01:42:26.0928] <zcorpan>
sideshowbarker: ouch. I wonder if we should revisit the decision to allow "&" at all tho

[01:42:46.0047] <zcorpan>
The current rules are basically impossible to explain

[01:44:20.0087] <sideshowbarker>
Yeah, I don’t even remember now at a high level now how the logic in the spec change distinguished between the usage in, e.g., a URL vs. the usage that we wanted to continue to disallow

[01:45:05.0910] <sideshowbarker>
As far as revisiting the decision, I do still think the use case for allowing it in URLs is valid and we should still allow that

[01:45:22.0062] <sideshowbarker>
 * Yeah, I don’t even remember now at a high level how the logic in the spec change distinguished between the usage in, e.g., a URL vs. the usage that we wanted to continue to disallow

[01:46:42.0537] <zcorpan>
IIRC Ian Hickson allowed ampersands based on feedback within google that there was no harm from using unescaped `&` in e.g. urls. But it only "works" for urls in attributes, so it's still brittle. Also the same argument would allow `font` or omitting `</div>`s

[01:47:49.0936] <sideshowbarker>
yeah I guess the possible long-term costs of some of these decisions were hard to foresee at the time

[01:54:01.0216] <sideshowbarker>
And incidentally other characteristic of this part of the parser code that makes this really “fun” is that the fact that the state machine in the parser code doesn’t really map very clearly to the state machine in the spec algorithm. Of course the resulting _behavior_ parser state machine is intended to be workalike conforming to the spec algorithm — but, in practice, working with that parser code, needing to mentally re-construct the code-to-spec mapping there every time I need to touch that code is not something I look forward to.

[01:54:16.0643] <sideshowbarker>
 * And incidentally other characteristic of this part of the parser code that makes this really “fun” is that the fact that the state machine in the parser code doesn’t really map very clearly to the state machine in the spec algorithm. Of course the resulting _behavior_ of the parser state machine is intended to be workalike conforming to the spec algorithm — but, in practice, working with that parser code, needing to mentally re-construct the code-to-spec mapping there every time I need to touch that code is not something I look forward to.

[01:55:07.0364] <sideshowbarker>
Anyway, I really wish we had someone else with time and interest in working on the parser maintenance

[01:55:07.0637] <zcorpan>
sideshowbarker: just rewrite the spec

[01:55:36.0630] <sideshowbarker>
snort

[01:56:07.0085] <sideshowbarker>
That would definitely help to make the spec algorithm even less maintainable too

[01:56:39.0833] <sideshowbarker>
Maybe that’s what we want in the end — we want everybody to be afraid to touch that part of the spec ever again

[01:57:34.0587] <zcorpan>
hehe

[01:58:26.0475] <zcorpan>
But do you want to file a spec issue about disallowing &?

[02:03:17.0393] <Noam Rosenthal>
smaug: hi! trying the understand the concern around https://github.com/whatwg/html/issues/9315. I don't see how it interferes with BFCache snapshots but perhaps I'm missing something

[02:04:12.0850] <smaug>
concern is to postpone when the first paint could happen

[02:04:49.0566] <smaug>
If handling the new event takes lots of time, what would UA  paint instead?

[02:05:08.0137] <Noam Rosenthal>
smaug: if there are no view transitions, it can still paint the snapshot

[02:05:24.0042] <smaug>
what if there are transitions?

[02:05:32.0568] <Noam Rosenthal>
view-transitions are same origin, have a timeout, and in this case it would be the feature :)

[02:06:08.0240] <Noam Rosenthal>
if there is a same-origin view transition, it would show the old document until you're done with that event etc

[02:06:56.0753] <smaug>
view-transitions are same origin right now, in Google's proposal, but will they always be?

[02:07:42.0838] <Noam Rosenthal>
smaug: *might* make them same-site at some point, in which case we'll need to make sure the opt-ins hold water

[02:08:21.0464] <Noam Rosenthal>
but in any case view-transitions reveal a lot about the old document to the new one

[02:08:51.0347] <Noam Rosenthal>
which we'll have to deal with if we ever go to same-site

[02:09:04.0376] <Noam Rosenthal>
(cross-site is a non-goal)

[02:12:14.0696] <Noam Rosenthal>
smaug: we're careful not to make choices that would bind us to staying constrained to same-origin. For example we don't expose anything to the old document.
But I don't see how this event is one of those features - by the time you get it both documents have opted in

[02:13:18.0126] <smaug>
If the behavior would be very different when ViewTransitions are around, should the event be dispatched only in that case

[02:13:26.0124] <smaug>
otherwise it would be rather error prone

[02:13:52.0803] <Noam Rosenthal>
that was the original behavior, but in the case of newly-initialized document it's useful also without view transitions

[02:13:57.0325] <smaug>
without VT one would have a paint before first rAF when coming out of bfcache

[02:13:58.0815] <Noam Rosenthal>
I mean the original proposal

[02:14:29.0829] <smaug>
 * without VT one would have a paint (painting using the cache) before first rAF when coming out of bfcache

[02:14:50.0076] <Noam Rosenthal>
"without VT one would have a paint (painting using the cache) before first rAF when coming out of bfcache" - is that specified anywhere?

[02:15:34.0520] <smaug>
no, but I wouldn't want to let web page to postpone painting when coming out of bfcache

[02:15:42.0955] <smaug>
that would make bfcache feel slower

[02:16:32.0342] <Noam Rosenthal>
yea but it's not a web-exposed feature. it's like showing a splash screen of the previous contents in a way

[02:17:09.0689] <Noam Rosenthal>
like in a page that has a clock you'll show some previous time

[02:17:49.0551] <smaug>
yes, and you want to remove that

[02:17:52.0763] <smaug>
for VT at least

[02:18:03.0183] <Noam Rosenthal>
right, but that's unrelated to the event

[02:18:14.0687] <smaug>
I'm confused

[02:19:20.0625] <smaug>
You want a new event which fires before first paint after activation. How is the event not related to the first paint?

[02:19:29.0255] <Noam Rosenthal>
think of it as:
- if (!has-transition) { showStaleSnapshot() } else { showOldDocument() } 
- fire reveal event
- fire pageshow

[02:20:23.0491] <Noam Rosenthal>
the main "novelty" of this event is how it behaves on initial load. As far as reactivating is concerned, it's the same as pageshow

[02:20:36.0205] <smaug>
I guess pageshow is confusing here, since this is also about page  load, and pageshow may fire way after the initial paint

[02:20:37.0877] <Noam Rosenthal>
I don't see showing the stale snapshot as a "paint"

[02:20:57.0002] <Noam Rosenthal>
it's not a paint in web-standards term

[02:21:10.0260] <smaug>
it is from the user's point of view.

[02:21:50.0465] <Noam Rosenthal>
hmm we can call it the first rendering update

[02:22:06.0419] <Noam Rosenthal>
the first non-stale paint

[02:24:07.0682] <smaug>
So for VT case how is reveal event different to having a rAF callback?

[02:25:19.0031] <Noam Rosenthal>
it's not too different from putting a rAF callback in the head + pageshow, but it fires before "update the rendering" phase

[02:25:41.0597] <smaug>
and why is that important?

[02:25:44.0250] <Noam Rosenthal>
it's more equivalent to putting onload on all your render-blocking scripts and styles + pageshow

[02:25:49.0781] <smaug>
er, why pageshow

[02:26:30.0308] <Noam Rosenthal>
this is "your page's rendering is about to be displayed for the first time"

[02:26:35.0798] <smaug>
yes

[02:26:44.0557] <smaug>
so you add a rAF callback

[02:28:46.0830] <smaug>
Why you need a new event to fire just before first "update the rendering", and not use the existing mechanism to get callbacks called during "update the rendering"?

[02:29:18.0833] <Noam Rosenthal>
but then you need to add that rAF callback also on page show

[02:29:52.0785] <Noam Rosenthal>
it's easy to miss that. you build your webpage in a way that works on first load, and then it breaks on BFCache restore

[02:29:56.0673] <smaug>
And how is adding a raf callback different to adding an event listener?

[02:30:09.0715] <Noam Rosenthal>
it's about doing it once vs doing it twice

[02:31:08.0003] <Noam Rosenthal>
in the VT case, it allows us to put a VT object reference in the event object. so this would be the only time where you can, for example, skip an incoming VT or listen to when it's finished.

[02:33:37.0163] <Noam Rosenthal>
I mean, we could have a VT-specific event for this and use the first rAF for other cases, but we thought it might be a useful event regardless of VT. Yoav Weiss you said something about having another use case for this?

[02:33:43.0749] <smaug>
VT object reference in the event, that is not something proposed in the issue

[02:34:41.0228] <Noam Rosenthal>
Yea when I proposed it I was thinking of having a `document.pendingTransition` instead. I will update the proposal

[02:37:29.0582] <Noam Rosenthal>
smaug: the cross-document view transition spec is in the making, and we noticed that this lifecycle event is somewhat missing (you have to register it twice, as first rAF+pageshow) so we wanted to discuss it as a general benefit rather than just in the context of VT. Trying to avoid having an event-per-CSS-feature, but if that's what we end up with it's also OK

[02:38:48.0130] <smaug>
Well, better to understand the context here, and I wasn't aware that something might be added to the event itself

[02:39:19.0787] <smaug>
Since that might make the event more useful

[02:39:57.0169] <smaug>
right now it feels more like minor helper event for things which can be done easily without making the platform even more complicated

[02:41:01.0258] <Noam Rosenthal>
smaug: good point

[02:44:50.0632] <Noam Rosenthal>
... updated the OP

[04:18:58.0468] <canadahonk>
is a *full* name required for the participant agreement? I don't feel exactly comfortable having my full name public atm (but is somewhat understandable)

[04:27:49.0357] <annevk>
canadahonk: unfortunately, yes: https://github.com/whatwg/sg/issues/93#issuecomment-1120799691

[04:28:28.0224] <annevk>
canadahonk: now having said that, if you happen to work for an entity that is already part of the WHATWG that doesn't apply

[04:28:47.0475] <annevk>
canadahonk: as your contributions would be on behalf of that entity, but I'm not sure if that applies to you or not

[04:32:15.0539] <Dominic Farolino>
WebIDL's "upon fulfillment" queues a microtask for you, right? (It seems to call into TC39 land which call the host enqueue promise job algo). Only reason I'm not sure is because I see some specs explicitly queue a microtask themselves: https://w3c.github.io/ServiceWorker/#ref-for-upon-fulfillment

[04:41:30.0216] <Andreu Botella>
> <@domfarolino:matrix.org> WebIDL's "upon fulfillment" queues a microtask for you, right? (It seems to call into TC39 land which call the host enqueue promise job algo). Only reason I'm not sure is because I see some specs explicitly queue a microtask themselves: https://w3c.github.io/ServiceWorker/#ref-for-upon-fulfillment

Maybe WebIDL should have a note indicating that

[04:42:07.0865] <Dominic Farolino>
👍️ I'll get a PR together

[04:42:20.0427] <Andreu Botella>
I was gonna do it myself, but sure

[04:43:36.0021] <Andreu Botella>
That said, there might be observable behavior differences if you didn't queue a microtask in those specs

[04:45:00.0104] <Andreu Botella>
since the microtask queue is FIFO and any microtasks enqueued between the time the promise resolves and the time the "upon fulfillment" steps run would run before the microtask that actually does the reaction work

[04:48:32.0854] <canadahonk>
> <@annevk:matrix.org> canadahonk: as your contributions would be on behalf of that entity, but I'm not sure if that applies to you or not

unfortunately not haha

[16:09:40.0979] <canadahonk>
is there any kind of "mapping" for safari TPs -> stable releases? (for referencing/etc)

[16:34:53.0345] <Sam Sneddon [:gsnedders]>
> <@canada_goose:mozilla.org> is there any kind of "mapping" for safari TPs -> stable releases? (for referencing/etc)

not really.