2021-07-01
[01:34:35.0083] <sujaldev>
Hi, Can anyone please describe what is exact procedure to "Consume the maximum number of characters possible" mentioned here: https://html.spec.whatwg.org/#named-character-reference-state

[01:35:32.0274] <sujaldev>
 * Hi, Can anyone please describe what is the exact procedure to "Consume the maximum number of characters possible" mentioned here: https://html.spec.whatwg.org/#named-character-reference-state

[01:45:30.0344] <Andreu Botella (he/they)>
Hm, there's arguably a bug there, since the string `&centerNotDot;` should only match the charref `&center`, rather than the prefix of `&centerdot;`

[01:46:08.0081] <Andreu Botella (he/they)>
 * Hm, there's arguably a bug there, since the string `&centerd;` should only match the charref `&center`, rather than the prefix of `&centerdot;`

[01:47:44.0487] <Andreu Botella (he/they)>
 * Hm, there's arguably a bug there, since the string `&centerd;` should only match the charref `&cent`, rather than the prefix of `&centerdot;`

[01:47:55.0225] <Andreu Botella (he/they)>
 * Hm, there's arguably a bug there, since the string `&center` should only match the charref `&cent`, rather than the prefix of `&centerdot;`

[01:50:21.0827] <sujaldev>
So what's the correct way to do this?

[01:51:45.0453] <Andreu Botella (he/they)>
Keep a copy of the named character references list, and for every consumed character, remove the entries that don't match up for that character

[01:53:07.0308] <Andreu Botella (he/they)>
But keep in a variable the latest entry that you have consumed in full (that is, for which the next character would be end-of-string)

