2022-06-01
[02:54:00.0184] <sideshowbarker>
For the `elementtiming` content attribute, I haven’t found a PR for adding it to the HTML spec. Don’t we need one?
It’s not adequately specified in https://wicg.github.io/element-timing/#sec-modifications-DOM but from what can be gleaned from that, it seems like it would need to be added to HTML as a new global attribute. Right?

[04:53:26.0459] <Yoav Weiss>
Domenicannevk: Can we land https://github.com/whatwg/html/pull/7885 ? 

[07:05:31.0920] <Domenic>
> <@yoavweiss:matrix.org> Domenicannevk: Can we land https://github.com/whatwg/html/pull/7885 ?

Yes, it looks like the Fetch PR is landed, I will land the HTML PR.

[07:05:51.0617] <Domenic>
> <@sideshowbarker:mozilla.org> For the `elementtiming` content attribute, I haven’t found a PR for adding it to the HTML spec. Don’t we need one?
> It’s not adequately specified in https://wicg.github.io/element-timing/#sec-modifications-DOM but from what can be gleaned from that, it seems like it would need to be added to HTML as a new global attribute. Right?

Yes, any HTML global attributes with multi-implementer interest should be specified in HTML. I suspect this is a single-implementer spec?

[07:09:04.0428] <raphaellouis>
Hi all! I wish everyone is well! How are you all? 
1. I would like to publicize my GitHub profile here are the ideas implemented in Js. Some ideas I filed, I found it very bad to implement and they didn't have a good concept. In summary, I implemented the following ideas(apis): 'BestReadOnTheWeb', 'MeasuringUserInteractionTimeWithWebsite' - I would to have positive or negative feedback of each idea - if you all wants. Note: Other ideas I've shelved too - because they're bad ideas because they depend on other things and/or ideas to get done. Link: https://github.com/raphaellouisandress - the licenses for each code are MIT.
2. I hope I helped with a few things to make the web better, safer, transparent
3. I feel that after building some of these implementations my help has ended, goodbye folks. Keep up the great work all, I really enjoyed the feedback I got here.

[07:10:46.0263] <Yoav Weiss>
sideshowbarker: there was some interest in `elementtiming` from Mozilla folks, but I'm not sure if it's enough for WHATWG HTML integration

[07:11:07.0184] <Yoav Weiss>
^^ sefeng 

[07:12:29.0977] <raphaellouis>
 * Hi all! I wish everyone is well! How are you all?

1. I would like to publicize my GitHub profile here are the ideas implemented in Js. Some ideas I filed, I found it very bad to implement and they didn't have a good concept. In summary, I implemented the following ideas(apis): 'BestReadOnTheWeb', 'MeasuringUserInteractionTimeWithWebsite' - I would to have positive or negative feedback of each idea - if you all wants. Note: Other ideas I've shelved too - because they're bad ideas because they depend on other things and/or ideas to get done. Link: https://github.com/raphaellouisandress - the licenses for each code are MIT.
2. I hope I helped with a few things to make the web better, safer, transparent
3. I feel that after building some of these implementations my help has ended, goodbye folks. Keep up the great work all, I really enjoyed the feedback I got here. I tried to solve some problems and/or help with some proposals in wicg/whatwg/w3

[08:05:16.0017] <sefeng>
yeah, it's okay to say we have interests informally, however I'd like this standard position issue https://github.com/mozilla/standards-positions/issues/192 to be resolved first before adding the attribute  

[08:10:18.0341] <sefeng>
Yoav Weiss: ^

[13:38:23.0586] <ntim>
mfreed: Hi! I'm not sure [my comment here](https://github.com/w3c/csswg-drafts/issues/7319#issuecomment-1144100767) is easy to understand, let me know if you want clarifications

[13:43:12.0410] <Eric Portis (he/him)>
annevk: Would https://github.com/annevk/orb block a response for a non-safelisted MIME type, that also came back with `Cross-Origin-Resource-Policy: cross-origin`? (Should it?)


2022-06-02
[23:39:33.0575] <annevk>
Eric Portis (he/him): it currently does, in https://github.com/annevk/orb/issues/30 I mention it as a possible fast path, but to match its processing model we'd have to track it across redirects

[23:41:18.0547] <annevk>
Eric Portis (he/him): I think if we do it properly (i.e., account for redirects) it's probably reasonable to safelist such responses

[03:33:48.0865] <Ondřej Žára>
Looks like the "Libera" IRC is not the proper whatwg chat place, right?

[03:34:09.0380] <Ondřej Žára>
That might explain noone responding to my messages ;-)

[03:42:00.0386] <annevk>
Ondřej Žára: I don't think we ever advertised anything but Freenode and this channel, and now it's just this channel

[03:43:01.0782] <Ondřej Žára>
> <@annevk:mozilla.org> Ondřej Žára: I don't think we ever advertised anything but Freenode and this channel, and now it's just this channel

Yeah, I have no memories about how I got from Freenode to Libera. Whatever.

[03:43:08.0335] <Ondřej Žára>
Let me repaste my original Libera question then

[03:43:15.0874] <Ondřej Žára>
are there any general guidelines regarding "js property <-> HTML attribute" reflection for custom elements?

[03:43:23.0502] <Ondřej Žára>
for instance those interactive components whose properties change quickly (`<my-map lat=... lon=...>`)

[03:43:50.0933] <Ondřej Žára>
I recall people suggesting to use attributes as the source of truth

[03:43:57.0242] <Ondřej Žára>
But that might not hold any more?

[03:52:30.0157] <annevk>
Might be a good question for #web-components:matrix.org though it's not very active. There's definitely no guidelines in the standard. I'd recommend looking at https://html.spec.whatwg.org/#reflect and seeing how it might be applicable for a custom element. At least if you want them to behave like built-in elements. Often that does use the attribute as a source of truth, but you could optimize around that a fair bit.

[03:53:31.0279] <Ondřej Žára>
Thanks for the pointers. Will read the spec part a bit, then probably re-ask in that channel.

[06:58:12.0713] <Eric Portis (he/him)>
annevk:  Ok, thanks! This would make the story for third party media hosts that want to upgrade resources without requiring every document that embeds from them to also upgrade, well, livable, I think.

[06:58:27.0786] <Eric Portis (he/him)>
 * annevk:  Ok, thanks! This would make the story for third party media hosts that want to upgrade resources without requiring every document that embeds from them to also upgrade, well, livable, I think.

[07:49:59.0113] <annevk>
Eric Portis (he/him): I mean in principle ORB shouldn't really impact anyone, though I suppose there might be some perf implications if you don't have your MIME types in order

[07:50:39.0314] <annevk>
Eric Portis (he/him): it might be a reasonable way out however for new image formats and over the long term require something like that for all cross-origin fetches

[09:03:02.0818] <smaug>
Domenic: will be there in the meeting real soon

[10:59:03.0784] <sefeng>
Noam Rosenthal: Just want to make sure I understand the rationale behind the LargestContentfulPaint spec. So if the image is expanded, we don't report the actual painted size, but rather we report the intrinsic size of the image 

[10:59:14.0669] <sefeng>
is it because we don't want web devs to game the metric?

[11:06:43.0007] <Eric Portis (he/him)>
annevk: “in principle ORB shouldn't really impact anyone”

Half of all <img>s load cross-origin; I’d suspect CSS background-image to have a similar breakdown. My mental model of ORB previously was: in order to adopt new image formats, lots of HTML was going to have to change, and there just wouldn’t be a way to use new image formats across origins in CSS. Big impact! Mitigated by CORP.

[11:08:06.0139] <annevk>
Eric Portis (he/him): I see, new media formats definitely have that wrinkle atm

[11:08:21.0608] <annevk>
Eric Portis (he/him): I'd be okay with this compromise

[11:08:42.0803] <annevk>
Eric Portis (he/him): do you want to put it forward in https://github.com/annevk/orb/issues/3?

[11:09:29.0596] <Eric Portis (he/him)>
annevk: will do!

[11:15:35.0783] <Noam Rosenthal>
> <@sefeng:mozilla.org> Noam Rosenthal: Just want to make sure I understand the rationale behind the LargestContentfulPaint spec. So if the image is expanded, we don't report the actual painted size, but rather we report the intrinsic size of the image 

That’s the basic idea. We don’t want an enormously scaled 1x1 image to be considered “largest”

[11:18:42.0767] <sefeng>
Noam Rosenthal: I see, I start to understand the penalty factor thing..but if a scaled 1x1 image is the largest, what's wrong of reporting it..?

[11:30:54.0985] <Noam Rosenthal>
It’s ok but you don’t want to report it as 1000x1000

[11:43:16.0228] <sefeng>
Noam Rosenthal: why don't we if that's what gets painted?

[11:43:20.0014] <sefeng>
 * Noam Rosenthal: why don't we if that's what gets painted?


2022-06-03
[00:21:30.0315] <annevk>
Luca Casonato: heya, https://common-min-api.proposal.wintercg.org/ doesn't list `ErrorEvent`, do you know if Deno or Node.js would be impacted by changes to it?

[00:56:54.0774] <Luca Casonato>
> <@annevk:mozilla.org> Luca Casonato: heya, https://common-min-api.proposal.wintercg.org/ doesn't list `ErrorEvent`, do you know if Deno or Node.js would be impacted by changes to it?

Deno would. We have WebSocket, which uses it.

[00:57:11.0880] <Luca Casonato>
Good catch btw!

[01:10:42.0676] <annevk>
Yoav Weiss: crbug.com/new is failing. Is that going to be fixed?

[01:16:21.0980] <Yoav Weiss>
Thanks for letting me know!

[01:16:32.0780] <Yoav Weiss>
I'll bug folks that actually know how that infra works

[01:38:53.0752] <Yoav Weiss>
crbug.new seems to be working

[01:58:43.0097] <Noam Rosenthal>
> <@sefeng:mozilla.org> Noam Rosenthal: why don't we if that's what gets painted?

It is a heuristic to make higher quality images count as larger than upscaled ones. that metric can be gamed in so many other ways though IMO. Yoav Weiss probably has more context on LCP than myself ☺️

[02:05:30.0073] <Noam Rosenthal>
> <@noamr:matrix.org> It is a heuristic to make higher quality images count as larger than upscaled ones. that metric can be gamed in so many other ways though IMO. Yoav Weiss probably has more context on LCP than myself ☺️

Think of the placeholder use case, when an image element shows a low-quality upscaled image and then loads the full-res image later. The full-res image would be considered larger for purposes of LCP than the placeholder

[02:13:00.0444] <sideshowbarker>
Yoav Weiss: looking at https://www.w3.org/TR/largest-contentful-paint/ I see it still shows https://wicg.github.io/largest-contentful-paint as the ED URL — where instead it should be https://w3c.github.io/largest-contentful-paint/ (which the wicg URL redirects to).
Should I go ahead and raise a PR with a patch?

