ID dans les sélecteurs (CSS Lint)

Bonjour à tous!

Je viens juste de consulter le dernier tweet d'alsacreations au sujet de CSS Lint.
Je viens de checker une feuille de style et je me retrouve avec une fulltitude d'erreurs: celle qui se répête le plus étant la suivante: "Don't use IDs in selectors." et j'avoue ne pas comprendre ce que je fais de mal dans le code suivant (exemple) :

 #logo{background: url('../images/bg-logo.png') top left no-repeat; height: 246px; width: 290px; position: absolute; top: 33px; left: -26px;}

Si quelqu'un pouvait m'expliquer mon erreur. Merci d'avance.

Cordialement.
Modifié par bgondy (16 Jun 2011 - 00:39)

Hello bgondy,

Comme indiqué dans la documentation de l'outil :

http://csslint.net/about.html#docs

"Don't use IDs in selectors

IDs shouldn't be used in selectors because these rules are too tightly coupled with the HTML and have no possibility of reuse. It's much preferred to use classes in selectors and then apply a class to an element in the page."

Il s'agit d'un problème de couplage fort entre le document HTML et la feuille de style, et tu empêches la réutilisation de la déclaration. (comme les IDs sont uniques)

Ca tient la route comme explication, les styles CSS doivent suivre les mêmes bonnes pratiques que tout langage de programmation, mais j'avoue ne jamais en avoir entendu parlé avant CSS lint.

Avez-vous plus d'info sur ce sujet?

POdy

Effectivement, l'id est à usage unique... mais c'est précisément pour cette raison que je mets un ID et pas une classe. Cela veut-il dire que je devrais mettre une classe logo que je n'utilise qu'une fois? Quel est l'intérêt?

Sinon sur l'outil, je connais depuis le tweet d'Alsacreations soit quelques minutes avant mon post =)

Je viens de regarder la liste des règles de CSS Lint et y'en a pas mal qui sont pour le moins étranges (pour rester poli)... Je serais toi j'oublierai cet outil.

Première fois que j'entend dire qu'il ne faut pas utiliser d'ID...

CSS Lint warns when a rule uses width or height in addition to padding and/or border.
CSS Lint simply checks to see if you've used float more than 10 times, and if so, displays a warning.


Je me demande à qui est destiné l'outil

Je me posais la même question...

Étonnant qu'un truc pareil soit posté sur le Tweeter d'Alsacreations.
Modifié par jb_gfx (16 Jun 2011 - 11:07)

Effectivement c'est assez bizarre comme lien, j'ai un sérieux doute sur la fiabilité de l'outil tout comme vous.

Comme le dit si bien l'auteur : "CSS Lint : Will hurt your feelings*"

L'auteur, Nicholas C. Zakas est un ancien architecte de chez YAHOO et maintenant freelance.
Il a été co développé avec Nicole Sullivan, architecte également, auteur de http://www.stubbornella.org.

Vous verrez ces deux personnes participer à de nombreuses conférences de renom de part le monde http://www.stubbornella.org/content/events/ et http://www.nczonline.net/speaking/.
Leurs contributions dans le domaine du web sont importantes et appréciées.

Ils ont développé un outil d'analyse statique de code pour le CSS comme ceux qu'on trouve dans d'autres langages, lint en c, JS lint en JS ou HTML validator plus proche de nous.
Ils servent en complément du compilateur ou de l'interpréteur et donnent des informations sur différents aspects du code.
Ce sont des recommendations, qu'on est libre de suivre, ou pas.

Etant donné la vitesse à laquelle évolue notre domaine, et le niveau de compétence des auteurs de cet outil, je pense que la démarche à suivre est de comprendre pourquoi CSS lint propose ces recommandations, plutôt que de les rejeter en comparaison de sa propre expérience.

Nicole dit justement vis à vis des IDs :

