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:
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 |
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> |
I only get 2 |
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) |