2024-08-01
[03:46:26.0361] <smaug>
Anyone with Safari? I wonder if it has changed behavior regarding https://github.com/whatwg/html/issues/2429 

[04:18:24.0322] <arai>
I get `log: 195` on Safari Technology Preview (Release 199 (Safari 18.0, WebKit 19619.1.22.5)) and Safari (17.5 (19618.2.12.11.6))


2024-08-02
[20:37:24.0443] <Ben Ho>
Following up on this, for my usable Dialog component, I eventually added a custom function to loop back to first focusable element and visa versa to encapsulate the tabbing. 

I have seen some concerns about accessibility where it is trapping users to make a decision when they want to move to address bar or other browser controls but it works for me because my Dialog always has escape method that can not be blocked. 

[20:37:33.0300] <Ben Ho>
 * Following up on this, for my re-usable Dialog component, I eventually added a custom function to loop back to first focusable element and visa versa to encapsulate the tabbing. 

I have seen some concerns about accessibility where it is trapping users to make a decision when they want to move to address bar or other browser controls but it works for me because my Dialog always has escape method that can not be blocked. 

[02:31:39.0972] <Yoav Weiss>
Not with Safari but I've been poking around this in webkit https://github.com/WebKit/WebKit/pull/31055

[02:31:57.0754] <Yoav Weiss>
My impression is that all image loading is sync

