Update the rules for boolean attributes for 4.0 #5388
Comments
|
Oh, interesting. Perhaps we should update this list for 4.0 as this can be considered a breaking change. Or we should get rid of this manual normalization, depending on users doing the right thing here. The biggest issue are possibly falsy checks on values since an empty string is also a valid value. This was also raised by @timmywil in a past issue where I proposed a similar simlification: #2946. If we're worried about compat for such things, my guess would be we could limit this list to just a few entries like Our list right now is:
As Richard mentioned, If we want to keep the logic for at least some attributes, I could see us doing so just for Thoughts, @timmywil @gibson042? |
|
Tentatively adding it to |
|
I did a query on GitHub for calls like
Searches for all the other attributes generated less than 50 results.
I was surprised to see so few uses of the
Of course, that is a breaking change; the few most common breakages:
We can add Migrate warnings for both cases. Thoughts? |
|
Given that any change is breaking for some cases (albeit possibly only hypothetical) and that the current behavior is wrong and will become more wrong over time as HTML expand more currently-boolean attributes to include other values, I am of the opinion that we should remove special treatment for any boolean attribute, generalizing the |
I continue to be worried about the same as what I mentioned at one of our meetings - there are attributes with a valid There's prior art for us special casing some inputs due to backwards compat even if we preferred to drop the code altogether; the logic when to auto-append Lines 1 to 33 in f80e78e |
|
I thought about my original proposal and I think if we want to special-case, we should include more attributes, though, perhaps all with >50 search results above. Our unit tests also tell a story - if we special cased not just Depending on how much we want to play safe, we could even keep a version of the getter that converts an empty string to the attribute name and returns the other values unchanged. That would make the HTML like It would be hard to warn against this in Migrate as we can only patch the getter there, we cannot see it's being used as a truthy check. |
|
I submitted #5451 implementing the conservative approach I mentioned above. We can make it less conservative be removing one or two parts from it. Let's discuss this today. We can also go with Richard's solution of generalizing |
The HTML spec defines boolean attributes: https://html.spec.whatwg.org/#boolean-attributes that often correlate with boolean properties. If the attribute is missing, it correlates with the `false` property value, if it's present - the `true` property value. The only valid values are an empty string or the attribute name. jQuery tried to be helpful here and treated boolean attributes in a special way in the `.attr()` API: 1. For the getter, as long as the attribute was present, it was returning the attribute name lowercased, ignoring the value. 2. For the setter, it was removing the attribute when `false` was passed; otherwise, it was ignoring the passed value and set the attribute - interestingly, in jQuery `>=3` not lowercased anymore. The problem is the spec occasionally converts boolean attributes into ones with additional attribute values with special behavior - one such example is the new `"until-found"` value for the `hidden` attribute. Our setter normalization means passing those values is impossible with jQuery. Also, new boolean attributes are introduced occasionally and jQuery cannot easily add them to the list without incurring breaking changes. This patch removes any special handling of boolean attributes - the getter returns the value as-is and the setter sets the provided value. To provide better backwards compatibility with the very frequent `false` value p 8000 rovided to remove the attribute, this patch makes `false` trigger attribute removal for ALL non-ARIA attributes. ARIA attributes are exempt from the rule since many of them recognize `"false"` as a valid value with semantics different than the attribute missing. To remove an ARIA attribute, use `.removeAttr()` or pass `null` as the value to `.attr()` which doesn't have this exception. Fixes jquerygh-5388 Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
|
At the meeting, we decided to:
PR #5452 implements this proposal. |
The HTML spec defines boolean attributes: https://html.spec.whatwg.org/#boolean-attributes that often correlate with boolean properties. If the attribute is missing, it correlates with the `false` property value, if it's present - the `true` property value. The only valid values are an empty string or the attribute name. jQuery tried to be helpful here and treated boolean attributes in a special way in the `.attr()` API: 1. For the getter, as long as the attribute was present, it was returning the attribute name lowercased, ignoring the value. 2. For the setter, it was removing the attribute when `false` was passed; otherwise, it was ignoring the passed value and set the attribute - interestingly, in jQuery `>=3` not lowercased anymore. The problem is the spec occasionally converts boolean attributes into ones with additional attribute values with special behavior - one such example is the new `"until-found"` value for the `hidden` attribute. Our setter normalization means passing those values is impossible with jQuery. Also, new boolean attributes are introduced occasionally and jQuery cannot easily add them to the list without incurring breaking changes. This patch removes any special handling of boolean attributes - the getter returns the value as-is and the setter sets the provided value. To provide better backwards compatibility with the very frequent `false` value provided to remove the attribute, this patch makes `false` trigger attribute removal for ALL non-ARIA attributes. ARIA attributes are exempt from the rule since many of them recognize `"false"` as a valid value with semantics different than the attribute missing. To remove an ARIA attribute, use `.removeAttr()` or pass `null` as the value to `.attr()` which doesn't have this exception. Fixes gh-5388 Closes gh-5452 Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
The `hidden` attribute used to be a boolean one but it gained a new `until-found` eventually. This led us to change the way we handle boolean attributes in jQuery 4.0 in jquerygh-5452 to avoid these issues in the future. That said, currently from the attributes we treat as boolean only `hidden` has gained an extra value, let's support it. Ref jquerygh-5388 Ref jquerygh-5452
The `hidden` attribute used to be a boolean one but it gained a new `until-found` eventually. This led us to change the way we handle boolean attributes in jQuery 4.0 in jquerygh-5452 to avoid these issues in the future. That said, currently from the attributes we treat as boolean only `hidden` has gained an extra value, let's support it. Ref jquerygh-5388 Ref jquerygh-5452
The `hidden` attribute used to be a boolean one but it gained a new `until-found` eventually. This led us to change the way we handle boolean attributes in jQuery 4.0 in jquerygh-5452 to avoid these issues in the future. That said, currently from the attributes we treat as boolean only `hidden` has gained an extra value, let's support it. Ref jquerygh-5388 Ref jquerygh-5452
The `hidden` attribute used to be a boolean one but it gained a new `until-found` eventually. This led us to change the way we handle boolean attributes in jQuery 4.0 in jquerygh-5452 to avoid these issues in the future. That said, currently from the attributes we treat as boolean only `hidden` has gained an extra value, let's support it. Ref jquerygh-5388 Ref jquerygh-5452
The `hidden` attribute used to be a boolean one but it gained a new `until-found` eventually. This led us to change the way we handle boolean attributes in jQuery 4.0 in jquerygh-5452 to avoid these issues in the future. That said, currently from the attributes we treat as boolean only `hidden` has gained an extra value, let's support it. Ref jquerygh-5388 Ref jquerygh-5452
The `hidden` attribute used to be a boolean one but it gained a new `until-found` eventually. This led us to change the way we handle boolean attributes in jQuery 4.0 in gh-5452 to avoid these issues in the future. That said, currently from the attributes we treat as boolean only `hidden` has gained an extra value, let's support it. Closes gh-5607 Ref gh-5388 Ref gh-5452
Our list of boolean attributes is outdated; it is missing several boolean attributes from HTML Attributes, includes a
scopedthat isn't even present there, and treatshiddenas boolean despite the expansion of that attribute to be an enumeration including "until-found" by whatwg/html@f5def65.Originally posted by @gibson042 in #5384 (comment)
The text was updated successfully, but these errors were encountered: