Appliquer commentaire conditionnel/hack css pour Opera? (la honte!...)

bonsoir , aucun si tu dimensionne ton div#nav a zero de hauteur , ou si tu peut l'extraire de ton template (a premiere vue , il est vide de tout élèments et est dimensionné a 100px de hauteur.

Sinon le display:none; extrait virtuellement un élèment de la page , lui et son contenu , en principe, ne sont plus affiché ou pris en compte par une majorité de médias ... qui lisent et appliquent les styles imposés .
Les médias ne supportant pas css , afficheront dans le flux tout les élèments de la page.

gc

merci, je comprend mieux l'utillité du display:none mais sur un autre point,jJe pense que tu te trompes, mon #nav n'est pas du tout vide de tout élèments , voila ce qu'il contient :

#nav{
margin-top:0px;
width:100%;
position:relative;
background:url(../images/nav.jpg) top left repeat-x;
height:100px;
z-index: 1;
}

Si je met le height a 0px, il me manque tout la bande du fond qui affiche l'image nav.jpg ...

Bonjour,

#nav ne contient rien (CSS ne gère pas de contenu).

Sa présence est en effet a piori inutile : l'image d'arrière-plan en question peut être appliquée à d'autres éléments existants par ailleurs, par exemple à un conteneur de ce qui suit.

Sinon, un remarque pour gcyrillus : diisplay:none retire un élément de la structure de formatage mais (évidemment) pas de l'arbre du document, le premier étant issu du second pour se prêter justement à ce type de manipulations. Ce qui laisse entièrement ouvertes diverses questions, notamment sur ce qu'est supposé en faire un lecteur d'écran, outil hybride au rôle actuellement indéterminé (Il lit quoi ? Ce qui s'affiche ? Le source html ? Un peu des deux à tempérament ? Et dans quel ordre, CSS ou linéaire ?)

Tiens, un truc amusant: un script client extrayant les <hn> de la page pour les afficher dans une liste déroulante ajoutée à l'affichage, pour ajouter une TOC à l'interface, doit-il tenir compte du display:none ? Oui ? Non ? zut ?
Modifié par Laurent Denis (22 Dec 2007 - 13:28)

oui, en effet, le #nav ne sert qu'a afficher une image d'arrière-plan qui pourrait être appliquée à d'autres éléments existants, mais bon...
Vous remarquerez que je vous ai écoutés et que j'ai sorti tous les tableau du haut page...c qui simplifie grandement le code...

Sinon, juste une dernière petite question, j'ai pu lire a maintes reprises...qu'il vaut mieux favoriser les positions relative et éviter surtout les margin négatifs? ...a cause d'IE6 qui n'aime pas du tout les margin/paddings négatifs...

Qu'en pensez vous?
Modifié par lerouxjul (22 Dec 2007 - 13:29)

