WHATWG on 2024-03-22

08:34	<Ms2ger>	Me too
08:36	<sideshowbarker>	cool — y’all could start a club (since we now know there’s at least two of you)
09:53	<judge_sour_dough_bread>	Hi all, for questions about CSS syntax and the CSS Syntax Module (Level 3) spec., can these be asked here or is there a better room for such discussions? I need to clarify a paragraph written in the spec. I am unable to find a "CSSWG" room, at any rate (searching using Element Matrix client).
10:04	<peterv>	annevk: it's a bit unclear to me when attr-associated elements is computed for reflected `FrozenArray<T>`-typed attributes, couldn't really find a reference to that. Is that something that needs to be explicitly called somewhere?
10:15	<judge_sour_dough_bread>	Going to take a chance and go ahead asking. Reading https://www.w3.org/TR/css-syntax-3/#consume-an-ident-like-token I am unable to "succinctly" understand the following condition, quoting: If the next one or two input code points are U+0022 QUOTATION MARK ("), U+0027 APOSTROPHE ('), or whitespace followed by U+0022 QUOTATION MARK (") or U+0027 APOSTROPHE (') This reads too ambiguous to me -- do the authors mean the [compound] condition where the next code point (the first in this context) is one of `"`, `'` or whitespace, and the subsequent code point (one immediately following the first) being one of `"` or `'`? Or do they mean something else?
11:46	<annevk>	peterv: that's a good question. That also applies to the "attr-associated element" concept. I think we should make that more explicit yeah. Just saying something is computed doesn't really tell you much.
11:48	<annevk>	peterv: my inclination would be to make it an algorithm instead that we just invoke wherever we currently access the property.
11:51	<annevk>	judge_sour_dough_bread: they mean the next code point is " or ' or the next code point is whitespace and the one after is " or '.
11:52	<annevk>	judge_sour_dough_bread: seems reasonable to file an issue and ask for clarification though.
12:48	<judge_sour_dough_bread>	judge_sour_dough_bread: seems reasonable to file an issue and ask for clarification though. Oh, I was meaning to, thanks.
13:05	<peterv>	annevk: ok, out of curiosity, was `ObservableArray` considered for these instead of `FrozenArray`? I understand it would be quite a different model since you'd have to keep track of changes to the list as opposed to computing it from the getter.
13:27	<Jake Archibald>	annevk: With `ElementInternals` you can create a custom element with form field capabilities. But is there a way to create a custom element that has form capabilities? As in, inner inputs can become associated with it. I could do it with `<form is="my-custom-thing">`, but given WebKit's opposition to that, is there an alternative?
13:40	<Jake Archibald>	I guess a solution (aside from `<form is>`) would be to allow a form within a shadow root to become the associated form for elements within the shadow and light DOM within. Has there been any discussion around that?
13:52	<Jake Archibald>	Filed an issue https://github.com/whatwg/html/issues/10220
14:05	<annevk>	peterv: I'm not sure. I don't recall being super closely involved when these were added. Just wanted to maintain some invariants around shadow trees. I can look at git blame I suppose.
14:08	<annevk>	Jake Archibald: this is the first request I've heard for <form>, interesting. I guess you'd need to do something like FACE, but for form. This has come up for label and such too, but it was hard to agree on how much semantics such a thing would have by default and how much you'd have to implement yourself.
14:14	<annevk>	peterv: So I was involved but I guess I didn't care for that detail. And Domenic noted it, but it was already implemented twice and so didn't push it. And so here we are. Hmm. https://github.com/whatwg/html/pull/7934
14:18	<annevk>	I guess some takeaways: All details matter. You can ignore them, but they'll just come back to haunt you later (unless you don't stick around, which is some people don't understand why you're blocking them over some detail that's not important to them). We should be very hesitant to use FrozenArray for anything from now on. And I think I was already hesitant back then, but implementations had already kinda happened so...
14:27	<annevk>	Oh, we export attr-associated element, that makes it harder to fix. Hmm.
14:28	<annevk>	Although, per https://dontcallmedom.github.io/webdex/a.html#attr-associated%20element%40%40Element%40dfn nothing references it? ... Success.
14:35	<Jake Archibald>	annevk: what's FACE?
14:35	<Jake Archibald>	ohh form-associated-custom-element
14:35	<Jake Archibald>	I should have thought about it an extra second
14:36	<Jake Archibald>	Yeah, I put two options in the issue. One is to allow form associations to cross shadow boundaries in some opt-in case, or do the FACE thing.
14:41	<Sam Sneddon [:gsnedders]>	Hi all, for questions about CSS syntax and the CSS Syntax Module (Level 3) spec., can these be asked here or is there a better room for such discussions? I need to clarify a paragraph written in the spec. I am unable to find a "CSSWG" room, at any rate (searching using Element Matrix client). https://matrix.to/#/#w3c_css:matrix.org
14:46	<annevk>	Jake Archibald: as with many things (I'm reminded of a recent Twitter exchange), the main thing all of this needs is the TC39-equivalent of a champion
14:47	<annevk>	I guess that should be "WHATWG-equivalent of a TC39 champion".
14:47	<Jake Archibald>	Fair
17:58	<TabAtkins>	Going to take a chance and go ahead asking. Reading https://www.w3.org/TR/css-syntax-3/#consume-an-ident-like-token I am unable to "succinctly" understand the following condition, quoting: If the next one or two input code points are U+0022 QUOTATION MARK ("), U+0027 APOSTROPHE ('), or whitespace followed by U+0022 QUOTATION MARK (") or U+0027 APOSTROPHE (') This reads too ambiguous to me -- do the authors mean the [compound] condition where the next code point (the first in this context) is one of `"`, `'` or whitespace, and the subsequent code point (one immediately following the first) being one of `"` or `'`? Or do they mean something else? That's technically four conditions - next is quote mark, next is apostrophe, next two is whitespace followed by quote, or next two is whitespace followed by apostrophe
18:21	<sideshowbarker>	TabAtkins: It seems that’s the answer for what the intent of the spec is. But the other part of what they were pointing out is that as currently written, the statement was ambiguous to them because they thought it could be parsed in two different ways. Maybe it could be made unambiguous them (and to others who might potentially be confused by it) if it were a bulleted list: If the next one or two input code points are one of the following: U+0022 QUOTATION MARK (") U+0027 APOSTROPHE (') whitespace followed by U+0022 QUOTATION MARK (") whitespace U+0027 APOSTROPHE (')
21:31	<judge_sour_dough_bread>	I remember dealing with a similar issue of ambiguous writing in some specification a while back, and the most useful answer and discussion I had gotten out of it was the mention of something called the Oxford comma. Basically, presence or absence of the comma at just the right place, combined with lack of standard "parsing" of sentences featuring the comma(s), by humans, on both sides of the Atlantic (and beyond, no doubt), was the source of unending confusion demonstrated by myself and some of the authors of the spec. Wish I could dig up the link now (on GH), alas. Anyway, a bullet-list will make it far more understandable, IMO, at the cost of more verbosity and "negative white space" (i.e. length of the document), although I admit I myself wouldn't be bothered by said increased verbosity.
21:34	<ljharb>	huh, i've never seen an example of the presence of an oxford comma introducing ambiguity. do you have an example?
21:35	<judge_sour_dough_bread>	Found it: https://github.com/whatwg/dom/issues/870 May not be ambiguity proper, but certainly was mentioned in the issue
21:52	<TabAtkins>	The presence of an oxford comma shouldn't be ambiguous, but the absence of it certainly can be.
21:53	<TabAtkins>	yeah i could rephrase into a list
21:53	<TabAtkins>	won't happen today, head down in some code
21:53	<TabAtkins>	but PR accepted
21:57	<judge_sour_dough_bread>	TabAtkins: It seems that’s the answer for what the intent of the spec is. But the other part of what they were pointing out is that as currently written, the statement was ambiguous to them because they thought it could be parsed in two different ways. Maybe it could be made unambiguous them (and to others who might potentially be confused by it) if it were a bulleted list: If the next one or two input code points are one of the following: U+0022 QUOTATION MARK (") U+0027 APOSTROPHE (') whitespace followed by U+0022 QUOTATION MARK (") whitespace U+0027 APOSTROPHE (') Reading the title of the list you suggested, I am not convinced it's all that unambiguous either. Which of the categories expressed in the bullets of the list, for example, may pertain to which of the two code points? Is every bullet point applicable to any one of the two code points? That's just one ambiguity I, for one, would be struggling with.
21:58	<TabAtkins>	the phrasing used in the opening of the sentence is a term of art
21:58	<judge_sour_dough_bread>	Yes, I had admitted the same thing then, and I agree again :)
21:59	<TabAtkins>	"next code point" can't be "whitespace followed by quotation mark", given that it's one and those are two
21:59	<TabAtkins>	and vice versa for "next two" and "quotation mark"
22:00	<judge_sour_dough_bread>	"next code point" can't be "whitespace followed by quotation mark", given that it's one and those are two Are you referring to your suggestion, or the original wording (in the spec.)?
22:01	<TabAtkins>	both ^_^
22:03	<judge_sour_dough_bread>	I guess that's one reason I were lost in the words there -- I think it's not unsound to implement a check like whether a specific code point matches "whitespace followed by quotation mark". Maybe I am damaged by look-ahead in regular expressions... For example, `code_point.matches(regex('\s(?=\?))` is a valid expression in at least JavaScript, expressing exactly the aforementioned condition.
22:05	<ljharb>	yeah i don't think a single instance of confusion indicates objective ambiguity :-) the presence of the comma always makes for a clearer result ime
22:07	<TabAtkins>	Yes, you're overthinking this. ^_^
22:07	<judge_sour_dough_bread>	Yes, you're overthinking this. ^_^ It's late, I'll sleep on this and get back to the parable tomorrow, see if it makes all the sense it hasn't so far :)
22:16	<judge_sour_dough_bread>	Ok, before I retire for the day, does the parable express the equivalent of `if (first is '\u0022' or first is '\u0027') or (is_whitespace(first) and (second is '\u0022' or second is '\u0027')) then create <function-token> ...`, am I getting it now? (`first` is the first code point of the two and `second` is the one directly following it)
23:31	<TabAtkins>	yes