[02:14:42.0167] <sideshowbarker>
hmm I see the source at https://github.com/w3c/largest-contentful-paint/blob/4a0930ca74a98941237635424cd34c8a44825b2d/index.bs#L10 does already have the w3c URL

[02:18:03.0957] <sideshowbarker>
aha I see https://github.com/w3c/largest-contentful-paint/commit/4a0930ca74a98941237635424cd34c8a44825b2d from 4 days ago already fixed it.
Can you re-build and re-publish that to https://www.w3.org/TR/2022/WD-largest-contentful-paint-20220524/ ?
It’s currently causing some of the mdn-spec-links automation to fail.

[02:25:37.0816] <Yoav Weiss>
we should really just auto-publish all the things..

[02:26:47.0554] <sideshowbarker>
yes you should :)

[02:27:20.0597] <sideshowbarker>
I could help y’all set it up but if this in the webperf group, I think Xiaoqian could too

[05:25:40.0010] <zcorpan>
smaug: ping https://github.com/whatwg/dom/issues/952

[05:27:48.0815] <zcorpan>
and Sam Sneddon [:gsnedders] (or someone from webkit, cdumez seemingly isn't here) ^

[09:09:44.0470] <Domenic>
Noam Rosenthal: I just noticed there are three _response_ variables in https://html.spec.whatwg.org/#preload , with the outer one in step 8 being shadowed? Can that one be deleted?

[09:12:29.0542] <Noam Rosenthal>
> <@domenicdenicola:matrix.org> Noam Rosenthal: I just noticed there are three _response_ variables in https://html.spec.whatwg.org/#preload , with the outer one in step 8 being shadowed? Can that one be deleted?

Yea, the outer one is a leftover and should be removed since there's a `preload entry`'s `response` instead.

[09:12:45.0356] <Domenic>
Ah great. Feel free to do so in the same refactoring PR, or in a separate one.

[09:13:30.0478] <Noam Rosenthal>
> <@domenicdenicola:matrix.org> Ah great. Feel free to do so in the same refactoring PR, or in a separate one.

Done

[12:53:06.0332] <wanderview>
how do I overload an algorithm name in html spec?  I tried the "for=foo" thing in the <dfn> tag, but it didn't seem to work

[13:20:21.0585] <wanderview>
I guess data-x is my friend

[14:07:36.0547] <Domenic>
wanderview: yeah, https://github.com/whatwg/wattsi/blob/main/Syntax.md is the more-or-less full docs, it's not nearly as good as Bikeshed.


2022-06-04
[03:24:39.0556] <jaywilsonsubbottomforu>
Hey there what's up


2022-06-05
[19:05:13.0095] <californiatl>
 I'll help 10 individuals how to earn $20,000 in just 72 hours  from the crypto market. But you will pay me 10% commission when you receive your profit. if interested send me a direct message via WhatsApp by asking me HOW for more details on how to get started
> +1 (2297781881




2022-06-06
[00:32:17.0259] <alpri1989>
Hi

[08:31:58.0188] <smaug>
Domenic: is https://html.spec.whatwg.org/#the-progress-element:attr-progress-value-4 only authoring requirement?

[08:32:20.0816] <Domenic>
Yes

[08:32:37.0148] <smaug>
The paragraphs below seem to hint that value and max content attributes should be parsed.. so leading whitespace is removed

[08:32:40.0512] <smaug>
ok

[08:33:15.0809] <smaug>
(browsers aren't consistent with this)

[08:45:26.0247] <Domenic>
The user agent requirements are in the paragraphs marked "User agent requirements"

[14:23:37.0804] <Domenic>
Does anyone understand why https://www.w3.org/TR/xml/#NT-Char is actually "any Unicode character, excluding the surrogate blocks, FFFE, and FFFF"? Seems like, e.g., U+0000 NULL is excluded?


2022-06-07
[22:11:18.0981] <annevk>
Domenic: excluding control code points is quite typical

[22:12:00.0645] <Domenic>
But this infects the [^] syntax it appears: https://www.w3.org/TR/xml/#sec-notation

[22:12:47.0106] <Domenic>
As well as just the [] syntax in general

[22:12:56.0430] <Domenic>
So it looks like XML-defined EBNF is just not really usable?

[22:13:53.0258] <annevk>
Oh great, I didn't realize that ☹️

[22:15:12.0854] <Domenic>
How do we feel about JS-compatible RegExps... The other main alternative is to just write a parser algorithm

[22:15:56.0138] <Domenic>
Or maybe https://www.rfc-editor.org/rfc/rfc5234

[22:59:15.0973] <annevk>
Domenic: I think writing it out in prose might not be so bad

[23:00:09.0053] <annevk>
Domenic: if you turn the code point sets into Infra-style definitions and then have a validating algorithm that says "if string is not a X followed by zero or more Ys" and such

[02:15:15.0847] <zcorpan>
What's the status of removing sync XHR? https://github.com/whatwg/xhr/issues/20

[05:18:09.0540] <Noam Rosenthal>
 annevk any chance to continue review on https://github.com/whatwg/fetch/pull/1413 at some point? yutakahirano has already given it a 👍️

[07:22:08.0734] <raphaellouis>
Hi all! Can someone help me?

[07:23:15.0058] <raphaellouis>
I have a question, if anyone can answer I would be happy

[07:32:24.0871] <raphaellouis>
I would like to know if we could create a library in javascript to generate user interaction data

[07:32:56.0569] <raphaellouis>
This would be an alternative to cookies etc.

[07:33:36.0413] <raphaellouis>
This can be interesting for data analysis etc

[07:33:59.0411] <raphaellouis>
concept: https://discourse.wicg.io/t/draft-idea-spec-proposal-an-interesting-open-free-libre-proposal-for-a-scalable-sustainable-secure-private-accessible-business-model-compared-to-alternatives-such-as-topics-cookies-flocs-and-other-user-tracking-technologies/5906/3

[07:35:59.0925] <raphaellouis>
I would like to know if this idea is good or bad, I want to hear all sides, all criticisms, everything that can be improved or corrected

[07:45:02.0012] <raphaellouis>
Everything I've written is still conceptual, draft

[08:37:56.0790] <annevk>
Noam Rosenthal: ah, from the title change I guess you have made a change in approach now

[08:38:42.0488] <annevk>
/me notices Domenic's comment there about formatting

[08:38:46.0964] <Noam Rosenthal>
annevk: yes, as we talked about, there's no longer a "conclude" call and fetch reports timing automatically, except for in the case of navigation and early-hints

[08:39:17.0466] <annevk>
I really wish someone would write a Bikeshed source code formatter we could use, ideally mostly compatible with existing conventions to not mess up blame too much

[08:39:20.0315] <Noam Rosenthal>
... accompanied by the HTML PR https://github.com/whatwg/html/pull/7722

[08:39:51.0603] <Domenic>
Source code formatter is on my list of "learn Rust" projects. Seems... unlikely to happen.

[08:40:57.0953] <Noam Rosenthal>
> <@annevk:mozilla.org> I really wish someone would write a Bikeshed source code formatter we could use, ideally mostly compatible with existing conventions to not mess up blame too much

Is there an open issue for what's required? I can fiddle with it. I know a bit of Rust

[08:58:57.0758] <annevk>
Noam Rosenthal: so I'm not sure what's happening with the review-resolve cycle but I'm finding the same issues as Yutaka it seems, e.g., timing global seemingly having an unaccounted null value; except this specific Yutaka issue was marked as resolved (whereas some others were not but do appear addressed)

[09:00:13.0616] <annevk>
Noam Rosenthal: as for the formatter, essentially something that takes a WHATWG-style `*.bs` file, parses it, and then serializes it according to the rough formatting guidelines in `README.md`

[09:00:31.0877] <annevk>
Domenic might have more informed thoughts 🙂

[09:01:23.0692] <Domenic>
Yeah, no open issue. It's hard because parsing/serializing bs (or Wattsi-style HTML) is not an identity function.

[09:01:27.0473] <annevk>
I guess Yutaka also r+'d it and there was no forced rebase so hmm

[09:02:49.0302] <Domenic>
Another problem with HTML formatters is that it's hard to know what whitespace is significant. E.g. HTML Tidy often creates `foo.\n</p>` which is undesirable by our standards.

[09:03:33.0299] <Domenic>
But like `<li>\n<p>` is technically different than `<li><p>`
 (different DOM structure, with a text node in the middle for the former) but we consider them both OK

[09:03:57.0374] <Domenic>
 * But like `<li>\n<p>` is technically different than `<li><p>`
 (different DOM structure, with a text node in the middle for the former) but we consider them both OK

[09:04:14.0807] <Domenic>
 * Another problem with HTML formatters is that it's hard to know what whitespace is significant. E.g. HTML Tidy often creates `foo.\n</p>` which is undesirable by our standards.

[09:04:28.0886] <Noam Rosenthal>
> <@annevk:mozilla.org> Noam Rosenthal: so I'm not sure what's happening with the review-resolve cycle but I'm finding the same issues as Yutaka it seems, e.g., timing global seemingly having an unaccounted null value; except this specific Yutaka issue was marked as resolved (whereas some others were not but do appear addressed)

That comment was resolved with a reply, ‘timingGlobal’ is null in the case of early hints, I will look at it again though to make sure 

[09:05:23.0960] <annevk>
Noam Rosenthal: as written fetch's _timingGlobal_ argument is either "client" or a global object afaict (though the usage side suggests "none" can be valid and the algorithm suggests null can be valid)

[09:06:29.0969] <annevk>
Domenic: you need to push something for https://github.com/whatwg/dom/pull/1079

[09:06:37.0241] <Noam Rosenthal>
> <@annevk:mozilla.org> Noam Rosenthal: as written fetch's _timingGlobal_ argument is either "client" or a global object afaict (though the usage side suggests "none" can be valid and the algorithm suggests null can be valid)

Ok, I will revise it and the usage to state null should be valid

[09:07:09.0865] <annevk>
Noam Rosenthal: to be clear I think it would be better if you made that "none" for consistency with "client"

[09:07:40.0022] <annevk>
Noam Rosenthal: if we're doing enum or object let's not also add null to the possible types

[09:07:55.0656] <Noam Rosenthal>
> <@annevk:mozilla.org> Noam Rosenthal: to be clear I think it would be better if you made that "none" for consistency with "client"

Sure, fine with me

[09:08:22.0588] <Noam Rosenthal>
I usually prefer whims 

[09:08:28.0202] <Noam Rosenthal>
Enums 

[09:09:37.0341] <Domenic>
> <@annevk:mozilla.org> Domenic: you need to push something for https://github.com/whatwg/dom/pull/1079

Done, thanks. Working on PotentialCustomElementName now.

[09:21:46.0445] <Noam Rosenthal>
annevk: fixed comments. re. request vs. fetch: the idea is that all timing-related things are associated with fetch and not with a request. So if the request is forwarded by a service worker the timing info, initiiator and reporting global relate to the service worker and not to the original fetcher

[09:23:27.0067] <annevk>
Noam Rosenthal: does that mean we need to change the fetch params when we hand it over to the SW?

[09:24:00.0658] <Noam Rosenthal>
annevk: no need. new fetch params are created when the SW calls `fetch()`

[09:24:47.0796] <annevk>
Noam Rosenthal: well yes, if it does that, but that's also the case for bits on request so I'm not sure how that's an argument for this setup

[09:26:38.0550] <Noam Rosenthal>
annevk: you mean the TAO bit etc.? I think they should also move to fetch-params

[09:26:53.0215] <Noam Rosenthal>
also those are a bit different because they're not passed from the outside

[09:28:50.0213] <Noam Rosenthal>
To me it seems cleaner if the request was something somewhat immutable and transient that kind of matches with the `Request` object, and doesn't need to be "reset" when forwarded by the SW. In the case of timing though, it currently doesn't really have any observable difference 

[09:31:35.0017] <Noam Rosenthal>
currently we keep bumping into these issues of ambiguity between request and fetch-params, I'm hoping that by making request somewhat immutable & transient we can avoid them, but maybe it's hard to accomplish because of thing's like request's client

[09:34:47.0271] <Noam Rosenthal>
annevk: but if you think it's preferable to make `timingGlobal`& `initiator` request-associated I could go with it, it keeps the current separation of fetch taking a request + callbacks as parameters

[09:52:21.0972] <annevk>
Noam Rosenthal: so to me the string field seems very similar to "destination" (and should probably be an enum like it)

[09:52:41.0235] <annevk>
Noam Rosenthal: and longer term we want to figure out how they relate going forward

[09:53:21.0860] <annevk>
Noam Rosenthal: I'm less sure about the other fields and I do like the idea of moving some stuff out of request as it's quite overloaded

[10:03:14.0968] <Noam Rosenthal>
annevk: ok, I will move both to being request-associated. Maybe changing it to an enum is more involved though for this patch, an initiator type could potentially be any element name

[10:03:50.0597] <annevk>
I see, yeah, please file a follow-up?

[10:03:53.0771] <Noam Rosenthal>
annevk: I forget, in the case of iframes, is request's client the container or the reserved environment of the iframe? If it's the former I can probably do away with `timingGlobal`

[10:05:00.0390] <annevk>
Noam Rosenthal: hmm, that's a very good question; I'm not sure

[10:05:20.0886] <Noam Rosenthal>
(the code in HTML for that is a bit hard to follow)

[10:05:46.0912] <annevk>
For the initial request you kinda need both I think, but I'm not sure what is written down and whether that maps to what implementations do

[10:06:17.0940] <annevk>
As in, you need the parent for referrer thingies, but you don't want the parent for SW selection, say

[10:14:25.0143] <Noam Rosenthal>
annevk: yea both are passed, and the client is the container. https://html.spec.whatwg.org/#process-a-navigate-fetch

[10:14:29.0262] <Noam Rosenthal>
(2)

[10:15:39.0225] <Noam Rosenthal>
annevk: it means that I can do away with `timingGlobal` - it's always `client`, and in the early hints case request's `client` is a reserved environment which doesn't have a global object, I can infer that instead of pass it from outside

[10:16:26.0093] <Noam Rosenthal>
for the cases where there are no reporting (e.g. cross-origin style subresources) initiatorType can be null or `do not report` etc

[11:21:32.0479] <Noam Rosenthal>
annevk: done, though currently fetch doesn't build due to some biblio thing?

[11:57:46.0155] <sefeng>
Yoav Weiss: For this test https://github.com/web-platform-tests/wpt/blob/master/largest-contentful-paint/initially-invisible-images.html, wouldn't you expect an `green-1x1.png` entry first and then the `yellow.png` one? 

[12:22:00.0511] <Yoav Weiss>
@sefeng: According to the spec, I think you're right and that's what I'd expect, because "potentially add an LCP entry" is called after the image is loaded 

[12:26:08.0907] <sefeng>
Okay, yeah, that assertion is going to fail for non “yellow” images, I’ll make some changes to the test

[12:27:33.0505] <Yoav Weiss>
Thanks! 


2022-06-08
[18:32:43.0788] <dlrobertson>
Why does https://wicg.github.io/background-fetch/#header-syntax and https://fetch.spec.whatwg.org/#simple-range-header-value only handle a subset of RFC 7233?

[18:34:26.0963] <dlrobertson>
Opened https://github.com/whatwg/fetch/issues/1450 before I realized background fetch didn't handle the `suffix-byte-range-spec`

[18:35:54.0243] <dlrobertson>
I didn't really have a strong reason for opening the issue... I was mostly just curious

[00:27:55.0825] <annevk>
dlrobertson: Jake Archibald hopefully remembers

[05:21:59.0562] <dlrobertson>
I'll look at the commit message PR thread... maybe there will be useful info there as well

[05:45:33.0713] <Noam Rosenthal>
annevk: Fetch build isn't passing because a few RFCs were merged into `HTTP-SEMANTICS`, I posted a fix: https://github.com/whatwg/fetch/pull/1451

[05:53:07.0064] <dlrobertson>
 * I'll look at the commit message and PR thread... maybe there will be useful info there as well

[05:55:19.0482] <annevk>
dlrobertson: if there's nothing there I'd be inclined to treat this as a bug; it's definitely a problem that we don't call it out in a note or some such

[05:55:52.0425] <annevk>
dlrobertson: I also thought that instead of "simple" we could use "single" or "single-range" to describe the semantics more clearly once we adjust this

[05:55:56.0649] <annevk>
Noam Rosenthal: thanks!

[05:56:12.0912] <dlrobertson>
> <@annevk:mozilla.org> dlrobertson: I also thought that instead of "simple" we could use "single" or "single-range" to describe the semantics more clearly once we adjust this

Ah! I like that

[05:56:57.0532] <dlrobertson>
I'd seen your note about renaming that, but hadn't thought of anything

[05:59:33.0531] <annevk>
Noam Rosenthal: I'm going to take that PR and adjust it a bit, I think that'll be quicker than review


2022-06-09
[23:52:02.0256] <foolip>
About the new static Response.json() which can't be documented in MDN/BCD yet: https://github.com/mdn/browser-compat-data/issues/16613

[23:56:41.0385] <Ms2ger 💉💉>
Oops

[23:58:44.0810] <sideshowbarker>
_“hope this doesn't happen much”_ indeed

[00:01:38.0602] <sideshowbarker>
foolip: Another possible option is to make a subfeature of `api.Response.json` named `"static"` — which is ugly and backwards but at least we wouldn’t need a separate filename or new subdirectory (and no mass updates of existing data)

[00:01:50.0201] <annevk>
foolip: perhaps you could do something like api.Response$statics.json, but stuffing prototype in all of the existing members would be correct

[00:02:27.0804] <sideshowbarker>
 * foolip: Another possible option is to make a subfeature of `api.Response.json` named `"static"` — which is ugly and backwards but at least we wouldn’t need a separate filename or new subdirectory (and no mass updates of existing data)

[00:04:50.0457] <foolip>
It would solve the problem, and would have the benefit that it tells BCD consumers what's static and what's not, but it would be a big change. It's notable that it's not done even for the javascript.* data, even though .prototype. is in the page titles (but not URLs) there, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/groupByToMap for example.

[00:09:52.0911] <sideshowbarker>
yeah in hindsight I guess it all should have been done that way from the beginning but at the point is seems like the correcting it globally would maybe be a case of the cure being worse than the disease

[00:15:38.0059] <sideshowbarker>
As far as my `"static"` subfeature hack, one side effect of it is that the current tooling would cause the compat data for the static method to show up in the BCD table for the instance method at https://developer.mozilla.org/en-US/docs/Web/API/Response/json#browser\_compatibility as an additional subfeature.

We wouldn’t want that of course — but I know the code for generating the BCD tables very well, and it would be easy to add some special-handling to it to cause it ignore any case of `"static"` as a subfeature but not ignore it when it’s called directly as a feature — that is, ignore it for the MDN page that specifies its relevant BCD feature/query is `api.Response.json` but not ignore it if the MDN page specifies its relevant BCD feature/query is `api.Response.json.static`.

[00:16:20.0376] <sideshowbarker>
 * As far as my `"static"` subfeature hack, one side effect of it is that the current tooling would cause the compat data for the static method to show up in the BCD table for the instance method at https://developer.mozilla.org/en-US/docs/Web/API/Response/json#browser\_compatibility as an additional subfeature.

We wouldn’t want that of course — but I know the code for generating the BCD tables very well, and it would be easy to add some special-handling to it to cause it ignore any case of `"static"` as a subfeature but not ignore it when it’s called directly as a feature — that ignore it for the MDN page that specifies its relevant BCD feature/query is `api.Response.json` but not ignore it if the MDN page specifies its relevant BCD feature/query is `api.Response.json.static`.

[00:16:44.0153] <sideshowbarker>
 * As far as my `"static"` subfeature hack, one side effect of it is that the current tooling would cause the compat data for the static method to show up in the BCD table for the instance method at https://developer.mozilla.org/en-US/docs/Web/API/Response/json#browser\_compatibility as an additional subfeature.

We wouldn’t want that of course — but I know the code for generating the BCD tables very well, and it would be easy to add some special-handling to it to cause it ignore any case of `"static"` as a subfeature but not ignore it when it’s called directly as a feature — that is, ignore it for the MDN page that specifies its relevant BCD feature/query is `api.Response.json` but not ignore it if the MDN page specifies its relevant BCD feature/query is `api.Response.json.static`.

[00:17:18.0887] <sideshowbarker>
 * yeah in hindsight I guess it all should have been done that way from the beginning but at the point is seems like correcting it globally would maybe be a case of the cure being worse than the disease

[00:17:31.0146] <sideshowbarker>
 * yeah in hindsight I guess it all should have been done that way from the beginning but at this point is seems like correcting it globally would maybe be a case of the cure being worse than the disease

[00:17:42.0584] <sideshowbarker>
 * Yeah in hindsight I guess it all should have been done that way from the beginning but at this point it seems like correcting it globally would maybe be a case of the cure being worse than the disease

[01:06:20.0407] <Jake Archibald>
dlrobertson: what other parts of the range syntax do browsers support?

[01:30:36.0660] <Jake Archibald>
(I've replied to the issue)

[03:28:38.0282] <Noam Rosenthal>
annevk: About the controller PR, I ended up spelling out all the initiator types, it does feel cleaner than a string. The PR build passes now and I went through all the comments again, I think it's ready.

[05:38:47.0411] <dlrobertson>
> <@jakea:matrix.org> dlrobertson: what other parts of the range syntax do browsers support?

Thanks! I'll comment in the issue as well

[05:45:52.0193] <dlrobertson>
tl;dr I think this would in practice only be used for blob slicing (and we don't have to support this)

[06:33:36.0801] <dlrobertson>
 * tl;dr I think this would in practice only be used for blob slicing (and we don't have to support this form of range there)

[07:20:32.0316] <Domenic>
foolip: sideshowbarker: IMO the more we can move the ecosystem away from incorrectly thinking of prototype/instance methods and properties as static ones the better... I'm excited that this is providing a forcing function. I hope one day strings like "Document.createElement" never appear in anyone's infrastructure...

[07:45:05.0337] <foolip>
> <@domenicdenicola:matrix.org> foolip: sideshowbarker: IMO the more we can move the ecosystem away from incorrectly thinking of prototype/instance methods and properties as static ones the better... I'm excited that this is providing a forcing function. I hope one day strings like "Document.createElement" never appear in anyone's infrastructure...

It’s just a lot of work, and even if done there isn’t another agreed-upon shorthand, so I think we’ll keep seeing this for a long time…

[07:46:41.0060] <foolip>
Someone would have to go on a long and dedicated cleanup campaign to sort this out across MDN, BCD and maybe other places.

[08:39:58.0594] <Domenic>
Shorthand doesn't seem necessary, `.prototype` is not a lot of extra characters

[08:40:23.0415] <Domenic>
I agree this is a lot of tech debt. Like all tech debt, it was waiting to bite us one day. You can keep paying interest or you can pay down the principal.

[08:40:29.0010] <Domenic>
 * I agree this is a lot of tech debt. Like all tech debt, it was waiting to bite us one day. You can keep paying interest or you can pay down the principle.

[08:40:48.0264] <Domenic>
 * I agree this is a lot of tech debt. Like all tech debt, it was waiting to bite us one day. You can keep paying interest or you can pay down the principal.

[09:47:58.0663] <raphaellouis>
Hi all! What do you all think of this idea?

[09:48:04.0812] <raphaellouis>
https://github.com/WICG/scroll-to-text-fragment/issues/185

[09:48:43.0561] <raphaellouis>
I open an issue - I would like to know the opinion of everyone here.

[09:49:03.0943] <raphaellouis>
`https://example.com/#:~:text=character_start&character_end&elementHTML`

[09:49:21.0092] <raphaellouis>
`https://example.com/#:~:text=characters&words&lines&without_white_space&paragraphs&spaces&sentences`

[09:50:12.0494] <raphaellouis>
My idea is to search text snippets according to character size or html reference

[09:50:28.0983] <raphaellouis>
`https://en.wikipedia.org/w/index.php?title=Cat#:~:text=38,7,1,32,1,6,1`

[09:50:49.0425] <raphaellouis>
"characters": "38", "words": "7", "lines":"1", "without white space":"32", "paragraphs": "1", "spaces": "6", "sentences":"1", "string": "Like almost all members of the Felidae"

[09:52:21.0524] <raphaellouis>
`https://en.wikipedia.org/w/index.php?title=Cat#:~:text=0&38&h3`

[10:18:46.0239] <raphaellouis>
please,  I would like to know the opinion of everyone here.

[10:47:16.0742] <raphaellouis>
is anyone online?


[10:53:57.0136] <raphaellouis>
Is this idea good or bad?

[10:57:29.0004] <raphaellouis>
if you think this idea is bad, an alternative would be this idea/concept: https://discourse.wicg.io/t/proposal-built-in-e2e-encryption-into-web-browsers/5897 - Hi all! A question is it possible to use the FIDO protocol and hardware keys through E2E in browsers?

[10:58:31.0672] <raphaellouis>
another doubt/concept: 3. Integrating css+js+html into a single language will allow what many call Embedded markup as RTF - Rich Text Format?

[10:59:30.0850] <raphaellouis>
4. What do you all think of this idea of having an official standard for importing/exporting passwords in browsers?

[11:24:51.0867] <Domenic>
raphaellouis: I think you should consider that if you are not getting responses, then this forum might not be the best place for your ideas. In general people most interested in hearing about a proposal for a specification are already on the specification's issue tracker. Or people interested in hearing new general ideas are already subscribed to the WICG discourse. Going to an unrelated standards forum's chat room and linking to your idea is maybe not a good way of interacting with that standards forum.

[11:28:41.0210] <Domenic>
 * I agree this is a lot of tech debt. Like all tech debt, it was waiting to bite us one day. You can keep paying interest or you can pay down the principle.

[12:21:56.0904] <raphaellouis>
@Domenic thank you for feedback


2022-06-10
[05:13:14.0856] <freddy>
How do I check / ensure that a concept in the HTML spec is exported? I'm looking for a `template` element's content. I see that there exists `<dfn>template contents</dfn>`. Do I want to supply a patch that adds an `id=` attribute here?

[06:12:01.0977] <annevk>
freddy: you want to make that <dfn for="HTMLTemplateElement" export>, ID should be generated already

[06:16:01.0985] <freddy>
Do these editorial things need an issue or would a pull request suffice? :)

[08:18:38.0575] <sefeng>
```
If imageRequest is not a data URL [RFC2397] and if the timing allow check fails for imageRequest’s resource, run the report image element timing algorithm, passing in the triple (element, imageRequest, now), 0, and root as inputs.
```

[08:21:20.0946] <sefeng>
Element Timing API spec has this ^, the `timing-allow-check` correctly covers loading a cross origin image case I believe, but I don't think it covers `make renderTime 0 if there are cross origin redirects, regardless the timing-allow-origin header`?

[08:21:45.0389] <sefeng>
Yoav Weiss: ^ 

[08:22:17.0069] <sefeng>
Here's the test case https://github.com/web-platform-tests/wpt/blob/master/largest-contentful-paint/multiple-redirects-TAO.html#L19

[08:26:49.0669] <Yoav Weiss>
Hmm.. I'm almost out for the week, but I'll get back to you

[08:28:05.0581] <sefeng>
no worries, I can always file a github issue

[08:32:14.0773] <annevk>
freddy: PR is fine

[09:46:09.0662] <sefeng>
Yoav Weiss: could be I interpreted the test wrong, still looking 


2022-06-13
[22:30:52.0385] <Yutaka Hirano>
annevk: Looking forward to your feedback on https://github.com/whatwg/fetch/issues/1438#issuecomment-1150755587.

[00:57:50.0353] <annevk>
Yutaka Hirano: sounds like a good plan; I can look at the PR later today

[01:20:47.0395] <Yutaka Hirano>
annevk: Thanks!

[03:42:20.0466] <Yoav Weiss>
sefeng: The spec's "timing-allow check" link should probably point directly to https://fetch.spec.whatwg.org/#concept-tao-check

[03:42:27.0136] <Yoav Weiss>
which does take redirects into account

[03:42:54.0378] <Yoav Weiss>
if the Chromium implementation doesn't, can you please file a bug? (Or land a WPT that would fail once we roll it in)

[03:48:07.0005] <Yoav Weiss>
sefeng: The comment you're pointing at in the WPT doesn't say that TAO for the redirects is ignored, just that the final resource is not impacting TAO passes or not, because it does

[07:54:50.0867] <wanderview>
annevk: regarding the struct on environment that would contain the various bits of StorageKey...  do you have a preference on the name of the struct?  what information do you see living in there besides nonce and cross-site-ancestor?

[09:11:00.0426] <annevk>
wanderview: top-level origin and origin, although I'm a little torn on origin given that it's still somewhat inconclusive what networking should do

[09:11:27.0059] <annevk>
But maybe it's okay enough that networking just ignores that part when creating its key

[09:12:52.0278] <annevk>
Given all of that I was thinking "authority" would be fitting and we'd ignore parts of it in specific contexts, but I'm definitely open to other ideas

[09:18:17.0029] <annevk>
Luca Casonato: hey, for full duplex, the tests you pointed to, does the server there support full duplex?

[09:36:41.0029] <annevk>
I added some thoughts to the full duplex issue directly, I think it's worth looking into, but I wonder if the existing setup already got us stuck with half duplex, e.g., due to the blobs

[11:36:01.0548] <Luca Casonato>
> <@annevk:matrix.org> Luca Casonato: hey, for full duplex, the tests you pointed to, does the server there support full duplex?

If it is the Deno.dev one, yes 


2022-06-14
[02:22:08.0249] <Noam Rosenthal>
annevk: for the fetch issue, can we count on client to always be task destination? `useParallelQueue` seems to change that, e.g. for sync XHR but I guess it's not in use much?

[02:23:16.0352] <Noam Rosenthal>
I guess it's OK in that case to use the parallel queue as the task destination anyway (thinking out loud)

[02:37:19.0734] <annevk>
Noam Rosenthal: I'm not sure, I suspect that in general we have to do more of that and less useParallelQueue

[02:37:51.0271] <annevk>
Noam Rosenthal: the effect could be that if you have to use a parallel queue you don't get automatic timing reporting?

[02:38:17.0134] <annevk>
I suspect you're more familiar with callers at this point, I haven't reviewed those in quite a while

[02:39:24.0516] <Noam Rosenthal>
annevk: only sync-xhr uses parallel queue from what I could gather. Also there are barely any callers of `processResponseEndOfBody` once we do the automatic reporting. From what I see it's OK to use the regular task destination and perform both operations

[02:39:56.0604] <annevk>
That would be great

[02:40:08.0873] <annevk>
I'll make sure to take another look later today

[02:40:40.0694] <Noam Rosenthal>
> <@annevk:matrix.org> I'll make sure to take another look later today

Thanks, I'll have the new revision up shortly

[04:02:35.0174] <smaug>
Does anyone know folks from Github?

[04:03:42.0704] <smaug>
It seems to be relying on very specific bfcache behavior https://bugzilla.mozilla.org/show_bug.cgi?id=1772739#c10

[04:35:34.0919] <annevk>
Luca Casonato: I saw you agreed to forbidding H/1 connections for upload streams, are you going to look at the full duplex issue still? I think we should solve that, although I suppose I could merge this PR and we'd leave the "blocking" label there for now; Yutaka Hirano thoughts?

[05:35:24.0152] <Luca Casonato>
annevk: yeah that sounds good. I am at https://webengineshackfest.org/2022/ until tomorrow, and then at another conf on Thursday, so I won’t get to the full duplex streaming until Friday 

[05:57:09.0411] <annevk>
Ooh cool, still hope to be able to visit that one year; enjoy!

[06:43:34.0159] <Domenic>
> <@smaug:mozilla.org> It seems to be relying on very specific bfcache behavior https://bugzilla.mozilla.org/show_bug.cgi?id=1772739#c10

Related, https://github.com/whatwg/html/issues/7253

[08:29:41.0786] <Luca Casonato>
> <@annevk:matrix.org> Ooh cool, still hope to be able to visit that one year; enjoy!

Thanks 😊 

[11:19:11.0381] <wanderview>
Domenic: Thinking about my next partitioning PR, I think we need to populate environment's top-level origin for SharedWorker.  In implementation, though, we only populate the origin with the top-level site.  Its the only consistent value to use when top-level site partitioning is in use.  (We don't want different values depending on which document first created the worker.)  Does that sound like a reasonable approach to take in the spec as well?

[11:57:37.0246] <Domenic>
wanderview: I *think* so. I'd prefer to get annevk's feedback, but from what I can tell from e.g. https://github.com/whatwg/html/pull/5491#issuecomment-638989208 and related comments, we have so far punted on defining top-level origin for workers until storage partitioning was in place, and we knew that we would eventually need it to ensure that e.g. network caches work well. Or at least, we would need enough info to feed into "obtain a storage key" / "obtain a storage key for non-storage purposes". Which I guess is just the site.

What's unclear to me is whether this means "top-level origin" is not a good primitive, and if so what we would do about it. But e.g. it is used in origin form for window-specific things like showPicker() or COOP enforcement. So maybe the best we can do is say that it's sometimes an origin and sometimes a scheme-and-host, and maybe rename it slightly to reflect that?

[12:04:08.0581] <wanderview>
right, this issue only effect SharedWorker and ServiceWorker... but right now I'm not aware of anything that actually depends on top-level origin specifically instead of top-level site

[12:04:51.0592] <wanderview>
its possible some extension stuff in chromium would see slightly different behavior for requests coming from those workers


2022-06-15
[22:15:46.0949] <annevk>
wanderview: if you created a shared or service worker from a document with a nonce, presumably they too should have a nonce?

[02:43:13.0724] <sideshowbarker>
https://github.com/gzuidhof/coi-serviceworker

[02:43:32.0752] <sideshowbarker>
 * https://github.com/gzuidhof/coi-serviceworker

[07:20:52.0492] <wanderview>
annevk: yes, the nonce would propagate and be part of the storage key as well

[08:24:05.0566] <annevk>
wanderview: I might have misunderstood and thought you were asking if we needed to pass anything on in addition to top-level origin... I think we have some things where we want to use top-level origin as opposed to site, e.g., if we want to disallow something in "third party" documents ideally we'd use cross-origin as a way to determine that. Some of that might be applicable to workers as well, but it's hard to come up with a concrete example

[08:33:49.0695] <wanderview>
annevk: I just discussed this with Domenic and he was going to write up an issue

[08:54:34.0013] <Domenic>
https://github.com/whatwg/html/issues/8014

[12:14:39.0523] <wanderview>
annevk: would an initial PR to add "authority container" with just an origin and then a follow-up PR to add top-level site to the container be reasonable?


2022-06-16
[00:05:24.0237] <annevk>
wanderview: yeah I think so, would love to hear from Google security folks too

[07:39:06.0543] <wanderview>
not sure what the question for the security folks is

[11:51:53.0272] <annevk>
wanderview: "could you please evaluate this idea and let us know your thoughts?"

[11:53:38.0469] <wanderview>
"this" == the refactor to add auth container?  or some other part of what we have been talking about?

[12:43:41.0531] <zcorpan>
Domenic: to solve https://github.com/whatwg/html/issues/7976 we need to solve https://github.com/whatwg/html/issues/1013 , right? Especially if we only want to allow adding new render-blocking things if the "current script" was itself render-blocking

[13:11:12.0701] <Domenic>
zcorpan: I don't understand the connection

[13:13:01.0815] <zcorpan>
Domenic: when import() runs, how can it tell whether the running script is render-blocking? (Assuming we don't want async scripts in <body> to be able to add render-blocking imports, or from setTimeout and such)

[13:13:58.0686] <zcorpan>
I guess the web-exposed mechanism for #1013 is not necessary, but the same internal mechanism

[13:31:46.0785] <Domenic>
I thought import(..., { blocking: "render" }) would just set the render-blocking flag on the script when it runs

[14:11:29.0374] <zcorpan>
Domenic: See https://github.com/whatwg/html/issues/7976#issuecomment-1145105267 it should not set the flag if the script was in <body>. Which makes me think the import() steps need to check if the <script> that contains the import() statement is render-blocking, to decide whether to allow the import to also be render-blocking

[14:13:41.0936] <Domenic>
Well, the problem is probably solvable here. The issue with module scripts is that they have many ancestors. We can "just" check that none of their ancestors is in the <body>.

[14:14:14.0160] <Domenic>
Although, by default all module scripts are defer, so run after </body> is encountered. So I am skeptical about this framing making sense.

[14:14:39.0645] <zcorpan>
You'd use async

[14:19:28.0601] <zcorpan>
I agree it should be solvable. I struggle to find existing terms in the spec to solve it tho :)

[15:16:29.0291] <Domenic>
Yeah I don't think we (or the JS spec) track ancestor information... I guess you'd probably propagate it down as part of executing a <script>


2022-06-17
[23:45:47.0240] <annevk>
wanderview: the issue Domenic opened and the ideas therein, so yeah, authority container, possibly combining it with policy container, as well as origin vs site aspects

[01:06:23.0900] <The Freelancer>
Hello everyone

[01:06:43.0431] <The Freelancer>
Wanted to ask one question that has been troubling me for a while?

[01:08:21.0522] <The Freelancer>
Back in the day, W3C had three divisions of the DOM spec. One was core DOM, the other was HTML DOM and the third was XML DOM. But when I go to the WHATWG spec, there is no mention of this distinction. My point is, that is this distinction still made in the specs of the DOM or can we now safely assume that there is no such distinction and that there is just one DOM spec.

[01:17:52.0733] <zcorpan>
The Freelancer: there's no XML DOM vs HTML DOM anymore, though the behavior of some APIs differ between HTML and XML. It's just the DOM spec, and some things that were previously in the "HTML DOM" spec is now in the HTML spec

[01:19:48.0439] <zcorpan>
e.g. `createElement` and `createCDATASection`

[01:50:30.0633] <The Freelancer>
zcorpan: So if some other vendor, or let's say a library author for another language such as Python, wants to implement the DOM, they have to go through the WHATWG spec. Is that right? But then how would that person be able to distinguish between what's really meant for HTML, what's meant for XML, and what's meant for both. I hope you get my point.

[01:51:35.0838] <zcorpan>
The Freelancer: if they don't support HTML, then they can no-op the parts that branch off of an HTML check

[01:52:01.0011] <The Freelancer>
Sorry, but I didn't get that.

[01:52:41.0582] <zcorpan>
Sorry, jargon :) no-op means no operation, meaning code that does nothing (or no code)

[01:53:50.0506] <zcorpan>
For example, when implementing https://dom.spec.whatwg.org/#dom-document-createelement , if "this" can never be an HTML document (because HTML is not supported), then you can skip step 2

[01:55:07.0920] <The Freelancer>
Ok, so that means that any person wanting to implement the DOM for HTML or non-HTML documents has to nonetheless go through the whole document filtering out what he/she really needs?

[01:55:12.0525] <The Freelancer>
Am I right?

[01:55:20.0617] <zcorpan>
yes

[01:55:44.0497] <The Freelancer>
One more thing, sorry to disturb you again and again, what was the motivation behind unifying these three DOM specifications (i.e. HTML DOM, XML DOM, and Core DOM)?

[01:56:33.0248] <zcorpan>
Browser engines is the primary implementer for web specs, and they have a single implementation of the DOM, not 3

[01:57:24.0054] <zcorpan>
It's easier to have a well-defined easy-to-implement spec if the behavior of an API is in one algorithm, instead of spread out across different documents

[01:57:56.0346] <The Freelancer>
That sounds relatable :)

[01:58:07.0974] <The Freelancer>
One last thing if you don't mind. May I?

[01:58:15.0318] <zcorpan>
don't ask to ask, just ask :)

[01:59:34.0705] <The Freelancer>
Thanks a lot. I don't find the style property in the WHATWG DOM standard. It's instead in the HTML standard. Why is this so? I guess that the style JavaScript property is also part of the DOM, then why does it get its place in the WHATWG HTML standard?

[02:02:36.0088] <zcorpan>
It's actually defined in CSSOM: https://www.w3.org/TR/cssom-1/#the-elementcssinlinestyle-mixin

[02:05:12.0996] <The Freelancer>
But it could've been defined in the DOM standard, couldn't it? There must be some reason, that I am unaware of, due to which it was given place in the CSSOM standard?

[02:06:51.0750] <zcorpan>
Yeah, but it would violate layering. Having HTML-specific things in DOM is also a layering violation, but HTML is less optional and more integrated. For the style attribute, DOM would have to put a dependency on CSS, HTML, SVG and MathML

[02:07:46.0178] <The Freelancer>
Alright.

[02:07:59.0370] <The Freelancer>
Can you elaborate this further : 'Having HTML-specific things in DOM is also a layering violation, but HTML is less optional and more integrated.'

[02:10:01.0090] <zcorpan>
Are you asking about what a layering violation is?

[02:10:14.0422] <The Freelancer>
Yeah.

[02:10:34.0213] <The Freelancer>
I think that it might be adding something where it ideally shouldn't be. Right?

[02:11:40.0554] <The Freelancer>
I guess that including the style attribute in the DOM standard would've required the DOM standard to define a lot of CSS-specific interfaces, which would've simply cluttered the spec. Is that so?

[02:12:39.0133] <zcorpan>
https://en.wikipedia.org/wiki/Multitier_architecture

[02:13:06.0993] <zcorpan>
The layering for the web is summarized in https://html.spec.whatwg.org/multipage/introduction.html#abstract

[02:15:08.0117] <The Freelancer>
So basically including HTML in the DOM standard is a violation, but it can't be avoided completely. Is that what you mean?

[02:15:19.0907] <Noam Rosenthal>
The Freelancer: the DOM standard can be used outside the context of HTML, it's an API to manipulate a document in general. You can see HTML as expanding it with browser features, and the CSS spec enhancing it even more

[02:16:29.0066] <Noam Rosenthal>
This python library, for example, is an implementation of DOM for reading XML documents and doesn't need to include anything from the HTML spec: https://docs.python.org/3/library/xml.dom.html#module-xml.dom

[02:16:47.0826] <The Freelancer>
Noam Rosenthal: when you say 'to manipulate a document' you mean an HTML or XML document, right? Or just about any document like docx, txt, etc.???

[02:17:12.0077] <Noam Rosenthal>
The Freelancer: yes, HTML or XML document. 

[02:17:26.0098] <The Freelancer>
Noam Rosenthal: Ok.

[02:17:29.0855] <zcorpan>
The Freelancer: right. There are sometimes benefits to layering violations

[02:18:55.0626] <The Freelancer>
zcorpan: Alright, I get it to a great extent.
But one thing that's 100% clear to me now is that writing specifications and ramifying them as separate documents is a very challenging task. Like really really really difficult.

[02:19:27.0421] <The Freelancer>
One has to consider **_a lot_** of details before drafting specs.

[02:19:39.0583] <zcorpan>
true

[02:19:43.0136] <Noam Rosenthal>
The Freelancer: tell me about it :) I now have 5 open pull-requests for separate specs for the same feature because of cross-dependencies

[02:20:33.0314] <The Freelancer>
Noam Rosenthal: I get it :) It's really difficult.

