@henon @ScarletKuro thoughts on deleting these redundant properties for v7 and keeping a philosophy of only adding properties for attributes when it has concrete values?

If the title attribute makes sense on MudButton then it would be best to have a Title parameter. This would be consistent with @onclick and OnClick. The advantage is that it is available for Intellisense and in the API Documentation and our users don't have to be html gurus to know that this functionality is available. I myself didn't even know about the title attribute of the button tag.

<summary>
The Title parameter adds a tooltip with title text to the button.
Hovering the mouse over the button will display the tooltip.
</summary>

If Title doesn't make sense for all descendents of MudBaseButton we'll have to pull it down again into those where it makes sense.

Of course this is always also a performance question. Every parameter adds a bit of overhead. So I guess the question is what is more important, performance or usability. Hard to say. We may be prematurely optimizing. There are usually only a handfull of buttons on every page and I'd say this is the most likely use-case.

On the other hand - and I am arguing against what I wrote above - we could just link to the W3C button page in the docs and tell users that all attributes added to MudButton are forwarded to the internal <button/> tag. Maybe that would be the best solution.

Usually only a handfull of buttons...

... a bit of overhead...

That could mean not that much overhead at the end. So usability (and consistency) may win against perfomance in this case ?

If the title attribute makes sense on MudButton then it would be best to have a Title parameter. This would be consistent with @onclick and OnClick. The advantage is that it is available for Intellisense and in the API Documentation and our users don't have to be html gurus to know that this functionality is available. I myself didn't even know about the title attribute of the button tag.

@henon The issue is that

1. The title attribute makes sense on a lot of components, not just button
2. There are other attributes that make sense on the button as well (Random examples: role, type, value, aria-label, aria-labelledby, aria-busy, accesskey, translate, etc)

On the other hand - and I am arguing against what I wrote above - we could just link to the W3C button page in the docs and tell users that all attributes added to MudButton are forwarded to the internal tag. Maybe that would be the best solution.

I'd agree with that in general because there are so many possible attributes for every component that it would be a never-ending venture to add them all. I don't know if it's our job to teach users about common attributes.

What would the link in the docs look like? We could add it directly to the class XML docs now that #8903 will be added

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.63%. Comparing base (28bc599) to head (da90520).
Report is 261 commits behind head on dev.

@@            Coverage Diff             @@
##              dev    #9098      +/-   ##
==========================================
+ Coverage   89.82%   90.63%   +0.80%     
==========================================
  Files         412      399      -13     
  Lines       11878    12494     +616     
  Branches     2364     2431      +67     
==========================================
+ Hits        10670    11324     +654     
+ Misses        681      626      -55     
- Partials      527      544      +17     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Added some docs to remind people they have more options for attributes; What do you think? @henon @jperson2000

@henon @ScarletKuro Does my implementation of ToggledUserAttributes make sense when the regular UserAttributes is capturing but ToggledUserAttributes is not? I'm not really sure the right way of handling this and whether this property makes sense in the first place. It could alternatively be applied on top of UserAttributes instead of replacing it.

Added some docs to remind people they have more options for attributes; What do you think? @henon @jperson2000

I was more thinking of the button page in our docs. The XML summary of MudButton is not the main info source for our users.

I was more thinking of the button page in our docs. The XML summary of MudButton is not the main info source for our users.

#8903 shows the summaries on the docs page, is that enough? @henon

OK, I guess that will be enough

Thanks Daniel!