[02:32:05.0796] <Yoav Weiss>
(I'm trying to fix that)

[08:20:33.0882] <smaug>
But the spec issue hints that some stuff in webkit is async


2024-08-04
[21:15:25.0654] <schickb>
Adam Rice: Any more thought on the stream close question above? Why is close() alone not sufficient? When constructing a ReadableStream  it is unexpected that you need to call controller.byobRequest.respond(0) after close() when no data is enqueued or risk causing the stream reader to hang.


2024-08-05
[04:10:11.0640] <Adam Rice>
> <@schickb:matrix.org> Adam Rice: Any more thought on the stream close question above? Why is close() alone not sufficient? When constructing a ReadableStream  it is unexpected that you need to call controller.byobRequest.respond(0) after close() when no data is enqueued or risk causing the stream reader to hang.

Sorry, I don't remember what the reason was, and I haven't been able to find the original discussion.


2024-08-06
[22:19:38.0537] <Domenic>
> <@schickb:matrix.org> Adam Rice: Any more thought on the stream close question above? Why is close() alone not sufficient? When constructing a ReadableStream  it is unexpected that you need to call controller.byobRequest.respond(0) after close() when no data is enqueued or risk causing the stream reader to hang.

I suggest filing an issue on whatwg/streams. Async discussion will likely get more participants and someone might be able to help. And if there is no good answer we can use the issue to track fixing it.

(I myself have not really been able to follow the issue across the multiple chat messages which often come in while I'm afk :))

[07:30:59.0090] <Jake Archibald>
https://dom.spec.whatwg.org/#dom-event-preventdefault - this mentions that calling `preventDefault` can have no effect. Does that mean `event.defaultPrevented` will remain false?

[07:31:42.0378] <Jake Archibald>
Or does it just mean that the dispatcher of the event may do nothing with that information

[11:30:00.0719] <TabAtkins>
I think the latter.

[15:56:57.0203] <gentlgeek>
Hi everyone! 👋 I’m new here and excited to join the conversation. I’m keen to learn more about HTML and related topics, and I’m looking forward to diving into some great discussions with all of you. If you have any tips or resources for someone just getting started, I’d love to hear them! Thanks for having me!




2024-08-07
[11:08:55.0756] <schickb>
Domenic: Adam Rice Create this ticket https://github.com/whatwg/streams/issues/1321

[11:09:05.0245] <schickb>
 * Domenic: Adam Rice Created this ticket https://github.com/whatwg/streams/issues/1321


2024-08-08
[04:58:46.0540] <zcorpan>
> <@gentlgeek:matrix.org> Hi everyone! 👋 I’m new here and excited to join the conversation. I’m keen to learn more about HTML and related topics, and I’m looking forward to diving into some great discussions with all of you. If you have any tips or resources for someone just getting started, I’d love to hear them! Thanks for having me!

Welcome! Maybe https://wpc.guide/ is of interest

[05:41:30.0933] <gentlgeek>
I have gone through the material and I think it will be of great benefit. There is a lot to learn, thankyou so much, I really appreciate your effort 👍️.


2024-08-09
[02:28:42.0406] <Kaiido>
> <@jakea:matrix.org> https://dom.spec.whatwg.org/#dom-event-preventdefault - this mentions that calling `preventDefault` can have no effect. Does that mean `event.defaultPrevented` will remain false?

In case the cancelable attribute is falsy, or if the passive listener flag is set, it indeed does nothing.
https://dom.spec.whatwg.org/#set-the-canceled-flag

[04:21:34.0355] <hsivonen>
annevk: Regarding https://github.com/whatwg/url/issues/815#issuecomment-2275009761 , do you have a recollection of why the ASCII asterisk and double quote are allowed in the domain name by the URL Standard?

[12:06:56.0833] <Meghan Denny>
spam <https://github.com/whatwg/url/issues/830>


2024-08-11
[04:01:38.0249] <Gasim Gasimzada>
Hello, I have recently been working on trying to implement `console.table` for the LadyBird browser and I have came across the `console` WHATWG repo. Unfortunately, there was no algorithm defined for `console.table`; so, I decided to investigate how Chromium and Firefox implement it and tried to figure out the algorithm. I created a pull request to https://github.com/whatwg/console/pull/237 that tries to describe the algorithm. Please let me know of your comments and concerns about this since this is my first ever contribution to Whatwg.

[10:41:37.0255] <Herman official>
Hallo


2024-08-13
[02:20:16.0971] <annevk>
I just found out that implementations use a decimal library to implement `<input type=number>` while HTML says nothing of the sort. Didn't realize that when initially reporting https://github.com/tc39/proposal-decimal/issues/80. Does anyone know more about this?

[13:30:46.0476] <one_>
Hi

[13:31:02.0646] <one_>
Hi


2024-08-14
[18:18:38.0457] <Domenic>
> <@annevk:matrix.org> I just found out that implementations use a decimal library to implement `<input type=number>` while HTML says nothing of the sort. Didn't realize that when initially reporting https://github.com/tc39/proposal-decimal/issues/80. Does anyone know more about this?

We had to do this in jsdom to pass web platform tests.

[10:43:33.0737] <annevk>
So maybe someone wrote some non-floating-point-compliant WPTs and everyone just decided to copy in a decimal lib? lol

[10:53:14.0539] <Sam Sneddon [:gsnedders]>
I mean if the spec doesn't define behaviour, and everyone thinks it's the right behaviour from a UX point-of-view, then making the tests pass is unsurprising. Or people blindly following the tests, unless it goes against the spec. Or just completely blindly following the tests.


2024-08-15
[18:05:17.0595] <Domenic>
I admit not reading the spec closely when we implemented in jsdom but I kind of assumed the spec was based on mathematical infinite-precision numbers.

[00:14:49.0152] <annevk>
I assumed that for a long time too, but looking at it today it just references floating-point math?

[01:16:33.0469] <Domenic>
I'm not sure, I think it only references floating-point for the parsing/serialization?

[01:17:06.0484] <Domenic>
The tests are for stepUp() etc. IIRC which says "Let value be the result of adding delta to value."

[02:22:21.0916] <annevk>
Ah, I guess that's fair.

[02:22:53.0300] <annevk>
Still, some additional clarity on this wouldn't hurt. Perhaps once we sort out numbers in Infra.

[05:11:37.0097] <sideshowbarker>
> <@annevk:matrix.org> So maybe someone wrote some non-floating-point-compliant WPTs and everyone just decided to copy in a decimal lib? lol

Are the relevant tests https://wpt.fyi/results/html/semantics/forms/the-input-element/number.html? or somewhere else?

[05:14:20.0827] <sideshowbarker>
hmm, I guess it’s probably not those, because Ladybird passes most of those

[05:17:34.0613] <sideshowbarker>
Anyway, I believe Ladybird implements the core `<input type=number>` requirements per-spec — that, is Ladybird uses a double parser. And so, if the WPTs don’t match the spec requirements, then Ladybird should be failing those

[06:34:26.0878] <Gasim Gasimzada>
> <@gasim:matrix.org> Hello, I have recently been working on trying to implement `console.table` for the LadyBird browser and I have came across the `console` WHATWG repo. Unfortunately, there was no algorithm defined for `console.table`; so, I decided to investigate how Chromium and Firefox implement it and tried to figure out the algorithm. I created a pull request to https://github.com/whatwg/console/pull/237 that tries to describe the algorithm. Please let me know of your comments and concerns about this since this is my first ever contribution to Whatwg.

annevk janbrasna Can I add you as reviewers for this PR?

[08:15:58.0144] <annevk>
Gasim Gasimzada: I think Dominic Farolino or one of the other editors is prolly better suited to review, maybe Domenic but I suspect he's very busy; if all that fails I could maybe take a look, but I'd have to ramp up on the whole subject so I'd rather not

[08:46:45.0555] <Dominic Farolino>
Ah, yeah I've been notified about the PR, just haven't had time to look at it yet. Coming back from vacation this week, so still warming up

[08:55:18.0691] <annevk>
Samesies. Been going pretty well thus far, but I'm suspecting it's because a lot of other people are away which makes it easier.

[09:14:50.0694] <Dominic Farolino>
zcorpan: I want to confirm something about https://github.com/web-platform-tests/wpt/blob/master/html/semantics/embedded-content/the-iframe-element/iframe-loading-lazy-reload-navigation-reload.html#L9-L10. Is this statement true because reloads don't go through the "normal" #navigate path, and it is only the normal #navigate path that clears the lazyload resumption steps? (https://html.spec.whatwg.org/C#beginning-navigation:lazy-load-resumption-steps). Is that the idea?

[09:16:16.0197] <Gasim Gasimzada>
> <@domfarolino:matrix.org> Ah, yeah I've been notified about the PR, just haven't had time to look at it yet. Coming back from vacation this week, so still warming up

Thanks! No rush! Just wanted to know who to set in the Checklist for "At least two implementers are interested (and none opposed):"

[09:21:13.0713] <annevk>
Gasim Gasimzada: ah, that part you want to lobby implementers for. But I if it's documenting what's already implemented you don't strictly need that.

[09:21:39.0582] <Gasim Gasimzada>
> <@annevk:matrix.org> Gasim Gasimzada: ah, that part you want to lobby implementers for. But I if it's documenting what's already implemented you don't strictly need that.

Makes sense! Thank you.


2024-08-16
[21:39:46.0528] <Domenic>
zcorpan: should have CCed you on the email, but FYI in https://groups.google.com/a/chromium.org/g/blink-dev/c/UquTxWTNON0 we're discussing UA styles for <meter> + appearance: none, which might be interesting given your past work in the area.

[01:01:27.0178] <zcorpan>
> <@domfarolino:matrix.org> zcorpan: I want to confirm something about https://github.com/web-platform-tests/wpt/blob/master/html/semantics/embedded-content/the-iframe-element/iframe-loading-lazy-reload-navigation-reload.html#L9-L10. Is this statement true because reloads don't go through the "normal" #navigate path, and it is only the normal #navigate path that clears the lazyload resumption steps? (https://html.spec.whatwg.org/C#beginning-navigation:lazy-load-resumption-steps). Is that the idea?

Right. https://html.spec.whatwg.org/#reload doesn't call "navigate"

[01:03:14.0320] <zcorpan>
> <@domenicdenicola:matrix.org> zcorpan: should have CCed you on the email, but FYI in https://groups.google.com/a/chromium.org/g/blink-dev/c/UquTxWTNON0 we're discussing UA styles for <meter> + appearance: none, which might be interesting given your past work in the area.

Thanks

[01:06:47.0183] <zcorpan>
Domenic: iirc I left primitive style for meter undefined because there wasn't consensus, but it seems now we might have consensus

[04:19:04.0780] <jub0bs>
I'm told that AWS API Gateway exhibits a weird behaviour: it splits a list-based field (`Access-Control-Request-Headers`) into multiple field lines. Example:
```http
Access-Control-Request-Headers: bar,baz,foo
```
becomes
```http
A
```
which I believe is non-compliant

[04:19:17.0400] <jub0bs>
 * I'm told that AWS API Gateway exhibits a weird behaviour: it splits a list-based field (`Access-Control-Request-Headers`) into multiple field lines. Example:

```http
Access-Control-Request-Headers: bar,baz,foo
```

becomes

```http
Access-Control-Request-Headers: bar,baz,foo
```

which I believe is non-compliant

[04:20:47.0746] <jub0bs>
 * I'm told that AWS API Gateway exhibits a weird behaviour: it splits a list-based field (`Access-Control-Request-Headers`) into multiple field lines. Example:

```http
Access-Control-Request-Headers: bar,baz,foo
```

becomes

```http
Access-Control-Request-Headers: bar
Access-Control-Request-Headers: baz
Access-Control-Request-Headers: foo
```

which I believe is non-compliant. I haven't found anything in RFC 9110 that describes this behaviour (only the reverse, i.e. merging multiple field lines of the same name into one). Am I missing something? Is such a proxy behaviour allowed?

[04:21:37.0424] <jub0bs>
 * I'm told that AWS API Gateway exhibits a weird behaviour: it splits a list-based field (`Access-Control-Request-Headers`) into multiple field lines. Example:

```http
Access-Control-Request-Headers: bar,baz,foo
```

becomes

```http
Access-Control-Request-Headers: bar
Access-Control-Request-Headers: baz
Access-Control-Request-Headers: foo
```

which I believe is non-compliant. I haven't found anything in RFC 9110 that describes this "splitting" behaviour (only the reverse, i.e. merging multiple field lines of the same name into one). Am I missing something? Is such a proxy behaviour allowed?

[04:22:33.0021] <jub0bs>
 * I'm told that AWS API Gateway exhibits a weird behaviour: it splits a list-based field (`Access-Control-Request-Headers`) into multiple field lines. Example:

```http
Access-Control-Request-Headers: bar,baz,foo
```

becomes

```http
Access-Control-Request-Headers: bar
Access-Control-Request-Headers: baz
Access-Control-Request-Headers: foo
```

which I believe is non-compliant. I haven't found anything in RFC 9110 that describes this "splitting" behaviour (only the reverse, i.e. merging multiple field lines of the same name into one). Am I missing something? Is a proxy allowed to split list-based fields like this?

[04:23:08.0226] <jub0bs>
 * I'm told that AWS API Gateway exhibits a weird behaviour: it allegedly (I haven't verified this yet) splits a list-based field (`Access-Control-Request-Headers`) into multiple field lines. Example:

```http
Access-Control-Request-Headers: bar,baz,foo
```

becomes

```http
Access-Control-Request-Headers: bar
Access-Control-Request-Headers: baz
Access-Control-Request-Headers: foo
```

which I believe is non-compliant. I haven't found anything in RFC 9110 that describes this "splitting" behaviour (only the reverse, i.e. merging multiple field lines of the same name into one). Am I missing something? Is a proxy allowed to split list-based fields like this?

[07:30:20.0531] <Richard Gibson>
it's allowed; see https://www.rfc-editor.org/rfc/rfc9110#section-5.3 (emphasis mine):
> a sender MUST NOT generate multiple field lines with the same name in a message (whether in the headers or trailers) or append a field line when a field line of the same name already exists in the message, **_unless_ that field's definition allows multiple field line values to be recombined as a comma-separated list** (i.e., at least one alternative of the field's definition allows a comma-separated list, **such as an ABNF rule of #(values) defined in [Section 5.6.1](https://www.rfc-editor.org/rfc/rfc9110#abnf.extension)**).

[Section 5.6.1](https://www.rfc-editor.org/rfc/rfc9110#section-5.6.1) defines "_a #rule extension to the ABNF rules of [RFC5234](https://www.rfc-editor.org/rfc/rfc9110#RFC5234)… for defining comma-delimited lists of elements… and optional whitespace_".

[`Access-Control-Request-Headers` is registered](https://www.iana.org/assignments/http-fields/http-fields.xhtml#field-names) with reference to WHATWG Fetch, which [describes its values](https://fetch.spec.whatwg.org/#http-new-header-syntax) as ABNF `1#field-name`, where ["ABNF" explicitly includes HTTP `#`](https://fetch.spec.whatwg.org/#infrastructure).

[09:22:33.0943] <hsivonen>
annevk: TIL: https://www.ietf.org/archive/id/draft-gulbrandsen-smtputf8-nice-addresses-00.html

[09:23:09.0508] <hsivonen>
> <@hsivonen:mozilla.org> annevk: TIL: https://www.ietf.org/archive/id/draft-gulbrandsen-smtputf8-nice-addresses-00.html

(Not particularly relevant to what HTML forms need to support, but there's a normative reference to the BNF currently in HTML!)

[09:27:40.0880] <annevk>
I guess we should email the authors if we manage to make progress on `<input type=email>` soon.

[12:03:04.0281] <janbrasna>
At the same time it won’t hurt having someone from the existing implementations check this retroactive speccing is aligned with how they’ve been understanding it for what’s shipped in the first place.

[12:05:42.0059] <janbrasna>
But I see you’re having such conversations already in both the spec PR and your implementation PR so let’s see where that leads you;) 


2024-08-17
[11:03:56.0090] <jub0bs>
> <@gibson042:matrix.org> it's allowed; see https://www.rfc-editor.org/rfc/rfc9110#section-5.3 (emphasis mine):
> > a sender MUST NOT generate multiple field lines with the same name in a message (whether in the headers or trailers) or append a field line when a field line of the same name already exists in the message, **_unless_ that field's definition allows multiple field line values to be recombined as a comma-separated list** (i.e., at least one alternative of the field's definition allows a comma-separated list, **such as an ABNF rule of #(values) defined in [Section 5.6.1](https://www.rfc-editor.org/rfc/rfc9110#abnf.extension)**).
> 
> [Section 5.6.1](https://www.rfc-editor.org/rfc/rfc9110#section-5.6.1) defines "_a #rule extension to the ABNF rules of [RFC5234](https://www.rfc-editor.org/rfc/rfc9110#RFC5234)… for defining comma-delimited lists of elements… and optional whitespace_".
> 
> [`Access-Control-Request-Headers` is registered](https://www.iana.org/assignments/http-fields/http-fields.xhtml#field-names) with reference to WHATWG Fetch, which [describes its values](https://fetch.spec.whatwg.org/#http-new-header-syntax) as ABNF `1#field-name`, where ["ABNF" explicitly includes HTTP `#`](https://fetch.spec.whatwg.org/#infrastructure).

Very interesting! Thanks for the pointers.


2024-08-19
[22:40:22.0800] <annevk>
If anyone has particular topics to discuss at TPAC, we're holding another WHATUP: https://github.com/whatwg/meta/issues/326

[23:58:45.0573] <annevk>
Domenic: further thoughts on https://github.com/whatwg/html/pull/10564?

[00:06:40.0467] <Domenic>
I think our existing "(the empty string)" convention is good. I would prefer you correct the single capitalized variant you found. I think we could contemplate adding quotes to all keywords (not just in the tables, but elsewhere too) but I think that opens up a lot of questions, e.g. do we do the same for attribute names or element local names?

[00:07:06.0649] <Domenic>
I'm unclear why we're revisiting this months after Keith's original PRs settled everything on a single style.

[00:16:24.0383] <annevk>
I guess I'll do that for now, but I had missed at the time we included parenthesis here. I think that's a rather confusing notation.

[00:19:26.0233] <annevk>
(And I do think it might make sense to distinguish a node's local name from a reference to the node itself.)

[08:19:51.0202] <Jake Archibald>
Anyone know where the click behaviour on `<button disabled>` is specified?

[08:22:57.0468] <Jake Archibald>
https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#enabling-and-disabling-form-controls:-the-disabled-attribute

> A form control that is disabled must prevent any click events that are queued on the user interaction task source from being dispatched on the element.

But that doesn't seem to cover how it prevents propagation of click events dispatched on child elements

[08:25:39.0223] <annevk>
Jake Archibald: https://github.com/whatwg/html/issues/1567 is related and generally search for "activation behavior" in whatwg/html; unfortunately that's messy and nobody has taken the time to clean it up as-of-yet

[08:26:23.0345] <Jake Archibald>
Good to know I'm not missing something obvious. Thanks!


2024-08-20
[19:18:02.0683] <Domenic>
https://github.com/whatwg/html/issues/10032 is some recent dsicussion

[14:48:58.0428] <TabAtkins>
Domenic / annevk : I'm doing some refactoring in Bikeshed, and realized that, although the "whatwg" group is listed as requiring Privacy and Security sections, all WHATWG specs didn't actually trigger that check in the code, due to a case mismatch (was expecting `Group: whatwg`, but all your specs have `Group: WHATWG`). Now that I'm fixing that (as a side-effect of some other bits), almost all WHATWG specs end up triggering the warning.

[14:49:18.0802] <TabAtkins>
Do y'all want WHATWG to require privacy/security sections? I can turn it off if not.

[14:53:58.0275] <TabAtkins>
(Well, I'm turning it off for now anyway; no reason to suddenly start making specs fail unexpectedly. Let me know if you'd like me to turn it back *on*.)

[14:57:25.0029] <TabAtkins>
(it looks like the check was added back in 2015 by Mike West <https://github.com/speced/bikeshed/commit/89f5bdc7f12294f5c59890ee19d9ee5619c57a66>, I'm not sure if y'all were even aware of it)


2024-08-21
[18:01:23.0646] <Domenic>
Turning it off, at least for now, sounds good; thank you!

[00:02:36.0430] <annevk>
I'm not convinced Privacy & Security sections are a net positive. They need to be an integral part of feature design.

[00:56:39.0759] <freddy>
Not a WHATWG steering commitee member, but I think we all know that privacy/security/a11y is seldomly well-solved when done as an afterthought. So, it would be more important to have this required for all specs during design phase (as anne says, I believe?) and thus enable these checks for all new specs

[00:57:39.0373] <freddy>
(Solutionism: Maybe there's could be a tag, like "legacy-no-security-privacy-section" that could be applied to old specs _and_ do the check such that that new specs will get the warning)

[01:04:46.0085] <annevk>
No, I'm saying these sections don't help. They often lead to people making normative statements in these sections that really should be part of the processing model.

[01:09:33.0528] <Domenic>
I'm not ready to make a blanket statement that the sections don't help, but I will strongly agree that I've seen that antipattern quite often.

[01:11:23.0326] <Domenic>
I guess they feel more like explainer sections than spec sections to me. But then we get into the old discussion about how much explanatory/non-normative text is helpful in a spec.

[01:34:46.0587] <annevk>
Yeah fair. I just think that if you need these sections to get something that's good security & privacy-wise, you've likely failed. But they can be useful to add some context, e.g., https://encoding.spec.whatwg.org/#security-background

[04:59:31.0895] <annevk>
freddy: see also the somewhat painful https://github.com/whatwg/dom/issues/776 and https://github.com/whatwg/dom/issues/777 which resulted in https://dom.spec.whatwg.org/#security-and-privacy. I could see it being helpful, but I can also see it leading to people not critically thinking about it for themselves.

[05:32:49.0516] <hsivonen>
Intentional or accidental that JSON modules integration ended up with a normative reference to IETF JSON instead of using the same specification mechanisms as Fetch?

[05:35:35.0208] <annevk>
hsivonen: oh wow, that seems bogus.

[05:37:33.0031] <annevk>
I wonder if people here have a term for "hash including hash sign" and "search including question mark", as an alternative way of solving https://github.com/whatwg/url/issues/779. We could do `hasSearch` that returns a boolean, but `searchWithSyntax` (if there's a better name) that returns `?test` instead of `test` might be more convenient.

[05:39:03.0288] <annevk>
hsivonen: oh actually, I think it might be a result of where the MIME type is defined

[05:40:13.0370] <hsivonen>
I'm trying to figure out if HTML ends up allowing non-UTF-8 encodings for JSON modules...

[05:40:30.0517] <annevk>
hsivonen: because for parsing we do end up calling the same %JSON.parse% operation as far as I can tell

[05:40:59.0373] <annevk>
hsivonen: we don't, see the logic in https://html.spec.whatwg.org/#fetch-a-single-module-script

[05:41:35.0912] <annevk>
hsivonen: in particular 13.2 and then 13.9

[05:42:12.0345] <hsivonen>
> <@annevk:matrix.org> hsivonen: in particular 13.2 and then 13.9

Thanks.

[05:42:40.0369] <hsivonen>
> <@annevk:matrix.org> hsivonen: oh actually, I think it might be a result of where the MIME type is defined

It appears in HTML as a conformance requirement beyond the MIME type.

[05:43:34.0752] <annevk>
Yeah, there might also be some [JSON] copypasta. Seems reasonable to file an issue to address at one point.

[06:10:32.0630] <hsivonen>
Oh, the encoding requirements of this version of IETF JSON are more reasonable than past IETF JSON.

[06:23:27.0800] <annevk>
hsivonen: I think at some point I pushed them pretty hard with the XMLHttpRequest "precedent" and that we were not going to change our ways

[06:34:02.0407] <easrng>
It's funny that RFC8259 requires both encoding as utf-8 and escapes as utf-16

[06:37:40.0786] <annevk>
Yeah, JavaScript was developed in the 16-bits are enough for all characters in the world days. And I guess since JSON is frozen-in-time and happened before the 21-bit escapes were added to JavaScript everyone will have to learn about that legacy anew.

[10:07:44.0890] <Vuk Stefanovic>
Hi All!
I need some help on how to handle backpressure for the ReadableSide of a Transform stream.

For example I am trying to implement a replace text functionality, where I replace a string of text coming from a ReadableStream with text coming from a second Readable stream, so far I couldn't find any example for this using whatwg streams.

This is pseudo code, so for simplicity I'm pretending like the text to replace won't span chunk boundaries

```javascript
class Transformer {
  async transform(chunk, controller) {
    const foundTextIndex = chunk.indexOf('text to replace');
    
    if (foundTextIndex === -1) {
      controller.enqueue(chunk);
      return;
    }

    // Enqueue text before the part that needs to be replaced
    controller.enqueue(chunk.slice(0, foundTextIndex));
    
    // This is where we do the replacement, we enqueue the text from the second source 
    // this is the part I'm not sure on how to handle, like for example what if we are adding
    // chunks to the readable sides, but it's internal queue is full full
    for await (const chunk of streamForReplacement) {
     controller.enqueue(chunk.slice(0, foundTextIndex));
     console.log(chunk);
   }
   
    // Enqueue text after replacement
    controller.enqueue(chunk.slice(foundTextIndex + 'text to replace'.length));
  }
}
```

One thing I saw thanks to good old `chatGTP` was to use `Promise.resolve()` to wait for the next event loop tick in case the `desiredSize` was negative.

For example
```javascript
class Transformer {
  async transform(chunk, controller) {
    const foundTextIndex = chunk.indexOf('text to replace');
    
    if (foundTextIndex === -1) {
      controller.enqueue(chunk);
      return;
    }

    // Enqueue text before the part that needs to be replaced
    controller.enqueue(chunk.slice(0, foundTextIndex));
    
    // Enqueue the text from the second source with backpressure support (maybe)
    for await (const chunk of streamForReplacement) {
     while (controller.desiredSize <= 0) {
       await Promise.resolve(); // wait for next tick to check if we can enqueue more chunks
     }
     controller.enqueue(chunk.slice(0, foundTextIndex));
   }
   
    // Enqueue text after replacement
    controller.enqueue(chunk.slice(foundTextIndex));
  }
}
```

I'm not sure if doing `Promise.resolve();` is valid, as I couldn't find any example dealing with this problem, and I want to know if there are better alternatives? I would really appreciate if someone could help with this and point me in the right direction

[10:34:08.0416] <Colin Alworth>
Can’t help with the spec side of things, but await Promise.resolve() is only going to be a microtask, so as I understand it there won’t be time for other tasks (like IO, browser events) to take place

[11:11:23.0943] <Vuk Stefanovic>
> <@niloc132:delightfullyoffto.pics> Can’t help with the spec side of things, but await Promise.resolve() is only going to be a microtask, so as I understand it there won’t be time for other tasks (like IO, browser events) to take place

This will actually be running in a Node env, not browser, it's going to be running in an edge function, where I get HTLM as streams and I need to combine main page with some other fragments and return that in the response

[11:12:02.0680] <Vuk Stefanovic>
so starving the macrotask queue is not really a concern


2024-08-22
[00:10:01.0365] <annevk>
Domenic: will ask internally about `file:` URL hostnames. Is this the only `file:` URL issue Chromium is blocked on? Ideally we make one set of changes to settle it forever, but maybe that is too much to hope for?

[00:11:00.0565] <Domenic>
No, I think it's more general unease about any changes unfortunately. Adam Rice is the relevant authority I believe.

[00:24:33.0731] <Luca Casonato>
> <@annevk:matrix.org> Domenic: will ask internally about `file:` URL hostnames. Is this the only `file:` URL issue Chromium is blocked on? Ideally we make one set of changes to settle it forever, but maybe that is too much to hope for?

What are these changes? I think Node and Deno have more in the wild usage of file:// URLs than all the browsers combined, so it’d be useful to ensure that those changes would not break any of our users.

[00:59:35.0894] <annevk>
Luca Casonato: makes sense. Nothing concrete as-of-yet, but https://github.com/whatwg/url/issues/599 recently got some new comments. There's a number of other `file:` URL issues open too (identified through a label).

[01:18:25.0051] <Adam Rice>
Hayato is more knowledgeable than me but I don't think he's here. The difference in drive-letter handling is my biggest concern, but given that people start Chromium with a file name on the command-line from batch scripts any change to the mapping between file: URLs and system filenames is scary.

[02:41:39.0417] <Domenic>
Yeah, it may be the case that Chromium is just not willing to change anything and thus can't contribute very helpfully to standards discussions, so that's why in my comment I was trying to be helpful to Dan by just giving a general vibe for the ecosystem. From that perspective Node/Deno would be great voices to happy.

[02:41:44.0938] <Domenic>
 * Yeah, it may be the case that Chromium is just not willing to change anything and thus can't contribute very helpfully to standards discussions, so that's why in my comment I was trying to be helpful to Dan by just giving a general vibe for the ecosystem. From that perspective Node/Deno would be great voices to have.

[05:30:16.0463] <annevk>
Domenic: I need to do some work with JSON for Declarative Web Push and the algorithms you added to Infra are really nice. I was thinking of hand-waving converting Infra values back to JS (so I can then do dictionary conversion), but even that is covered. Thanks!

[09:38:14.0967] <annevk>
Is it possible to find out what sites registered for https://developer.chrome.com/origintrials/#/view_trial/919297273937002497?

[10:02:17.0529] <Luke Warlow>
That link just goes to the active trials tab btw

[11:01:49.0572] <annevk>
Interesting, for me it goes to "Trial for Mutation Events Deprecation Trial" in a couple of browsers at least. Anyway, that's the trial I'm interested in. :-)

[14:49:33.0047] <Panos Astithas>
annevk: unfortunately we can't share trial registration info externally. You can ask the feature owners for aggregate data that they can share.

[16:59:35.0396] <smaug>
I'd be also interested in to know  which sites do want to still use mutation events. Telemetry data has gone down a bit, but it is not zero.


2024-08-23
[23:41:36.0179] <annevk>
littledan: FWIW, serialization and deserialization of non-ECMA-262 objects is generally defined alongside the objects directly using the IDL [Serializable] annotation

[23:42:59.0581] <annevk>
Panos Astithas: that essentially makes it impossible for other browsers to act until the reverse trial is done

[23:43:35.0314] <annevk>
So maybe we shouldn't have negative tests in WPT and such yet then... Or register WPT for the reverse origin trial

[02:38:45.0902] <littledan>
> <@annevk:matrix.org> littledan: FWIW, serialization and deserialization of non-ECMA-262 objects is generally defined alongside the objects directly using the IDL [Serializable] annotation

Right thanks for the correction, not sure how I forgot that.

[04:56:25.0295] <annevk>
keithamus: just stumbled across https://github.com/whatwg/notifications/issues/17 😀

[04:57:12.0148] <keithamus>
Are you looking at all of the 10yo issues? 😆

[05:10:51.0645] <annevk>
keithamus: hah, did you file many? I was just looking at Notifications and was somewhat surprised we briefly interacted 10 years ago. But my memory generally being bad could also be an explanation.

[05:13:09.0679] <keithamus>
annevk: I don't even remember filing this issue so my memory is no better. Looking at it now I don't think I have historically filed all that many. One or two a year: https://github.com/issues?q=is%3Aissue+author%3Akeithamus+archived%3Afalse+org%3Awhatwg+sort%3Acreated-asc+

[05:15:34.0210] <annevk>
Oh wow, `<dialog>` without JavaScript is from 2018 lol

[08:58:14.0559] <annevk>
Why does Push API talk about the "plain text of the message". Surely that's the "byte sequence of the message" or some such. Vague and wrong is a great combination. Makes it hard to blame colleagues who just implement against WPT.

[09:00:01.0908] <annevk>
To be clear and fair, DOM is doing things like this too: https://github.com/whatwg/dom/commit/ad422bef2890c14c92e8d618ac372e16b808b0c5

The number of people critically reading standards and reporting what is wrong feels like low single digits. 😅

[13:22:38.0366] <Luke Warlow>
> <@annevk:matrix.org> To be clear and fair, DOM is doing things like this too: https://github.com/whatwg/dom/commit/ad422bef2890c14c92e8d618ac372e16b808b0c5
> 
> The number of people critically reading standards and reporting what is wrong feels like low single digits. 😅

I've found the ladybird model of writing exactly what the specs say is really handy for finding bits where the specs just make no sense. Just reading specs on its own I find it a struggle to contextualise what's being said in quite the same way.

[15:29:22.0942] <Panos Astithas>
annevk: I don't think Origin Trial registrations would be that useful, given that there is no guarantee that registering an origin implies control over that origin. As I said, the feature owners can collect data about feature usage (or deprecation in this case) and share that.


2024-08-25
[00:59:46.0458] <sideshowbarker>
In WPT do we not actually have any tests which check that “trailing junk” in floating-point-number values is ignored?

[01:01:38.0149] <sideshowbarker>
The only “trailing junk” test I can find is in http://wpt.live/html/semantics/forms/the-input-element/number.html — which is testing _valid_ floating-point number values as defined at https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-floating-point-number — and in that case, the spec requires the trailing junk to not be ignored.

[01:04:42.0217] <sideshowbarker>
But otherwise per https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#rules-for-parsing-floating-point-number-values, for values that are parsed as floating-point numbers (which may not necessarily be “valid” ones), the spec requires any trailing junk in the input string to be ignored when parsing it into a number.

[01:05:37.0828] <sideshowbarker>
And that’s the case where it doesn’t seem like we have any tests in WPT to check that implementations do actually ignore any trailing junk


2024-08-26
[19:36:36.0312] <sideshowbarker>
Question for any and all: When you want to copy the text of a particular algorithm from a spec and preserve the step numbers, what mechanism do you use?

I mean specifically, how do you get around the problem that if you just select the text from the HTML version of the spec, and you try paste into some other place, the step numbers aren’t preserved.

[00:31:08.0939] <sideshowbarker>
For `input type=number` with a user-input value of `+1`, should the expected result per-spec be `1`, and not the empty string?

[00:32:59.0092] <sideshowbarker>
I’m looking at the tests at https://wpt.fyi/results/html/semantics/forms/the-input-element/number.html, and specifically at the `{value: "+1", expected: "", testname: "value = +1"}` and `{value: "1.", expected: "", testname: "value ending with '.'"}` tests in https://github.com/web-platform-tests/wpt/blob/master/html/semantics/forms/the-input-element/number.html

[00:34:45.0568] <sideshowbarker>
…and I’m looking at what the spec says at https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number):valid-floating-point-number — which is:
> *User agents must not allow the user to set the value to a non-empty string that is not a valid floating-point number. If the user agent provides a user interface for selecting a number, then the value must be set to the best representation of the number representing the user's selection as a floating-point number.*

[00:37:05.0167] <sideshowbarker>
…where “best representation of the number representing the user's selection as a floating-point number” is: the string obtained from running the JS *ToString(n)* operation on the parsed number _n_.

[00:38:27.0860] <sideshowbarker>
So, given all that, it would seem like for the relevant WPT tests, the expected result for the input `+1` would be `1` — and not the empty string.

[00:40:01.0231] <sideshowbarker>
…since `1` would seem like the “best representation” of `+1`

[00:40:47.0999] <sideshowbarker>
And similarly for the input `1.` — it seems like the test expectation for that should `1`

[00:42:20.0619] <sideshowbarker>
And similarly for all the other tests in lines 38–42 of https://github.com/web-platform-tests/wpt/blob/0cb2ae37c74f1509a03f3837fe80b2d7b5794e31/html/semantics/forms/the-input-element/number.html#L38-L42 that are checking for values with leading spaces

[00:45:11.0569] <sideshowbarker>
Or to put it in implementation terms, if the input string value isn’t a “valid floating-point number”, then the implementation should change the value to result of parsing/converting it into a double, and then running the JS `ToString()` operation on double.

[00:47:19.0152] <sideshowbarker>
But… that‘s not what the WPT tests expect, and that’s not what any of Gecko, Blink, or WebKit do — instead, the texts expect the empty string to be returned if the input value doesn’t match the “valid floating-point number” requirements.

[00:47:31.0535] <sideshowbarker>
 * But… that‘s not what the WPT tests expect, and that’s not what any of Gecko, Blink, or WebKit do — instead, the tests expect the empty string to be returned if the input value doesn’t match the “valid floating-point number” requirements.

[00:48:13.0408] <sideshowbarker>
 * But… that‘s not what the WPT tests expect, and that’s not what any of Gecko, Blink, or WebKit do — instead, the tests expect the empty string to be returned if the input value doesn’t match the “valid floating-point number” requirements, and Gecko, Blink, and WebKit do return the empty string.

[00:48:51.0472] <sideshowbarker>
 * For `input type=number` with a user-input value of `+1`, shouldn’t the expected result per-spec be `1`, and not the empty string?

[00:50:55.0107] <sideshowbarker>
And even just looking at it intuitively: What user benefit would there be to changing the user input `+1` into the empty string, rather than just coercing it into `1`? Who would find that behavior desirable?

[00:59:24.0799] <sideshowbarker>
 * …where _“best representation of the number representing the user's selection as a floating-point number”_ is: the string obtained from running the JS _ToString(n)_ operation on the parsed number _n_.

[01:49:32.0869] <annevk>
sideshowbarker: I almost never copy a set of steps I think. So usually it's something like "and as step 3.23.1 says ..."

[01:49:48.0149] <annevk>
Domenic: is https://github.com/whatwg/html/pull/5841 back in your queue?

[01:52:15.0781] <annevk>
sideshowbarker: for the `+1` case. Are you sure it's end user input? Because that would be up to the user agent. If it's something that ends up running through https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#rules-for-parsing-floating-point-number-values that algorithm would explain why `+` leads to rejection.

[01:57:26.0699] <Ms2ger>
I guess you can/should read "the number representing the user's selection" as being UA-defined - that is, if I type "+1" into an input, "the number representing the user's selection" is 1

[02:00:15.0124] <Ms2ger>
Note that the “best representation of the number representing the user's selection as a floating-point number” algorithm explicitly takes a number, not a string - so you can't pass it "+1"

[02:02:33.0873] <sideshowbarker>
> <@ms2ger:igalia.com> Note that the “best representation of the number representing the user's selection as a floating-point number” algorithm explicitly takes a number, not a string - so you can't pass it "+1"

Thanks, yeah — that’s why I said the implementation would need to parse it into a double first, then run that double through JS the JS `ToString()` operation

[02:06:35.0810] <sideshowbarker>
> <@annevk:matrix.org> sideshowbarker: for the `+1` case. Are you sure it's end user input? Because that would be up to the user agent. If it's something that ends up running through https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#rules-for-parsing-floating-point-number-values that algorithm would explain why `+` leads to rejection.

That algorithm doesn’t reject a leading `+`, right? Instead it explicitly says to ignore the leading `+`, and not return an error, doesn’t it?

[02:14:45.0828] <sideshowbarker>
> <@ms2ger:igalia.com> Note that the “best representation of the number representing the user's selection as a floating-point number” algorithm explicitly takes a number, not a string - so you can't pass it "+1"

As far as how to actually implement _“the number representing the user's selection”_, it seems like the most-likely way to get the number representing the user’s selection would be to run a double parser on the “user’s selection”, and the result of that is the number.

[02:16:04.0697] <Ms2ger>
Possibly - or do something more lenient. Note that UAs aren't required to present this as a text field

[02:16:47.0862] <sideshowbarker>
Well more concretely maybe what the spec should instead do is to explicitly say, _“…the number that results from applying the rules for parsing floating-point number values to the user’s selection”_

[02:17:43.0675] <sideshowbarker>
But if any of this is user-defined, then it seems like we should not have explicit WPT tests for it at all

[02:17:59.0518] <sideshowbarker>
 * But if any of this is UA-defined, then it seems like we should not have explicit WPT tests for it at all

[02:18:42.0895] <Ms2ger>
But wait, nothing in the wpt is actually testing what happens when a user inputs something

[02:19:04.0758] <Ms2ger>
It's just calling the `HTMLInputElement.value` setter

[02:19:34.0591] <sideshowbarker>
Ah, I see. Then I guess I need to look at the requirements for that intead

[02:21:01.0729] <sideshowbarker>
aha OK yeah

[02:21:18.0600] <Ms2ger>
Should have looked at the test first :)

[02:21:18.0617] <sideshowbarker>
sorry for the noise… the spec is actually very clear

[02:21:22.0655] <sideshowbarker>
https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number):value-sanitization-algorithm

[02:21:37.0207] <sideshowbarker>
> The value sanitization algorithm is as follows: If the value of the element is not a valid floating-point number, then set it to the empty string instead.



[02:22:54.0207] <Ms2ger>
Yeah, that's somewhat harsh

[02:28:04.0071] <sideshowbarker>
Seems so yeah — I don’t see what the benefit of that is to end users. But anyway, I will uncritically implement it as spec’ed

[02:53:25.0698] <Ms2ger>
No end users involved on this code path, though - just authors

[03:16:13.0519] <annevk>
sideshowbarker: oh you're right, it's just that it's not valid when serialized, which apparently is what the specification looks it? Not sure I'd have defined it this way

[03:16:42.0429] <annevk>
 * sideshowbarker: oh you're right, it's just that it's not valid when serialized, which apparently is what the specification looks at? Not sure I'd have defined it this way

[03:27:13.0229] <sideshowbarker>
> <@annevk:matrix.org> sideshowbarker: oh you're right, it's just that it's not valid when serialized, which apparently is what the specification looks at? Not sure I'd have defined it this way

Yeah I’m not sure if we’re gaining much by having any algorithm for double-parsing in the spec at all. I still wonder if we’d be better off replacing the algorithm with a statement saying to just parse it per the IEEE 754 requirements for a binary64/double…

[03:27:54.0505] <sideshowbarker>
But I guess the problem with that is, the relevant spec isn’t freely available

[04:30:33.0631] <annevk>
I could see us relying on JS, maybe. Not sure if that's been looked at closely

[06:12:58.0827] <Ms2ger>
annevk: ^

[08:24:29.0754] <annevk>
 * I could see us relying on JS, maybe. Not sure if that's been looked at closely. (Although I do vaguely recall this conversation happening every now and then.)

[13:26:58.0836] <Richard Gibson>
> <@sideshowbarker:matrix.org> Question for any and all: When you want to copy the text of a particular algorithm from a spec and preserve the step numbers, what mechanism do you use?
> 
> I mean specifically, how do you get around the problem that if you just select the text from the HTML version of the spec, and you try paste into some other place, the step numbers aren’t preserved.

ecmarkup manually adds hidden counter text to support this use case: https://github.com/tc39/ecmarkup/blob/main/js/listNumbers.js

it would probably make sense to do something similar in bikeshed-based specs


2024-08-27
[19:40:38.0163] <sideshowbarker>
I’m looking again at the `input type=number` WPT tests at https://github.com/web-platform-tests/wpt/blob/f5e542a731d61e302bc8048308963b6806620fb1/html/semantics/forms/the-input-element/number.html#L33C63-L33C72 and now wondering what part of the spec requires that the _string value_ of `HTMLInputElement.value` must represent a number less than or equal to Number.MAX_VALUE.

[19:41:01.0839] <sideshowbarker>
`{value: "2e308", expected: "", testname: "value >= Number.MAX_VALUE"}` is the particular case I mean

[19:45:14.0566] <sideshowbarker>
The spec requirement at https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number):valid-floating-point-number-4 just says:
> If the value of the element is not a valid floating-point number, then set it to the empty string instead.
But it doesn’t seem like a strict implementation of the [“valid floating-point number”](https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-floating-point-number) checking algorithm is on its own can determine whether the value represents a number less than or equal to Number.MAX_VALUE.

[19:45:28.0293] <sideshowbarker>
 * The spec requirement at https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number):valid-floating-point-number-4 just says:

> If the value of the element is not a valid floating-point number, then set it to the empty string instead.

But it doesn’t seem like a strict implementation of the [“valid floating-point number”](https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-floating-point-number) checking algorithm is on its own can determine whether the value represents a number less than or equal to Number.MAX\_VALUE.

[19:46:02.0076] <sideshowbarker>
 * The spec requirement at https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number):valid-floating-point-number-4 just says:

> If the value of the element is not a valid floating-point number, then set it to the empty string instead.

But it doesn’t seem like a strict implementation of the [“valid floating-point number”](https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-floating-point-number) checking algorithm can on its own determine whether the value represents a number less than or equal to Number.MAX\_VALUE.

[19:46:26.0169] <sideshowbarker>
 * The spec requirement at https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number):valid-floating-point-number-4 just says:

