Pour ou contre la normalisation d’un hack propre ?

Bonjour à tous,

Faisant face régulièrement aux spécificités (pour ne pas dire bugs) des différents navigateurs, je me demandais s’il n’était pas temps de lancer une pétition visant à obtenir du W3C la normalisation d’un hack propre. Il s’agirait de normaliser la possibilité de nourrir les différents navigateurs de pans de code spécifique à chacun, pour simplifier la vie des webmasters et accroître la pérennité de leurs travaux.

Les bugs et imperfections dans l’application des normes par les navigateurs sont un fait naturel incompressible, y compris de la part des projets réputés. Par ailleurs il existe toujours quelques des cas de figure pour lesquels les normes laissent aux navigateurs une certaine liberté d’interprétation pouvant en théorie conduire à un comportement marginal. Enfin le futur ne pourra que ressembler au présent en la matière, puisque les bugs régulièrement corrigés feront naturellement place aux petits nouveaux à venir lors de l’application de normes récentes (on peut penser aujourd’hui à CSS3, SVG, MathML, XFORMS…).

Le bug étant donc un fait de société incontournable, pourquoi n’a –t-il pas été pris en compte par le W3C ? Il serait bien pratique de disposer d’un mécanisme officiel, fiable et propre permettant de communiquer à chaque navigateur des portions de code spécifique lorsque cela est nécessaire pour contourner un défaut ou imposer une dégradation acceptable. Ce pourrait être quelque chose proche des commentaires conditionnels à la Microsoft. Nous avons déjà :

<!--[if lt IE 7]>
fragment destiné à IE6 et inférieur
<![endif]-->

Nous pourrions avoir :

<!--[if = FF 1]>
fragment destiné à Firefox 1
<![endif]-->

ou 

<!--[if gt OP 6]>
fragment destiné à Opéra 6+
<![endif]-->

Chaque navigateur appliquant le mécanisme normalisé aurait simplement à publier son identifiant et une règle de description des versions.

Qu’en pense–t-on sur Alsacreations ?
Modifié par Xavier (03 Oct 2005 - 21:30)

Hum... Bon... À un moment, l'argument principal en faveur des standards était qu'il n'est plus (normalement) nécessaire de développer deux versions de chaque page: une pour "IE5.5 et supérieurs" et une pour "Netscape et compatibles". C'est tout l'intérêt d'une norme.

Le mécanisme que tu proposes reviendrait à faire une version (ou une adaptation) par navigateur, voire pire: par version de navigateur ! Au final, tu ré-utilises les octets que tu avais économisés en passant au design table-less et tu as un code qui est tout sauf indépendant de la plateforme et du logiciel (principe de la norme).

De plus, il faudrait normaliser ceci. La solution que tu proposes servirait à contrebalancer le fait que l'implémentation des normes dans les navigateurs est lente (temporellement). Mais ta solution doit également être implantée. C'est le serpent qui se mord la queue..

Je suis contre. Par contre, tu peux proposer un patch à Microsoft pour son IE ou aider à l'implémentation de CSS2 et 3 dans Gecko ou KHTML.

Voilà. @+, HoPHP

HoPHP a écrit :
Le mécanisme que tu proposes reviendrait à faire une version (ou une adaptation) par navigateur, voire pire: par version de navigateur

Non ça ne reviendrait pas à ça. Car il n'y aurait bien entendu pas d'obligation d'utiliser ce mécanisme , et certainement pas sur l'ensemble du code, mais seulement là où le webmaster rencontre un problème, et juge qu'il peut le résoudre en envoyant un code modifié.

HoPHP a écrit :
La solution que tu proposes servirait à contrebalancer le fait que l'implémentation des normes dans les navigateurs est lente (temporellement). Mais ta solution doit également être implantée. C'est le serpent qui se mord la queue

Non je ne crois pas. L'existence de bugs est un fait qui ne varira pas dans le temps puisqu'il y aura toujours de nouvelles adaptations à implémenter dans les navigateurs, alors que l'implémentation du mécanisme proposé est à faire une fois, et en dépis du temps que cela pourrait prendre, il a un terme fini.

Bonjour,

