7 Replies - 815 Views - Last Post: 05 March 2015 - 07:11 AM

#1 Christopher.Burkhouse   User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 20
  • Joined: 03-March 15

CSSLint, and why I dislike it. Am I wrong?

Posted 04 March 2015 - 08:29 PM

Hey guys, I have a few questions to ask!

I've been coding in HTML, CSS, JS, and so on for a while now. Well, CSSLint makes some great points, but also some harmful points in my opinion. I've read some articles which back up some of my stances, but tell me what you all thing!

1. Disallow IDs in selectors
Why does CSSLint hate on ID tags?
https://github.com/C...Ds-in-selectors

Quote

However, IDs have a downside: they are completely unique and therefore cannot be reused. You could potentially style every element on your page with an ID selector but you would lose a lot of the benefit of CSS in the process.


This isn't necessarily a BAD thing, is it? I use IDs for unique one time only features such as header/footer info that is unique and only used once. I do use classes a LOT, but it seems like they implement this rule since some users overuse IDs. Therefore, they should NEVER be used. They treat IDs like high school English teachers explain the word 'and.' Believe it or not, it is okay to start a sentence with 'and,' but lots of students were overusing the rule (since it should be used scarcely). As a result, lots of high schools figured it was best to say a sentence should simply never start with the word 'and.' What do you guys think?

2. Disallow outline:none
CSSLint argues that outline:none should be allowed since browsers use it for accessibility. It allows users to know where the focus is. If you select a checkbox, you get a focus line of 1px. Some users do not want this focus, therefore remove it. Well, CSSLint tags this! Preference should not define a standard. It's a feature to allow flexibility. I understand the reasoning behind CSSLint's dislike towards this tag, but feel telling coders it should NEVER be used is wrong.
https://github.com/C...-outline%3Anone

3. Disallow @import
At first I was torn, but I just feel like the reason not to allow @import isn't great enough to not allow it. I mean... is it going to slow performance drastically? Maybe I'm missing something here but it seems like a silly rule.
https://github.com/[email protected]

Just three reasons that got me originally disliking CSSLint and what I feel is spreading incorrect standards. Am I wrong to feel this way though? Please let me know, I'd love to know what you all feel, and if you have anything to add (:

-Chris

View PostChristopher.Burkhouse, on 04 March 2015 - 08:25 PM, said:

2. Disallow outline:none
CSSLint argues that outline:none should be allowed since browsers use it for accessibility.


I meant to say shouldn't, sorry about that! I can never find the edit button on this website, am I missing it?

Is This A Good Question/Topic? 0
  • +

Replies To: CSSLint, and why I dislike it. Am I wrong?

#2 macosxnerd101   User is offline

  • Games, Graphs, and Auctions
  • member icon




Reputation: 12769
  • View blog
  • Posts: 45,954
  • Joined: 27-December 08

Re: CSSLint, and why I dislike it. Am I wrong?

Posted 04 March 2015 - 08:40 PM

Quote

I meant to say shouldn't, sorry about that! I can never find the edit button on this website, am I missing it?

Dormilich answered your question on that here, post 18.
Was This Post Helpful? 1
  • +
  • -

#3 Christopher.Burkhouse   User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 20
  • Joined: 03-March 15

Re: CSSLint, and why I dislike it. Am I wrong?

Posted 04 March 2015 - 10:28 PM

Ah he did. For some reason I misread that as a 15min give/take time limit, rather than post count. Sorry for repeating myself. My post count is probably the culprit then :P/>

This post has been edited by Dormilich: 05 March 2015 - 01:21 AM

Was This Post Helpful? 0
  • +
  • -

#4 ge∅   User is offline

  • D.I.C Lover

Reputation: 319
  • View blog
  • Posts: 1,335
  • Joined: 21-November 13

Re: CSSLint, and why I dislike it. Am I wrong?

Posted 05 March 2015 - 01:25 AM

I think you shouldn't use id selectors for containers if you can avoid it. It's not well explained in the documentation but it has to do with rules priority in CSS : the more specific a selector is, the more important it is.

Take this example

<div id="foo">
   <p>blablabla <a>bliblibli</a> blobloblo</p>
   <p class="bar">blablabla <a>bliblibli</a> blobloblo</p>
</div>



Imagine you have set the following rule in your CSS

#foo a {
   color: red;
}



then you want to set that rule for links contained in .bar

.bar a {
   color: blue;
}



It won't work ! Because there is nothing more specific than an id attribute since it uniquely define an element.

So you'll have to write the following

#foo .bar a {
   color: blue;
}



or

.bar a {
   color: blue !important; /* don't do that */
}



The more you use id selectors, the more you need them. If you're not cautious, you will end up prefixing a very big part of your code in order to manage priority, making your CSS a lot less flexible : if you then want to apply some of the rules for another container, you can't do it without having to duplicate code or use coma separated selectors, making your already complex selectors even more twisted and long...

I don' think you should ban id selectors altogether but it's nice to have a warning when you use them because you should always wonder "can this be applied to other elements ?". I know I usually style elements container by container (I also use SCSS nesting a lot), so using id selectors OR very specific selectors when it's not required is very likely to create such a snowball effect.

-

Concerning outline : none. Really, if you don't provide a replacement style its a VERY BAD practice. The purpose of the web is to make content accessible to the user, if someone with mechanical disabilities cannot navigate with his keyboard on your site it's simply wrong. You can use the same style as the :hover selector (don't use JS tricks to defocus stuff because it's even worse for accessibility, obviously). You can add a class in JS on mouseout if you want - I know it's not great but accessibility is more important than anything.
Was This Post Helpful? 0
  • +
  • -

