rfc: @attr mode: "boolean" incorrect semantics

[jcludwig]

💬 RFC

As I understand the boolean mode of the @attr decorator is meant to replicate the semantics of the boolean html attributes, like disabled.

MDN says:
Note: The strings "true" and "false" are invalid values. To set the attribute to false, the attribute should be omitted altogether. Though modern browsers treat any string value as true, you should not rely on that behavior.

My request for comments is about what the behavior of FAST should be for these attributes. Right now FAST will treat an attribute like disabled="false" as having the value false. This does not match the behavior for native elements. This is often disguised (e.g. in Fluent UI WC) because this will match a CSS selector with [disabled]. This can lead to inconsistent behavior across components or even within a component. Perhaps these should be considered bugs within the implementor, but if the aim is to support semantics that are close to "native" I think any component library built with FAST would want semantics that match how most browsers will treat this situation, which is to interpret disabled="false" as true.

💻 Repro or Code Sample

@attr(mode: "boolean")
public disabled?: boolean;

You can see this behavior with the Fluent UI WC.

• Storybook: https://storybooks.fluentui.dev/web-components/?path=/docs/components-button-button--docs
• Code: https://github.com/microsoft/fluentui/blob/6411342ccfa1a14f414d13af9881c61788bafd7e/packages/web-components/src/button/button.styles.ts

🤔 Expected Behavior

When the element has the attribute disabled="false" the disabled attribute on the class instance should be set to true.

😯 Current Behavior

The string "false" is interpreted as falsey, and the value of disabled is set to false.

💁 Possible Solution

Another possible solution would be to set the value to undefined, which more accurately matches the spec. However, this is still problematic for component library authors who need to specifically handle this value and avoid using selectors like [disabled] in their CSS.

🔦 Context

We implement a component library, similar to Fluent UI. Almost all components have a disabled attribute. CSS usually behaves as we want, but we have to take extra precautions in code to avoid treating disabled="false" differently than CSS. Essentially, we cannot use the built-in mode: "boolean" mode.

🌍 Your Environment

Reproduced in all versions of FAST 2.0 as far as I can tell.

[chrisdholt]

Thanks for this @jcludwig. Could you help me with a specific repro here? There are two different considerations here:

1. HTML land => Attributes are truthy
2. Binding land => Attributes are passed as true, false, or undefined and resolve to attribute presence.

I put this starter together pulling in the Fluent package and HTML buttons side by side. I also created a binding example component, where disabled passes through the parent to illustrate the host behavior in HTML and the binding behavior in the template: https://stackblitz.com/edit/typescript-6kfx55ae?file=index.html

We're happy to dig in here, I just want to make sure I understand the specific implementation that you're running into this with. The examples in stackblitz show disabled="false" as truthy for both buttons and the example component in HTML. With that said, I may not have covered your specific scenario. If that's the case, please feel free to fork the stackblitz and reduce the repro with an example so we can better support and understand what you're seeing!

[jcludwig]

Sure, I can repro some issues in Fluent UI WC, here is a simple example: https://stackblitz.com/edit/typescript-ands1b2f?file=index.html. The first tab has disabled="false" while the second tab has just disabled. You can see that the first tab looks disabled, but actually it is not, you can navigate to it with the keyboard (also aria-disabled is not set). This is (as far as I can tell) because some of the code/css is treating disabled as truthy and other parts are treating it as falsey. The actual property on the component instance is set to false (e.g. select it in the dev tools and check $0.disabled), so any code that uses this property, or the observable changed handler, will treat disabled as false.

I think your comprehensive example (thanks) shows essentially the same behavior in the second example (attribute binding to "false"), the (x) => x.disabled binding is evaluating to false. Wouldn't you expect the buttons to be disabled when the background is pink? How would we expect people to write this code to get that behavior?

[chrisdholt]

Sure, I can repro some issues in Fluent UI WC, here is a simple example: https://stackblitz.com/edit/typescript-ands1b2f?file=index.html. The first tab has disabled="false" while the second tab has just disabled. You can see that the first tab looks disabled, but actually it is not, you can navigate to it with the keyboard (also aria-disabled is not set). This is (as far as I can tell) because some of the code/css is treating disabled as truthy and other parts are treating it as falsey. The actual property on the component instance is set to false (e.g. select it in the dev tools and check $0.disabled), so any code that uses this property, or the observable changed handler, will treat disabled as false.

I think your comprehensive example (thanks) shows essentially the same behavior in the second example (attribute binding to "false"), the (x) => x.disabled binding is evaluating to false. Wouldn't you expect the buttons to be disabled when the background is pink? How would we expect people to write this code to get that behavior?

Thanks, I think the tablist issue may be a bug there, which is worth looking into.

In terms of the examples - those were specifically to illustrate that disabled is truthy in those scenarios and how the bindings inside work. My intention here wasn't to provide authoritative direction, but illustrate how the bindings may work internally when passing an attribute vs. the truthiness of the external. We're just passing disabled straight down here, not setting 'disabled' as true in the event of truthiness. I'd personally author that differently if the goal is, 'if disabled is truthy, everything inside is disabled'.

Let me look though to see if there is something with the tablist first.

One scenario that I thought of that is lifecycle related where this can happen.

IF you default to false in the class. The component is constructed as null, attribute changes to false, host is decorated as false, the callback won't fire because the attribute didn't change. In a non-binding scenario (just HTML land), the attribute is technically the same.