JT

bbxdesign

Vestiges d'un CSS Guru

Mode normal → (affichage complet du blog)

Suivant

Précédent

w3c

bd cinéma couleur css firefox google gratuit ie6 interface iphone javascript microsoft musique navigateur new york photo photoshop theme vidéo wordpress

Le XHTML 2 c’est fini. Le HTML 5 s’en trouve renforcé.

Billet

w3c_main

Vous êtes sans doute au courant que le groupe travaillant sur le XHTML 2 va s’arrêter à la fin de l’année, pour notamment rejoindre le groupe du HTML 5. C’est moins laisser tomber quelque chose que se concentrer sur un seul standard.

Différence XHTML / HTML

La différence principale entre le XHTML et le HTML est la rigueur du code. Un document XHTML nécessite de n’inclure aucune erreur de syntaxe pour être bien rendu, alors qu’un document HTML peut se permettre de contenir certaines erreurs. Ca vient du moteur de rendu du navigateur qui gère les deux documents différemment. Ca ne veut pas dire qu’il faut être négligeant dans l’écriture du code pour autant. Mais c’est plus propre d’avoir à se tenir à une syntaxe rigoureuse.

Le HTML a l’avantage d’être davantage rétro-compatible. Les navigateurs plus anciens arrivent à mieux lire un document HTML récent qu’un document XHTML récent. Ca vient sans doute du côté “léger” de sa rigueur.

Concrètement, ça change quoi cette fin du XHTML 2 ?

A vrai dire, pas grand chose car c’est dans la logique des choses. Depuis quelques mois, le HTML 5 n’arrête pas de faire parler de lui. Les navigateurs commencent à bien l’implémenter (Safari 4, Opera et le tout récent Firefox 3.5). Et il a un gros potentiel. Pour en savoir plus, vous pouvez lire ma petite introduction au HTML 5.

Etant un adepte du XHTML 1.0 (pour des raisons de rigueur de code et pour éviter le Quirks Mode), je n’aurais pas à choisir entre le HTML 5 et le XHTML 2. Il n’y en aura plus qu’un. Et puis le HTML 5 aura aussi sa “version XML“. Donc je pourrais toujours imposer au document d’être totalement propre.

Je pense que cette fin du XHTML 2 est une bonne chose (même si ce n’est pas la fin du XHTML). Pas de casse-tête avec plusieurs standards à suivre, et un renforcement du HTML 5, ce qui va amener les navigateurs à être encore plus plongé dans le HTML 5 et va faciliter cette tâche.

Tableaux de support des standards sous IE6, IE7, Firefox et Opera

Billet

Pour savoir ce que l’on peut utiliser sans craindre une incompatibilité entre navigateurs, on peut se fier à ces tableaux des propriétés HTML, CSS, DOM et ECMAScript. Il manque juste Webkit dans le lot.
tableau-support-proprietes-css
Il y a par ailleurs un tableau résumant tout.

Un h1 pour le logo ou pas ?

Billet

A la question “Est-ce que je mets un <h1> pour mon logo ?”, je répondais oui avant. Maintenant, je réponds non.

Le débat

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 :

  • h1 pour le logo
    Etant donné que le logo porte le nom du site, c’est l’élément le plus important. Il doit donc être dans un <h1>, sur toutes les pages.
    Exemple : http://wordpress.org/
  • h1 différent par page, un lien pour le logo
    Le h1 doit représenter le contenu de la page. Ce dernier étant différent pour chaque page, il faut que le h1 change aussi.
    Exemple : http://simplebits.com/

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.

Le h1, le plus important et l’unique (?)

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.

Paradoxal le h1 ?

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 ?

Title et h1 : amis intimes

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 :

  • <title>Un h1 pour le logo ou pas ? < Blog < bbxdesign</title>
  • <h1>Un h1 pour le logo ou pas ?</h1>

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.

Un h1 est-il unique ?

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.

La solution optimale : un h1 différent par page, un lien pour le logo

Si je résume, le h1 :

  • décrit la section qui le suit
  • reprend une partie du title, qui lui-même décrit la page
  • est unique (selon moi)

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 ?

