2021-12-01 [20:20:16.0746] Hi guys, is this room appropriate to ask questions regarding the HTML spec? [20:21:42.0914] I'll ask for now, but feel free to delete it if it's not allowed, so here is my question: [20:21:53.0439] * I'll ask for now, but feel free to delete it if it's not allowed, so here is my question: [20:29:54.0931] In the HTML parsing section, specifically the "Named character reference state", we have the following info: >>> Consume the maximum number of characters possible, where the consumed characters are one of the identifiers in the first column of the named character references table. Append each character to the temporary buffer when it's consumed. >>[If there is a match]: If the character reference was consumed as part of an attribute, and the last character matched is not a U+003B SEMICOLON character (;), and the next input character is either a U+003D EQUALS SIGN character (=) or an ASCII alphanumeric, then, for historical reasons, flush code points consumed as a character reference and switch to the return state. >>[Otherwise:] If the last character matched is not a U+003B SEMICOLON character (;), then this is a missing-semicolon-after-character-reference parse error. Set the temporary buffer to the empty string. Append one or two characters corresponding to the character reference name (as given by the second column of the named character references table) to the temporary buffer. Flush code points consumed as a character reference. Switch to the return state. [20:33:50.0109] At what point do I decide to stop consuming? It's not clear , I know I can lookahead and stop matching when I encounter a semi-colon but the spec doesn't make that clear [20:35:09.0154] devsrealmguy: I think you basically stop consuming when thereโ€™s no match [20:35:20.0976] no substring match [20:38:40.0369] so if you get `&h`, keep consuming, `&he`, keep consuming, `&hel`, `&hell`, `&helli`, still consuming [20:39:28.0815] because those all are substring matches of valid character references [20:40:07.0990] but if you hit `&helliq`, stop consuming โ€” because that is not a substring match of any valid character reference [20:41:01.0746] Thanks for replying, I appreciate it a lot. I am on mobile, so, it's really hard to write and my sight is really poor, so, sorry if I my grammar is wrong. And yes, that is exactly what I am doing, what if you have ¬ and ¬in? [20:44:06.0282] > but if you hit `&helliq`, stop consuming โ€” because that is not a substring match of any valid character reference Brilliant, I was looking to stop consuming when I encounter a semi-colon but you just nailed it. [20:54:43.0723] Never mind with the ¬it and ¬in. Got it, thanks ๐Ÿ˜Š [23:29:26.0200] morning annevk, I think https://github.com/whatwg/fetch/pull/1311 is reviewable again, and I have two other pending ones (preload & controller), when you get the chance to look [06:48:50.0645] I think I am done with covering the tokenization state, the only state that is a bit difficult is the "Named Character Reference State". Just to confirm I didn't mess things up, this point says: 1) If the last character matched is not a U+003B SEMICOLON character (;), then this is a missing-semicolon-after-character-reference parse error. 2) Set the temporary buffer to the empty string. Append one or two characters corresponding to the character reference name (as given by the second column of the named character references table) to the temporary buffer" An example of point 1 is this: "James & his brother went for launch". It is clear that the & is missing a semi-colon, so, is the point 2 saying to correct it to & (with the semi-colon) or is it saying to swap it with the codepoint which is U+00026 as that is what is given in the second column table which the point 2 is referring to. I was curious enough to check how other libraries did theirs, some are converting the codepoint to a character, some are appending the semi-colon and many ignored it. I can see why it trips people of. Where should I sail to? [06:49:13.0307] * I think I am done with covering the tokenizationstate, the only state that is a bit difficult is the "Named Character Reference State". Just to confirm I didn't mess things up, this point says: 1) If the last character matched is not a U+003B SEMICOLON character (;), then this is a missing-semicolon-after-character-reference parse error. 2) Set the temporary buffer to the empty string. Append one or two characters corresponding to the character reference name (as given by the second column of the named character references table) to the temporary buffer" An example of point 1 is this: "James & his brother went for launch". It is clear that the & is missing a semi-colon, so, is the point 2 saying to correct it to & (with the semi-colon) or is it saying to swap it with the codepoint which is U+00026 as that is what is given in the second column table which the point 2 is referring to. I was curious enough to check how other libraries did theirs, some are converting the codepoint to a character, some are appending the semi-colon and many ignored it. I can see why it trips people of. Where should I sail to? [06:49:33.0671] * I think I am done with covering the tokenization state, the only state that is a bit difficult is the "Named Character Reference State". Just to confirm I didn't mess things up, this point says: 1) If the last character matched is not a U+003B SEMICOLON character (;), then this is a missing-semicolon-after-character-reference parse error. 2) Set the temporary buffer to the empty string. Append one or two characters corresponding to the character reference name (as given by the second column of the named character references table) to the temporary buffer" An example of point 1 is this: "James & his brother went for launch". It is clear that the & is missing a semi-colon, so, is the point 2 saying to correct it to & (with the semi-colon) or is it saying to swap it with the codepoint which is U+00026 as that is what is given in the second column table which the point 2 is referring to. I was curious enough to check how other libraries did theirs, some are converting the codepoint to a character, some are appending the semi-colon and many ignored it. I can see why it trips people of. Where should I sail to? [06:51:51.0877] * I think I am done covering the tokenization state, the only state that is a bit difficult is the "Named Character Reference State". Just to confirm I didn't mess things up, this point says: 1) If the last character matched is not a U+003B SEMICOLON character (;), then this is a missing-semicolon-after-character-reference parse error. 2) Set the temporary buffer to the empty string. Append one or two characters corresponding to the character reference name (as given by the second column of the named character references table) to the temporary buffer" An example of point 1 is this: "James & his brother went for launch". It is clear that the & is missing a semi-colon, so, is the point 2 saying to correct it to & (with the semi-colon) or is it saying to swap it with the codepoint which is U+00026 as that is what is given in the second column table which the point 2 is referring to. I was curious enough to check how other libraries did theirs, some are converting the codepoint to a character, some are appending the semi-colon and many ignored it. I can see why it trips people of. Where should I sail to? [06:57:09.0409] Step 1 is just "the author screwed up" - you should ignore the step completely unless you surface parse errors somehow [06:59:28.0394] `&` without the semicolon is in the table, so you just parsed an "&" [07:00:12.0195] Did that help or just confuse more? :) [07:00:28.0904] You mean, I should add the "&" to the temporary buffer? [07:02:23.0453] Yes, it seems like that's the result [07:02:41.0652] /me was unaware of this particular ugly corner of the parser [07:03:38.0426] Okay, thanks. I spent tons of time on just that state than the rest of the states combined ๐Ÿ˜‚ [07:03:52.0913] * Okay, thanks. I spent tons of time on just that states than the rest of the state combined ๐Ÿ˜‚ [07:04:32.0147] * Okay, thanks. I spent tons of time on just that state than the rest of the state combined ๐Ÿ˜‚ [07:04:44.0168] * Okay, thanks. I spent tons of time on just that state than the rest of the states combined ๐Ÿ˜‚ [09:02:29.0923] At some point we should blog about the fact that we've added/are adding a bunch of new standards: Web IDL, Test Utils, WebSockets, and File System [09:02:36.0599] I guess I will try to draft something quick [11:28:57.0652] Posted https://blog.whatwg.org/new-living-standards-2021 and tweeted https://twitter.com/WHATWG/status/1466126880344616966 [14:38:01.0032] I seem to remember there was a tool that lists all Web IDL interfaces, where they are defined and where they are used in other specifications. Anyone knows what it was called again? [14:38:57.0710] https://dontcallmedom.github.io/webidlpedia/index.html ? [14:39:28.0920] Yep, that's it. Thanks! ๐Ÿ˜ [14:40:00.0280] There's also https://github.com/w3c/webref/tree/main/ed/idl 2021-12-02 [22:24:31.0155] Anybody knows of specific implementation difficulties with the `search` element in any of the 3 browsers? [22:33:36.0773] Are there hotkeys on whatpr.org? [22:35:09.0197] * Are there hotkeys on whatpr.org? Yep, J.K. Rowling [22:37:18.0708] Is there a way to filter seciton number changes from the diffs? [02:28:00.0895] Andreu Botella (he/they): care to review https://github.com/whatwg/fetch/pull/1364? (very small) [02:28:23.0773] Oh maybe wait, build is still failing [06:50:31.0079] The triage meeting will take place here on matrix? [07:02:17.0802] No, it's a video call [07:02:56.0741] I don't find any info about what software is used for the call. [07:05:31.0215] What's the conferencing software used? [07:07:28.0895] I think it's Google Meet, no software needed other than a browser [07:07:48.0296] and a google account ;-) [07:08:38.0607] I don't think so [07:09:27.0847] oh, great how is the meeting link/code shared? [07:11:30.0750] Unless you are different from Kaleidea on GitHub I think past mentioned they will get you an invite? [07:12:15.0265] Yes, I was wondering, how he'll do it. [07:12:45.0177] Presumably via a calendar invite [07:31:15.0651] kaleidea: FWIW, the fundamental problem with inheritance for HTML elements is that engine logic is based on local name, not type of class; this is also why custom elements has the is="" hack (which in retrospect I wish we never shipped) [07:32:03.0459] The other problem with a new element for navigation is bad XSS filters and just overall complexity. [07:36:27.0547] > <@annevk:mozilla.org> kaleidea: FWIW, the fundamental problem with inheritance for HTML elements is that engine logic is based on local name, not type of class; this is also why custom elements has the is="" hack (which in retrospect I wish we never shipped) HTMLFormElement is a final class (all HTML*Elements are), so inheritance quickly fell out as a solution. I've made a HTMLFormElement, distinguished only by qualified name (namespace incl.). This is the same solution that's used for
,
, etc. - and would be used for the div-based -, but with HTMLElement being the instantiated class. [07:37:09.0603] However, being a HTMLFormElement, all the form logic also applies without additional effort. [07:37:48.0174] Right, I'm saying that's false. [07:38:20.0112] Where does it fail? [07:39:04.0682] I recommend reading up on the web component discussions around inheritance, maybe that will help clear it up. [07:39:23.0696] Sure, do you have a link handy? [07:42:24.0881] Or a starting point. Is it all in the GH issues? [07:48:58.0849] I'll investigate this clue, might take a day or more. https://github.com/whatwg/html/issues?q=is%3Aissue+custom+element+inheritance is not immediately useful. If you find any pointers in the meantime, I'll appreciate it. [07:49:29.0946] * I'll investigate this clue, might take a day or more. https://github.com/whatwg/html/issues?q=is%3Aissue+custom+element+inheritance is not immediately useful. If you find any pointers in the meantime, I'll appreciate it. [07:53:00.0314] kaleidea: WICG/webcomponents is prolly a better starting point; you'll also run into it if you try to implement it in a browser [08:32:11.0469] /me wonders if mek is the one from Google ๐Ÿ˜Š [08:32:29.0401] /me is pretty close to having a working fork of File System [08:48:01.0552] Well, that went better than expected: https://whatpr.org/fs/1.html [08:50:23.0548] Domenic: I noticed PR Preview didn't have access to websockets yet; now fixed [08:54:17.0670] > * <@annevk:mozilla.org> wonders if mek is the one from Google ๐Ÿ˜Š yes, that's me. Figured I should finally figure out how this matrix thing works.... Sorry I didn't reply to your email yesterday [08:56:38.0347] mek: that's quite alright, I think I figured out a model that works, although entries are a tad underspecified so maybe not ๐Ÿ™‚ [08:56:54.0019] annevk: oh dang, I did miss that step... thanks [08:57:42.0364] Oh I guess one thing that's missing still is a logo [08:59:56.0774] Storage already took the floppy disk :( [09:01:53.0573] mek: would a folder icon of sorts work? [09:02:25.0826] works for me [09:06:35.0206] I should have some time tomorrow / early next week. We need to wait a little longer anyway as one SG rep wanted to confirm something internally [10:42:54.0161] Domenic: Hi, are there WPT for shadow DOM delegatesFocus + autofocus yet? (not talking about ) [10:43:03.0786] * Domenic: Hi, are there WPT for shadow DOM delegatesFocus + autofocus yet? (not talking about ) [10:43:38.0752] Pretty sure yes... [10:43:59.0395] I think the introduction of the focus delegate thing slightly changed shadow DOM delegatesFocus if I'm not mistaken [10:44:53.0504] (e.g. it now looks for the autofocus delegate, whereas it didn't before) [10:45:04.0817] https://github.com/web-platform-tests/wpt/commit/facfe0234c1252393bd8da54d7b33444928ebb9b I think [10:45:32.0383] A few others in https://github.com/web-platform-tests/wpt/commits/master/shadow-dom/focus [10:46:13.0359] I guess https://github.com/whatwg/html/pull/7361 changes not just the case so should possibly come with tests for non-dialog scenarios... [10:46:51.0016] perfect, thanks 2021-12-03 [02:20:49.0243] Noam Rosenthal: I suspect it's past the end of your work week already, but let me know (whenever really) if I missed any outstanding review requests. For the controller one I'd really like Jake Archibald and Yutaka to take a look. I'll ping them. [02:22:06.0821] annevk: the controller one is https://github.com/whatwg/fetch/pull/1329/ yeah? [02:22:41.0058] Jake Archibald: yeah and a related one in SW I pointed to in the final comment of that PR [02:23:17.0379] Cool. Not sure I'll get to it today, but I've got it on my todo list [02:23:30.0315] Thanks! [02:54:08.0114] > <@annevk:mozilla.org> Noam Rosenthal: I suspect it's past the end of your work week already, but let me know (whenever really) if I missed any outstanding review requests. For the controller one I'd really like Jake Archibald and Yutaka to take a look. I'll ping them. Thanks! Youโ€™re all caught up with my PRs and I will look into the details next week. [05:24:09.0595] > <@noamr:matrix.org> Thanks! Youโ€™re all caught up with my PRs and I will look into the details next week. Actually I had an hour to revise now even though it's past my work week :) [06:23:27.0433] hm, the HTML and fetch specs still have the websocket sections [07:29:18.0964] Andreu Botella (he/they): Yutaka volunteered to take care of that 2021-12-06 [04:06:53.0606] annevk: currently the navigate spec often sends a request with referrer policy = "", referrer = "no-referrer". (e.g. for ) It would be more elegant if we just used referrer policy. Do you think that's possible? [04:28:23.0066] Domenic: that's probably feasible, though setting referrer directly is quicker in theory as it bypasses the referrer policy check [04:28:38.0189] (if you set it to "no-referrer", that is) [04:29:05.0620] Cool, OK 2021-12-07 [02:19:16.0515] selection in shadow DOM issue will have its birthday in a month: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15444 , later https://github.com/WICG/webcomponents/issues/79 [02:23:05.0595] Maybe make a cake in the shape of a "10", and give it a selection of fillings. [02:23:11.0393] (I'm so sorry) [04:19:25.0375] Noam Rosenthal: โ‰ซ is not ยป [04:19:39.0493] Noam Rosenthal: if they are indistinguishable in your editor, I recommend copying from https://infra.spec.whatwg.org/#lists [04:21:17.0162] gotcha annevk. I must say I find these ambiguous unicode characters in specs somewhat cumbersome... [04:24:34.0955] annevk: regarding `allow preloads` and custom headers, how would you suggest to ignore preloads when custom XHR/fetch() headers are present? [04:25:11.0207] Noam Rosenthal: I think the presence of any header would indicate a custom header [04:25:55.0977] annevk: ok [04:26:14.0255] Noam Rosenthal: you can guard the check with "unsafe-request flag" which only fetch() and XHR set [04:26:59.0578] As for the Unicode characters, they generally seem to work okay for me as long as I copy-and-paste. Could you elaborate on what makes them cumbersome? [04:27:19.0047] they're cumbersome because mistakes are not visible to the naked eye [04:27:45.0123] and they're not common characters in other forms of programming, and don't appear on keyboards [04:28:14.0394] I think that makes them unique among characters used in specs, but I might be wrong about that [04:29:27.0331] Well, the precedent here is JavaScript, which uses the same characters for its internal List type [04:29:55.0962] Yea, I figured there's some historical reason for this [04:32:04.0578] @annevk: regarding "allow preloads", I thought to keep it for now for the "sync XHR" case, I don't think there's another way for fetch to know that this is a case where preload should be avoided [04:36:55.0012] Noam Rosenthal: sync xhr always bypasses preloads? I didn't know. Seems somewhat unfortunate to give sync xhr a special ability. Might make people want to use it more. [04:38:32.0968] annevk: yea, actually I should dig more into why chrome does that. I don't think other implementations do. Maybe that part should be outside the spec for now and added separately with a separate discussion [04:42:41.0338] Noam Rosenthal: to be clear, "done" running before "end-of-body" is also bad [04:45:12.0916] annevk: not sure why, but I can follow along [04:46:14.0405] Noam Rosenthal: because whoever is passing these callbacks might set up state accordingly, if they get them out of order that could lead to unexpected results [04:46:59.0563] annevk: right, and I thought that saying that `done` always come before `end of body` is equivalent to the opposite [04:47:17.0595] though maybe it's less intuitive, naming-wise [04:47:45.0013] "done" is the last thing, after "end-of-body" you might get trailers (though they are not exposed atm) [04:48:46.0799] In any event, we wouldn't want to change the order as part of a PR to expose network errors better, right? [04:51:09.0068] annevk: currently there are no callers of both "done" and "end of body". maybe they should be either/or? It would make things clearer. IMO having both callbacks doesn't make sense [04:51:26.0721] "end of body" sort-of encapsulates "done" [04:54:07.0169] Noam Rosenthal: we could merge them potentially [04:54:27.0334] Noam Rosenthal: oh wait, end-of-body does its reading thing [04:55:25.0067] yes exactly, we added done for `fetch()` and for random things which don't need the response body, such as `sendBeacon` [04:55:32.0368] I think it's okay to use both, especially once we have trailers, but I could see adding that requirement for now [04:56:21.0551] annevk: OK, so I can keep the order as is, but add an assert at the beginning of fetch. would that work? [04:58:25.0734] Noam Rosenthal: I'm not sure I follow, what kind of assertion? [04:59:01.0157] > <@annevk:mozilla.org> Noam Rosenthal: I'm not sure I follow, what kind of assertion? how would you specify an either/or parameter to fetch? [04:59:49.0826] Noam Rosenthal: I suggest we leave that to a follow-up PR, I'm not entirely convinced yet it's worth doing [05:00:33.0573] annevk: ok, so is it still necessary to change the order right now? it complicates the logic a bit but doable [05:05:02.0730] Noam Rosenthal: yeah, because we should set things like the done flag in the right order [05:24:29.0642] annevk: updated both PRs, thanks for your time. btw with the ยป thingy, maybe it's worthwhile to add a lint rule to disallow the character that looks like it? [05:26:19.0143] Noam Rosenthal: https://github.com/whatwg/whatwg.org/blob/main/resources.whatwg.org/build/deploy.sh has some lint rules you could update [05:37:27.0667] > <@annevk:mozilla.org> Noam Rosenthal: https://github.com/whatwg/whatwg.org/blob/main/resources.whatwg.org/build/deploy.sh has some lint rules you could update https://github.com/whatwg/whatwg.org/pull/387 [07:02:54.0107] https://stackoverflow.com/questions/70261043/fetch-cancels-with-an-abortsignal-does-res-json-too [07:37:36.0186] Added an answer [11:15:24.0162] cac [14:07:05.0172] > <@annevk:mozilla.org> kaleidea: WICG/webcomponents is prolly a better starting point; you'll also run into it if you try to implement it in a browser @annevk I've dug through webcomponents. I've found the following worth to investigate: https://wiki.whatwg.org/wiki/Custom_Elements#Subclassing_existing_elements https://annevankesteren.nl/2015/01/dom-element-constructors https://annevankesteren.nl/2015/01/dom-custom-elements 4 discussions listed at: https://gist.github.com/Kaleidea/49055f021e7da814c233846a95115f96 Are these the ones you've hinted at? 2021-12-08 [16:28:40.0359] foolip: Yet another area which is causing webcompat issues for Firefox because of wrong chrome behavior assumed good. https://bugs.chromium.org/p/chromium/issues/detail?id=1141209 https://bugzilla.mozilla.org/show_bug.cgi?id=1400958 https://bugs.webkit.org/show_bug.cgi?id=233956 [17:48:14.0831] good work here from krosylight about events across browsers https://bugzilla.mozilla.org/show_bug.cgi?id=1653882#c14 [23:44:14.0696] kaleidea: from a quick skim those seem to cover the topic, yes; I forgot I blogged about this stuff [00:20:15.0232] annevk: Thank you. Nice blog, btw. Quite interesting articles, too. There are a few questions in relation if you have the time: > custom elements has the is="" hack (which in retrospect I wish we never shipped) Although not related to the current topic, one day I'd be interested what other solution you prefer now: removal / other? > WICG/webcomponents is prolly a better starting point The 4 discussions listed at https://gist.github.com/Kaleidea/49055f021e7da814c233846a95115f96 mentioned "various tools which key on local name, including JavaScript frameworks, HTML preprocessors and postprocessors, HTML conformance checkers", but did not refer to a research document that lists specific code examples or scenarios that would be affected. Is that research summarized somewhere? [00:23:11.0119] * annevk: Thank you. Nice blog, btw. Quite interesting articles, too. There are a few questions in relation if you have the time: > custom elements has the is="" hack (which in retrospect I wish we never shipped) Although not related to the current topic, one day I'd be interested what other solution you prefer now: removal / other? > WICG/webcomponents is prolly a better starting point The 4 discussions listed at https://gist.github.com/Kaleidea/49055f021e7da814c233846a95115f96 mentioned "various tools which key on local name, including JavaScript frameworks, HTML preprocessors and postprocessors, HTML conformance checkers", but did not refer to a research document that lists specific code examples or scenarios that would be affected. Is that research summarized somewhere? [00:30:30.0658] kaleidea: it might be too late for removal, though Safari notably does not ship it; I think that would be better. I don't think there's research, those were known facts by the participants who work on such code. [00:33:08.0047] Just to be clear: removal without an alternative? [00:38:37.0681] kaleidea: yeah, we could probably support inheritance with a lot of work by moving things to use instance checks, change Selectors around, etc. but it's not clear to me that inheritance is really that great of a programming pattern to go through all that effort for [00:39:35.0017] I think the strides we're making with composition-like semantics (see form-associated custom elements for instance) show a lot more promise [00:47:16.0263] > moving things to use instance checks I'd imagine that would more likely look like `element.builtinTagName === 'button'`. Selectors are a longer story though, for ex. `@button`, but choosing the spec. char would be difficult. Maybe that wouldn't be necessary if style inheritance would be as easy as `my-button { @apply button; }` > composition-like semantics (see form-associated custom elements That's one specific case. It seems to me there's a lot of work to do to make that into a general composition pattern. Just a few thoughts. I'm going to return to the original topic. [00:48:23.0156] * > moving things to use instance checks > I'd imagine that would more likely look like `element.builtinTagName === 'button'`. Selectors are a longer story though, for ex. `@button`, but choosing the spec. char would be difficult. Maybe that wouldn't be necessary if style inheritance would be as easy as `my-button { @apply button; }` > composition-like semantics (see form-associated custom elements > That's one specific case. It seems to me it there's a lot of work to do to make that into a general composition pattern. Just a few thoughts. I'm going to return to the original topic. [00:48:34.0119] * > moving things to use instance checks I'd imagine that would more likely look like `element.builtinTagName === 'button'`. Selectors are a longer story though, for ex. `@button`, but choosing the spec. char would be difficult. Maybe that wouldn't be necessary if style inheritance would be as easy as `my-button { @apply button; }` > composition-like semantics (see form-associated custom elements That's one specific case. It seems to me it there's a lot of work to do to make that into a general composition pattern. Just a few thoughts. I'm going to return to the original topic. [00:48:56.0609] * > moving things to use instance checks I'd imagine that would more likely look like `element.builtinTagName === 'button'`. Selectors are a longer story though, for ex. `@button`, but choosing the spec. char would be difficult. Maybe that wouldn't be necessary if style inheritance would be as easy as `my-button { @apply button; }` > composition-like semantics (see form-associated custom elements That's one specific case. It seems to me it there's a lot of work to do to make that into a general composition pattern. Just a few thoughts. I'm going to return to the original topic. [00:49:15.0950] * > moving things to use instance checks I'd imagine that would more likely look like `element.builtinTagName === 'button'`. Selectors are a longer story though, for ex. `@button`, but choosing the spec. char would be difficult. Maybe that wouldn't be necessary if style inheritance would be as easy as `my-button { @apply button; }` > composition-like semantics (see form-associated custom elements That's one specific case. It seems to me there's a lot of work to do to make that into a general composition pattern. Just a few thoughts. I'm going to return to the original topic. [00:57:32.0126] annevk: Back to your point: > FWIW, the fundamental problem with inheritance for HTML elements is that engine logic is based on local name Yes and no. The entry point of the basic logic is virtual functions such as ParseAttribute() and HandleLocalEvents(), which is based on the vftable, independent of local name. Parsing and cross-cutting logic is dependent on tagName, but some of that uses `IsA<>` type-checking (which is trivial to implement with a more reliable form of type identification). Btw, did you mean to refer to RTTI being disabled in Blink and substituted with tagName checking? [01:11:48.0979] No [01:28:13.0939] Implementing the search element requires only 10 tagName comparisons (3 of which are type checks), 5 more than without form. 3 comparisons are in the parser, pre-instantiation, that must be tagName check. 2 is to differentiate with form, must be tagName. The remaining 5 can be type checks (dynamic_cast). That's the extent of the impact the search element has on the browser. How does that affect your views? [01:32:20.0900] I think you're underestimating the effort required. [01:32:57.0885] Did you know that I've already implemented it? [01:35:38.0389] I got that impression, but I strongly suspect there will be things that are broken. Anyway, it's also not clear to me this is the best design. Overloading functionality and having multiple elements to do the same thing has created problems in the past. [01:38:37.0562] annevk: I've shared it probably 5-10 times. If you find any test vectors that are broken that would help my work. [01:39:18.0567] > <@karlcow:mozilla.org> good work here from krosylight about events across browsers https://bugzilla.mozilla.org/show_bug.cgi?id=1653882#c14 This seems like really good research, and the sort of thing we've been solving in the HTML Standard triage meetings. A spec issue with research + proposal for best behavior that is sensible but also likely web-compatible + list of deltas between current behavior and that proposal would be a great next step IMO. [01:44:46.0137] > not clear to me this is the best design Well, there's no competitor aiming to be a better design. This OTOH matches developer expectations. [13:38:34.0928] * annevk: I've shared it probably 5-10 times. Assumptions aren't useful. If you find any test vectors that are broken that would help my work. Good solutions are built on facts and testing. 2021-12-09 [14:59:49.0470] is `createConicGradient` now supported in Chrome โ€” without needing to enable the `#new-canvas-2d-api` flag? [15:11:09.0503] sideshowbarker: mdn suggests no, but maybe it's out of date: https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/createConicGradient [15:12:17.0210] ntim: yeah, testing in Chrome just now seems to indicate that MDN (BCD) is out of date on this โ€” it seems to work without #new-canvas-2d-api needing to be enabled 2021-12-10 [00:42:59.0718] mek: when do you think you can look at the FS PR? [04:05:07.0317] annevk: hi, reminder that my preload & error fetch PRs are ready for re-reviewing :) [05:28:21.0011] hmm, does anything in the HTML spec define the notation it is using for some algorithms? (basically, does it link to https://tc39.es/ecma262/#sec-algorithm-conventions ) [05:28:39.0133] I need to every now and then check what those ! and ? mean [05:31:27.0641] I would have thought https://html.spec.whatwg.org/multipage/infrastructure.html#dependencies , but apparently not [05:49:48.0812] Noam Rosenthal: sorry, this week has been busy [05:52:13.0322] > <@annevk:mozilla.org> Noam Rosenthal: sorry, this week has been busy Understood, no worries [15:41:36.0162] anyone have a favorite HTML5 formatter (beautifier)? Prettier's output looks a bit unnatural to me and have only really been exposed [`htacg/tidy-html5`](https://github.com/htacg/tidy-html5) and some other ones that come bundled as text editor extensions 2021-12-11 [18:51:10.0891] **Quick question:** If the [ownerDocument](https://dom.spec.whatwg.org/#dom-node-ownerdocument) is to return null if it is a document or document if it is another node type, why does the number 4 of [insert a character](https://html.spec.whatwg.org/multipage/parsing.html#insert-a-character) says the following: > Otherwise, create a new `Text node` whose data is data and **whose node document is the same as that of the element in which the adjusted insertion location finds itself**, and insert the newly created node at the adjusted insertion location. I am referring to the bolded part above, why do I need to use the document of the adjusted location in the `Text node` yet again if each node has an associated node document set upon creation, wouldn't that be superfluous since they likely point to the same document anyway? [18:51:39.0511] * **Quick question:** If the [ownerDocument](https://dom.spec.whatwg.org/#dom-node-ownerdocument) is to return null if it is a document or document if it is another node type, why does the number 4 of [insert a character](https://html.spec.whatwg.org/multipage/parsing.html#insert-a-character) says the following: > Otherwise, create a new `Text node` whose data is data and **whose node document is the same as that of the element in which the adjusted insertion location finds itself**, and insert the newly created node at the adjusted insertion location. I am referring to the bolded part above, why do I need to use the document of the adjusted location in the `Text node` yet again if each node has an associated node document set upon creation, wouldn't that be superfluous since they likely point to the same document anyway? [14:36:46.0069] hello i was going trough the code of the ZenithVR website (looking for hidden key) and found this convo, what are you guys doing here ? [15:45:54.0610] wow, that seems like a stretch lol (some of us aren't guys btw) [15:46:41.0576] that website nearly crashed the my tab; they must be trying to run VR in the browser or something [15:50:16.0652] to answer the question of "what are we doing here" -- not much, it's kinda the weekend and nobody is all that very talkative -- either that or they don't want to let me in on their favorite HTML5 formatter (altho HTML Tidy is a tough act to follow) 2021-12-13 [23:46:04.0164] devsrealmguy: that step is allocating a new Text node, so for that it needs to specify the node document [02:28:21.0570] Thanks, that's what I was doing, I was confused when that passage says it should be the adjusted location document, after back and forth, I realized it was for emphasis. Thanks, appreciate your reply. [03:49:55.0029] Noam Rosenthal: I think you're correct that the callback order will have to end up switching [03:50:14.0770] Noam Rosenthal: doing anything else seems rather involved [03:50:30.0980] It does seem like the current patch still has logic bugs [03:50:46.0651] > <@annevk:mozilla.org> Noam Rosenthal: doing anything else seems rather involved Yea, I think it would be much more succinct if the callbacks are either/or [03:51:03.0966] if there is a future use case that needs both endOfBody and done we can deal with it then [03:51:23.0038] I don't think they have to be exclusive per se, but the consume operation will necessarily complete after EOF has been reached [03:51:37.0872] yea [03:51:57.0490] and request's "done" would mean "EOF" rather than something to do with whether it has been consumed [03:52:20.0951] (that flag is anyway a bit strange, is it in use?) [03:53:45.0918] It's for fetch groups, but those haven't been completely defined [03:59:38.0386] annevk: ok, I re-switched the order. Did it have other logic errors? [04:01:08.0862] I wasn't really ready evaluating this thing yet [04:04:15.0985] Noam Rosenthal: I think this works, but we need better names, maybe in a follow-up PR [04:04:35.0199] better names for "process response done" and "process response end of body"? [04:04:42.0273] Noam Rosenthal: what's now "done" really seems more like EOF and what's now EOF really seems more like "consume body" [04:05:00.0820] got it [04:05:05.0934] I'm not sure how disruptive that will be though at this point, thoughts? [04:05:18.0731] process response done is used by 2-3 places I know well [04:05:22.0821] (I added all of them) [04:05:26.0595] If I do the rename for Fetch and XHR, can you tackle the other places? [04:05:34.0221] absolutely [04:05:57.0897] I think I added processResponseEndOfBody to CSS, and HTML mainly uses processResponse [04:06:46.0272] Noam Rosenthal: what's the status of https://github.com/web-platform-tests/wpt/issues/30968? Presumably some of those tests have to be updated now it's HTTP(S)-only? [04:06:50.0499] Maybe processResponseEndOfStream. Also it's not exactly "process", it's more of a notification [04:07:08.0968] > <@annevk:mozilla.org> Noam Rosenthal: what's the status of https://github.com/web-platform-tests/wpt/issues/30968? Presumably some of those tests have to be updated now it's HTTP(S)-only? Already done. I removed the tests for blob: about: etc [04:07:35.0140] also the tests for abort are gone [04:07:57.0648] it's only tests that can't be distinguished from CORS errors - like timeout, too many redirects, host not found etc. [04:08:46.0225] How about "processResponseFlush"? To correspond with stream naming [04:11:03.0964] Noam Rosenthal: yeah that also seems reasonable [04:12:04.0145] request's "done" flag can be renamed to "flushed" [04:13:11.0278] Yeah maybe. I'll merge the PR and then write the renaming patch. I think I'll just do the algorithms for now. [04:13:47.0301] > <@annevk:mozilla.org> Yeah maybe. I'll merge the PR and then write the renaming patch. I think I'll just do the algorithms for now. thanks! I'll prepare PRs for CSS/sendBeacon etc. later this week [04:17:48.0937] Noam Rosenthal: will you file impl bugs and link them from OP? [04:18:42.0171] > <@annevk:mozilla.org> Noam Rosenthal: will you file impl bugs and link them from OP? Sure, once there's a PR or issue for the algo renaming to link to [04:20:01.0509] Noam Rosenthal: does "Create timing info for HTTP(S) network errors" seem like an accurate commit message to you? [04:20:33.0489] > <@annevk:mozilla.org> Noam Rosenthal: does "Create timing info for HTTP(S) network errors" seem like an accurate commit message to you? Yes. [04:40:13.0214] Noam Rosenthal: https://github.com/whatwg/fetch/pull/1369 [04:41:06.0411] > <@annevk:mozilla.org> Noam Rosenthal: https://github.com/whatwg/fetch/pull/1369 Great! Will create issues later today (have to be off for a few hours) [04:56:35.0693] sideshowbarker: Looks like it was good not to update log4j to 2.x. (So far, it looks like the 1.x RCE that I'm aware of doesn't apply.) https://twitter.com/tbroyer/status/1470024270852014086 [05:25:40.0423] mek: so foolip has approved the FS PR, but I'd like your take as well; do you think you can get to it this week? [12:18:51.0331] > <@hsivonen:mozilla.org> sideshowbarker: Looks like it was good not to update log4j to 2.x. (So far, it looks like the 1.x RCE that I'm aware of doesn't apply.) https://twitter.com/tbroyer/status/1470024270852014086 Indeed yeah. Seems like weโ€™re fine just staying on log4j v1 [13:41:04.0325] Bikeshed complains that it finds _two_ specs that define the `WebSocket` interface. Should other specs (like Streams) keep using the [\[HTML\]](https://html.spec.whatwg.org/multipage/web-sockets.html#the-websocket-interface) one, or should we migrate to [\[WEBSOCKETS\]](https://websockets.spec.whatwg.org/#the-websocket-interface)? EDIT: [Answered](https://github.com/whatwg/streams/pull/1198#issuecomment-992944477), thanks Domenic! ๐Ÿ™‚ [13:44:26.0054] I just invited Eric Meyer here - Eric is trying to help figure out what to specifically put in a PR for HTML re: directionality and shadow Dom - it's currently in the last comment of https://github.com/whatwg/html/issues/3699#issuecomment-988890095 - can someone have a look and direct him toward how to get a PR or edit? / Domenic or annevk maybe? [13:44:51.0052] What's the question? Is it how to send PRs to HTML? [13:45:55.0348] I think it is whether what he written makes sense to send as a PR? [13:48:15.0510] Oh, no, that didn't seem like a spec to me. I think the idea is to modify https://html.spec.whatwg.org/#the-directionality and maybe https://html.spec.whatwg.org/#directionality-of-the-attribute and maybe https://html.spec.whatwg.org/#rendering [13:48:53.0165] that's helpful, ta [13:59:26.0458] * Bikeshed complains that it finds _two_ specs that define the `WebSocket` interface. Should other specs (like Streams) keep using the [\[HTML\]](https://html.spec.whatwg.org/multipage/web-sockets.html#the-websocket-interface) one, or should we migrate to [\[WEBSOCKETS\]](https://websockets.spec.whatwg.org/#the-websocket-interface)? EDIT: [Answered](https://github.com/whatwg/streams/pull/1198#issuecomment-992944477), thanks Domenic! ๐Ÿ™‚ [14:18:10.0565] Iโ€™ll work on doing that, but in the meantime, it would be great to know if anyone has questions/comments/objections on the text that was posted. Or even thumbs-up/thumbs-down from members. [14:18:14.0806] > <@domenicdenicola:matrix.org> Oh, no, that didn't seem like a spec to me. I think the idea is to modify https://html.spec.whatwg.org/#the-directionality and maybe https://html.spec.whatwg.org/#directionality-of-the-attribute and maybe https://html.spec.whatwg.org/#rendering * Iโ€™ll work on doing that, but in the meantime, it would be great to know if anyone has questions/comments/objections on the text that was posted. Or even thumbs-up/thumbs-down from members. [14:18:37.0465] I can take thumbs-up as being satisfied with what the comment says, and thumbs-down I can follow up on to find out what concerns there are. [14:20:04.0586] * I can take thumbs-up as being satisfied with what the comment says, and thumbs-down I can follow up on to find out what concerns there are. [14:20:06.0372] Well, I don't really understand it well enough to comment :). I guess it seems like the main content is the nested 6th bullet, and that will modify https://html.spec.whatwg.org/#the-directionality ? That seems like a lot less spec than what Fantasai proposes in her comment, but maybe it's just a really short statement of it. [14:20:43.0807] My plan is to do editorial review only, and delegate normative spec review to people like Fantasai or the Chrome rendering team who understand this stuff better. [14:22:34.0113] I guess also the 5th bullet indicates that there'll be a big change of most of #the-directionality from using tree relations (e.g. "parent element") to using flat tree relations, as well? [14:24:48.0744] I think itโ€™s basically the same, with that one exception. Shadow DOM directionality and language inheritance should be essentially โ€œflatten the tree, then act as described in https://html.spec.whatwg.org/#the-directionality, except for this one exception with slots and hosts when the slot has no actual contentโ€. [14:25:18.0203] Well, what we need is a spec for determining "the directionality of an element"; I don't see how you'd insert "flatten the tree" into that. [14:25:36.0441] I.e. we're not re-determining the directionality of the entire document tree every frame [14:25:45.0488] We need a mechanism for computing the directionality of a specific element when asked. [15:19:46.0998] was there ever any discussion about combining urlpattern instances? i don't see anything on github. if this isn't dumb i might open an issue 2021-12-14 [16:59:53.0663] > <@devsnek:matrix.org> was there ever any discussion about combining urlpattern instances? i don't see anything on github. if this isn't dumb i might open an issue I think URLPatternList is the keyword, mentioned a couple times in the issues and explainers. I don't see any actual explanation of what it is but it was part of the very original plan. /cc wanderview [17:00:56.0050] ah i see [17:01:35.0019] yeah this would be a nice solution [22:20:43.0585] > <@noamr:matrix.org> Great! Will create issues later today (have to be off for a few hours) Morning, I think all the relevant PRs are submitted [07:29:12.0028] > <@domenicdenicola:matrix.org> Well, what we need is a spec for determining "the directionality of an element"; I don't see how you'd insert "flatten the tree" into that. I think Iโ€™m confused. Is https://html.spec.whatwg.org/#the-directionality not that spec? [08:10:24.0905] Eric Meyer: I think it's more about the how. What Domenic is asking for is an algorithm that is equivalent to what we have today. Given an element, it returns a direction. [08:13:36.0773] > <@emeyer:igalia.com> I think Iโ€™m confused. Is https://html.spec.whatwg.org/#the-directionality not that spec? That is the spec. However my understanding is that that algorithm gives incorrect results, currently, for elements in shadow trees. And so your goal is to modify that algorithm so that it returns correct results for elements in shadow trees. [08:16:27.0520] > <@domenicdenicola:matrix.org> That is the spec. However my understanding is that that algorithm gives incorrect results, currently, for elements in shadow trees. And so your goal is to modify that algorithm so that it returns correct results for elements in shadow trees. Given that spec says โ€œany elementโ€ does that mean itโ€™s known to apply to Shadow DOM trees? Or is that part of the needed clarification? [08:16:57.0311] Yes, it currently applies to any element. It just gives wrong results (from what I understand) for some elements. [08:17:14.0725] Where by "wrong" I guess I mean "not according to latest CSSWG / implementer consensus" [08:18:46.0402] I donโ€™t think itโ€™s all that wrong, actually! Except for certain edge cases with `slot` elements, which definitely does need to be clarified. So I think my move is to add the bit about contentless `slot`s taking directionality from the host, and that should resolve it. (I hope.) [08:42:31.0416] Eric Meyer: if you want to operate in the flat tree presumably the tree walking is incorrect too? [08:44:14.0877] > <@annevk:mozilla.org> Eric Meyer: if you want to operate in the flat tree presumably the tree walking is incorrect too? I donโ€™t understand, sorry. [08:48:49.0018] Eric Meyer: e.g., the parent of a slotted node would be the shadow host, but it might have to look at the slot element it's slotted into instead? [09:00:56.0402] Thatโ€™s a good question and I need to take a few minutes to unspool it. (If you have a specific structure in mind, Iโ€™m happy to work through it!) [11:44:44.0560] Hi [11:49:21.0666] > <@annevk:mozilla.org> Eric Meyer: e.g., the parent of a slotted node would be the shadow host, but it might have to look at the slot element it's slotted into instead? Iโ€™ve been working through this (with a lot of help from bkardell) and should have an answer soon. But I do believe that weโ€™ve managed to avoid the flattened tree. [11:53:38.0133] well, we avoid trying to just saying "use the flat tree" I guess...conceptually I guess it's pretty similar, just how to adjust the algorithm in the spec to arrive there [14:53:49.0956] Interesting, image via might be removable? https://deprecate.it/#plugin-elements [14:55:41.0645] oooooh, let's do it [14:55:47.0259] one more nail in 's coffin 2021-12-15 [01:08:47.0579] Eric Meyer: bkardell: sounds good. It might be that DOM should provide some helper terms here as thus far the flattened tree has been mostly a layout affair, but aspects of it are observable through events (iirc) [01:12:04.0281] Eric Meyer: bkardell: https://dom.spec.whatwg.org/#ref-for-get-the-parent%E2%91%A4 and https://dom.spec.whatwg.org/#ref-for-get-the-parent%E2%91%A6 highlight the important differences in terms of traversal [11:04:36.0172] I was under the impression that the only way to get a document to be decoded as UTF-16 was with a BOM, since `` can't be used to switch into/out of UTF-16 [11:04:55.0263] but I was completely forgetting the `charset` MIME parameter [11:06:00.0730] So, since UTF-16 is ASCII-incompatible, is there a security risk here? Or we can assume that there isn't one, since the server clearly knows it's serving UTF-16? [11:06:21.0154] (but then what about the possibility of proxies doing multiple passes on some input?) [11:06:27.0251] * (but then what about the possibility of proxies doing multiple passes on some input?) [13:23:08.0332] I don't think malicious proxies are really in the threat model? A malicious proxy could completely rewrite the input if it wanted to. [13:25:03.0451] I wasn't talking malicious proxies, but about the possibility of a chain of servers processing each other's outputs, where an intermediate server doesn't know it's handling UTF-16 but the final one does [13:25:17.0843] but that's probably too much of a stretch [13:25:22.0959] and not part of the threat model [13:27:48.0146] I'm not really sure myself, so don't take my sentence above as a definitive answer... 2021-12-16 [22:32:49.0132] Andreu Botella (he/they): I think it's tricky due to the 0x00 bytes surrounding the ASCII bytes [23:40:17.0406] Domenic: https://github.com/tc39/proposal-shadowrealm/pull/336#issuecomment-994446991 onward is relevant to your interests. Seems like we might not be getting rid of serialize and transfer anytime soon. [07:20:03.0975] Wonderful. Should've known nothing would be simple with TC39. [07:22:22.0058] Looking over fetch standard right now, very well written [07:49:35.0624] Thanks! [09:20:34.0354] wattsi supports plurals in xrefs, right? Does that not work for multi-word? [09:20:41.0825] Apparently it's not catching "scalar value strings" [09:21:11.0943] though let me do `git pull` on html-build [09:22:34.0692] ok, apparently they don't work at all, and I'm too used to bikeshed ๐Ÿ˜„ [09:23:46.0490] Wattsi does not support plurals or stemming, yeah :(. Just capitalization changes. [09:44:09.0753] Def one of my favorite features [11:26:08.0201] Especially now that you added gerund support for initial verbs [11:26:26.0731] (i.e., do the thing -> [=doing the thing=] just works.) [13:33:40.0116] it's full stem support, in fact - any transform it would do to the last word, it'll do to the first word too 2021-12-17 [02:44:03.0971] Hello! I would like to bring to the attention of people working on HTML5 team the issue of working with footnotes and also the issue of a 1.5 column layout (with footnotes as sidenotes/marginnotes). I am convinced that it should be possible to write in Tufte Style (https://edwardtufte.github.io/tufte-css/) seamlessly using clean, semantic HTML5 only, without any JS whatsoever. For this purpose, it should be easily possible to have a 1.5 column layout. Furthermore, critically, footnotes as sidenotes should be easy to place in the margin at the appropriate height in the margin even in crowded margin situations (not flowing over other footnotes but elegantly positioned as close to the definition position as possible without any overlaps). Second, there should be an easy way to number footnotes with two different numbering schemes, ie. arabic for sources and alphabetical (from [a] to [zzzzz] for notes). It should be also possible to add a note without any numbering (marginnote) in the margin space. Please, please, please. Seamless support for footnotes in 1.5 column layout is absolutely essential for my use of semantic, clean HTML5. This is because footnotes are absolutely critical (I am not convinced by tooltips as they require an additional click and are not readily visible) and it's a design flaw to place them at the very, very end. Is there any hope that somebody will look into it? [02:57:00.0811] m4themagic: could you explain how this pertains to HTML and not CSS? [03:24:51.0853] Good point. I didn't consider this. Nonetheless, it seems to be a good design goal to make 1.5 column layout implementable in HTML5+CSS as easily, as cleanly and as semanticly as possible, which may bring some considerations for HTML5 as well. The reason for this is that it should not be considered as some custom and unnatural layout but an essential one. Almost as important as the one with footnotes at the end (1-column). In this way, I would be able to ditch Latex in favor of clean HTML5. Currently, I need Latex to make footnotes adjust well and automatically. I would like to treat HTML5+CSS pages in 1.5-column layout as primary way of storing science-related or any other quality articles with footnotes. But I don't want to store them in a highly convoluted way that will make them inaccessible in 10 years' time. I would like to use a method almost as reliable as pdf but plain-text. This could also have some implications for EPUB files. [03:25:04.0770] annevk: ^ [03:26:49.0886] EPUB is just packaged HTML and CSS so I somewhat doubt that. Anyway, I recommend taking this to the CSS WG. And probably search their issue archive first as this is likely something that has come up before. [03:31:25.0811] Thank you, I plan to do so. [03:53:16.0461] As a side note, it seems that there are many semantic elements in HTML for articles: article, section, header, footer AND **aside** which prima facie sounds excellent for 1.5 column layout but I guess there are difficulties with making it work properly and automatically in a 1.5 column layout. From the spec: "The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography." [04:04:31.0099] One idea (perhaps bad), would be to extend HTML with "margin" in addition to header and footer elements. Margin notes are very important, essential. Proof of Fermat's theorem is famous for being first mentioned on a margin. I understand that web is not print but this positioning with readily visible notes or footnotes makes sense also for web. [04:07:07.0628] The distinguishing trait of margin notes is that their vertical positioning is universally related to the position of the text they comment on. [04:08:06.0667] I'm no expert, but the `