Re: [WICG/webcomponents] Custom Property + 0 or more Custom Attributes => Custom Enhancement (Issue #1000)

I've updated this proposal to address as best I can two points raised during the face-to-face:

Why attachedCallback and not connectedCallback?  Advantages of connectedCallback is it perfectly aligns with the terminology used for custom elements, and clearly the custom enhancement class above closely resembles a custom element. I could go with that.  It doesn't break the essence of this proposal in any way.  This was raised (I don't know by whom, but I *think* it was a member of the WebKit team, but not the person leading the meeting) during a face-to-face, seemingly as a "showstopper" for this proposal (I think), that it made the proposal seem amateurish (paraphrasing).  **Yes, I am definitely an "amateur" in this space, and I was quite reluctant to even make this proposal for that very reason. I did so because I was (and am) frustrated by not seeing such a proposal forthcoming from the WebKit team, and I am very eagerly awaiting said proposal**.  When it does (hopefully) and the name "connectedCallback" appears, which seems likely, I hope they will consider my reasoning, even if I am an amateur.  But one thing I will not say is that it is a showstopper or amateurish for whatever choice is made.

Reasons I think attachedCallback would be clearer:

First, let me emphasize that if the reason for the rather pointed comment was that my using "attachedCallback" was a slight towards the name used for custom elements, nothing could be further from the truth.  If custom elements had chosen "attachedCallback" I might very well have gone for "connectedCallback" in this case.

It just feels different to me.  When a plane lands, it "connects" to the ground.  When we add a wing to the plane, we are "attaching" a wing.  Or maybe it makes just as much sense to say when a plane lands, it attaches to the ground.  And when we add a wing to the plane, we are "connecting" the wing.  Again, different.  Using the same term for both would be confusing, I think, for that reason.  (In this analogy, the "ground" is the DOM fragment, the wing is the "enhancement").

As this proposal currently stands, the signatures are different, which again, lends itself to thinking the names should also be different.

Attaching (connecting?) a cross-cutting concern on top of an existing element feels like attaching Shadow DOM.  If we weren't living in such troubled times, I would have seriously considered calling the class ElementHorcrux rather than ElementEnhancement, just to fully cement my amateur status.

Anyway, as I said, I think that decision should be of little consequence, so please replace it with whatever name you like.  That's my amateur take.

And I will add my voice to many, please provide the non-amateur version ASAP, WebKit!

Also raised during the face-to-face by @rniwa, seconded by @justinfagnani:

So why not use the customElements' registry, why come up with a new registry, customEnhancements?  This point was also raised, quite respectfully, at the face to face, and seems to me like it may have some merit, and I suspect "under the hood" might make a tremendous amount of sense.  But from a developer point of view, it seems strange to use the "customElements" object to attach (connect?) things onto built in elements, so I wonder if the "under the hood" considerations could be camouflaged, in the name of clarity?  I again eagerly await the formal proposal from the WebKit team(?) where the reasoning for this is spelled out.  

The closest thing I could see without causing confusion to amateur developers like me is if the method name for customElements was different from define, that clarified that the scope was much broader than custom (HTML) elements.

Again, not a showstopper in my mind, and I suspect I'm missing something.




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

Message ID: <WICG/webcomponents/issues/1000/1773798861@github.com>