Les titres : une question d’ordre ou de poids ?

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.

Choisir des couleurs en fonction du contraste

Billet

Choisir des couleurs pour son site, c’est cool, parce qu’il n’y a pas de limites. Même si l’on est parfois contraint de respecter une certaine homogénéité lorsqu’il s’agit d’un client ayant déjà une charte graphique définie (même partiellement), les couleurs (et surtout leur association) sont un terrain de jeu quasi infini.

Mais le web, même si il est très graphique, reste un support pour le contenu. Et le média le plus répandu reste le texte. Dans ce cas là, le choix des couleurs doit tenir compte de certaines règles en matière de contraste pour éviter de rendre difficile voire impossible à lire votre site web. Le W3C possède une formule pour analyser ce contraste.

Analyser le contraste de son site

AccessColor est un outil gratuit qui analyse les CSS de votre site pour vérifier le contraste entre le texte et le fond. Il évalue alors la différence de luminosité et le contraste (en utilisant le formule du W3C). Mais il ne marche pas pour les images de fond. Mon site, comme vous le voyez, obtient un très mauvais score.

Analyse AccessColor de bbxdesign

Analyse AccessColor de bbxdesign

Trouver des couleurs suffisamment contrastées

Autant l’outil précédent est utile pour analyser, autant il ne permet pas de décider quelles couleurs utiliser à la place. C’est là que Particletree entre en jeu. En utilisant là encore la formule du W3C, ils ont écrit une fonction en PHP pour définir la couleur d’un élément en fonction de la couleur de fond. Bien sûr, tout ceci est dynamique.

Wufoo Charts

Wufoo Charts

Sortie de Colorzilla 2.0, avec son générateur de palette de couleurs

Billet

Ce matin en ouvrant mon navigateur préféré, une mise à jour de Colorzilla était disponible. Vous connaissez sans doute cette extension Firefox qui permet d’avoir un outil “pipette” dans votre navigateur. Ainsi, en naviguant sur un site, il suffit de cliquer sur l’icône Colorzilla et de placer le curseur sur un pixel d’un élément de la page pour connaître ses codes couleurs (RVB et Hexadécimal).

Souvent, lors d’une mise à jour, une page du site de l’extension s’ouvre pour vous décrire les maj installées. En général, je zappe rapidement cette page, pensant qu’il n’y a qu’une liste de bugfix sans intérêt pour ma part. Mais là, j’ai bien fait de lire les nouveautés.

Aujourd’hui, la version 2.0 de Colorilla est sortie. Quoi de neuf ? Et bien 2 fonctions bien pratiques :

  • Webpage DOM Color Analyzer
    En un clic, vous obtenez une palette de couleurs du site sur lequel vous êtes. Mais le must, c’est qu’il dresse la liste des éléments qui utilisent les couleurs en question. Il y a même la possibilité de sauvegarder la palette ou d’obtenir un permalien vers celle-ci. Voici un exemple avec mon blog :
    Webpage DOM Color Analyzer
    Un excellent outil pour obtenir les couleurs d’un site que vous appréciez.
  • Online Palette Viewer
    En complément de l’outil précédent, Colorzilla permet de visualiser, sauvegarder et partager les palettes de couleurs proposées par les utilisateurs. Par exemple, voici la palette du site du W3C. Vous remarquerez l’outil “pipette” en bas à gauche de la page, même si vous n’avez pas installé l’extension.

La version 2.0 porte plutôt bien son nom, avec son lot de fonctionnalités de partage très intéressantes, sans oublier la simplicité et l’efficacité du générateur de palettes.

Prémices du HTML 5

Billet

Ca faisait quelques temps que je voulais en parler. Cela fait suite à cet article de “A List Apart” : A Preview of HTML 5, dont ce post est entièrement inspiré.

Voici donc des infos sur le HTML 5. Cela correspond aussi au XHTML 5 (à la différence que ce dernier est exprimé en XML, ce qui apporte son lots de variations), qui passerait de la version 1.1 à la version 5 (et coller à celle du HTML). Bien évidemment, tout ceci n’est pas encore clairement défini, ce sont juste des versions alpha (et encore) développées par le W3C et le WHATWG.