[02:21:27.0779] <The Freelancer>
zcorpan and Noam Rosenthal thanks a lot for your time.

[02:21:46.0618] <zcorpan>
np

[02:22:10.0613] <The Freelancer>
I am leaving this chat with a sound amount of information. If ever in future I want to ask a question related to WHATWG standards, I now know the right forum to turn to.

[02:22:13.0160] <The Freelancer>
Thanks a lot.

[02:28:12.0722] <sideshowbarker>
PSA: I’ve mentioned here before that I wrote a tool which generates activity reports for GitHub repos somewhat like the Pulse thing in GitHub itself, but in a lot more detail.

Today and yesterday I used it to generate and archive a bunch of reports for a bunch of different repos — including some WHATWG ones.

The ones I generated so far are at https://git-pulse.github.io/reports/

[02:29:12.0945] <sideshowbarker>
https://git-pulse.github.io/reports/whatwg-html-2022-06-15-pulse.html, for example

[02:31:07.0155] <sideshowbarker>
if there are any other repos that anybody would like to see reports for, either let me know and I can add them, or else you can run the tool yourself and open a PR to add the output

[04:13:04.0796] <amphitryon>
The HTML Standard says "The form element represents a hyperlink," but shouldn't that only be true when its method is GET or POST?

[04:13:33.0978] <amphitryon>
In something like <dialog open><form method=dialog><p>Text you need to acknowledge</p><button>OK</button></form></dialog>, I would not think that the form represents a hyperlink.