[01:54:29.0619] <Andreu Botella (he/they)>
Once the list is empty, unconsume as many characters as (number of characters you've consumed in this algorithm - length of the latest entry consumed in full or 0)

[01:54:52.0418] <Andreu Botella (he/they)>
the latest entry consumed in full is the match you've found, if there is any

[01:56:27.0036] <sujaldev>
sorry to ask a stupid question but what does it mean to "unconsume" here?

[01:59:31.0276] <Andreu Botella (he/they)>
To walk back the pointer into the input stream, such that the next input characters would be the characters after the end of the matched character reference, even if in parsing you've consumed more characters than those

[02:00:40.0500] <sujaldev>
oh ok! thank you for the help!!

[02:08:20.0816] <Andreu Botella (he/they)>
If it's not very obvious, that part of the algorithm tries to find the longest character reference that matches the input

[02:09:19.0036] <Andreu Botella (he/they)>
So both `cent` and `centerdot;` are character references, so if the next few characters are `center;`, you want to match `cent` only

[02:09:39.0867] <Andreu Botella (he/they)>
If you're reading character by character, you would have to read `center` and then backtrack when you find the semicolon

[02:10:46.0708] <Andreu Botella (he/they)>
but if you do find `centerdot;` you want to take that as the match, not `cent`

[02:24:05.0296] <sujaldev>
So from what I understand from the above explanation an html stream <p>center;</p> would be read as <p>&cent;er</p>

right?

[02:24:39.0229] <sujaldev>
displayed as:
¢er;

[02:24:57.0635] <sujaldev>
 * So from what I understand from the above explanation an html stream <p>center;</p> would be read as <p>&cent;er;</p>

right?

[02:28:39.0856] <sideshowbarker>
sujaldev: `center;` would never reach that algorithm — because `center;` doesn’t begin with an `&` ampersand 

[02:29:24.0528] <sujaldev>
sorry i mean &center;

[02:29:48.0033] <sujaldev>
let me just edit that

[02:29:55.0501] <sujaldev>
 * So from what I understand from the above explanation an html stream <p>&center;</p> would be read as <p>&cent;er;</p>

right?

[02:31:34.0810] <Andreu Botella (he/they)>
¢er; indeed

[02:32:32.0163] <sujaldev>
trying to implement it now in my project! thank you again!

[02:35:01.0390] <sideshowbarker>
sujaldev: I guess you probably already know about the html5lib test suite, but if not, you definitely want to be testing your implementation against that — https://github.com/html5lib/html5lib-tests

[02:36:37.0199] <sideshowbarker>
and not to muddy the waters, but it’s worth mentioning that you don’t need to match the steps in that part of the parsing algorithm exactly, as long as you end up with the same result

[02:37:39.0469] <sujaldev>
> <@sideshowbarker:mozilla.org> sujaldev: I guess you probably already know about the html5lib test suite, but if not, you definitely want to be testing your implementation against that — https://github.com/html5lib/html5lib-tests

I didn't know about this, real helpful.

[02:37:53.0647] <sideshowbarker>
yeah for https://github.com/validator/htmlparser we don’t match the spec steps exactly for that part of the algorithm, but do it in a different way that produces the same test results

[02:39:28.0599] <sujaldev>
does it still follow state machine concept?

[02:39:54.0295] <sideshowbarker>
yes

[02:41:52.0317] <sideshowbarker>
there are some places where it doesn’t conform to the spec, and I’ve had some pull requests open for quite a while now to fix those, but… fixing them has not been a big priority for that particular project

[02:43:49.0582] <sujaldev>
> <@sideshowbarker:mozilla.org> yeah for https://github.com/validator/htmlparser we don’t match the spec steps exactly for that part of the algorithm, but do it in a different way that produces the same test results

If I knew more about parsing and also knew java would have loved to contribute to this

[10:04:46.0615] <shu>
how do overloads work in WebIDL? specifically, for `Window.alert`, which is spec'd to have two overloads `alert()` and `alert(message)`, what's `alert.length` supposed to be?

[11:13:00.0225] <zcorpan>
shu: https://heycam.github.io/webidl/#dfn-create-operation-function

[11:13:13.0710] <zcorpan>
step 6

[13:44:26.0768] <shu>
zcorpan: thanks

[15:19:54.0928] <timothygu>
shu: what's the plan for https://github.com/heycam/webidl/pull/982? is it waiting on ES still?

[16:08:51.0806] <shu>
timothygu: resizable buffers is stage 3, so i was planning on requesting to merge that after there's at least one implementation shipping

[16:09:18.0200] <shu>
it's a fairly big proposal to implement, actually, so we might not see anything till Q4

[16:09:43.0714] <timothygu>
okay, I converted it to a draft in the meantime

[16:09:54.0783] <shu>
ah okay, is that the convention?

[16:39:50.0394] <Domenic>
We invented a "do not merge yet" convention for WHATWG repos before draft PRs existed. These days it seems like a mix.

[16:39:58.0724] <Domenic>
 * We invented a "do not merge yet" label convention for WHATWG repos before draft PRs existed. These days it seems like a mix.


2021-07-02
[17:21:15.0592] <shu>
i thought "Draft" meant something like the author was still modifying it, and it wasn't ready for review

[17:21:37.0400] <shu>
and something like "do not merge" is, its contents are ready to go, but it's gated on other things

[18:31:34.0710] <Domenic>
Yeah I think I personally prefer that taxonomy

[22:56:15.0402] <sideshowbarker>
for using Node.js in Github Actions, rather than needing specify any particular Node.js version, is there some way I can specify “just use the latest available Node.js version”?

[07:21:56.0344] <DerekNonGeneric>
sideshowbarker: looks like it uses to `nvm` (bash version) syntax https://github.com/actions/setup-node#supported-version-syntax

[07:22:19.0579] <sideshowbarker>
/me looks

[07:22:44.0738] <sideshowbarker>
so is there an `nvm` syntax for “latest”?

[07:23:27.0376] <sideshowbarker>
I know there’s `lts/*`, but that’s not latest-latest

[07:24:03.0354] <DerekNonGeneric>
might just be `node` according to the docs https://github.com/nvm-sh/nvm#usage

[07:24:31.0040] <DerekNonGeneric>
> # "node" is an alias for the latest version

[07:26:07.0647] <DerekNonGeneric>
(have not actually tested this myself)

[07:28:18.0239] <sideshowbarker>
oh cool — will try that

[07:31:42.0389] <sideshowbarker>
dang, didn’t work

[07:31:58.0361] <sideshowbarker>
https://github.com/w3c/mdn-spec-links/actions/runs/993930895
> Unable to find Node version 'node' for platform linux and architecture x64.


[07:32:48.0692] <sideshowbarker>
no big deal, though — for the specific context, any version >=15 works fine

[07:33:35.0565] <sideshowbarker>
I just need support for `.replaceAll()`, but the default node in Ubuntu latest is too old to have that

[07:33:53.0518] <sideshowbarker>
so I guess I’ll just use `16`

[07:35:46.0829] <DerekNonGeneric>
yeah, the latest-even number versions will last a while

[07:35:58.0853] <sideshowbarker>
yeah


2021-07-03
[00:18:03.0659] <Sarath kumar>
HI, can anyone tell me how to design this type of card ?


[00:26:31.0214] <DerekNonGeneric>
the "design" is self-evident in the image; how it should be coded is probably off-topic

[00:43:07.0029] <DerekNonGeneric>
Sarath kumar: i do not understand your question.. it seems to have already been designed, no?

[01:00:55.0488] <Sarath kumar>
current design is like below, i have to modify the current design to the above one


[01:01:33.0858] <Andreu Botella (he/they)>
Sarath kumar: Hi, this chatroom is for working on the web standards, or for help understanding them. It's not for general help with web development.

[01:02:30.0558] <Andreu Botella (he/they)>
You might want to try asking in #webdevelopment:matrix.org or #webdesign:matrix.org

[01:31:00.0274] <DerekNonGeneric>
> <@sideshowbarker:mozilla.org> so is there an `nvm` syntax for “latest”?

there appears to be a way to acquire the latest version of node for github actions, but you have to define it in the manifest https://github.com/actions/setup-node/blob/38d90ce44d5275ad62cc48384b3d8a58c500bb5f/src/installer.ts#L53

[01:32:05.0503] <sideshowbarker>
/me > <@dereknongeneric:mozilla.org> there appears to be a way to acquire the latest version of node for github actions, but you have to define it in the manifest https://github.com/actions/setup-node/blob/38d90ce44d5275ad62cc48384b3d8a58c500bb5f/src/installer.ts#L53

looks now

[01:33:45.0112] <DerekNonGeneric>
unclear on what is meant by "manifest" here, but it is possible that they mean in the `package.json` file (`engines.node` key)

[01:42:46.0041] <DerekNonGeneric>
we do not use the term "manifest" in node core when referring to the package.json file at all, but have seen Yarn do so in their docs

[02:05:53.0726] <DerekNonGeneric>
probably going to end up setting up a test project to get this solved for my own purposes, but am surprised that this isn't more ergonomic

[02:10:34.0383] <sideshowbarker>
I guess I rightly should be setting the `engines.node` version to `>=15.0.0` regardless — since that’s what’s required for using `.replaceAll()`

[02:12:52.0566] <DerekNonGeneric>
in reality, it should probably be `>=16` since this release line will last you longer (wonder if setting this value to `node` does anything)

[02:22:14.0336] <sideshowbarker>
I can try setting it to `node` and see

[02:23:47.0162] <DerekNonGeneric>
you would still need to figure out what the github actions yaml file would need to look like in order for it to utilize the package.json tho (i think)

[02:28:57.0700] <sideshowbarker>
ah

[03:16:25.0452] <DerekNonGeneric>
> * <@sideshowbarker:mozilla.org> looks now

this part is documented here, so it looks like it is simply determining whether the version specified in the package.json is the latest x.x.x version: https://github.com/actions/setup-node/blob/main/docs/advanced-usage.md#check-latest-version

[04:25:55.0289] <DerekNonGeneric>
sideshowbarker: here it is my friend, all that needs to be done is to specify the version as `x.x.x` and ensure `check-latest` is set to `true` -- glad we got that squared away https://github.com/DerekNonGeneric/test-repo-please-ignore/blob/main/.github/workflows/build.yml

[04:29:41.0468] <sideshowbarker>
> <@dereknongeneric:mozilla.org> sideshowbarker: here it is my friend, all that needs to be done is to specify the version as `x.x.x` and ensure `check-latest` is set to `true` -- glad we got that squared away https://github.com/DerekNonGeneric/test-repo-please-ignore/blob/main/.github/workflows/build.yml

thanks much!

[04:30:22.0047] <DerekNonGeneric>
yw


2021-07-04

2021-07-05
[07:45:20.0943] <sideshowbarker>
PSA: https://dontcallmedom.github.io/mdn-issue-by-spec/whatwg.rss

[10:35:48.0921] <smaug>
Isn't https://searchfox.org/mozilla-central/rev/b7bc94b4689a7f002c61d016c6e162e5e5708bf3/testing/web-platform/tests/shadow-dom/imperative-slot-api.html#211,216-218 buggy

[10:36:29.0686] <smaug>
That part of the test was written way before the spec

[10:41:09.0520] <smaug>
The spec allows moves and there is no "recalc"


2021-07-06
[05:13:01.0578] <sujaldev>
are you supposed to convert carriage return to newline character in the html tokenization stage?

[05:16:56.0170] <sujaldev>
https://github.com/html5lib/html5lib-tests/blob/master/tokenizer/domjs.test the first test in this file points to the above doubt...

[05:20:01.0852] <Sam Sneddon [:gsnedders]>
sujaldev: it's in the pre-processing the input stream stage; pretty sure the tokeniser tests assume the two are done together


2021-07-07
[19:30:01.0992] <sujaldev>
oki thanks!

[19:48:21.0534] <sideshowbarker>
wonderful, https://drafts.csswg.org/ completely broken again for the Nth time

[19:50:31.0658] <sideshowbarker>
after this having happened so frequently, it’s baffling that there’s not a watchdog or something set up

[19:51:07.0966] <sideshowbarker>
/me goes off to raise an https://github.com/w3c/csswg-drafts issue about it for at least the 3rd time

[05:30:45.0316] <smaug>
I have asked this before, I think. Is there some documentation for a good workflow for making spec changes? Including the usual github pr creation but also what checks people do to find if there are relevant WPTs etc.

[07:18:51.0496] <freddy>
Admittedly, you are probably not exactly the intended audience but this might help https://wpc.guide/bug-guide/ 

[07:19:20.0967] <freddy>
but TBH, I often just look at similar patches and the follow-up bugs (e.g., for WPT) they led to

[09:49:10.0242] <bakkot>
annevk: domenic suggested you might have an opinion on https://github.com/bakkot/proposal-arraybuffer-base64/issues/5. the question under consideration (as I see it; he is welcome to correct) is, must any new base64-decoding API in the web platform decline to validate the padding bytes by default (and hence match the behavior of `atob`), or can it be stricter by default in pursuit of making it harder to accidentally fall into security issues arising from the (I think fairly natural) assumption that base64 encoding is one-to-one?

[09:49:26.0961] <bakkot>
also interested in opinions from others

[09:50:38.0867] <bakkot>
Domenic seems to feel strongly that it is more important to match `atob`, I feel fairly strongly that it is more important to make the less-secure behavior opt-in, so I am hoping we can get other opinions on the matter

[09:55:31.0995] <Domenic>
Matching data: URLs and other base64 encoding behaviors in the platform (e.g. SRI digests) is more important than atob

[10:01:30.0064] <Luca Casonato>
I agree

[10:03:20.0300] <bakkot>
I understand that position even less; how many people are ever manually decoding a data: url or an SRI digest?

[10:04:15.0944] <bakkot>
(CSP, incidentally, requires padding, so the web platform is not uniform here)

[10:05:42.0564] <bakkot>
actually SRI does too, as far as I can tell from the spec

[10:06:59.0207] <Domenic>
Yeah the spec doesn't seem to match browsers there

[10:08:11.0105] <Domenic>
I can't find base64 decoding in the CSP/SRI specs, only the implementations

[10:09:53.0468] <bakkot>
that's because they don't aren't specified in terms of decoding; they compare by string equality, and assume that base64 encoding is 1-to-1, since everyone makes this assumption.

[10:09:58.0979] <bakkot>
 * that's because they aren't specified in terms of decoding; they compare by string equality, and assume that base64 encoding is 1-to-1, since everyone makes this assumption.

[10:10:10.0192] <bakkot>
 * that's because they aren't specified in terms of decoding; they compare base64-encoded strings by string equality, and assume that base64 encoding is 1-to-1, since everyone makes this assumption.

[10:17:28.0705] <bakkot>
> <@domenicdenicola:matrix.org> Yeah the spec doesn't seem to match browsers there

Browsers disagree; Firefox follows the spec, Chrome does not

[10:22:48.0863] <bakkot>
 * that's because they aren't specified in terms of decoding; they compare base64-encoded strings by string equality, and assume that base64 decoding is 1-to-1, since everyone makes this assumption.

[10:39:40.0062] <shu>
> that's because they aren't specified in terms of decoding; they compare base64-encoded strings by string equality, and assume that base64 decoding is 1-to-1, since everyone makes this assumption.

i find this footgun argument to be pretty persuasive. fwiw i feel more radicalized than before from reading those tweets, and feel like if anything we should try to change the web default

[10:52:51.0999] <sideshowbarker>
Domenic: r? https://github.com/whatwg/whatwg.org/pull/371

[10:58:26.0784] <sideshowbarker>
Domenic: also https://github.com/whatwg/html-build/pull/265

[11:00:38.0279] <Domenic>
> <@shuyuguo:matrix.org> > that's because they aren't specified in terms of decoding; they compare base64-encoded strings by string equality, and assume that base64 decoding is 1-to-1, since everyone makes this assumption.
> 
> i find this footgun argument to be pretty persuasive. fwiw i feel more radicalized than before from reading those tweets, and feel like if anything we should try to change the web default

I just don't think these people are JS practictioners. They are crypto people (?) who maybe use base64 for crypto purposes. We should not expose base64 at all if our audience is people hand-rolling crypto.

[11:00:46.0369] <Domenic>
Note also that the tweets note that Go has the same default as JS

[11:01:01.0901] <Domenic>
It feels really bad for TC39 to try to shift the web default by fiat

[11:02:49.0671] <shu>
the "we shouldn't expose this at all" is a separate argument, which i think i also disagree with, but we should table in this context

[11:03:38.0510] <Domenic>
Well it's relevant because what is our goal in exposing this

[11:03:53.0892] <Domenic>
Is it to allow people to decode base64 in a fashion they're used to from Node/Go/Deno/the web?

[11:04:08.0198] <Domenic>
Or is it to allow people to do secure crypto-adjacent stuff that assumes bijection?

[11:04:20.0170] <shu>
> <@domenicdenicola:matrix.org> It feels really bad for TC39 to try to shift the web default by fiat

i have a hard time engaging with this as well -- there are technical reasons to prefer the stricter variant, which there is disagreement with. it similarly feels bad to accuse TC39 of some kind of power grab here

[11:04:20.0398] <bakkot>
Filippo Valsorda is one of the people your employer pays to be hand-rolling crypto

[11:04:39.0055] <Domenic>
> <@bakkot:matrix.org> Filippo Valsorda is one of the people your employer pays to be hand-rolling crypto

Yes, and I don't think he's the target audience for this API.

[11:04:57.0365] <Domenic>
I don't really think pointing at someone with a different opinion and saying "you get your money from the same dude" is really that insightful

[11:05:27.0201] <shu>
yes let's... cool down on that front

[11:10:51.0800] <Luca Casonato>
Just for clarity: this is about the strictness of base64 **decoding** right? We do all agree that base64 encoding should always include padding?

[11:11:55.0395] <Domenic>
Yes

[11:12:06.0513] <shu>
i've tried to steer the conversation to something more pragmatic, but so long as we're talking about broad-scope arguments like "we shouldn't diverge at all from existing standardized web APIs" and "the current default is not great", i do find the latter more convincing because i'm not sure what group the former position helps in this particular case

[11:12:53.0381] <Luca Casonato>
In this case, what are some arguments for being strict with padding by default? What use cases would this benefit?

[11:13:02.0994] <shu>
for the concrete AMP case, it seemed like the weird Java printer was, well, regarded as weird, and an attempt was made to fix it

[11:13:59.0823] <shu>
> <@lucacasonato:matrix.org> In this case, what are some arguments for being strict with padding by default? What use cases would this benefit?

the use case that the (imo reasonable) assumption that base64 is a bijection holds, and that when it does not, it prompts the author to take a second look and figure out why

[11:16:00.0513] <Domenic>
Who is going around saying "I really want bijection"? I'm worried about people going "I want to switch from Buffer.from(x, "base64") to the new thing, but I did and now we have a production outage because I didn't know about how TC39 decided to diverge from Node semantics and data that used to work now fails"

[11:16:28.0860] <shu>
i think that's precisely the point of why it's so surprising -- nobody's going around saying that because they don't even realize it's not. i certainly didn't!

[11:16:58.0058] <Domenic>
I suspect people don't *expect* it.

[11:17:09.0559] <Luca Casonato>
> <@shuyuguo:matrix.org> the use case that the (imo reasonable) assumption that base64 is a bijection holds, and that when it does not, it prompts the author to take a second look and figure out why

shu: Many other languages and ecosystems have set the precedent that this is not the case though: Go, Python, Java, Deno, Node, Rust. I don't think it is a reasonable assumption to make.

[11:17:21.0525] <Domenic>
Bijection is just not a property one usually insists on for encoding/decoding, is my claim. Certainly not with text encodings!

[11:17:28.0353] <Luca Casonato>
https://docs.rs/base64/0.13.0/base64/ <- too little padding is ok, too much is not

[11:17:31.0981] <bakkot>
Domenic: to be clear, `Buffer.from(x, "base64")` accepts _mixed_ base64 and base64url in the same string, which I am definitely not proposing to support

[11:17:49.0891] <Domenic>
> <@bakkot:matrix.org> Domenic: to be clear, `Buffer.from(x, "base64")` accepts _mixed_ base64 and base64url in the same string, which I am definitely not proposing to support

Well OK, that's pretty bonkers, fair enough.

[11:17:54.0017] <shu>
Domenic: i'm worried about the latter too, but that's why i want more data here! it's all too easy to raise the specter of possible compat breakage

[11:18:01.0599] <bakkot>
(CSP does too, fun fact)

[11:18:21.0272] <Domenic>
Seems like *that* should be a non-default mode...

[11:18:32.0118] <shu>
and while we're here and i'm a little worked up, i really want us to stop pitting whatwg-vs-tc39, both inside and outside of tc39

[11:18:41.0393] <Domenic>
(I'll open a tracking issue)

[11:19:59.0061] <shu>
i mean, obviously JS is a stakeholder in the web platform and we want to improve it too. there are delegate who don't care about the web as much, but perpetuating that dichotomy entrenches that position which is counter-productive

[11:27:04.0717] <Domenic>
I don't think this is a very WHATWG-vs.-TC39 thing; for me at least I tried to frame all my comments as about technical/API surface concerns on each proposal. E.g. even if TC39 wants to do this then I still am unsure about putting things on the prototypes vs. a separate utility class.

At first I thought it was more a web-vs-non-web thing. But recent research showing that Deno/Node/Go/etc. all do forgiving base-64 makes it seem like it's not even that. It's apparently about whether you expect a new JS API to have some bijection property vs. whether you expect it to align with the JS ecosystem/other standard library APIs.

[11:31:13.0885] <bakkot>
> <@domenicdenicola:matrix.org> Bijection is just not a property one usually insists on for encoding/decoding, is my claim. Certainly not with text encodings!

My claim is that a great many people _assume_ it holds, for base64 in particular. Either Chrome's implementation of CSP or the CSP spec itself assumes it holds, so it's not like it's only amateurs who make this mistake. (I don't know what the intent of the CSP authors was, so I'm not saying Chrome is wrong, just that it doesn't match the spec-as-written.)

That is to say, my claim is that very few people have the correct intuition about what `atob` and friends actually do in this edge case, and in any case are unlikely to be exposed to it, and as such we should match what they expect these APIs to do, not what they actually do.

[11:35:11.0050] <shu>
> <@domenicdenicola:matrix.org> I don't think this is a very WHATWG-vs.-TC39 thing; for me at least I tried to frame all my comments as about technical/API surface concerns on each proposal. E.g. even if TC39 wants to do this then I still am unsure about putting things on the prototypes vs. a separate utility class.
> 
> At first I thought it was more a web-vs-non-web thing. But recent research showing that Deno/Node/Go/etc. all do forgiving base-64 makes it seem like it's not even that. It's apparently about whether you expect a new JS API to have some bijection property vs. whether you expect it to align with the JS ecosystem/other standard library APIs.

i was responding mainly to the "TC39 tries to shift the web default by fiat" comment

[13:13:47.0641] <timothygu>
Another data point in the "base64-being-bijection" problem. By default, the GNU coreutils `base64` program _emits_ base64-encoded output wrapped at 76 cols, so already it requires whitespace to be ignored during decoding. In terms of decoding, all popular non-JS base64 decoders that I tested (Perl, Python, Ruby, coreutils) ignore whitespace and treat `YQ==` and `YR==` similarly (return `a` with no errors).

It really seems like forgiving-decode is already an established default across ecosystems.

[13:20:04.0752] <shu>
ah cool, thanks for the extra datapoint

[13:20:59.0111] <bakkot>
timothygu: so there's two notions of "ignoring padding". "treat YQ== and YR== similarly" is one; "treat YQ and YQ== similarly" is the other

[13:22:22.0902] <timothygu>
Yeah I understand. I was trying to conclude that the notion of “base64 as bijection” may already be a lost cause

[13:24:09.0598] <bakkot>
I claim that literally zero people will have put `YR==` into a base64 decoder except as one of a.) manually, to see what happens; b.) leaking memory, or c.) because they are actively malicious and trying to take advantage of the looseness of parsers

