[Résolu] Import d'une feuille de style

Salut,

En consultant la FAQ et plus particulièrement la question "Link ou @import ?", il me semble que l'option la plus intéressante soit de faire comme suit :

<style type="text/css">
@import url(/styles/habillage.css) screen, projection;
</style>
<!--[if IE]>
<link rel="stylesheet" type="text/css" media="screen, projection" href="/styles/habillage.css" />
<![ endif]-->

Ainsi :

- Les vieux navigateurs tels que Netscape4 ne disposent d'aucune feuille de style, ce qui leur évite des problèmes d'affichage.
- Les navigateurs conformes disposent de la première feuille de style.
- Internet Explorer ne dispose que de la seconde feuille de style.
- Le media est correctement indiqué ce qui évite de préconiser la feuille de style à n'importe qui.
- Opera fonctionne en plein écran du fait de l'ajout du media projection.

Quelques petites questions...

Etes-vous d'accord pour l'ajout du media projection ?
Pour Safari ou IE5Mac, comment celà se passe-t-il ? Quelqu'un serait-il en mesure de tester ?

Je pense qu'il serait aussi intéressant de préciser dans la FAQ qu'en cas d'utilisation de la règle @import, celle-ci doit être indiquée avant toute autre déclaration CSS afin de ne pas altérer le rendu du document dans la plupart des navigateurs. ( çà je peux peut-être le faire ! )
Modifié par koala64 (28 Aug 2006 - 21:16)

Bonjour,

Il n'y a pas, en fait, d'option unique "préférable dans l'absolu".

Les modes de liaison des feuilles de style dépendent du type de propriétés combinées dans les styles, des choix de rendu selon les navigateurs, des capacités du CMS, des éventuels styles alternatifs, etc.

D'autre part, il ne semble pas judicieux d'inciter à écrire des feuilles de style complètes spécifiques à IE, de simples correctifs en commentaires conditionnels étant presque toujours suffisants.

Sinon, un détail: l'ajout du media projection pour IE est inutile, ce navigateur ne l'implémentant pas.

Pour la place de @import, c'est une règle de validité CSS. Mais ne pas oublier que @charset doit précéder @import lorsqu'il est également précisé.
Modifié par Laurent Denis (28 Aug 2006 - 07:20)

a écrit :
Il n'y a pas, en fait, d'option unique "préférable dans l'absolu".

Les modes de liaison des feuilles de style dépendent du type de propriétés combinées dans les styles, des choix de rendu selon les navigateurs, des capacités du CMS, des éventuels styles alternatifs, etc.

Oui, je disais surtout çà en ce qui me concerne, par rapport à ma méthode de travail ainsi qu'aux aboutissants que j'en attends. Je n'en fais pas pour autant une généralité.

a écrit :
D'autre part, il ne semble pas judicieux d'inciter à écrire des feuilles de style complètes spécifiques à IE, de simples correctifs en commentaires conditionnels étant presque toujours suffisants.

Mon problème n'est pas tant d'écrire une nouvelle feuille de style pour IE mais plus d'assurer une compatibilité ascendante. Si je passe par une balise link, NN4 va l'interpréter, ce que je ne souhaite pas et si je n'ajoute pas le type de media dans @import, j'envoie la feuille de style sur des supports inadaptés.

a écrit :
Sinon, un détail: l'ajout du media projection pour IE est inutile, ce navigateur ne l'implémentant pas.

oui, exact, petite erreur d'inattention.

a écrit :
Pour la place de @import, c'est une règle de validité CSS.

C'est vrai mais çà ne gène pas IE lorsqu'on lui met @import sans media. Cà peut prêter à confusion.

a écrit :
Mais ne pas oublier que @charset doit précéder @import lorsqu'il est également précisé.

Ok, je ne savais pas. D'ailleurs, puis-je mettre une déclaration pour chaque feuille de style importée ou est-ce que le @charset est une déclaration pour toutes les feuilles de style ?

Salut

L'utilisation de <link /> ou @import a-t-elle une influence sur la mise en cache de la feuille de style par les navigateurs ?

Sopo a écrit :
Salut

L'utilisation de <link /> ou @import a-t-elle une influence sur la mise en cache de la feuille de style par les navigateurs ?

aucune.

mmh.. bon, après mûre réflexion autour de mes sushis, je trouve cette histoire de @charset un peu bizarre.

Si je me réfère à l'indication du charset qu'on fait dans une balise meta d'un document (x)html,...

<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />

... celle-ci correspond au document courant.
Vu qu'on ne fait pas de déclaration de charset au sein d'un document CSS (équivalent à la meta), le @charset ou même la meta...