[04:14:21.0987] <amphitryon>
I guess it's complicated, though, since it could have a submit button with a formmethod attribute.

[05:58:58.0032] <annevk>
Luca Casonato: duplex = "half" | "full" is prolly what we want, c.f. https://en.wikipedia.org/wiki/Duplex_(telecommunications)

[05:59:25.0742] <Luca Casonato>
Yeah, that makes much more sense indeed 

[06:01:05.0259] <annevk>
Luca Casonato: I think you'll have to explain how we're not already "half" due to blobs

[06:01:37.0815] <annevk>
Luca Casonato: because I strongly suspect that with a blob that results in some I/O error, browsers will reject the promise

[06:01:55.0846] <Yutaka Hirano>
If it's difficult to choose "half" as the default value, how about not choosing a default value? That means web developers always need to specify the option.

[06:02:39.0447] <annevk>
Yutaka Hirano: we can require it for streams, but I'm not sure how that helps with blobs

[06:03:12.0406] <Yutaka Hirano>
Yeah I'm talking about the case where body is a ReadableStream.

[06:08:30.0652] <Luca Casonato>
I guess you are right annevk. Arguably all of `fetch` is current half duplex, because a server could technically respond with response headers before we have finished sending the request body (even a large static request body), but we don't allow the `Promise` returned from `fetch` to complete until the entire request body is uploaded. In an ideal world, full duplex would allow the `Promise` returned from `fetch` to be only blocked on the response headers, never on the request body sending.

