Decide on the desired behavior when a boolean value is passed to an unknown prop.

[flarnie]

Moving the discussion from comments in #10509 to this issue.

[sophiebits]

cc @aweary @nhunzaker

What are the properties that expect "true" or "false" values?

I know the ARIA boolean attributes do but from a cursory look at https://www.w3.org/TR/wai-aria/states_and_properties, all of the boolean attributes default to false (grep the page for true (default), no matches – compare to false (default)).

That means we could do ="true" for true and omit the attribute for false. I think that might be compatible for almost every case. In HTML, any string is treated as a boolean value so ="true" is valid. download="true" is the only attribute I know of whose behavior is different from download and we already have a special case for that that I guess we can just keep.

[flarnie]

Attempting to summarize the proposals and pros/cons so far:

Option 1:
Stringify and pass booleans through.

Pros:

• Consistent with the way React currently treats known attributes.
• Already implemented in Moar attribute tests #10509

Cons:

• Is probably not what the engineer wants or expects their code to do.
• Could create bugs; 'foo="false"' may get treated the same as 'foo="true"' by some browsers.

Option 2:
Render is as an implicit boolean attribute, either adding with a no value if true was passed, removing if false was passed.

Pros:

• This is consistent with the spec, and probably closest to the desired behavior.
• This would fix Boolean attributes on Web Components #9230

Cons:

• Needs to be implemented.
• We should change behavior for known attributes as well, in order to be consistent. If not, then introduces inconsistency.
• (?) Introduces another flavor of behavior for attributes in React, could be confusing. Maybe not a problem.

Option 3:
Remove booleans and warn.

Pros:

• This is consistent with how we treat other "invalid" values, like functions.
• This is the behavior on master, and could be achieved by minor updates to Moar attribute tests #10509

Cons:

• Would require minor updates to Moar attribute tests #10509.
• Isn't totally consistent with the spec for boolean attributes, might be unexpected for users.

Edit: Please correct anything I missed, thanks to everyone who has chimed in about this.

[flarnie]

Also wanted to share this:

Let's try to:

• Keep behavior consistent between "known attributes" and "unknown attributes" when possible
• Limit the number of colors used; it's simpler for users to have fewer variation how React deals with property values.

[sophiebits]

So IIUC as far as we know option 2 has no downsides and will never cause the wrong behavior that we know of. Is that right? If so, that sounds the most compelling to me.

[aweary]

That means we could do ="true" for true and omit the attribute for false.

@spicyj setting boolean attributes to "true" isn't valid according to the HTML spec section on boolean attributes.

If the attribute is present, its value must either be the empty string or a value that is an ASCII case-insensitive match for the attribute's canonical name, with no leading or trailing whitespace. The values "true" and "false" are not allowed on boolean attributes.

This is especially a problem with custom elements, as outlined in #9230.

download="true" is the only attribute I know of whose behavior is different

spellcheck is another enumerable attribute that accepts "true" and "false".

What I'm suggesting is this:

1. If it's a known attribute that expects a stringified boolean, stringify it before calling setAttribute

2. If it's an unknown attribute, treat true and false as boolean attributes according to the spec (setting attribute with an empty string or a case-insensitive match of the attribute name for true and removing the attribute for false)

3. Otherwise, call setAttribute with the stringified value

[nhunzaker]

@spicyj Actually... for a prior version of the custom attributes feature, @gaearon and I dug through the spec and found all of the attributes that expected true/false strings. They are:

HTML:

    autoComplete: 0,
    // IE only true/false iFrame attribute
    // https://msdn.microsoft.com/en-us/library/ms533072(v=vs.85).aspx
    allowTransparency: 0,
    contentEditable: 0,
    draggable: 0,
    spellCheck: 0,
    // autoCapitalize and autoCorrect are supported in Mobile Safari for
    // keyboard hints.
    autoCapitalize: 0,
    autoCorrect: 0,
    // autoSave allows WebKit/Blink to persist values of input fields on page reloads
    autoSave: 0,

SVG:

  'autoReverse',
  'externalResourcesRequired',
  'preserveAlpha',

[sophiebits]

@aweary It has the correct behavior though, right? In practice, you would test .hasAttribute() since it is common to do checked="" and common to do checked="".

@nhunzaker Ah, so like autoComplete={false} would need to become autocomplete="false"? Good find.

[aweary]

@spicyj the existing behavior isn't correct because it renders <div bool={false} /> as <div bool="false" />. The spec also explicitly states that "true" is not a valid value for boolean attributes, so I suspect there may be implications extending past whether hasAttribute returns the right value (for example, with custom elements)

[nhunzaker]

I think what @aweary is suggesting makes sense, we already have the stringy boolean attributes in the list. We'd still allow all boolean values through in the filter, but change the way the boolean attribute is actually written in DOMPropertyOperations and DOMMarkupOperations.

[nhunzaker]

@aweary Still, I'm curious about the behavior here. Why does setAttribute('test', false) assign a string 'false' here, if that doesn't match the spec?

https://codepen.io/nhunzaker/pen/vJrvmY

[aweary]

@nhunzaker it's weird, I know. Boolean attributes are kind of spec'd as "they should exist, or they shouldn't" so using setAttribute to remove a boolean attribute doesn't make sense given that the API is all about setting attributes. That's why the spec states to use removeAttribute for boolean attributes with a false value.

At least, that's my interpretation. I can't speak to the motives of the spec authors 😄

[aweary]

We'd still allow all boolean values through in the filter, but change the way the boolean attribute is actually written in DOMPropertyOperations and DOMMarkupOperations.

👍 maybe we could coerce known enumerable attributes expecting booleans to strings earlier in the code path so that setValueForAttribute can just coerce true to "" and call removeAttribute for false. Or maybe pass a flag to setValueForAttribute. Either way, I think implementing this behavior shouldn't be too complex.

[flarnie]

@sebmarkbage pointed out we don't actually have a consistent behavior in 15.* for booleans - sometimes they get stringified, sometimes maybe not. I'll let him add some context on why we thought of stringifying as the default in 16.0.

[aweary]

To clarify my position, I'm mostly advocating for following the spec for unknown boolean attributes. If there are compatibility concerns with some set of known/previously-known attributes, that totally makes sense, and I can get behind special casing that behavior.

I just think the default approach for attributes we have no information about should be consistent with the spec if possible.