C'est un sujet et une tentation qui reviennent régulièrement. Parfois, il s'agit de réclamer un bug de parsing CSS officiel dans chaque navigateur, comme lors de la sortie du premier Safari. Parfois, il s'agit d'étendre les commentaires conditionnels Microsoft.

Mais les effets n'en sont que rarement mesurés.

Dans le cas des commentaires conditionnels, ce qui est utile et gérable pour les différentes version d'un navigateur unique, dominant le marché, aura de tout autres effets en étant systématisé en tant que fonctionnalité requise pour tous les navigateurs.

On reviendrait effectivement à une discrimination des contenus par id de navigateur, et non plus par capacité de l'agent utilisateur, quel que soit son id précis. Avec toutes les échecs de gestion à terme des versions sucessives de navigateurs en nombre indéterminés, et toutes les dérives possibles.

Bien-sûr, ce n'est pas comme cela qu'on envisage l'utilisation de ce système quand on le trouve séduisant. Mais c'est ainsi qu'il serait réellement employé : c'est une pente naturelle que l'on a abondamment vue suivre à chaque fois que c'était possible.

Que dire ensuite si on se souvient que le petit monde des navigateurs desktop est très loin de représenter la majorité des agents utilisateurs ? Va-t-on gérer conditionnellement les innombrables navigateurs mobiles ? Les navigateurs Web-Tv ? Les navigateurs pour verticaux ? Les navigateurs vocaux ?

D'autre part, si les bugs sont en effet incompressibles, ils sont par nature temporaires et évolutifs. Ils invitent plutôt à gérer des dégradations admissibles ne nécessitant ni hack ni discimination de contenu, qu'à actualiser en permanence un éventail de CSS spécifiques. En admettant des impossibilités parfois, et en renonçant à certains effets.

Enfin, les marges d'interprétation des normes CSS sont gérées à un autre niveau : celui des versions successives des normes elles-mêmes. CSS2.1, directement issue des implémentations et ayant elle-même conduit à faire converger celles-ci, en est un excellent exemple.

Tentant, oui. Très tentant. Mais à contre-courant de l'interopérabilité.
Modifié par Laurent Denis (03 Oct 2005 - 17:09)

Laurent Denis a écrit :
On reviendrait effectivement à une discrimination des contenus par id de navigateur, et non plus par capacité de l'agent utilisateur, quel que soit son id précis

Un tel mécanisme serait une possibilité de discrimination des contenus par id, mais une possibilité seulement, pas une obligation, et pas spécialement contradictoire avec la sélection selon la capacité de l'agent prévue par la norme.
Ceci étant j'admets qu'il est difficile d'imaginer toutes les dérives possibles.

Laurent Denis a écrit :
si les bugs sont en effet incompressibles, ils sont par nature temporaires et évolutifs. Ils invitent plutôt à gérer des dégradations admissibles ne nécessitant ni hack ni discimination de contenu, qu'à actualiser en permanence un éventail de CSS spécifiques. En admettant des impossibilités parfois, et en renonçant à certains effets

Je suis particulièrement sensible à cet argument. Le renoncement est vraiment la bonne façon d'éviter la lourdeur inévitable requise par la mise à jour d'une multiplicité de spécifiques. Cependant si le renoncement devient déchirant à un moment ou un autre, alors pourquoi ne pas exploiter une porte de sortie un peu moins glauque que la myriade de hacks actuellement en usage sur le web ?

Sur le plan de l'interopérabilité, je suis un peu dubitatif. Il me semble qu'elle est déjà difficile à mettre en place du fait de la variabilité de la capacité des différents agents utilisateurs, comme cela a été souligné. Il est nécessaire de jongler avec les contenus et leurs présentations si l'on souhaite s'adresser à un grand nombre de types de postes clients. Le mécanisme des commentaires conditionnels n'aiderait en rien certes, mais ne viendrait pas particulièrement en détériorer les conditions par rapport à la situation actuelle.

Xavier a écrit :
Cependant si le renoncement devient déchirant à un moment ou un autre, alors pourquoi ne pas exploiter une porte de sortie un peu moins glauque que la myriade de hacks actuellement en usage sur le web ?

