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

Hi @sorvell and @LeaVerou 

So we are all on board with supporting multiple attributes, which is great, excellent idea.

In my excitement, I didn't think to check in with you as far as your thoughts with observedAttributes vs has?  I think @trusktr reached the same conclusion from different vantage points, but wanted to get a show of hands I guess.  I'm concerned we may have a split.

Syntactically, is there a reason to prefer:

```html
<input has="moods" onhappy... onsad... onbored...>
```
over

something like:

```
<input ismoody onhappy... onsad... onbored...>
```

or my preference (am I the only one)?

```
<input is-moody on-happy... on-sad... on-bored...>
```

?  

Or is there something else I failed to see in addition to wanting to support multiple attributes?

Feel free to enjoy your weekend, no rush, I just felt a bit bad for jumping to conclusions I shouldn't have.  

I've expressed my concerns before, perhaps too harshly, but I would like to understand how to sell something if I am to support it.

Of far less importance to me is whether the restriction I assumed would still hold, holds still -- no dashes.   I think it's great if we don't need them.  It seems @sorvell and @trusktr   don't believe it matters.  The way I look at it, yes, it does mean every attribute needs some sort of prefix.  That's the worst aspect.  For two words it adds only a slight amount of inconvenience, frankly I find it more readable, easier to type (on the keyboard) than camel case, but most importantly, it increases risk if we stop using them.  It seems most globals and element specific attributes these days are getting long multiple syllable at least, so dashes can't hurt.  If the industry had long ago abandoned such concerns (I know we have for custom elements, which I have mixed feelings about, but I came to peace with it long ago)  but the industry generally has not for higher level elements, where the argument grows stronger, in my mind (maybe not so much now, but I believe it will with time).   Why rock the boat on that question?  If this is somehow magically resolved by scoped registry, that's all I need to know, and that would be a great surprise.

I will note that others have honestly reported encountering this issue with custom elements, quite recently, so it's a real issue in my mind.

@LeaVerou, I'm totally with you as far as wanting to link up attributes with properties, parsing, etc.  I'm okay with requiring that be fixed as part of this proposal.  I think your idea to filter on Element types is a great one, and I've added it to my proposal with attributions. I just wonder why it is so important that behaviors have to extend Attribute (singular), when you've said enhancements (is there something toxic about that word I'm missing?) don't require attributes, and now supports multiple attributes.  Can you see why I find that hard to wrap my brain around?  I honestly don't think I'll be alone in that.

We're all in this together, let's make sure we get the best ideas out there, and I hope at least some of mine can get counted in.

BTW, I'm softening my stance on enh- if anyone cares.



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

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