> *If the value of the element is not a valid floating-point number, then set it to the empty string instead.*

But it doesn’t seem like a strict implementation of the [“valid floating-point number”](https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-floating-point-number) checking algorithm can on its own determine whether the value represents a number less than or equal to Number.MAX\_VALUE.

[19:48:05.0732] <sideshowbarker>
Instead, to pass that WPT test, an implementation needs to actually try to parse the value into a number

[19:49:04.0575] <sideshowbarker>
So I‘m wondering what spec requirement that WPT test is checking conformance for

[23:28:16.0373] <annevk>
Anyone remember why IDL integers go beyond the max safe integer values?

[23:47:47.0828] <annevk>
sideshowbarker: hmm, so what happens if parse and serialize gives a different value from the input, does that end up being invalid? Curious how this is implemented. As a matter of principle I'm not a big fan of grammar checks. They're almost never implemented that way and if they are would largely duplicate an existing parser of sorts.

[23:55:19.0087] <annevk>
Given https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A...%3Cinput%20type%3Dnumber%20value%3D0.1234567890123456789012345678901234567890123456789012345678901234567890%3E%0A%3Cscript%3E%0Aw(document.querySelector(%27input%27).validity.valid)%0A%3C%2Fscript%3E I guess I don't know how this works exactly without more exploration and reading the code.