[06:10:04.0273] <Luca Casonato>
Deno does implement it this way, where the `Promise` returned from `fetch` is only blocked on response headers, and request sending happens in a separate parallel task. I would not be suprised if switching this behavior in browsers at some point would break compatibility, so we probably have to make full duplex opt-in. That's very unfortunate.

[06:10:15.0384] <Luca Casonato>
Especially because CFW and Deno already do full duplex by default.

[06:11:23.0707] <annevk>
Yeah, I would be okay with requiring _duplex_ to be set for streams though as Yutaka suggested, to encourage some amount of thinking about it going forward.

[06:12:24.0559] <Luca Casonato>
Yeah, that would be reasonable. Deno and CFW would have a legacy interop issue where we'd default that to `"dupelx"`, but I think that's not the end of the world.

[06:13:52.0577] <Luca Casonato>
If browsers are ok with no default for `"duplex"`, and requiring `"duplex": "half"` to be set for `ReadableStream` bodies, I have no further concerns.

[06:15:06.0770] <Luca Casonato>
 * Yeah, that would be reasonable. Deno and CFW would have a legacy interop issue where we'd default that to `"duplex": "full"`, but I think that's not the end of the world.

[06:17:59.0621] <Luca Casonato>
I will summarize & record this in the issue in a moment. 

