8000 Bug with disabled attribute on component itself · Issue #3021 · riot/riot · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Bug with disabled attribute on component itself #3021

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
1 of 7 tasks
kachurun opened this issue Sep 10, 2024 · 6 comments
Open
1 of 7 tasks

Bug with disabled attribute on component itself #3021

kachurun opened this issue Sep 10, 2024 · 6 comments
Assignees
@GianlucaGuarini
Labels
breaking change enhancement fixed low priority

Comments

@kachurun
Copy link
Member
kachurun commented Sep 10, 2024 •
edited
Loading

Help us to manage our issues by answering the following:

  1. Describe your issue:

When the disabled attribute is set to false in the component, it still renders as disabled="false". However, setting disabled={ null } does not cause this issue, and the disabled attribute is correctly omitted.

Example:

<my-tag disabled={ false }>
  <h1 disabled={ false }>False</h1>
  <h1 disabled={ true }>True</h1>
</my-tag>

The result is:

<my-tag disabled="false">
  <h1>False</h1>
  <h1 disabled="disabled">True</h1>
</my-tag>
  1. Can you reproduce the issue?

Post the link using one of our bug report templates:

  1. On which browser/OS does the issue appear?

  2. Which version of Riot does it affect?
    I noticed this issue after upgrading from 7.1.0 to 9.4.0.

  3. How would you tag this issue?

  • Question
  • Bug
  • Discussion
  • Feature request
  • Tip
  • Enhancement
  • Performance
@kachurun
Copy link
Member Author

I also checked other "boolean" html attributes:
https://plnkr.co/edit/WvoIjvIsCnlst7Qa

@GianlucaGuarini
Copy link
Member

Thank you it looks like a bug.

Side note: this is an edge case since you should not use specific native boolean attributes on elements that do not support them

@GianlucaGuarini GianlucaGuarini self-assigned this Sep 13, 2024
@kachurun
Copy link
Member Author

this is an edge case since you should not use specific native boolean attributes on elements that do not support them

Maybe I didn’t understand your message correctly, but I don’t see any difference between native and non-native attributes from a developer’s perspective when building a frontend. I don’t care much about W3C validations and prefer clean code, even if it breaks some standards. I also don’t think Riot should behave differently in those cases. It’s just too complicated to constantly think like "Oh, if I put this on a button, it will work differently than if I put it on a link."

Anyway, <button is="my-tag"></button> behaves the same way in this scenario and renders as <button is="my-tag" disabled="false"></button>

@GianlucaGuarini
Copy link
Member

I have checked this issue and its solution is trivial https://github.com/riot/compiler/blob/main/src/generators/template/expressions/attribute.js#L48-L54
However it's a breaking change and I will consider it in the next Riot.js major release.

Thank you for reporting it

@GianlucaGuarini GianlucaGuarini mentioned this issue Oct 25, 2024
Open
7 tasks
GianlucaGuarini added a commit to riot/compiler that referenced this issue May 23, 2025
@GianlucaGuarini
chore: Add patch for riot/riot#3021
e7fbcee
GianlucaGuarini added a commit that referenced this issue May 23, 2025
@GianlucaGuarini
fix: #3021
31e7a31
@GianlucaGuarini
Copy link
Member

This issue was fixed in Riot.js@10.0.0-alpha.3. @kachurun could you please check if it works for you? Thanks

@kachurun
Copy link
Member Author

Yep, looks great

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@GianlucaGuarini GianlucaGuarini

Labels
breaking change enhancement fixed low priority
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@GianlucaGuarini @kachurun
0