OK, donc dans une autre question, quelque chose a été discuté, et ce lien a été mentionné:
HTTPS: //developer.mozilla.org/fr/writing_efficient_css P>
Dans cet article, ils disent que certaines choses que je ne savais pas, mais avant que je leur demande, je devrais demander à ce sujet ... Est-ce que cela s'applique à CSS interprété par Firefox? Pardonnez mon noobness, mais je n'étais pas sûr de ce qu'ils signifiaient par Mozilla UI. (Ne me fais pas mal!) P>
Si cela s'applique, quand ils disent: P>
Évitez le sélecteur descendant! P>
Le sélecteur descendant est le plus Sélecteur coûteux en CSS. Il est terriblement chère, surtout si un la règle à l'aide du sélecteur est dans la balise ou catégorie universelle. Fréquemment quoi est vraiment souhaité est l'enfant sélecteur. L'utilisation du descendant Le sélecteur est banni dans UI CSS sans l'approbation explicite de votre peau Propriétaire du module. P>
* BAD - treehead treerow treecell { } * BETTER, BUT STILL BAD (see next guideline) - treehead > treerow > treecell { }
8 Réponses :
Un descendant pourrait être un enfant / petit-enfant / arrière-petit-enfant / etc.? Et l'enfant n'est qu'un profond? P> blockQuote>
Oui, exactement. Étant donné qu'un enfant ne peut être qu'un profond, il y a un espace beaucoup plus petit que le moteur de rendu doit rechercher récursivement pour vérifier si la règle correspond ou non. P>
et oui, cet article concerne à la fois Firefox et les navigateurs en général. La plupart (tous?) De ce qui est en elle s'applique à tout moteur de rendu de page. P>
Un "parent> enfant" n'est qu'un pas en bas, alors qu'un "descendant ancestral" pourrait être une ou plusieurs étapes. P>
Même mieux consiste à utiliser des balises "#id" dans la mesure du possible, de sorte qu'il y ait moins de recherche DOM. P>
L'UI CSS est destiné à coiffer les internes du navigateur - la boîte de dialogue Paramètres, les interfaces d'extension, etc. P>
Descendants et enfants sont différents, les enfants sont beaucoup plus spécifiques et entraînent beaucoup moins à être envisagés. P>
... comme je vous écris, je pense que j'aurais pu le comprendre. Un descendant pourrait être un enfant / petit-enfant / arrière-petit-enfant / etc.? Et l'enfant n'est qu'un profond? P> blockQuote>
En effet. p>
Une chose que je peux ajouter sur le côté efficacité des choses est la suivante:
n'utilise pas * sauf si vous voulez vraiment le dire strong>. Il est assez intensif que les règles vont et la plupart des gens pourraient s'en tirer, la spécification des éléments qu'ils veulent vraiment cibler. P>
J'ai appris cela en ajoutant une réinitialisation. Mais merci de réitérer! Je n'ai même pas réalisé que certains de ces universels décrits dans cet article étaient possibles, mais peut-être que c'était pour le meilleur hehe.
@Oli: Je sais que c'était une citation directe, mais le profanité a été signalé, alors je l'ai édité. Ridicule, je sais, mais je ne pense pas que cela prend autre chose de votre réponse.
Le problème avec le sélecteur enfant est que ce n'est pas aussi bien soutenu. Bien sûr, cela aurait pu être corrigé sur de nouveaux navigateurs. P>
Dans tous les cas, lors de la rédaction de CSS pour une page Web, ce ne sera pas ce problème. Je doute des fractions de secondes que vous économisez dans la charge de la page serait même remarquée. Cet article semble plus dirigé vers les gens qui écrivent des trucs pour le navigateur réel, pas des sites Web. P>
Tout d'abord - les suggestions de cet article sont L'application du CSS sur une page HTML moyenne est l'une des choses les plus rapides que de se produire lors du chargement de la page. mauvais - .treecell.indented {} C'est presque scandaleux em>. Cela peut conduire à des CSS plus rapides, mais qui se soucie? En supposant que vous avez déjà
En outre, l'article peut suggérer le moyen le plus rapide d'appliquer les règles CSS, mais à quel coût? Par exemple, ils suggèrent de ne pas avoir plus d'une classe par règle: p>
Bon - .treecell-indenté {} p>
blockQuote>
.treecell code> et .Nindentré code>, après ces suggestions conduit à logique compliquée em>, maintenance plus difficile, Dupliquié CSS EM > Règles, Javascript plus difficile (qui coûte beaucoup plus que CSS), etc.
Ils suggèrent pas utiliser la richesse complète des sélecteurs CSS em> et remplacent ces sélecteurs avec des classes plats, qui est une honte. P>
En fait, l'article donne "Treecell.Nindentré" non ".treecell.Doilé" comme "mauvais". Il donne un exemple générique de quelque chose comme "p.indended" et le point est "Ne qualifiez pas de règles classées par catégorie avec des noms de balises". Cela ne dit rien d'avoir plus d'une classe par règle.
@PW - Vous êtes correct. Je ne peux pas expliquer comment cela s'est passé, mais l'article a suffisamment d'exemples de ce que les gens font quotidiennement sur CSS, qui n'est pas recommandé sur XUL. Avec votre permission, je laisserai la réponse tel quel. :)
La documentation de la vitesse de la page de Google (un complément Firefox / Firebug) comprend un bonne page sur le CSS efficace . p>
Oui. Et les sélecteurs d'enfants ne fonctionnent pas dans IE6, donc si ce support est un must, vous êtes assez désossé.