[00:09:11.0811] <sideshowbarker>
> <@annevk:matrix.org> sideshowbarker: hmm, so what happens if parse and serialize gives a different value from the input, does that end up being invalid? Curious how this is implemented. As a matter of principle I'm not a big fan of grammar checks. They're almost never implemented that way and if they are would largely duplicate an existing parser of sorts.

I’m also not a fan of grammar checks, and it’s not clear to me why this particular one is even in the spec to begin with

[00:10:07.0644] <sideshowbarker>
And as far as them never getting implemented as spec’d — yeah, I think that’s the case here

[00:11:19.0527] <sideshowbarker>
However, Ladybird has a default policy of implementing spec algorithms as spec’d — so I’m attempting to implement it that way

[00:11:50.0626] <sideshowbarker>
For the sake of comparison, the WebKit implementation looks nothing like the spec

[00:11:57.0343] <sideshowbarker>
lemme get a link

[00:13:31.0810] <sideshowbarker>
https://github.com/WebKit/WebKit/blob/f6fd2039015c4cbd575768f822ac036102dbc79c/Source/WebCore/html/parser/HTMLParserIdioms.cpp#L220-L232

[00:14:01.0508] <sideshowbarker>
```c++
    // parseDouble() allows the string to start with a '+' or to end with a '.' but those
    // are not valid floating point numbers as per HTML.
    if (characters.front() == '+' || characters.back() == '.')
        return std::nullopt;
    size_t parsedLength = 0;
    double number = parseDouble(characters, parsedLength);
    return parsedLength == characters.size() && std::isfinite(number) ? number : std::optional<double>();
```


