Re: [WICG/webcomponents] Proposal: Custom attributes for all elements, enhancements for more complex use cases (Issue #1029)

bahrus left a comment (WICG/webcomponents#1029)

As the author of the world's [most ignored and/or amateurish alternative proposal](https://github.com/WICG/webcomponents/issues/1000), I recognize that I'm quite biased and/or confused.  I'm in a bit of a quandary whether I am officially "opposed" to this proposal, as I can see how this might be useful for a rather finite list of use cases -- reusable classes for parsing and stringifying attribute string values where the requirements for how to parse and/or stringify are quite extraordinary.   But this use case doesn't bear any resemblance to the use cases people are bandying about.

Being that I am so far away from being able to provide an alternative implementation to compare with, my proposal will be likely continue to be ignored. I guess I see the writing on the wall (sigh).   I look forward to the explainer, which will hopefully dispel doubts, but not holding my breath.

I will be quite disappointed if the platform adopts this as the end all to enhancing built-in and third party custom elements, as I understand it, as it appears to lack some fundamental niceties and important aspects that I seem to be in a minority of one as far as caring about.  

Namely:

1.  Performance -- my proposal allows a developer to instantiate, in an official, scoped way, a class not tied to an expensive DOM node or even a property, just a weak reference,  and to do so lazily and with a simple single liner api call, without the need to add a separate line to add the  attribute, which adds to the HTML weight, unnecessarily in some cases.  The class definition can be imported / loaded anytime, and need not be hardcoded into a mixin that is packaged with the element.  Adoption of named attributes and/or api properties is a choice to be made only when needed, not a demand.
2.  Conforming to proven and industry-wide practices.  None of the built in elements, to my knowledge, implement their functionality using built-in custom attributes.   Is the platform going to start doing so?  What advantages has the platform identified as to why they will do so? A large percentage of web sites using multiple frameworks attach objects directly to the DOM without expecting or demanding a corresponding attribute.  Why does the w3c think they are all wrong in what they are doing?  Also, none of the frameworks that do support custom attributes, like Vue, Angular, Svelte, Knockout, etc attach the code associated with the enhancement to the attribute instance, to my knowledge, but rather, to the DOM element itself, at least in some cases.   I think it's fair to say that the industry regards (or should regard, in my opinion) string attributes as declarative conveyors of server-rendered configuration / state in the HTML, and a tool for styling, so changing the meaning in this way would certainly be a significant eyebrow raiser, in my view.  If I were to try to sell it, I'm at a loss to think of what the advantages are, other than "this is the best the browser engineers could come up with".  One of the selling points of custom elements was that it empowers the developer to do what the platform (and existing frameworks like Angular) are/were doing -- implement new elements.  That analogy appears to break down with custom elements :: elements :: custom attributes :: attributes.
4.  Boolean valued attributes typically become true when present, false when not present.  It seems to have an enhancement that takes in a boolean value, it would have to be "true" or "false", which is kind of clunky / makes styling a little uglier, etc.
5.  @sorvell  raised the excellent point about the desirability to group multiple attributes together, and package / roll them up into one coherent "controller" that recognizes and is aware of all of them.  Since @sorvell raised the issue, I implemented it in my custom library, and it has been a godsend for my library.  This is probably the biggest (in my mind) "showstopper" for this proposal, the reason I would drag my feet the hardest as far as deciding to use this favored alternative.
6.  Other features I'd like to see spec'd out that are in my proposal:  The ability to schedule  / hydrate multiple "attributes" in sequence.   The ability to specify types of elements it can support (input / type =  text) and textarea, for example.   Not clashing with custom element or built in attributes.  Supporting emoji attributes.   

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/1029#issuecomment-3599297022
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/1029/3599297022@github.com>