Structure d’une page

Pour l’instant, les balises existantes définissent des titres, des paragraphes, des liens, des emphases, des abbréviations… Mais lorsqu’il est question d’établir les grandes parties d’une page, on doit se tourner vers l’inévitable balise générique : <div> (qui amènera l’horrible expression “coder en div”), balise qui ne signifie et ne représente rien. Que ce soit le header, le footer ou la sidebar, n’ayant pas autre chose sous la main, on utilise des <div> par défaut, auxquelles on applique des id spécifiques.

Le HTML 5 corrigera tout ça. On aura droit à des nouvelles balises très utiles :

  • header
  • nav
  • article
  • section
  • aside
  • footer

La structure d’une page pourra ressembler à ceci :

<body>
  <header>Bienvenue</header>
  <nav>Accueil - A Propos - Contact</nav>
  <article>
    <section>
      Prémices du HTML 5
    </section>
  </article>
  <aside>Catégories</aside>
  <footer>bbxdesign 2008</footer>
</body>

Plus léger et plus lisible. Il faut noter que dans sa syntaxe, une balise <article> pourra regrouper plusieurs balises <section>, ces dernières correspondants à des sous-parties d’un article.

L’intérêt n’est pas seulement pour l’intégrateur du site, mais aussi au niveau des moteurs de recherches. A l’heure actuelle, un moteur ne peut en aucun cas savoir que différentes parties existent dans une page. Il ne peut pas hiérarchiser ou utiliser ces parties.
Ces véritables balises de page pourront le permettre. Ensuite, libre alors aux moteurs de les interpréter à leur façon.

Question accessibilité, ces balises seront très utiles. La page étant bien hiérarchisée, on pourra facilement naviguer et sauter des parties, aller d’une section à une autre… Il suffira d’adapter les outils à cette nouvelle structure.

Balises Multimédia Audio et Vidéo

Lorsqu’il s’agit d’audio ou de vidéo dans les pages web, on pense tout de suite et exclusivement au lecteur Flash. Il s’est imposé par sa légèreté, ses fonctionnalités (streaming, multimédia…), son design. C’est tout simplement le seul moyen de partager de l’audio et de la vidéo facilement, avec des unités de contrôle, et une grande rapidité.

HTML 5 proposera une alternative grâce à ses balises <video> et <audio>. Par exemple, pour la vidéo on pourra définir :

  • la source
  • les dimensions
  • l’image de preload
  • le type de fichier
  • des contrôles

Bref, ça sera le strict minimum, histoire d’avoir la possibilité de lire des fichiers multimédia sans passer par Flash (surtout lorsqu’on ne le maîtrise pas).

D’autres nouvelles balises

Un petit tour sur le site du W3C permet de connaître quelques autres nouvelles balises qui vont venir enrichir le panel :

  • <dialog> : pour une conversation
  • <meter> : pour des unités de mesure
  • <time> : pour l’heure
  • <datagrid> : une représentation intéractive d’une arborescence ou de données tabulaires
  • <output> : pour définir le résultat d’un processus, par exemple celui d’un script

La liste des balises (et des attributs) s’agrandit pour mieux nous aider en tant que développeurs (facilité, flexibilité, lisibilité) mais aussi en tant qu’utilisateurs (accessibilité, intéraction, simplicité).

Sources :  A Preview of HTML 5 , HTML 5 differences from HTML 4

Opera veut forcer IE à respecter les standards

Billet

Opera VS IE

Voici une nouvelle action contre le mastodonte Microsoft et son statut très favorable de domination sur les systèmes d’exploitation. On se souvient du fameux Windows XP Edition N qui faisait suite à une plainte contre Windows Media Player. Cette fois-ci, c’est Opera qui s’y colle. Le navigateur norvégien a déposé une plainte à la Commission Européenne contre Internet Explorer en accusant le statut anti-concurrentiel de ce dernier (car livré en bundle avec Windows) et le non-respect des standards du W3C.

Lire la suite →

Populaire Tutoriels Fun

Idées de cadeaux originaux