Skip to content
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.

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

false positive on no-whitespace-for-layout #2899

Open
nvdk opened this issue May 31, 2023 · 2 comments
Open

false positive on no-whitespace-for-layout #2899

nvdk opened this issue May 31, 2023 · 2 comments
Labels

Comments

@nvdk
Copy link

nvdk commented May 31, 2023

I'm getting a linting error on the following code (running ember-template-lint 5.10.0):

                <button type="button"
                  {{on "click" (fn @onChange zeroBasedPage)}}
                  class="-ml-px relative inline-flex items-center {{this.paddingClass}} border border-zinc-300 bg-white {{this.textSizeClass}} leading-5 font-medium {{if (eq zeroBasedPage this.page) "text-blue-600 hover:text-blue-800 active:text-blue-600" "text-zinc-700 hover:text-zinc-500 active:text-zinc-700"}} focus:z-10  focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-blue-500">
                  {{page}}
                </button>

it seems to be angry about the whitespace after the inline handlebars in the class attribute (column 142 of that line). I know this isn't the prettiest code, but shouldn't the rule ignore attributes?

@bmish
Copy link
Member

bmish commented Jun 1, 2023

Currently, as the rule doc says, this rule checks any text nodes for excess whitespace, including text inside or outside attributes. But I think it's a fair question to ask if the rule should be checking the values of arbitrary attributes. Arguably, the class attribute could be fair-game for an excess whitespace check, as it's an attribute we know shouldn't have (or at least doesn't need) excess whitespace in it, but attribute values aren't used for the page layout, so checking this may not align with the goal of the rule.

I didn't immediately see a justification for this behavior in the original rule PR #819. Maybe @MelSumner has some context on whether this is intended behavior.

@MelSumner
Copy link
Contributor

@bmish I'd be okay with excluding attribute values from these checks, that seems reasonable.

@bmish bmish added the bug label Jun 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants