2023-07-02 [20:38:28.0197] Brandon Sheley: 2023-07-04 [21:35:01.0284] Alexander Kalenik: Did you have a chance to look at https://github.com/whatwg/html/issues/9148#issuecomment-1610989949 ? I would love to get your implementer experience-informed opinion, before I go making changes. [00:50:27.0386] Domenic: do you know which sites would benefit from `origin-agent-cluster` (regardless of its default value)? [00:52:54.0686] > <@zcorpan:mozilla.org> Domenic: do you know which sites would benefit from `origin-agent-cluster` (regardless of its default value)? Google Workspace uses it heavily to hint for process isolation among its many same-site cross-origin pages. [00:55:13.0022] Domenic: ok. Do you know if there's interest from non-Google properties? [00:57:26.0556] I haven't been in touch with any. Unfortunately it looks like it's not used on the sites HTTP archive picks up, but it's used by ~0.5% of page views. https://chromestatus.com/metrics/feature/timeline/popularity/3286 [00:58:11.0644] Domenic: ok, thanks! [01:31:09.0873] Domenic: I see 39 sites in httparchive using resources with OAC: ?1 [01:36:27.0782] Oh nice! [01:54:37.0938] Domenic: https://docs.google.com/spreadsheets/d/1WNmB2zpx8BAf8bkBOeL-gVeHghR02sXW2Jzea6t2vpE/edit?usp=sharing [01:55:20.0226] Well, that is kind of suspicious [01:55:58.0679] It got into some white-label Brazilian photo-printing site I guess? [01:56:30.0983] oh wait, I made a mistake. They're actually using `Origin-Agent-Cluster: 1` [02:03:47.0789] Domenic: 6406 pages use `?1` https://docs.google.com/spreadsheets/d/11-6EKWZaQdpvOe8L1nxHW3wWtTnwDy1GhNYDJCcVY-0/edit?usp=sharing [02:05:15.0174] Curious that the use counter doesn't find these in httparchive [02:06:31.0901] I think maybe I renamed the use counter at one point. I wonder if that broke it. [02:06:48.0338] Ah wow that is a nice list. 2023-07-05 [23:14:26.0242] Domenic: I want to raise an issue for adding `VideoPlaybackQuality` and `getVideoPlaybackQuality()` to HTML. I had thought we had an issue template of some kind with a checklist (e.g., including the _“no implementers object”_ language — but right now, I can’t find any such template. And maybe I’m confusing it with the browser-project “Intent to implement/ship” messages I’ve seen that do have such checklists? [23:15:52.0292] * Domenic: I want to raise an issue for adding `VideoPlaybackQuality` and `getVideoPlaybackQuality()` to HTML. I had thought we had an issue template of some kind with a checklist (e.g., including the _“no implementers object”_ language) — but right now, I can’t find any such template. And maybe I’m confusing it with the browser-project “Intent to implement/ship” messages I’ve seen that do have such checklists? [23:21:47.0725] ah, nevermind — I realize now that I what I had been thinking of was of course the template for _PRs_ 2023-07-06 [17:37:05.0283] Help wanted / Good first issue: For anybody interested in contributing to the HTML standard, https://github.com/whatwg/html/issues/1102 might be a good issue you could resolve, by writing a spec patch for it with a modest amount of effort — perhaps mostly by just porting over the existing `` spec text from https://w3c.github.io/html-media-capture/ [02:01:36.0187] I'm confused about why you cannot directly download the resource (file) on the local machine using JS, but you can do it with JS if you fetch the resource, construct the a element with the fetched resource as URL and then click it using JS? [02:26:55.0782] Is there a spec issue about upstreaming https://wicg.github.io/document-policy/#integrations ? [05:31:53.0649] zcorpan: I don't think there is one against HTML [05:32:10.0718] annevk: ok [05:57:34.0326] vrafaeli: example? I thought `.click()` would generally work. Seems weird if it performs a same-origin check ahead of time given redirects. [06:18:31.0899] I initially thought https://github.com/whatwg/html/issues/9491 was about making `/>` conforming on all tags but also have it continue to be meaningless [06:19:11.0958] So you can write `
yolo
` and the HTML checker won't yell [06:20:12.0335] Anyway, if we do a flag it should just be "XML5" [06:20:40.0427] * Anyway, if we do a flag it should just be "XML5" (and the flag is `text/xml`) [06:45:53.0442] > <@annevk:matrix.org> vrafaeli: example? I thought `.click()` would generally work. Seems weird if it performs a same-origin check ahead of time given redirects. https://codesandbox.io/s/interesting-nightingale-vkpy9s?file=/src/index.js I use a plugin to inject response header "content-disposition: attachment". I was expecting that after the response has been received the browser would initialte a download to the local machine. [06:46:47.0247] but the download to local machine does not happen [06:47:24.0110] > <@annevk:matrix.org> vrafaeli: example? I thought `.click()` would generally work. Seems weird if it performs a same-origin check ahead of time given redirects. * https://codesandbox.io/s/interesting-nightingale-vkpy9s?file=/src/index.js I use a Chrome plugin to inject response header "content-disposition: attachment". I was expecting that after the response has been received the Chrome browser would initialte a download to the local machine. [06:47:57.0211] * https://codesandbox.io/s/interesting-nightingale-vkpy9s?file=/src/index.js I use a Chrome plugin to inject response header "content-disposition: attachment". I was expecting that this would make the Chrome browser to do a download to the local machine. [06:50:28.0748] * https://codesandbox.io/s/interesting-nightingale-vkpy9s?file=/src/index.js I use a Chrome plugin to inject response header "content-disposition: attachment". (in my real case the server sets it) I was expecting that this would make the Chrome browser to do a download to the local machine. [11:14:09.0413] Hm, is there a term I can reference for "frames that can be communicated with"? Basically just anything you can postMessage to? [11:17:52.0867] browsing context group? [11:18:22.0678] (though BroadcastChannel is an exception) [11:18:51.0279] (Context is "things that should be able to see an MQ change if it gets toggled by script", re: https://github.com/w3c/csswg-drafts/issues/6517) [11:19:23.0758] Because if you darkmode a site via an in-site toggle you'd like iframes to darkmode as well, ideally. [12:41:41.0422] TabAtkins: you can postMessage() across origins. In the issue you say it shouldn't be visible to cross-origin iframes [13:14:28.0268] Basically I just don't want to invent a new security boundary. If you can already freely message a cross-domain frame, you should be able to affect their MQs. [13:30:12.0475] TabAtkins: for popups you can communicate between opener and openee unless it was opened with `noopener`. For iframes I *think* you can always send a message (if embedding is allowed). When same-origin, you can communicate even if there's no reference to the window (with `BroadcastChannel` or `localStorage` or `document.cookie` or a shared worker) [13:30:43.0752] Right, all this detail is why I was asking if there's already a spec concept for communicating subframes. [13:34:17.0414] TabAtkins: it's still not clear to me what you want [13:39:26.0232] I want to define that you can toggle certain MQs from script. These MQs want to transmit their script-changed values to subframes (so an iframe will also be darkmode if the top-level frame was set to darkmode). But I don't want to open a new communication channel. I'm *presuming* that "frames you can postMessage" is a reasonable description of the boundary for things that can see the altered MQs. [13:40:06.0696] And I'm hoping this is already a concept defined somewhere so I don't have to create and maintain such a definition in a CSS spec that doesn't otherwise care about the web's communication/security boundaries. [13:40:43.0005] TabAtkins: what about popups? [13:41:05.0924] I suspect we should treat them like subframes in this regard. [13:42:03.0627] > <@tabatkins:matrix.org> I want to define that you can toggle certain MQs from script. These MQs want to transmit their script-changed values to subframes (so an iframe will also be darkmode if the top-level frame was set to darkmode). But I don't want to open a new communication channel. I'm *presuming* that "frames you can postMessage" is a reasonable description of the boundary for things that can see the altered MQs. Didn't we resolve at some point that the embedded page's color scheme depended on the color-scheme value of the iframe? [13:42:17.0402] Or discuss doing it or something? [13:42:43.0855] yeah we at least discussed it, tho I don't recall the conclusion exactly. But we should rely on the same mechanism, def. [13:43:50.0036] Seems like if we do that stuff then it works. But yeah gecko has the "browsing context group" concept which is just that, stuff you can postMessage to [13:50:17.0146] I'm a bit uneasy with making custom MQ available to the whole browsing context group. It would be like `BroadcastChannel` but to all origins [13:59:17.0959] I don't really care what concept I end up leaning on. If browsing context group is too large, then a smaller one would work just fine for me. I just need the concept to exist somewhere where it can be reasonably maintained as we continue to add more distinctions and guards to it. [14:00:40.0276] TabAtkins: it seems like you only want to propagate to descendant documents so that's probably what you want to say; or do you also want to go to ancestors or popups? [14:01:22.0830] Not ancestors (ancestors need to be able to propagate to *me*). Possibly popups, but I don't think I have much of an opinion. Seems reasonable that if the page is in darkmode its popups should be too. [14:02:08.0355] "Its popups" is somewhat of a corner area as some popups are created deliberately without communication channel [14:02:27.0195] yeah that's fair [14:02:29.0588] Anyway, if you don't want ancestors claiming you want equivalence with postMessage() is not too helpful [14:02:57.0700] I would start with a document and its descendant documents (HTML has some terms for this though they are not super) [14:05:09.0502] Descendants will count things like, say, fenced frames tho I assume, so I'll still need more clarification there. [14:05:14.0313] But yeah that's probably the starting point. [14:06:16.0706] Fenced frames aren't integrated with HTML so who knows how they work. If descendant documents return them they probably have some issues to work out. [14:06:33.0957] fair [14:06:57.0990] Probably just leaving an impl note next to the definition will suffice for now. 2023-07-07 [02:39:12.0527] Have a nice summer folks [02:43:10.0919] The same to you all Have a wonderful summer vacation [07:07:41.0507] https://url.spec.whatwg.org/#serialize-an-integer is entertainingly succinct. No idea what data type it returns for example :) [07:17:48.0472] I found https://github.com/whatwg/infra/issues/201, so now I know fetch has a very slight improvement on this, which has apparently been copied into various other specs. [09:00:19.0119] A decimal number is a data type :p [09:02:19.0473] Anyway, yeah, we should add numbers and ways to serialize them to strings to Infra. Maybe now that BigInt is defined we can actually do so. [13:55:52.0419] jarhar: mfreed: hey, did you see https://github.com/whatwg/html/pull/9456#issuecomment-1611419095? [13:56:39.0868] jarhar: mfreed: would be great to have your input; cc ntim [13:57:44.0481] I’m looking at https://github.com/w3c/webappsec-credential-management/actions/runs/5465713950/jobs/9949551741 ``` LINE ~299: No 'dfn' refs found for 'parent browsing context'. [=parent browsing context=] ``` [13:58:26.0965] I guess `parent browsing context` got changed to something else at some point before March? [14:02:05.0147] aha, `parent navigable`, it seems [14:02:20.0150] * aha, `parent navigable`, it seems. Right? [14:02:47.0795] Yeah, though I'm not sure it's really a term of art on its own; you'd get the current navigable somehow and then grab its parent member. [14:03:38.0759] I see [14:03:59.0235] Lemme grab the relevant part of the credential-management spec [14:05:24.0508] https://w3c.github.io/webappsec-credential-management/#algorithm-same-origin-with-ancestors > 6. While _current_ has a parent browsing context: > > 1. Set _current_ to current’s parent browsing context. [14:06:17.0259] So I guess I can’t just `s/parent browsing context/parent navigable/` there? [14:07:26.0320] Maybe I need to add some earlier step to get the current navigable first? [14:10:29.0046] _current_ prolly needs to become a navigable and then you check _current_'s parent [14:11:17.0162] Domenic and Dominic Farolino have a better hold on this and might be able to suggest even better things [14:11:20.0095] is there a _“get navigable for…”_ hook? [14:12:01.0599] > <@annevk:matrix.org> Domenic and Dominic Farolino have a better hold on this and might be able to suggest even better things Thanks yeah then I’ll wait to hear from them. It’s not urgent. The related issue has been open since March 2nd [14:12:02.0308] You can grab it from the `Window` object at least [14:12:09.0412] It looks like you want to go from document -> navigable. For that, use "node navigable". [15:10:33.0388] Unrelated incidental bikeshed warning: ``` LINK ERROR: Multiple possible 'fetch()' idl refs. Arbitrarily chose https://wicg.github.io/background-fetch/#dom-backgroundfetchmanager-fetch To auto-select one of the following refs, insert one of these lines into a 
 block:
spec:background-fetch; type:method; text:fetch(id, requests)
spec:fetch; type:method; text:fetch(input)
{{fetch()}}
```

[15:11:29.0231] 
…but I _did_ already put:
```diff
@@ -76,6 +76,7 @@ spec: web-otp; urlPrefix: https://wicg.github.io/web-otp
 
 spec:html; type:dfn; for:html-origin-def; text:origin
 spec:html; type:dfn; for:environment settings object; text:global object
+spec:fetch; type:method; text:fetch(input)
 spec:fetch; type:dfn; for:/; text:request
 spec:fetch; type:dictionary; for:/; text:RequestInit
 spec:infra; type:dfn; for:/; text:set
```

[15:12:27.0373] 
…but Bikeshed seems to be ignoring that

[15:12:48.0836] 
 * Unrelated incidental bikeshed warning:

```plain
LINK ERROR: Multiple possible 'fetch()' idl refs.
Arbitrarily chose https://wicg.github.io/background-fetch/#dom-backgroundfetchmanager-fetch
To auto-select one of the following refs, insert one of these lines into a 
 block:
spec:background-fetch; type:method; text:fetch(id, requests)
spec:fetch; type:method; text:fetch(input)
{{fetch()}}
```

[15:12:56.0055] 
 * Unrelated incidental bikeshed warning:

```none
LINK ERROR: Multiple possible 'fetch()' idl refs.
Arbitrarily chose https://wicg.github.io/background-fetch/#dom-backgroundfetchmanager-fetch
To auto-select one of the following refs, insert one of these lines into a 
 block:
spec:background-fetch; type:method; text:fetch(id, requests)
spec:fetch; type:method; text:fetch(input)
{{fetch()}}
```

[15:13:09.0683] 
 * Unrelated incidental bikeshed warning:

```
LINK ERROR: Multiple possible 'fetch()' idl refs.
Arbitrarily chose https://wicg.github.io/background-fetch/#dom-backgroundfetchmanager-fetch
To auto-select one of the following refs, insert one of these lines into a 
 block:
spec:background-fetch; type:method; text:fetch(id, requests)
spec:fetch; type:method; text:fetch(input)
{{fetch()}}
```

[15:13:58.0811] 
 * Unrelated incidental bikeshed warning:

```text
LINK ERROR: Multiple possible 'fetch()' idl refs.
Arbitrarily chose https://wicg.github.io/background-fetch/#dom-backgroundfetchmanager-fetch
To auto-select one of the following refs, insert one of these lines into a 
 block:
spec:background-fetch; type:method; text:fetch(id, requests)
spec:fetch; type:method; text:fetch(input)
{{fetch()}}
```

[15:18:57.0166] 
sideshowbarker: I think that's because it lacks input as argument so you either want to remove input in link-defaults or add it where you reference

[15:19:55.0286] 
sideshowbarker: in fact if you did `fetch()` you'd probably not need link-defaults

[15:23:04.0406] 
> <@annevk:matrix.org> sideshowbarker: in fact if you did `fetch()` you'd probably not need link-defaults

Hai. Will do that instead

[16:03:50.0458] 
hi all, edgecase with `HTMLStyleElement` for you: if the disabled flag is set and the children are updated, should the stylesheet be updated/applied?

[16:04:29.0075] 
example:
```js
const style = document.createElement("style")
style.disabled = true;
assert(style.disabled); // true
style.textContent = "new content";
assert(!style.disabled); // false
```

[16:05:01.0183] 
 * example:

```js
const style = document.createElement("style");
document.body.appendChild(style);

style.disabled = true;
assert(style.disabled); // true

style.textContent = "new content";
assert(!style.disabled); // false
```

[16:05:57.0578] 
 * example:

```js
const style = document.createElement("style");
document.body.appendChild(style);

style.disabled = true;
style.disabled // true