Laurent Denis a écrit :
Ce qui laisse entièrement ouvertes diverses questions, notamment sur ce qu'est supposé en faire un lecteur d'écran, outil hybride au rôle actuellement indéterminé (Il lit quoi ? Ce qui s'affiche ? Le source html ? Un peu des deux à tempérament ? Et dans quel ordre, CSS ou linéaire ?)

Tiens, un truc amusant: un script client extrayant les <hn> de la page pour les afficher dans une liste déroulante ajoutée à l'affichage, pour ajouter une TOC à l'interface, doit-il tenir compte du display:none ? Oui ? Non ? zut ?

C'est en effet une problématique intéressante qui mériterait d'être approfondie. Je serais à priori d'avis qu'une feuille de styles en média screen devrait être ignorée par le lecteur d'écran, un mode de restitution étant prévu pour ce dernier.
La question de l'implémentation dans ces outils pointe malencontreusement une fois de plus le bout de son nez et fausse la réflexion.

Benjamin D.C. a écrit :
Je serais à priori d'avis qu'une feuille de styles en média screen devrait être ignorée par le lecteur d'écran, un mode de restitution étant prévu pour ce dernier.

Ah... screen ? reader ? Bien tenté, mais c'est au-delà de la question de l'implémentation du media screen...
Modifié par Laurent Denis (22 Dec 2007 - 14:16)

Pour préciser, une application de ce type ( donc soit étant elle-même, soit étant couplé à... un navigateur affichant quelque-chose sur un quelconque écran) doit-il:
- lire le HTML indépendamment des CSS screen (l'ordre de lecture en fonction du positionnement visuel par exemple) ?
- lire le HTML et appliquer uniquement une CSS de media speech ?
- lire le HTML et appliquer uniquement une CSS de media screen?
- lire etc. et patouiller avec un ordre de priorité entre screen et sppech ?
- faire quoi faire d'une CSS projection ?
- faire quoi d'une CSS handheld ?
- faire quoi quand il s'agit spécifiquement d'un lecteur d'écran ? Et quand il s'agit spécifiquement d'une loupe d'écran dotée de fonctionnalités vocales dont l'utilisateur est explictement dans les deux modes d'accès simultanés (visuel CSS et vocal) ? Et...

Sans compter qu'il reste à déterminer comment arbitre-t-on entre display, visibility et speack ?

Pas simple du tout.
Modifié par Laurent Denis (22 Dec 2007 - 14:27)

Laurent Denis a écrit :
Pour préciser, une application de ce type ( donc soit étant elle-même, soit étant couplé à... un navigateur affichant quelque-chose sur un quelconque écran) doit-il:
- lire le HTML indépendamment des CSS screen (l'ordre de lecture en fonction du positionnement visuel par exemple) ?
- lire le HTML et appliquer uniquement une CSS de media speech ?
- lire le HTML et appliquer uniquement une CSS de media screen?
- lire etc. et patouiller avec un ordre de priorité entre screen et sppech ?
- faire quoi faire d'une CSS projection ?
- faire quoi d'une CSS handheld ?
- faire quoi quand il s'agit spécifiquement d'un lecteur d'écran ? Et quand il s'agit spécifiquement d'une loupe d'écran dotée de fonctionnalités vocales dont l'utilisateur est explictement dans les deux modes d'accès simultanés (visuel CSS et vocal) ? Et...

Sans compter qu'il reste à déterminer comment arbitre-t-on entre display, visibility et speack ?

Pas simple du tout.

De fait.

Benjamin D.C. a écrit :

De fait.

Oui, n'est-ce pas ? C'est amusant, CSS, ça ne résoud pas grand-chose, contrairement aux apparences. ça soulève plutôt d'autant plus de questions intéressantes que ça démultiplie les moyens pertinents, en fait.

Joyeuses Pâques. zut, Noël. Enfin, joyeux quelque-chose, quoi

oula, sa vole haut, trop haut pour moi!
sinon, personne pour donner son avis la dessus...

lerouxjul a écrit :

Sinon, juste une dernière petite question, j'ai pu lire a maintes reprises...qu'il vaut mieux favoriser les positions relative et éviter surtout les margin négatifs? ...a cause d'IE6 qui n'aime pas du tout les margin/paddings négatifs...

Qu'en pensez vous?

Pardon. C'etait une apparté déplacée, pour laquelle je plaide entièrement coupable.

lerouxjul a écrit :

sinon, personne pour donner son avis la dessus...

Il n'y a pas d'avis absolu en la matière. Reposer des éléments via la position:relative ou une marge néfative est relativement rare. Parfois, avoir à le faire peut être un signe de souci dans le mode général de CSS. Parfois, c'est une astuce pertinente.

Mais sinon, l'un ou l'autre peuvent être également adaptés, sachant en outre qu'IE nécessite souvent un zest de position relative sur une marge négative, sinon ce ne serait pas drôle. Sur le fond, il est très difficile de dire quoi que ce soit tant leurs emplois sont spécifiques et liés à des contextes CSS précis.

Hum... à la réflexion, quand même, s'il fallait donner un conseil général: la marge négative est peut-être préférable a priori, dans la mesure où elle ne casse pas le flux.

MERCI BEAUCOUP pour cet avis éclairé.