[13:27:26.0651] <bakkot>
since there is no reasonable way to end up with `YR==` as an input, I am not at all convinced you can meaningfully extrapolate from "base64 decoders in other languages accept it" to "we also should accept it". it is an implementation detail that no one encounters in real life outside of malicious input.

[13:30:34.0042] <bakkot>
(as another data point, the most popular Rust base64 decoder rejects `YR==`, so it's not universal.)

[13:31:14.0272] <timothygu>
> <@bakkot:matrix.org> I claim that literally zero people will have put `YR==` into a base64 decoder except as one of a.) manually, to see what happens; b.) leaking memory, or c.) because they are actively malicious and trying to take advantage of the looseness of parsers

would it make sense to gather metrics to support this claim? I could imagine some browser adding a usecounter to atob() for inconsistent padding

[13:33:17.0126] <bakkot>
if you think that claim requires support, sure. I am confident in its accuracy personally.


2021-07-08
[03:36:14.0374] <cketti>
Many base64 implementations are strict by default and less strict when being passed flags to change the behavior. Variants of forgiving behavior: allowing line breaks (only allowing CRLF is often an option, "required" for email), allowing whitespace, allowing arbitrary non-base64 "characters", allowing invalid padding (in all variants you can imagine). As someone working on email I wish every implementation would be strict by default. That way implementations generating input requiring forgiving decoders would be found and fixed quickly. Sadly, that's not the world we live in. The next best option is to use forgiving decoders, but warn users when non-conforming input is processed. Please don't be forgiving and silent by default.

[11:57:50.0222] <devsnek>
what do whatwg specs say about adding non-standard methods to things

[12:00:55.0182] <Andreu Botella (he/they)>
> <@devsnek:matrix.org> what do whatwg specs say about adding non-standard methods to things

https://html.spec.whatwg.org/multipage/infrastructure.html#extensibility-2

[12:01:38.0741] <devsnek>
"Documents must not use such extensions" does this mean the document object?

[12:02:45.0791] <Andreu Botella (he/they)>
I think that's a requirement for authors to not use any such extensions

[12:02:55.0185] <devsnek>
ahh ok

[12:03:18.0214] <devsnek>
thanks!


2021-07-09
[07:38:47.0892] <Karl>
I have a question about origins - can somebody tell me if I'm completely misunderstanding them? Right now there are 2 kinds of origins: tuples and opaque, and opaque origins have this weird property where every time you calculate them, you get a "new" opaque origin which doesn't compare as same-origin with any previously-calculated opaque origin. The HTML spec uses them really carefully and calculates them at specific times to walk this tightrope, URL libraries use things like global atomic counters or UUIDs, etc. This whole "calculation is creation" setup is quite fragile and can lead to brittle code.  

[07:40:04.0855] <Karl>
So... as I've been reading about them, I've been thinking: it seems that there are really 3 kinds of origins - tuple (security domain defined by protocol + host + port), application-defined opaque (security domain defined some other way, for a specific operation or frame or other context), and undefined opaque (totally unknown security domain). Would that be an accurate way to model them?

[07:45:18.0278] <Karl>
The URL standard says that the origin of "file:" URLs is "an exercise for the reader". IIRC, there was some disagreement because Chrome defines an origin for "file:" URLs and doesn't (or didn't) want to change that. Would that be an example of an application-defined opaque origin? In other words, Chrome has some other information which allows it to assign a security domain for certain file operations?


2021-07-10
[20:50:52.0735] <Thomas Sikma>
🤩heard there was a party in oculus tn..?

[20:51:50.0671] <Thomas Sikma>
wrong room, i suppose.

[00:23:55.0334] <sideshowbarker>
anybody know what `{% raw %}` in a GitHub Actions workflow file does?

[00:24:25.0546] <sideshowbarker>
context is https://docs.github.com/en/actions/guides/publishing-docker-images#publishing-images-to-github-packages


2021-07-11

2021-07-12
[00:38:57.0516] <Hamish Willee>
Eric Portis (he/him): I'm doing VERY basic first docs on using EXIF for getting intrinsic size in https://github.com/mdn/content/pull/6798 
Would I be correct that all four of PixelXDimension, PixelYDimension, ResolutionX, and ResolutionY (and ResolutionUnit) must be set and consistent or they will be ignored?

At this point I am saying very little because I can't find a good place in the existing docs to frame it. I think everyone assumes that all the terminology and relationships between terms are well understood but they aren't by me: CSS Pixel, Pixel density, device pixel density. Can you recommend a good explainer of that? I do kind of get it after some internet search, but would be good to have independent confirmation. 

[00:44:09.0795] <sujaldev>
hi, is there something like https://html.spec.whatwg.org/multipage/parsing.html for css
and something like https://github.com/html5lib/html5lib-tests again for css?

[00:45:08.0019] <Ms2ger>
https://drafts.csswg.org/css-syntax/

[00:45:31.0901] <sujaldev>
Thank you!

[09:28:29.0381] <sideshowbarker>
https://html.spec.whatwg.org/multipage/embedded-content-other.html#dimension-attributes

[09:28:42.0936] <sideshowbarker>
> The width and height attributes on img, iframe, embed, object, video, source when the parent is a picture element and, when their type attribute is in the Image Button state, input elements may be specified to give the dimensions of the visual content of the element (the width and height respectively, relative to the nominal direction of the output medium), in CSS pixels. 

[09:29:03.0365] <sideshowbarker>
I am having a hard time parsing that sentence

[09:29:29.0460] <sideshowbarker>
it does not seem grammatically correct/complete

[09:35:31.0914] <sideshowbarker>
in particular, the part around _“when their type attribute is in the Image Button state, input elements may be specified ”_

[10:08:53.0343] <bakkot>
sideshowbarker: "The width and height attributes on { img, iframe, embed, object, video, (source when the parent is a picture element) and, ( when their type attribute is in the Image Button state, input elements) } may be specified [...]" is how i read it

[11:09:03.0868] <littledan>
Hello!

[11:09:44.0795] <littledan>
Is anyone who is following modules interested in reviewing the PR which integrates the TC39 Realms proposal? I've updated it based on previous feedback from the editors. https://github.com/whatwg/html/pull/5339

[15:16:59.0994] <sideshowbarker>
> <@bakkot:matrix.org> sideshowbarker: "The width and height attributes on { img, iframe, embed, object, video, (source when the parent is a picture element) and, ( when their type attribute is in the Image Button state, input elements) } may be specified [...]" is how i read it

ah OK, thanks 


2021-07-13
[08:04:33.0139] <yug34>
Hello, I am using one of your images in my research paper (specifically: https://html.spec.whatwg.org/images/asyncdefer.svg), how do I cite you?

[08:15:07.0712] <yug34>
 * Hello, I am using one of your images in my research paper (specifically: https://html.spec.whatwg.org/images/asyncdefer.svg), how do I cite WHATWG?

[11:09:07.0835] <Domenic>
I think that depends on your paper/journal's style guide for citations. Probably cite them the way you would cite any webpage.


2021-07-14
[20:25:50.0949] <bakkot>
are there any nested namespace objects in HTML? Math or JSON, but hanging off another property

[20:26:14.0803] <bakkot>
I can't think of any except maybe `crypto.subtle`

[20:26:39.0748] <bakkot>
(tc39 is bikeshedding `Temporal.now`)

[20:27:34.0219] <bakkot>
 * are there any nested namespace objects in HTML? like Math or JSON, but hanging off another property

[22:57:56.0436] <Andreu Botella (he/they)>
> <@bakkot:matrix.org> are there any nested namespace objects in HTML? like Math or JSON, but hanging off another property

`console`?

[22:58:24.0736] <shu>
oh man is `console` a namespace object?

[23:03:21.0936] <Andreu Botella (he/they)>
/me was checking the JS spec to make sure "namespace object" isn't a specific concept that they'd missed

[23:03:40.0036] <shu>
it is not! that's something we were debating, and we couldn't come to an exact definition

[23:05:16.0964] <sideshowbarker>
”namespace object“ is a WebIDL thing, not an ES thing, right?

[23:09:12.0738] <Andreu Botella (he/they)>
oh, _nested_ namespace objects

[23:09:19.0628] <Andreu Botella (he/they)>
/me is still half asleep

[00:14:44.0249] <yug34>
> <@domenicdenicola:matrix.org> I think that depends on your paper/journal's style guide for citations. Probably cite them the way you would cite any webpage.

It is APA 7th ed., is there any author? Or should I just have:

HTML Living Standard, (2021, July 14). WHATWG. https://html.spec.whatwg.org/

[00:16:09.0187] <yug34>
> <@domenicdenicola:matrix.org> I think that depends on your paper/journal's style guide for citations. Probably cite them the way you would cite any webpage.

It is APA 7th ed.! is there any author? Or should I just have:

HTML Standard, (2021, July 14). WHATWG. https://html.spec.whatwg.org/

[07:40:51.0147] <Domenic>
> <@shuyuguo:matrix.org> oh man is `console` a namespace object?

It is, but it is not nested. It is lowercase for legacy reasons. https://console.spec.whatwg.org/#:~:text=For%20historical%20reasons%2C%20console%20is%20lowercased.

[07:43:30.0112] <Domenic>
> <@bakkot:matrix.org> I can't think of any except maybe `crypto.subtle`

crypto and crypto.subtle were designed before Web IDL supported namespaces; otherwise they would probably be a good candidate. In general the web has a lot of things which should probably be namespaces but are instead singleton instances (e.g. navigator is another one). You can tell the difference since crypto.constructor exists and crypto.subtle.constructor exists. These days that pattern is lightly discouraged; see https://w3ctag.github.io/design-principles/#:~:text=Several%20non-constructible%20classes%2C%20like%20Navigator%2C%20History%2C%20or%20Crypto%2C%20are%20non-constructible%20because

[07:45:30.0006] <Domenic>
> <@yug34:matrix.org> It is APA 7th ed.! is there any author? Or should I just have:
> 
> HTML Standard, (2021, July 14). WHATWG. https://html.spec.whatwg.org/

You could cite the editors, which are listed in https://html.spec.whatwg.org/multipage/acknowledgements.html#:~:text=For%20about%20ten%20years%20starting%20in%202003%2C%20this%20standard%20was%20almost%20entirely%20written%20by . But the text was authored by hundreds of people, who you can see in the large list above, so I'm not sure what your style guide would recommend for such cases.

[08:51:13.0915] <foolip>
Have y'all seen https://dontcallmedom.github.io/mdn-issue-by-spec/ and in particular https://dontcallmedom.github.io/mdn-issue-by-spec/whatwg.html?

[08:52:10.0627] <foolip>
Right?

[08:52:13.0242] <Ms2ger>
[html] Issue with input validation

[08:52:33.0272] <foolip>
Too bad it's on static hosting or one could have a bit of fun


2021-07-15
[02:26:04.0020] <weeb69>
Hi, is there a machine readable list of all the HTML elements, their attributes, etc? If so, where can I find it?
Context: I'm looking to build a strongly-typed HTML DSL

[02:26:17.0776] <weeb69>
(please ping me when responding)

[02:28:26.0421] <sideshowbarker>
weeb69: https://github.com/validator/validator/tree/main/schema/html5

[02:29:15.0429] <weeb69>
> <@sideshowbarker:mozilla.org> weeb69: https://github.com/validator/validator/tree/main/schema/html5

is there a readme or anything i can look at to know to how to parse this?

[02:31:16.0727] <sideshowbarker>
it’s a relaxng schema

[02:31:29.0906] <sideshowbarker>
the entry points are in https://github.com/validator/validator/blob/main/schema/.drivers/

[02:31:34.0706] <sideshowbarker>
e.g., https://github.com/validator/validator/blob/main/schema/.drivers/html5-all.rnc

[02:33:01.0426] <sideshowbarker>
but it’s meant to be used with two inputs: 1) that grammar, and 2) an instance against which to validate, using that grammar