<meta http-equiv="content-type" content="text/css; charset=iso-8859-1" />
[i]( je crois bien l'avoir croisé quelquepart )[/i]

... correspond dès lors aux feuilles de style attachées. Le soucis, c'est qu'on ne dispose visiblement pas d'un attribut pour savoir à quelle feuille de style cette déclaration se rattache. Du coup, j'en déduis qu'on ne peut avoir qu'une seule déclaration pour toutes les feuilles de style.

Par ailleurs, dans un document (x)html, il est bon d'ajouter un header pour indiquer le type d'encodage du document. On pourrait en faire de même avec une feuille de style ou un script JS externe, non ?

Enfin ( sorry, je dévie un peu ), on indique le type de support auquel est destiné une feuille de style... soit. Mais pourquoi n'a-t-on pas la même chose pour une page (x)html ou un script JS ?

Ce n'est pas dit que j'ai des réponses à ces questions mais voilà, c'est juste pour dire que je ne trouve pas çà logique parfois.

Il traîne quelques tests ici et là (beaucoup n'ont pas été remis en ligne à l'occasion d'une refonte). A ma connaissance, c'est un sujet très peu traité, la plupart des CSS étant simplement cohérentes avec le jeu de caractère des documents (X)HTML (Mais on rencontre des choses amusantes dans des projets coopératifs internationalisés). Quoi qu'il en soit, la conclusion est clairement:
- comme toujours, vérifier la cohérence des en-têtes HTTP et de l'encodage réel des fichiers concernés
- pour un safe-sex optimal, utiliser la règle @charset dès qu'une CSS comporte des caractères non ASCII.
- évitez sinon d'avoir un jeu de caractère différent de celui de vos sources (X)HTML.
Modifié par Laurent Denis (28 Aug 2006 - 14:23)

koala64 a écrit :
Enfin ( sorry, je dévie un peu ), on indique le type de support auquel est destiné une feuille de style... soit. Mais pourquoi n'a-t-on pas la même chose pour une page (x)html ou un script JS ?

Pas compris ? Les informations de type de contenu et de jeu de caractères peuvent (et devraient) être données pour les fichiers (X)HTML comme pour les fichiers .js. Où est le problème ?
Modifié par Laurent Denis (28 Aug 2006 - 14:26)

koala64 a écrit :
Mon problème n'est pas tant d'écrire une nouvelle feuille de style pour IE mais plus d'assurer une compatibilité ascendante. Si je passe par une balise link, NN4 va l'interpréter, ce que je ne souhaite pas et si je n'ajoute pas le type de media dans @import, j'envoie la feuille de style sur des supports inadaptés.

Bonjour,
Dans ce cas tu pourrais simplement lier le fichier de cette façon (ça ne pose pas de problème à IE)

<style type="text/css" media="screen, projection">
@import "/styles/habillage.css";
</style>

(ici, sans url(), IE 4 sera également filtré)
Modifié par Alan (28 Aug 2006 - 14:47)

Laurent Denis a écrit :
Où est le problème ?

Ben je parlais là de l'attribut media pour une balise link. C'est quand même bien pratique pour indiquer que la feuille de style n'est destinée qu'aux écrans, à l'impression ou autres. Pour les pages (x)html ou js, on indique certes le type de contenu et le jeu de caractères mais on n'a pas moyen de limiter l'accès aux supports qui comprennent ces langages. Du coup, on peut se retrouver à envoyer ces documents sur des supports où l'interprétation ne se ferait pas (on aurait qu'un texte brut au mieux)
Modifié par koala64 (28 Aug 2006 - 14:48)

Salut Alan,

<style type="text/css" media="screen, projection">
@import "/styles/habillage.css";
</style>

Cà ne pose pas de problème de validation ?

koala64 a écrit :
Pour les pages (x)html ou js, on indique certes le type de contenu et le jeu de caractères mais on n'a pas moyen de limiter l'accès aux supports qui comprennent ces langages.

Heu... pour la partie pages (x)html, j'ai un peu de mal, conceptuellement, avec le fait d'envoyer quelque-part du HTML contenant l'instruction de ne pas accéder au HTML qu'on vient d'envoyer

Pour la partie javascript, les script externes sont ignorés par les UA qui n'implémentent pas js, sans qu'une instruction du type media ne soit nécessaire. Les scripts internes, naturellement, sont téléchargés puisqu'ils sont dans le HTML forcément téléchargé. Mais ils sont simplement ignorés. C'est, effectivement, l'un des arguments en faveur de l'externalisation (pour les mobiles, par exemple).
Modifié par Laurent Denis (28 Aug 2006 - 15:09)

Alan a écrit :

Bonjour,
Dans ce cas tu pourrais simplement lier le fichier de cette façon (ça ne pose pas de problème à IE)

<style type="text/css" media="screen, projection">
@import "/styles/habillage.css";
</style>

Si ma mémoire est bonne, on avait à peu près le point ici:
http://forum.alsacreations.com/topic.php?fid=4&tid=6312&s=%40import

koala64 a écrit :
Salut Alan,

<style type="text/css" media="screen, projection">
@import "/styles/habillage.css";
</style>

Cà ne pose pas de problème de validation ?

Aucun. Le mot-clé url, les parenthèses et les guillemets sont facultatifs en CSS2.x

koala64 a écrit :
Salut Alan,

<style type="text/css" media="screen, projection">
@import "/styles/habillage.css";
</style>

Cà ne pose pas de problème de validation ?

Il s'agit d'un bug du validateur (qui ne se produit pas avec un seul media) :
http://www.w3.org/Bugs/Public/show_bug.cgi?id=697

Laurent Denis a écrit :
Heu... pour la partie pages (x)html, j'ai un peu de mal, conceptuellement, avec le fait d'envoyer quelque-part du HTML contenant l'instruction de ne pas accéder au HTML qu'on vient d'envoyer

Ben là, j'aurais bien vu une instruction qui se trouverait dans un header et non dans le html lui-même.

header: "content-type: text/html"
header: "but-content-type: hi hi, this is not html, after all"

?
Modifié par Laurent Denis (28 Aug 2006 - 16:15)

Plus sérieusement, un document text/html est envoyé à un UA qui déclare l'accepter avec un en-tête Accept. Evidemment, il arrive souvent qu'il soit envoyé en fait par défaut à tout le monde, mais les UA n'acceptant pas text/html et ne le déclarant pas sont assez rares

oui, je me doute que çà ne court pas les rues mais vu qu'on parle recommendations, j'aurais trouvé judicieux de le prévoir... Enfin bref, on fait avec...

Laurent Denis a écrit :
header: "content-type: text/html"
header: "but-content-type: hi hi, this is not html, after all"

euh... çà, je te laisse le proposer tout seul au W3C... Je me dégage de toute responsabilité.