5177 sujets

Le Bar du forum

Pages :
(reprise du message précédent)

Laurent Denis a écrit :

- y inclure les avancées CSS3 de Firefox et Opera pour les modules CSS3 qui ne sont pas encore implémentables (ceux qui n'ont pas atteint le stade de Candidate Recommandation) : il ne s'agit pas à proprement parler de bug, mais d'implémentations problématiques.


Je précise, car l'idée d'assimiler les bugs d'IE et les avancées CSS3 de Firefox va sans doute susciter quelques hurlements scandalisés :
- une CSS truffée de hacks pour que ça soit quand même pareil dans IE est fragile (car sans aucune garantie sur son résultat dans le prochain IE), peu lisible et difficile à maintenir en général (je modifie innocemment une valeur... Zut ! Il faut que je modifie aussi la valeur hackée, et comment il marchait, déjà, ce hack ?)
- De la même manière, une CSS fondée sur des implémentations précoces de CSS3 est fragile (quel est le résultat dans les navigateurs plus raisonnablement conformes aux normes réelles ?) et amusante à maintenir (par définition, les modules CSS3 qui n'ont pas atteint le stade de Candidate Recommandation sont susceptibles de tous les changements)

Les critères de choix sont strictement identiques :
- est-ce que j'investis (critère économique) dans un pari sur CSS3 ?
- est-ce que j'en fais une question d'esthétique (CSS3 roxor car ça me flatte et c'est amusant, ou à l'inverse, CSS3 pas bô car pas encore une norme) ?

Sont en revanche totalement exclues de ce champ les extensions propriétaires CSS conformes à CSS2.1, bien sûr.
Modifié par Laurent Denis (04 Jul 2005 - 08:20)
Salut à tous,

je suis cette discussion très intéressante depuis très loin, vu mon niveau, mais j'ai une question: à partir de quand doit-on décider que ces fameux "hacks" sont indispensables? Ne serait-il pas plus sage de "lâcher un peu de lest" en ce qui concerne le rendu voulu de notre site, quitte à se passer de ces hacks?
bouquins a écrit :
Salut à tous,

je suis cette discussion très intéressante depuis très loin, vu mon niveau, mais j'ai une question: à partir de quand doit-on décider que ces fameux "hacks" sont indispensables?


Je dirais : quand aucune alternative n'existe (autre présentation), et que la dégradation du rendu dans le navigateur en question est jugée inacceptable. Ce qui laisse chacun assumer ses choix.

bouquins a écrit :

Ne serait-il pas plus sage de "lâcher un peu de lest" en ce qui concerne le rendu voulu de notre site, quitte à se passer de ces hacks?


Oh que oui !

Mais tous les rendus liés aux capacités limitées d'un navigateur ne sont pas toujours acceptables : ils peuvent:
- être refusées par un décideur
- causer une crise cardiaque à un graphiste attaché à son OEuvre
- être une gêne pour l'utilisateur

Concrètement, la position Moi, les hacks ? Jamais ! n'est pas tenable systématiquement en production hors des sites personnels.
Modifié par Laurent Denis (04 Jul 2005 - 08:46)
Administrateur
Bien, merci à tous pour ces compléments d'informations pertinents et intéressants.
J'espère simplement que oxEz ne nous en voudra pas d'avoir beaucoup dévié de sa question initiale Smiley smile
Oh que non en fait je vous en suis reconnaissant Smiley ravi

J'ai compris le quart de ce que vous avez raconté la Smiley sweatdrop , je crois qu'il me reste beaucoup à apprendre sur ce sujet!

Merci encore! :]
Raphael a écrit :


* par définition "universel" donc pourquoi pas "qui contient tout" ?


Je dirais que * se réfère à ce qui est contenu plutôt qu'à ce qui contient

#trucmuche * --> tout ce qui est contenu dans <element id="trucmuche>

auquel cas

* {

}


signifierait "tout ce qui est contenu dans..." ah ben oui dans quoi au fait ?

C'es évident que dans la logique d'un non dit par défaut on renverrait à l'élément de plus haut niveau possible.

on aura donc

* {

}

<=>

html * {

}


ce qui dans le cadre du hack décrit donne quelque chose de franchement surprenant

html * html etc... {

}

Modifié par clb56 (04 Jul 2005 - 20:54)
clb56 a écrit :

Je dirais que * se réfère à ce qui est contenu plutôt qu'à ce qui contient


Avec ce qu'il me reste ce soir d'une connection plus que défaillante, je m'élèverai jusqu'à mon dernier octet de bande passante, au nom du comité anti-viol de spécifications innocentes, contre cette abus scandaleux !

En effet, un sélecteur simple (* ou div, ou html, etc.) ne dit rien des relations du type "contient..." ou "est contenu..." : ça n'est du tout son boulot. C'est celui des combinateurs, c'est à dire ici de l'espace.

Ces combinateurs, d'ailleurs, ne font pas intervenir la notion de "contenir/contenu", mais plutôt les relations dans l'arbre du document, c'est à dire parent/enfant, ascendant/descendant, etc.

Dans #trucmuche *, lu de droite à gauche, on a donc :
- n'importe quel élément (le sélecteur universel)
- ayant comme ascendant (l'espace)
- n'importe quel élément d'id trucmuche (*#trucmuche, ici abrégé en #trucmuche)

en revanche, dans * {}, on a:
- n'importe quel élément
-... et c'est tout ! Il n'y a aucun combinateur, et aucune notion de contenance, d'ascendance, etc Smiley cligne
- <edit>je sais, il y a une espace. Loupé : ce n'est pas un combinateur, mais une espace syntaxique optionnelle. On peut écrire *{} au lieu de * {} Smiley lol


html * {} signifie donc uniquement n'importe quel élément ayant html comme ascendant (ou contenu dans html, pour employer un langage plus intuitif)
Modifié par Laurent Denis (04 Jul 2005 - 22:21)
Laurent Denis a écrit :

html * {} signifie donc uniquement n'importe quel élément ayant html comme ascendant (ou contenu dans html, pour employer un langage plus intuitif)


hors le fait que je n'ai rien compris à ta défaillance vacillatoire, il me semble que nous disons très précisemment la même chose.

dans l'occurence indiquée, * ne dit rien de lui même (il n'est en rien un universel subsumant des parties) mais seulement de sa relation à l'élément html (tout cela qui est en état de subsumation de l'élément en question, ici html).

Ce qui est exprimé n'est donc pas un universel intégrant mais bien l'universalité de ce qui est intégré.

<edit>
de plus soyons précis : html * {} ne signifie pas n'importe quel élément mais bien "tous" les éléments et ce quelque soit le degré de parenté, 1ère, 2ème 3ème etc... génération.
</edit>
Modifié par clb56 (04 Jul 2005 - 23:21)
à Laurent Denis,

reprenons,

de deux choses l'une.

Soit tu démontres que ceci : "c'est évident que dans la logique d'un non dit par défaut on renverrait à l'élément de plus haut niveau possible."

n'a aucun sens.

Soit ma démonstration doit être admise.
Cessons donc de tergiverser !
clb56 a écrit :

de plus soyons précis : html * {} ne signifie pas n'importe quel élément mais bien "tous" les éléments...

Pourtant...
Recommandation CSS2 du W3C a écrit :

Le sélecteur universel, noté "*", est vérifié pour le nom de n'importe quel type d'élément. Il agit sur chacun des éléments de l'arbre du document.

http://www.yoyodesign.org/doc/w3c/css2/selector.html#x10
Recommandation CSS2 du W3C a écrit :

Arbre du document
C'est l'arbre des éléments qui résulte du formatage du document source. Chacun de ces éléments a exactement un seul parent, l'exception étant l'élément racine qui n'en a pas ;

http://www.yoyodesign.org/doc/w3c/css2/conform.html#doctree

La vraie question est : la synthaxe * html est-elle possible ? Attention ! Pas valide, mais possible.

Par ailleurs...
clb56 a écrit :

Soit tu démontres que ceci : "c'est évident que dans la logique d'un non dit par défaut on renverrait à l'élément de plus haut niveau possible."

n'a aucun sens.

Dans le cas d'un non dit, *{} signifie tout simplement « n'importe quel type d'élément » sans égard à sa position dans l'arbre du document ou à sa relation parent-enfant (ce n'est pas son rôle). N'importe quel type d'élément ayant vécu, vivant, ou à venir. Tout simplement. Smiley lol
Modifié par Stephan (05 Jul 2005 - 05:52)
Pour compliquer un peu (ou clarifier?), dans quel cas la syntaxe suivante serait-elle vraie ?

div * p {color: green;}

Un paragraphe contenu dans n'importe quel type d'élément lui-même contenu dans une division.

<div>
 <p>ceci est faux</p>
</div>

<div>
 <ul>
  <li><p>ceci est vrai</p></li>
 </ul>
</div>

Selon la même logique, html * body est impossible.

Alors, est-ce que l'élément html peut descendre de « n'importe quel type d'élément » ?
Merci, Stephan d'avoir relevé le flambeau face à nos petits camarades qui tentaient lâchement de pousser leur avantage pendant ma défaillance connective .

Bobe a écrit :
De l'art de couper les cheveux en quatre...


Quels cheveux ? L'arbre du document est chauve.
Modifié par Laurent Denis (05 Jul 2005 - 05:49)
Stephan a écrit :

La vraie question est : la synthaxe * html est-elle possible ? Attention ! Pas valide, mais possible.


Non la vraie question c'est la syntaxe * html a-t-elle le moindre sens ?

pour
Recommandation CSS2 du W3C a écrit :

Arbre du document
C'est l'arbre des éléments qui résulte du formatage du document source. Chacun de ces éléments a exactement un seul parent, l'exception étant l'élément racine qui n'en a pas ;

J'aurai effectivement du écrire "quelque soit le degré de descendance" au lieu de "quelque soit le degré de parenté"
Stephan a écrit :
Pour compliquer un peu (ou clarifier?), dans quel cas la syntaxe suivante serait-elle vraie ?

div * p {color: green;}



Ce n'est pas une question de faux et de vrai mais de savoir quand la propriété décrite suivant une sélection déterminée s'applique et quand elle ne s'applique pas.
Modifié par clb56 (05 Jul 2005 - 06:07)
clb56 a écrit :

Ce n'est pas une question de faux et de vrai mais de savoir quand la propriété décrite suivant une sélection déterminée s'applique et quand elle ne s'applique pas.

euh... Pourquoi tu t'acharnes sur mes exemples ? T'as rien de plus constructif à faire ? Smiley confus
Stephan a écrit :

Alors, est-ce que l'élément html peut descendre de « n'importe quel type d'élément » ?


L'élément html, nous l'avons tous appris à l'école darwinienne, descend du singe Smiley lol
Pages :