style.textContent = "new content";
style.disabled // false
```

[16:13:14.0741] 
Yeah, see https://html.spec.whatwg.org/#update-a-style-block and caller


2023-07-10
[19:09:32.0210] 
> <@sideshowbarker:matrix.org> …but I _did_ already put:
> ```diff
> @@ -76,6 +76,7 @@ spec: web-otp; urlPrefix: https://wicg.github.io/web-otp
>  
>  spec:html; type:dfn; for:html-origin-def; text:origin
>  spec:html; type:dfn; for:environment settings object; text:global object
> +spec:fetch; type:method; text:fetch(input)
>  spec:fetch; type:dfn; for:/; text:request
>  spec:fetch; type:dictionary; for:/; text:RequestInit
>  spec:infra; type:dfn; for:/; text:set
> ```

Hmmm, that's a bug on my part if I'm recommending a link-defaults but the linker isn't using it in this situation.

[19:09:55.0603] 
I presume you've just got a `{{fetch()}}` somewhere that's triggering the failure in the first place?

[19:10:12.0887] 
Howdy Tab

[19:10:21.0465] 
> <@tabatkins:matrix.org> I presume you've just got a `{{fetch()}}` somewhere that's triggering the failure in the first place?

Yeah, exactly

[19:10:43.0014] 
But in the meantime, I worked around it by fulling inlining the ref

[19:10:48.0294] 
/me looks for the PR

[19:11:32.0381] 
k, the magic that makes an arg-less method autolink work even if you didn't dfn any argless forms must be done in such a way that it doesn't catch the link-default. So yeah, bug on my part.

[19:13:23.0990] 
well, Anne pointed out to me how to inline it properly in this case — and I guess it’s better to do it that way anyway (so maybe it’s not really so much a workaround after all)

[19:13:29.0885] 
https://github.com/w3c/webappsec-credential-management/pull/223/files#diff-5e793325cd2bfc452e268a4aa2f02b4024dd9584bd1db3c2595f61f1ecf7b985R2191

[19:14:20.0260] 
but that said, that’s repetitive in that there are multiple instances of that, which I see could instead just be handled by setting a default

[19:14:53.0533] 
so that makes me really see the purpose and value of having that mechanism for setting defaults — so that I don’t have to repeat like that

[19:15:06.0308] 
right, regardless of whether you could work around it in this instance it's still absolutely a bug that I'm recommending a fix that doesn't work

[19:17:09.0118] 
> <@tabatkins:matrix.org> If you want to use local versions of boilerplates because whatever's getting downloaded by `bikeshed update` is bad, ideally gimme a PR at , but failing that just put the appropriate boilerplate file next to your spec source. Bikeshed'll use local files over stuff in its database.

TabAtkins: by the way, I had been meaning to say Thanks to for that guidance ⬆️ you gave me a couple few weeks ago (about how to use local boilerplate properly)

[19:17:30.0662] 
> <@tabatkins:matrix.org> If you want to use local versions of boilerplates because whatever's getting downloaded by `bikeshed update` is bad, ideally gimme a PR at , but failing that just put the appropriate boilerplate file next to your spec source. Bikeshed'll use local files over stuff in its database.

 * TabAtkins: by the way, I had been meaning to say Thanks to you for that guidance ⬆️ you gave me a couple few weeks ago (about how to use local boilerplate properly)

[19:18:26.0466] 
Nice, glad I could help!

[19:18:29.0622] 
Also: https://github.com/speced/bikeshed/issues/2600


2023-07-11
[13:47:59.0760] 
Heads up: I just pushed the first phase of my html parser rewrite (take 2). It looks like it should be great; in particular, I got *zero* output changes in WHATWG specs. I did spot checks on several specs to make sure I wasn't outputting spurious new warnings, but as I don't yet have console text logged as part of tests, I'm not 100% sure about that. Please let me know if anything looks wrong.

[13:48:08.0208] 
(It's in the new version 3.14.0)

[16:01:52.0481] 
> <@tabatkins:matrix.org> Heads up: I just pushed the first phase of my html parser rewrite (take 2). It looks like it should be great; in particular, I got *zero* output changes in WHATWG specs. I did spot checks on several specs to make sure I wasn't outputting spurious new warnings, but as I don't yet have console text logged as part of tests, I'm not 100% sure about that. Please let me know if anything looks wrong.

Python parser? Embedded in Bikeshed?

[16:02:29.0891] 
Yeah, plan for a long while has been to integrate all of Bikeshed's core parsing into one (heavily modified) parser.

[16:02:54.0306] 
HTML, markdown, and all of bikeshed's varied shorthand syntaxes

[16:03:00.0878] 
Excellent

[16:04:33.0351] 
Optimized for performance? Or instead that's not a priority?

[16:05:33.0485] 
Definitely not a priority at this phase, but I'm pretty confident it will be a perf benefit over the "run shitloads of regexes over the document repeatedly" process that I do today.

[16:06:00.0269] 
But mostly it's about correctness; processing things in the distinct phases that I do today just doesn't work

[16:07:41.0283] 
(There's a bunch of places where, say, I have to handle something before the HTML parser sees it, but I have to avoid messing with it if it shows up inside an XMP or markdown code span, etc. All my inline shorthands work only if you nest them in the order that I happen to process them. etc.)


2023-07-13
[17:13:08.0088] 
sideshowbarker: It looks like the MDN-spec-links project moved to html-now? But the SPECMAP.json file is still present at the old location, and apparently out of date.

[17:13:24.0604] 
(Bikeshed is pulling down some 404 pages for mdn data right now.)

[18:12:52.0335] 
> <@tabatkins:matrix.org> sideshowbarker: It looks like the MDN-spec-links project moved to html-now? But the SPECMAP.json file is still present at the old location, and apparently out of date.

Not moved. The html-now SPECMAP.json is a copy. But spec-links is just borked at the moment, for some reason. I’ll look into right now and fix it.

[18:14:30.0240] 
Kk. I should respond to 404s better too 

[18:14:44.0844] 
yeah

[18:15:14.0530] 
can you give me one that you are getting a 404 on right now?

[18:15:54.0628] 
ah nevermind

[18:15:59.0396] 
I see now

[18:16:08.0161] 
lord, what did I do

[18:17:07.0864] 
w3c.github.io/mdn-spec-links is just entirely redirecting to https://html-now.github.io/

[18:17:41.0976] 
that’s completely unintentional and I don’t yet have any idea how I caused that, nor when (how long ago)

[18:23:16.0243] 
…and unfortunately, used a 301 rather than a 302

[18:27:10.0523] 
TabAtkins: should be un-borked now — at least from non-browser requests without some network cache in between

[18:27:36.0434] 
for browsers, may need to do some fiddling in devtools

[13:01:09.0814] 
The web platform and JS are inconsistent wrt each other in the handling of `undefined` & missing arguments to functions. (When I speak of "missing arguments", I mean only for cases where an argument is required, and is not typed to accept `undefined`.)

Historically in JS, missing arguments are treated the same way as explicit `undefined`: coerce the value `undefined` to the relevant argument type. So for example `escape()` returns the string `"undefined"`.

In the web platform, missing arguments are an error, in contrast to JS. Like in JS, an explicit `undefined` is coerced to the relevant argument type, so it is handled differently from missing arguments.

TC39 just came to consensus that we'd like to be stricter here, for new APIs. In fact we'd like to be stricter even than the web platform currently is - we'll adopt the "missing arguments are an error" thing from the web platform, but in addition we'll start treating explicit `undefined` as an error.

I'm hoping the web platform can make the same change: treat missing arguments and explicit `undefined` consistently with each other, as an error. Obviously this is not a trivial change.

Assuming people are open to this, what's the best way to go about making such a change? I was thinking a new [LegacyCoerceUndefined] Web IDL attribute, which would be attached to ~every existing API specified with Web IDL, and then change the default definition for argument handling without that attribute so that explicit `undefined` throws. Does that sound reasonable?

[13:01:51.0211] 
cc Domenic since we were talking about this over in the tc39 channel

[14:11:16.0050] 
bakkot: in principle I think that could work, modulo the amount of work; but presumably it only applies to a subset of arguments, strings and nullables?

[14:12:09.0869] 
we don't want to coerce `undefined` to 0 either? and for nullables accepting `undefined` is fine

[14:12:38.0217] 
for booleans the default value is generally `false` so coercing is fine, as long as you can also just omit the argument and get `false`

[14:12:57.0278] 
you can't coerce `undefined` to object types, of course. I think that covers everything?

[14:14:12.0057] 
that is, when passing an explicit `undefined`:
- any object type: already an error
- nullable: legal because that's what "nullable" means
- boolean: presumably intended to default to `false`; should continue to do so
- string: should become error
- number: should become error


[14:14:31.0695] 
 * that is, when passing an explicit `undefined`:

- any object type: already an error
- nullable: legal because that's what "nullable" means
- boolean: presumably intended to default to `false`; should continue to do so
- string: should become error
- number: should become error (unless 0 is intended to be the default, as it often is)

[14:15:12.0671] 
in the boolean/number cases where you want a default value, missing arguments should be accepted and treated the same way as an explicit `undefined`, rather than getting an error

[14:16:14.0647] 
 * that is, when passing an explicit `undefined`:

- any object type: already an error
- symbol/bigint/function types: already an error
- nullable: legal because that's what "nullable" means
- boolean: presumably intended to default to `false`; should continue to do so
- string: should become error
- number: should become error (unless 0 is intended to be the default, as it often is)

[14:19:08.0945] 
Makes sense, I forgot that undefined works for numbers/booleans

[14:21:24.0705] 
Nit: passing `undefined` to a WebIDL dictionary should probably stay equivalent to passing {}. There's a recommendation  (https://webidl.spec.whatwg.org/#dfn-optional-argument-default-value) to make that the default value for trailing dictionaries, but there might be interior ones for which it matters.

[14:22:33.0995] 
Well, I guess I don't actually have a preference that people be able to pass `undefined` instead of `{}`. It's just not quite true that it's already an error for all object types.

[14:23:56.0325] 
ah, I only mean for this to apply when there are no default values specified

[14:24:16.0529] 
in the case of default values, I would want explicit `undefined`, like an entirely missing argument, to give you the default value

[14:24:59.0789] 
... also is the default for dictionaries really `{}` instead of `{ __proto__: null }`? seems bad...

[14:26:04.0235] 
for non-trailing dictionaries, which do not have default values (i.e. the argument is required), it seems like it ought not accept `undefined`, to me?

[14:26:10.0470] 
 * for non-trailing dictionaries, which do not have default values specified (i.e. the argument is required), it seems like it ought not accept `undefined`, to me?

[14:28:14.0446] 
> <@bakkot:matrix.org> ... also is the default for dictionaries really `{}` instead of `{ __proto__: null }`? seems bad...

WebIDL dictionaries are only ever taken as arguments, they're never returned from an API, so this isn't a concern.

[14:28:32.0221] 
bakkot: `{}` is a Web IDL literal, it's not a JS object

[14:28:39.0443] 
ah, ok

[14:29:23.0779] 
Dictionaries are returned by some APIs btw.

[14:32:01.0823] 
Oh, it says it can't be a value of constants or attributes, but that's because then there's the issue of what happens when JS code updates them

[14:32:24.0304] 
But in the case of a returned dictionary, the empty one is `OrdinaryObjectCreate(%Object.prototype%)`

[14:32:39.0586] 
(https://webidl.spec.whatwg.org/#es-dictionary)

[14:37:48.0206] 
I'm not so worried about returned dictionaries. I just want to ensure that when using an empty dictionary as a default value, you don't risk inheriting missing properties from Object.prototype.

[14:38:21.0299] 
I guess if you're returning a dictionary for which some property is conditionally present that would be a concern.

[14:44:06.0834] 
It might actually be ambiguous in WebIDL. The spec is "Optional argument default values can also be specified using the two token value {}, which represents a default-initialized (as if from ES null or an object with no properties) dictionary value.", but as you say, null and "an object with no properties" could be interpreted as producing different dictionaries. 


2023-07-14
[00:38:54.0959] 
> <@jyasskin:matrix.org> It might actually be ambiguous in WebIDL. The spec is "Optional argument default values can also be specified using the two token value {}, which represents a default-initialized (as if from ES null or an object with no properties) dictionary value.", but as you say, null and "an object with no properties" could be interpreted as producing different dictionaries.

No it can't, there's actual normative prose elsewhere that will be unambiguous

[04:26:53.0738] 
annevk: https://github.com/mdn/content/pull/27927 would benefit from some of your attention

[07:30:57.0688] 
hey annevk I don't really understand this comment https://github.com/whatwg/html/pull/9452#discussion_r1247914359 -- I could reply as much but this has taken so long already (apologies I have been taking care of my mom for the last month) that I thought maybe here could be faster to clarify

[09:04:15.0288] 
bkardell: I don't have a lot of time right now, but the comment is that what you're saying it branches on and the branches themselves don't line up

[09:24:48.0235] 
> <@ms2ger:igalia.com> No it can't, there's actual normative prose elsewhere that will be unambiguous

"{}" only appears in WebIDL normative text twice, and the other just refers to this use. "Default-initialized" only appears once. Can you find the unambiguous normative prose for this?

[09:58:50.0782] 
Jeffrey Yasskin: presumably the normative requirement is the overload resolution algorithm followed by ES to dictionary conversion

[10:00:30.0800] 
ES->dictionary clearly specifies how `null` converts, and a fix would probably be to remove "or an object with no properties", but I don't see a place in overload resolution that mentions {} or default initialization.

[10:00:33.0361] 
Having said that, perhaps we should clarify that parenthetical

[10:01:25.0422] 
I think the `{}` is more of a syntax requirement on specifications to improve readability and doesn't translate into a requirement on Web IDL consumers

[10:09:44.0659] 
The requirement on WebIDL consumers comes from "If the argument at index i is declared with a default value, then append to values that default value." in https://webidl.spec.whatwg.org/#dfn-overload-resolution-algorithm, but it's only the text I quoted from https://webidl.spec.whatwg.org/#dfn-optional-argument-default-value that defines what the default value is. I fully believe that the text used to specify this precisely, but some refactoring must have lost it. I doubt anyone has actually implemented this differently; it's just a technical nit.

[10:45:39.0701] 
Jeffrey Yasskin: hmm yeah, file an issue? I couldn't find one

[10:46:47.0058] 
Great, blame isn't loading

[10:52:53.0179] 
Oh, it did: https://github.com/whatwg/webidl/commit/7329e8c62b5825376a52626a579a1890ac83cb29

[10:53:06.0695] 
So looking at that I don't think anything else was added at the time

[13:44:55.0226] 
bkardell: oh and hey, no need to apologize to me! I'm happy for you to take the time that you need. I should also note that I will be generally less available until August 20 or so. I have a couple more working days here and there and I'll try to prioritize this PR should you update it, but I'm personally in no rush. 😊


2023-07-17
[23:20:50.0253] 
TabAtkins:  https://drafts.fxtf.org/compositing/#abstract is showing something other than the expected spec. I guess that must be due to whatever underlying problem is causing https://api.csswg.org/bikeshed/ to not work as expected

[23:21:17.0532] 
 * TabAtkins:  https://drafts.fxtf.org/compositing/ is showing something other than the expected spec. I guess that must be due to whatever underlying problem is causing https://api.csswg.org/bikeshed/ to not work as expected

[23:22:37.0593] 
but it seems odd that https://drafts.fxtf.org/compositing/ would be the only spec that’s failing (which it is, as far as I can see)

[10:12:46.0151] 
sideshowbarker: it seems to be showing the expected spec now

[10:13:20.0835] 
But yeah, I think fxtf and houdini aren't using the same build setup as the csswg atm because we haven't gotten around to it, so if the server is hiccuping it might affect them.

[10:39:16.0827] 
> <@annevk:matrix.org> Jeffrey Yasskin: hmm yeah, file an issue? I couldn't find one

https://github.com/whatwg/webidl/issues/1344 Thanks bakkot too.

[15:51:43.0714] 
The web platform tests https://github.com/web-platform-tests/wpt/pull/41029 state that no reviewer could be found. The tests are for https://github.com/whatwg/html/issues/9518 and the corresponding spec  PR https://github.com/whatwg/html/pull/9527. Who would happen to be good folks to tag on the issue and PRs?


2023-07-18
[21:53:50.0711] 
I gave it a shot, although I'm not a layout person

[08:11:15.0655] 
annevk: When HTTP-redirect fetch is invoked, at this time response's URL list does not contain the location URL, right? In other words, response's URL (last URL list item) is the URL that redirected (to the location URL), right?

[08:12:06.0112] 
And then I believe we do a bunch of checks, and append the location URL to the request's URL list, and then once we get a response (maybe another redirect), we set the response's URL list to a clone of the request's URL list. Do I have the steps right here?

[13:05:00.0484] 
Hi Everyone,
I'm an enthusiast Django developer with 25 years of experience in IT, mainly handling DevOps jobs and architect infrastructure solutions for deployment on cloud.

I was thinking about whether we could add some functionalities to HTML to make it handle communication with backend APIs instead of using JavaScript to do the job. Would this make the frontend more secure for web applications and improve data privacy concerns of users?

I've also been wondering why there hasn't been much development happening with HTML after version 5.


2023-07-19
[18:20:08.0089] 
There has been a lot of development happening with HTML after "version 5". See https://github.com/whatwg/html/commits/main

[21:51:29.0627] 
> <@domenicdenicola:matrix.org> There has been a lot of development happening with HTML after "version 5". See https://github.com/whatwg/html/commits/main

HTML 5 version released in 2014, past 9 years I did not heard about any new version? Why cant we add few features to handle backend API for web applications in HTML? That will make a lot more things more secure and address the data privacy concerns of users.

At the time of HTML 3 in 1997 there was technology limitations to handle new features. As of 2023 we have powerful processors and large size storage and memory with pretty good internet connections with good bandwidth. Any thoughts guys?

[21:52:09.0195] 
 * Hi Everyone,
I'm an enthusiast Django/React/Anguar developer with 25 years of experience in IT, mainly handling DevOps jobs and architect infrastructure solutions for deployment on cloud.

I was thinking about whether we could add some functionalities to HTML to make it handle communication with backend APIs instead of using JavaScript to do the job. Would this make the frontend more secure for web applications and improve data privacy concerns of users?

I've also been wondering why there hasn't been much development happening with HTML after version 5.

[22:55:39.0361] 
There has been constant changes to the HTML specification since then, which browsers have been regularly shipping, there just hasn't been a new version

[22:56:00.0691] 
the HTML standard is now a living standard, that gets regularly updated at https://html.spec.whatwg.org/multipage

[22:56:19.0222] 
 * There has been constant changes to the HTML specification since then, which browsers have been regularly shipping, it just hasn't been released as a new major version

[22:56:25.0271] 
 * There has been constant changes to the HTML specification since then, which browsers have been regularly shipping, it just hasn't been released as major versions

[22:57:09.0278] 
https://whatwg.org/faq#living-standard

[23:01:02.0841] 
> <@abotella:igalia.com> There has been constant changes to the HTML specification since then, which browsers have been regularly shipping, it just hasn't been released as major versions

May I know why cant we add few features to handle backend API for web applications in HTML? That will make a lot more things more secure and address the data privacy concerns of users. Is there any technological bottle neck?

[23:03:00.0982] 
if there is a way to make such a thing more secure and address privacy concerns, it might make sense to implement it, but I don't see how it would

[23:03:13.0093] 
could you expand some more?

[23:06:03.0528] 
> <@abotella:igalia.com> if there is a way to make such a thing more secure and address privacy concerns, it might make sense to implement it, but I don't see how it would

Is it possible to communicate with backend API from HTML without the help of scripting languages?

[23:06:34.0330] 
I doubt so, since backend APIs are used for a lot of things, and I'm not sure how you'd cover most use cases for them without making the features that handle them a programming language unto itself

[23:09:42.0618] 
> <@abotella:igalia.com> I doubt so, since backend APIs are used for a lot of things, and I'm not sure how you'd cover most use cases for them without making the features that handle them a programming language unto itself

As simple as get the data from the backend API and display it on the web page (this is what we do with web applications in simple terms.) with HTML without any scripting languages. Hope this is clear?

[23:10:08.0209] 
with no processing?

[23:11:38.0483] 
> <@abotella:igalia.com> with no processing?

Server side processing? only validations happens at frontend right, no business logic in frontend

[23:14:46.0545] 
in my experience, there's a ton of business logic on the frontend

[23:15:28.0076] 
> <@abotella:igalia.com> in my experience, there's a ton of business logic on the frontend

Those are the data privacy concerns.

[23:17:08.0102] 
also useful business logic

[23:17:22.0027] 
the thing is, this new API would have to be attractive enough to existing users so they want to move away from their current solution

[23:17:36.0263] 
and what you're describing would just remove functionality that those existing users would be using

[23:18:46.0101] 
script would still be a thing, so there wouldn't be any actual security or privacy benefits if no one is using this new API

[23:19:02.0668] 
> <@abotella:igalia.com> the thing is, this new API would have to be attractive enough to existing users so they want to move away from their current solution

Why should we make them move, it is a personal choice and based on other requirements of the business.

[23:20:06.0385] 
May I know why cant we add few features to handle backend API for web applications in HTML? Is there any technological bottle neck?

[00:08:14.0468] 
Would that be possible to develop features for HTML to add interactivity to web pages, such as responding to user input, making changes to the content of the page, and loading new content from the server?

[00:12:22.0870] 
 * Would it be possible to develop features for HTML to add interactivity to web pages, such as responding to user input, making changes to the content of the page, and loading new content from the server in a minimalist way?

[00:19:22.0984] 
 * Would it be possible to develop features for HTML to add interactivity to web pages, such as responding to user input, making changes to the content of the page, and loading new content from the server in a minimalist way? Most of these are possible with HTML except loading new content from the server.
An example is a calculator made with HTML and CSS without any scripting.
https://codepen.io/Lovkiy/pen/KxxmNj

Would it be possible to make a feature in HTML to loading new content from the server?

[00:20:49.0426] 
that calculator does use javascript, it's in the `onclick` attributes

[00:22:50.0520] 
> <@abotella:igalia.com> that calculator does use javascript, it's in the `onclick` attributes

Could you please elaborate on it? I could not see any JS in the codepen JS box.

[00:23:51.0865] 
> <@abotella:igalia.com> that calculator does use javascript, it's in the `onclick` attributes

 * Could you please elaborate on it? I could not see any JS in the codepen JS box. Anyway just curious.

My real query is Would it be possible to make a feature in HTML to loading new content from the server?

[00:27:57.0793] 
the contents of the `onclick` attribute of `` is evaluated as JS when you click on it

[00:28:49.0301] 
> <@abotella:igalia.com> the contents of the `onclick` attribute of `` is evaluated as JS when you click on it

Thanks I have no idea. :-)

[00:29:15.0062] 
Would it be possible to make a feature in HTML to loading new content from the server?

[00:30:35.0969] 
Yes it would be technically possible. The main blocker is that you have to convince browsers and the various other html stakeholders that it's a good idea, and explain in detail how it would work.

[00:31:31.0647] 
Technical feasibility isn't the end-all-be-all. And I'm not convinced of the security and privacy advantages you claim it would have

[00:31:46.0861] 
but yeah, feel free to file an issue at https://github.com/whatwg/html

[04:04:16.0766] 
Domenic I'm not sure anymore that https://github.com/whatwg/html/pull/9520 is correct.
- Before that PR, the top-level worker module script was fetched with _outside settings_ and its settings object was set to _inside settings_. Then, all its dependencies where fetched with _inside settings_ and their settings object was _inside settings_.
- After that PR, all its dependencies are fetched with _outide settings_ and their settings object is _outside settings_.

where _outside settings_ and _inside settings_ are defined in https://html.spec.whatwg.org/#worker-processing-model 

Should the settings object of all the dependencies be _inside settings_ instead, while keeping the fetch client as _outside settings_? Is it observable in any way?

[04:05:42.0289] 
The behaviour after that PR matches the old behaviour before the modules loading refactor, but the fact that only the top-level module script has _inside settings_ as its settings object seems weird to me

[05:35:20.0095] 
> <@nicolo-ribaudo:matrix.org> Domenic I'm not sure anymore that https://github.com/whatwg/html/pull/9520 is correct.
> - Before that PR, the top-level worker module script was fetched with _outside settings_ and its settings object was set to _inside settings_. Then, all its dependencies where fetched with _inside settings_ and their settings object was _inside settings_.
> - After that PR, all its dependencies are fetched with _outide settings_ and their settings object is _outside settings_.
> 
> where _outside settings_ and _inside settings_ are defined in https://html.spec.whatwg.org/#worker-processing-model 
> 
> Should the settings object of all the dependencies be _inside settings_ instead, while keeping the fetch client as _outside settings_? Is it observable in any way?

Oh dang, oops. Yes, the fetch client should be outside settings, with the settings object being inside settings. That is pretty important. The observability is in the various callers of https://html.spec.whatwg.org/#classic-script . Sigh, sorry I missed that in review.

[06:49:44.0437] 
> <@domenicdenicola:matrix.org> Oh dang, oops. Yes, the fetch client should be outside settings, with the settings object being inside settings. That is pretty important. The observability is in the various callers of https://html.spec.whatwg.org/#classic-script . Sigh, sorry I missed that in review.

I'll open an issue about it, but I will not work on a fix until after the params renaming PR is merged (given that every single line would conflict)

[10:29:00.0690] 
Is it a good idea to think about making the form submission in HTML can be like AJAX requests?

[10:36:29.0178] 
 * Is it a good idea to think about making the existing form submission method in HTML can be like AJAX requests?


2023-07-20
[08:36:44.0774] 
If someone familiar with image lazy loading could take a minute to look at https://github.com/mdn/content/pull/28077 and comment, that would be great. That change is adding this note:
> **Note:** Images that have `loading` set to `lazy` will never be loaded if their width or height is `0`, even if loading them would change that.

[08:39:16.0096] 
sideshowbarker: This isn't an answer, but IIRC it's based on IntersectionObserver, I wonder if that's spec'd to fire when elements have no area

[08:39:32.0674] 
aha

[08:45:41.0837] 
from a quick read through https://w3c.github.io/IntersectionObserver/#run-the-update-intersection-observations-steps, I can’t tell

[08:50:20.0798] 
sideshowbarker: Because the lazyload spec uses the default threshold of zero, I think it is supposed to fire: https://wpt.fyi/results/intersection-observer/same-document-zero-size-target.html

[08:51:31.0582] 
I'll comment and if I'm wrong maybe somebody else will chime in (:

[08:51:59.0571] 
Cheers and thanks 👍

[14:08:01.0249] 
does JS support 64 bit numbers yet?

[14:10:15.0388] 
i'm trying to parse a binary data format that uses quadwords as the main building block

[14:19:16.0095] 
Ian Hickson: are you looking for https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt64Array and/or https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigUint64Array ?

[14:21:45.0565] 
ideally i would like to be able to store a 64 bit int in a variable and do maths with it

[14:24:42.0529] 
yes, that is possible with BigInt

[14:58:13.0724] 
for example:
```
// Make an array-like view over a byte buffer containing the data for
// 3 big-endian uint64s with the first two set to 2**63 - 1.
const uint8View = new Uint8Array([
  127, ...Array(7).fill(255),
  127, ...Array(7).fill(255),
  ...Array(8),
]);
const dataView = new DataView(uint8View.buffer);
const uint64View = {
  get: i => dataView.getBigUint64(i * 8),
  set: (i, n) => dataView.setBigUint64(i * 8, n),
};