Oui. Tout à fait. Les commentaires conditionnels sont l'alternative à privilégier face aux bugs d'IE 5.x - 6.0 Windows. Mais dans la mesure où cette porte de sortie ne concerne qu'un navigateur unique dans une situation bien spécifique.

Laurent Denis parle bien mieux que moi de choses qu'il connait ben mieux que moi, mais ce qu'il a dit était en sorte ce que j'aurais voulu dire. (Ouah, la belle phrase !)

Bref, ceci mis à part. Ce qu'on cherche à faire, c'est proposer la meilleure version possible à chaque navigateur. Ce qu'il faudrait discriminer (dans le sens "séparer"), ce n'est pas les navigateurs, mais les fonctionnalités. Je ne sais pas comment mais un truc style : Si CSS2 = OK

Non ?

@+, HoPHP

Ah... Mais on peut déjà faire cette discrimination positive. Il suffit par exemple :
- d'utiliser les extensions CSS propriétaires définies par CSS2.1, du type -moz-..., -op-... etc.
- d'utiliser le display-table pour gérer du colonnage et ses hauteurs dans les navigateurs conformes, en se repliant sur un colonnage "pauvre" dans IE
- d'utiliser les compteurs CSS pour le titrage dans Opera et la future version de Firefox
- de dégrader la position fixe en position absolue dans IE
- d'exploiter la propriété content CSS3 dans Opera, ignorée par les autres navigateurs,
- d'utiliser certains filtres dans IE, dans des commentaires conditionnels
- d'exploiter le support d'application/xhtml+xml pour profiter d'une meilleure implémentations CSS dans les navigateurs modernes, en servant une autre feuille de style à IE (tant qu'on est à faire de la négociation de contenu).
-etc...

Rien n'empêche d'exploiter au mieux les implémentations de chaque navigateur...

<edit>Ah... si. Il y a quelque-chose qui l'empêche souvent : l'idée issue tout droit du monde de l'imprimé selon laquelle le graphisme ne doit pas varier d'un navigateur à l'autre .</>
Modifié par Laurent Denis (03 Oct 2005 - 20:57)

Laurent Brocolis a écrit :
- de dégrader la position fixe en position absolue dans IE

Sans hack ?

Laurent Denis a écrit :
Rien n'empêche d'exploiter au mieux les implémentations de chaque navigateur

C'est bien ce à quoi je pensais avec ces commentaires conditionnels étendus aux autres navigateurs.

C'est vrai que l'équivalent peut être implémenté avec la négociation de contenu coté serveur, sans toutefois présenter le même coté pratique.

Bonjour,
Pourrais-je insidieusement profiter de ce post pour demander à Laurent Denis (ou à tout autre personne), si il connaît de la documentation sur : Les extensions CSS propriétaires du type -moz-, -op-.

Bonsoir,

Voir la spécification CSS2.1, http://www.w3.org/TR/CSS21/syndata.html#q4

Et les pages éventuellement consacrées par chaque navigateur à ses extensions.

Pour Opera, elles sont au nombre de 3 (et servent à gérer des liens et des images dans des documents XML) : http://www.w3.org/TR/CSS21/syndata.html#q4

Pour Gecko, elles sont plus nombreuses, peu documentées et changeantes.

Ce qui est frustrant avec css2.1, c'est d'avoir un préfixe par vendeur, alors que certains font la même chose, puisque c'est souvent une implémentation "en avance" du brouillon CSS3.

Donc, puisqu'on en est aux réclamations concernant les normes, j'aimerais bien avoir un préfixe CSS "-draft-...", ou un truc du genre. Comme ça quand plusieurs UA implémentent une fonctionnalité avant la recommandation finale (au hasard : border-radius), on pourrait au moins avoir la même syntaxe.

Laurent le disait plus haut :
ce genre de manip est ingérable !

Nous avons actuellement en gros 4 moteurs de rendu :
Gecko (mozilla, firefox & cie)
Opera (connait pas le nom du moteur mais bon...)
Trident (IE Win)
KHTML (Konqueror, Safari)

Bon, il y a le moteur IE Mac mais on le fout au cimetière celui là.

Voilà où nous en sommes en 2005.

