Hacker News Reader

Comment by karhuton | Hacker News Reader

My understanding is Apple / Webkit is blocking custom element extension on native HTML elements, which would cut down this 500 line monster to:

class SaganButton extends HTMLButtonElement { … }

Anyone know the reasoning they’re blocking this?

View on HN

But why bother when you can just use <button>?

The is="" customized-built-in path (extends HTMLButtonElement) is exactly what would collapse that 500-line reimplementation. Safari refusing it is why you still fall back to a full autonomous element + ElementInternals.

The only browser Apple is blocking it on is Safari: other browsers implement it just fine, and the standard passed over Apple's objections. The rationale was architectural, arguing that extending built-in components would lead either to brittle components that would break when new properties were added or causing the specification of builtin components to freeze forever to avoid such breakage. I'm not sure I buy the arguments 100%, but for sure it's not evil/incompetent board executives twirling their mustaches as they deliberately break the web: https://github.com/WICG/webcomponents/issues/509#issuecommen...

Standard practice in every decent frontend framework has been to create a component, that wraps the <button> without rendering its own dom node. This avoids the typical downsides of inheritance.

Can we not just do `:host { display: contents }` and use the same approach?

This is sort of correct on webkits side. inheritance chains especially when you don't control who is inheriting from you are going to be very brittle. The standard would probably have been better if it had been specified as a form of composition instead. However not supporting something like this is largely worse than just doing the inheritance. I'm not sure this is a hill I would die on despite largely agreeing with the webkit folks here philosophically.

That's my take on it too. The DOM itself is full of issues from its naive inheritance-happy OO design, and could use a refresh into something with better separation between data and presentation, but it's what we have right now in the real world. There's always going to be footguns, we can't put safeties on all of them. I have to wonder if it's something in the design of WebKit that makes inheritance particularly difficult to implement.

As for potential property collisions, I think the common wisdom is to just ensure the property name contains a dash, since the html5 spec goes out of its way to avoid using them. Doesn't solve brittle inheritance hierarchies in general, but it does at least stay out of the way of built-in behavior.

Reply on news.ycombinator.com