Standards du Web vs. Standards du Print

Rigueur. Et passion !

Ne dites pas à ma mère que je suis artisan en architecture de l'information appliquée aux sites web : elle croit que je suis webdesigner, intégrateur HTML & CSS, rédacteur web, formateur NTIC et consultant en webmarketing depuis 2001 ! Voulez-vous en savoir plus ?

Le blog de l'intégrateur web

Standards du Web vs. Standards du Print

Julien Dubedout @mariejulien vient d’écrire un article très intéressant sur le rendu au pixel près des maquettes dans les différents navigateurs. Il explique son point de vue sur certaines différences de rendu de certaines propriétés qui ne sont pas { acceptables | logiques | normales } ; elles proviennent d’un standard qui — par définition — devrait garantir un affichage identique d’une même propriété sous tous les navigateurs. L’argumentation est rigoureuse et l’analyse est fine ; je partage une grande partie des points abordés par Julien que je résume rapidement ainsi :

On peut dire que certaines prises de position sur le «lâcher-prise» concernant le design web sont parfois l’expression de l’impuissance travestie en abstinence. On ne peut pas le faire, donc c’est mal.

Toutefois, pour en revenir à l’exemple des ombres portées, j’ignore s’il existe une norme qui définit comment elles doivent s’afficher. Leur rendu à l’écran (quels écrans ?) dépend surtout des logiciels qui permettent de les créer. Une ombre portée n’est probablement pas strictement identique dans Photoshop, Gimp ou Paint. Pourquoi serait-ce différent pour les navigateurs web qui sont des logiciels comme les autres ?

Lorsque j’imprime une ombre portée réalisée dans Photoshop, son rendu diffère selon la nature du papier  : offset, couché, non couché, bouffant ou bible ! Sans parler des différences d’une même plaquette imprimée sur le même papier chez deux imprimeurs différents (avec pourtant strictement les mêmes valeurs CMJN)…

Juste une petite pique, donc, en lisant que :

L’industrie de l’imprimerie a, de son coté, pas mal réussi à relever ce défi de standardisation, il faudrait donc s’en inspirer sur ce point et ne pas laisser tomber en route la standardisation de l’affichage.

Je ne peux m’empêcher de penser aux plus de deux millions de personnes qui se demandent pourquoi il y a encore, en 2011, cette satanée différence entre écran et résultat imprimé ;-)

Articles sur le même sujet

PS : Le respect de la vie privée sur internet est important : j'ai décidé d'échanger mon bouton Like de Facebook par un bouton Faire un don de Paypal car
Il n'y pas d'amour, il n'y a que des preuves d'amour (Jean Cocteau) ;) Merci d'avance.



10 commentaires pour “Standards du Web vs. Standards du Print”

  1. tuxfre dit :

    S’acharner à ne pas comprendre pour quoi print et screen ne pourront jamais faire que s’approcher (on peut déjà simuler assez fidèlement les rendus, y compris tenant compte du support) c’est comme s’acharner à vouloir mettre du diesel dans sa voiture essence, sous prétexte que ce sont deux carburants. Il s’agit de deux mode de calculs de couleurs opposés (synthèse additive vs soustractive), et donc on n’aura donc jamais la même couleur, mais, comme je l’ai dit, (et ce même sur le meilleur écran de la terre super-mega-bien-calibré) il ne s’agit que d’une approximation.

    • br1o dit :

      Rassures-toi, je comprends très bien toutes ces problématiques de rendu des couleurs pour avoir calibrer un bon paquets de chaines graphiques dans ma jeunesse ^^ Mon propos est justement de faire toucher du doigt qu’il ne s’agit pas de mondes si différent que ça.

      Quand je travaillais en PAO, les problèmes de rendu des flasheuses ne valaient pas mieux que les différences entre les navigateurs. Een PAO quand tu as trouvé un bon imprimeur, tu peux commencer à travailler sereinement (écran calibré ou non, si tu as l’habitude de te représenter les couleurs directement en CMJN, question d’habitude…).

      Avec le web, on pourrait penser que la conception sur un écran pour un rendu à l’écran réglerait le problème, mais on voit bien que ce n’est pas une question de RVB vs CMJN

    • Julien dit :

      ça tombe bien c’est pas DU TOUT de ça dont il est question :-/

  2. William dit :

    Et encore le navigateur est un problème, mais quid des réglages propres à l’utilisateur final ? – Son écran (sans parler de résolution) : marque, luminosité, contraste (réglages que chaque utilisateur peut paramétrer à sa convenance) – Sa carte graphique (chez moi par exemple nVidia et ATI ne rendent pas les couleurs de la même manière) – La luminosité ambiante – Le reflet de m…. sur l’écran qui empêche de voir l’ombre si savamment codée.

    Bref il y a des contraintes software à prendre en compte, et effectivement ce n’est pas normal que les rendu diffèrent selon les navigateurs pour un même code, mais il y a aussi des contraintes qu’aucun graphiste/webdesigner/intégrateur ne pourra prévoir ou traiter qui sont lié à environnement. C’est peut être pour cela qu’on parle « d’expérience utilisateur » en web design non ?

    Au moins un rendu print il y a moins de contraintes Hardware pour l’utilisateur final…ha si, ses lunettes -__-

  3. Julien dit :

    Ça devient assez laborieux là quand même :-/ (voire ça devient n’importe quoi…)

    « Une ombre portée n’est probablement pas strictement identique dans Photoshop, Gimp ou Paint »

    et alors ? ce sont des logiciel de travail, pas un rendu diffusé. Tant que l’ombre est conforme à ce que veut le DA, où est le problème ?

    « Pourquoi serait-ce différent pour les navigateurs web qui sont des logiciels comme les autres ? »

    peut être parce que justement non ? Qu’un navigateur est sensé délivrer un site précis quand photoshop sert à créer ?

    Pour les rendus papiers différents : il s’agit AUSSI d’un choix, donc c’est normal que chaque papier ait ses contraintes, tout comme il est normal que ça s’affiche différemment sur un iphone et un imac, mais sur 2 papiers de même grammage/propriétés même de marque différentes, ça s’affiche pareil. Une feulle A4 mesure 21×29,7 cm, quelle que soit la marque, POINT.

    Et pour finir tu tapes à coté en parlant du décalage entre affichage RVB chez un particulier et l’impression sur son imprimante familiale, hors de tout standard ou de chaine de prod, bref on nage en plain nawak là quand même…

    • br1o dit :

      L’agent utilisateur qui sert à visualiser ton site est aussi un choix. Mais pour le coup, ce choix ne dépend pas de toi, mais de l’utilisateur final. Je ne sais pas où tu as lu qu’un navigateur était censé délivrer un site précis…

      Je parlais bien de l’impression dans le cadre d’une chaine calibrée, pas en mélangeant l’imprimante familiale et la presse à imprimer ;)

      Ce que je veux dire c’est que quand bien même les standards du web parviendraient à standardiser les paramètres liés à l’affichage d’une ombre portée pour qu’elle s’affiche partout de la même manière, tu ne pourras pas obliger les éditeurs de navigateurs à implémenter toute une spécification, ni obliger les internautes à installer un navigateur qui implémente 100% des standards…

      A moins que l’HADOPI s’en mêle, on ne sait jamais ^^

  4. Corey dit :

    Pour ma part j’ai l’impression que ce n’est pas la bonne question… Il existe des « contraintes » propres à chaque métier. Ces contraintes peuvent être soit des murs soit des outils, la richesse du web est aussi due au fait qu’on ait pas qu’un seul navigateur et c’est grâce à la concurrence entre navigateur que cela avance. Les gens qui expérimentent sur print l’ont bien compris (jeux de couverture replaçable, transparentes avec plusieurs calques,…) De la même manière pour un l’intégrateur (ou développeur ou webdesigner) je comprends l’intérêt de grilles… cependant, là aussi, ce ne sont que des outils pas deslois sacrés ou des cloisons…

  5. Zipnu dit :

    La logique voudrait que les navigateurs respectent les standards, mais dans leur secteur de plus en plus concurrentiel avec ses enjeux sous-jacents ils n’y trouvent peut-être pas d’intérêt, puisque l’utilisateur final s’en moque et préfère des fonctionnalités plus pragmatiques quand à l’interface et aux outils de navigation. Il existerait un navigateur super respectueux des standards qu’il n’aurait aucun succès, sauf auprès de ceux qui programment.

    Après programmer en prévoyant tout les types de navigateurs, ça risquerait de n’être plus possible sur un long terme, d’autant plus que chacun possède des tas de versions différentes, vouloir servir le client est honorable, se compliquer la vie(quand cela pourrait être évité) afin d’atteindre cet objectif est un débat.

    D’ailleurs on voit déjà des prêches d’abstinence, pas d’ombre, pas de html5, on lance la vapeur on la renverse, elle nous revient à la tête, cycle infini du progrès d’où émerge à la fois de nouveaux bons et de nouveaux mauvais procédés.

    Est-ce que cela aura le temps de se décanter, avant qu’on en vienne au html42, css69, internet explorer666, firefox451… Que restera t-il de l’expérience humaine face aux plaisirs les plus instantanés. Angoisses inutiles, sans doute.

  6. Briegel02 dit :

    Dans le web, et contrairement au print, le pixel-perfect n’est pas le but à atteindre (pas de bol). Il y a plein de buts aussi importants, et pour ma part je préfère avoir un code léger, accessible et facilement référençable qu’avoir la garantie des ombres qui passent sur les vieux navigateurs. Trois paramètres contre un : les ombres du graphiste ont perdu, dommage, mais c’est ça le web : bienvenue !

  7. [...] en voie de [développement] [disparition] ? Les claviers ont crépité la semaine dernière autour du rendu des maquettes Photoshop au pixel près. En relisant les billets et les commentaires, [...]

Laissez un commentaire

Vous pouvez utiliser les balises HTML suivantes : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Les commentaires sont publiés sous votre pleine et entière responsabilité et ne doivent pas contrevenir aux lois et règlementations en vigueur. Les propos racistes ou antisémites, diffamatoire ou injurieux, divulguant des informations fausses, relatives à la vie privée d'une personne ou utilisant des oeuvres protégées par les droits d'auteurs ne sont pas les bienvenus et seront modérés sans modération.

Merci d'être constructif et n'oubliez pas : « sans la liberté de ramer il n'est point d'éloge flotteur ! »



Colophon

CSS & Webdesign est une publication irrégulomadaire à tendance hebdomadaire
éditée par Bruno Bichet qui carbure à WordPress et au café équitable.
Tous droits réservés © 2006 - 2011.

Contactez l'auteur du site