Customized built-in elements

[annevk]

Request for position on an emerging web specification

Information about the spec

• Spec Title: Customized built-in elements
• Spec URL: https://html.spec.whatwg.org/multipage/custom-elements.html#customized-built-in-element

Bugs tracking this feature

• WebKit Bugzilla: https://bugs.webkit.org/show_bug.cgi?id=182671

Anything else we need to know

WebKit supports autonomous custom elements, but hasn't implemented this aspect of custom elements.

Colleagues and I wanted to share our thinking around that in this issue and also open it up for feedback from the community.

[annevk]

Custom elements give web developers the power to create their own HTML elements. The idea behind customized built-in elements is to give web developers a similar power, but starting from an existing HTML element. Essentially subclassing it. The main use cases driving customized built-in elements are:

• Enhancing existing form controls.
• Inheriting accessibility logic from the existing elements.
• Progressive enhancement due to fallback to the existing elements.
• Supporting the special HTML parser behavior of existing elements, such as td or template.

Customized built-in elements attempts to achieve this through an is attribute, e.g., <input is=my-input>. (The reason it’s not <my-input extends=input> is because it was deemed too hard to change implementations to key internal logic on the element type rather than the local name and namespace pair.)

Colleagues and I are interested in addressing these use cases, but thus far we haven’t been convinced customized built-in elements is the way to do it:

• Thanks to form-associated custom elements, the main use case for customized built-in elements has a better solution that gives developers a lot more flexibility.
• Thanks to ElementInternals and ARIAMixin, autonomous custom elements have pretty good accessibility support that we plan to expand even further.
• Customized built-in elements cannot have access to shadow trees (with a couple minor exceptions) or ElementInternals by design, making them a kind of second-class custom element.
• Customized built-in elements also cannot realistically have good accessibility support built-in as they are logically different from the element they extend. Therefore customizations with respect to the accessibility tree are still needed, but would only be possible through the public ARIA API as ElementInternals is not available.
• For much the same reason we think the progressive enhancement use case falls short of meeting its goal. Using child elements is the established way in HTML to provide fallback contents. E.g., this is how canvas and picture approach it.
• The syntax used prioritizes implementers over web developers which is wrong per the Priority of Constituencies.

The main compelling use case to us at this point is the HTML parser use case and we’d love to jointly dive into that deeper to see if we can come up with a better solution that comes with fewer drawbacks. whatwg/html#8114 is probably a good place for that particular discussion.

[WebReflection]

I think there are tons of arguments for desiring cross-browser builtin extends out of the box within the linked bug, so I won't repeat myself or other developers findings and otherwise-impossible improvements builtin extends bring compared to Shadow DOM but this point in particular makes me very curious:

Customized built-in elements also cannot realistically have good accessibility support built-in

in my experience it has the best accessibility support because developers don't need to do anything to add standard builtin accessibility to elements that already support that, so I'd like to hear, or better understand, in which case builtin extends makes accessibility worse.

One missing point though is the ability to extend elements in the HEAD of a site, being that for runtime import maps, meta, even title, or literally any other element that doesn't need Shadow DOM but it's crucial to describe a document and its expected behavior.

[romainmenke]

One aspect not yet listed is that customized built-in elements do not load/initialize gracefully.

The only way we see them working well is when JavaScript is a blocking resource and when you are a 100% sure it will always load successfully.

For async/defered JavaScript the elements will always exist partly as un-upgraded elements. The elements will first behave as native elements before being customized. This will lead to unexpected document states and hard to solve bugs.

This is the main reason we never used this API for client work.
We could have picked a polyfill for Safari but we never saw this feature as viable.

---

This is different from regular custom elements.
Those are not expected to have any behaviour when the JavaScript is slow or fails to load.

[WebReflection]

@romainmenke as one that used builtin extend forever (and wrote all polyfills to date), I am curious around these takes too:

The only way we see them working well is when JavaScript is a blocking resource and when you are a 100% sure it will always load successfully.

