Stop reflecting default values to attributes

[sorvell]

Given HTML:

<sl-button></sl-button>

The resulting DOM looks like:

<sl-button variant="default" size="medium" ...></sl-button>

This is not how other platform elements like input work, causes a series of problems, and requires non-trivial code to accommodate.

It also leads to confusing and unexpected behavior:

button.removeAttribute('variant');
console.assert(!button.hasAttribute('variant'), 'huh?')'

Unfortunately, this is how Lit's built-in attribute reflection works (reflect: true). Shoelace augments this behavior to make attribute removal reset the default value.

I believe the main reason for this is (1) ensure there's a valid property value if the attribute is removed, (2) provide styling via the attribute.

Case 1 should be handled via a property setter that coerces an invalid value to a correct one (e.g. null would become the default value).

Case 2 should be handled via css custom :state(). This is now widely supported (last 2 major browser versions). While it's true that there's no declarative version of state, the attribute can be used as a fallback if this is important:

:where([variant="primary"], :state(variant-primary)) { ...}

:where(:not([variant], [variant="default"], :state(variant-default) {...}

While this is admittedly a bit cumbersome, the need is rare.

Here is a proof of concept that these changes should be feasible.

[claviska]

Feasible? Yes. Something we're prioritizing for 50+ components right now? No.

To be honest, this burden should probably be lifted at the library level. This is how reflected attributes work in Lit, so we're adding more complexity to work around how Lit intends reflected properties to work.

IMO, this suggestion would be better to discuss in the Lit repo.

[claviska]

Oh, sorry! You're referring to the durable attributes logic specifically. That's a work around specifically to solve DOM morphing issues. We can't really remove it without breaking that for users.

I'd entertain a PR to allow users to opt into this behavior somehow. A static property would probably work, but would be cumbersome to set for all elements. I'm not sure of an easier approach that would be available early enough, but open to suggestions.

[sorvell]

It seems like this DOM morphing concern stems from the fact that properties have default values that need to reflect to attributes.

Is that really important? It's a drift from how platform elements work and if you do it naively (in the element constructor, which Lit doesn't do) it generates an exception.

Instead these would just be styled as the default state of the element. For example,

1. variant= 'neutral', size = 'medium', appearance='accent' would have their defaults removed.
2. if you want to style those you just target the default state of the element, e.g. target wa-button {...}

The downside I see is that you lose the ability to generically target this default state across element types, but I'm not sure how common a need that is v. setting custom properties or ::parts which can easily be done across elements types.

[claviska]

Yes, it's largely due to styling DX which isn't a great excuse on its own, but end users find it convenient to reliably target those defaults. I'm definitely open to exploring this more, especially if we can target default values with :where() which would remove specificity concerns of using :hot(:not([variant="default"])), etc.

[LeaVerou]

Just as an update @sorvell, we are looking into this (for Web Awesome), and I think there is a lot of value to it. Besides helping debugging by not cluttering devtools with extra attributes, it would also simplify some upcoming improvements, and would allow certain traits (e.g. variant) to be inheritable. That said, it is technically challenging to implement, so I’m not sure when (or even definitively if) we'll be able to ship this. Hope this helps!

[sorvell]

Nice. I'm happy to help review, advise, and/or land a Lit feature that helps facilitate the behavior you want.

It would be helpful to know the design you're going for, e.g. "mostly like input.type"... there are a lot of weird edge cases to consider. For example, input.type allows the attribute and property to deviate and lets the attribute become, "null" and "undefined."

[LeaVerou]

I believe Lit does not support enum types, so it can't behave too much like input.type and other enumerated attributes, but it's possible I'm simply not aware of the edge cases you have in mind.

I think, ideally the design we would want is:

• Until the prop is modified (either via DOM methods, or JS accessors) leave it alone (if it's there let it be even if equal to the default value, if it's not there don't sprout it)
• If the prop is set via JS, do update the attribute to match it (let's not repeat the input.value mistake, ever).
• If the prop is set to null or undefined, remove the attribute
• If the attribute is not present, the getter should return the default value, and not null/undefined (otherwise authors using the component need to be aware of its default values to interpret its props)

That said, unless the Lit feature ships very soon, the design we'll likely go with will be somewhat different, mainly to make our userland implementation more feasible. Namely, if the prop is set to its default value, we'd remove it, regardless of how it was set (explicitly or implicitly).