Best Practice: using 'type' as a property name?

[zeroedin]

Thoughts on using 'type' as a property name?

@property({reflect:true}) type: 'fixed-width' | 'full-width' = 'full-width'

The type attribute is used on elements such as input[type='radio'] should we avoid using it in custom elements?

[markcaron]

@zeroedin I'm in favor of this practice since it would be familiar as well as semantic. And for custom elements, which are, in many respects, supposed to follow HTML it would seem appropriate IMO.

We had gone this route (using common, semantic attributes) on PFE as well. For example:

• <pfe-datetime> uses type
• <pfe-number> uses type
• <pfe-avatar> uses src
• <pfe-modal> uses width

For reference, other HTML elements with the type attribute are <a>, <button>, <link>, <menu>, <script>, etc.

[bennypowers]

Spent a few minutes canvassing the neighbours:

Library	Uses type	Uses variant	Notes
Shoelace	✅	✅	e.g. type for input, variant for alert
Lion	❌	❌	Prefers separate element definitions
FAST	✅	❌

I'm finding it a bit hard to develop an intuition for this. Maybe one could say "type for behaviours, variant for appearance" 🤷 ?

[marionnegp]

I think @heyMP's example makes sense. Would type be what's listed under component name on ux.redhat.com? For example, an alert would be <rh-alert type="inline-alternate" variant="success">.

[bennypowers]

@heyMP

If we went with that then the new rh-dialog would go from variant=video to type=video. #288

I proactively made that change anyway, since pfe-modal uses variant for width. The alternative to <rh-dialog type="video"> would be <rh-video-dialog>. If that's more desirable (Lion, for example, follows this route, as does vaadin IIRC) we can make that happen.

[bennypowers]

@marionnegp in your example <rh-alert type="inline-alternate" variant="success">, there would be one page for "Alert", with a section for type and another section for variant. Each legal option for each attribute would have a sentence or two describing it.

[zeroedin]

This question came up again in PR review #259 (comment) in the code that actually spawned this original question thread. That said, the original question was more focused on the reuse of type and less on the specifics of what the property was doing.

@property({ reflect: true }) type: 'fixed-width' | 'full-width' = 'full-width';

For the specific use case of rh-secondary-nav, I have a dropdown menu sub-component that has a [type] attribute that modifies the layout of the menu between fixed or full width.

@bennypowers on the review comment said:

bennypowers May 5 2022
in this case what about layout or size?

I think layout is likely an appropriate solution but want to hear the opinions of @RedHat-UX/designers on what they feel is the most appropriate for this very specific use case.

The discussion above seems yet unresolved as far as what specific attribute name should be used for layout changes.

[bennypowers]

I'm good with layout. if @RedHat-UX/designers want to loop back prior to 1.0 and change names across our library, let's to that then