Le design dans le navigateur est une technique de Webdesign qui fait l’impasse sur la maquette Photoshop. Derrière ce concept se trouve l’idée selon laquelle dans « Webdesign » il y a d’abord « Web » : pourquoi commencer le travail dans Photoshop pour refaire ensuite presque la même chose en HTML et en CSS ? Surtout quand la prise en charge progressive de CSS3 par les navigateurs récents autorise des effets graphiques qui nécessitaient autrefois de nombreuses images et un marquage HTML surnuméraire…
Travailler directement dans le navigateur est l’occasion de pratiquer l’amélioration progressive ou la dégradation gracieuse selon le côté où l’on se place. L’amélioration progressive est une méthode de conception centrée sur le contenu : les effets graphiques sont ajoutés dans un deuxième temps pour les navigateurs modernes. La dégradation gracieuse privilégie l’apparence : utilisation des dernières technologies en première intention et mise en place de fallbacks pour que la page reste fonctionnelle sur les configurations plus modestes. Opposées en apparence, ces deux approches sont souvent complémentaires dans la pratique.
Dans ce tutoriel, après avoir crayonné une esquisse de la page sur le papier et choisi une palette de couleur, nous passerons en revue les balises HTML5 utilisées dans cet exercice de style. Nous verrons comment obliger Internet Explorer à prendre en compte ces nouveaux éléments. Pour finir, nous ajouterons du « volume » à la page grâce à la magie de CSS3. La page se présentera sous son meilleur jour dans les dernières versions de Firefox, Chrome ou Opera, tout en restant totalement fonctionnelle et très proche visuellement de « l’original » dans Internet Explorer 6, 7 et 8 malgré l’absence des effets.
1. Baliser le contenu
Pour mettre en œuvre le principe de l’amélioration progressive, il est important de commencer par le contenu. L’idéal est de faire un découpage HTML du matériel fourni par le client qui soit indépendant de toute mise en forme. La mise en page en plusieurs colonnes s’effectuera en ajoutant des balises `div` aux endroits stratégiques. N’hésitez pas à ouvrir le fichier index.php dans votre navigateur et votre éditeur préféré pour avoir une vision globale du code et suivre les explications sur l’utilisation des nouvelles balises HTML5.
Il s’agit bien du degré zéro de l’amélioration progressive mais cette page est déjà fonctionnelle dans tous les agents utilisateurs ! Son affichage est garanti sur tous les périphériques affichant du HTML quelle que soit leur ancienneté ou leur résolution d’écran (même les lecteurs vocaux devraient s’y retrouver). Il s’agit véritablement de la matière première brute de fonderie qu’il faudra styler pour aboutir à quelque chose de plus flatteur visuellement.
2. Ébauche de la page
Une fois que vos contenus textes et images sont été correctement balisés avec les balises HTML appropriées, il est temps d’ouvrir votre bloc-note préféré pour griffonner l’allure générale de votre page web :
Pas besoin de trop détailler. Il faut seulement faire ressortir la structure générale du site : empagement, en-tête, pied de page, nombre et emplacement des colonnes pour les articles et les barres latérales. Cette esquisse sert surtout de point de repère pour éviter de se disperser dans le feu de l’action.
3. Choisir les couleurs
Le succès d’un site web repose en grande partie sur l’harmonie des couleurs utilisées. L’application en ligne Kuler d’Adobe contient plusieurs milliers de palettes de couleurs modifiables de manière intuitive. Nous récupérerons les valeurs HEX (hexadécimale) et RGB (Red, Green, Blue) des couleurs que nous auront sélectionnées.
4. Squelette de page HTML5
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Une page HTML5...</title>
</head>
<body>
<p>...avec du contenu.</p>
</body>
</html>
La structure de base d’une page HTML5 se différencie peu des anciennes versions. La syntaxe du DOCTYPE (Document Type Declaration, ou DTD) est simplifiée et ne propose qu’un seul mode : fini le choix cornélien entre Strict, Transitional ou Frameset !
En HTML5 le doctype s’écrit en bas de casse mais pour des raisons de compatibilité avec les anciennes conventions héritées de SGML (Standard Generalized Markup Language), il est recommandé d’écrire DOCTYPE en lettres capitales. La présence d’une DTD permet aux moteurs de rendu des navigateurs web d’afficher les pages dans un mode standard (Standard Complient Mode).
J’utilise l’IDE (Integrated Development Environment) Netbeans (Notepad++ est aussi un très bon choix) et le navigateur Firefox équipé de Firebug. Je teste ensuite les pages dans un maximum de navigateurs : Google Chrome, Opera, Safari, Internet Explorer 6, 7, 8 (9 Preview) mais aussi sur des périphériques mobiles à résolution d’écran limitée (téléphone portable, Netbooks, iPhone, etc.).
5. Préparer Internet Explorer pour HTML5
<!--[if lt IE 9]>
<script>
// http://remysharp.com/2009/01/07/html5-enabling-script/
/*@cc_on'abbr article aside audio canvas details figcaption figure footer header hgroup mark menu meter nav output progress section summary time video'.replace(/w+/g,function(n){document.createElement(n)})@*/
</script>
<![endif]-->
Internet Explorer ne prend pas en charge les nouvelles balises HTML5. Toutefois, il est possible de les injecter dans le DOM (Document Object Model) à l’aide de quelques lignes de Javascript à placer dans la balise `head`. Les commentaires conditionnels permettent de cibler toutes les versions inférieures à Internet Explorer 9 (soyons optimistes !).
6. Structure générale de la page
Là où HTML 4.0.1 n’offrait grosso modo qu’une balise `div` générique pour « div-iser » nos pages web, HTML5 propose différents éléments permettant d’affiner la structure d’une page : `header`, `hgroup`, `section`, `aside`, `nav`, `article`, `footer`, etc. Malgré des intitulés apparemment sans ambiguïté, l’utilisation de ces nouvelles balises n’est pas toujours simple : la compréhension des contenus fournis par le client est plus importante que jamais, ce qui devrait booster la dimension littéraire de votre intégrateur web 😉
7. `header`
Il s’agit de l’introduction du site ou d’une section de la page. Ici, nous avons trois niveaux d’en-tête. Un header contient généralement un ou plusieurs niveaux de titre `h1` – `h6` ou un groupe de titres `hgroup`. Il peut également abriter un formulaire de recherche, un menu de navigation, le logo ou tout autre élément en rapport avec la page ou le site web dans son ensemble.
8. `footer`
C’est en quelque sorte la conclusion de l’introduction du site ou de la section de la page auquel il se rapporte. Selon le contexte, `footer` peut contenir le copyright pour l’ensemble du site ou la date de publication d’une note. Dans l’exemple, j’utilise `footer` (et `header`) au niveau du `body`, de `div#container` et de `article`. Cette balise n’est pas nécessairement située en fin de section : elle peut se trouver juste après la balise `header`. On pourra en effet vouloir regrouper visuellement toutes les informations relatives à un article.
9. `hgroup`
Cet élément a pour vocation de regrouper différents niveaux de titre à l’intérieur d’un élément `header`. Typiquement : le nom du site et sa Baseline ou un titre et un sous-titre. La subtilité de `hgroup` tient au concept d’Outline qui permet de souligner la structure d’une page (si `hgroup` contient un `h1` et un `h2`, seul le premier niveau sera pris en compte par l’Outliner).
10. `article`
Tout contenu indépendant susceptible d’être syndiqué dans un flux Atom ou RSS comme une note, une entrée de blog, un article de journal ou même un Widget interactif (un système de chat, par exemple) peut être enveloppé avec `article`. Cette balise peut également être imbriquée dans un autre élément `article` dans le cadre de commentaires laissés par les utilisateurs.
11. `section`
Une section est une portion plus ou moins importante de contenu avec au moins un niveau de titre. Tout ce qui se trouve à l’intérieur de `section` devrait pouvoir être isolé du reste et fournir une information autonome.
Pour faire simple, l’élément `section` ne devrait pas être utilisé :
Pour l’application de styles CSS ou d’ancrage pour du Javascript (préférez l’élément `div`),
Si les éléments `article`, `aside` ou `nav` sont plus appropriés,
Si vous n’avez pas de titre à mettre – et non, le display: none n’est pas une option 😉
12. `nav`
C’est un élément plus ambiguë qu’il n’y parait. On a envie de l’utiliser pour envelopper toutes les balises `ul` et `ol` de la page dès lors que les liens qui s’y trouvent pointent vers le site, mais cette balise est avant tout destinée à la navigation principale !
Un site web peut comporter plusieurs systèmes de navigation comme la listes des pages, les catégories ou les tags. Si ces listes sont de bonnes candidates pour la balise `nav`, il faut garder à l’esprit le concept d’Outline : la balise `nav` se porte mieux accompagnée d’un niveau de titre, en l’absence duquel il est préférable d’utiliser une balise `div`.
13. `aside`
Cet élément regroupe les éléments tangentiellement reliés au contenu. Il peut être utilisé de deux manières : dans une balise `article`, il pourra regrouper la définition des termes employés, les notes additionnelles, etc. tandis qu’en dehors, il pourra servir de barre latérale (Sidebar) pour accueillir des éléments de navigation, une liste de liens (Blogroll) ou encore la présentation de l’auteur.
14. Appliquer un reset CSS
Les navigateurs possèdent chacun une feuille de style par défaut, une sorte de degré zéro du design pour styler les balises HTML : les listes présentent des puces et sont en retrait, les titres ont des tailles relatives à leur niveau hiérarchique, `strong` est en gras et `em` en italique… Le fichier global.css est là pour mettre les navigateurs au diapason. Il est composé d’une version modifiée du reset CSS d’Eric Meyer et d’une partie du fichier typography.css du framework CSS Blueprint.
Le fichier style.css est composé de la redéfinition des styles via la règle @import global.css et des règles CSS spécifiques à la page index.php ainsi qu’aux autres pages du site, le cas échéant.
15. Styler les balises `html` et `body`
html {
background: #380707;
color: #CBB388;
}
body {
position: relative;
width: 960px;
margin: 6em auto;
padding: 1.5em 9px;
border: 1px solid #1F0404;
background: #590B0B;
}
La balise `html` reçoit la couleur pour le fond du Viewport (la partie visible de la fenêtre) et la couleur par défaut pour l’ensemble des textes. Dans un premier temps, on indique les propriétés qui s’afficheront dans tous les navigateurs. Le fait de styler la balise `body` permet d’économiser la balise `div` qui sert généralement de Container pour l’ensemble de la page.
Les effets CSS3
16. Les ombres portées et les dégradés
body {
/* Degrade */
background: -moz-linear-gradient(-90deg,#590B0B,#1F0404);
background: -webkit-gradient(linear, left top, left bottom, from(#590B0B), to(#1F0404));
/* Ombre portee */
-webkit-box-shadow: #000 0px 0 16px -1px;
-moz-box-shadow: #000 0px 0 16px -1px;
box-shadow: #000 0px 0 16px -1px;
}
Dans un deuxième temps — on améliore progressivement –, on ajoute un dégradé linéaire et une ombre portée. Les navigateurs n’affichant pas ces propriétés utiliseront le background: #590B0B et la propriété border: 1px solid #1F0404 de l’étape précédente.
17. Textes ombrés
#brand h1 {
text-shadow: rgba(0,0,0,0.7) 2px 3px,rgba(255,255,255,0.7) 0 -1px;
}
La propriété text-shadow applique une ombre portée sur les textes. L’utilisation conjointe de rgba() autorise un effet de transparence pour alléger l’effet et le fondre dans la page. Ici, deux ombres portées décalées sont appliquées : une vers le haut et l’autre vers le bas.
18. Coins arrondis
.roundies {
-moz-border-radius: 5px; /* Firefox */
-webkit-border-radius: 5px; /*Safari, Chrome */
-khtml-border-radius: 5px; /* Linux */
border-radius: 5px; /* CSS3 */
}
Dans la mesure où cette propriété est utilisée plusieurs fois avec les mêmes valeurs, les bords arrondis sont regroupés dans une classe CSS. Ici, le rayon pour l’arrondi est de cinq pixels pour tous les angles. Pour arrondir les angles supérieurs gauche et droit uniquement, il suffit de remplacer 5px par 5px 5px 0 0 et le tour est joué ! N’hésitez pas à tester plusieurs combinaisons. Il existe un générateur de propriétés CSS3 interactif pour se faciliter la tâche.
19. Égaliser les colonnes avec Javascript
<script src="column.js"></script>
<script>
var divs = new Array('articles','sidebar-1','sidebar-2');
</script>
Dans le modèle de page terminée vous avez peut-être remarqué que la barre latérale du milieu s’allonge en fonction de la hauteur du contenu principal. Cet effet, bien qu’optionnel pour la compréhension du contenu, n’en est pas moins intéressant visuellement (le contenu est roi, mais ce n’est pas une raison pour oublier l’esthétique !). Pour cela, j’utilise un script très léger (column.js) qui harmonise les colonnes selon la plus haute parmi celles qui sont passées en paramètre. Ajoutez l’appel Javascript dans la balise `head` pour équilibrer les colonnes `div#articles`, `div#sidebar-1` et `div#sidebar-2`.
Pour aller plus loin
- Amélioration progressive
- Make Your Mockup in Markup (Design dans le navigateur)
- Kuler (Adobe)
- Netbeans
- Notepad++
- Firefox
- Firebug
- Outliner
- Reset CSS
- Blueprint
- CSS3 Generator
- CSS Balanced Columns
Bon à savoir
Cet article a paru en mai 2010 dans le Hors-Série n°5 du magazine Web Design consacré à HTML5, CSS3 et jQuery. Lire Webdesign Magazine — un Hors-Série n°5 spécial HTML5, CSS3 et jQuery pour plus d’information. N’hésitez pas à vous manifester pour ajouter votre grain de sel, en particulier sur sur partie concernant l’utilisation des balises HTML5 `header`, `hgroup`, `section`, `aside`, `nav`, `article`, `footer`, etc., d’autant plus que des changements ont pu survenir dans les Drafts du W3C depuis la rédaction de l’article.
Excellent article, juste un point pour préciser que l’on ai pas obliger de passer par Javascript pour égaliser des colonnes. Il existe de vielles propriétés CSS 2 qui permettent de la faire display:table-cell.
Excellent article 🙂
oui sa m’a beaucoup appris, merci beaucoup
Très bon article et j’adhère complètement à cette nouvelle méthode de conception…
Pourquoi ? Parce que je suis développeur et mes connaissances en Photoshop sont quasi nulles. Du coup, faire un design en code statique avec du HTML et du CSS, c’est d’avantages dans mes cordes et me permet de faire du WebDesign à ma sauce… C’est la première raison.
La seconde, c’est que cela permet de se rendre compte en condition réelle « in navigatorus » du rendu d’un design et mine de rien cela permet de voir tout de suite le résultat final sans l’effet photoshop…
Et enfin, parce que l’utilisation d’un framework CSS permet de rendre ce travail beaucoup plus simple, rapide et efficace. Par exemple, l’utilisation des variables avec Less ou SASS permet de gagner un temps fou et de changer radicalement le design (couleur, margins, taille des radius, profondeur des ombres) d’un site statique en une poignée de manipulation (tout comme avec Photoshop).
Bref, que des avantages pour un non designer, une personne comme moi !
PS : Dommage l’utilisation du JavaScript pour la colonne du milieu, j’ai jamais été fan d’utiliser le JS pour le rendu visuel…
Excellent post !
La question sous-jacente est : Que vont devenir tous ces infographistes qui ne débordent pas de Photoshop/Illustrator ?
J’en connais, et je les incite systématiquement à plonger un minimum dans le code (HTML + CSS).
Alors quel sera le véritable profil du webdesigner de demain ? Programmateur avec quelques sensibilités artistiques ou Artiste codeur à ses heures ?
C’est le sujet de ma conférence au Paris Web !! 😛 http://cl.ly/27Cu
Tout à fait !
Et le côté « strict » du code oriente bien le côté Artistique en lui donnant une structure…
Tient, je viens de découvrir un « bug ».
Je ne sais pas trop a quoi il est du. Javascript ?
Donc :
1 – Charger la page.
2 – Aller en bas des commentaires pour voir que tout va bien.
3 – Cliquer sur une des images de l’article. (ex 1. Baliser le contenu)
4 – Utiliser le btn « précèdent » du navigateur.
5 – Revenir aux commentaires, et la normalement c’est tout cassé.
Sinon article intéressant !
Oui merci, c’est un bug que j’avais la flemme de résoudre depuis déjà longtemps causé par la conjonction de plusieurs facteurs et il fallait que je choisisse lequel sacrifier :
Différer l’affichage des publicités ou pas,
Avoir une longueur de barre latérale égale à la longueur du contenu via JS ou une image en background
Pour aller vite, j’ai mis une image en background.
En tout cas, merci de ta vigilance qui a contribué à me bouger là-dessus 😉
Pour compléter cet intéressant article en poussant la partie intégration et HTML5 : http://www.codesign.fr/blog-categories/integration,6
On vient de me filer cet article… mon dieu, que dire ? J’ai rarement vu une telle méconnaissance du webdesign.
Ou plutôt, c’est une vision purement dev, dans le courant du design soutenu par alsacréations, avec le design en tant que « couche » avec « des élements qui font jolis qu’on rajoute pour décorer ». Et tout y est : la structure bateau, l’utilisation de kuler au pif etc…
En fait, avant le webdesign, il y a normalement un concept, avec de la direction artistique. On ne touche même pas un crayon. Ensuite on formalise un peu plus en faisant des croquis rapides, ou en croquant directement dans photoshop, qui est un outil quasi direct de dessin finalement (et encore ça bride pas mal). Vous comprenez bien qu’à ce stade il n’est pas question de baliser quoi que ce soit, on ne peut pas se permettre de ralentir et de fermer la porte à ses idées. Photoshop est bien plus souple que du code, l’expression doit être la plus directe possible. Une fois que tout est calé, on peut demander à l’intégrateur d’intégrer. En gros, il faut s’affranchir des contraintes au maximum, même si on les garde en tête, ça ne sert à rien de s’en imposer dès le départ. Sinon on aurait tous des sites d’intégrateurs/développeurs structurés de la même manière avec les mêmes effets css3 limités.
Ça n’empêche pas qu’il m’arrive de designer dans le navigateur, une fois que j’ai le principal, mais ça n’est pas une méthode pour démarrer un CONCEPT de site. Il faut éviter au maximum de se brider, et commencer en balisant et en codant (quoi de moins direct que le code ?)n’est pas une bonne idée pour designer des sites un peu originaux/travaillés.
Pour conclure, je rigole en voyant ce qui sont contents « parce qu’ils ne savent pas utiliser photoshop alors c’est cool » oui mais si vous voulez bien, chacun son métier hein, c’est pas pour rien que les sites de dev sont souvent des aberrations. Vous savez, photoshop sait exporter en HTML aussi, et je ne me dis pas « chouette ça tombe bien je ne savais pas intégrer ».
Julien — Je ne suis pas loin de partager ton point de vue. Je ne suis pas personnellement fan des « effets » CSS3. Tu noteras d’ailleurs que dans cet article, la part qui leur est accordée est relativement faible comparé au traitement de HTML5.
Je pense que les effets CSS3 ont beaucoup d’avenir dans la mise en place des back-office qui sont rarement bien « designés » par les graphistes, soit par manque de motivation, soit par manque de budget.
En ce qui concerne ton « je rigole en voyant ce qui sont contents « parce qu’ils ne savent pas utiliser photoshop » il faut savoir que tout les projets Web ne nécessitent pas forcément de lancer Photoshop. Il m’est arrivé de travailler dans des boites où l’on demandais à des purs dev de faire du design « vite fait mal fait » bien qu’ils s’en seraient certainement passé 😉 Pour eux, les effets CSS3 sont bienvenues.
@Julien :
On est au moins d’accord sur le « chacun son métier »…
Je ne suis pas WebDesigner donc je ne touche pas à photoshop (et aussi parce qu’il coûte un bras). Néanmoins avec de la pratique, le code peut s’avérer presque aussi souple que du code, c’est ce dont je parle avec les frameworks.
Enfin bref, chacun son métier et chacun ses outils. Moi je garde mon IDE !
euh ?
Je voulais dire qu’un éditeur graphique…
hum/// lol. donc Ok, tu ne sais pas DU TOUT te servir de photoshop (ou équivalent) 😉
Sur photoshop c’est simple : tu choisis une couleur et tu dessines. C’est quasimeent le plus direct si on excepte le dessin sur une feuille.
Je parle pas de rapidité mais d’efficacité une fois un projet lancé.
On a pas la même vision des choses c’est tout…
Pour toi changer la couleur d’un élément se fait en quelques click, pour moi ca se fait en changeant une classe ou une propriété dans fichier CSS (ou directement avec un Inspecteur Web)…
I’m Out !
en 2 mots comme en 1000 : Ce que propose ce genre d’articles, c’est de tuner un R19 avec de la peinture et des ailerons, quand logiquement si c’est bien fait on devrait concevoir une nouvelle voiture de zéro.
Ça doit certainement venir de mon côté intégrateur web bien bourrin ^^
@Julien dit :
C’est simple et rapide, certes, à ce détail prés que tu n’es pas sur le support final, pour lequel il faudra retranscrire, ce qui rajoute une étape inutilement longue et complexe… mais je suppose que tu as une armée de braves intégrateurs mal payés qui se chargent du sale boulot à ta place, n’est-ce pas ?
@julien j’espère que c’est de l’ironie. Sinon j’ai bien l’impression que tu oublie un concept fondamental du Web, l’utilisateur est roi, et quelque soit le design que tu veut mettre en place dans ton photoshop, ce sera jamais celui qui sera affiché chez l’utilisateur final. Le Web n’est pas du print.
Ce sont les préférences utilisateurs (types et taille de polices, thème du système d’exploitation, navigateur, équipement, taille du Viewport, taille de la fenetre, plugins, …) qui détermine le rendu final, qui varie considérablement d’un utilisateur à l’autre.
Alors, oui il y a une idée directrice, mais tous les intégrateurs que je connais définissent d’abord la sémantique avant d’appliquer les styles pour matcher aux plus proches les écrans.
Voilà qui est très intelligent. Mais pourquoi on design alors, autant filer du texte noir. Le design est vecteur de sens, je sais que ça a du mal à rentrer chez certains intés mais bon.
Que le mec change sa typo c’est pas plus un problème qu’un daltonien qui verrais mal une affiche, mai sc’est pas une raison pour ne pas designer/conceptualiser.
Bon, y a pas à dire, c’est un très bon article qui montre que l’on peut très bien créer des maquettes fonctionnelles en ne passant pas par Photoshop. C’est d’ailleurs le cheval de bataille de certains maîtres du web design comme Meagan Fisher ou Andy Clarke. Donc, le concept fait son chemin du côté « graphique » aussi.
Maintenant, on ne peut pas tout faire avec CSS3 et HTML5 et il reste encore quelques éléments graphiques qui vont nécessiter l’utilisation d’un éditeur graphique, que ce soit Photoshop ou un autre. Ils peuvent même être très nombreux. Donc, oui à la maquette HTML mais jusqu’à un certain niveau.
Enfin, je me rends compte encore dans les commentaires que le web designer est toujours autant paumé entre le « graphiste qui se croit à faire du print » et l' »intégrateur qui se prend pour un designer ». Va vraiment falloir penser à se faire une autre idée du métier. Le web designer est un acteur à part entière, qui bosse le côté graphique (entre autres) et qui connaît les impératifs de l’intégration. Par pitié, arrêtez de vous bouffer la tête sur des sujets pareils en séparant les deux mondes. CSS3 et HTML5 sont deux opportunités pour mettre tout le monde d’accord, alors plutôt que de continuer avec ces clichés, essayez de voir le bon chez les autres, et dîtes vous qu’ici bas, il y a de vrais web designers, pour qui ce genre de pratique ( conception dans le navigateur ) est un aspect complémentaire à leur travail et qu’ils s’en réjouissent !! 😉
Euh… mwoui.
Je crois qu’il y a confusion entre réaliser/conceptualiser un site et colorier/habiller un site, quel que soit le talent qu’on y mette. Alors oui on peut faire un truc joli tout plein et bien colorié direct dans le navigateur, on peut même conceptualiser à mort, mais c’est juste une bride. Après si c’est amusant hein pourquoi pas. On pourrait dessiner sous paint ou intégrer avec word après tout.
Après on mélange tout, ça n’est pas une question de print ni rien, je connais les contraintes du web, et je sais intégrer, ça n’est pas par méconnaissance que je ne le fais pas, mais juste parce que ça n’est pas la méthode, parce qu’une bonne fois pour toute le GRAPHISME N’EST PAS UNE PUTAIN DE COUCHE POUR FAIRE JOLI SUR UN ZONING, mais bien un vecteur de sens.
Voilà ce qui fera toujours la différence entre intés et DA/webdesigners.
« On pourrait dessiner sous paint ou intégrer avec word après tout. »
J’ai rencontré des ingés en école d’architecture qui utilisaient ces outils pour se dédouaner de ne pas savoir utiliser les softs dédiés à l’image. Ils trouvaient que la performance valait bien le résultat… Jusqu’à la présentation du projet où ils se faisaient ratatiner par manque de soin sur leurs planches.
Ce que l’architecture m’a appris, c’est que le meilleur projet n’a aucune chance contre la meilleure présentation, et la norme n’y fait rien.
Je suis d’accord avec toi, la com’, le graphisme, c’est plus large que l’intégration web, le contenu n’est pas l’unique préoccupation de l’entreprise qui veut communiquer sur le web, et il existe des outils dédiés pour répondre à cette demande d’image, du papier DESSIN (les carreaux, cher Bruno, ça craint, parce que ton croquis, c’est un outil de discussion avec le client), à Photoshop.
ça n’est pas par méconnaissance que je ne le fais pas, mais juste parce que ça n’est pas la méthode
Je ne suis pas sûr qu’il y ait une et une seule manière de faire ou de voir les choses. Dans pas mal de cas, on peut très bien partir directement avec une maquette fonctionnelle dans le navigateur, tout en y intégrant les éléments visuels conçus sous Photoshop.
Bon, perso je ne le fais que rarement étant habitué à Photoshop, mais quelque part, je pense qu’on gagnerait en rapidité pour faire certaines modifs comme le positionnement des blocs, et tout ce que les CSS3 nous permettent. Qui plus est, de plus en plus de clients veulent avoir une maquette fonctionnelle où ils peuvent cliquer même si ça ne les mène nulle part !! ^^
au niveau conception, Photoshop est un outil parmi d’autres. Personnellement, j’utilise des outils très simples comme iMockups voire même Keynote parfois… Et j’arrive sur Photoshop uniquement parce que l’outil me permet de réaliser des éléments graphiques que je ne peux pas faire ailleurs. Par exemple, je viens de réaliser un design minimaliste pour un site. Et bien, je me demande si ça n’aurait pas été mieux et plus rapide de le faire directement dans le navigateur parce que le rendu des polices sur Photoshop est non seulement naze, mais ne permet pas non plus de savoir quel rendu on va avoir sur les navigateurs. A la limite, Fireworks est plus à même de proposer quelque chose de sympa…
@Francis : pour avoir un bon rendu des polices sous Photoshop, il faut régler le mode de rendu du texte à côté du sélecteur de taille du texte : sans, net, précis, fort ou léger. Sélectionnes « sans », et tu auras un rendu fidèle.
« sans » is beurk !! 😛
But is correct ! 😉
J’ai observé de nombreux graphistes et webdesigners travailler et je suis arrivé à la conclusion qu’il existe plusieurs approches intelligentes pour concevoir le graphisme et le « design » d’un site web.
Le point commun entre tous les graphistes que j’ai eu l’occasion de voir bosser c’est que tous — sans exception — ont des habitudes de travail qu’ils mettent en oeuvre de manière quasi identique quelque soit le projet et ses contraintes.
C’est ce qui m’a amené à relativiser la part de soi-disant « créativité adaptés aux besoins du client » souvent mise en avant par les agences. La plupart du temps, j’ai surtout été témoin de l’application de recettes toutes faites, ou presque.
Ce qui ne remet pas en cause le fait qu’il existe des graphistes possédant une solide formation, un esprit créatif et l’intelligence de s’effacer devant les besoins du client final, mais je dois reconnaitre que je ne les ait que très peu côtoyés, et je le regrette.
Par ailleurs, il se trouve — même si c’est malheureux — que de plus en plus de projets web se satisfont de peu de choses en terme de graphisme ou d’ergonomie.
A la limite, j’observe que la partie « ergonomie » est un peu mieux lotie que la partie « graphisme ». Les développeurs et les intégrateurs révisent leurs gammes et se mettent à jour (nouvelles techniques, sémantique, accessibilité, respect des standard, etc.) plus souvent que les graphistes purs et durs ;))
Parce que soyons clairs : se mettre à jour sur Photoshop ou Illustrator c’est quand même beaucoup plus simple que d’être à jour sur l’ensemble des langages et des techniques qu’il faut maitriser quand on fait de l’intégration web ou du développement front-end ^^ J’utilise Photoshop et Illustrator depuis le tout début des années 90 et fondamentalement peu de choses ont vraiment changée 😉
Donc, dans ce contexte (un peu brouillon, faudrait que je rassemble mes idées sur le sujet pour un prochain billet) je trouve que les effets CSS3 — utilisés à bon escient, bien entendu — ont toute leur place dans la boite à outils de l’intégrateur web qui ne devrait pas rougir de les utiliser si le projet le permet.
Les expressions-clés à retenir étant bien évidemment : « utilisés à bon escient » et « si le projet le permet » 😉
Je suis peut être allé un peu fort mais bon. mais avec un début commencat par « J’ai rarement vu une telle méconnaissance du webdesign. ».
Il faut distingués plusieurs types de sites Webs :
les sites à vocations très communicantes où la effectivement le graphisme n’est pas une putain de couche pour faire joli sur un zoning mais bien un vecteur de sens.
les sites plus applicatifs où le graphisme est juste une couche pour faire joli sur un zoning
Aujourd’hui, le modèle Photoshop => Intégration => Développement fonctionnelle montrent ces limites. Il est adaptés aux premier types de sites.
La vocation de HTML 5 est donné la couche applicative que l’on a dans le monde du logiciels. La démarche proposé dans cette article est très proches de ce qu’on l’on fait dans les clients lourds.
Chaque projet nécessite une approche adapté.
Ha ouais nan mais ok si on fait des intranets, faites tout ce que vous voulez dan sle navigateur, c’est pas gênant.
@bruno : la reflexion sur photoshop qui n’évolue pas trop montre bien qu’il y a un problème de perception. Si photoshop n’évolue pas, je ne te parle même pas du bloc et du crayon, unchanged since XVth century 😉
C’est bien le signe qu’il y a là une logique outil, or ça n’est pas à la base d’un bon webdesign.
Très bon article. Je pense que l’on pourrait utiliser dès maintenant le HTML5 en production pour les clients, avec des scripts pour gérer la compatibilité comme Modernizr.
Cela dit, Photoshop reste et restera indispensable si on veut un design abouti et personnalisé.
Ca me rappelle fâcheusement cet article : http://css4design.com/le-creatif-peut-il-etre-independant-du-peripherique-de-sortie
Mais en inverse… Très drôle.
Ceux qui pestent contre les créas 100% Adobe, et ceux qui accusent les devs d’être des ingénieurs bornés à leurs codes et leurs normes.
J’en reviens à ce que je disais : bienheureux celui qui appartient aux deux camps en même temps. Au pays des paranoïaques, le schizophrène est roi !
@Brunot : je fais les mêmes choses (à quelques détails près) sous Photoshop CS3 que je faisais sous Photoshop 6, c’est vrai. La philosophie de base de Photoshop n’a pas changé et c’est logique : calque, sélection, fusion, formes, autant de concepts inusables et indépassables quand on fait du pixel.
@briegel > Je suis obligé de poster tout en bas, il n’y a pas plus de niveau pour continuer la réponse sous la tienne… C’est correct par rapport à quoi ? Parce que personnellement, je n’ai jamais vu de polices s’afficher comme ça ni sur Mac ni sur Windows… :-/ ou alors sur un vieil OS avec un vieux navigateur… Je sais que Windows n’est pas fameux pour l’aliasing mais quand même non ?
Bah justement, non. En tous cas, c’est le cas si on n’a pas touché la config de base de Windows (je suis sous XP). J’ai quand même tenu à vérifier parce que ça m’a surpris aussi, et après quelques captures d’écran, c’est ce que j’ai relevé.
Ceci dit, ça change pas grand chose au fait que sous ‘toshop, tu peux modifier le lissage des polices pour avoir un rendu fidèle.
L’avantage de travailler sur photoshop ou illustrator au préalable est d’éviter pas mal de calculs de marges etc pour égaliser goutières et espaces entre les éléments en gardant une structure centrée. Surtout avec l’alignement sur la grille de pixels d’illustrator…
http://fr.wikipedia.org/wiki/Faux-texte
Excellent article 😉
Cependant HTML5 n’est pas près de se développer… car vu le nombre d’utilisateur utilisant des vielles version de IE et compagnie. Les Webmaster ne vont pas s’embêter a faire 2 versions du site…
Euh au niveau de l’égalisation des colonnes, c’est du gros useless le script… Soit tu passes une propriété CSS2 (le table cell), soit tu utilises la hack des colonnes factices. Alourdir la page avec un script, bof quoi.
Sinon bon article dans l’ensemble, même si certains points sont relativement discutables…
P.S. : t’as un gros bug dans tes commentaires, un chevauchement au niveau de tes related post…
Salut Bruno !
J’allais te dire, en mauvaise langue que je suis, qu’il n’est pas conseillé de mettre une largeur au body, car ça entraine un bug sur IE toutes versions.
Un exemple de ce bug est visible à cette adresse :
http://josselin.willette.free.fr/codessources/width-body/
Ce bug apparait uniquement lorsque le navigateur ouvre une nouvelle fenêtre sur le lien (avec un target= »_blank » par exemple) et disparait au moindre rechargement de la page.
En fait, un élément positionné relativement dans un body ayant une largeur prend pour référence le viewport au chargement et non le body.
Je disais donc que je suis mauvaise langue, puisque ton exemple fonctionne très bien, étant donné que le position:relative sur le body corrige ce fameux bug. 😉
Et il est intéressant de constater qu’avec une largeur et une couleur de fond au body, celle-ci s’étend à l’ensemble du viewport, sauf dans le cas où une couleur de fond est renseignée à l’élément html. Dans ce cas c’est cette dernière qui s’étend au viewport et celle du body se confine à son élément selon ses dimensions.
Salut Josselin !
Merci pour toutes ces précisions. Ouf, ça va, je n’ai pas trop perdu la main donc, on dirait 😉
Article très intéressant….et commentaires très instructifs également. Malgré l’intérêt que je porte à la plupart de tes articles Bruno, il est des thèmes récurrents dans tes billets qui tendent à laisser penser que le webdesign et une vraie charte graphique sont bien dispensables et peuvent rester aux vestiaires. Tu parles de coder directement dans le navigateur, d’oublier photoshop, et puis tu t’interroges sur la pertinence du design qui est « inutile » dans 80% des cas… et que sais-je encore.
A trop penser comme ça, et il suffit de voir les URLS des commentateurs qui te plus-soient sur ce sujet, on finit avec un web uniforme et 5000 sites qui se ressemblent, duplicatas de duplicatas sans réflexion visuelle en amont.
Je suis pour à 100% que les dévs prennent la main des intégrateurs qui prendront eux mêmes la main des graphistes. Que ça communique un peu et que ça ne tire pas le web vers le bas en restant dans une vision à oeillères qui se centre sur les seuls impératifs de son métier et oublie le reste de la Grande Chaîne du Web…en l’occurence le design.
Un peu de curiosité et de culture graphique que diable, le Webdesign ce n’est pas un emballage cadeau et un ruban pour faire joli !
A bon entendeur, et sans rancune 🙂
Papier-pixel — Salut, j’avais commencé à te répondre ici, mais finalement j’ai transformé cette réponse en billet. Cf. http://css4design.com/design-graphique-sites-web 🙂
Très bon articles, mais j’ai quand même une question :
Est-tu sur que l’utilisation des balises « Header » et « Footer » dans les balises « Articles » soit bien judicieuse ?
Je me dit que ces nouvelles balises sont bien pour bien séparer les différents éléments qui composent la page, mais est-ce aussi le cas pour les différents éléments qui composent un article comme tu le préconise ? cela ne vas t’il pas amener un désordre dans la structure de la page, donc gener le référencement par exemple ?
PS : Je suis aussi pour la conception graphique directement en HTML+CSS+JS, comme au siècle dernier dans la PAO avec Xpress, on ne faisait pas les maquettes dans Photoshop pour les intégrer après 😉 …
Les docs HTML5 sont très claires là dessus, header et footer peuvent et doivent être utilisées comme des entête et des pieds de pages pour des sections ( et/ou articles ). Donc, ça reste ouvert, à toi de voir ce qui te convient le mieux. C’est pareil pour « aside » d’ailleurs qu’on aurait tendance à mettre que pour la sidebar alors qu’il peut être utilisé dans d’autres cas de contenu complémentaire…
Donc la redondance des balises « Footer » et « Header » n’est pas un problème comme on peut le constater avec des balises identifié (ID) … ça me fait bizarre, mais bon, je prend note … merci pour ta réponse 😉
Personnellement, je m’y suis habitué même si ça peut devenir rapidement le bordel !! 😀
Pour ma part, je viens de tester une méthode d’amélioration progressive sur le dernier design de mon site : tout simplement prévoir un design en 800*600 pour tout le monde, et utiliser les média-queries pour gérer les améliorations (ce que IE va ignorer entre nous soit dit).
Pour l’exemple, je me suis amusé à prévoir un design plus large pour les navigateurs modernes (qui garderont le côté 800*600 si la résolution diminue)… l’idée pourrait être poussée : ajout des propriétés non supportées dans la média-query, etc. à mon sens, il y a des pistes à découvrir. 🙂
Merci pour ce document qui est clair et efficace.
D’ailleurs, as-tu lu l’excellent HTML5 for Webdesigners ?
( Oui, je débarque un mois après la guerre, excellent article 🙂 )
Pourquoi vous insistez sur IE?
Microsoft est toujours en retard en ce qui concerne les technologies open source et W3C.
Vaut mieux se contenter de Chrome et Firefox, mieux proteges, plus rapide et plus pratiques.
Conference web — simplement parce qu’en l’occurrence les adaptations ne prennent pas plus de 5 mn à mettre en place et que par ailleurs, si l’intégrateur web peut être force de proposition sur son lieu de travail, ses arguments contre IE résistent assez mal à l’analyse des statistiques de fréquentation par navigateurs effectuée par les petits gars du maketing ^^
Vous avez peut être raison. IE est toujours bien installe dans les grandes entreprises.
Cela dit, je ne l’utilise que pour vérifier la compatibilité. Tout mon travail de création est fait avec Chrome/Firefox 🙂
Merci Bruno !
ici c’est très clair.
Article très complet 🙂
En espérant que la version IE 9 comble son retard sur l’intégration du HTML5.
Sinon, voici un site de tutoriels vidéos en ligne proposant des vidéos sur du CSS3 :
http://www.formamotion.com/formavideos,7,10,CSS.html
🙂
Excelent arcticle! Merci 😉