Custom element extended built-in support and special `is` attribute

[toastal]

document.createElement support additional options, namely is for custom elements that are extended. You can see that no additional arguments are sent to document.createElement.

Since custom elements are a goto solution for when limitations of Elm are crossed, allowing more support for them would be worthwhile. I tried in vain both using Html.Attributes.property and Html.Attributes.attribute because it must be set on element creation .

I would suggest similar to _VirtualDom_nodeNS, to have _VirtualDom_nodeIs or _VirtualDom_extendedNode that takes a string is like the namespace variable that applies it to document.createElement(tag, { is: is }). It could then be exposed in Html as a special case for Html.Attributes.is or Html.extendedNode.

This is related to Html issue https://github.com/elm/html/issues/192

[wolfadex]

From reading the docs on the is attribute, createElement(), and extending built-ins I've thought of a couple paths that could work nicely.

The first is _VirtualDom_nodeWithOptions : Tag -> List Option -> ... where Option is a something similar to an Attribute. This is slightly divergent from everything in Html being like writing HTML because when you specify is in HTML you specify it as an attribute. It does however more align with the JavaScript implementation of createElement(tagName, [ options]).

The second idea is to go with the is attribute and update the virtual dom to look for attributes that act as options. This would align more with writing HTML, but make the implementation a little strange in that the VirtualDom is looking a specific attribute on an element.

I do think the first option provides a more clear idea of what's going on. The user is modifying their element in an atypical manner. It's also more obvious to a person who is coming into a large code base for the first time and trying to understand why their element is behaving in a way that isn't typical of an element with that name.

[dotnetCarpenter]

I do not have enough insight to be a proponent of any specific implementation, hence not just adding +1 to the OP. But I do want to +1 fixing extending standard HTMLElement via Web Components.

@jreusch made an example (for fun, not for real usage), https://ellie-app.com/8LXM8GVGxWWa1 But it highlights why extending the DOM with Object.defineProperty (HTMLElement.prototype simply does not work.

Ref: https://discourse.elm-lang.org/t/calling-dom-methods-from-elm/5701/7

@pdamoc made an example of how it might look like, if there is support for is attribute. validity is however not an attribute but a read-only property.. So ignore that part.

validity =
    attribute "validity"

Documentation: https://developer.mozilla.org/en-US/docs/Web/API/HTMLObjectElement/validity Reference: https://discourse.elm-lang.org/t/calling-dom-methods-from-elm/5701/5

[enjoythelive1]

Is anybody working on this or is this in active discussion? I would like to collaborate

[rlefevre]

@enjoythelive1 According to https://discourse.elm-lang.org/t/calling-dom-methods-from-elm/5701/15 and https://caniuse.com/#search=custom%20elements, it's not possible to customize built-in elements with the is syntax in Safari. If confirmed, this would lower significantly the interest of adding support for it.

[wolfadex]

I'm having difficulty finding the source task that was for implementing is= in webkit but has been closed as will not implement. In lieu of that I have found a discussion about the lack of support https://github.com/w3c/webcomponents/issues/509. There other various GitHub discussions about Safari's lack of support as well.

[boccato]

On the discussion about the Safari issue it is recomended to use a polyfill (https://github.com/ungap/custom-elements) which not only makes it work on Safari but also on older versions of other browsers.

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