[02:33:36.0279] <sideshowbarker>
https://github.com/relaxng/jing-trang is the tool for working with it

[02:35:10.0545] <sideshowbarker>
but it would be a lot of work to repurpose that grammar for something other than validation

[02:35:28.0381] <weeb69>
I need to convert that information to Rust types. I can't find any documentation on *how* the information is laied out (which files contains what)

[02:36:01.0504] <weeb69>
Right now, my best bet seems to be to scrape MDN docs and put in some manual work

[02:36:06.0190] <sideshowbarker>
however, I’m not aware of any other machine-readable expressions of HTML that conform to the current spec
 

[02:36:27.0618] <Luca Casonato>
The WebIDL?

[02:36:56.0932] <Ms2ger>
The syntax?

[02:37:40.0368] <weeb69>
does the WebIDL contain information about HTML elements?

[02:37:54.0655] <sideshowbarker>
yes

[02:38:04.0143] <Ms2ger>
Only sort of

[02:38:08.0268] <sideshowbarker>
but WebIDL expresses the DOM interface and DOM attributes, not the content/markup attributes

[02:38:14.0468] <Luca Casonato>
> <@weeb69:matrix.org> does the WebIDL contain information about HTML elements?

The JS APIs corresponding to all html elements

[02:38:39.0157] <sideshowbarker>
and there is not 1-to-1 WebIDL for every element

[02:38:44.0652] <Ms2ger>
There's also https://html.spec.whatwg.org/multipage/indices.html#elements-3

[02:39:21.0646] <sideshowbarker>
ah yeah that would be parseable

[02:41:14.0387] <weeb69>
> <@ms2ger:igalia.com> There's also https://html.spec.whatwg.org/multipage/indices.html#elements-3

I have a feeling parsing that would be more work than parsing the MDN page

[02:41:32.0819] <weeb69>
https://developer.mozilla.org/en-US/docs/Web/HTML/Element and https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes

[02:41:35.0378] <weeb69>
ones

[02:44:47.0532] <weeb69>
https://github.com/mdn/content/tree/main/files/en-us/web/html

[02:44:54.0229] <weeb69>
this seems like a nice representation

[02:45:14.0040] <weeb69>
i could use just the directory structure to get the data

[05:41:32.0309] <freddy>
It seems this all depends on how bad an inaccuracy here would be for your desired outcome.. :) 

[10:34:19.0058] <tabatkins>
Hm, it's not possible to set an ObservableArray attribute directly to an array (having it replace all the members), is it? @domenic?

[10:34:36.0605] <tabatkins>
If not, I can raise an issue for it.

[10:46:15.0833] <hsivonen>
Do I understand correctly that WebKit and Blink use the full HTML tokenizer for `meta` prescan but don't use the real tree builder for figuring out which tokens would imply `<body>`?

[10:48:06.0299] <Domenic>
> <@tabatkins:matrix.org> Hm, it's not possible to set an ObservableArray attribute directly to an array (having it replace all the members), is it? @domenic?

It is possible; see https://heycam.github.io/webidl/#ref-for-dfn-observable-array-type%E2%91%A3

[11:08:11.0434] <tabatkins>
Oh dang, that's nice. I'll still probably submit a PR to add an example of this to the description, as it's not clear from anywhere *outside* that algo that this is possible.

[12:57:04.0123] <Domenic>
Well, there's also https://heycam.github.io/webidl/#:~:text=building.employees%20%3D%20%5Bnew%20Employee(%22D%22)%2C%20employeeB%2C%20new%20Employee(%22C%22)%5D%3B

[13:22:10.0651] <tabatkins>
Oh huh, I skipped right over that.

[13:22:25.0646] <tabatkins>
I was actively reading that and the next chunk of example code.


2021-07-16
[00:34:50.0209] <hsivonen>
https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/html/parser/html_meta_charset_parser.h;l=58 indeed looks a lot like Chromium is using the real HTML tokenizer. But not the real tree builder: https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/html/parser/html_meta_charset_parser.h;l=58

[00:35:46.0795] <hsivonen>
Can anyone think of bad Web compat consequences from using the real tree builder algorithm for figuring out where `body` starts?

[00:36:28.0469] <hsivonen>
That is, running the tree builder in the scripting enabled mode without actually executing scripts during the `meta` prescan?

[00:37:43.0654] <hsivonen>
Oops. The second link was supposed to be https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/html/parser/html_meta_charset_parser.h;l=58

[00:37:51.0420] <hsivonen>
What

[00:38:14.0568] <hsivonen>
https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/html/parser/html_meta_charset_parser.cc;l=88

[00:38:27.0803] <hsivonen>
Something weird going on with how the copypasteable URL updates.

[00:41:31.0580] <hsivonen>
AFAICT, the biggest risk is probably `meta` inside `script` in a manner that should be honored for compat. Need to write tests...

[02:05:12.0030] <Sam Sneddon [:gsnedders]>
> <@hsivonen:mozilla.org> AFAICT, the biggest risk is probably `meta` inside `script` in a manner that should be honored for compat. Need to write tests...

FWIW, I would be strongly in favour of not allowing this (or `meta` inside `noscript`), if we could get away this from a compat POV

[02:07:27.0244] <Sam Sneddon [:gsnedders]>
I don't know the origins of why Hixie spec'd it as allowing it, though…

[02:07:35.0486] <Ms2ger>
Compat is nice and all, but sometimes I understand why people wanted to burn it all to the ground

[02:13:01.0823] <Sam Sneddon [:gsnedders]>
I guess it's somewhat difficult to avoid the actual parser changing encoding from `document.write`, and probably practically unacceptable :(

[02:14:24.0008] <jgraham>
Compat is nice / but compat can stop you / from doing all the things in life you'd like to.

[02:16:01.0608] <jgraham>
(also I think to quote The Smiths these days, one need to pretend that Morrissey doesn't exist and it's all Johnny Marr)

[02:16:16.0450] <Ms2ger>
Who are The Smiths?

[02:18:15.0628] <Sam Sneddon [:gsnedders]>
/me gets inspired to put on a far more acceptable band, The Jesus and the Mary Chain

[02:23:30.0114] <hsivonen>
> <@gsnedders:mozilla.org> I don't know the origins of why Hixie spec'd it as allowing it, though…

I thought Hixie specced it the way it's specced in order to imitate IE6. However, I could be wrong and maybe the spec is creative in ways it shouldn't have been.

[02:24:27.0804] <Sam Sneddon [:gsnedders]>
> <@hsivonen:mozilla.org> I thought Hixie specced it the way it's specced in order to imitate IE6. However, I could be wrong and maybe the spec is creative in ways it shouldn't have been.

I have a suspicion that it didn't handle `<script>` for the sake of keeping the prescan as simple as possible?

[02:24:39.0807] <hsivonen>
Also possible.

[02:32:16.0402] <Sam Sneddon [:gsnedders]>
If I'm reading the Chromium code correctly, it's running the tokeniser with scripting disabled, which means the prescan would pick up `<noscript><meta charset=…>`

[02:32:27.0500] <hsivonen>
Fun

[02:33:06.0493] <hsivonen>
What would be a simple way for the page to self-diagnose whether there was a charset reload?

[02:33:31.0313] <Sam Sneddon [:gsnedders]>
write in localStorage? though I guess that depends on how it deals with committing things there

[02:34:11.0856] <hsivonen>
I guess local-storage would involve having to edit a test-specific key into each test.

[02:34:48.0921] <Sam Sneddon [:gsnedders]>
> <@gsnedders:mozilla.org> I guess it's somewhat difficult to avoid the actual parser changing encoding from `document.write`, and probably practically unacceptable :(

a more radical suggestion to deal with `document.write` for the parser would be to change the confidence to `certain` before executing any script; I wonder how often that would change things…

[02:35:10.0563] <hsivonen>
Pretty sure that would break the Web.

[02:35:47.0654] <Sam Sneddon [:gsnedders]>
I can find very little evidence for sites using `document.write("<meta charset=…>")` at least, but yeah, I suspect it would break the web due to sites having the meta after a first script

[02:36:35.0515] <Sam Sneddon [:gsnedders]>
even just changing changing it to certain on a `document.write` call would I expect break things :(

[02:36:44.0316] <Andreu Botella (he/they)>
Wouldn't that have to be `document.write("<meta ch" + "arset=...")`?

[02:36:58.0705] <Sam Sneddon [:gsnedders]>
to avoid the prescan? yes

[02:37:42.0465] <Sam Sneddon [:gsnedders]>
my hypothesis is few sites are deliberately trying to avoid the prescanner 🙃

[02:42:41.0200] <hsivonen>
That WebKit/Blink got away with https://hsivonen.com/test/moz/meta/after-head-after-1kb.htm goes against my intuition of the Web.

[02:43:30.0090] <hsivonen>
Too bad that for TLS reasons, it's very annoying to test IE6 these days.

[02:43:36.0167] <Ms2ger>
Please leave your intuition at the door as well?

[02:44:02.0655] <Sam Sneddon [:gsnedders]>
is that another difference with the prescanner? (after `</head>`)

[02:44:50.0590] <hsivonen>
Looking for the end of `head` is a WebKit/Blink difference from the spec. The one that I'm trying to resolve in Gecko.

[02:47:03.0431] <hsivonen>
Specifically, I'm trying to make Gecko load https://hsivonen.com/test/moz/meta/after-1kb.htm like WebKit/Blink without reloading. (With this test the reload is so fast that you don't notice.)

[02:49:17.0305] <hsivonen>
(As for why not just go ahead and do exactly what Chrome does: That would involve introducing the capability of the tokenizer to have different kinds of token sinks in Gecko. Also, if using the tree builder works, the prescan process could yield speculative loads.)

[02:54:12.0486] <Sam Sneddon [:gsnedders]>
the only difference then would be the prescan running without scripting?

[02:54:44.0778] <Sam Sneddon [:gsnedders]>
(v. the "real" parser)

[05:20:21.0917] <hsivonen>
> <@gsnedders:mozilla.org> the only difference then would be the prescan running without scripting?

Yes. In particular, the prescan could be the real parse if UTF-8 is declared and none of the scripts `document.write`. That is, it could be a speculative real parse.