The whole point of builtin extends is that these don't need JS by design and the element will do what that element does by standard specifications. This current behavior is pretty off from your conclusion that builtin extends must be successfully loaded and/or as blocking resource. I completely miss your use case that fails here, being that an image, a button, an input, a table, or any other element that would work out of the box as-is, which is the only reason to use builtin extends.

For async/defered JavaScript the elements will always exist partly as un-upgraded elements.

This is true for "dumb elements" too (Custom Elements without builtin extend and without JS driving them) except these literally do nothing and represent nothing until the class that takes them over kicks in. How are these superior for tables, inputs, head elements, even divs, quotes, pre elements, and so on?

The elements will first behave as native elements before being customized.

This is exactly the feature builtin extends bring to the table, so it looks like you are confused around what builtin extends are or what's their application? You can have a body tag, even an html one, that's builtin extend: how anything you say breaks there?

This will lead to race conditions and hard to solve bugs.

This is in contradiction with the statement you made after:

This is the main reason we never used this API.

If you never used this API, how can you write opinions around such API? It'd be great to have more contributors from people that actually understood and used builtin extends in production, first Polymer users or A-Frame users or somebody from Google as they also used these in various products and these days are falling back to ugly home-made solutions like it is for the YouTube case.

[romainmenke]

If you never used this API, how can you write opinions around such API?

Edited my comment.
Obviously this isn't an unmotivated comment.
Haven't used it in production vs. haven't used it at all.

---

My point was that either you want a standard element or you want a custom one.
You never deliberately want a standard element for the first 100ms of a page view and a custom one for the remainder. There is no way this can ever be viewed as a desirable trait.

The first 100ms can easily become the first 5s for users on slower devices with a slow connection.

I have no intention of derailing this thread with a lengthy discussion about this detail. If you do want to discuss this further then I am happy to do so elsewhere.

[WebReflection]

@romainmenke to simplify my answer: please do check any website that use builtin extends with JS disabled (to mimic no JS load at all) now check with the same constraint any site based on custom elements without builtins and see the difference.

Also: race conditions don't exist in JS by definition because JS is single tread since day 0 but if there's anything that cause problems with builtin extends it will cause problems with custom elements too, except, like I've said, these represent nothing until the definition kicks in ... surely can't represent body, html, style, pre, code, button, link, tables, link, script, title, and the list goes on and on (pretty much any void element in the specs + every other).

[WebReflection]

@romainmenke

You never deliberately want a standard element for the first 100ms of a page view and a custom one for the remainder.

I definitively do and these are the benefits:

• I can style the element for everyone in one CSS, instead of needing two styles, one for light-dom and one for SD
• I can be sure that element will always work as meant to do by standard definition
• I don't need JS at all to know my site works, even via curl

The first 100ms can easily become the first 5s for users on slower devices with a slow connection.

Exactly why I prefer builtin extends over non-builtin extends if my purpose is to show a video tag, an img, a table, a body, etc etc

[WebReflection]

I have no intention of derailing this thread with a lengthy discussion about this detail

Me neither, but this discussion is claiming non-real-world facts so it's good to counter-argument these as long as anyone is willing to answer my questions ... to date, I keep asking questions but I rarely receive answers.

Reasons builtin extends, when builtin extends make sense, are superior to me:

• no FOUC. One style and you're good. Speficity is great too, so either the CSS didn't load neither, or the element will look exactly as it did before once the definition kicks in. Whenever the definition lands on the page, nothing happens for users eyes or surfing.
• builtin extends are the literal de-facto definition of graceful enhancement. Anyone running a querySelectorAll on the page, or a MutationObserver, to instruments/enrich regular elements, would be better off with builtin extends (bootstrap to name one case).
• of course a developer can destroy a builtin extend behavior via a badly written custom element, but that's true since jQuery exists (and bootstrap to name one case) and it's also true with custom elements and Shadow DOM.
• accessibility is the best out of the box so I really want to hear the a11y story because that really made me wonder what is it that I am missing. If there was anything inferior, instead of superior, in terms of default a11y I would've never pushed so hard for polyfills and builtin extends, so please anyone elaborate and thank you in advance.
• hydration ... the most difficult and bloated topic in the industry, can happen out of the box with builtin extends. I have libraries published that do that and compete with tools based alternatives (Svelte and friends) plus hydration is extremely hard on JSX world (de-facto standard) and everyone is coming up with one or another bloated solution that builtin extends would gracefully solve without issues.

I also don't want to derail this issue though, so I might just step-aside until I have at least some answer around the questions I've made, thank you!

[romainmenke]

race conditions don't exist in JS by definition because JS is single tread since day 0

yup yup, edited my comment so as not to trigger unwanted associations.
I did not mean a multi-threading race condition where multiple threads are accessing the same memory.

A race condition or race hazard is the condition of an electronics, software, or other system where the system's substantive behavior is dependent on the sequence or timing of other uncontrollable events. It becomes a bug when one or more of the possible behaviors is undesirable.

So by a broader definition race conditions most definitely exist within websites.

---

I have no intention to debate this further here.
Especially not at this intensity.

I know that a lot of people want this feature and that people do not like it that Safari does not support it.

I came here to share one more aspect which makes this feature not ideal. Those concerns are not the result of misunderstanding the feature. It should be ok for me to express these things.

Maybe we are unique in finding that this is an issue and in that case I am sure that my concern won't have any impact on the outcome.

[WebReflection]

@romainmenke

It should be ok for me to express these things

absolutely, but it should be OK for me to provide real-world solutions that don't suffer anything you mentioned so far.

I have tons of libraries based on builtin extends that are just working and none of these suffer any point you mentioned, but I don't want to flood this issue with libraries, although I am curious to read your code around your claims. My twitter DMs are open, if interested in sharing more.

P.S. race conditions as you mentioned there, are solved by customElements.whenDefined which method exists for that exactly purpose: avoid kicking in stuff before it's needed.

[MikeVaz]

I remember reading the thread and I couldn't find any reasonable argument in favor of Not implementing it in WebKit. In reality it caused a lot of pain for teams who try to use the platform features over a library and add some negative points to the WebKit and Apple brands.

In my opinion it is a simple inheritance. Blocking inheritance only in some cases seems odd. I can extend HTMLElement but why I wouldn't be able extending HTMLSpanElement. And the use case like to get a display inline could be just one of examples re-using some of the properties of the parent class.

Now, we can argue what is the best way to define it declaratively <span is="my-span"></span> or something else. But we already have a standard defining that so why not just follow it.

I read your bullet points like 5 times and can't really agree with any of those. They seems questionable. Which makes me think there is a bigger hidden reason why team not implementing it. I just don't get why.... 🤷‍♂️

[MikeVaz]

Could you elaborate on The syntax used prioritizes implementers over web developers which is wrong per the Priority of Constituencies. ?

[WebReflection]

If I can pile up a question:

Customized built-in elements cannot have access to shadow trees

I still need to see out there a built in extend that needs or use Shadow DOM at all but this point reminds me Shadow DOM can be already added to any element on the page so it’s hard to understand what’s the point in favor of not having builtin extends there.

Thanks in advance for any clarification

[bennypowers]

@WebReflection certain built in extends can have shadow roots, but not controls

https://dom.spec.whatwg.org/#dom-element-attachshadow

I'm curious to know why that is, as well.

[WebReflection]

@bennypowers thank you! I still think builtin extends don’t need or ask for shadow DOM at all, actually the opposite, at least in my experience, because their purpose is to enhance, not to change their nature, so I accept the limitation without being a blocker but it seems more like an attachShadow issue, not a builtin one.

edit on the other hand, this SD limitation seems a very valid reason to have builtin extends, as there’s no other way in the platform if not by requiring userland boilerplate to extend those elements when SD is not needed.