[06:19:45.0700] <annevk>
Luca Casonato: well, I guess we'd default it to "half" outside of streams, if we end up reflecting it on Request, which we might have to I suppose

[06:20:17.0541] <annevk>
Luca Casonato: I'm not sure it makes sense to have an "auto" value as the programming model is quite a bit different

[06:21:07.0065] <annevk>
Also, with "full" and blobs you end up not being able to detect upload failures I think, as long as we don't have FetchObserver

[06:25:10.0377] <annevk>
krosylight: happy b-day! 🎂🎉

[06:27:47.0409] <Luca Casonato>
> we'd default it to "half" outside of streams

That seems fine. I am 99% sure this will be non-breaking for us.

I also agree, that no "auto" option is probably best.

And yeah, "full" + blob has no way to detect upload failures. This is fine for us right now, because our blobs can never produce I/O errors right now.

[06:27:52.0070] <Luca Casonato>
 * > we'd default it to "half" outside of streams

That seems fine. I am 99% sure this will be non-breaking for us.

I also agree, that no "auto" option is probably best.

And yeah, "full" + blob has no way to detect upload failures. This is fine for us right now, because our blobs can never produce I/O errors right now.

[06:57:03.0115] <Domenic>
> <@annevk:matrix.org> wanderview: the issue Domenic opened and the ideas therein, so yeah, authority container, possibly combining it with policy container, as well as origin vs site aspects

So the issue I opened doesn't deal with the authority container/policy container idea, which I think still only you understand. It's solely about whether we should track top-level site vs. top-level origin. We can ask security people what they think of my issue, but I'm pretty sure they'll just be like, "yes, sounds right, there's no clear top-level origin for shared workers, but there is a clear top-level site".

[08:09:54.0248] <annevk>
Domenic: what is unclear about it?

[08:32:43.0153] <wanderview>
what I don't understand is why security team would care about the structure of html spec... seems equivalent whether attributes are in an auth struct or passed individually as attributes on environment, etc... there doesn't seem to be a functional difference they would have an opinion about

[08:33:23.0432] <annevk>
wanderview: the people I tagged wrote the text on policy container and have a lot of experience with it

[08:35:00.0174] <annevk>
And also, fundamentally the spec is higher-level architecture and it's good to get that right, hence getting experts to review it

[08:52:05.0497] <krosylight>
Thank you 😊

[10:49:22.0483] <Domenic>
> <@annevk:matrix.org> Domenic: what is unclear about it?

It's hard to explain what's unclear because neither Ben nor I understand the idea? It's never been written down in an expanded form of what the proposal is, that we could ask questions about? I.e. what exactly is proposed to change from X to Y, and what implications this would have.

[10:51:33.0557] <Domenic>
Like what is an "authority", is it just a renaming of "top-level site"? Why would you put that in a policy container?


2022-06-20
[09:54:29.0056] <smaug>
https://github.com/shaseley/abort-signal-any/blob/main/README.md talks about memory management being hard with JS based solutions, but I'm missing to see how the proposed solution helps with that

[09:54:39.0533] <smaug>
looking at https://github.com/shaseley/abort-signal-any/blob/main/README.md#userland-solutions as an example

[09:54:55.0463] <smaug>
(is shaseley on matrix?)

[09:58:46.0205] <smaug>
/me filed an issue on the proposal


2022-06-21
[04:48:03.0327] <smaug>
jgraham: is there a matrix room for cross-browser wpt related stuff?

[04:50:06.0524] <smaug>
There just happens to be some nice conflicts atm 😉 https://bugzilla.mozilla.org/show_bug.cgi?id=1774475#c7

[04:50:45.0253] <Andreu Botella>
#wpt:matrix.org 

[04:50:51.0083] <smaug>
I was fixing a test and around the same time the whole test was reverted on chromium side.

[04:51:02.0514] <smaug>
Andreu Botella: thanks

[04:51:08.0110] <Andreu Botella>
sure


2022-06-22
[14:30:34.0316] <smaug>
Hmm, why this lowercases charset: (new Response(new Blob(["data"]), {headers: [["Content-Type", "text/plain;charset=UTF-8"]]})).blob().then((b)=> { console.log(b.type); });

[14:32:00.0669] <smaug>
Blob constructor does convert type to lowercase, but fetch spec doesn't use that constructor 

[15:58:50.0964] <Luca Casonato>
`blob.type` always returns a lowercase string:

> On getting, user agents must return the type of a Blob as an ASCII-encoded string in lower case

See https://w3c.github.io/FileAPI/#attributes-blob

[16:00:33.0177] <Luca Casonato>
 * `blob.type` is specified to always returns a lowercase string:

> On getting, user agents must return the type of a Blob as an ASCII-encoded string in lower case

See https://w3c.github.io/FileAPI/#attributes-blob


2022-06-23
[00:48:50.0751] <annevk>
smaug: Luca Casonato: see https://github.com/w3c/FileAPI/issues/43 for changing that (it shouldn't lowercase parameters as that can change meaning in certain cases, such as with `boundary`)

[01:49:32.0820] <emilio>
sideshowbarker: when you're around, can you merge https://github.com/validator/htmlparser/pull/70? Henri will be afk for a couple weeks :)

[03:26:29.0609] <sideshowbarker>
> <@emilio:mozilla.org> sideshowbarker: when you're around, can you merge https://github.com/validator/htmlparser/pull/70? Henri will be afk for a couple weeks :)

yup — just now merged

[03:29:25.0356] <emilio>
sideshowbarker: if you can review https://github.com/validator/htmlparser/pull/71 as well that'd be awesome, but no worries, it's not super-urgent (though it should be trivial :P). Tests and so have been reviewed already in https://bugzilla.mozilla.org/show_bug.cgi?id=1775477 fwiw :)

[03:29:44.0686] <sideshowbarker>
will look right now

[03:30:38.0613] <sideshowbarker>
/me checks the spec

[03:31:27.0034] <sideshowbarker>
hmm yeah `keygen` is not in the spec any longer, I see

[03:31:40.0016] <sideshowbarker>
/me now reads https://bugzilla.mozilla.org/show_bug.cgi?id=1775477

[03:32:53.0371] <emilio>
Yeah, all browsers agree on it being an HTMLUnknownElement _except_ gecko when created from the parser, because we forgot to regenerate the C++ sources / ElementName.java :-(

[03:33:05.0379] <sideshowbarker>
heh :)

[03:33:38.0987] <sideshowbarker>
well, it’s merged now — so we’ll have proper interop for it

[03:33:50.0139] <sideshowbarker>
minor win but hey, it’s still good