// Read the first two values and set the third to their sum.
const a = uint64View.get(0);
const b = uint64View.get(1);
assert(a === 2n ** 63n - 1n, "a");
assert(b === 2n ** 63n - 1n, "b");
const c = a + b;
uint64View.set(2, c);

// Verify the results from both perspectives.
assert(uint64View.get(2) == 2n ** 64n - 2n, "c");
assert.deepEqual(uint8View.slice(0, 8), [127, ...Array(7).fill(255)], "a bytes");
assert.deepEqual(uint8View.slice(8, 16), [127, ...Array(7).fill(255)], "b bytes");
assert.deepEqual(uint8View.slice(16, 24), [...Array(7).fill(255), 254], "c bytes");
```


2023-07-21
[02:51:30.0138] 
Is the build for fetch broken on main? Locally I'm seeing:
```
jgraham@goldfinch:~/develop/fetch$ git fetch origin 
jgraham@goldfinch:~/develop/fetch$ git checkout main 
Switched to branch 'main'
Your branch is up to date with 'origin/main'.
jgraham@goldfinch:~/develop/fetch$ make
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  374k    0   146  100  374k     18  49062  0:00:07  0:00:07 --:--:--    40

Error running preprocessor, returned code: 2.
FATAL ERROR: Spurious / in <a>.
 ✘  Did not generate, due to fatal errors