[MikeVaz]

One of the unusual use cases in favor of customizing built-ins is progressive enhancement. It took some time for Safari and other browsers to start support <dialog> element. But we could have progressively enhanced it. <dialog is="my-progressive-dialog"> to add a conditional code extending HTMLDialogElement if available or using a custom one. Limitation around customizing built-ins blocked us from doing that. So unblocking such scenarios would be helpful.

[steveblue]

I haven't experienced any of these shortcomings mentioned above when implementing customized built-ins. I disagree with the assertion the primary use-case for customized built-ins are form controls and their inclusion in WebKit would thus be superfluous given form-associated elements already cover this use case. There are plenty of instances where customized built-ins work brilliantly, including extending table and list elements or HTMLButtonElement, where the user would want to retain existing behaviors (that are not exclusive to accessibility), but extend their functionality.

While I agree the shortcomings of customized built-ins should be addressed by at the very least a warning that Shadow DOM isn't possible for most instances, I don't think this aspect to them should block their inclusion in a browser. Every custom element doesn't have to utilize Shadow DOM.

Chrome, Firefox, and Edge all support customized built-ins. Even if a successor were chosen, it would be wildly inappropriate for those browsers to deprecate customized built-ins, so if WebKit doesn't support the specification web engineers are left with fragmentation and have to load a polyfill, which undermines the use value of custom elements (despite the best efforts of @WebReflection, not knocking your work, it's quite good). For those who have adopted customized built-ins, WebKit is asking a lot for those users to adopt another spec and abandon customized built-ins, when a majority of browsers already implemented the specification. This violates one aspect of custom elements I find the most alluring: longevity. A custom element that works today should work in browsers for years to come. is should just work.

[bahrus]

Most (all?) the use cases for customized built-ins would, I think, be better served by standardized element decorators / behaviors / custom attributes / directives - what virtually every framework other than react have found it beneficial to support. This would allow multiple, loosely coupled enhancements by different vendors to be applied to the same element, in a way that could avoid conflicts with future enhancements to the built-in elements. I find it puzzling that webkit hasn't proposed this as their preferred alternative. I also think such decorators could serve a dual purpose during template instantiation.

But the ability for limited implementation single inheritance / built in method overriding also seems useful, especially for the template element, or the form element (e.g. defining custom checkValidity() overrides). I'm not even sure customized built-ins support that, but if they do, that does seem useful to me. Webkit's stated objections to heavy use of this antipattern (?) are valid, it seems to me, so in my ideal world, support for both would be provided, with a heavy nod towards the former (element behaviors) as far as the preferred approach.

[thepassle]

I'd love to see customized built-ins happen, but I did always understood Safari's reservations about adding them, because it could potentially become harder to add new features to native HTMLElements in a non-breaking way. Was there ever a solution found to address these concerns?

[WebReflection]

@thepassle imagine these days “standard” solutions propose template literal tags based libraries where @click or ?attr are injected as template element content and gosh knows what any other template literal tag based library can propose as alternative, as opposite of separating view and behavior/listeners in core DOM, like builtin extends or CE can do already …

[thepassle]

Sorry, I fail to see how that answers my question

[WebReflection]

@thepassle my bad … all I wanted to say is that if there’s any concern around future extensibility of any element, template literal tags based solutions that exist today are a great example of how that concern is not solved at all by not providing builtin extends, as any library in that field use their own ergonomics to provide this or that feature, including ref attribute, and so on.

[Westbrook]

I’m certainly one of the many that have not used customised built-ins in any form of scale due to the lack of WebKit support, so there’s not much that I can bring in favor of shipping the spec’d behavior here, other than that it is spec’d. In that way, shipping it or actively working to get it out of the spec seems the correct course for WebKit here. Neither of which has been done.

