47 votes

Pourquoi tous les navigateurs téléchargent-ils tous les fichiers CSS - même pour les types de média qu’ils ne prennent pas en charge?

Si je spécifie un lien CSS avec un unsupported media type ("bork"), il obtient toujours téléchargé par tous les navigateurs que j'ai essayé (y compris à la fois de bureau et de plusieurs navigateurs mobiles).

<link href="bork.css" media="bork" rel="stylesheet" type="text/css" />

Et il y a pire...

Si le fichier bork.css @imports un autre fichier CSS (également avec un unsupported media type) que le deuxième fichier CSS aussi est téléchargé.

/* Inside "bork.css" */
@import url("bork2.css") bork, bork;

Pourquoi!?

Ma première hypothèse était que certains navigateurs peuvent être à la recherche pour imbriquée @imports ou @media blocs avec des types de médias qu'ils ont pris en charge - et ensuite appliquer les règles de style contenues dans ces fichiers...

/* Inside "bork2.css" */
@import url("all.css");
@media all {
  /* rules */
}

...mais s je peux dire, pas un seul navigateur. (Heureusement, car ce serait un bug.)

Donc, le téléchargement semble totalement redondant - à moins qu'il y a une explication que j'ai manqué tout au long.

EDIT: Ce que j'essaie de comprendre, c'est que motive les éditeurs de navigateurs pour y aller:
"Hey! Nous essayons de faire de notre navigateur fou rapide! Nous allons télécharger un tas de fichiers CSS que nous n'avons pas l'intention de l'appliquer, et de stopper le chargement de ressources en attendant!"

13voto

Jason Gennaro Points 20848

Je pense que la réponse est celle-ci:

Les navigateurs sont autorisés et encouragés à analyser media descripteurs - quel que soit le descripteur - comme un moyen de rendre le futur

Les futures versions de HTML peuvent introduire de nouvelles valeurs et permettra peut-être paramétrée des valeurs.

*À partir de: http://www.w3.org/TR/html4/types.html#h-6.13

De cette façon, les médias peuvent un jour, 3d-glasses ou d'autres descripteurs, y compris bork ;-)

EDIT:

La dernière CSS3 spec sur les requêtes de média dit, qui prend en charge ci-dessus, à un certain degré:

Inconnu des médias les types de la valeur false. Effectivement, ils sont traités de manière identique à connu types de médias qui ne correspondent pas à la type de support de l'appareil.

*À partir de: http://dev.w3.org/csswg/css3-mediaqueries/#error-handling

Ils sont donc traités comme connu et téléchargés pour être utilisé, tout simplement pas en ce temps/pour ce périphérique.

9voto

Steve Points 81

Penser que la vraie raison pour qu'ils charge toutes les demandes des médias est parce que de nombreux dispositifs de MODIFIER leurs réponses à ces requêtes après la charge.

L'imagerie d'un iPhone5 qui est en portrait au chargement de la page (reporting 'largeur' comme 640px, mais pas le portrait, malheureusement l'iSeries ne prennent pas en charge les requêtes)... ensuite, vous décidez d'activer l'iPhone sur le côté, et le navigateur s'active désormais le pseudo mode paysage (encore une fois, déclenchée à partir de la largeur @ 1126 plutôt que de "paysage").

Le plus probable, un responsive web design a été conçu pour nourrir différentes feuilles de style, à un navigateur affichant à 640 (plutôt étroit, probablement un téléphone/tablette) qu'il n'en faut à un navigateur affichant à 1126 (plus probablement un ordinateur portable).

Si elle n'avait pas pris la peine de charger le support supplémentaire de la requête feuilles, alors il serait tout d'un coup à s'arrêter, tirer une requête http, attendre que la feuille de charge, puis de l'analyser pour l'affichage. Cela pourrait entraîner une assez moche retard.

Comme la plupart des navigateurs suivent un modèle de réutilisation de code, et la base de morceaux de Webkit ou Gecko, par exemple, peuvent ne pas être conscients qu'ils sont sur un ordinateur portable ou une tablette (comme si ces lignes ne sont pas en train d'effacer toute façon), il suffit simplement de charges de chaque média requête de indépendamment de si oui ou non ils choisir de l'afficher.