"Nicole Sullivan Says:
April 28th, 2011 at 5:46 pm
IDs and descendant selectors were probably great when sites were documents and mostly uniform throughout. I think that was only the case as long as w3c specs and technical papers converted from LaTeX made up the vast majority of the web.

Actually, they are still useful now. IDs are great for JavaScript hooks into the DOM, but not for styling, and descendent selectors are fine within the nodes of any one component, as long as they don’t leak to the content area."


Par contre, elle dit aussi "In fact, in most cases, the things we considered best practices were leading to the bad outcomes we sought to avoid." dans http://www.stubbornella.org/content/2011/04/28/our-best-practices-are-killing-us/

Ce qui justifie que comme tout, il faut pondérer les recommandations.

Pour l'anecdote, Nicholas Zakas a travaillé avec Douglas Crockford, guru JavaScript et auteur de JSLint, chez YAHOO.
JSLint a provoqué les mêmes réactions à l'époque.
Puis elles ont été suivies à la lettre (ne pas utiliser == mais uniquement === en JS par exemple). Enfin, aujourd'hui elles sont contestées.
Mais pas contestées disant qu'elles n'étaient pas appropriées, mais simplement que les connaissances ayant évolué, on sait pondérer l'application des recommandations.
Aujourd'hui il est plus propre d'utiliser == que === dans certains cas bien précis.

De votre côté, quelles sont les recommandations qui vous ont choqué, et lesquelles trouvez-vous à propos?

POdy

Bonjour,

POdy a écrit :
Comme le dit si bien l'auteur : "CSS Lint : Will hurt your feelings*"

L'auteur, Nicholas C. Zakas est un ancien architecte de chez YAHOO et maintenant freelance.
Il a été co développé avec Nicole Sullivan, architecte également, auteur de http://www.stubbornella.org
....
POdy

J'allais dire quelque chose du style, mais loin d'être aussi détaillé.

Ces deux personnes, Zakas et Sullivan, sont, au jour d'aujourd'hui, des précurseurs du développement front-end.
Dans dix ans, ce qu'ils ont préconisé aujourd'hui, ils le trouveront absurde. Mais ils le font comprendre, ce qu'ils préconisent, vaut pour aujourd'hui et les quelques mois/années qui arrivent.

Stubbornella a aussi créé, avec Stoyan Stefanov, Smush it intégré aux tools de YSlow ( site mais aussi plug-in FF ).
Elle pond aussi avec quelques personnes qui ont un impact dans notre domaines, une sorte de proposition au w3c pour le futur du CSS ( je n'ai plus vraiment le lien ).
Elle est aussi l'auteur d'un framework CSS, OOCSS, plutôt sympathique, et de plusieurs articles/conf concernant sa vision du CSS en l'orientant objet ( très sympa à étudier/lire/écouter ).

Bref, moi, elle me fait rêver, zakas, je le connais moins.

POdy a écrit :

Puis elles ont été suivies à la lettre (ne pas utiliser == mais uniquement === en JS par exemple). Enfin, aujourd'hui elles sont contestées.
Mais pas contestées disant qu'elles n'étaient pas appropriées, mais simplement que les connaissances ayant évolué, on sait pondérer l'application des recommandations.
Aujourd'hui il est plus propre d'utiliser == que === dans certains cas bien précis.

C'est un peu le même soucis avec CSS Lint. Établir des règles absolues comme ça, par exemple, en disant qu'il faut toujours tester le type d'une valeur c'est complétement partial et con.

a écrit :

De votre côté, quelles sont les recommandations qui vous ont choqué, et lesquelles trouvez-vous à propos?

a écrit :

Don't use adjoining classes

Adjoining classes look like .foo.bar. While technically allowed in CSS, these aren't handled properly by Internet Explorer 7 and earlier.

Déjà je vois par comment l'auteur de l'outil peut se permettre de décider pour quels navigateurs on développe. Ensuite les classes multiples fonctionnent plutôt bien dans IE7 (en fait j'ai jamais eu d'exemple où ça ne fonctionnait pas). Et pour IE6 faut voir si on développe encore pour lui ou non.

a écrit :

Don't use too many floats

Using float for layout isn't a great idea, but sometimes you have to. CSS Lint simply checks to see if you've used float more than 10 times, and if so, displays a warning. Using this many floats usually means you need some sort of abstraction to achieve the layout.

Tout dépend de la complexité de la page et du nombre de sections. Utiliser une valeur absolue en disant : en dessous c'est bien, au dessus c'est mal, est juste ridicule. C'est du même niveau que l'exemple que tu donnes pour JS Lint.

a écrit :

Don't use too many web fonts

Web fonts are growing in popularity and use of @font-face is on the rise. However, using web fonts comes with performance implications as font files can be quite large and some browsers block rendering while downloading them. For this reason, CSS Lint will warn you when there are more than five web fonts in a style sheet.

Idem que le point précédent.

a écrit :

Don't use IDs in selectors

IDs shouldn't be used in selectors because these rules are too tightly coupled with the HTML and have no possibility of reuse. It's much preferred to use classes in selectors and then apply a class to an element in the page.

Alors là je sais même pas quoi dire...

a écrit :

Don't qualify headings

Heading elements (h1-h6) should be defined as top-level styles and not scoped to particular areas of the page. For example, this is an example of an overqualified heading:

.foo h1 {
font-size: 110%;
}

Heading elements should have a consistent appearance across a site.

Là encore une règle absolue qui ne tient pas compte des cas spécifiques.

a écrit :

Heading styles should only be defined once

Heading elements (h1-h6) should have exactly one rule on a site. CSS Lint warns if it finds more than one.

Idem.

a écrit :

Be careful using width: 100%

Using width: 100% on an element whose parent element has padding will result in the child stretching outside of the parent's bounding box. It's generally not a good idea to use width: 100%. Instead, use width: auto or display: block.

Idem.

a écrit :

Avoid selectors that look like regular expressions

CSS3 adds complex attribute selectors such as ~= that are slow. When using attribute selectors, don't use the complex equality operators to avoid performance penalties.

Idem.

a écrit :

Beware of broken box models

Borders and padding add space outside of an element's content. Setting width or height along with borders and padding is usually a mistake because you won't get the visual result you're looking for. CSS Lint warns when a rule uses width or height in addition to padding and/or border.

Celle là c'est ma préféré...
Modifié par jb_gfx (16 Jun 2011 - 15:19)

Hello,

J'arrive (longtemps) après la bataille, simplement pour donner mon avis qui est que dans un contexte de production, CSSLint a raison sur de nombreux points, voire tous. Et tout particulièrement au sujet des id.

Il faut parfois accepter de se remettre en question : http://blog.goetter.fr/post/31193037773/css-la-grande-remise-en-question

Effectivement, CSS lint est un outil, au même titre que le validator du W3C. Il vous informe uniquement, et c'est à vous de décider de suivre ou non ces recommandations.

Concernant les IDs, si vous vous amusez un tant soit peu avec des frameworks css - et même micro-frameworks - alors vous ne pouvez pas dire que cette règle est idiote puisque c'est le fondement même des frameworks css : la réutilisabilité du code. DRY, tout simplement.

OOCSS n'est pas vraiment un framework, c'est une manière d'appréhender la pratique des CSS. Et le code DRY en est la base même. CSS Lint a pour objectif de vous aider à produire des CSS DRY.

Trop de déclarations float ? Pourquoi ne pas créer vos classes right et left pour les attribuer directement, comme dans KNACSS - au hasard ?

Il s'agit d'une véritable pratique et d'une mentalité de travail que l'on souhaite appliquer ou non, personne ne vous force. CSS Lint est un outil extrêmement fiable pour qui en comprend l'utilité, si vous décidez de vous en servir appliquez ce qu'il vous dit, sinon ne vous en servez pas.