For my money, however, it would be great to see actual in production (or at least a fully thought out form) usage of this specification to date. There are many argument as to what you might do with this spec, but even as a rather seasoned web component author and consumer I’m not sure I’ve ever needed to do something with this part of the spec. At least not one that didn’t involve disproving someone’s implication that “web components” weren’t “shipped” wifey enough to leverage.

If anyone on this thread could point me to a lib or repo with which I could expand on my understanding in this area, I’d be much obliged!

[WebReflection]

@Westbrook it’s a bit controversial as for 9 years WebKit has been loud about not shipping builtins extend, so that developers either never cared much (React about CE in general) or had to migrate to avoid needing a polyfill forever (Polymer, AFrame, Google AMP). So basically you’re asking who’s currently betting on a doomed standard that requires mandatory polyfill in case WebKit browsers are part of the equation. I have provided tons of libraries that either workaround this situation or solve it with importMaps but the latter is too late to the game to show concrete examples, yet I’ve already talked about YouTube going out with their home made builtin extend for a style tag, and if YouTube is not a good example already about what a site might need to do with builtin extends, I don’t know what else would convince you developers are finding, or will find, other ways to extend obtrusively builtin elements, as they’ve done to date already.

I agree this limbo is unacceptable and quite a parody of how meaningless standards could be … so kill it (hopefully providing alternatives before) or embrace it because it’s out there and nobody is innovating around this standard due its current state.

edit I did explore and innovated around builtin extend potential with many libraries but I don’t want to spam this thread with self-referenced links

[tanepiper]

As we've seen in he last few days, Chrome has their own problems around standards and that we have a monoculture of Blink-based browser's looking to implement a DRM layer is sad.

But sadly it's the landscape we have to work to, as we also start to build and use custom elements - Safari no longer is a viable option for continued support in the long run.

Really the only option left for developers is either some customers get a degraded or broken experience using Safari, or no customers get a good experience as we have to cut off our own abilities to provide enhanced experiences.

When the scale is millions, even billions of users, and Product Owners in the real world want to improve the customer experience - guess which option is going to win? Safari might want to try hold out but you cannot bend reality to your will.

I'd also prefer the second option considering the adoption rate of browsers.

[chrisdholt]

I think what disappoints me most is that users which opt into other browsers which support this on iOS still get Safari. Were that not the case, I’d have a lot less care about the impact of this decision.

[jaredcwhite]

I do agree with @EisenbergEffect that the customized built-ins spec can and it would seem should be jettisoned in favor of an alternative approach that works with WebKit's priorities here. I don't have a problem with that personally, I'm quite used to wrapping native elements and don't see much advantage in, say, button is= over my-button > shadow root > button (and rather opposite in fact, shadow DOM styling and encapsulation is very important to me).

[RobM-ADP]

@jaredcwhite - the advantage is when you need to use things like aria-controls which need to reference ids of elements. You can't put aria-controls="my-popover" inside your shadow root and refer to an element outside of it. As a result you either have to not use shadow dom or you need to make your my-button "be a button" by implementing all its behavior manually. It's worse for something like an anchor tag where you can't really implement all the behavior of a link such as the right click menu that is unique to links.

I agree that the current spec could be improved upon, but whatever better solution we come up needs to keep these important use cases in mind... especially where it impacts a11y.

[tayfunyugruk]

I want to share my own experience on this topic which i think will be helpful to the positive side of the is debate.

At my company we created a web components + Tailwind based UI library that can work on any JS framework and Shopify themes. Thanks to the web components and ability to extend builtin elements we were not worried about SEO or a11y issues of fully custom components until we test it on Safari.

Safari was not rendering builtin extended elements (is="..." is not working) so we did a research and realized that Safari is not supporting this feature at all!

Not sure if our case is an edge case but i think having ability to extend builtin elements is unlocking many improvements to the developer experience.

[rniwa]

The position has been established.

[dmitriid]

@steveblue

Why bother having the discussion if WebKit's position can't be changed based on other's valid arguments and several people's calls to support the specification?