[00:15:57.0251] <sideshowbarker>
So, in prose terms: it just checks that the string doesn’t start with `+` or `-`, and then it actually parses it into number and checked the that length of that number is the same length as the input string — and is finite

[00:16:13.0611] <sideshowbarker>
…and that passes all the WPT tests

[00:16:35.0655] <sideshowbarker>
 * So, in prose terms: it just checks that the string doesn’t start with `+` or `-`, and then it actually parses it into number and checks that the length of that number is the same length as the input string — and is finite

[00:16:52.0035] <sideshowbarker>
 * So, in prose terms: it just checks that the string doesn’t start with `+` or `-`, and then it actually parses it into number and checks that the length of that number is the same length as the input string — and is the parsed number is finite

[00:19:17.0330] <sideshowbarker>
My implementation for Ladybird looks like this:
```c++
bool is_valid_floating_point_number (StringView string)
{
    GenericLexer lexer { string };
    // 1. Optionally, a U+002D HYPHEN-MINUS character (-).
    lexer.consume_specific('-');
    // 2. One or both of the following, in the given order:
    // 2.1. A series of one or more ASCII digits.
    bool has_leading_digits = !lexer.consume_while(is_ascii_digit).is_empty();
    // 2.2. Both of the following, in the given order:
    // 2.2.1. A single U+002E FULL STOP character (.).
    if (lexer.consume_specific('.')) {
        // 2.2.2. A series of one or more ASCII digits.
        if (lexer.consume_while(is_ascii_digit).is_empty())
            return false;
    } else if (!has_leading_digits) {
        // Doesn’t begin with digits, doesn’t begin with a full stop followed by digits.
        return false;
    }
    // 3. Optionally:
    // 3.1. Either a U+0065 LATIN SMALL LETTER E character (e) or a U+0045 LATIN CAPITAL
    //      LETTER E character (E).
    if (lexer.consume_specific('e') || lexer.consume_specific('E')) {
        // 3.2. Optionally, a U+002D HYPHEN-MINUS character (-) or U+002B PLUS SIGN
        //      character (+).
        lexer.consume_specific('-') || lexer.consume_specific('+');
        // 3.3. A series of one or more ASCII digits.
        if (lexer.consume_while(is_ascii_digit).is_empty())
            return false;
    }
    return lexer.tell_remaining() == 0;
}
```


