Skip to content

Could Overqualified Elements check rest of usage? #44

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

Closed
LeeKowalkowski opened this issue Jun 16, 2011 · 4 comments
Closed

Could Overqualified Elements check rest of usage? #44

LeeKowalkowski opened this issue Jun 16, 2011 · 4 comments
Assignees
Labels
Milestone

Comments

@LeeKowalkowski
Copy link

For a class, if every occurrence of element.my-class is div.my-class, then of course that looks overqualified and unnecessary. But if I have li.my-class dt.my-class and dd.my-class, then they do not appear to be overqualified.

I think this warning should only be displayed if every occurrence of element.class is a reference to the same HTML tag name.

@dpie
Copy link

dpie commented Jun 16, 2011

Agreed. Here's an example of how CSS Lint is flagging elements as overqualified when it shouldn't.

li.last {
  margin-bottom: 2px;
}

p.last {
  margin-bottom: 10px;
}

This results in two warnings:

Overqualified Elements
Element (li.last) is overqualified, just use .last without element name.

Overqualified Elements
Element (p.last) is overqualified, just use .last without element name.

If the author was to reduce both selectors down to .last as suggested, all elements with that class would receive the compiled sum of both styles (in this case, margin-bottom:10px), which isn't the intention of the CSS code.

@nzakas
Copy link
Contributor

nzakas commented Jun 16, 2011

Interesting point. Definitely something we can look into.

@ghost ghost assigned stubbornella Jun 23, 2011
@nzakas
Copy link
Contributor

nzakas commented Jun 23, 2011

Nicole, what do you think on this one?

@stubbornella
Copy link
Member

good point.

I can think of another example:

.message{} //most code here
p.message{} //exceptions for block level elems here
strong.message{} // exceptions for inline elements here

Seems like a good change to me.

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

4 participants