Why do you dismiss WebKit's valid arguments as invalid just because somebody else has some arguments that you find valid?

[steveblue]

The discussion was over when the spec made it into the HTML Living Standard. It's sad to see @WebKit can't set a good example by implementing a specification they disagree with, especially when that specification is implemented in every other mainstream browser engine. @dmitriid I am not dismissive of @WebKit's position. On the contrary, I believe @WebKit had valid arguments during the discussion, but the discussion was over long ago. Now any decision to oppose only comes at the expense of fragmenting the platform for web developers. It doesn't demonstrate @WebKit representatives have the ability to properly support the web development community or end users.

[colepeters]

I have to agree with @steveblue here. There are clearly valid and compelling use cases for customized built ins, as demonstrated by the fact that this spec has been implemented in every other major client (along with many reported use cases in this very issue). The fact that this issue was opened to ask for feedback on the position and then closed (quite dismissively, to be honest) with none of the feedback having informed a response leaves a really bad taste in my mouth. Living standards exist for a reason — so that technologies are standardized across the board, not implemented based on individual vendor preferences (as was the case before such rigorous standards, for those who remember).

There may well be reasons to question the current implementation, but I'm not seeing any evidence of this being actually managed by WebKit (for example, by filing a report with the WHATWG steering committee, as is meant to be the case when there's a dispute on standards, if I've interpreted the working mode documents correctly). On top of this, the very proposals WebKit suggests should serve as alternatives (Custom Attributes, Element Behaviours, etc) seem to have received no priority from WebKit themselves. With no required interest from other vendors (because they've already shipped customized built ins), where is the push to fill in the gaps supposed to come from?

I feel like a lot of WebKit's reasoning here relies on the presumption that customized built ins are primarily useful for form element upgrades, which is frankly a huge oversight. There are so many reasons a user would want to extend non form elements to take advantage of built in accessibility (which can be nigh on impossible to effectively reimplement from scratch — consider even the basics of elements which inherently participate in keyboard navigation flow, such as links, buttons, etc) or to associate their custom elements with the desired semantics of built ins (i.e. table elements, list elements, etc).

At the end of the day, this is frankly table stakes for web components as a whole, and the gap left by Safari hurts both authors and end users. Regardless of whatever objections WebKit may have to the current implementation, the fact is that customized built ins are now a part of the living standard and have been supported by other engines for close to five years now. This either needs to be implemented or alternatives need to be given priority (and discussed with other vendors to achieve parity) ASAP. Or, at the very least, a conflict needs to be raised with the steering committee to resolve this officially, rather than requesting authors for feedback and then doing nothing.

Honestly, it's really sad to see this kind of regression in the spirit of vendors aligning on web standards. Whether WebKit has stated that they will not implement this is frankly beside the point when they've also agreed to uphold web standards as defined by the larger community.

I'm not looking to come off as hostile to anyone in particular here (though I'm sure some of my remarks may incite unintentional vitriol), but folks at WebKit need to know this is damaging both to authors and the web as a whole, and it sets an extremely poor precedent for the entire nature of web standards.

[jaredcwhite]

this is frankly table stakes for web components

In several years of shipping web components in a variety of ways and tech stacks and working on design systems which are built out of web components, I've almost never felt the need to ship any extended built-ins, and I think this case has been overstated.

Applying various native browser behaviors to custom elements seems like it has had and will continue to have the best success in utilizing compositional patterns rather than pure inheritance.

[colepeters]

In several years of shipping web components in a variety of ways and tech stacks and working on design systems which are built out of web components, I've almost never felt the need to ship any extended built-ins, and I think this case has been overstated.

That's fair — we've all only encountered the use cases that have come up in our own work. I've worked on design systems across a number of stacks over the past 15 years as well, and I've often shipped customized versions of built in elements (obviously without web components given this issue). That said, I don't presume every other author will have had a need for this themselves. There are lots of web standards (like the shadow DOM) that I have little to no use for, but that doesn't mean that's the same for other authors — nor that those specs shouldn't be implemented.

