Surcharge de Styles - Information

**pierre_42** · 15/05/2009, 11h14

Bonjour,
Plusieurs sujets de ce forum parlent de surcharger les styles par défaut définis dans l'API Géoportail.
Deux remarques :

Modifier les propriétés définis peut parfois ne pas être heureux. Par exemple l'augmentation de la taille des polices, pour des zones difficilement lisibles, peut conduire à des débordements dont le résultat sera pire.
Si, malgré tout des surcharges doivent être réalisées il faut bien comprendre l'ordre dans lequel les informations de style sont lues. Pour cela FireBug est intéressant car il permet, pour un style, de visualiser toutes ses références en barrant celles qui sont surchargées.

Surcharger une propriété définie par l'API ne peut pas se faire par une balise <style> dans le header de la page HTML. Seule l'adjonction d'une propriété non définie fonctionne dans ce cas.

En effet la feuille de style standard de l'API, style.css, est chargée dynamiquement par l'API lors de l'initialisation, c'est à dire après que toute les directives contenues dans le header ait été traitées. C'est donc elle qui surcharge les autres définitions (si vous redéfinissez les mêmes propriétés d'un style vous constaterez avec FireBug que celles de la page HTML sont barrées et que ce sont celles de style.css qui sont actives).

La solution est de faire comme l'API un chargement dynamique d'une feuille de style, et ce, après que l'API ait chargé la sienne.

Comme, lors de l'initialisation l'API lance la fonction 'initGeoportalMap', c'est dans cette fonction qu'il faut placer le code de chargement dynamique de sa propre feuille de style par une séquence du type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
var C=document.createElement("link");
C.setAttribute("rel","stylesheet");
C.setAttribute("type","text/css");
C.setAttribute("href","mystyle.css");
document.getElementsByTagName("head")[0].appendChild(C);

Merci à Tous pour la réactivité de ce forum

**dgrichard** · 15/05/2009, 11h31

La surcharge fonctionne via <style> : les exemples de l'API utilisent ce mécanisme. Par contre, comme indiqué par pierre_42, c'est fonctionnel sur les butineurs classique qui supporte correctement le HTML/CSS/Javascript.

Vous pouvez (cher développeur) vous affranchir complètement du mécanisme initGeoportalMap() qui a été mis en place pour faciliter la prise en main de l'API. Jetez un oeil sur cette page :

http://api.ign.fr/geoportail/api/doc...eur/setup.html

en particulier, le paragraphe "Développement avancé avec l'API (à partir de la version 1.0beta4)" qui vous propose en n'utilisant pas le paramètre instance de faire votre propre callback onload.

Pour les plus courageux, vous pouvez même développer un nouveau viewer ...

**cmail** · 15/05/2009, 11h49

Question divergente intéressante.
Si on surcharge un style, doit-on le faire impérativement entre les balises <style> du fichier html contenant l'API, comme l'affirme dgrichard?
ou peut-on renvoyer simplement nos modifs dans un fichier CSS avec un <link> adequat dans le <head> du fichier html contenant l'API comme je le suppose?

**dgrichard** · 15/05/2009, 12h11

Les deux fonctionnent :
- en terme de développant et donc pédagogique, j'utilise l'insertion <style> dans le code pour bien montrer que c'est possible et comment;
- en production, l'utilisation d'un fichier CSS est recommandée;

J'ai mis en place une option theme (comme OpenLayers) dans Geoportal.Viewer qui permet de faire cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
        ...
        // load user's theme :
        if (options.theme) {
            this.theme= options.theme;
            var cssNode= this._loadCSS(options.theme);
        }
        ...

A la création du viewer, il suffit d'ajouter l'option theme avec l'URL de la CSS :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
        ...
        theme: 'http://mon/url/vers/mon/theme/theme.css
        ...

Mais, dans ce cas il faut écrire son propre callback onload (j'ai donné les info pour cela).

**pierre_42** · 15/05/2009, 12h21

Bonjour dgrichard,
En réalité les exemples de l'API surchargent les styles prédéfinis afin de définir de nouvelles propriétés et non pour modifier celles définies en standard. Dans ce cas le traitement des styles fait bien le complément.

Par contre la balise <style> ne permet pas de modifier une propriété définit dans la feuille de style de l'API.

Un test simple:

.nameScale correspond à la zone d'affichage dans la boite à outils des étiquettes Monde Pays Dépt ......

L'API définit ce style par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
    .nameScale {
        float:left;
        height:100%;
        left:5px;
        top:5px;
        width:35px;
   }

Si on introduit une modification de ces propriétés dans la balise <style>, par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
    .nameScale {
        float:left;
        height:100%;
        left:5px;
        top:5px;
        width:38px;
   }

Et que l'on lance FireFox3 sur cette page on constate (avec FireBug) que toutes les propriétés définies dans la page HTML sont barrées, y compris width qui a été modifiée et que ce sont celles de style.css qui sont actives.

C'est pourquoi je pense que, même avec les butineurs classiques, on ne peut avec la balise <style> que définir de nouvelles propriétés pour un style donné mais pas modifier celles définies par l'API dans style.css

**dgrichard** · 15/05/2009, 12h37

Envoyé par pierre_42

C'est pourquoi je pense que, même avec les butineurs classiques, on ne peut avec la balise <style> que définir de nouvelles propriétés pour un style donné mais pas modifier celles définies par l'API dans style.css

Effectivement 100% d'accord

Mais ceci ne fonctionnerait-il pas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
.nameScale {
    width:38px!important;
}

Certains des exemples "surchargent" de cette manière un style existant de cette façon si j'ai bonne mémoire.

**pierre_42** · 15/05/2009, 13h04

Effectivement l'utilisation de !important dans la balise <style>:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
.nameScale {
    width:38px!important;
}

permet de modifier l'ordre de prise en compte des surcharges de style et permet de donner la priorité à la valeur donnée dans la balise <style> (à condition que la dernière feuille de style chargée, en l'occurrence style.css, ne l'utilise pas aussi!)

J'ai fait le test en chargeant dynamiquement une feuille de style monstyle.css comme indiqué dans mon premier message (dans la fonction 'initGeoportalMap')

Si dans monstyle.css j'ai aussi la caractéristique !important c'est cette valeur qui est retenue
Si dans monstyle.css !important n'est pas précisé c'est la valeur définie dans la balise <style> qui elle comporte !important qui est retenue.

**pierre_42** · 15/05/2009, 14h49

Pour cmail

En réalité il n'y a pas de divergence fondamentale entre les réponses de dgrichard et les miennes.

Mais il n'y a pas non plus de solution impérative ou simple!

Il faut surtout bien comprendre le mécanisme de cascade entre les définitions, compléments ou surcharges des styles. S'il s'agit de compléments (définition de propriétés non précisées par ailleurs) il n'y a pas de problème et le mécanisme de traitement des styles fera l'union de toutes les propriétés. Le problème se pose en cas de surcharge d'une propriété.

Pour schématiser, le dernier qui parle a raison!

Voici un exemple de header de page HTML :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>Test Geoportal</title>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
    <script type="text/javascript" src="http://api.ign.fr/geoportail/api?v=1.0beta4-e&amp;key=KEY&amp;instance=viewer&amp;"> </script>
    <link rel="stylesheet" type="text/css" href="monstyle.css" />
    .........
    <style>
    ........
    </style>
</head>

Dans cet exemple la balise <script> va permettre de charger l'API et de transmettre la clef, mais pas de charger la feuille de style standard de l'API.

La balise <link> va charger la feuille de style 'monstyle.css'

La balise <style> va définir de nouveaux styles ou modifier (surcharger) ceux définis dans 'monstyle.css'

Ce qu'il faut savoir c'est que l'API va charger sa propre feuille dynamiquement en fin de lecture du header lors de l'initialisation. Elle va donc surcharger tout ce qui a été précédemment défini, aussi bien dans le <link> que dans le <style>

Ce fonctionnement en cascade des définitions de style se trouve complexifié par la possibilité de préciser la caractéristique !important sur certaine valeurs. Cette caractéristique modifie le traitement de la cascade en ignorant toute modification ultérieure de cette propriété SAUF SI LA MODIFICATION ULTERIEURE POSSEDE AUSSI LA CARACTERISTIQUE !important (la cascade s'effectue alors entre les valeurs caractérisées !important et c'est la dernière lue qui l'emporte)

En résumé il est possible d'utiliser aussi bien la balise <link> que la balise <style> (personnellement je préfère la solution <link> afin d'avoir un fichier de style plutôt que d'encombrer le code HTML). Mais dans ce cas il faut préciser la caractéristique !important pour éviter que ces définitions soient surchargées par l'API.

L'autre solution est de venir charger sa propre feuille de style APRES que l'API ait chargé la sienne afin de la surcharger. Je suppose, je ne l'ai pas testé, que c'est ce qui est fait par l'option theme préconisée par dgrichard. Pour ma part j'ai introduit ce chargement dans ma fonction 'initGeoportalMap' puisque celle-ci est exécutée lors de l'initialisation et après que l'API ait chargé sa propre feuille de style.

NOTA: l'utilisation de FF3 et de FireBug est très utile car ceci permet de visualiser tous les endroits ou un style est défini/modifié et FireBug barre toutes les propriétés surchargées.

**Unusual** · 15/05/2009, 16h03

Envoyé par dgrichard

La surcharge fonctionne via <style> : les exemples de l'API utilisent ce mécanisme. Par contre, comme indiqué par pierre_42, c'est fonctionnel sur les butineurs classique qui supporte correctement le HTML/CSS/Javascript.

Vous pouvez (cher développeur) vous affranchir complètement du mécanisme initGeoportalMap() qui a été mis en place pour faciliter la prise en main de l'API. Jetez un oeil sur cette page :

http://api.ign.fr/geoportail/api/doc...eur/setup.html

en particulier, le paragraphe "Développement avancé avec l'API (à partir de la version 1.0beta4)" qui vous propose en n'utilisant pas le paramètre instance de faire votre propre callback onload.

Pour les plus courageux, vous pouvez même développer un nouveau viewer ...

Sur la page indiquée :

Des modèles de développement sont présents là :

* Développement en local ;
* Développement en production.

Les deux liens ne débouchent sur rien (404 not found)

Par contre, cela m'intéresse qu'il n'y ait plus d'appel "automatique" dans le onload() qui peut être déclenché souvent dans mon cas en ASP.NET. J'ai du me débrouiller pour contourner le pb, sinon la carte se réinitialisait intempestivement lors de rafraichissements autres...

**dgrichard** · 15/05/2009, 16h19

Envoyé par Unusual

Les deux liens ne débouchent sur rien (404 not found)

Par contre, cela m'intéresse qu'il n'y ait plus d'appel "automatique" dans le onload() qui peut être déclenché souvent dans mon cas en ASP.NET. J'ai du me débrouiller pour contourner le pb, sinon la carte se réinitialisait intempestivement lors de rafraichissements autres...

Je viens encore de cliquer dessus et ils fonctionnent. D'autres internautes ont ce problème ? J'ai mis les deux fichiers en pièces attachées à la réponse.

Sur le onlad() les exemples montrent comment faire.

**pierre_42** · 15/05/2009, 16h23

Envoyé par Unusual

Les deux liens ne débouchent sur rien (404 not found)

Il semble en effet qu'il y ait une erreur d'adressage sur ces liens.

Par contre les deux exemples sont accessibles en allant dans:

Exemples Geoportal Bêta (dans le bas de la liste en haut à gauche)

et dans la liste des différents exemples ce sont les deux derniers qui en fait pointent sur des .txt et non des .htlm

**pierre_42** · 15/05/2009, 16h29

Nos réponses ce sont croisées.

Il y a effectivement un problème avec les liens qui figurent dans la partie texte:

http://api.ign.fr/geoportal/doc/exam...ssed_local.txt

alors qu'il devrait être :

http://api.ign.fr/geoportail/api/doc...ssed_local.txt

Même chose pour le second

Surcharge de Styles - Information

IGN API Géoportail

Discussions similaires

Partager

Partager