[00:19:37.0256] <sideshowbarker>
… but that on its own doesn’t pass the WPT tests

[00:21:03.0404] <sideshowbarker>
In order to pass the WPT tests, I need to call that `is_valid_floating_point_number` function and additionally parse the value:
```c++
    } else if (type_state() == HTMLInputElement::TypeAttributeState::Number) {
        // https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number):value-sanitization-algorithm
        // If the value of the element is not a valid floating-point number, then set it
        // to the empty string instead.
        if (!is_valid_floating_point_number(value))
            return String {};
        auto maybe_value = parse_floating_point_number(value);
        // AD-HOC: The spec doesn’t require these checks — but other engines do them, and
        // there’s a WPT case which tests that the value is less than Number.MAX_VALUE.
        if (!maybe_value.has_value() || !isfinite(maybe_value.value()))
            return String {};
```

[00:25:52.0721] <sideshowbarker>
I hope I’m misunderstanding something — or I have missed something — but as far as I can see, in order to have interop with the behavior in existing engines and with the WPT tests, it’s not sufficient to just strictly implement only the “valid floating-point number” checking algorithm; instead I also need to check that parsing the value returns and actual number rather than an error (for example, because the string value represents a number larger than Number.MAX_VALUE (e.g., `2e308`).

[00:30:02.0608] <sideshowbarker>
Anyway, if that is in fact the case, then I guess to get the spec to match the implementation behavior in existing engines, we could add a step 4 to the algorithm, saying *“Apply the [rules for parsing floating-point number values](https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#rules-for-parsing-floating-point-number-values) to the value, and if the result is an error, then the string is not a valid floating-point number”.*

[00:30:36.0563] <sideshowbarker>
 * Anyway, if that is in fact the case, then I guess to get the spec to match the implementation behavior in existing engines, we could add a step 4 to the algorithm, saying _“Apply the [rules for parsing floating-point number values](https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#rules-for-parsing-floating-point-number-values) to the string, and if the result is an error, then the string is not a valid floating-point number”._

[00:31:42.0123] <sideshowbarker>
 * I hope I’m misunderstanding something — or I have missed something — but as far as I can see, in order to have interop with the behavior in existing engines and with the WPT tests, it’s not sufficient to just strictly implement only the “valid floating-point number” checking algorithm; instead I also need to check that parsing the value returns an actual number rather than an error (for example, because the string value represents a number larger than Number.MAX\_VALUE (e.g., `2e308`).

[05:27:17.0539] <Domenic>
How would you expose a value larger than Number.MAX_VALUE to JS?

[05:28:06.0240] <Domenic>
I think there is an implicit step here you are skipping over where, when exposing numbers to JS, they have to be exposed as JS numbers... it's probably in Web IDL or something.

[05:51:07.0395] <zcorpan>
https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#rules-for-parsing-floating-point-number-values step 16

[08:34:52.0258] <Gasim Gasimzada>
Hi, I recently created a PR about implementing the spec for console.table. I was told to use types not from the Whatwg infra but use types from Ecmascript. I wanted to ask, are those types the WebIDL ones?

[09:45:25.0540] <annevk>
Gasim Gasimzada: https://github.com/whatwg/console/pull/237#issuecomment-2306200273 is the advice you want to focus on and per zcorpan's comment it seems like the way forward is indeed to use ECMAScript operations on the passed in value

[09:46:19.0367] <Gasim Gasimzada>
I am new to the whatwg spec writing. What does ECMAScript operations mean in this case? Is it the IDLs?

[09:48:16.0726] <annevk>
It means operations defined in the ECMAScript specification.

https://html.spec.whatwg.org/multipage/structured-data.html#structuredserializeinternal does this for instance as does https://tc39.es/ecma262/ (the ECMAScript specification)

[09:49:01.0417] <annevk>
It's unfortunate as this is quite hard and there's quite a few gotchas, but given everything that's stated in that thread thus far this seems like the way forward as implementers are unlikely to want to significantly refactor their code.

[09:50:19.0476] <Gasim Gasimzada>
No, it is okay, I just want to know what I need to convert my initial algorithm into :) 

[09:51:07.0952] <annevk>
So you want to use operations like:

Otherwise, for each key in ! EnumerableOwnProperties(value, key)

and

Let inputValue be ? value.[[Get]](key, value).

[09:51:34.0962] <annevk>
And you'll have to learn that ! is an assert of sorts that means the operation can't throw and ? means it can.

[09:52:01.0256] <Gasim Gasimzada>
Makes sense. I will try to convert my algorithm code into this and update my PR. Hopefully, I'll get it right :D 

[09:52:37.0853] <annevk>
Best of luck! It's an adventure of sorts, but it's also kinda fun in a way. At least I remember not finding it completely miserable when I had to do it.

[09:53:14.0981] <Gasim Gasimzada>
Thanks! It is exciting and fun :)


2024-08-28
[22:42:43.0370] <sideshowbarker>
> <@zcorpan:mozilla.org> https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#rules-for-parsing-floating-point-number-values step 16

Right — and that’s relevant _if_ either the “valid floating-point number” algorithm or the https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number):valid-floating-point-number-4 requirement invoke the “rules for parsing floating-point number values” algorithm. But as far as I can see, neither part does. At least they definitely don’t _directly_ invoke it.

[22:51:25.0772] <sideshowbarker>
> <@domenicdenicola:matrix.org> How would you expose a value larger than Number.MAX_VALUE to JS?

As far as I can understand, neither the “rules for parsing floating-point number values” algorithm nor the [If the value of the element is not a valid floating-point number, then set it to the empty string instead](https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number):valid-floating-point-number-4) statement specify anything about requiring the number to be exposed to JS.

Certainly the requirements (elsewhere) for actually doing anything with `HTMLInputElement.value` are about exposing the value to JS. But those are separate requirements. The _“rules for parsing floating-point number values”_ algorithm and the _“If the value of the element is not a valid floating-point number, then set it to the empty string instead”_ seem to be just limited to the _string value_. And implementation-wise, all they require is to essentially just run a lexer on the string, looking at the string character-by-character — without converting or otherwise processing the string in any way.

