01:58
<jarhar>
annevk Domenic i am thinking about multi-select for selectlist (i dont plan on formally proposing this for a very long time), and im wondering if it should have a multiple attribute or a have a distinct tag name. i kind of like having a separate tag name more because then we dont have to handle changes between the single and multiple states, but what do yall think? were "select multiple" and "input type" bad ideas?
02:02
<jarhar>
this has been briefly discussed in openui but with no recent updates: https://github.com/openui/open-ui/issues/447
03:03
<sideshowbarker>
jarhar: were "select multiple" and "input type" bad ideas? Yes, IMHO. At least from the perspective of developer ergonomics. Especially in the case of ”input type”, smuggling 20 different logical elements with different presentations/UI/behavior into one element has created very significant costs that would have been unnecessary otherwise. It's made it more difficult to document, and more difficult to do conformance checking for, more difficult to explain to developers when they run into problems (for example, developers coming to Stack Overflow with questions, and other people trying to help answer them).
03:06
<sideshowbarker>

jarhar:

were "select multiple" and "input type" bad ideas?

Yes, IMHO. At least from the perspective of developer ergonomics. Especially in the case of ”input type”, smuggling 20 different logical elements with different presentations/UI/behavior into one element has created very significant costs that would have been unnecessary otherwise. It's made it more difficult to document, and more difficult to do conformance checking for, more difficult to explain to developers when they run into problems (for example, developers coming to Stack Overflow with questions, and other people trying to help answer them).

05:00
<annevk>
Heh, we're still evaluating <selectlist>. 😅
05:23
<annevk>

I think what I'd look at is how much branching you would need to do and how much shared code there ends up being between the two features. And how difficult it would be to add new features if they were separate elements.

And while it's probably correct that we'd do <input> differently today, the way it was designed has a number of benefits we still benefit from today. It has made it much easier to introduce new input controls, such as type=email. Or soon <input type=checkbox switch>.

08:15
<Domenic>
I would prefer separate elements.
08:44
<annevk>
I had forgotten why making progress on <input type=email> was difficult, but now it's very clear again unfortunately
11:07
<annevk>
Luca Casonato: very nice to see my URL Interop issue was a dupe. At least there's two people that care. 😅
11:14
<Ms2ger>
Sure it wasn't a dupe for an issue you also filed?
11:43
<annevk>
Ms2ger: 🐢🐢
14:32
<keithamus>
Is it right that a bubbling+composed event with a relatedTarget stops bubbling when it hits the shadowroot? Shouldn't it retarget the relatedTarget to the host?
14:33
<keithamus>
y = $0.attachShadow({mode:'open'})
y.append(document.createElement('button'))
x = y.querySelector('button')
x.addEventListener('focusin', console.log)
y.addEventListener('focusin', console.log)
$0.addEventListener('focusin', console.log)
x.dispatchEvent(new FocusEvent('focusin', { relatedTarget: x, bubbles: true, composed: true }))

I only get 2 console.logs when I expected 3

14:45
<keithamus>
If I s/FocusEvent/Event I get 3.
14:55
<annevk>
zcorpan: did you want to give feedback on https://github.com/whatwg/html/pull/9689? I think Jonathan Kew agrees with it so probably have enough in terms of implementer interest, but always nice to get more review
14:56
<annevk>
keithamus: if that's what DOM's dispatch algorithm says, yes (it's been a long time since I looked at this, but I think it's written down)
15:04
<annevk>
Noam Rosenthal: activateAfter makes me think it's no different from activationTimeout
15:05
<annevk>
Noam Rosenthal: as in, setTimeout runs after x seconds
15:07
<annevk>
Noam Rosenthal: before you talked about a deadline, which made me think that if you passed x, running at x-1 would be okay, but x+1 would not be; doesn't that mean "before"? Whereas for "after" x+1 would be fine.
15:34
<Noam Rosenthal>
annevk: both are fine, but for different reasons. The timeout duration is like a preference. The UA would activate before the timeout in case of termination or some such, and after the activation timeout for throttling/batching
15:35
<Noam Rosenthal>
The word "timeout" is maybe confusing because it's the opposite of the abort signal's timeout
15:35
<Noam Rosenthal>
Yea activateAfter means the same thing but it's clear it's a timeout until activation rather than "A timeout after which activation expires" or something like that
15:41
<annevk>
I see, thanks. Domenic you haven't weighed in yet, maybe tell us what you think after the weekend?
18:01
<TabAtkins>
Same; multi-select is related to single-select, but wants a fairly distinct UI. (Even the existing godawful UI is quite distinct between the two states.)
18:01
<TabAtkins>
So yeah, multiple elements.
21:35
<sideshowbarker>
jarhar: FYI https://github.com/WebKit/WebKit/pull/18785
21:43
<sideshowbarker>
jarhar: I wonder if we could consider updating the spec to require that in the “ancestor details revealing algorithm”, before setting the open attribute, we suppress mutation events — in the same way as is done in the “ensure details exclusivity by closing the given element if needed” algorithm https://html.spec.whatwg.org/multipage/interactive-elements.html#ensure-details-exclusivity-by-closing-the-given-element-if-needed
21:44
<jarhar>
oh wow, i didn't know that david actually specced the don't fire mutation events flag
21:44
<jarhar>
sounds great to me! disable mutation events everywhere!
22:05
<sideshowbarker>
In WebKit, there’s actually an assert at https://github.com/WebKit/WebKit/blob/main/Source/WebCore/dom/Node.cpp#L2461 which will get hit unless we introduce some flag for skipping it (which means, skipping the dispatch of the DOMSubtreeModified mutation event)