WHATWG on 2021-12-08

00:28	<karlcow>	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
01:48	<karlcow>	good work here from krosylight about events across browsers https://bugzilla.mozilla.org/show_bug.cgi?id=1653882#c14
07:44	<annevk>	kaleidea: from a quick skim those seem to cover the topic, yes; I forgot I blogged about this stuff
08:20	<kaleidea>	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?
08:30	<annevk>	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.
08:33	<kaleidea>	Just to be clear: removal without an alternative?
08:38	<annevk>	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
08:39	<annevk>	I think the strides we're making with composition-like semantics (see form-associated custom elements for instance) show a lot more promise
08:47	<kaleidea>	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.
08:57	<kaleidea>	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?
09:11	<annevk>	No
09:28	<kaleidea>	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?
09:32	<annevk>	I think you're underestimating the effort required.
09:32	<kaleidea>	Did you know that I've already implemented it?
09:35	<annevk>	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.
09:38	<kaleidea>	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.
09:39	<Domenic>	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.
09:44	<kaleidea>	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.