[22:51:59.0767] <sideshowbarker>
> <@domenicdenicola:matrix.org> How would you expose a value larger than Number.MAX_VALUE to JS?

 * As far as I can understand, neither the “rules for parsing floating-point number values” algorithm nor the [If the value of the element is not a valid floating-point number, then set it to the empty string instead](https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number):valid-floating-point-number-4) statement specify anything about requiring the number to be exposed to JS.

Certainly the requirements (elsewhere) for actually doing anything with `HTMLInputElement.value` are about exposing the value to JS. But those are separate requirements. The _“rules for parsing floating-point number values”_ algorithm and the _“If the value of the element is not a valid floating-point number, then set it to the empty string instead”_ statement seem to be just limited to the _string value_. And implementation-wise, all they require is to essentially just run a lexer on the string, looking at the string character-by-character — without converting or otherwise processing the string in any way.

[23:00:29.0829] <zcorpan>
sideshowbarker: aha, yeah. Maybe it makes more sense to invoke the parse rules then

[23:02:27.0321] <sideshowbarker>
Yeah — or maybe drop the requirement entirely?

[23:03:14.0176] <sideshowbarker>
Though I guess that wouldn’t be backward-compatible now

[23:03:32.0651] <sideshowbarker>
But I mean, it doesn’t seem like anyone knows why that is-valid requirement was added to begin with, or what problem it’s meant to solve

[23:05:30.0423] <sideshowbarker>
And the parse rules already get invoked on that string — just elsewhere, later

[02:29:52.0484] <annevk>
Also implementations don't show the result of parse as per the test I showed yesterday. They only do that once you manipulate the value using the up and down buttons. That leads me to think implementations do have a non-parsing validator as required by the specification, however weird that may be.

[13:04:55.0466] <Dominic Farolino>
How is it valid to return `? ReadableStreamFromIterable(...)` from https://streams.spec.whatwg.org/#rs-from?

[13:05:27.0819] <Dominic Farolino>
The `?` means operations can give you a throw completion, which we're just returning instead of converting to an exception and re-throwing it to Web IDL?

[13:11:18.0607] <Dominic Farolino>
Or does `?` somehow translate to "re-throw" in Web IDL world. It doesn't seem like it though.

[13:15:01.0980] <Dominic Farolino>
HTML does this too: https://html.spec.whatwg.org/C#structuredserialize

[13:15:18.0333] <zcorpan>
Dominic Farolino: does https://tc39.es/ecma262/multipage/notational-conventions.html#sec-returnifabrupt help?

[13:15:24.0800] <zcorpan>
and the next section

[13:15:28.0426] <ljharb>
that's indeed what it means in JS.

[13:17:41.0457] <Dominic Farolino>
> <@zcorpan:mozilla.org> Dominic Farolino: does https://tc39.es/ecma262/multipage/notational-conventions.html#sec-returnifabrupt help?

To me it does not, but probably that's just because I don't get it :) those algorithms just Return the abrupt completions early. So ultimately that leads to us passing abrupt completions to Web IDL as the return value of some methods, and I don't see anything in Web IDL that converts abrupt completions to proper Exceptions

[13:18:13.0928] <Dominic Farolino>
Except for in the places where we invoke user callbacks. That seems to be the only place Web IDL specifically references "abrupt completions" and re-throws their completion record value.

[13:19:45.0148] <Dominic Farolino>
I'd expect generalized handling of that sort elsewhere in Web IDL, if we were allowed to return ES completion records from Web IDL methods

[13:22:57.0410] <zcorpan>
Maybe Domenic knows this better :)

[13:28:38.0097] <Domenic>
The boundary between these is not super clear but the intention is that if you "return" an abrupt completion that's equivalent to throwing in the rest of the web ecosystem

[13:29:03.0134] <Domenic>
https://github.com/whatwg/infra/pull/539 tried to do stuff with this

[13:29:12.0500] <Domenic>
A lot of places in Web IDL use the ?/! notation and thus completions

[13:32:43.0943] <Domenic>
https://github.com/whatwg/infra/issues/518 seems to express the same confusion

[13:43:34.0761] <Dominic Farolino>
I see. Good to know the intention and that this is a generally accepted convention. Thanks.


2024-08-29
[07:33:09.0146] <nicolo-ribaudo>
Why in the HTML PR preview diff the keyboard shortcut for "next" is J and for "prev" is K? The "next" button is on the right of the "prev" button, but J is on the ledt of K

[07:47:54.0596] <evilpie>
> <@nicolo-ribaudo:matrix.org> Why in the HTML PR preview diff the keyboard shortcut for "next" is J and for "prev" is K? The "next" button is on the right of the "prev" button, but J is on the ledt of K

Probably because of vi/vim

[09:47:30.0728] <Domenic>
annevk: think we can merge https://github.com/whatwg/html/pull/10188 ?

[09:53:02.0231] <annevk>
Domenic: sounds good to me.

[09:53:29.0912] <annevk>
/me wonders if Domenic is traveling

[10:06:28.0339] <krosylight>
re: sensitive=true, I think the conversation fully went to the direction about server-side browser AI feature, which makes sense, but the original GH issue I think is more focused on AI crawlers which users don't have control of. Maybe do some enum attribute that selectively signal those crawlers for initial simplicity, like donotcollectby=crawler or something

[10:07:53.0698] <krosylight>
Context: today's whatnot meeting on https://github.com/whatwg/html/issues/10519

[10:57:33.0795] <annevk>
Why would a crawler see end user sensitive data? That would be a website bug, no?

[12:28:38.0338] <Timo Tijhof>
> <@annevk:matrix.org> Why would a crawler see end user sensitive data? That would be a website bug, no?

I suppose it's possible for cookieless authenticated URLs to be leaked or indirectly discovered by a crawler. Akin to "invite/share by link" private URLs, or internal mechanisms where emails point to APIs, static file servers, etc that are private where the URL is the secret.

However this is an area where I'd expect norobots to be used on each page, and/or for these to be in a sub tree excluded wholesale by robots.txt

[12:31:32.0880] <Timo Tijhof>
> <@annevk:matrix.org> Why would a crawler see end user sensitive data? That would be a website bug, no?

I'd expect such a page, if it contains public info on the same url, to have a public version without that private data where that one is canonical or otherwise already indexed instead. The same applies to search engines already, where one needs to be careful not to allow sneaky extraction via "site" and "inurl" operators for accidentally crawled private pages.


2024-08-30
[22:58:26.0698] <sideshowbarker>
Why does the HTML spec fire some events without their defined constructor?

What I means is: When specifying firing of events, in some places in the spec it states the event constructor with *“using”,* like this:
> *fire an event named `hashchange` at document's relevant global object, **using `HashChangeEvent`***
…and in other places it’s stated without *“using”*
>  fire an event named `input` at the element, with the `bubbles` and `composed` attributes initialized to true.

So given that, when that `input` event is fired, the `Event` constructor is used — because the caller doesn’t have a *“using”* statement.

But the `input` event have an `InputEvent` constructor defined in the UI Events spec at https://w3c.github.io/uievents/#inputevent. Why doesn’t the HTML spec state that constructor must be used when firing the `input` event?



[22:58:44.0585] <sideshowbarker>
 * Why does the HTML spec fire some events without their defined constructor?

What I means is: When specifying firing of events, in some places in the spec it states the event constructor with _“using”,_ like this:

> _fire an event named `hashchange` at document's relevant global object, **using `HashChangeEvent`**_

…and in other places it’s stated without _“using”_

> fire an event named `input` at the element, with the `bubbles` and `composed` attributes initialized to true.

So given that, when that `input` event is fired, the `Event` constructor is used — because the caller doesn’t have a _“using”_ statement.

But the `input` event have an `InputEvent` constructor defined in the UI Events spec at https://w3c.github.io/uievents/#inputevent. Why doesn’t the HTML spec state that constructor must be used when firing the `input` event?