That said, why would two of the three major browser engines have shipped this spec if there wasn't significant interest and quantities of use cases unlocked by doing so?

Applying various native browser behaviors to custom elements seems like it has had and will continue to have the best success in utilizing compositional patterns rather than pure inheritance.

There are lots of fundamental composition patterns (again: tables, lists, summary/details, picture, video…) that cannot be composed with autonomous custom elements. Autonomous custom elements also cannot themselves participate in the document navigational flow or contribute to the document outline. The only way to achieve these things with custom elements within the current living standard is to extend from built in elements.

[dmitriid]

@colepeters @steveblue

You keep arguing that "Safari should dimplement this because others have implemented this". Not on the merits of the specs, not on the merits of the arguments, but "others have done it, do it, your arguments are invalid".

This is especially ironic given that this is a discussion about web components which are a great example of why you shouldn't implement something just because others implemented it, and should spend however long it takes to find a proper solution.

The reason is simple: once something's in the browser, you can't remove it. As an example, it took Google almost 5 years to remove Custom Components V0 from Chrome because they rushed, and re-wrote Youtube with Polymer targeting this version.

As a larger picture, just take a look at Web Components Community Group: 2022 Spec/API status. 20 more specs just to fix deficiences in the original design many of which stem from a single source: Shadow DOM. Some of them like Declarative Custom DOM were originally proposed by Safari but got overulled by Chrome because "move fast, fix later". And here we are now, 13 years later still busy patching problems and holes in the original design. All while breaking or hindering a lot of other stuff because new useful specs have to make sure they work with Shadow DOM. [1]

And now you're arguing that Safari absolutely must implement subclassing on all built-in elements that have never been designed to be extandable, including things like <table> or <picture>? And dismiss any concerns about their current or future behaviour?

There's literally a 4-year-old unsolved issue in web components now that custom element buttons cannot be used to submit forms. Literally the most basic behaviour of a browser is broken by just having bad specs implemented across browsers. And now you're arguing that even more fundamentally complex and behaviour-breaking spec must absolutely be implemented just because others did it?

I have my own gripes with Safari. But in this case they seem to be the only ones who actually take care to not break the web with rash poorly thought-out implemetations and specs.

[1] Edit: note, these specs still don't solve the issues like interop with SVG which is left to a tentative unpecified "web components v2"

[inopinatus]

The overwrought grandstanding on principle just adds to the outside perception of a pissing contest between vendors. After forty years in tech, I can safely say this unedifying spectacle remains very familiar. Once dug in, don't expect the participants to leave their trenches without an order from above. As with any and every tech vendor, Apple will implement custom built-in elements in a heartbeat when they experience a compelling commercial reason to do so. This github issue is simply another act in the kick-the-can-down-the-road theatre confirming there isn't one.

The galling part, for those of us who already spend too much time working around browser limitations, isn't the refusal to implement this part of the standard. The galling part is that after the better part of a decade of standards football, WebKit doesn't implement an equally capable alternative.

[steveblue]

"It just works" isn't compelling enough?

[dmitriid]

I'll respond with just a single quote from my response.

There's literally a 4-year-old unsolved issue in web components now that custom element buttons cannot be used to submit forms. Literally the most basic behaviour of a browser is broken by just having bad specs implemented across browsers.

There's more in my response about "it just works", do read it

[waterplea]

The discussion was over when the spec made it into the HTML Living Standard. It's sad to see @WebKit can't set a good example by implementing a specification they disagree with, especially when that specification is implemented in every other mainstream browser engine. @dmitriid I am not dismissive of @WebKit's position. On the contrary, I believe @WebKit had valid arguments during the discussion, but the discussion was over long ago. Now any decision to oppose only comes at the expense of fragmenting the platform for web developers. It doesn't demonstrate @WebKit representatives have the ability to properly support the web development community or end users.