make: *** [Makefile:5: remote] Error 22

```

[02:53:01.0598] 
`make local` works fine, so maybe there's a difference between the remote version of bikeshed and the local one?

[02:54:27.0996] 
(also I really do prefer specs that don't depend on make for unclear reasons)

[02:58:16.0488] 
Why are the reasons unclear?

[02:59:07.0883] 
This might be the Bikeshed parser changes TabAtkins made. I'm not sure if he tested those on just the tests or also live copies of the current specifications. I haven't really done any specification development recently.

[05:01:18.0580] 
jgraham: I suspect it's failing on main: https://github.com/whatwg/fetch/pull/1655#issuecomment-1642314570

[09:15:58.0143] 
Because specs have trivial dependency graphs, so they don't need any of the features of a complex build system, meanwhile the build system itself becomes an additional requirement. Plus make itself is only well understood by relatively few people.

[09:24:49.0373] 
I mean, we could replace it with something else, but what else is as cross-platform and readily available?

[10:48:16.0079] 
I tested on all the specs, but I still don't track build messages in the testsuite, that'll be fixed this quarter. So Fetch builds an *identical output*, it just has a different set of messages. (Apologies for that.)

[10:48:21.0274] 
anyway lemme see what's up

[10:54:15.0466] 
Ah, it's actually catching a legimately broken tag.

[10:54:27.0539] 
``, meant to be ``

[10:56:58.0306] 
https://github.com/whatwg/fetch/pull/1689

[10:56:59.0937] 
annevk: ^^^


2023-07-22
[19:49:21.0984] 
> <@tabatkins:matrix.org> I tested on all the specs, but I still don't track build messages in the testsuite, that'll be fixed this quarter. So Fetch builds an *identical output*, it just has a different set of messages. (Apologies for that.)

I'm a bit confused by this, with a FATAL ERROR there is no output, so shouldn't the difference between the empty string and the actual fetch spec be detectable?

[20:03:43.0461] 
No, I build the test suite with -f. Otherwise many, many specs would have no output.

[21:25:12.0714] 
Could you build WHATWG specs like they are built by the WHATWG, instead?

[14:42:43.0861] 
No, because that would mean if something became a fatal error I'd have zero output. What I will do, as I just said, is capture build messages in the test artifacts, so I can tell what else is happening.

[14:43:43.0007] 
(For example, the testsuite does not capture or use your make script, so the sha macro y'all use in your boilerplate doesn't match. That's a fatal error! But it's also irrelevant for testing purposes, and I have plenty of macro tests elsewhere.)


2023-07-23
[20:26:18.0895] 
> <@tabatkins:matrix.org> No, because that would mean if something became a fatal error I'd have zero output. What I will do, as I just said, is capture build messages in the test artifacts, so I can tell what else is happening.

Why is zero output for fatal errors a problem? Fatal errors in WHATWG specs prevent us from deploying them.

[20:26:42.0381] 
> <@tabatkins:matrix.org> (For example, the testsuite does not capture or use your make script, so the sha macro y'all use in your boilerplate doesn't match. That's a fatal error! But it's also irrelevant for testing purposes, and I have plenty of macro tests elsewhere.)

Yes, you would need to update the test suite to supply the SHA macro, just like you'd need to update it to stop using -f, for WHATWG specs.

[06:11:02.0205] 
Can someone rubber-stamp https://github.com/whatwg/meta/pull/268?


2023-07-24
[02:43:42.0808] 
> I mean, we could replace it with something else, but what else is as cross-platform and readily available?

Ideally typing `bikeshed spec` would result in a functional build. 

[02:47:05.0528] 
jgraham: that doesn't meet our requirements

[02:52:38.0480] 
OK, but "WHATWG specs have a worse dev experience than W3C specs" seems like a problem worth addressing (and I'm sure the people who work on these specs all the time have internalised the workflow and don't notice this problem). 

[03:02:17.0929] 
I'd be happy for someone to address that, though I also don't think that statement really holds

[03:03:03.0322] 
I've tried contributing to ARIA and some other W3C documents and they're generally a mess with very custom solutions, lots of warnings, linking errors, etc.

[03:17:59.0193] 
Well I'm sure there's some variety on the W3C side. But the best case scenario is that you can download any spec and type `bikeshed spec` to get a build and `bikeshed serve` to get a local webserver with auto-rebuild, and afaict the current WHATWG template means that neither of those things can work because you always need to look up extra command line arguments to fill in the `COMMIT-SHA` macro, so it might be that you could just make that optional and you'd already be most of the way there (and if it was up to me I'd then inline the deploy steps into the GitHub action, accept that anyone who does any non-trivial spec work is going to end up running bikeshed locally and forget about the `remote` target, and then delete the makefiles entirely to avoid having a complex tool just to more or less wrap three shell commands)

[03:19:02.0117] 
 * Well I'm sure there's some variety on the W3C side. But the best case scenario is that you can download any spec and type `bikeshed spec` to get a build and `bikeshed serve` to get a local webserver with auto-rebuild, and afaict the current WHATWG template means that neither of those things can work because you always need to look up extra command line arguments to fill in the `COMMIT-SHA` macro.

So it might be that you could just make that macro optional and you'd already be most of the way there (and if it was up to me I'd then inline the deploy steps into the GitHub action, accept that anyone who does any non-trivial spec work is going to end up running bikeshed locally and forget about the `remote` target, and then delete the makefiles entirely to avoid having a complex tool just to more or less wrap three shell commands)

[09:14:26.0083] 
> <@domenicdenicola:matrix.org> Why is zero output for fatal errors a problem? Fatal errors in WHATWG specs prevent us from deploying them.

Because I prefer Bikeshed being robust to failure as much as possible, so you can run with `-f` and still get something reasonable rather than forcing people to have a fully working build. (That is, the messages are intended to be lint-level as much as possible; it's of course reasonable to require zero linting errors to publish/update.) That implies I want visibility into the build result regardless. It is just *also* the case, again, that I should be capturing the messages so I know when I'm throwing more or different errors than I previously did. Like I said, this is going to be fixed.

[09:17:15.0514] 
> <@jgraham_:matrix.org> Well I'm sure there's some variety on the W3C side. But the best case scenario is that you can download any spec and type `bikeshed spec` to get a build and `bikeshed serve` to get a local webserver with auto-rebuild, and afaict the current WHATWG template means that neither of those things can work because you always need to look up extra command line arguments to fill in the `COMMIT-SHA` macro.
> 
> So it might be that you could just make that macro optional and you'd already be most of the way there (and if it was up to me I'd then inline the deploy steps into the GitHub action, accept that anyone who does any non-trivial spec work is going to end up running bikeshed locally and forget about the `remote` target, and then delete the makefiles entirely to avoid having a complex tool just to more or less wrap three shell commands)

Hm, let me raise a whatwg/meta issue, I agree that this can probably be simplified without losing any requirements, but want to make sure I'm not missing anything.

[09:39:15.0539] 
Okay filed https://github.com/whatwg/meta/issues/286 and https://github.com/whatwg/meta/issues/287

[09:39:38.0124] 
depending on how those shake out we can talk about dropping `make remote` and removing the makefile entirely

[09:40:34.0566] 
annevk: I like what you did with `:dir`


2023-07-25
[17:32:02.0831] 
> <@tabatkins:matrix.org> Because I prefer Bikeshed being robust to failure as much as possible, so you can run with `-f` and still get something reasonable rather than forcing people to have a fully working build. (That is, the messages are intended to be lint-level as much as possible; it's of course reasonable to require zero linting errors to publish/update.) That implies I want visibility into the build result regardless. It is just *also* the case, again, that I should be capturing the messages so I know when I'm throwing more or different errors than I previously did. Like I said, this is going to be fixed.

But again, this is about WHATWG specs. THey *don't* prefer to be robust to failure; they prefer to fail-fast (like your new HTML parser). We're asking that you reflect that in your test suite, so your test suite gets the same failures as the actual live environment.

[17:34:05.0317] 
Capturing the build messages will accomplish the same thing (any messages at all are bad for whatwg specs) without making me lose output entirely when there's a change in build messages. 

[17:34:46.0182] 
The thing you're actually asking for (ensure that new messages don't break your build) is on my task list this quarter.

[17:49:44.0050] 
I just think there's a lot to be said for having tests match prod

[07:09:43.0566] 
Hello. I hope this is my last cross-post. I was pointed to this room to ask my question.

[07:10:00.0087] 
i should probably raise this to whatwg, but i was wondering why are user agents required to load `about:blank` in quirks mode? is there a specific reason? if not, shouldn't step 2 of [loading an HTML document](https://html.spec.whatwg.org/multipage/document-lifecycle.html#read-html) include something like

> 1. Let _doctype_ be the result of creating a document type with the qualified name of "html"
> …
> 5 Append _doctype_ to _document_.

or similar steps?

[07:16:42.0706] 
The answer to "why" is "because that's what browsers have done historically"

[07:17:30.0180] 
The answer to "and why did they do that" is that that's the result of parsing an empty byte stream (i.e., without a doctype) as html

[07:44:50.0292] 
And the answer to "why don't they change that" is it seems relatively risky to change for a relatively small gain.

[08:02:48.0767] 
> <@ms2ger:igalia.com> The answer to "and why did they do that" is that that's the result of parsing an empty byte stream (i.e., without a doctype) as html

Isn't it still populated with `html/head/body`? There doesn't seem to be any parsing done within this branch. That answer doesn't sound plausible to me. Could it have been just an oversight?

[08:08:18.0921] 
Try feeding an empty html document to your favourite browser and you'll see that it does indeed get html, head and body elements

[11:39:25.0298] 
I think if you ask hsivonen or someone else who's worked on this they might s/relatively risky/very risky/ or maybe just say "totally unworkable given webcompat constraints"

[11:43:40.0533] 
For what is worth, I think inheriting about:blank quirk-ness for frames and popups could be nice. I've seen site bugs related to that. But yeah rather risky, because `document.write()`-ing inside an `about:blank` document is rather common

[11:44:26.0508] 
I think I'd take or write a patch to firefox to do that behind a pref to investigate compat, if others think it's worth the effort

[11:44:54.0757] 
But should probably be a cross-vendor effort, and maybe a hill not worth spending resources on

[11:45:33.0972] 
But yeah hsivonen (away from Matrix until 2023-08-07) would probably have more context


2023-07-26
[17:04:50.0617] 
Is there any movement on Contact Picker API?
And, is there any shim/polyfill for Contact Picker API that works in all browsers? Or any alternative approach?

[19:05:49.0347] 
Domenic: Just want to clarify what you mean by "blow up", in https://github.com/whatwg/html/issues/9488#issuecomment-1650858581. The spec wouldn't crash, right? I think we'd just a get a network error because we'd enter #create-navigation-params-by-fetching, right?

[19:06:24.0902] 
I admit I was typing that on my phone without looking at the spec, let me try harder

[19:07:46.0683] 
Np. I _think_ regardless of whether we decide to use "is" or "matches", we end up with a network error and an error document in the document state.

[19:09:50.0097] 
Unrelated: why is https://html.spec.whatwg.org/#concept-document-salvageable italicized (in dfn and all refs). Seems random?

[19:10:23.0972] 
Hmm yeah you're right, it'd end up trying to fetch it. Srcdoc processing is keyed on documentResource not URL (in the spec)

[19:10:49.0374] 
Right. Its just that Chrome has this open bug where we still allow it to resolve in some cases

[19:10:50.0976] 
And using "is" is probably better to keep those in sync

[19:11:09.0826] 
(I believe Arthur was trying to remove that behavior and match the spec, but ran into some difficulty)

[19:11:36.0685] 
Cool, thanks for taking a look so quickly

[19:14:26.0251] 
Now I'm trying to think through if it ever matters what's in the error document state's "origin" field in that scenario...


2023-07-27
[11:03:36.0716] 
Hey, I had a quick question. What is the reason for the port to be set to 'null' if it is equal to the URL scheme's default port?

https://url.spec.whatwg.org/#port-state
> Set url’s port to null, if port is url’s scheme’s default port; otherwise to port.

[14:16:45.0063] 
I’m having trouble finding an answer to this online: Was there any discussion about making FileSystemSyncAccessHandle usable by SharedWorkers?

[14:19:17.0758] 
 * I’m having trouble finding an answer to this online: FileSystemSyncAccessHandle is usable by dedicated Web Workers but not by Shared Workers. Has there been any discussion exploring possibly making it usable by Shared Workers? (Asking after reading https://github.com/rhashimoto/wa-sqlite/discussions/81.)

[14:19:29.0030] 
 * I’m having trouble finding an answer to this online: FileSystemSyncAccessHandle is usable by dedicated Web Workers but not by Shared Workers. Has there been any discussion exploring possibly making it usable by Shared Workers? (I’m asking this after reading https://github.com/rhashimoto/wa-sqlite/discussions/81.)


2023-07-28
[17:52:38.0626] 
> <@briandoesdev:matrix.org> Hey, I had a quick question. What is the reason for the port to be set to 'null' if it is equal to the URL scheme's default port?
> 
> https://url.spec.whatwg.org/#port-state
> > Set url’s port to null, if port is url’s scheme’s default port; otherwise to port.

Basically, because the canonical form of `https://example.com:443/` is `https://example.com/`, not `https://example.com:443/`. This is most important when serializing, but maybe has some other impacts too.

[20:29:48.0500] 
Some troubleshooting help with https://github.com/mdn/content/issues/28222 would be welcome


2023-07-29
[09:15:56.0566] 
> <@jschoi:matrix.org> I’m having trouble finding an answer to this online: FileSystemSyncAccessHandle is usable by dedicated Web Workers but not by Shared Workers. Has there been any discussion exploring possibly making it usable by Shared Workers? (I’m asking this after reading https://github.com/rhashimoto/wa-sqlite/discussions/81.)

Answering my own question from two days ago: I just found https://github.com/whatwg/html/issues/8362, which would address rhashimoto/wa-sqlite#81 without requiring communication between workers’ tabs. Unfortunately the issue seems to have been initially coupled to web-extension use cases. But SQLite would be useful for shared workers and service workers for general web apps outside of web extensions, and hopefully this will be explored in the future.

[09:17:10.0406] 
> <@jschoi:matrix.org> I’m having trouble finding an answer to this online: FileSystemSyncAccessHandle is usable by dedicated Web Workers but not by Shared Workers. Has there been any discussion exploring possibly making it usable by Shared Workers? (I’m asking this after reading https://github.com/rhashimoto/wa-sqlite/discussions/81.)

 * Answering my own question from two days ago: I just found https://github.com/whatwg/html/issues/8362, which would address rhashimoto/wa-sqlite#81 without requiring communication between workers’ tabs. Unfortunately the issue seems to have been initially coupled to web-extension use cases. But SQLite would be useful for shared workers and service workers for general web apps (particularly offline-first web apps) and not just web extensions, and, hopefully, service workers spawning workers will be explored more in the future.


2023-07-30
[19:34:14.0882] 
About the “sandboxed origin browsing context flag”, how I can figure out which APIs it affects in addition to `document.cookies` and `localStorage`?

[19:35:15.0768] 
 * About the “sandboxed origin browsing context flag”, how I can figure out which APIs it affects in addition to `document.cookies` and `localStorage`? https://html.spec.whatwg.org/multipage/browsers.html#sandboxed-origin-browsing-context-flag

Or more specifically, if I have an iframe without `allow-same-origin`, which APIs are not going to work in that iframe?

[19:38:19.0680] 
> <@sideshowbarker:matrix.org> About the “sandboxed origin browsing context flag”, how I can figure out which APIs it affects in addition to `document.cookies` and `localStorage`? https://html.spec.whatwg.org/multipage/browsers.html#sandboxed-origin-browsing-context-flag
> 
> Or more specifically, if I have an iframe without `allow-same-origin`, which APIs are not going to work in that iframe?

Any API which does origin checks will be affected... so, many of them. Searching for links to #concept-document-origin will work...

[20:05:28.0619] 
incidentally, the specific context is the behavior of the “Playground” in MDN — which is a feature where you can directly edit code MDN-article code snippets directly in the browser, and see the results immediately.

So if you go for example to https://webdocs.dev/en-us/docs/web/api/document/cookie#example_1_simple_usage and click the Play link, it opens a new tab to https://webdocs.dev/en-us/play with the content of the snippets from that MDN article. And if you inspect the source for the iframe in the right-hand side there, you’ll see this:
```html

```
notice the URL, https://ab457e4a-7a76-49c5-ad28-d5b08e7bfbdc.mdnplay.dev/en-US/docs/Web/CSS/minmax/runner.html

It’s a dynamically-generated subdomain. And if you want to try replicating the hosting for that, it requires some relatively complex DNS setup.

[20:10:08.0253] 
But if instead you just don’t use `allow-same-origin` in the `sandbox` value of the iframe, then you can just use the same origin, and you don’t need to do any complex DNS setup.

The tradeoff is that anything you run from that iframe that requires an origin check won’t work in the “Playground” environment.

So for users, that would mean that for any of those articles that have code snippets with features that `allow-same-origin` to work as expected, the users won’t be able to have the convenience of using the Playground to test changing the code from the snippets and to see the effects.

[20:10:23.0017] 
 * incidentally, the specific context is the behavior of the “Playground” in MDN — which is a feature where you can directly edit MDN-article code snippets directly in the browser, and see the results immediately.

So if you go for example to https://webdocs.dev/en-us/docs/web/api/document/cookie#example\_1\_simple\_usage and click the Play link, it opens a new tab to https://webdocs.dev/en-us/play with the content of the snippets from that MDN article. And if you inspect the source for the iframe in the right-hand side there, you’ll see this:

```html

```

notice the URL, https://ab457e4a-7a76-49c5-ad28-d5b08e7bfbdc.mdnplay.dev/en-US/docs/Web/CSS/minmax/runner.html

It’s a dynamically-generated subdomain. And if you want to try replicating the hosting for that, it requires some relatively complex DNS setup.

[20:12:02.0220] 
 * But if instead you just don’t use `allow-same-origin` in the `sandbox` value of the iframe, then you can just use the same origin, and you don’t need to do any complex DNS setup.

The tradeoff is that anything you run from that iframe that requires an origin check won’t work in the “Playground” environment.

So for users, that would mean that for any of those articles that have code snippets with features which require `allow-same-origin` to work as expected, the users won’t be able to have the convenience of using the Playground to test changing the code from the snippets and to see the effects.

[20:25:44.0451] 
 * incidentally, the specific context is the behavior of the “Playground” in MDN — which is a feature where you can directly edit MDN-article code snippets directly in the browser, and see the results immediately.

So if you go for example to https://webdocs.dev/en-us/docs/web/api/document/cookie#example\_1\_simple\_usage and click the Play link, it opens a new tab to https://webdocs.dev/en-us/play with the content of the snippets from that MDN article. And if you inspect the source for the iframe in the right-hand side there, you’ll see this:

```html

```

notice the URL, https://ab457e4a-7a76-49c5-ad28-d5b08e7bfbdc.mdnplay.dev/en-US/docs/Web/CSS/minmax/runner.html

It’s a dynamically-generated subdomain. And if you want to try replicating the hosting for that, it requires some relatively complex DNS setup.

[20:26:14.0918] 
 * But if instead you just don’t use `allow-same-origin` in the `sandbox` value of the iframe, then you can just host the iframe from the same origin, and you don’t need to do any complex DNS setup.

The tradeoff is that anything you run from that iframe that requires an origin check won’t work in the “Playground” environment.

So for users, that would mean that for any of those articles that have code snippets with features which require `allow-same-origin` to work as expected, the users won’t be able to have the convenience of using the Playground to test changing the code from the snippets and to see the effects.

[21:43:45.0591] 
Yeah, but if you allow same-origin access, then playground scripts can steal cookies and such. Not sure what MDN's security model is for the playground but it's generally best practice not to let arbitrary script run in such un-sandboxed iframes. (allow-same-origin undoes most of what we think of as sandboxing.)

[22:04:42.0082] 
> <@domenicdenicola:matrix.org> Yeah, but if you allow same-origin access, then playground scripts can steal cookies and such. Not sure what MDN's security model is for the playground but it's generally best practice not to let arbitrary script run in such un-sandboxed iframes. (allow-same-origin undoes most of what we think of as sandboxing.)

OK thanks — that makes me even more convinced that it’d be much better not use `allow-same-origin` on those iframes. Given that the goal is to give developers authoritative guidance on how to use web-platform features, deploying the article code content in a way that conflicts with best practices is not a great way to model things for developers.

[22:14:58.0272] 
Domenic: I now wonder if we should a (non-normative) Note to the spec:
> Using the `allow-same-origin` keyword undoes most of what we think of as sandboxing. In particular, it’s generally best practice not to let arbitrary scripts run in iframes that have effectively been un-sandboxed due to the `allow-same-origin` keyword being specified.

[22:15:06.0215] 
 * Domenic: I now wonder if we should a (non-normative) Note to the spec:

> _Using the `allow-same-origin` keyword undoes most of what we think of as sandboxing. In particular, it’s generally best practice not to let arbitrary scripts run in iframes that have effectively been un-sandboxed due to the `allow-same-origin` keyword being specified._

[22:16:05.0811] 
 * Domenic: I now wonder if we should a (non-normative) Note to the spec:

> _Using the `allow-same-origin` keyword undoes most of what we think of as sandboxing. In particular, it’s generally best practice not to let arbitrary script run in iframes that have effectively been un-sandboxed due to the `allow-same-origin` keyword being specified._

[22:16:34.0964] 
Sorry, I think there are a lot of double-negatives that are confusing things...

[22:16:56.0237] 
> `sandbox="allow-same-origin"`: this is insecure. This allows cookie-stealing.

> `sandbox=""`: this is more secure. This prevents bad things.

[22:19:43.0295] 
OK that I understand — but I guess my (re)wording doesn’t convey that clearly

[22:21:36.0343] 
the iframes in this case would still be deployed with `sandbox="allow-scripts` — just not with `sandbox="allow-scripts allow-same-origin"` (as MDN is currently doing, and which is insecure)

[22:21:49.0577] 
 * the iframes in this case would still be deployed with `sandbox="allow-scripts`" — just not with `sandbox="allow-scripts allow-same-origin"` (as MDN is currently doing, and which is insecure)

[22:22:15.0369] 
 * the iframes in this case would still be deployed with `sandbox="allow-scripts"` — just not with `sandbox="allow-scripts allow-same-origin"` (as MDN is currently doing, and which is insecure)

[22:34:53.0715] 
I guess MDN's setup is "insecure" in that code running on `https://ab457e4a-7a76-49c5-ad28-d5b08e7bfbdc.mdnplay.dev/` can mess with other code running on that domain. But presumably the idea is that only one piece of code ever runs on that domain? So it's probably secure enough.

[22:39:22.0057] 
Yeah, all the content at those URLs is ephemeral. If you navigate directly to https://ab457e4a-7a76-49c5-ad28-d5b08e7bfbdc.mdnplay.dev/, you’ll see there’s no `body` content there at all, and if you navigate directly to the https://webdocs.dev/en-us/play parent, it’s not populated with anything. It only gets populated when you open a Play link from any particular MDN article.

[12:32:51.0111] 
Hello, I want to implement a subset of the HTML standard and from what I've gathered the strings in the DOM need to be UTF-16 encoded. Is this caused by JavaScript and, if yes, what would it change if I were to use UTF-8 instead?


2023-07-31
[18:47:52.0491] 
Where did you gather that strings need to be UTF-16 encoded?

[11:38:12.0818] 
https://infra.spec.whatwg.org/#string