Boolean attributes

[edemaine]

Questions: How should JSX attributes foo and foo={true} behave for an HTML element, as in <div foo> or <div foo={true}>? Should the behavior differ for components and/or spreads?

Current behavior in Solid:
Assume const Div = (props) => <div {...props}/>

JSX	Equivalent HTML
<div foo>	<div foo="">
<div foo="">	<div foo="">
<div foo={true}>	<div foo="true">
<div foo="true">	<div foo="true">
<Div foo>	<div foo="true"> ☆
<Div foo="">	<div foo="">
<Div foo={true}>	<div foo="true">
<Div foo="true">	<div foo="true">

The ☆ behavior (another consequence of setAttribute's string casting) is particularly counterintuitive, as it differs between HTML elements and component-wrapped elements. (It may also be an SSR discrepancy?) @fabiospampinato's observation of this weirdness is what spawned this exploration (in #templating channel, also with @lxsmnsyc).

Relevant facts:

• HTML 5 defines attribute foo to be equivalent to foo=""
• React defines that foo is equivalent to foo={true}.
• TypeScript treats foo like foo={true} (attribute should accept Boolean value)
• React (specifically react-dom) converts JSX attribute foo to HTML equivalent of foo="true" unless foo is on a whitelist of "Boolean" attributes, in which case it converts to foo="". Here's a relevant list; note that there are some Boolean-like attributes which aren't actually Boolean. For example, React "correctly" converts draggable={true} to draggable="true" and "correctly" converts async={true} to async="".

Desired properties:

1. foo is always equivalent to foo="" for HTML/SVG elements (as in HTML 5). This is useful for copy/pastability of HTML, which the JSX spec considers important.
2. foo is equivalent to foo={true} (as in React and TypeScript)
3. draggable={true} is equivalent to draggable="true"
4. <div foo> is equivalent to const Div = (props) => <div {...props}/>; <Div foo>

We can't have all four properties.

• Properties 1, 2, and 3 contradict each other: 1+2 imply draggable={true} is equivalent to draggable="".
• React satisfies Properties 2, 3, and 4. It follows Property 1 only for a whitelist of Boolean attributes.
• Solid satisfies Properties 1 and 2. It satisfies Property 3 for Div but not div. It doesn't satisfy Property 4 because of ☆.

Proposal:
I really like Property 1, and would propose gaining Property 4 by compiling foo={value} to essentially _el$.setAttribute('foo', value === true ? '' : value), where value is stored in a temporary variable if it's a general expression, with a similar modification to spreads. This would basically flip ☆, and also change those marked "!":

JSX	Equivalent HTML
<div foo>	<div foo="">
<div foo="">	<div foo="">
<div foo={true}>	<div foo=""> !
<div foo="true">	<div foo="true">
<Div foo>	<div foo=""> ☆
<Div foo="">	<div foo="">
<Div foo={true}>	<div foo=""> !
<Div foo="true">	<div foo="true">

(By contrast, React's approach of an attribute whitelist feels gross...)

[fabiospampinato]

I think potentially there's a 5th desired property:

• Writing <div foo /> should produce a div with an identical outerHTML string for any value of foo both if Solid's custom transform is used and if it isn't.

Maybe this isn't super desirable or it's too much of an edge case, but since using Solid with React's transform is supported I'd find it strange if something completely static like <div draggable /> produced different divs depending on which transform is used, though in general some differences are expected or the custom transform wouldn't exist.

[otonashixav]

To be clear, this wouldn't affect directives, correct? i.e. <div use:foo> still calls foo(ref, () => true), and not foo(ref, () => "").

[LiQuidProQuo]

what about the case where you want to remove the attribute
undefined probably
false null maybe

[edemaine]

To be clear, this wouldn't affect directives, correct? i.e. <div use:foo> still calls foo(ref, () => true), and not foo(ref, () => "").

Correct. It won't even affect props in components: foo will still appear as props.foo === true. It's just about when something hits the DOM, which never happens for directives.

what about the case where you want to remove the attribute
undefined probably
false null maybe

undefined and null already behave this way (whereas false renders as "false"). Oops, I didn't realize there's already a setAttribute helper which could be used for exactly this purpose:

https://github.com/ryansolid/dom-expressions/blob/3c593d43147a73ddd52c58ba8c49f4f1e0e7e560/packages/dom-expressions/src/client.js#L68-L71

I took a stab at implementing the proposal here: ryansolid/dom-expressions#141

[LiQuidProQuo]

undefined and null already behave this way

yes

(whereas false renders as "false").

but then isn't odd if true does this:
<div foo={true}> | <div foo="">
and false does this
<div foo={false}> | <div foo="false">

?

[ryansolid]

I see. In general we set known boolean attributes by property and everything else by setAttribute. I see I left boolean(no arg) working like a boolean in it literally sets empty string but this is probably wrong. A boolean attribute cannot be removed so there is no inconsistency on that side but it means we probably should be setting it to true.

We used to do this the other way but there are attributes that actually want "true" and "false". I think we should continue checking against the list and apply it to the boolean form. I guess thats siding with React. But the other way is no good either.

There is no guarantee it ends up in the DOM through a component so it has to come in as true. The spread has the choice. And we've landed on pass list. So i think it has to be the first example that is off.

EDIT: If you are wondering the source of Solid's implementation. As usual Inferno is what I trust for these sort of things. React probably has the most thorough but I suspect this is a place both Inferno and Preact save size by doing something reasonable.

[lxsmnsyc]

Some helpful resource (from React).

• React marks contentEditable, draggable, spellCheck and value as those properties that would be convered into "true" and "false" when written as eg. <div draggable> and <div draggable={true}>. Users can still use <div draggable="true">, which is defined by React as Booleanish (https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react/index.d.ts#L54 and https://github.com/facebook/react/blob/main/packages/react-dom/src/shared/DOMProperty.js#L30)
• Aside from the mentioned above, React also does this for the SVG properties autoReverse, externalResourcesRequired, focusable, and preserveAlpha even though these properties aren't actually booleans.
• The rest of the boolean attributes (encoded as attr="" are still filtered instead of generalized https://github.com/facebook/react/blob/main/packages/react-dom/src/shared/DOMProperty.js#L330-L367
• while others are directly set as a property https://github.com/facebook/react/blob/main/packages/react-dom/src/shared/DOMProperty.js#L369-L392
• They also have a third type called "overloaded boolean" which acts like "booleans" but can also accept string values, specifically they use it only for capture and download https://github.com/facebook/react/blob/main/packages/react-dom/src/shared/DOMProperty.js#L394-L413

Nothing is mentioned about aria-* properties, but should we handle them like draggable?

Edit:
Seems like Solid already properly handles aria-* properties based on my tests on solid-headless

[edemaine]

This is a great analysis of React behavior @lxsmnsyc! I think this line actually makes aria-* and data-* behave like aria-*="true" and data-*="true"; at least that matches my testing.

Obviously one option is to reproduce React's behavior. I think there's still an open question of what to do with attributes that aren't on any of these lists:

1. We could default to foo/foo={true} meaning foo="true", as Solid currently does.
2. We could default to foo/foo={true} meaning foo="" as in Desired Property 1 / HTML 5 spec.
3. We could default to foo/foo={true} meaning "make no attribute, but issue warning", which I just discovered React does.

Personally I think Option 2 makes sense, given HTML spec, but it differs from both current Solid and React. An advantage of this approach is that you only need a list of "enumerated but Boolean-like" attributes, like those listed in bullets 1 and 2 of @lxsmnsyc's post and aria-* (not sure about React's decision to include data-* — that feels like it should be application-specific, so matching HTML behavior makes more sense to me). No need to have a list of all Boolean properties because Option 2 will just handle them correctly. (There's a similar advantage to Option 1: you'd "only" need to list Boolean properties, not pseudo-Boolean properties. But I think that list is longer.)

[lxsmnsyc]

With data-*, how does dataset property work with raw boolean values?

[edemaine]

With data-*, how does dataset property work with raw boolean values?

Good point: dataset casts true to "true". Currently, Solid seems to use setAttribute for setting data-* attributes, but if it switched to using dataset in the future, it might make sense to map data-foo to data-foo="true" for consistency with the reactive case.

[ryansolid]

If I didn't make it clear in my previous response. While I see potential of changing more things and doing stuff differently. It's the first row that is the bug today and should be fixed. We already default to true except for a pass-list and I'm not prepared to change that at the moment. We were the other way in the past but it caused other confusion and errors.

So I've updated this case to use that pass-list: <div foo> => <div foo="true">. Where a known boolean attribute would work appropriately.

[edemaine]

For what it's worth, I recently bumped into this React GitHub issue where users were confused about the inconsistent behavior, in particular for data-* attributes and how it differs from HTML. (They write "JavaScript" but they mean the innerHTML interface.)

facebook/react#24812

At the least I think we need to document things clearly here. (Personally I'd also much rather have the default be "like HTML" instead of "like React".)