Projetons nous en 2007, la société "MachinBidule" veut créer un navigateur parceque ceux qui sont sur le marché ne lui convienne pas et que c'est hype les navigateurs.
Bon, refaisons un moteur de rendu... bah vui, les moteurs actuels plaisent pas au patron de "MachinBidule", Hop, voilà MBibule créé, le moteur de rendu du navigateur MachinB

Allo, M. W3C, oui c'est pour une modification de norme, j'ai créé un navigateur, il faut m'ajouter un commentaire conditionnel.

Voilà... la réponse coule de source...
Et de façon encore plus concrète comme le précisait Laurent, les navigateurs mobiles etc.

Ce genre de chose revient exactement à la même chose que la détection navigateur avec JS (en plus fiable en plus... donc potentiellement encore pire pour les porchiots du HTML).

Bonjour

Lanza a écrit :
Donc, puisqu'on en est aux réclamations concernant les normes, j'aimerais bien avoir un préfixe CSS "-draft-...", ou un truc du genre. Comme ça quand plusieurs UA implémentent une fonctionnalité avant la recommandation finale (au hasard : border-radius), on pourrait au moins avoir la même syntaxe.

Que fait-on quand Opera et Mozilla n'extrapolent pas de la même manière la propriété -draft-foo, et que l'un fait le contraire de l'autre ?

Olivier a écrit :
Allo, M. W3C, oui c'est pour une modification de norme, j'ai créé un navigateur, il faut m'ajouter un commentaire conditionnel.

En fait, non, Olivier. Ce "allo" ne serait absolument pas nécessaire, et il n'y aurait aucun problème à ce niveau.

Chaque navigateur discriminerait, comme le fait IE Windows actuellement, selon l'id et la version spécifiée dans le commentaire conditionnel : Moi, je suis FF, je ne lis que les "if FF...".

Monsieur Bidule aura juste à s'assurer que son navigateur, même s'il s'appelle Fififox pour le public, n'a pas comme id FF, ce qui ne concerne aucun organisme de normalisation.

Laurent Denis a écrit :
Bonjour

Que fait-on quand Opera et Mozilla n'extrapolent pas de la même manière la propriété -draft-foo, et que l'un fait le contraire de l'autre ?

Alors il faut revoir le working draft

papillon41 a écrit :
Bonjour,
Pourrais-je insidieusement profiter de ce post pour demander à Laurent Denis (ou à tout autre personne), si il connaît de la documentation sur : Les extensions CSS propriétaires du type -moz-, -op-.

Mozilla CSS Extensions

Lanza a écrit :


Alors il faut revoir le working draft

Sauf que ça peut être une candidate recommandation, ou même une recommandation finale dans CSS modulaire. Et qu'en attendant, quoi que ce soit, on est bien emmm....

Un autre exemple, avec une approche différente : les actuelles extensions Opera visent le traitement des liens dans les ressources XML. Elles ne sont pas destinées à traiter des documents Web (mêm si on peut les y utiliser pour des choses étranges), mais au fonctionnement des clients mail et RSS du navigateur. Elles sont donc très spécifiques à ce navigateur et n'ont aucun rapport avec aucun WD, CR ou recommandation CSS...
Modifié par Laurent Denis (06 Oct 2005 - 14:54)

Laurent Denis a écrit :


En fait, non, Olivier. Ce "allo" ne serait absolument pas nécessaire, et il n'y aurait aucun problème à ce niveau.

Chaque navigateur discriminerait, comme le fait IE Windows actuellement, selon l'id et la version spécifiée dans le commentaire conditionnel : Moi, je suis FF, je ne lis que les "if FF...".

Monsieur Bidule aura juste à s'assurer que son navigateur, même s'il s'appelle Fififox pour le public, n'a pas comme id FF, ce qui ne concerne aucun organisme de normalisation.

A ce moment là il ne sert à rien de normaliser le bidule côté W3C comme le suggerait/sous entendait Xavier

Le listing des identifiant doit bien être normalisé quelque part, sinon c'est le chaos...

Donc, si je capte bien, au final, adios le w3c puisque chacun gère sa sauce de son côté en utilisant son piti identifiant perso.

Il ne resterait qu'à implémenter les commentaires conditionnels avec gestion de l'identifiant pour les navigateurs.

Reste ensuite le problème des versions...