#5 Christopher.Burkhouse   User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 20
  • Joined: 03-March 15

Re: CSSLint, and why I dislike it. Am I wrong?

Posted 05 March 2015 - 02:00 AM

View Postge∅, on 05 March 2015 - 01:25 AM, said:

I think you shouldn't use id selectors for containers if you can avoid it. It's not well explained in the documentation but it has to do with rules priority in CSS : the more specific a selector is, the more important it is.

Take this example

<div id="foo">
   <p>blablabla <a>bliblibli</a> blobloblo</p>
   <p class="bar">blablabla <a>bliblibli</a> blobloblo</p>
</div>



Imagine you have set the following rule in your CSS

#foo a {
   color: red;
}



then you want to set that rule for links contained in .bar

.bar a {
   color: blue;
}



It won't work ! Because there is nothing more specific than an id attribute since it uniquely define an element.

So you'll have to write the following

#foo .bar a {
   color: blue;
}



or

.bar a {
   color: blue !important; /* don't do that */
}



The more you use id selectors, the more you need them. If you're not cautious, you will end up prefixing a very big part of your code in order to manage priority, making your CSS a lot less flexible : if you then want to apply some of the rules for another container, you can't do it without having to duplicate code or use coma separated selectors, making your already complex selectors even more twisted and long...

I don' think you should ban id selectors altogether but it's nice to have a warning when you use them because you should always wonder "can this be applied to other elements ?". I know I usually style elements container by container (I also use SCSS nesting a lot), so using id selectors OR very specific selectors when it's not required is very likely to create such a snowball effect.

-

Concerning outline : none. Really, if you don't provide a replacement style its a VERY BAD practice. The purpose of the web is to make content accessible to the user, if someone with mechanical disabilities cannot navigate with his keyboard on your site it's simply wrong. You can use the same style as the :hover selector (don't use JS tricks to defocus stuff because it's even worse for accessibility, obviously). You can add a class in JS on mouseout if you want - I know it's not great but accessibility is more important than anything.


WOW, I never realized this issue with IDs and classes. It explains a lot of my earlier day issues where IDs would do what Classes couldn't... I'm willing to bet it's more of an issue with priority as you showed in your example above. I'm so glad I asked, I really appreciate the response btw.

As for outline:none, I guess the more I think about it, the more I can agree. Especially for older users, or as CSSLint explains, users who only use keyboards, etc... accessibility features are there only to help.

Yet I still can't justify why @import would be disallowed. Any theories on why CSSLint feels the non-parallel downloads is enough to justify trashing @import if possible? I dislike @import, but feel it can be very useful in some cases, especially if you use one CSS file in several other CSS files.

-Chris
Was This Post Helpful? 0
  • +
  • -

#6 baavgai   User is offline

  • Dreaming Coder
  • member icon


Reputation: 7507
  • View blog
  • Posts: 15,558
  • Joined: 16-October 07

Re: CSSLint, and why I dislike it. Am I wrong?

Posted 05 March 2015 - 04:31 AM

1. IDs: This makes sense. The id is, at noted, "that thing." It is not, "that thing which looks like this." The looks like part is the job of the class.

2. ouline: The context of this is using the property to show the active element. In that context, this is entirely valid. Having an element that could be active, or worse is active, and not being able to tell that is just a UI fail.

3. @imports: When you look at your HTML page you can clearly see the styles applied. So you just open up the style and find... a fucking @import! Now you don't know where the hell anything comes from. You open of the @import and find... another fucking @import! These things are like built in CSS Rickrolling. The only reason to use them is laziness or maliciousness.
Was This Post Helpful? 0
  • +
  • -

#7 ge∅   User is offline

  • D.I.C Lover

Reputation: 319
  • View blog
  • Posts: 1,335
  • Joined: 21-November 13

Re: CSSLint, and why I dislike it. Am I wrong?

Posted 05 March 2015 - 06:56 AM

baavgai, I don't know what development tool you are using but Firebug tells me everything I want to know about a CSS rule (selector, rule, file, line) even if there are @import on the way.

I use @import and I like it because my server merges stylesheets containing @import rules. So, on my local machine running Apache my browser follows the @import rules, it works just fine, and on my production site the client requests a single CSS file when it would have requested a lot more if I had used link tags in my HTML code. @import is used by SCSS as well (the Partials feature) so when I have SCSS projects I don't need to change anything, it works the same way.

I agree it's twisting the rule because it's not used as it was intended but it's nice to be able to add a server-side command in a CSS file, have it work without the server logic and validate W3C.
Was This Post Helpful? 0
  • +
  • -

#8 ge∅   User is offline

  • D.I.C Lover

Reputation: 319
  • View blog
  • Posts: 1,335
  • Joined: 21-November 13

Re: CSSLint, and why I dislike it. Am I wrong?

Posted 05 March 2015 - 07:11 AM

Christopher,

Concerning priorities, I've read something long ago about how it was computed and it helped me a lot.

You can think of a selector as a 3 digits number : the number of id attributes in the selector are added to the first digit, the number of class attributes are added to the second, and the number of tag names are added to the third.

So #foo a has a priority of 101, .bar a a priority of 11 and #foo .bar a a priority of 111.

I remember it's a bit more complicated than that, but most of the time it can be simplified this way : when you use a identifier other than a tag name, you can only override it with an identifier of equal or superior importance.

note: if you have more than 9 identifiers of one kind in your selector, you have to use a 6 digits number : 10 tag names is not as important as 1 class attribute

This post has been edited by ge∅: 05 March 2015 - 07:18 AM

Was This Post Helpful? 1
  • +
  • -

Page 1 of 1