Attribute Coercion Behavior

breaking

#

Overview #

Here is a high level summary of the changes:

• Drop the internal concept of enumerated attributes and treat those attributes the same as normal non-boolean attributes
• BREAKING: No longer removes non-boolean attribute if the value is boolean false. Instead, it's set as attr="false". To remove the attribute, use null or undefined. Handling of boolean attributes remain untouched.

For more information, read on!

2.x Syntax #

In 2.x, we had the following strategies for coercing v-bind values:

• For some attribute/element pairs, Vue is always using the corresponding IDL attribute (property): like value of <input>, <select>, <progress>, etc.

• For "boolean attributes" and xlinks, Vue removes them if they are "falsy" (undefined, null or false) and adds them otherwise (see here and here).

• For "enumerated attributes" (currently contenteditable, draggable and spellcheck), Vue tries to coerce them to string (with special treatment for contenteditable for now, to fix vuejs/vue#9397).

• For other attributes, we remove "falsy" values (undefined, null, or false) and set other values as-is (see here).

The following table describes how Vue coerces "enumerated attributes" differently with normal non-boolean attributes:

We can see from the table above, current implementation coerces true to 'true' but removes the attribute if it's false. This also led to inconsistency and required users to manually coerce boolean values to string in very common use cases like aria-* attributes like aria-selected, aria-hidden, etc.

3.x Syntax #

We intend to drop this internal concept of "enumerated attributes" and treat them as normal non-boolean HTML attributes.

• This solves the inconsistency between normal non-boolean attributes and “enumerated attributes”
• It also makes it possible to use values other than 'true' and 'false', or even keywords yet to come, for attributes like contenteditable

For non-boolean attributes, Vue will stop removing them if they are false and coerce them to 'false' instead.

• This solves the inconsistency between true and false and makes outputting aria-* attributes easier

The following table describes the new behavior:

*: changed

Coercion for boolean attributes is left untouched.

Migration Strategy #

Enumerated attributes #

The absence of an enumerated attribute and attr="false" may produce different IDL attribute values (which will reflect the actual state), described as follows:

Since we no longer coerce null to 'false' for “enumerated properties” in 3.x, in the case of contenteditable and spellcheck, developers will need to change those v-bind expressions that used to resolve to null to resolve to false or 'false' in order to maintain the same behavior as 2.x.

In 2.x, invalid values were coerced to 'true' for enumerated attributes. This was usually unintended and unlikely to be relied upon on a large scale. In 3.x true or 'true' should be explicitly specified.

Coercing false to 'false' instead of removing the attribute #

In 3.x, null or undefined should be used to explicitly remove a non-boolean attribute.

Comparison between 2.x & 3.x behavior #

Migration build flags:

• ATTR_FALSE_VALUE
• ATTR_ENUMERATED_COERCION