Discussion :

[khayyam90]

Bien le bonjour,

Officiellement nous en sommes à CSS 2.1 qui est à peu près correctement implémenté partout et que nous (développeurs web) pouvons utiliser sans problème.
Nous pouvons donc faire des pages valides au sens du W3C, jusque là, pas de souci.

Cependant CSS 3 peut apporter des agréments intéressants, leurs implémentations ne sont pas arrêtées, leurs noms non plus. 2 solutions :
* utiliser les noms propriétaires en -moz et -webkit pour bénéficier des dernières implémentations avant-gardistes (et avoir des pages non valides)
* ne pas les utiliser et attendre la St GlinGlin et la normalisation du CSS 3 et conserver nos pages valides CSS 2.1.

Quel est votre point de vue ? Quel est votre choix ?
Je ne parle ici que des implémentations propriétaires se basant sur les futures règles CSS 3, je ne parle pas des gadgets de chaque navigateur pour faire des effets farfelus.

[kohsaka]

l'utilisation du css 3 n'a ca place que dans des poc, ou à la rigueur dans les back office, d'après moi.

un site qui se prive des visiteurs sous ie, ca fait un sacré manque a gagner.

[khayyam90]

Les navigateurs n'implémentant pas ces règles ne bénéficient simplement pas du rendu optimal, mais ils peuvent tout à fait utiliser le site web sans même savoir qu'une version plus "évoluée" du site est disponible.

L'idée n'est pas de boycotter certains navigateurs, l'idée est de proposer davantage à ceux qui peuvent le gérer. C'est sur cette démarche que je m'interroge.

[adiGuba]

Salut,


Il est en effet embêtant que le validateur génère une erreur lors de l'utilisation des propriétés spécifiques aux différents moteurs. Surtout que cela fait partie des spécifications : http://www.w3.org/TR/CSS2/syndata.html#vendor-keywords


Perso je n'ai rien contre l'utilisation des ces propriétés, tant que l'on sait ce que l'on fait et que l'on conserve une page qui de dégrade bien. C'est à dire tant qu'on obtient une page moins "joli" mais toujours correctement lisible.

L'exemple parfait étant border-radius, qui est un moyen simple et efficace d'arrondir les angles d'un élément. Dans le pire des cas l'élément n'aura pas d'angle arrondi mais c'est un moindre mal...

Par contre le choix doit bien se faire propriété par propriété, en conservant bien en tête cette notion de dégradation afin de ne pas se couper des navigateur qui ne supporterait pas cela...


a++

[kohsaka]

Les navigateurs n'implémentant pas ces règles ne bénéficient simplement pas du rendu optimal, mais ils peuvent tout à fait utiliser le site web sans même savoir qu'une version plus "évoluée" du site est disponible.

L'idée n'est pas de boycotter certains navigateurs, l'idée est de proposer davantage à ceux qui peuvent le gérer. C'est sur cette démarche que je m'interroge.

dans quel contexte veux tu mettre une telle pratique en place ? en production, si je dis à mon client que son site sera plus moche sur ie et qu'en plus ca me prendra plus de temps (ajustements supplémentaires à faire pour avoir un rendu convenable partout), je peux dire au revoir au projet.

si c'est pour une démarche personnelle, ca se rapproche du poc dans ce cas.

[khayyam90]

Ça ne se passe pas forcément dans le cas d'une livraison pour un client, ça peut être pour des sites persos ou pour des développements où on cherche simplement à faire "le mieux possible".

L'appellation "poc" ne me séduit pas, elle décrit un aspect expérimental qui n'est pas forcément présent.

Les contraintes sont simplement de réaliser un site web qui soit techniquement et esthétiquement le mieux possible.

[adiGuba]

dans quel contexte veux tu mettre une telle pratique en place ? en production, si je dis à mon client que son site sera plus moche sur ie et qu'en plus ca me prendra plus de temps (ajustements supplémentaires à faire pour avoir un rendu convenable partout), je peux dire au revoir au projet.

Ce n'est pas une question de dire qu'il sera plus moche sur IE, mais plutôt qu'il sera plus beau sur les autres navigateurs.

Après c'est sûr que si tu en abuses au point d'obtenir deux sites totalement différent c'est problématique.

Par contre si tu te contentes de rajouter un effet par-ci par là c'est tout à fait acceptable. Tu as plein d'exemple comme cela sur des gros sites. Quelques exemples :

• YouTube ou Twitter dispose de quelques arrondis supplémentaires, comme sur le bouton "Rechercher"...
• Sur Twitter le texte de certains boutons dispose d'une petite ombre.
• Sur Wikipedia, les liens vers les "Notes et références" en bas de page surligne le bloc correspondant.

Il y a surement d'autres exemple comme ceux-ci, qui ne sautent pas forcément aux yeux si on ne met pas les deux pages côtes à côtes...

a++

[khayyam90]

si tu te contentes de rajouter un effet par-ci par là c'est tout à fait acceptable

graphiquement, absolument. Mais on perd la sacro-sainte validation CSS Valid. Est-elle passée de mode ? Importe-t-elle encore à quelqu'un ?

[adiGuba]

