CSS + WordPress + Web Design
26 May
Encore des plugins Firefox ? Oui, mais là, c’est différent :
In short, Jetpack is an API for allowing you to write Firefox add-ons using the web technologies you already know.
En gros, pour faire des plugins Jetpack, il suffit de s’y connaître en HTML/CSS mais surtout en Javascript. Tiens, “plugins”… “Javascript”… Ca rappelle exactement le plugin (XPI lui) Greasemonkey. Et dans un sens, ça rappelle aussi les bookmarklets.
Lire la suite →
17 May
Vous avez une image, vous voulez savoir d’où elle vient ? TinEye permet de trouver la source des images qu’on lui fournit. Par exemple, si je lui donne une image d’un de mes posts précédénts, sur le premier navigateur web, ça me donne d’autres sites qui utilisent une image similaire.
17 May
Pour chercher sur Google, Wikipedia ou Youtube, simultanément et rapidement, je dois dire que keyboardr a trouvé une formule efficace, en utilisant uniquement les flèches et la touche “Entrée” pour naviguer.
13 May
Je suis grand fan de ce genre de photos : des plans panoramiques à 360° de New York.
C’est intéractif, c’est fluide, et la qualité visuelle est au rendez-vous. Ca rappelle le Quicktime Virtual Reality mais en 20 fois mieux. Je me demande vraiment quel dispositif est utilisé pour prendre de telles photos.
Faites clic droit > Planet View. Vous verrez, c’est surprenant. 
12 May
A la question “Est-ce que je mets un <h1> pour mon logo ?”, je répondais oui avant. Maintenant, je réponds non.
Il existe un débat assez récurrent sur l’élément de la page qui portera le h1. Que ce soit dans un post ou deux, ou dans des commentaires, la question reste ouverte. Il y a 2 écoles :
Cas particulier : il arrive d’avoir un h1 pour le logo uniquement sur la page d’accueil, les autres pages ayant un h1 différent. Je classe ces sites dans la deuxième catégorie.
C’est quoi un h1 d’abord ? Selon le W3C, ça donne :
A heading element briefly describes the topic of the section it introduces. Heading information may be used by user agents, for example, to construct a table of contents for a document automatically.
Le h1 est le titre de premier niveau et doit introduire la section qui le suit.
Si le h1 est sur le logo, alors il est tout en haut. Il doit donc décrire tout ce qui le suit, c’est à dire, le reste de la page. Il ne faut pas le mettre sur le logo alors ?
Le titre de la page (balise <title>) est défini ainsi par le W3C :
The TITLE element is not considered part of the flow of text. It should be displayed, for example as the page header or window title. Exactly one title is required per document.
Le titre est unique et doit décrire le contenu de la page. C’est à peu près de cette façon que j’utilise mon h1 : il est unique et décrit la page. Il est pour moi différent pour chaque page, comme l’est le titre.
Par contre, le titre doit être davantage fourni que le h1. L’idéal pour ce post serait :
Mon titre décrit le contenu du document et d’où il provient.
Mon h1 décrit la section qu’il introduit : mon post.
Les deux sont complémentaires parce que l’un fait partie du flux du document, l’autre non. Ils ont donc un rôle légèrement différent.
Je viens de remarquer que Digg et A List Apart ont deux h1 dans la même page (lorsque l’on va dans les commentaires ou sur un article). Ca m’a surpris parce que j’ai toujours cru que le h1 était unique, comme l’est la balise title. Le W3C ne spécifie rien sur l’unicité des headings (h1,h2,h3…) mais étant donné qu’elle préconise d’utiliser une partie de la balise title pour son contenu, je présume qu’il faut que le h1 soit unique.
Si je résume, le h1 :
Cette équation a une seule solution : il y a un h1 différent par page, un lien pour le logo (à part éventuellement pour la page d’accueil, qui est un cas particulier).
Si le h1 doit décrire ce qui le suit et que je le mets sur le logo “bbxdesign” sur toutes les pages (il l’est actuellement uniquement sur ma page d’accueil), alors toutes mes pages auront comme contenu “bbxdesign” ? C’est très léger comme description de ma page, et très redondant, surtout pour les moteurs de recherche. Toutes mes pages ne parlent pas de “bbxdesign”. C’est juste le nom du site (qui est par ailleurs dans l’url). Mes pages ont toutes un contenu différent et je veux que mon h1 reflète ceci. C’est pour ça que ma page d’accueil a le logo comme h1, mais tous mes posts ont leur titre comme h1 (et le logo devient h2).
Le logo décrit le site, pas la page que l’on consulte actuellement. Après, il est possible de mettre deux h1, un pour le logo, un pour le titre du post par exemple. Mais cela voudrait dire que le premier h1 (celui du logo) affiche “bbxdesign”, et l’autre affiche “Un h1 pour le logo ou pas ?”. Pourquoi pas, mais je trouve que le second a davantage de poids et de légitimité que le premier. Et étant donné que l’on jusqu’à 6 niveaux hiérarchiques, pourquoi ne pas en tirer profit ?
Si le h1 n’est pas le logo, il se peut (et c’est mon cas) que le h1 ne soit pas le premier élément de la page, mais arrive après le header et la navigation. Est-ce que c’est problématique ? Je ne pense pas. Le W3C ne précise rien à ce sujet. Il faudrait plutôt se poser la question si les titres (h1,h2,h3…) sont davantage une question d’ordre ou de poids ?
A première vue, c’est surtout une question d’ordre. On a d’abord un h1, puis un h2, puis un ou plusieurs h3, puis peut-être un autre h2 suivi d’autres h3… A ce propos, il est interdit de “sauter” un niveau hiérarchique. On ne passe pas d’un h1 à un h3 sans avoir de h2. Il faut voir les h1-h6 comme des chapitres d’un livre.
Users should order heading elements properly. For example, in HTML, H2 elements should follow H1 elements, H3 elements should follow H2 elements, etc. Content developers should not “skip” levels (e.g., H1 directly to H3).
Pour le W3C c’est une question d’ordre. Mais il m’arrive de ne pas suivre cette règle à la lettre. Par exemple, dans une sidebar structurée, je mets des <h3> et des <ul> parce que c’est le poids que je leur donne par rapport au contenu de la page. Et mon post a lui aussi des h3-h6. Par conséquent, l’ordre de mes titres dans mon code peut passer du h6 au h3. Et ce n’est pas spécifique à la sidebar. Ca peut arriver lorsqu’il y a plusieurs zones dans la page avec un contenu différent.
Les titres h1-h6 restent des éléments assez mal utilisés (par moi d’abord), sans doute par manque de précisions de la part du W3C. En même temps, c’est peut-être têtu de s’obstiner autant. Parce qu’en ayant d’un côté le W3C (avec les soucis de standardisation et d’accessibilité) et de l’autre les moteurs de recherche (qui analysent minitieusement notre code), couplés à un flou autour de la définition de l’utilisation des titres, on se demande parfois si la solution est unique.
11 May
Le premier navigateur Web dénommé “WorldWideWeb” créé par Tim-Berners Lee tournait sous un ordinateur NeXT, et faisait office d’éditeur aussi. A la base un outil pour aider les scientifiques à s’échanger des informations, le Web a pris une dimension bien plus grande.
If households nowadays want a computer, it is not to compute, but to go on the Web.
WorldWideWeb : le premier navigateur web
6 May
Je me suis posé la question de savoir combien était divisé mon temps pendant que j’intégrais. J’ai divisé en 5 parties ce temps (peut-être en oubliant des parties) et évalué grossièrement leur répartition. Je suis arrivé à ce graphique :
Je code toujours en XHTML 1.0 Strict, et ça m’a évité pas mal de problème de Quirksmode je me rends compte. J’utilise au maximum les balises sémantiques <p>,<ul>,<label>,<hn>,<strong>… mais je suis de moins en moins réticent à multiplier les <div> et <span>. D’un côté, c’est cool d’éviter la divite, c’est joli, c’est léger. Mais en pratique, et surtout pour les gros sites, il faut être très spécifique quant aux styles à appliquer à certains éléments. Donc je rajoute une ou deux div par ci par là pour améliorer ma productivité et surtout la flexibilité du code. Ca facilite grandement la différenciation. Et ça permet surtout de prévoir d’eventuelles évolutions de fonctionnalités, et avoir une approche plus modulaire.
A force de prôner la séparation HTML (contenu) / CSS (mise en page), on a peur de modifier le HTML, comme si c’était devenu interdit voire impossible. Je me dis que les développeurs ne sont pas bien méchants et que l’on peut leur demander des modifs HTML, avoir plusieurs classes sur un même élément au lieu de répéter son code CSS pour pas grand chose (voir plus bas).
C’est évidemment très lié au HTML utilisé. Depuis quelques temps, je me suis fait un fichier reset.css qui utilise le Reset CSS de Yahoo! . Par contre, ce n’est pas un fichier que j’importe à chaque fois mais un code que je copie-colle en créant ma CSS. Parce que oui, je préfère garder une seule CSS pour tout le site. Niveau lisibilité, je n’ai pas trop de problème à utiliser un seul fichier parce que j’écris chaque sélecteur CSS sur une seule ligne. Niveau productivité, répartir des propriétés sur plusieurs CSS c’est passer beaucoup de temps de l’une à l’autre, trouver où se trouve ce sélecteur, éviter les conflits… J’évite. Et le seul vrai avantage d’avoir plusieurs CSS, c’est d’en appeler certaines dans certains cas, et d’autres dans les autres cas. Je préfère mettre une class au body pour différencier les pages, c’est beaucoup mieux.
Les exceptions pour utiliser plusieurs CSS sont : un fichier pour ie6, un fichier par couleur (si il y a des thèmes par couleur) et un fichier pour le print.
Je fais encore pas mal de contextualisation (ex: .bloc table tbody td.direction ) parce que ça permet d’éviter les conflits. + de contextualisation = – de classes à créer
Il y aussi le cas où vous voulez que plusieurs éléments HTML aient les mêmes propriétés CSS Dans ce cas, il y 3 choix :
La première méthode est à éviter : si on veut changer une propriété (ex: la couleur d’une bordure), il faut le changer autant de fois que l’on a copié-collé.
La deuxième méthode est la plus propre : le HTML reste relativement léger (= non alourdi de classes) mais la CSS est plus longue à maintenir. C’est ce que je faisais avant.
La troisième méthode est plus “modulaire” je dirais. Un élément HTML aura par exemple : class=”.maclasse .manouvelleclasse”. On rajoute donc une classe aux éléments qui ont le même style. Mmmh. Est-ce que c’est bien ? Est-ce que l’on sépare bien la mise en page du contenu ? Plus ou moins je dirais. En fait, dans le HTML, on ajoute la classe à tous les éléments qui doivent appraître de la même façon. Et si on veut plus qu’un élément n’aie plus ces propriétés ? Il faut supprimer la classe dans le code HTML. Ah. C’est pas bien. On ne devrait plus avoir à toucher au code HTML. En théorie, c’est vrai. Mais en pratique, c’est, d’une part, très rare de vouloir changer le style d’un seul élément, et d’autre part, pourquoi n’aurait pas-t-on le droit de modifier le HTML ? Une fois livré, on ne peut plus rien faire (voir § sur le HTML) ?
Je dois préciser une chose importante : cette méthode modulaire, je l’utilise surtout pour les blocs et les gros éléments, pour les éléments qui structurent et divisent l’affichage. Il faudrait que j’envisage de faire un article avec des exemples plus éloquents.
J’ai déjà parlé de ce que l’on pourrait faire si IE6 n’existait plus. En fait, rendre un site compatible IE6, c’est du débuggage pur et simple. On doit utiliser des overflow:hidden, position:relative, display:inline… pour aucune raison valable si ce n’est faire plaisir aux internautes du siècle dernier (ou presque). Sans compter tout ce que l’on est privé de faire. Bref, une calamité.
Dans mon souci d’avoir un code lisible, pour moi et ceux qui retoucheront aux CSS, j’essaye d’avoir des noms de class/id simples mais efficaces. Simple, ça veut dire court. Avec 4 lettres, on peut faire pas mal de choses : .bloc, .nav, .main, .side… J’ai par exemple remplacé .pagination par .page. Ou mettre .srv au lieu de .service. C’est pas très méchant et ça permet d’avoir une CSS bien plus lisible (surtout si l’on contextualise ET que l’on met tout sur une ligne).
Et si je passe autant de temps, c’est aussi pour éviter d’appeler un élément “grillade” par exemple (alors que ça n’a rien à voir avec un barbecue). J’ai vérifié, elle y est encore.
Dernier point : découper le PSD. On voit directement si un PSD est fait par quelqu’un qui sait intégrer ou pas. J’ai de la chance, c’est souvent le cas. Mais lorsque ça ne l’est pas, il faut voir les effets de dégradés, les superpositions, les ombres qui dépassent… qui n’ont l’air de rien graphiquement, mais qui sont une calamité à intégrer. D’ailleurs, c’est une calamité à cause d’IE6! Parce que pour IE6, il faut tout aplatir! L’ombre doit aller avec l’élement qui la fait ET avec l’élément où elle se projette. N’est-ce pas logique ? Et bien non. Vive les PNG. C’est tout.
J’ai essayé de faire un rapide panorama de ce que doit faire un intégrateur. On se rend compte que le grand ennemi reste IE6. Les 40% cités correspondent au temps de débuggage, mais je suis sûr qu’on peut gagner du temps dans les autres domaines (découpage, css, html) si il n’y avait pas IE6. J’ai peut-être oublié des éléments, je ne sais pas. Vous avez des idées ? Des remarques ? Des critiques ?
4 May
The do’s and don’ts of modern web design regroupe les bonnes pratiques (do’s) et les mauvaises pratiques (don’ts) en web design. A chaque fois, un lien est fourni vers un article expliquant pourquoi c’est une bonne ou mauvaise pratique.
Dans les do’s on trouve par exemple :
Il faut dire qu’en l’occurence le conseil “Mix and match Classes” contredit un peu le “Write good class and id names” parce qu’il crée une classe “bordered” (bouh pas bien). Mais dans l’ensemble ça reste cohérent.
Dans les don’ts (à éviter donc) on a par exemple :
Le site aurait du rajouter “oublier de faire un lien sur le logo du site”!
3 May
Nyle “Let The Beat Build” from Nyle on Vimeo.
Une vidéo de grande qualité, dans sa conception et sa réalisation. Je suis étonné par la qualité du son (enregistré directement). Les prises de son ont du se faire à plusieurs endroits, puis masterisé après. Et j’ai bien aimé la phrase “I don’t need a sample, I’ve got a girl with a banjo”.