[23:53:26.0945] <Ms2ger>
sideshowbarker: the default is `Event` - are you sure these cases use `InputEvent` in practice? (https://dom.spec.whatwg.org/#firing-events)

[00:38:07.0470] <zcorpan>
sideshowbarker: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13038 - I suppose `InputEvent` is used for inputting text, and `Event` is used for other cases

[00:48:44.0780] <sideshowbarker>
> <@ms2ger:igalia.com> sideshowbarker: the default is `Event` - are you sure these cases use `InputEvent` in practice? (https://dom.spec.whatwg.org/#firing-events)

No, I wasn’t sure — it just seemed odd that https://html.spec.whatwg.org/#text-(type=text)-state-and-search-state-(type=search):user-interaction-task-source has this:
> [Queue an element task](https://html.spec.whatwg.org/#queue-an-element-task) on the [user interaction task source](https://html.spec.whatwg.org/#user-interaction-task-source) given the element to [fire an event](https://dom.spec.whatwg.org/#concept-event-fire) named [input](https://w3c.github.io/uievents/#event-type-input) at the element, with the [bubbles](https://dom.spec.whatwg.org/#dom-event-bubbles) and [composed](https://dom.spec.whatwg.org/#dom-event-composed) attributes initialized to true.
…where [input](https://w3c.github.io/uievents/#event-type-input) is a link to the UI events definition of an `input` event with an `InputEvent`. But then despite that, the spec doesn’t state the event must be constructed with that `InputEvent` interface

[00:48:55.0544] <sideshowbarker>
> <@ms2ger:igalia.com> sideshowbarker: the default is `Event` - are you sure these cases use `InputEvent` in practice? (https://dom.spec.whatwg.org/#firing-events)

 * No, I wasn’t sure — it just seemed odd that https://html.spec.whatwg.org/#text-(type=text)-state-and-search-state-(type=search):user-interaction-task-source has this:

> [Queue an element task](https://html.spec.whatwg.org/#queue-an-element-task) on the [user interaction task source](https://html.spec.whatwg.org/#user-interaction-task-source) given the element to [fire an event](https://dom.spec.whatwg.org/#concept-event-fire) named [input](https://w3c.github.io/uievents/#event-type-input) at the element, with the [bubbles](https://dom.spec.whatwg.org/#dom-event-bubbles) and [composed](https://dom.spec.whatwg.org/#dom-event-composed) attributes initialized to true.
>
…where [input](https://w3c.github.io/uievents/#event-type-input) is a link to the UI events definition of an `input` event with an `InputEvent`. But then despite that, the spec doesn’t state the event must be constructed with that `InputEvent` interface

[00:50:45.0194] <Ms2ger>
Ugh, that's needlessly confusing. https://html.spec.whatwg.org/multipage/indices.html#events-2 does say it uses Event, though

[00:51:38.0385] <Ms2ger>
Seems worth an issue

[02:02:35.0768] <arai>
https://html.spec.whatwg.org/#fetching-and-processing-a-resource-from-a-link-element says "They also have linked resource fetch setup steps which ..., but unless explicitly stated, they use the default fetch and process the linked resource algorithm.".  How can I see which (or what kind of) case uses the "default" one and which case doesn't?  Is there a list of "non-default" cases?  I'm currently trying to figure out how `<link rel="stylesheet" ...>` interacts with cache, and investigating how things work in general as a first step.

[02:05:34.0730] <arai>
oh, looks like clicking the " linked resource fetch setup steps" text shows a popup with references, and there are 3 cases (icon/manifest/stylesheet) listed.  is that all?  or can there be any other cases?

[02:06:48.0432] <annevk>
arai: that should be exhaustive

[02:07:01.0914] <arai>
okay, thank you :D

[02:27:30.0957] <sideshowbarker>
So I notice that the Event code in WebKit sets `isTrusted` (to true by default) in the Event _constructor_ — despite the DOM spec making a clear distinction between the “constructing an event” operation and the “creating an event” operation. And the spec states that that `isTrusted` is set to true in the “creating an event” operation, not in the constructing an event” operation.

Nevertheless, it’d seem like the observable behavior in WebKit must be conforming to the spec — since WebKit passes whatever the relevant tests in WPT are.

So… Is it actually expected that setting `isTrusted` in the Event constructor will have the same observable effect at setting in the implementation of the “create an event” operation? And if so, the separation about where `isTrusted` is set is something that exists in the spec for some reason but doesn’t actually get exercised in practice by all calling operations?

[02:28:15.0924] <sideshowbarker>
Relevant part of the DOM spec is <https://dom.spec.whatwg.org/#constructing-events>

[02:28:45.0177] <sideshowbarker>
 * So I notice that the Event code in WebKit sets `isTrusted` (to true by default) in the Event _constructor_ — despite the DOM spec making a clear distinction between the “constructing an event” operation and the “creating an event” operation. And the spec states that that `isTrusted` is set to true in the “creating an event” operation, not in the “constructing an event” operation.

Nevertheless, it’d seem like the observable behavior in WebKit must be conforming to the spec — since WebKit passes whatever the relevant tests in WPT are.

So… Is it actually expected that setting `isTrusted` in the Event constructor will have the same observable effect at setting in the implementation of the “create an event” operation? And if so, the separation about where `isTrusted` is set is something that exists in the spec for some reason but doesn’t actually get exercised in practice by all calling operations?

[02:31:20.0007] <sideshowbarker>
I ask this because I have found that in writing a new implementation, it‘s a lot easier, implementation-wise, to set `isTrusted` in the code for the Event::Event constructor than it is to set in and Event::create code (“create an event” operation) — which I can imagine is the reason why WebKit implemented that way

[02:33:08.0665] <sideshowbarker>
Though I can also imagine it was implemented that way in WebKit in a time long ago — and maybe before this separation between the operations existed in the DOM spec, which perhaps got added later

[02:33:46.0337] <sideshowbarker>
 * I ask this because I have found that in writing a new implementation, it‘s a lot easier, implementation-wise, to set `isTrusted` in the code for the Event::Event constructor than it is to set in and Event::create code (“create an event” operation) — which I can imagine is the reason why WebKit implemented that way

[02:36:24.0723] <zcorpan>
I think it's not observable

[02:36:35.0610] <sideshowbarker>
OK

[02:37:07.0516] <annevk>
https://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cscript%3E%0Aw(new%20Event(%27x%27).isTrusted)%0A%3C%2Fscript%3E shows it as false, so I suspect what WebKit does is a bit more involved.

[02:37:37.0872] <sideshowbarker>
It’s false for synthetic events

[02:38:34.0787] <sideshowbarker>
So in cases where it‘s false in WebKit, the calling code must be setting it to false when constructing

[02:38:43.0579] <annevk>
Not sure what you mean by constructor if that case doesn't cover it.

[02:42:35.0349] <sideshowbarker>
I guess I could step through it in a debugger in a WebKit build and see

[02:46:10.0660] <sideshowbarker>
But to put more a bit more context on why I’m asking: For Ladybird, because the project has a policy that the spec requirements should be followed as closely as possible: I’m trying to decide if I should _try_ to implement it strictly the way the spec states it happens — in the “create an event” operation — whether there’s some observable benefit to implementing it that way vs the additional cost/complication which comes from following the spec strictly in this case

[02:52:40.0346] <sideshowbarker>
And I mean, assuming I figure out how to get `new Event('x')` to end up setting `isTrusted` to false, the way WebKit manages to

[02:54:39.0022] <annevk>
`static Ref<Event> create(const AtomString& type, const EventInit&, IsTrusted = IsTrusted::No);` What makes you think it defaults to true?

[03:41:46.0352] <sideshowbarker>
Because in the constructor code at  https://github.com/WebKit/WebKit/blob/e4d6852ee20ff3dfcd3a59fe241d84f662abb234/Source/WebCore/dom/Event.cpp#L45-L55 I see:

```c++
, m_isTrusted { isTrusted == IsTrusted::Yes }
```

…and the `create` signatures I see are:

```
Ref<Event> Event::create(const AtomString& type, CanBubble canBubble, IsCancelable isCancelable, IsComposed isComposed)
{
    return adoptRef(*new Event(EventInterfaceType::Event, type, canBubble, isCancelable, isComposed));
}
```
…so if that’s called, then it defaults to `IsTrusted::Yes`

And then the other `create` signature is:

```
Ref<Event> Event::create(const AtomString& type, const EventInit& initializer, IsTrusted isTrusted)
{
    return adoptRef(*new Event(EventInterfaceType::Event, type, initializer, isTrusted));
}
```

…for callers that need to set `IsTrusted::No`

[04:08:38.0987] <annevk>
There are indeed various defaults so it depends which internal constructor you call. However, note that `m_isTrusted { isTrusted == IsTrusted::Yes }` is not itself not setting a default. It just sets it to whatever the value of `isTrusted` is. It's a way to convert from a class enum to a boolean.

[04:09:07.0444] <annevk>
 * There are indeed various defaults so it depends which internal constructor you call. However, note that `m_isTrusted { isTrusted == IsTrusted::Yes }` is not setting a default. It just sets `m_isTrusted` to whatever the value of `isTrusted` is. It's a way to convert from a class enum to a boolean.

[04:19:10.0559] <sideshowbarker>
I see

[09:39:11.0791] <Domenic>
Luca Casonato: regarding https://github.com/whatwg/html/pull/10593 , how does tihs interact with the closebehavior/closedby etc. proposed for https://github.com/whatwg/html/issues/9373 ?

[09:39:46.0218] <Domenic>
I guess I should ask this question on the issue since I am about to go to lunch

[11:52:17.0703] <Dominic Farolino>
Domenic: I've got a question about this line right here: https://streams.spec.whatwg.org/#readable-stream-from-iterable:~:text=Let%20nextPromise%20be%20a%20promise%20resolved%20with%20nextResult.%5B%5BValue%5D%5D. nextResult.[[Value]] is expected to be a Promise, right? But we wrap it in a Promise just in case it's not a Promise, so that reacting to it is always async? Is that right?

[12:03:32.0626] <Dominic Farolino>
 * Domenic:  I've got a question about this line right here: https://streams.spec.whatwg.org/#readable-stream-from-iterable:~:text=Let%20nextPromise%20be%20a%20promise%20resolved%20with%20nextResult.%5B%5BValue%5D%5D. nextResult.\[\[Value\]\] is expected to be a Promise, right? But we wrap it in a Promise just in case it's not a Promise, so that reacting to it is always async? Is that right?

[12:06:26.0859] <Domenic>
I believe that's right. That sort of wrapping is pretty pervasive when dealing with potentially-user code.


2024-08-31
[21:00:59.0076] <jimtendo>
Hi all, I was just wondering what the rationale behind the Safelisted Protocol Handlers in this spec here:
https://html.spec.whatwg.org/multipage/system-state.html#safelisted-scheme
... and whether this applies only to PWA's (running from within a browser) or also applies to TWA's (PWA "installed" on device and opened as more of a web-frame... sorry, not sure on correct terminology for that).
I can't see the reason why having such a whitelist is necessary (that's not to say there isn't one, I just can't quite grasp it) and it makes developing TWAs a bit difficult in the sense that existing apps would have to adapt to use a `web+` prefix for their existing links to support TWA clients.