Il reste en effet le problème de la validation...

Là dessus je ne saurais quoi dire. Perso le rendu global me semble plus important que la validation, surtout si les erreurs concernent uniquement ces propriétés non-standard.

Maintenant je comprend que cela puisse gêner

a++

[Bovino]

Salut

Déjà, les préfixes propriétaires sont bien souvent obsolètes.
A titre d'exemple, opacity est aussi bien reconnu que -moz-opacity et autres.

Ensuite, concernant la validation, mon point de vue est de savoir différencier l'esprit de la lettre.
L'esprit, ce serait de savoir si en utilisant des telles propriétés, tu commets des erreurs et tu vas à l'encontre des bonnes pratiques. Si on reprend l'exemple de opacity, peut-on considérer que gérer l'opacité d'un élément dans une page est contraire aux règles de style
La lettre, c'est est-ce que ça passe ou non la validation.
A mon sens, l'esprit est plus important que la lettre et c'est donc ce qu'il faut privilégier, quitte à se passer du logo de validation.

[adiGuba]

Déjà, les préfixes propriétaires sont bien souvent obsolètes.
A titre d'exemple, opacity est aussi bien reconnu que -moz-opacity et autres.

Ca dépend du travail du w3c.
Les navigateurs utilisent les préfixes propriétaites tant que le document associé est en "working-draft", car des changements majeurs pourraient encore survenir.

Une fois que le document passe en release-candidate, ils peuvent utiliser la version standard.

a++

[kohsaka]

Les contraintes sont simplement de réaliser un site web qui soit techniquement et esthétiquement le mieux possible.

Dans ce cas tout dépend de ce que tu appelles le mieux techniquement, car beaucoup de propriétés css3 sont réalisables sur tous les navigateurs à conditions d'être un peu astucieux.

Par contre si tu te contentes de rajouter un effet par-ci par là c'est tout à fait acceptable. Tu as plein d'exemple comme cela sur des gros sites. Quelques exemples :

* YouTube ou Twitter dispose de quelques arrondis supplémentaires, comme sur le bouton "Rechercher"...
* Sur Twitter le texte de certains boutons dispose d'une petite ombre.
* Sur Wikipedia, les liens vers les "Notes et références" en bas de page surligne le bloc correspondant.

Comme dit juste au dessus, ce genre de petits effets peuvent être proposés sur tous les browser à condition de ne pas se cantonner au css. Je reviens donc sur la notion de poc, car pour moi, limiter l'expérience de certains utilisateurs pour pouvoir utiliser des propriétés css3, c'est expérimenter.

pour la validation w3c, j'avoue m'en préoccuper beaucoup en ce qui concerne la partie HTML, mais pour le css, il ne m'est jamais arrivé de vérifier

[khayyam90]

Je suis d'accord qu'il est possible de contourner beaucoup de limitations dûes à certains navigateurs soit par des hacks bidons css, soit par des développements javascript à coup de test sur le navigateur (if(IE), if(gecko) ...).
Bien que réalisables et valides, ces hacks nous ramènent à l'age de pierre et à la bidouille. Je trouve plus élégant l'utilisation d'une propriété propriétaire quitte à laisser de côté les navigateurs qui ne l'implémentent pas ou rien de similaire.

Ta réaction sur le cantonnement au css me fait réagir puisqu'au premier abord, on essaie justement de bien séparer les effets graphiques, des données et des évènements utilisateur à autant de couches bien distinctes (html, css, js). Toute tentative de gérer un aspect par un autre non dédié (gérer un positionnement par du js par exemple) est par définition une mauvaise idée.
Je ne dis pas que ça fonctionnera moins bien ou mieux, je dis simplement que la cohérence du développement en prend un coup.

[adiGuba]

Dans ce cas tout dépend de ce que tu appelles le mieux techniquement, car beaucoup de propriétés css3 sont réalisables sur tous les navigateurs à conditions d'être un peu astucieux.

Mais les propriétés CSS3 ont l'avantage d'être très simple à mettre en place, sans avoir à bidouiller dans le code HTML.

Bien souvent ces astuces consistent à multiplier les balises pour cumuler les effets, là où bien souvent une simple propriété CSS3 suffit. Donc cela revient à "pourrir" le code (x)html pour conserver une feuille de style propre


a++

[kohsaka]

Et je suis d'accord avec toi. Je rêve que cela soit possible, mais le web évoluant constamment, je doute que ca soit vrai un jour.

Quand le html5 + css3 seront parfaitement implémentés, il est fort possible que nos besoins aient encore évolué, on entendra peut être parler de css4 et de ses fantastiques possibilités !

Toute tentative de gérer un aspect par un autre non dédié (gérer un positionnement par du js par exemple) est par définition une mauvaise idée.

Ce problème relève plus de l'interprétation des navigateurs que du css en lui même. Et a ce moment, je préfère trouver une solution intermédiaire pour ma part, plutôt que d'utiliser un hack css ou le javascript.

[kohsaka]

Mais les propriétés CSS3 ont l'avantage d'être très simple à mettre en place, sans avoir à bidouiller dans le code HTML.

Ma foi, un peu de defi dans le travail ne me dérange en rien c'est ca aussi qui est motivant.

Bien souvent ces astuces consistent à multiplier les balises pour cumuler les effets, là où bien souvent une simple propriété CSS3 suffit. Donc cela revient à "pourrir" le code (x)html pour conserver une feuille de style propre

C'est vrai que certaines solutions sont un peu imbuvable. mais du moment qu'elles restent valides, ca ne me dérange pas. C'est pour une bonne cause, mettre tout le monde sur un pied d'égalité. Tout le monde n'est pas informaticien, et on ne peut pas exiger des gens qu'ils soient à la pointe technologique en permanence

edit: Excusez le double post
Et je tiens a préciser que je ne discrédite pas vos solutions, mais que c'est juste une vision différente du web que nous avons.

[adiGuba]

Ma foi, un peu de defi dans le travail ne me dérange en rien c'est ca aussi qui est motivant.

Pour un PoC oui... En production c'est autre chose

Et je tiens a préciser que je ne discrédite pas vos solutions, mais que c'est juste une vision différente du web que nous avons.

L'idée, c'est que la recherche du "100% identique" limite fortement les possibilités. Et plutôt que de limiter "tout le monde", on peut se permettre d'offrir ces petits plus à ceux qui dispose d'un navigateur compatible...

Encore une fois je parle bien d'effet graphique et non pas de fonctionnalitée essentielle.


Quoique même de ce coté là il commence à y avoir une joli fronde anti-IE6 !


a++

[Erwan31]

Bonsoir,
s'agissant de la validation, il faut arrêter de se focaliser dessus comme si c'était un but absolu à atteindre surtout concernant la validité CSS (sauf cas syntaxique problématique comme l'oubli d'un ";" une ',' une accolade etc).

La validation n'est qu'un outil très commode dont il faut servir à titre indicatif.
Je ne suis pas entrain de dire qu'il ne sert à rien de faire valide mais
que l'invalidité assumée en connaissance de causes est parfois préférable à la validité qui n'est pas toujours synonyme de valeur ajoutée en terme de qualité web.

Ici le parser CSS ne contentera d'ignorer les extensions propriétaire, et aucune futur propriété standard ne risquant de commencer par "-",
elles ne représente donc aucun danger, si ce n'est de ralentir parfois les performances d'affichage dans le cas des propriétés Microsoft filter par exemple.

Déjà, les préfixes propriétaires sont bien souvent obsolètes.
A titre d'exemple, opacity est aussi bien reconnu que -moz-opacity et autres.

Je dirais plutôt encore minoritairement obsolète (exemple : https://developer.mozilla.org/en/CSS...lla_Extensions même si pas mal de propriétés ne sont pas encore proposés par le CSS WG), la plupart des modules n'ayant pas encore atteint le niveau de CR (Candidate Recommandation), ce dernier étant nécessaire pour que puisse démarrer la phase d'appel à implémentation.

Bien souvent ces astuces consistent à multiplier les balises pour cumuler les effets, là où bien souvent une simple propriété CSS3 suffit. Donc cela revient à "pourrir" le code (x)html pour conserver une feuille de style propre

Oui effectivement ça alourdit un peu le code mais il faut penser dans ce cas à factoriser un maximum les effets redondant (par exemple une class unique pour gérer tous les border-radius...)

Ce problème relève plus de l'interprétation des navigateurs que du css en lui même. Et a ce moment, je préfère trouver une solution intermédiaire pour ma part, plutôt que d'utiliser un hack css ou le javascript.

Non cela relève d'une simple logique de séparation Structure/contenu - Mise en forme - comportement. Il faut éviter autant que possible de mélanger les trois pour différentes raisons (accessibilité, performance, maintenance, interopérabilité, portabilité du code, compatibilité ascendante...)

[adiGuba]

la plupart des modules n'ayant pas encore atteint le niveau de CR (Candidate Recommandation), ce dernier étant nécessaire pour que puisse démarrer la phase d'appel à implémentation.

Au passage je viens de m'apercevoir que le module "borders & backgrounds" est passé en CR en fin d'année.

Donc on pourra bientôt utiliser border-radius, border-image ou les multiples background-images

Oui effectivement ça allourdit un peu le code mais il faut penser dans ce cas à factoriser un maximum les effets redondant (par exemple une class unique pour gérer tous les border-radius...)

En fait je parlais plutôt des "astuces" permettant de faire cela en CSS 2.1, qui consiste généralement à empiler plusieurs éléments pour jouer avec les marges/paddings et les images de fond...

a++

[Erwan31]

Au passage je viens de m'apercevoir que le module "borders & backgrounds" est passé en CR en fin d'année.

Donc on pourra bientôt utiliser border-radius, border-image ou les multiples background-images

Oui certainement (dans pas trop longtemps j'espère).
Après sur le fond je suis d'accord avec ce qui a été dit à propos de la dégradation élégante sur IE (avec parfois des équivalence propriétaire (filter...)). De toute façon on va pas attendre qu'IE8 (qui n'implémente presque rien de CSS3) soit très minoritairement utilisé avant d'utiliser CSS3