The real reason this is a big deal is iOS webkit monopoly. They can afford to not set that example and will continue to do so until the real platform competition exists. Nobody can afford to ditch all iOS customers so we are all at their mercy and in 10 years I've seen so many human hours wasted by that predicament. I'm really glad we finally see some movement there with Digital Markets Act and I'm excited to see how this might change the landscape.

[dmitriid]

They can afford to not set that example

Set what example?

I'm really glad we finally see some movement there with Digital Markets Act and I'm excited to see how this might change the landscape.

I mean, we all know how the landscape will change. The "non-iOS-monopoly" browser that holds ~65% browser worldwide share from a company that has monopoly on the internet will keep implementing "non-wasted-hours" APIs that both Safari and Firefox consider harmful while web devs cheer on.

Unlike that browser, Safari actually has valid substantiated claims as to why they don't implement this particular part of the standard [1] And the whole extremely complicated and tangled nature of DOM, Web Components, browser assumptions etc. only validates their stance. (e.g no amount of "customizable built-ins" would solve form participation or the simple act of being a submit button).

[1] Note that the whole Web Component space is one interminable train wreck coupled with a dumpster fire. Also pushed by that same "real platform competition" against all objections or alternatives. How's this or this for wasted hours? But that's for a different discussion in a different venue.

[thepassle]

How's this or this for wasted hours?

Absolutely love this reply after seeing you spend hours replying with salty comments in this thread

[jaredcwhite]

This thread has gotten pretty out there, but…

@dmitriid I was with you until [1] which makes no sense. The Web Components Community Group has been doing great work, and there was a lot of interest at TPAC from implementors (with multiple sessions led by @rniwa!) regarding the 2023 report. Just putting that out there for posterity.

[dmitriid]

@thepassle

Absolutely love this reply after seeing you spend hours replying with salty comments in this thread

I wrote exactly 4 comments on a thread of over 100, and I definitely didn't spend hours writing them. Ad hominem attacks don't work nearly as effectively as you think they do.

The Web Components Community Group has been doing great work, and there was a lot of interest at TPAC from implementors

@jaredcwhite Then you didn't understand what I wrote, and why I wrote that. After 12 years in development Web COmponents still need ~20 new mostly JS-only standards (on top of ~a dosen existing ones) to fix issues that they introduced in the first place. The 2023 report ended up selecting just four of them (including the critical one, cross-root ARIA) which still leaves all the other issues unanswered (an some issues unsolved). But, as I said, this is a discussion for a different venue.

Going back to this current thread, I would like anyone wanting customized built-in elements to describe how exactly do they think they would work. Considering especially that some people want core elements like tables to be customizable built-ins. I mean, sit down and describe how a table, an input, a <..insert your favorite here...> would work given browser assumptions, ARIA, text selecitons, form participation etc., and how they will work in the future when browsers inevitably change or extend the behaviour of these built-in components.

Note: I, for one, can see a possible solution only in

• providing a comprehensive set of built-in elements instead of the anemic wasteland that we have now. https://open-ui.org/ is a good start, and some of those elements are arriving in browsers
• these elements must provide extensive extension points (even the ability to control the apperance of everything with CSS will cover 99% of devs' needs)
• these elements, and the browser in general, must provide an extensive set of APIs (both low-level and high-level) like any desktop/mobile GUI framework does that lets you override behaviour/appearance of an element either wholesale or part by part. Look for example how Qt has been doing it for ~30 years: https://doc.qt.io/qt-6/qcombobox-members.html

Alas, this will never happen

[thepassle]

You and I both know how much time you spent talking about web components, whether its in this thread or elsewhere :)

[dmitriid]

@thepassle

We components are 12 years this year. I've spent maybe two hours talking about them in total. Even if you collect all my comments, blog posts, github discussions etc. Okay. Perhaps 3 hours.

Now compare that to the number of hours wasted trying to make submit buttons work inside them.

Anyway, this is severely off-topic.