[05:30:13.0461] <hsivonen>
So far, `noscript` is the only case where using the real tree builder would differ from Chrome: https://hsivonen.com/test/moz/meta/

[05:45:38.0426] <hsivonen>
Another difference between Chrome and the real tree builder: https://hsivonen.com/test/moz/meta/in-template-after-1kb.htm

[13:09:34.0922] <dg12>
I noticed that on the introduction page ( html.spec.whatwg.org/multipage/introduction.html ) the section :"Design Notes"  includes a paragraph stating:  Authors can create plugins and invoke them using the embed element. This is how Flash works.

Since the announcement of Adobe ending support of Flash Player on December 31, 2020,
should this be revised to provide a different example?

[13:12:09.0391] <Andreu Botella (he/they)>
Good point. It's no longer true that authors can create plugins, since the after the death of Flash the spec's sections about plugins are being slimmed down to only leave things that are relevant to PDF viewers.

[13:13:34.0112] <dg12>
Andreu, can you submit an issue?

[13:14:09.0107] <Andreu Botella (he/they)>
I'll file a pull request

[13:14:17.0412] <dg12>
Thansk

[13:15:37.0532] <dg12>
when you do can you please let me know where it is filed.

[13:30:52.0200] <Andreu Botella (he/they)>
dg12: https://github.com/whatwg/html/pull/6867

[14:28:23.0674] <Andreu Botella (he/they)>
dg12: Do you want me to add you to the acknowledgments section?

[15:14:17.0267] <Ian Hickson>
hey folks, long time no see

[15:14:30.0114] <hober>
hi ian!

[15:14:44.0052] <hober>
i hope you're well

[15:14:46.0582] <sideshowbarker>
whoah

[15:14:54.0508] <sideshowbarker>
Howdy Ian

[15:15:01.0574] <Ian Hickson>
i figured i would pop in because i've been working on a vector graphics format for flutter and thought y'all might be a good audience to get feedback from :-)

[15:15:30.0257] <Ian Hickson>
flutter.dev/go/vector-graphics is the doc, it's mostly a discussion on the use cases and requirements and such, but there's a proposal at the bottom

[15:17:27.0557] <sideshowbarker>
Ian Hickson: incidentally, one thing that surprised me when I read this before was the *“Flutter explicitly does not support vertical text”* part

[15:17:57.0290] <sideshowbarker>
for developing apps for Japanese users, seems like a pretty big limitation 

[15:19:12.0895] <Ian Hickson>
yeah, that was a decision we made really early on, because we knew that if we had to support vertical text it would increase the complexity hugely, since it's really not something you can bolt on the side

[15:19:22.0108] <sideshowbarker>
yup

[15:19:36.0988] <Ian Hickson>
we tried to use the "pay as you go" model for most of our design, and we couldn't see a way to do vertical text in that model

[15:20:24.0321] <Ian Hickson>
(pay as you go, as in, if you don't need a feature, you don't have any overhead from it. like, in HTML, even if you never use padding, you still have to pay the cost for parsing `padding` in CSS, laying it out, etc. but in flutter if you never use padding, all the code for it is literally not in your binary.)

[15:21:22.0635] <Ian Hickson>
(same's true of bidi, but there's a bigger portion of people who need that.)

[15:21:34.0584] <sideshowbarker>
right yeah it makes sense but certainly I would think that choice is going to limit Flutter adoption in Japan vs the alternatives

[15:21:40.0112] <Ian Hickson>
yeah

[15:21:56.0737] <Ian Hickson>
definitely

[15:22:24.0418] <sideshowbarker>
yeah vertical text is very exceptional in that it really isn’t needed outside Japan, while however it’s *really* needed in Japan 

[15:22:46.0233] <sideshowbarker>
anyway, I had another meta-comment about the WVG part

[15:23:10.0938] <sideshowbarker>
…which is, why you prefaced it with *This is presented as a proof of concept, not a formal proposal*

[15:24:39.0759] <sideshowbarker>
that somewhat gives me the impression that maybe I should avoid avoid looking at the spec in much detail, because maybe it’s all just  gonna change… or something

[15:29:29.0373] <Ian Hickson>
oh it'll definitely change, yeah

[15:29:44.0456] <Ian Hickson>
right now it's just a strawman intended to trigger discussion

[15:29:55.0704] <Ian Hickson>
i want to see if people are like "this entire approach is absurd"

[15:30:03.0820] <Ian Hickson>
or if they're like "omg this is awesome ship it now"

[15:30:11.0376] <Ian Hickson>
or something in between

[15:30:56.0376] <Ian Hickson>
and if nobody says its absurd, the next step is to remove the thing saying its just a proof of concept, and threaten to implement it, maybe that'll get people to say its absurd. :-)

[15:31:08.0962] <Ian Hickson>
 * and if nobody says its absurd, the next step is to remove the thing saying its just a proof of concept, and threaten to implement it, maybe that'll get people to say it's absurd. :-)

[15:31:42.0910] <sideshowbarker>
hahaha

[15:33:23.0713] <Ian Hickson>
i've definitely never found a good solution to the problem of getting feedback on an early proposal. there seems to be no step between "everyone ignores it because it doesn't matter" and "everyone freaks out because they think you're deploying a _fait accompli_"

[15:34:26.0839] <Alan Stearns>
I’ll wait until v3 to say it’s absurd, because by then it will inevitably be so.

[15:34:50.0650] <Karl>
The vector format is interesting - especially the lack of support for text and strokes. The former I can understand; text is awfully complex, and probably isn't too important for the listed use-cases. The latter seems potentially more controversial; have you made any prototypes using representative images to see what the benefit is of converting all of these to fills, and if it is worth the added complexity to the overall image?

[15:34:55.0277] <Ian Hickson>
alan: careful, if it's a format i'm designing it's not gonna be versioned :-P

[15:35:26.0075] <Ian Hickson>
karl: yeah that's definitely one of the things i'm most curious about.

[15:36:17.0797] <Ian Hickson>
karl: it's based on the desire to be able to implement the whole format in graphics shaders, where strokes are a lot harder to do than fills (apparently, i'm basing this on feedback i got from graphics library implementors, not personal experience)

[15:36:24.0907] <Ian Hickson>
i haven't tried converting a stroke-based image to fills

[15:36:34.0460] <Ian Hickson>
that would definitely be a good thing to try

[15:36:50.0431] <Ian Hickson>
the tiger image in particular has a lot of strokes and is one i would love to test

[15:38:36.0325] <Ian Hickson>
you lose the ability to do hairline strokes of course

[15:46:27.0264] <sideshowbarker>
at the broadest level, I would want this optimized for implementation in browser engines

[15:46:50.0562] <sideshowbarker>
I say that because while I’d be glad for y’all if you end up with a format that works well in Flutter, I would be much gladder if it also were to become something that web developers could use on the web — as an alternative to needing to use SVG

[15:47:07.0232] <Ian Hickson>
yeah, web support is definitely something i would love to see