[03:34:07.0747] <emilio>
yeah, fairly minor, but while I was at it seemed worth doing :)

[03:34:19.0346] <sideshowbarker>
yup

[06:35:49.0416] <zcorpan>
Hmm why is lists.whatwg.org incomplete? (Doesn't contain replies to the referenced email)

[06:35:57.0035] <zcorpan>
referenced in https://twitter.com/fmalina/status/1539963473488011264

[10:22:18.0614] <Domenic>
It was created from some static backup crawl that I believe was incomplete

[10:22:42.0364] <Domenic>
https://github.com/whatwg/whatwg.org/pull/270

[10:23:40.0181] <Domenic>
https://github.com/whatwg/meta/issues/153#issuecomment-566980200

[13:08:50.0880] <Seirdy>
I think that the discrepancy between the HTML standard's `aside` element and WAI-ARIA's `contentinfo` role warrants breaking the first rule of ARIA, but I'm just a novice so i thought i should ask first:
In articles on my website, I have section permalinks following each `<h2>` (excluding those in sections with `role="doc-preface"`, since those aren't in the TOC). I want these permalinks to look more or less the same whether you use a textual browser (e.g. lynx) or a graphical browser, and to not be radically different to screen reader users. Here's an example article (https://seirdy.one/posts/2022/06/10/cli-best-practices/).
Problem: some article extractors ("reader modes") don't handle these section permalinks well. DOM Distiller (Chromium) completely removes the headings and permalinks; Readability (Firefox, Brave), Safari reading mode, and Immersive Reader (used in Edge) include the permalinks; Trafilatura sometimes combines the headings and permalinks without any whitespace between them. Ideally, a reading-mode implementation would just remove the section permalinks but keep the headings; none of them do this.
One change that would fix all these reading-modes would be wrapping the section permalinks in an `aside` element. That seems in line with the HTML Standard (ancilliary content that a reading-mode can exclude), but doesn't seem to be in line with WAI-ARIA: I don't want to create a `contentinfo` landmark for each section permalink! I could override the `aside` elements' implicit roles with an explicit `role` attribute, but I want to be careful; I've never broken the first rule of ARIA before, so I don't know if this is the "right place" to do so.

Anyone more familiar with the standards know how I should navigate this discrepancy between the WHATWG HTML standard and WAI-ARIA?

[13:16:58.0820] <Domenic>
Permalinks don't seem like <aside>s to me. Recall that aside is a "section of the page", i.e. something that traditionally has its own headings, content, etc.

[13:18:12.0306] <Seirdy>
ah I see

[13:18:18.0316] <Seirdy>
How would you go about this?

[13:18:36.0380] <Seirdy>
I've seen many different ways of doing this but I'm not particularly fond of them

[13:18:59.0448] <Seirdy>
because they make textual-browsers, graphical-browsers, and screen readers see content that is too different (IMO)

[13:20:08.0705] <Seirdy>
my current solution (no `<aside>`, just a hyperlink with an `aria-labelledby` that includes the visible link name and the section name) actuall works really well, in that all three aforementioned audiences perceive something almost identical and can navigate it pretty easily. That is, until you use literally any reading-mode implementation (hence the problem).

[13:21:20.0754] <Seirdy>
* my current solution (no `<aside>`, just a hyperlink with an aria-label that includes the visible link name) actuall works really well, in that all three aforementioned audiences see something almost identical and can navigate it pretty easily. That is, until you use literally any reading-mode implementation (hence the problem).

[13:22:24.0956] <Seirdy>
* How would you mark this up?

[13:23:19.0803] <Seirdy>
* because they make textual-browsers, graphical-browsers, and screen readers show content that is too different (IMO)

[13:23:35.0078] <Seirdy>
* my current solution (no `<aside>`, just a hyperlink with an aria-label that includes the visible link name) actuall works really well, in that all three aforementioned audiences perceive something almost identical and can navigate it pretty easily. That is, until you use literally any reading-mode implementation (hence the problem).

[13:24:49.0992] <Seirdy>
* my current solution (no `<aside>`, just a hyperlink with an `aria-labelledby` that includes the visible link name and the section name) actuall works really well, in that all three aforementioned audiences perceive something almost identical and can navigate it pretty easily. That is, until you use literally any reading-mode implementation (hence the problem).

[13:27:13.0095] <Domenic>
I don't know how I would mark it up because I don't know the exact heuristics article extractors use to get rid of elements

[13:29:14.0488] <Domenic>
https://github.com/mozilla/readability/blob/master/Readability.js#L121 gives some potential clues... like if you put class="utility" maybe they will go away? In Readability at least?

[13:29:33.0033] <Seirdy>
hmm that's a last resort i guess

[13:30:43.0517] <Seirdy>
/me likes the perhaps-unrealistic ideal of making a website that sticks only to exisitng standards and doesn't have any implementation-specific quirks.

[13:30:57.0760] <Domenic>
But these tools you're trying to cater for don't have any standards governing them

[13:30:57.0770] <Seirdy>
(thi is  a personal site after all heh)

[13:31:12.0886] <Seirdy>
well, they sort of do

[13:31:18.0886] <Seirdy>
readability and apple reader mode at least

[13:31:33.0032] <Domenic>
Oh, I wasn't aware? Where's the spec for them?

[13:32:15.0131] <Seirdy>
they use microdata with schema.org vocab to identify articles (when that markup exists), semantic html elements like `aside` and `article`, Dublin Core and more microdata for metadata extraction, etc.

[13:32:22.0978] <Seirdy>
so i guess it's not a standard for their behavior

[13:32:32.0510] <Seirdy>
more like standards they observe

[13:32:55.0635] <Seirdy>
DOM Distiller tries to be "smart" and also removes elements with high link-density

[13:33:03.0686] <Seirdy>
that's not a standard behavior

[13:33:08.0770] <Domenic>
Yeah, but the core behavior of stripping elements has no standard, so to the extent you want to interact with that, you're gonna have to use something nonstandard.

[13:33:43.0013] <Seirdy>
yeah i mean they identify the meanings of elements when extracting content, and they perform that identification according to existing standards

[13:33:57.0934] <Seirdy>
when they render that extracted content, that's nonstandard ofc

[13:34:33.0207] <Domenic>
It's not clear to me whether they perform the extraction before or after filtering out elements, but I take your meaning

[13:35:17.0501] <Seirdy>
honestly im probably overthinking this, but it's fun. i just find the whole concept of article-distillation so interesting :3

[13:36:32.0651] <Seirdy>
the way you gotta balance the need to observe standards (identify elements: what is an article and what isn't?) but still break them (remove parts of a page) presents a really fascinating problem.

[13:36:45.0295] <Domenic>
Yeah, I find it pretty interesting too. It's unfortunately at that intersection of technologies like "semantic web" where, if everyone did perfect markup + maybe we made a couple more specs, we could have a nice result. But 95% of people won't do perfect markup so heuristics rule.

[13:36:58.0348] <Seirdy>
well it's a combination

[13:37:24.0446] <Seirdy>
for instance, they use hueristics to determine _if_ reader mode should even be presented on a page

[13:37:36.0164] <Seirdy>
those hueristics are gerated by a ML program

[13:37:38.0758] <Domenic>
E.g. reader mode won't even trigger in Firefox for any WHATWG specs because they are at the root of their domain and Firefox has a heuristic to not allow reader mode on root domains.

[13:37:50.0294] <Seirdy>
(Fathom on mozilla's side; check out #fathom:mozilla.org)

[13:39:26.0814] <Seirdy>
but when it comes to the actual article-distillation process on a page that has decent markup, Readability is quite predictable. It observes existing standards quite well.

[13:39:28.0275] <Domenic>
I wonder if an ML model would do better at article extraction than existing code like readability. If you had enough training data... but I do not know how much is "enough"

[13:39:41.0444] <Domenic>
I don't find https://github.com/mozilla/readability/blob/master/Readability.js#L2062-L2142 very predictable tbh :)

[13:40:04.0684] <Domenic>
`(!isList && headingDensity < 0.9 && contentLength < 25 && (img === 0 || img > 2) && !this._hasAncestorTag(node, "figure"))` as just one line...

[13:41:40.0327] <Seirdy>
Domenic: DOM Distiller uses a weird-ass hybrid approach that combines multiple different extraction algos and uses hueristics to determine which algo to use. The algos were mostly written by humans, but they used the outputs of some machine learning programs as reference. And DOM-Distiller is a Java program transpiled to JavaScript.

[13:41:54.0067] <Seirdy>
all that complexity screams "Google project" to me, heh

[13:42:43.0707] <Seirdy>
ironically the article-extractor made by an adtech company (Google) is the most aggressive at removing sponsored content (link density hueristics give false positives).

[13:43:46.0827] <Seirdy>
also the version built into chromium is only available via chrome://flags, and the flag expired in m105 so 🤷

[13:45:14.0929] <Seirdy>
> <@domenicdenicola:matrix.org> I don't find https://github.com/mozilla/readability/blob/master/Readability.js#L2062-L2142 very predictable tbh :)

oh true

[13:46:27.0985] <Seirdy>
would be nice if reading-modes had a "simple" and "aggressive" mode. where the simple mode errs towards "trust the page" and strictly observes standards when identifying elements, while the "agressive" mode assumes the page has bad or deceitful markup to sneak in some ads and whatnot.

[13:46:40.0441] <Seirdy>
and users could switch between them


2022-06-24
[19:16:23.0021] <raphaellouis>
Hi all!

[19:16:59.0616] <raphaellouis>
delete my account here: https://discourse.wicg.io/t/delete-my-account/5920

[21:11:04.0178] <raphaellouis>
How can I delete my wicg account?

[23:28:16.0518] <Yutaka Hirano>
@annevk I think I've addressed questions & concerns raised at https://github.com/whatwg/fetch/issues/1438. Could you take a look at https://github.com/whatwg/fetch/pull/1457 and https://github.com/web-platform-tests/wpt/pull/34496?

[06:49:56.0309] <유신>
Hello. Is it correct to ask a question here about HTML? If that's true, I have a question for you.

I'm curious as to the rationale for including the <h2> tag inside the <li> tag.

Thanks in advance for your reply.


2022-06-26
[00:43:18.0410] <Noam Rosenthal>
It's a sub-heading, having a list of sections each with its own subheading kind of makes sense to me as one of the rationales:

```
<h1>Page Heading</h1>
1. <h2>Section Heading\</h2>
    <p>Stuff</p>


2. <h2>Other section heading</h2>
 <p>Stuff</p>
```

Not sure about the history etc.

[00:43:36.0897] <Noam Rosenthal>
 * It's a sub-heading, having a list of sections each with its own subheading kind of makes sense to me as one of the rationales:

```
\<h1>Page Heading\</h1>
1. \<h2>Section Heading\</h2>
    \<p>Stuff\</p>


2. \<h2>Other section heading\</h2>
 \<p>Stuff\</p>
```
Not sure about the history etc.

[00:43:53.0702] <Noam Rosenthal>
 * It's a sub-heading, having a list of sections each with its own subheading kind of makes sense to me as one of the rationales:

```
<h1>Page Heading</h1>
1. <h2>Section Heading\</h2>
    <p>Stuff</p>


2. <h2>Other section heading</h2>
 <p>Stuff</p>
```

Not sure about the history etc.

[00:46:33.0060] <유신>
> <@noamr:matrix.org> It's a sub-heading, having a list of sections each with its own subheading kind of makes sense to me as one of the rationales:
> 
> ```
> <h1>Page Heading</h1>
> 1. <h2>Section Heading\</h2>
>     <p>Stuff</p>
> 
> 
> 2. <h2>Other section heading</h2>
>  <p>Stuff</p>
> ```
> 
> Not sure about the history etc.

Thank you for answer.

[00:51:20.0154] <유신>
Noam Rosenthal: If it's not uncomfortable, can you answer one more question?

[00:51:57.0028] <Noam Rosenthal>
> <@ryushin0:matrix.org> Noam Rosenthal: If it's not uncomfortable, can you answer one more question?

Just ask, if I won't answer maybe someone else would

[00:52:48.0223] <유신>
    
```
<h1>1</h1>
    <section>
        <h2>2</h2>
        <ol>
            <li>
                <h3>3</h3>
            </li>
        </ol>
    </section>
```

[00:52:55.0645] <유신>
I was actually curious about this.
There's no grammatical error in this structure. And semantically correct?

[00:53:43.0512] <유신>
My colleague who works with me told me that the heading level cannot be used in the <li> tag, so I wonder if it is correct.

[00:53:53.0449] <Noam Rosenthal>
> <@ryushin0:matrix.org> I was actually curious about this.
> There's no grammatical error in this structure. And semantically correct?

"semantically correct" is not something you can answer based on this, it depends on the content.

[00:55:14.0581] <유신>
So only in terms of grammar?

[00:55:17.0501] <Noam Rosenthal>
it *can* be semantically correct if organizing the sections and heading in this way would also make sense *for your content* in a screen reader, automatic table-of-contents generator etc.

[00:57:24.0184] <Noam Rosenthal>
e.g. if you're using <h3> as a way to affect the style but it doesn't represent an actual heading, then it's not "semantically correct", as that H3 would appear in your table of contents as a heading (as one example)

[00:57:38.0685] <유신>
My colleage called it a grammatical error that <h2> or <h3> is contained in <li>. But I didn't think it was an error, and I couldn't detect any errors in the actual validation.

[01:03:24.0410] <Noam Rosenthal>
> <@ryushin0:matrix.org> My colleage called it a grammatical error that <h2> or <h3> is contained in <li>. But I didn't think it was an error, and I couldn't detect any errors in the actual validation.

AFAIK it's not a grammatical error and semantical errors are more about the content.

[01:04:29.0619] <유신>
Noam Rosenthal: Thank you for your kind reply:)


2022-06-27
[19:02:39.0517] <dlrobertson>
I've got another newbie question: https://w3c.github.io/FileAPI/#dfn-slice indicates that the result of `blob.slice` with no `contentType` should have the content type set to `""`. 1) Am I reading this right? 2) A simple wpt test indicates that no browser does this, so is this worth a wpt test or spec issue?

[21:27:42.0067] <Domenic>
> <@dlrobertson:matrix.org> I've got another newbie question: https://w3c.github.io/FileAPI/#dfn-slice indicates that the result of `blob.slice` with no `contentType` should have the content type set to `""`. 1) Am I reading this right? 2) A simple wpt test indicates that no browser does this, so is this worth a wpt test or spec issue?

That's my reading as well. Worth a spec issue.

[23:04:01.0993] <Yutaka Hirano>
annevk: I suspect I failed to mention last Friday, so let repeat the same message. Sorry if you've already seen the message.

[23:04:14.0096] <Yutaka Hirano>
annevk:  I think I've addressed questions & concerns raised at https://github.com/whatwg/fetch/issues/1438. Could you take a look at https://github.com/whatwg/fetch/pull/1457 and https://github.com/web-platform-tests/wpt/pull/34496?

[00:19:44.0671] <annevk>
Yutaka Hirano: hey, I'm not really working until at least mid July or so

[00:20:13.0431] <annevk>
Yutaka Hirano: if it's urgent I can maybe make some time, but perhaps someone else can review first?

[00:43:16.0585] <annevk>
And come to think of it, as I wrote on my blog it might really take until September or so when I will have more regular availability

[03:18:27.0105] <Yutaka Hirano>
annevk: thanks, I see. I will probably not be able to spend much time on this on Q4 and beyond, so I'm in a bit of hurry, but I understand your situation. Let's hope we won't need big changes in the future.

[03:49:20.0729] <Yutaka Hirano>
 * annevk: I suspect I failed to mention last Friday, so let me repeat the same message. Sorry if you've already seen the message.

[06:17:24.0364] <dlrobertson>
Domenic: thanks!

[06:22:41.0226] <annevk>
Yutaka Hirano: I'll have a look tomorrow morning; hopefully Luca Casonato can have a look as well (if he hasn't already)

[06:23:03.0038] <Yutaka Hirano>
annevk: Thank you very much!


2022-06-28
[02:27:50.0723] <smaug>
Content-type parsing is nicely inconsistent in all the implementations.

[02:27:57.0506] <smaug>
And even wpt tests look buggy

[08:48:52.0267] <zcorpan>
Yoav Weiss: thanks for the review for sizes=auto! What do you think about the association concept? Storing a pointer on the attribute also feels weird because the attribute can be omitted. Storing it on the `<source>` element still seems wrong because it could apply to multiple `<img>`s e.g. `<picture><source srcset='x 50w, y 100w' sizes=auto><img width=500><img width=1000></picture>`. Maybe the parsed sizes result should be stored on the `img`?

[08:58:36.0791] <zcorpan>
I'll ponder on it and come up with something tomorrow :)

[12:23:37.0091] <smaug>
annevk or anyone familiar with the setup for https://searchfox.org/mozilla-central/source/testing/web-platform/tests/mimesniff/mime-types/resources/generated-mime-types.json  and tests around it

[12:23:52.0914] <smaug>
looks like the tests are expecting that blob.type doesn't modify the value

[12:24:38.0904] <smaug>
but https://w3c.github.io/FileAPI/#dfn-type at least says that it should be always lower case

[12:24:55.0976] <smaug>
and hints also that validation is done too

[12:25:27.0061] <smaug>
webkit seems to have currently rather reasonable behavior

[12:26:27.0740] <smaug>
But I'm not sure how to modify generated-mime-types.json 

[12:28:37.0420] <smaug>
https://wpt.fyi/results/xhr/overridemimetype-blob.html?label=master&label=experimental&aligned has results for mime-types.json and https://wpt.fyi/results/mimesniff/mime-types/parsing.any.html?label=experimental&label=master&aligned also for generated-mime-types.json


2022-06-29
[21:58:21.0328] <GPHemsley>
smaug: That file is generated by a Python script: https://github.com/web-platform-tests/wpt/blob/master/mimesniff/mime-types/resources/generated-mime-types.py

[22:17:05.0150] <Domenic>
> <@smaug:mozilla.org> but https://w3c.github.io/FileAPI/#dfn-type at least says that it should be always lower case

I think that is kind of under debate, in https://github.com/w3c/FileAPI/issues/43 . But having the tests not match the spec is indeed not great.

[23:50:45.0062] <zcorpan>
hober: nice to see https://github.com/WebKit/standards-positions ! What should we do with Warnocked requests for position emails to webkit-dev? Open an issue or assume lack of interest?

[23:55:08.0243] <sideshowbarker>
also nice to see that the WebKit project has migrated stuff out of its legacy wiki and into https://github.com/WebKit/WebKit/wiki/

[03:35:21.0412] <zcorpan>
What's the chromium equivalent of standards-positions? Email to blink-dev?

[04:00:51.0680] <Domenic>
That's probably the best... or ping someone on the appropriate spec issue.

[08:54:39.0102] <smaug>
Hmm, Chrome says false here https://mozilla.pettay.fi/moztests/data_url_isSecureContext.html 

[08:56:37.0729] <smaug>
the spec says "environment's top-level creation URL is "Potentially Trustworthy", then return true."

[08:56:43.0152] <smaug>
top level is https://...

[09:03:26.0382] <smaug>
Mike West: you might know something about ^

[09:23:57.0163] <smaug>
I guess Chrome's implementation wasn't ever updated after https://github.com/w3c/webappsec-secure-contexts/issues/69#issuecomment-585780599 

[09:23:57.0977] <smaug>
https://wpt.fyi/results/secure-contexts/basic-popup-and-iframe-tests.https.html?label=experimental&label=master&aligned

[09:59:45.0724] <zcorpan>
Who are planning to attend TPAC in person?

[10:39:17.0116] <zcorpan>
Also will there be an HTML meeting at TPAC?

[15:02:54.0369] <sideshowbarker>
> <@zcorpan_:matrix.org> Also will there be an HTML meeting at TPAC?

There’s no HTML meeting on the schedule. We might still be able to add one if we want


2022-06-30
[00:50:18.0994] <zcorpan>
sideshowbarker: ok. I was thinking we could do a "group update" to present what has happened in HTML in the past year (or since we last gave an update at tpac). maybe a meeting could also be useful, maybe other WGs want to discuss things with us in person

[01:00:59.0579] <sideshowbarker>
zcorpan: I’m certain we could at least do something on Wednesday the 14th — that’s the normal “breakout sessions”/unconference day

[01:01:32.0778] <sideshowbarker>
…which sessions I guess would be 50 minutes each

[01:01:59.0894] <sideshowbarker>
but if we reckon we want more time than that, we might still be able to get something scheduled

[01:04:10.0636] <sideshowbarker>
the scheduling this year is done in half-days — 4 hour sessions rather than 8 hours or whatever it normally is — I guess in order to accommodate it being a “hybrid” thing where we expect many participants will be taking part remotely (and experience shows it’s impractical to expect hybrid meetings to actually work effectively if they are any longer than 4 hours or so max)

[01:46:20.0115] <zcorpan>
sideshowbarker: ok, I can open an issue to see if there's interest

[01:58:49.0910] <zcorpan>
https://github.com/whatwg/html/issues/8056

[02:01:27.0378] <zcorpan>
Rick Byers: what's the status for https://github.com/w3c/css-houdini-drafts/blob/main/scroll-customization-api/explainer.md ?

[05:24:25.0264] <Ms2ger 💉💉>
annevk: https://github.com/whatwg/participant-data/blob/main/entities.json#L68 might need an update

[06:35:46.0938] <zcorpan>
hsivonen (away from Matrix until July 11): sideshowbarker : hmm, https://validator.github.io/validator/ seems to be stuck in a reload loop