Regression: boolean attributes are no longer removed if value is false if attr name contains a dash

[rejhgadellaa]

• Check if updating to the latest Preact version resolves the issue

Describe the bug

Preact 10.11.1 introduced the following change:

Fix falsy data attributes not working
https://github.com/preactjs/preact/releases/tag/10.11.1

Related issue #3717 and PR #3720

To Reproduce

With preact 10.11.0, the following snippet:

<div data-has-toolbar={hasToolbar} />

would result in either a <div /> with or without the attribute:

<div data-has-toolbar="true" />
<div />

but starting in 10.11.1, it results in:

<div data-has-toolbar="true" />
<div data-has-toolbar="false" />

Expected behavior

I was relying on the old behaviour for style rules so, at least in my use-case, this change could be considered a regression. The following CSS selector now always applies:

div[data-has-toolbar] { /* ... */ }

where previously it would only apply if the prop's value was true.

The old behaviour feels more like HTML spec for boolean attributes/properties, but I'm not sure this applies to data- attributes?

For example, I think element.dataset.hasToolbar will always return a string where boolean properties-derived-from-attributes like element.required and -.disabled will actually return a boolean in javascript.

I can also see how it's worthwhile following React's behaviour here. They've actually recently fixed an issue and adopted Preact's behaviour for boolean attributes without dashes: facebook/react#9230

[krskrs]

Hi,
in my case it wasn't a regression, but a fix, as it was causing issues with React MUI which don't occur in react.

[rejhgadellaa]

@krskrs yeah I can see how this fixes compat with React but at the same time introduces issues for projects that rely on the old behaviour. My main reason for opening this ticket is to point that out and to make sure the team is aware that they didn't just fix a bug (unless the old behaviour truly was unintentional - the fix may still break sites but at least then those sites just relied on the effects of the bug, not actual intended behaviour)

[rburgst]

see #3717

[JoviDeCroock]

@rejhgadellaa We are aware of this and I want to apologise for it, I did not account for this breaking behavior but thinking about it both unit tests and manual dom lookups could have suffered because of it.