[15:47:16.0078] <Ian Hickson>
(that's why i called it WVG :-) )

[15:47:18.0009] <sideshowbarker>
 * I say that because while I’d be glad for y’all if you end up with a format that works well in Flutter, I would be much gladder if it also were to become something that web developers could use on the web — as an alternative to needing to use SVG

[15:47:29.0031] <Domenic>
Yeah, SVG has some cool uses, like interactive diagrams in the HTML spec where it cross-links to the relevant definitions and algorithms... but for vector icons etc., something nice and simple would be great.

[15:47:43.0843] <sideshowbarker>
yeah

[15:47:48.0006] <Ian Hickson>
flutter being a fork of chrome and using the same skia backend, i suspect anything we do for flutter will work fine for the web

[15:48:12.0660] <Ian Hickson>
but that's definitely on my mind

[15:48:27.0844] <Domenic>
I guess I had trouble reading the spec because it's all about the binary format. I was able to get a high-level view that it only supports a few primitives and was able to tell what it omits. But I'd be curious about the authoring-friendly pre-compilation format and what that would look like. I enjoy the hackability of SVG.

[15:49:29.0313] <Ian Hickson>
there's a link somewhere to sample images which show the format i used to create them

[15:49:40.0680] <Domenic>
Or maybe from another angle: I'd be interested in what the abstract model for such a file is, with the binary format being just one serialization of that model.

[15:50:05.0702] <Ian Hickson>
here's an example: https://github.com/google/ui-exp-dg/blob/e9416c6bb836b0b0e412ea71d8164feefcf0e047/wvg/handcrafting/samples/action-info.wvgtxt

[15:50:36.0597] <Domenic>
Seems like it's something like "has metadata, has matrices, has shapes, has gradients, has paint somethings, has composition somethings" but it's all defined in terms of the binary blocks

[15:50:41.0297] <Ian Hickson>
or a more elaborate one: https://github.com/google/ui-exp-dg/blob/e9416c6bb836b0b0e412ea71d8164feefcf0e047/wvg/handcrafting/samples/slider.wvgtxt

[15:50:44.0454] <Domenic>
Which is probably great for interoperable implementations but just makes it hard to read

[15:51:00.0978] <Domenic>
Oh those examples do help

[15:51:52.0366] <Ian Hickson>
but yeah that's good feedback, i should add an intro section that talks about the abstract model

[15:52:08.0555] <Ian Hickson>
/me makes a note

[15:53:09.0099] <Domenic>
Also I can't quite tell where WVG comes down on this but I do think one killer advantage a new format might have is properly accounting for high-gamut and HDR colors. (Are those the same thing? Different? Color spaces? I dunno.) It seems like the web is going through a very slow and painful transition process to allow better colors and I imagine SVG getting that will be years down the line, after canvas and CSS and <img> etc.

[15:53:34.0786] <Ian Hickson>
currently this is all just 32bit color

[15:53:38.0178] <Ian Hickson>
rgba

[15:53:43.0252] <Ian Hickson>
though i guess i don't actually say rgba anywhere

[15:54:36.0525] <Domenic>
I don't know if anyone is clamoring for HDR icons but it seems like a good idea to allow them in the abstract

[15:54:58.0666] <Ian Hickson>
 * srgb

[15:55:03.0004] <Ian Hickson>
 * though i guess i don't actually say srgb anywhere

[15:55:45.0040] <Ian Hickson>
what would the format need to support to allow for it?

[15:56:46.0236] <Domenic>
I am like 60% confident that it would want some notion of color space, plus the ability for colors to be more than 32 bits. (I think 16 bits x 4 channels was mentioned somewhere). But it's better to ask someone who actually knows things :)

[15:57:00.0694] <Ian Hickson>
color space would be easy to add

[15:57:14.0235] <Ian Hickson>
more than 32 bits per color would be a new format, heh

[15:57:25.0966] <Ian Hickson>
this format is basically built around 32 bits as the unit of data

[15:57:58.0138] <Ian Hickson>
(it can certainly be 64 bits if that's what we need though, this is the kind of thing i really want to find out)

[15:58:34.0070] <Karl>
HDR icons would be very cool - one of the things I really love about the Mac (at least traditionally) is the fidelity and attention to detail even in "little things" like icons. Richer colours might not be the thing you'd immediately notice, but if you got used to it and went back to SDR colour, I think you'd feel that it just wasn't as good; that something was just missing.

[16:01:22.0085] <Domenic>
https://github.com/whatwg/html/issues/299 is somewhat relevant

[16:08:58.0498] <Ian Hickson>
based on some research it looks like 32 bits to describe the colors in the file itself would be fine in a vector format; we can always extend it later with a color space block to change how those 32 bits are interpreted

[16:09:32.0620] <Ian Hickson>
e.g. in the extreme we could literally define a block that defines a palette using groups of floats and then index into that

[16:11:34.0451] <sideshowbarker>
Domenic's link makes me realize that Dean Jackson is probably among the specific people from who you'd want to get feedback on this

[16:12:01.0201] <Domenic>
It looks like there are two issues: color space and how many bits you use to represent that space

[16:12:21.0563] <Domenic>
If you are using a high-gamut space like rec2020 (HDR) then 8 bits per channel will produce visible banding

[16:12:41.0379] <Domenic>
Seems like people are variously claiming you need 10, 12, or 14.

[16:12:49.0330] <Domenic>
So the current proposal is 16 bits per channel

[16:13:02.0990] <Domenic>
And there is some debate about 16-bit float vs. 16-bit int which I can't quite understand

[16:13:20.0488] <Ian Hickson>
in the output you want more than 32 bits total per pixel for sure

[16:13:28.0950] <Ian Hickson>
but colors in a vector format aren't used per-pixel

[16:13:36.0443] <Ian Hickson>
they're used as end-points of gradients, and solid colors

[16:13:41.0026] <Domenic>
Ah yeah good point

[16:14:16.0190] <Domenic>
So people wouldn't be able to manually create perfect gradients out of strokes but that's fine

[16:14:32.0720] <Ian Hickson>
yeah

[16:14:35.0815] <Ian Hickson>
they couldn't anyway :-)

[16:15:23.0372] <Domenic>
I guess the only remaining edge case I can think of is some company saying "our brand color is exactly between these two 8 bit values, how dare you not let us express it precisely"

[16:15:45.0071] <Ian Hickson>
i'm willing to take that phone call

[16:16:04.0860] <Ian Hickson>
if only to hear their explanation of how they're going to calibrate everyone's monitors and make sure everyone has perfectly-calibrated light bulbs

[16:17:49.0455] <Ian Hickson>
sideshowbarker: do you know what dean's current contact info is? is he still at apple? i thought i'd read he'd left at some point in the past few years but i admit i'm out of touch

[16:27:18.0039] <sideshowbarker>
> <@hixie:matrix.org> sideshowbarker: do you know what dean's current contact info is? is he still at apple? i thought i'd read he'd left at some point in the past few years but i admit i'm out of touch

He's still at Apple. Been especially active in the Web GPU work. https://mobile.twitter.com/grorgwork is one way to reach him

[16:27:28.0210] <Ian Hickson>
cool

[16:27:29.0570] <Ian Hickson>
thanks


2021-07-17

2021-07-18
[15:47:21.0727] <Andreu Botella (he/they)>
I just noticed that the "location" field of the WHATWG organization in Github still says "#whatwg, Freenode"


2021-07-19
[17:14:20.0263] <sideshowbarker>
Andreu Botella (he/they) what should we make it say instead?

[17:15:01.0014] <Andreu Botella (he/they)>
Why not "#whatwg, Matrix" or something similar

[18:26:08.0998] <DerekNonGeneric>
`#whatwg:matrix.org`

[18:29:35.0330] <DerekNonGeneric>
or bizarro world if keeping the sense of logic at the door theme

[19:17:41.0433] <sideshowbarker>
hmm, seems like it now won’t let me change it to anything that’s no an actual place on map

[19:18:22.0284] <sideshowbarker>
I guess it does client-side input validation now that it didn’t do before

[19:18:35.0389] <sideshowbarker>
/me tries to see if he can hack around it

[19:21:20.0945] <sideshowbarker>
yeah it’s not persisting the change even after I change it directly in the DOM

[19:30:48.0256] <sideshowbarker>
OK, changed it using the API

[19:30:57.0769] <sideshowbarker>
I changed it to https://matrix.to/#/#whatwg:matrix.org

[19:31:16.0791] <sideshowbarker>
if others think it should be `#whatwg:matrix.org` instead, lemme know

[19:32:28.0189] <sideshowbarker>
hmm, I see it still tries to hyperlink it to something on Google Maps

[19:33:41.0967] <sideshowbarker>
and for whatever reason, https://matrix.to/#/#whatwg:matrix.org ends up resolving to “Software Lab 5 | do it green” in Wannweil

[19:35:23.0341] <sideshowbarker>
ah I see that’s because that company has its own location set to `matrix.to` (or as specific matrix.to address)

[19:43:00.0811] <DerekNonGeneric>
lgtm

[20:11:20.0594] <DerekNonGeneric>
sideshowbarker: did you have to use the api to change it to `#whatwg:matrix.org`?

[20:25:27.0876] <sideshowbarker>
> <@dereknongeneric:mozilla.org> sideshowbarker: did you have to use the api to change it to `#whatwg:matrix.org`?

Yeah I did need to use the API

[20:31:03.0453] <DerekNonGeneric>
wow, that is such a hassle

[20:33:12.0551] <DerekNonGeneric>
sideshowbarker: i need to do this for my own org and would <3 it if you could share the curl command you used

[20:36:52.0941] <sideshowbarker>
> <@dereknongeneric:mozilla.org> sideshowbarker: i need to do this for my own org and would <3 it if you could share the curl command you used

```
curl -u sideshowbarker:$GITHUB_TOKEN  -X PATCH   -H "Accept: application/vnd.github.v3+json"  https://api.github.com/orgs/whatwg   -d '{"location":"#whatwg:matrix.org"}'
```

[20:40:30.0509] <DerekNonGeneric>
thanks, worked :)

[23:43:32.0961] <annevk>
Oh wow, over a 100 people here now, welcome all! 👋🏻

[23:48:31.0890] <annevk>
Karl: yeah, for file: URLs some implementations have other types of origins (reading backlog)

[00:04:22.0342] <annevk>
bakkot: did you see https://github.com/lucacasonato/proposal-binary-encoding? Luca Casonato did you see https://github.com/tc39-transfer/proposal-arraybuffer-base64?

[00:20:55.0672] <bakkot>
annevk: yeah, see https://github.com/tc39-transfer/proposal-arraybuffer-base64/issues/4

[00:40:21.0983] <DerekNonGeneric>
impressive that such an issue was opened (was still feeling things out over at tc39)

[00:43:41.0358] <DerekNonGeneric>
my suggestion to Luca Casonato is to not propose anything there until Q1 2022

[00:44:23.0989] <DerekNonGeneric>
(let alone transfer a proposal repo)

[00:46:30.0224] <jgraham>
> <@annevk:mozilla.org> Oh wow, over a 100 people here now, welcome all! 👋🏻

Yeah, without actually running the numbers, it feels like the hypothesis that moving to matrix might increase participation has been validated.

[01:48:31.0151] <sideshowbarker>
annevk: https://github.com/mdn/content/issues/7026 is accurate?
> Functions `toBinary` and `fromBinary` are buggy - they fail with "RangeError: too many function arguments" if the input string is too long. The exact length when it starts to fail [seems to depend on the browser](https://stackoverflow.com/questions/22747068/is-there-a-max-number-of-arguments-javascript-functions-can-accept). 

[01:50:30.0338] <sideshowbarker>
ah https://stackoverflow.com/questions/22747068/is-there-a-max-number-of-arguments-javascript-functions-can-accept is about *“Is there a max number of arguments JavaScript functions can accept?”* in general

[01:51:48.0481] <Luca Casonato>
Yeah, I think V8's max 2^16

[01:54:13.0814] <sideshowbarker>
yeah it seems surprising for real code to be hitting that limit

[01:54:26.0505] <sideshowbarker>
maybe Spidermonkey has a much lower limit

[01:55:13.0245] <sideshowbarker>
so my next question is, does the change in https://github.com/mdn/content/pull/7027/files seem like a reasonable way to work around the limit?

[01:55:46.0598] <Luca Casonato>
I dislike the use of `reduce()`. I think it would be a lot more readable with another for loop.

[01:56:18.0572] <sideshowbarker>
hmm yeah

[01:56:25.0479] <sideshowbarker>
I’ll add a comment

[01:56:38.0366] <sideshowbarker>
thanks!

[01:56:54.0558] <Luca Casonato>
no problem :-)

[02:03:34.0537] <DerekNonGeneric>
Luca Casonato: not sure how important it is to you, but...

[02:03:37.0847] <DerekNonGeneric>
> Also fwiw tcq2 built on fluid framework should be out q1 2022

[02:03:58.0997] <DerekNonGeneric>
source: https://matrixlogs.bakkot.com/TC39_General/2021-06-24

[02:06:46.0932] <DerekNonGeneric>
the presentation queue currently in use is sorta messed up and their notes taking methodology needs work

[02:07:06.0857] <Luca Casonato>
TC39 you mean?

[02:07:34.0821] <DerekNonGeneric>
indeed

[02:08:49.0844] <Luca Casonato>
The base64 proposal for TC39 is bakkot's. My alternative is proposed as an addition to the HTML spec, not ES: https://github.com/lucacasonato/proposal-binary-encoding

[02:09:28.0494] <Luca Casonato>
The two proposals were opened two weeks from each other, kinda confusing. Mine has a larger scope, and support for more encodings.

[02:10:39.0303] <Luca Casonato>
I should probably make that clear in the explainer

[02:11:07.0604] <DerekNonGeneric>
hmm, you would need to find a champion (delegate) either way, so bakkot might be your best bet on that

[02:11:59.0791] <DerekNonGeneric>
w/o having looked at the other proposal you mentioned, i wonder if a merger would be a good idea or not

[02:12:53.0023] <Luca Casonato>
Maybe yeah - I would want to slightly expand the scope of the TC39 proposal. The main differenciator is that my proposal allows for easier future extensions, and streaming support.

[02:12:58.0333] <Luca Casonato>
 * Maybe yeah - I would want to slightly expand the scope of the TC39 proposal. The main differentiator is that my proposal allows for easier future extensions, and streaming support.

[02:13:43.0348] <annevk>
To be clear, you don't need a TC39 delegate for HTML spec additions; WHATWG has its own process

[02:16:16.0129] <DerekNonGeneric>
what is considered a "proposal" to tc39ers is a bit of a mystery to me, but my intention wasn't to delay

[02:17:14.0784] <DerekNonGeneric>
apparently, they only consider something a "proposal" if a delegate has it on their agenda

[02:18:24.0466] <Luca Casonato>
I don't think the WHATWG has any strict definition of "proposal". I think anything with an open issue on an existing spec or an explainer is considered a proposal. The bar is pretty low.

[02:25:06.0027] <DerekNonGeneric>
not sure which org would be best for either of the proposals mentioned, but be able to help w/ nodejs impl

[02:25:43.0665] <DerekNonGeneric>
if node is currently misaligned, let me know and we see about getting that fixed if its not a huge PITA

[02:35:15.0210] <DerekNonGeneric>
we currently have a few dependencies in our repo vendored in from elsewhere, so it might be as simple as adding the streaming cryto dependency to our source tree

[02:36:33.0396] <DerekNonGeneric>
we would expose it through V8, but don't necessarily need to wait for stage advancement in tc39 and such

[02:40:25.0385] <DerekNonGeneric>
the main advantage to the whole proposal-stage-etc stuff is being able to collect feedback from smart ppl

[03:01:24.0265] <DerekNonGeneric>
(that's just node though)

[03:02:00.0674] <sideshowbarker>
annevk: about https://github.com/mdn/content/issues/6970

[03:02:24.0824] <sideshowbarker>
…I’m trying to figure out what wording to add to https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams/URLSearchParams#parameters

[03:04:12.0733] <Luca Casonato>
sideshowbarker: It actually doesn't explicitly accept `FormData`. `FormData` just happens to be an iterator that conforms to `sequence<sequence<USVString>>` which URLSearchParams can accept (so it is webidl converted).

[03:05:36.0344] <sideshowbarker>
Luca Casonato: right but it’s kind of an important instance of “just happens to be”

[03:06:43.0085] <Luca Casonato>
Ah sure. In that case maybe ```- A sequence of USVString pairs, representing names/values. This includes `FormData` objects.```?

[03:06:58.0084] <Luca Casonato>
Or just demo it in an example?

[03:06:59.0479] <Andreu Botella (he/they)>
In any case, a mention of `FormData` should note that `File` entries will be serialized as `[object File]` rather than as their filename as they would in an `application/x-www-form-urlencoded` form

[03:07:24.0233] <sideshowbarker>
> <@lucacasonato:matrix.org> Ah sure. In that case maybe ```- A sequence of USVString pairs, representing names/values. This includes `FormData` objects.```?

Yeah maybe something as simple as that would be enough

[03:07:41.0293] <annevk>
sideshowbarker: sounds similar to that other case where URL "is accepted" because it stringifies

[03:07:50.0984] <sideshowbarker>
annevk: right

[03:07:57.0850] <annevk>
sideshowbarker: you prolly want to establish some kind of pattern in terms of wording

[03:08:20.0820] <sideshowbarker>
yeah I guess I should be consistent

[03:10:15.0061] <sideshowbarker>
anyway I guess this one to me seems a bit exceptional in that it really is the common case rather than the case of giving URLSearchParams some name/value pairs in some other way

[03:10:26.0339] <sideshowbarker>
or maybe that’s just me

[03:13:07.0027] <sideshowbarker>
> A {{domxref("USVString")}} or any other object with a <a href="/en-US/docs/MDN/Contribute/Howto/Write_an_API_reference/Information_contained_in_a_WebIDL_file#stringifiers">stringifier</a> — including, for example, an {{htmlelement("a")}} or {{htmlelement("area")}} element

…is how I previously worded the stringifier case

[03:13:26.0616] <sideshowbarker>
/me will write up a PR with similar wording for this

[05:43:47.0383] <annevk>
That sounds good to me, FWIW

[05:44:45.0635] <annevk>
sideshowbarker: writing that down I realized what I now see Andreu Botella (he/they) already noted above, `Blob`/`File` inside `FormData` will behave unexpectedly and it should probably mention that

[05:45:10.0423] <sideshowbarker>
yeah I will add that

[08:07:48.0551] <annevk>
jgraham: foolip: shall I update https://github.com/whatwg/sg/pull/164 to say Test Utils?

[08:08:47.0545] <annevk>
And now https://www.w3.org/2021/06/WHATWG-W3C-MOU_2021_update.html is published (yay!) I guess we should also work on a PR for Web IDL

[08:33:20.0574] <annevk>
If anyone has questions about that let me know, but it basically formalizes a number of things that were already in motion. And as it happens making things formal after the fact can take a lot of time.

[08:33:50.0456] <Andreu Botella (he/they)>
I noticed the webidl branch on sg a while ago, and I was wondering what took it so long

[08:36:49.0581] <jgraham>
annevk: I'm happy for you to update it.

[08:44:11.0346] <annevk>
Andreu Botella (he/they): for reference, adding a one-sentence copyright line to Web Applications 1.0 (former name of HTML) took six months

[08:52:32.0612] <bakkot>
> <@dereknongeneric:mozilla.org> the presentation queue currently in use is sorta messed up and their notes taking methodology needs work

fwiw I'm not really sure what this is referring to; the queue works great and we have pretty much verbatim notes these days. did you have a different experience at the last meeting? I didn't see you in the call, I think

[09:41:31.0569] <DerekNonGeneric>
(hoping to drive innovation here, not argue) am looking forward to all suggestions that were mention

[09:44:48.0821] <DerekNonGeneric>
* (hoping to drive innovation here, not argue) am looking forward to all suggestions that were mentioned (having the queue use a publicly-visible representation i.e., sheets) would help

[09:58:03.0754] <DerekNonGeneric>
bakkot, here is what i was referring to when i was commenting about the upgrade path

[09:58:05.0698] <DerekNonGeneric>
https://developers.google.com/sheets/api/reference/rest

[10:02:00.0324] <DerekNonGeneric>
the point that was mentioned by Rob about the history tracking offered by Docs was also key

[10:02:02.0314] <DerekNonGeneric>
https://developers.google.com/docs/api/reference/rest

[10:05:38.0112] <DerekNonGeneric>
being placed on the queue by the bot sounded interesting as well, but not trying to tell you how to run the show

[10:06:15.0864] <DerekNonGeneric>
 * being placed on the queue by the bot sounded interesting as well, but not trying to tell you how to run the show, just wanted to point out that a lot of good advice was provided and would like to see it materialize

[10:09:31.0174] <annevk>
DerekNonGeneric: prolly best to take that to #tc39-general:matrix.org or some such

[10:10:54.0603] <DerekNonGeneric>
yeah, agreed, getting back on-topic sounds good -- am totally in the dark about WHATWG processes too lol

[10:16:05.0357] <DerekNonGeneric>
going to have to do my research i guess, but if anyone wants to link how proposals work here, i will bookmark it

[10:17:08.0503] <DerekNonGeneric>
 * going to have to do my research i guess, but if anyone wants to link how proposals work here, i will bookmark it for later seeing as how i am a bit busy writing a specification for something else

[10:21:15.0074] <DerekNonGeneric>
 * going to have to do my research i guess, but if anyone wants to link how proposals work here, i will bookmark it for later seeing as how i am a bit busy writing a specification for something else (still just a UI)

[10:29:22.0551] <DerekNonGeneric>
would be curious to know how one goes about writing something like the worklets specification https://html.spec.whatwg.org/multipage/worklets.html#worklets

[10:40:20.0729] <Domenic>
https://whatwg.org/faq#adding-new-features is probably the right place to start

[10:41:39.0928] <annevk>
And https://whatwg.org/working-mode

[10:42:20.0011] <annevk>
Domenic: so it could be I don't understand BYOB, but I thought at a high-level the concept was that the web developer would create a buffer + view, and the API would write data into that

[10:42:55.0170] <annevk>
Domenic: so what I don't understand in your PR is that there's a step where the API creates a buffer + view, when the size isn't sufficient

[10:55:37.0488] <Domenic>
annevk: the idea is that if your underlying source (i.e. network APIs) support it and the buffer is big enough, you write into it. E.g. for filesystem APIs were you can explicitly control how many bytes you request this works great. For network APIs you can't always control; flow control takes a while to propagate through TCP. So in that case we might have too many bytes to fit into the buffer.

[10:57:29.0964] <Domenic>
In actuality you wouldn't need to create any JS ArrayBuffer objects like the spec does so you do save a couple of mini-allocations. And since it's all hidden behind transferrability you could avoid copying in favor of slicing up memory regions and making making the new view point to the original region. But there's no way to write 64 KiB of data from the network into a 1 KiB developer-supplied buffer.

[10:58:10.0041] <annevk>
Maybe my confusion stems from the specification using JS views and buffers

[10:59:14.0555] <annevk>
Domenic: how does it work if you do read(largeView) and the network is slow? You have to wait a long time?

[10:59:37.0760] <Domenic>
annevk: no in that case you get back your buffer with however many bytes were available and a view onto only the bytes that were written into it

[11:00:11.0391] <Domenic>
https://github.com/whatwg/streams/pull/1145 is a proposal for the "wait a long time" variant, which in some cases might be convenient.

[11:00:40.0094] <annevk>
Ah okay, so you basically get each chunk or however many chunks a UA decides to combine

[11:01:13.0311] <annevk>
And the API is a bit different from encodeInto in that it returns a view

[11:01:44.0287] <Domenic>
Hmm yeah I never thought to compare with encodeInto

[11:01:45.0903] <annevk>
In principle you only need to know how much was written, right?

[11:02:51.0882] <Domenic>
You also need to know the new ArrayBuffer object identity (same backing memory) since it went through a transfer dance

[11:03:25.0199] <annevk>
Aah, thanks. I think I understand it a bit better now. I'll look into the queuing thing tomorrow I suspect, unless a lot of other things pile up.

[11:04:01.0270] <Domenic>
np, no rush on any of this I don't think

[11:04:22.0441] <Domenic>
It's slightly more near-term-relevant than it used to be because WebTransport is my impression.

[11:07:18.0392] <Domenic>
https://twitter.com/nevali/status/1416107137714040845 I can get behind this

[11:19:09.0216] <timothygu>
annevk: what would the process be like for publishing review drafts for IDL? Would the editors be responsible for that or do you usually publish the RDs for all the specs

[11:21:11.0628] <annevk>
timothygu: we'd handle it automatically through review.py in whatwg/meta

[11:21:46.0233] <annevk>
timothygu: which effectively comes down to me / foolip / Domenic

[11:22:03.0787] <annevk>
If there's a build error in the main file it might involve you though

[11:22:24.0227] <timothygu>
great! sounds good

[14:20:00.0817] <Luca Casonato>
This might have been one of the fastest turnarounds for a new spec addition in a while: https://github.com/w3c/webcrypto/pull/266. Added to Chrome, Firefox, Safari, Deno and Node in only 17 days. Already shipped in stable latest Deno release.

[14:20:14.0425] <Luca Casonato>
Granted it is a tiny addition and change, but still good to see.

[14:20:27.0359] <Luca Casonato>
 * This might have been one of the fastest turnarounds for a new spec addition in a while: https://github.com/w3c/webcrypto/pull/266. Added to Chrome, Firefox, Safari, Deno and Node in only 17 days. Already shipped in latest stable Deno release.

[15:37:24.0298] <bakkot>
glad to see webcrypto getting some love again!


2021-07-20
[00:24:44.0128] <annevk>
Yeah, nice work by timothygu and twiss

[00:50:13.0302] <Andreu Botella (he/they)>
I didn't realize infinities were converted to 0 when cast to a WebIDL integer type

[00:50:30.0625] <Andreu Botella (he/they)>
I was trying to do `setTimeout(fn, a ? Number.POSITIVE_INFINITY : 10 * 1000)`

[00:50:50.0586] <Andreu Botella (he/they)>
 * I was trying to do `setTimeout(fn, timeout ? 10 * 1000 : Number.POSITIVE_INFINITY)`

[01:56:56.0496] <sideshowbarker>
https://github.com/validator/validator/issues/1192

[01:57:51.0726] <sideshowbarker>
per-spec should the following be a document-conformance (authoring-conformance error)?
```html
<input type='text' autocomplete=' ' />
```

[04:22:32.0542] <sideshowbarker>
https://github.com/mdn/content/issues/7049 could use some help/attention from someone among us with strong domain knowledge (and strong opinions…) about Shadow DOM

[09:01:44.0275] <Domenic>
> <@sideshowbarker:mozilla.org> per-spec should the following be a document-conformance (authoring-conformance error)?
> ```html
> <input type='text' autocomplete=' ' />
> ```

I believe it should per the authoring conformance requirements in https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fe-autocomplete

[09:02:14.0755] <Domenic>
Hmm nope https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#set-of-space-separated-tokens did not say what I thought it said

[09:02:45.0316] <Domenic>
So it seems like both autocomplete="" and autocomplete=" " should be valid?

[09:20:23.0853] <sideshowbarker>
oh

[09:21:08.0112] <sideshowbarker>
well currently I’m reporting the empty string as invalid, but not the whitespace-only string

[09:22:05.0256] <sideshowbarker>
I wonder if something changed in the spec after the time when I originally implemented this in the checker

[09:24:19.0006] <sideshowbarker>
though, doesn’t really matter because I need to make it conform to the current spec anyway

[09:31:21.0484] <sideshowbarker>
meanwhile FYI for anybody curious, https://github.com/mdn/content/pull/7092 is a PR for converting the sources for all the MDN JavaScript docs from HTML to Markdown


2021-07-21
[08:58:14.0563] <annevk>
Domenic: I can write a simple test for reportError as a start

[08:58:21.0896] <annevk>
Domenic: unless you already have something locally

[09:00:23.0809] <Domenic>
annevk: I've got nothing, please do!

[10:36:13.0745] <DerekNonGeneric>
sideshowbarker (et al), something i really appreciate in a lot of docs and specs i have encountered lately is the table of contents that follows you as you scroll and have been looking into seeing how to best implement it for my own purposes similar to the following link: https://ebidel.github.io/demos/sticky-position-event.html

[10:42:54.0679] <DerekNonGeneric>
not surprised it isn't more common, it turns out to be quite an endeavor if wanting to do this in amp, but i found a nice codepen someone wrote up (the code comments are in japanese too, which is fun) https://codepen.io/yuheijotaki/pen/zeqZVd

[15:12:33.0104] <DerekNonGeneric>
the codepen above could be slightly old, but they could have used `scroll-padding-top` there instead and it would look a lot better to me https://codepen.io/chriscoyier/pen/NJJERg

[15:16:32.0533] <DerekNonGeneric>
(these things are just nice to have, not really anything urgent, but it does seem doable afaict)

[16:57:57.0505] <sideshowbarker>
https://github.com/mdn/content/issues/7138 could use some help from somebody with experience writing about Service Worker


2021-07-22
[08:28:25.0822] <bkardell>
totally random q.... would it be useful for anyone else if the HTML spec had a service worker / offline ? Has someone made a fork like that or something? Was it discussed?

[08:29:20.0133] <bkardell>
I feel like I open this doc for searching very often and it generally takes a long time to load - if my connection just happens to be slow atm it is like... very very slow

[08:29:41.0135] <bkardell>
I guess I could grab the PDF but ick

[08:30:02.0698] <bkardell>
fwiw I have given this about 1m thought

[08:30:07.0988] <Domenic>
It's been discussed and is desired; all the other specs have it. It's just a bit more work nobody has done yet.

[08:30:15.0459] <Domenic>
The loading time issue is Chrome-specific though.

[08:30:21.0413] <Domenic>
And a service worker won't help that

[08:30:28.0984] <Domenic>
It's something about the HTML parser not dealing well with large documents.

[08:30:38.0424] <bkardell>
ok

[08:32:13.0558] <bkardell>
> <@domenicdenicola:matrix.org> It's something about the HTML parser not dealing well with large documents.

yeah wow it is striking

[08:40:01.0184] <bkardell>
never compared in FF before 

[09:04:18.0319] <annevk>
Browsers should just move to daily updates and bundle the HTML Standard

[09:05:44.0636] <bkardell>
:)

[09:15:29.0491] <jgraham>
Although if he problem is HTML parsing, they'd need to bundle some kind of dump of the internal representation.

[09:15:58.0468] <jgraham>
Might be easier for Chrome to just bundle gecko and use it for that URL ;p


2021-07-23
[20:05:41.0422] <sujaldev>
does there exist a room similar to this one but for css?

[23:49:39.0580] <hober>
> <@sujaldev:matrix.org> does there exist a room similar to this one but for css?

There's #css on irc.w3.org

[02:05:04.0514] <sujaldev>
thank you!


2021-07-24
[13:25:11.0124] <Nate Mann>
Hi


2021-07-25

2021-07-26
[07:16:05.0761] <wanderview>
there are some changes to chromium's html parser landing in canary right now... curious to see if it will help with loading something like html spec: https://bugs.chromium.org/p/chromium/issues/detail?id=1041006

[07:16:45.0354] <wanderview>
I guess mainly stuff to enable running some experiments, so far


2021-07-27
[09:52:56.0646] <sideshowbarker>
Domenic: GPHemsley can’t connect to https://wiki.whatwg.org/wiki/Fork_tracking 

[09:53:35.0113] <Domenic>
sideshowbarker: very weird... https://downforeveryoneorjustme.com/wiki.whatwg.org?proto=https

[10:01:47.0461] <sideshowbarker>
must be a routing issue

[10:03:07.0730] <sideshowbarker>
```
15. if-ae-9-2.tcore1.n75-newyork.as6453.net                                                                           0.0%    10  164.9 191.4 164.9 290.0  45.8
16. 66.110.96.26                                                                                                      0.0%    10  161.1 177.2 161.0 247.3  30.9
17. (waiting for reply)
```

[10:05:33.0286] <sideshowbarker>
d’oh, fixed it

[10:06:36.0927] <sideshowbarker>
I had an old `165.227.84.185 wiki.whatwg.org` line in my `/etc/hosts`

[10:31:13.0450] <Domenic>
sideshowbarker: now that MDN seems to do more things with its issue tracker, should we add something to the PR template asking us to file an issue on MDN for changes that might require doc updates?

[10:39:41.0448] <annevk>
Interesting how a force push of main shows up in all PRs, but not https://github.com/whatwg/html/commits

[11:00:10.0271] <sideshowbarker>
Domenic: yeah, good idea — that would be great

[11:01:49.0288] <sideshowbarker>
speaking of MDN, we unfortunately still have many code examples there with iframes that call `alert()` — which outside of just being quaint and bad, no longer works in Chrome:
> A different origin subframe tried to create a JavaScript dialog. This is no longer allowed and was blocked. See https://www.chromestatus.com/feature/5148698084376576 for more details.

[13:29:31.0651] <Domenic>
tabatkins: can you help find a reviewer for https://github.com/w3c/csswg-drafts/pull/6300 ?

[13:29:57.0914] <Domenic>
Although I guess I could ping emilio directly ^

[16:57:24.0773] <EveryOS>
Hello
Section 4.2.6 of the WhatWG HTML spec specifies what immediately happens when a style element is encountered. It references CSSWG, which says that the stylesheet gets added to the "document or shadow root CSS style sheets".
I was wondering when these are actually applied to the document? And when it is determined if a certain rule in the root CSS stylesheets applies to a certain element? What spec should I look at for info like this?


2021-07-28
[17:01:45.0470] <Domenic>
Some CSS spec, I imagine, but I don't know which.

[17:06:51.0432] <EveryOS>
Ok, thanks
I'll look among the CSS specs

[17:06:58.0867] <EveryOS>
And see if I can find which

[01:17:13.0085] <sideshowbarker>
https://stackoverflow.com/questions/68556581/why-cant-i-fetch-an-object-url-aka-blob-url-cross-site-and-cross-frame

[01:18:37.0760] <sideshowbarker>
I’m vaguely recall there being a workaround for that in JavaScript (I mean other than using browser runtime flags to disable security)

[03:52:13.0113] <annevk>
EveryOS: CSSOM defines part of the infrastructure (though there are some bugs in the details and this area needs work)

[03:52:36.0005] <annevk>
EveryOS: but basically the moment you insert a `<style>` element the styles "apply"

[03:56:56.0713] <annevk>
sideshowbarker: I added an answer

[07:19:07.0505] <sideshowbarker>
annevk: thanks much

[13:15:54.0837] <tabatkins>
Domenic: Yeah emilio 


2021-07-29
[08:05:25.0218] <wanderview>
anyone else having problems with the bikeshed server?  I'm getting "<html><body><p><strong>WARNING: </strong>mysqli_connect(): (HY000/2002): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)</p></body></html>"

[08:10:55.0137] <annevk>
Domenic: implementations have non-JS streams

[08:11:16.0364] <annevk>
(re Fetch architecture)

[08:12:38.0400] <annevk>
wanderview: you can ping plinns on GitHub for help perhaps

[08:15:36.0051] <wanderview>
what repo is the bikeshed server associated with?

[08:19:24.0405] <annevk>
I don't know, if you don't have a PR or something I guess I'd file an issue against tabatkins/bikeshed

[08:20:55.0733] <Sam Sneddon [:gsnedders]>
wanderview: none, plinss hosts it (see also drafts.csswg.org being down)

[08:21:46.0004] <wanderview>
I guess if the outage is wider scope then maybe its already known about

[08:27:50.0426] <Domenic>
> <@annevk:mozilla.org> Domenic: implementations have non-JS streams

Sure but when do they create ReadableStream objects and enqueue from them, is the question. I think you could get away without a first-class non-JS stream primitive in the spec since you can just pretend the data hasn't reached you yet if it's queued up.

[08:29:05.0240] <annevk>
Domenic: I suspect it gets created the moment someone "touches" it

[08:29:22.0501] <Domenic>
Hmm I don't think that's true in Chrome

[08:29:24.0615] <annevk>
As in, once someone does res.body

[08:30:55.0473] <Domenic>
No, that returns an existing BodyStreamBuffer->Stream() it seems

[08:31:04.0933] <Domenic>
Trying to find out when those are created

[08:31:22.0770] <Domenic>
(the implementation actually seems to use the same JS-stream infrastructure for blob() and arrayBuffer() as the spec does, interestingly!)

[08:32:08.0353] <annevk>
The JS object is eagerly allocated? Interesting. I thought those were pretty much always lazily created, but maybe that's only in Gecko.

[08:32:08.0691] <Domenic>
The ReadableStream is created the same time the Response object is created

[08:32:39.0349] <Domenic>
Well the JS object is created lazily but the "IDL" (C++) object is created eagerly

[08:32:56.0553] <wanderview>
bikeshed seems to be fixed now

[08:33:44.0280] <annevk>
I see, but in theory the IDL object could be cross-thread...

[08:33:59.0531] <Domenic>
O_o I guess in theory, but not in implementations

[08:34:00.0527] <annevk>
Might be a bit confusing though


2021-07-30
[05:56:22.0993] <laurentdhont>
Good evening to all. I wonder where I can find the specification for the automatic creation of variables using the id of HTML elements. Should I look in the ES or HTML spec, and what is the term for this auto creation?

[05:57:24.0213] <Ms2ger 💉💉>
HTML

[05:57:39.0478] <Ms2ger 💉💉>
https://html.spec.whatwg.org/multipage/window-object.html#named-access-on-the-window-object

[06:00:11.0106] <Andreu Botella (he/they)>
They're not variables. In JS, when you use a variable name that isn't in scope, it's looked up as a property of the global object (`window` in this case)

[06:06:45.0738] <laurentdhont>
Thank you very much, this really helped. Is there any way to disable this? I guess not

[08:23:50.0330] <Sam Sneddon [:gsnedders]>
see also https://tc39.es/ecma262/#sec-global-environment-records for global environment records in ES


2021-07-31
[08:56:43.0690] <sideshowbarker>
in the document at https://dom.spec.whatwg.org/#introduction-to-the-dom aren’t there in fact two newlines at the end of the body element?

[08:58:09.0072] <sideshowbarker>
the spec shows it as having a single newline, but if you inspect the actual DOM or serialize it, I think you’ll find two newlines there, right?

[09:37:43.0795] <Domenic>
> <@sideshowbarker:mozilla.org> the spec shows it as having a single newline, but if you inspect the actual DOM or serialize it, I think you’ll find two newlines there, right?

I only see one:

[09:40:12.0243] <sideshowbarker>
doesn’t the DOM inspector elide the newlines?

[09:40:24.0955] <sideshowbarker>
I mean in that view

[09:43:37.0367] <sideshowbarker>
if you select **Edit as HTML**, I think you’ll see this:
```html
<html class="e"><head><title>Aliens?</title></head><body>Why yes.

</body></html>
```

[09:44:14.0435] <sideshowbarker>
oh sorry, I see now I didn’t look through the whole image

[09:50:22.0265] <Domenic>
Yeah if I choose edit as HTML I only get one newline

[09:50:39.0007] <Domenic>
I wonder if there's a \r\n -> \n\n thing going on at some point

[09:51:41.0616] <sideshowbarker>
aha

[09:51:46.0769] <sideshowbarker>
probably that?

[09:52:04.0560] <sideshowbarker>
platform line-ending difference?

[09:52:20.0345] <sideshowbarker>
I am looking at it on macOS

[09:53:17.0285] <sideshowbarker>
but I thought the serializer normalized all that

[09:53:44.0151] <sideshowbarker>
 anyway, the context is https://github.com/mdn/content/pull/7472

[09:54:47.0947] <Domenic>
Yeah but maybe like copy-to-clipboard did something weird

[09:56:37.0480] <sideshowbarker>
I’m trying to replace the horrible description (copied from the DOM Level 3 spec) in https://developer.mozilla.org/en-US/docs/Web/API/Text with a description that actually means something to people

[09:57:02.0103] <sideshowbarker>
> <@sideshowbarker:mozilla.org> I’m trying to replace the horrible description (copied from the DOM Level 3 spec) in https://developer.mozilla.org/en-US/docs/Web/API/Text with a description that actually means something to people

yeah probably so, it seems

[16:54:25.0511] <sideshowbarker>
https://github.com/mdn/content/issues/7470 is a good issue for anybody looking to help improve MDN and who has familiarity with the canvas 2D API