Tout cela permet d'économiser chaque navigateur à partir à la recherche de mauvais, dans l'ensemble il se casse une bonne partie de l'utilitaire derrière les media queries.

Un téléphone cellulaire ou un cheap android tablet ne devriez pas avoir à télécharger les fichiers supplémentaires (en particulier sur des données limitées, les plans) qu'il va tout simplement jamais besoin.

Pour le moment, mes dessins NE l'utilisation des media queries, mais je les utilise avec parcimonie. La plupart des médias queryishness sur mes sites est mis en œuvre à l'aide de javascript au chargement des fichiers requis pour éliminer ces déchets. Le restant des requêtes sont utilisés dans les cas de javascript étant fermé, ou pour les feuilles qui doivent être chargés "au cas où" (mon 640px de mise en page, par exemple, est généralement toujours chargées, comme la plupart des appareils peuvent afficher dans une situation ou d'un autre).

Si quelqu'un à mieux, plus propre, la méthode de manipulation, s'il vous plaît laissez-moi savoir.

En attendant, si vous pouvez penser à un simplement pour implémenter des fonctionnalités qui pourraient contourner cela (peut-être android de style se manifeste intégré dans les navigateurs?), vous pourriez laisser tomber une ligne à l'Mozilla ou Chrome équipes... semblent comme ils pourraient utiliser une main sur celui-ci.

4voto

Már Örlygsson Points 6861

Après avoir réfléchi sur cette de plus, je me suis formée à la théorie qu'il pourrait être une "règle" à travail - que toute feuille de style, l'image ou le script sera téléchargé, sans poser de questions, quel que soit le mime spécifié-type de média ou d'attribut.

Cependant, après un rapide test, les résultats sont un peu ambiguë...

  1. <script src="bork.js" type="bork/bork"></script>
  2. <script src="bork2.js" type="text/bork"></script>

Chrome 12 téléchargements ni.
IE8 téléchargements #2.
Firefox 4 téléchargements à la fois.
Opera 11 téléchargements à la fois.
Safari 5 Gagner downlads à la fois.

Toujours pas de l'analyse ou de l'exécution a lieu dans l'un des navigateurs. Un javascript alert(); à l'intérieur de fichier ne fonctionne pas. Et c'est un peu différent de la CSS cas de charge, car les navigateurs analyser l' bork-media code CSS pour @include des directives et des téléchargements de ces ressources de manière récursive.

1voto

Donal Fellows Points 56559

Parfois, il est nécessaire de considérer la prosaïque réponse. Il est possible que toutes les feuilles de style sont téléchargés par les navigateurs, tout simplement parce que les auteurs de chaque navigateur n'est vraiment envisager le cas où il existe une unique (maître) de la feuille de style lors de l'optimisation de la vitesse, et la pratique de beaucoup de sites d'une seule feuille de style encourage ce comportement. Si personne n'est à l'essai pour elle, c'est presque certainement pas une affaire qui est en cours d'optimisation, car les gens préfèrent pour travailler sur les résultats qui sont visibles (ou au moins mesurable). Peut-être que votre question sera d'encourager quelqu'un à changer le régime d'essai...

Aussi, je me risquerais que l'écrasante majorité des sites de " feuilles de style sont des documents statiques, et donc capable d'être très fortement mis en cache (et livrés par le CDN trop, si les propriétaires de site choisir de payer).

1voto

Knu Points 8385

La seule raison logique à laquelle je peux penser est que lorsque vous modifiez de manière dynamique (javascript) la valeur de l'attribut défectueux de l'élément <link> élément reconnu, le fichier doit être disponible immédiatement.
En fait, dans certains cas, cela pourrait être considéré comme une fonctionnalité si vous voulez charger le fichier mais différer son appliance pour plus tard.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X