I'm still getting introduced to the iAPI code, which is not being straightforward, but something is not right with me with that list of “boolean attributes.”

The first thing that comes to my mind is to simply check for each element if they are of boolean type, instead of having to list the dozens of potential boolean types that could be useful for any use case.

Anyway, I would like to hear from @luisherranz

Hi @SirLouen 👋 I'm taking a look at this PR and the related issue.

It's true that we could check if a given attribute is of boolean type, although that comparison is not straightforward. Some attributes don't directly translate to their corresponding property (e.g., readonly → readOnly, novalidate → noValidate, etc.) So, we would have to rely on a "list" for this, either all boolean attributes or the corresponding prop if they have a different name.

Regarding the list of all boolean attributes, this is what I get from Claude Opus 4.5:

Full Reference

Attributes with Different HTML/DOM Names

This is unmaintainable. The list may grow over time. Do you really think there isn't a more generalizable way to target them? For example, camelcase testing or something like that?

Yeah, the list is quite long. 🤔 I agree that camelcase testing would be more approachable. Still, we would need a list of attributes that have their equivalent DOM prop in camelcase, right? This would have the same maintainability problem, given that the list could also grow over time.

Yes, its almost impossible to achieve this

I've asked GPT for some ideas, and after reviewing and several iterations I got to this conclusion

Long story short:

1. Gets all the elements from DOM
2. Check against each element if the attribute is boolean by creating the element and adding the attribute and testing it
3. There are some elements like async that are false by default and others like autofocus are true so it test in the two conditions
4. Finally, it returns the result.

Conclusion: This is crazy low-performing and not viable. There could be some caching in between to slightly improve the overall performance.

Definitely the most performant way is still, to maintain a list. So at this point I wonder if there could be another implementation without having to necessarily check if it's boolean (or maybe just stick to the boolean elements we have in the inspector controls).

Preact checks the name in the element, and if it doesn't exist (because there's a camel case mismatch), it falls back to setAttribute.

`open` in `details` // true
// Preact uses elem[attr] = value;

`readonly` in `input` // false because it's readOnly, not readonly
// Preact uses elem.setAttribute(attr, value);

elem.setAttribute(attr, value) works fine when the element is boolean and the value is an empty string (""), so we don't have to worry about that case.

We can simply do this to match what Preact is doing underneath:

if (attributeValue === "" && typeof elementNode[attributeName] === "boolean") {
  props[attributeName] = elementNode[attributeName];
} else {
  props[attributeName] = attributeValue;
}

Alternative PR:

• iAPI: Preserve boolean HTML attributes during client side navigation #74446

Nice! Thanks, @luisherranz, that's a much better approach. I should have paid more attention to the internal nuances of Preact's diffing algorithm. 😅

@vipul0425, @SirLouen, I think we can close this PR in favor of #74446.

I had a hunch that there had to be a better solution. I'm not into preact so I would have never figured out. Time to close this 👍