Sont Minifiers CSS qui combinent des éléments destructeurs?
https://stackoverflow.com/questions/7811395
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
J'ai trouvé ce CSS minifier ( http://www.lotterypost.com/css-compress.aspx ). Il y a une section au bas de cette page intitulée « Qu'est-ce que le compresseur CSS volontairement pas faire? » Il y a quatre choses, deux dont je ne comprenais pas pourquoi ils pourraient être destructeurs:
La combinaison de marge individuelle, rembourrage, ou les styles de bordure dans une seule propriété.
margin-top: 10px;
margin-right: 0;
margin-bottom: 8px;
margin-left: 30px;
Devient
margin: 10px 0 8px 30px;
Et la combinaison de styles pour le même élément qui sont spécifiés dans les différents blocs de style.
#element {
margin: 0;
}
#element {
color: #000000;
}
Devient
#element {
margin: 0;
color: #000000;
}
Je pense que CSSTidy fait les deux. La page Web ci-dessus correcte? Y at-il des situations où ces types de minification pourraient être un problème?
La solution
Je suis le développeur du compresseur CSS qui fait l'objet de cette question ( http: / /www.lotterypost.com/css-compress.aspx ), donc je vais élaborer un exemple de la façon dont un compresseur peut briser la cascade CSS si un outil agressivement ré-écrit il.
Il y a plusieurs façons de cibler les éléments dans une feuille de style, et parce qu'un compresseur CSS n'a pas une connaissance intime de la structure DOM de la page, les classes, ids, etc., il n'y a aucun moyen pour un compresseur de savoir si une optimisation qui traverse les définitions bracketing briser ou non.
Par exemple, une structure simple HTML:
<div class="normal centered">
<p>Hello world.</p>
</div>
Et certains CSS:
div.normal p {
margin: 10px 0 10px 0;
}
div.centered p {
margin: 10px auto;
}
div.normal p {
margin-bottom: 5px;
}
Le code non compressé produirait un paragraphe centré avec une marge supérieure de 10px et une marge inférieure 5px.
Si vous exécutez les styles CSS à travers le compresseur CSS, vous aurez le code suivant, qui maintient l'ordre et cascade des styles non compressés d'origine.
div.normal p{margin:10px 0}div.centered p{margin:10px auto}div.normal p{margin-bottom:5px}
Disons que vous voulez compresser agressivement les styles plus loin, en combinant les marges des deux div.normal p définitions. Ils ont tous deux exactement le même sélecteur, et ils semblent le style de la marge du bas de manière redondante.
Il y aurait deux façons de combiner les marges: vous pouvez combiner les deux définitions de marge dans la première (en haut) div.normal p le style ou les combiner dans le dernier (en bas) un. ESSAYONS les deux sens.
Si vous combinez les marges dans le premier (en haut) div.normal p style, vous obtenez ceci:
div.normal p{margin:10px 0 5px}div.centered p{margin:10px auto}
Le résultat de la combinaison des marges de cette façon entraînerait la marge inférieure étant mal réglée à 10px, parce que la classe « centrée » emporterait la marge inférieure (parce que le « décentré » le style défintion apparaît maintenant plus tard dans la cascade).
Si vous combinez les marges dans le dernier (en bas) div.normal p style, vous obtenez ceci:
div.centered p{margin:10px auto}div.normal p{margin:10px 0 5px}
Le résultat de la combinaison des marges de cette façon entraînerait le paragraphe n'apparaît plus comme centrée, parce que la définition de « p » inférieur emporterait sur les marges gauche et droite de « auto » qui sont définis dans la classe « centrée ».
On peut donc voir qu'en combinant les définitions de style qui ont même le même sélecteur exacte peut causer des problèmes assez mauvais.
écririez-vous personnellement jamais un code comme celui-ci? Peut etre ou peut etre pas. En raison des différentes règles « poids » de la cascade, il est possible de tomber dans ce type de piège de code sans jamais en rendre compte.
En outre, compte tenu du fait que dans les pages Web d'aujourd'hui, plusieurs fichiers CSS sont souvent combinés en un seul fichier pour frapper le serveur avec moins de téléchargements, il est facile d'imaginer le CSS compresseur vissage royalement la cascade par style multiples ré-écriture feuilles (éventuellement écrites par des personnes différentes) qui sont ajoutés ensemble dans un seul fichier.
En fait, je l'ai écrit le CSS Compressor pour ce scénario très sur mon site Web, Loterie Poster . Chaque page Web a de nombreuses feuilles de style supportant divers jQuery et d'autres composants, et le CSS compresseur est utilisé pour compresser automatiquement toutes les feuilles de style en un seul téléchargement. Toutes les pages du site ont au moins 10 combinés ensemble des feuilles de style différents, et la plupart des pages ont plus que cela.
Par exemple, si vous regardez le code derrière la page du compresseur CSS lui-même, vous trouverez la feuille de style principale dans la tête qui ressemble à ceci:
<link rel="stylesheet" href="http://lp.vg/css/d11019.0/j2HKnp0oKDOVoos8SA3Bpy3UHd7cAuftiXRBTKCt95r9plCnvTtBMU2BY2PoOQDEUlKCgDn83h16Tv4jbcCeZ(gupKbOQ9ko(TcspLAluwgBqrAjEhOyXvkhqHA(h5WFDypZDK2TIr(xEXVZtX7UANdFp6n1xfnxqIMR8awqGE)vrwUgY2hrCGNNTt1xV7R1LtCSfF46qdH1YQr2iA38r1SQjAgHze(9" />
Le gobbledeegook dans l'URL est en fait une chaîne cryptée contenant toutes les feuilles de style pour combiner sur le serveur. Le serveur les compresse et met en cache le résultat.
Les techniques et d'économie spatiaux temps sur cet appel de la feuille un style comprennent:
- La combinaison de feuilles de style en un seul fichier / téléchargement en les ajoutant simplement tous ensemble
- Compresser la feuille de style combiné utilisant le CSS compresseur (sans déconner la cascade!)
- L'utilisation d'un nom de domaine différent (de lp.vg) pour la feuille de style téléchargement, ce qui améliore la capacité du navigateur à télécharger en parallèle
- L'utilisation d'un très court nom de domaine (lp.vg)
- la compression Gzip est appliquée à la feuille de style sur le serveur Web
- Le numéro de version de la feuille de style est intégré dans l'URL ( « ... / d11019.0 / ... ») de sorte que si un style est changé dans l'un des multiples feuilles de style, je peux changer la version nombre et le navigateur ne sera jamais utiliser la version qu'il a mis en cache. (Notez que le numéro de version doit faire partie du chemin d'URL, pas dans la chaîne de requête, car certains serveurs proxy ne regardent pas la chaîne de requête pour déterminer si une page doit être extrait du cache.)
J'espère que cela explique mieux les choses et est utile pour ceux qui cherchent à améliorer les performances de la page!
-Todd
PLUS D'INFO:
Pour ajouter à ce qui précède, imaginez si nous prenons votre exemple de couleur, et de combiner les définitions de style avec les mêmes sélecteurs.
Voici quelques styles non compressés:
div.normal p {
margin: 10px 0 10px 0;
}
div.centered p {
margin: 10px auto;
color: blue;
}
div.normal p {
color: black;
}
Le CSS compresseur produit la sortie suivante:
div.normal p{margin:10px 0}div.centered p{margin:10px auto;color:blue}div.normal p{color:#000}
Si nous appliquions agressif combinant des définitions de style qui ont le même sélecteur, nous allons obtenir le code suivant.
Méthode 1 , combinant à la fois dans la première définition, ferait de manière incorrecte la couleur bleue du texte:
div.normal p{margin:10px 0;color:#000}div.centered p{margin:10px auto;color:blue}
Méthode 2 , combinant à la fois dans la seconde définition, ferait de façon incorrecte le texte aligné à gauche:
div.centered p{margin:10px auto;color:blue}div.normal p{margin:10px 0;color:#000}
Le seul combinant les définitions de style avec le même sélecteur est 100% sans erreur lorsque les définitions apparaissent directement l'un après l'autre, mais dans tous les cas cette technique des risques corrompant la cascade des styles.
Je ne pouvais pas imaginer un cas où tout développeur écrirait le code de cette manière (deux définitions de style avec exactement le même sélecteur, un immédiatement après l'autre), je conclus que le montant de l'effort nécessaire pour le code, et la possibilité d'un autre point de défaillance dans le compresseur, était pas la peine d'un long-shot.
Franchement, je serais très inquiet au sujet d'un compresseur CSS que les styles combinés de différents blocs de définition, parce que la cascade est une chose très fragile, et il est extrêmement facile de briser la cascade.
Autres conseils
La page a une section sur « raison de ne pas utiliser » qui décrit pourquoi il ne fait pas ces deux choses .
Et en plus de cela, je suppose qu'il ne cherche pas à faire ces choses parce qu'il est pas un analyseur CSS complet / interprète, et commencerait à des choses comme Bork CSS blocs conditionnels.
Par « destructrice » Je suppose que vous voulez dire «le CSS ne fonctionne pas comme prévu.
La combinaison de règles à long main comme votre premier exemple peut se faire sans aucun mauvais effet du tout.
Dans une ancienne plaine stylesheet sans blocs de médias ou d'autres choses de fantaisie, le second exemple également ne posera aucun problème.
La raison # 2 est risqué parce que changer l'ordre des règles ou des règles de pliage ensemble sans prendre en compte la cascade, peut entraîner des cassures.
Certains compresseurs CSS peuvent modifier l'ordre des règles par ordre alphabétique ou par type de sélection. Ce sont très risqué parce que les règles qui se déplacent peuvent se casser en cascade behavour l'auteur créé.
Minifiers comme le compresseur YUI ne font aucun d'entre eux, en optant pour des stratégies plus sûres comme la suppression des espaces, des points-virgules redondants et des zéros, et autres.
Avec plus CSS contenant des blocs de médias et autres codes CSS3 il est probable que bon nombre des compresseurs CSS courant ne fonctionnera pas correctement du tout. La plupart ne disposent pas d'un bon lexer pour analyser le code - ils utilisent le contexte courant octet par octet (Tidy) ou regexs (la plupart du reste) pour traiter le code
.Lors de la sélection d'un compresseur, je suggère de trouver quelque chose qui va le faire localement et avalisés avec la suite bon test afin que vous puissiez voir ce cas sont (et ne sont pas) gérées correctement.
