Après avoir tenu ce discours : «Non les formulaires, on ne peut pas les styler, désolé» pendant des années, les webdesigners les plus tenaces sont revenus avec des exemples de sites en nous disant : «Tu me dis que c’est pas possible, mais là sur tel site, ils l’ont fait.»”

Ok, reprenons : styler des éléments de fomulaire html, ça ne donne pas un résultat terrible, mais… avec javascript on arrive à voir un résultat plutôt satisfaisant. La question est : faut-il utiliser du JS pour faire de la cosmétique ? Parce que la seule chose qu’on fait avec JS ce n’est pas styler des éléments de formulaires, mais au mieux cacher des éléments de formulaires (ou les rendre invisibles) pour leur substituer des éléments graphiques, au pire remplacer des éléments de formulaires par d’autres balises html qui elles pourront être stylées avec CSS. Par exemple, remplacer un select par une liste non ordonnée. Est-ce que le jeu en vaut la chandelle ? Est-ce qu’on va alourdir les pages et retarder leur affichage pour quelques effets que l’utilisateur ne remarquera même pas ?

La question que tout le monde se pose (ou peut-être qu’il n’y a que moi qui me la pose), c’est pourquoi on ne peut pas styler les éléments de formulaire ? Ok pour les input de type texte (et encore pas avec tous les navigateurs), mais pourquoi pas les listes déroulantes de type select, les cases à cocher ou autres boutons radio ? Y-a-t-il une raison à ça ou les fabricants de navigateurs, se sont dit : «oups, on a oublié les formulaires !» «Laisse tomber on va dire que c’est fait exprès.»

Argumentons dans le sens où c’est fait exprès : les internautes ont l’habitude de leur système d’exploitation, du coup ils vont toujours identifier ces éléments quelque soit le navigateur dans lequel ils sont, et ça en terme d’utilisabilité c’est imbattable ! Mouais, pas vraiment convaincant tout ça…

Est-ce qu’on se posait la question avant ? «Fais moi ça en flash c’est plus joli». Ce serait de la faute de flash, alors ? Toujours est-il qu’on trouve de plus en plus de plugins qui permettent de faire ça facilement, tentant, non ? J’en ai essayé deux ou trois, je vous donne mon avis :

jQuery UI selectmenu

Pas des plus facile à manipuler, mais très complet, il couvre largement le spectre des utilisations de menus avec des listes déroulantes. Trop de styles inline qui complique le skinning des css externes. A noter que ce plugin utilise les attributs ARIA pour l’accessibilité.

jQuery UI checkbox

Simplissime. Par exemple pour une case à cocher il suffit d’initialiser le script de cette façon $('input').checkBox();
Et la case à cocher est remplacée par un span avec la classe “ui-checkbox”, il ne reste plus qu’à appliquer les CSS.

jQuery Stylish select

Je ne l’ai pas testé personnellement, mais ça a été utilisé sur un projet récent dans ma boîte. Complètement customisable en CSS et ultra light.

Uniform

Je suis tombé sur celui-ci il y a quelques jours, il me parait assez complet et facilement skinnable, une image sprite pour tous les éléments (vous pouvez créer des thèmes et les proposer sur le site), une fois les éléments stylés la navigation au clavier me parait correcte, reste juste à mettre plus en avant le focus sur les éléments.

Après c’est vous qui voyez… Personnellement, je ne trouve pas ça indispensable, mais pourquoi pas si les contraintes de conception ne sont pas trop draconiennes.

Bon je repose ma question aux concepteurs de navigateurs : Pourquoi les éléments de formulaire ne peuvent être stylés de la même façon que les autres balises html ?

D’abord pourquoi passer à HTML5 alors que pendant des années on a seriné à tous ceux qui voulaient l’entendre que XHTML, c’est l’avenir, il y a rien de mieux et que franchement HTML c’est has-been (ok je caricature, mais à peine). Est-ce que tous ces évangélistes aussi prompts à faire du prosélytisme auraient retourné leur veste ? Effectivement nous de notre côté on a pu avoir des doutes au début et puis on s’est rendu compte que ça changeait pas grand chose finalement, on peut très bien continuer à faire du XHTML dans la syntaxe en utilisant les nouvelles balises HTML5, c’est vrai que Les Intégristes ont l’avantage de parler à des professionnels qui ne portent pas forcément Internet Explorer dans leur cœur. En revanche l’avantage et qui n’est pas des moindres c’est qu’HTML5 intègre ARIA et en terme d’accessibilité c’est un grand pas en avant. Si vous voulez un petit rafraichissement de mémoire allez voir par là, la traduction qu’avait faite Pierre de Introduction to WAI ARIA.

Si pour un blog ou l’administration d’un site on peut s’amuser avec HTML5 et CSS3 en ajoutant les JS qui vont corriger les déficiences d’Internet Explorer (http://code.google.com/p/html5shiv/ et http://www.keithclark.co.uk/labs/ie-css3/), il est moins possible de le faire pour un site grand public générant un chiffre d’affaires de plusieurs millions d’euros. Le moindre ko est traqué et il serait risqué de s’appuyer sur un script qui demain pourrait ne plus être mis à jour et créer pas mal de désagréments.

Plusieurs solutions :

• Continuer à faire du bon vieux XHTML 1 et CSS 2.1
• Faire accepter qu’avec IE ce sera moins bien
• Faire du code forking, comme on faisait avant que des bibliothèques JS gèrent ça pour nous : une version pour IE une version pour les autres
• Prendre le risque des solutions JS quand même

Aucune de ces solutions n’est parfaite mais les intégrateurs et développeurs sont tellement impatients d’utiliser des specs qui sont encore à l’état de brouillon, que je suis sur que les arguments ne manqueront pas pour vanter les mérites d’une technologie balbutiante, quitte à faire le travail deux fois.

Un petit tour d’horizon sur ce qu’il faut savoir de HTML5 et CSS3, comment l’utiliser, quelles solutions JS, etc. :

• Les specs officielles :
  • http://dev.w3.org/html5/spec/Overview.html
  • http://www.w3.org/Style/CSS/current-work

  On n’y coupe pas !

• HTML5 et l’accessibilité
  • http://on-air.hiseo.fr/html5/html5-accessibilite-aria-wai-microformats/
  • http://www.cfit.ie/news-and-commentary-archive/96-wai-aria-in-html5
• Quelques lectures intéressantes sur le sujet :
  • http://diveintohtml5.org/
  • http://www.fredcavazza.net/2009/09/10/html-5-css-3-une-revolution-pour-les-interfaces-web/
  • http://html5doctor.com/
  • http://desgeeksetdeslettres.com/blog/programmation-java/html5-audio-et-video
  • http://www.seomix.fr/web/developpement/videolink-javascript-video-html5/
  • pas mal de liens sur html5 et css3 sur maxdesign.com
• Faire du html5 quand même :
  • http://52framework.com/
  • http://css3pie.com/
  • http://code.google.com/p/html5shiv/
  • http://www.keithclark.co.uk/labs/ie-css3/
  • http://media1.smashingmagazine.com/wp-content/uploads/images/html5-cheat-sheet/html5-cheat-sheet.pdf
• Démos et tutos
  • http://www.1stwebdesigner.com/resources/css3-tutorials/
  • http://dev.opera.com/articles/view/custom-html5-video-player-with-css3-and-jquery/
  • http://html5tutorial.net/
  • http://html5demos.com/
  • http://ie.microsoft.com/testdrive/Default.html
• Où en est votre navigateur ?
  • http://www.html5test.com/
  • http://www.findmebyip.com/litmus#target-selector
  • http://www.quirksmode.org/dom/html5.html
  • http://html5readiness.com/
  • http://w3c.html5.free.fr/

Et vous quel usage faites vous d’html5 et ses amis ? Applicable en milieu professionnel ou à réserver pour des projets isolés ?

Les listes de définitions ne varient que légèrement par rapport à d’autres types de listes, ce type de liste est composé de deux parties : un terme et une description.

L’utilisation la plus appropriée est donc celle où un mot ou une expression : <dt> serait défini par une courte explication : <dd>, comme dans un dictionnaire ou un glossaire, par exemple.

Mais si nous allons plus loin, les recommandations donnent également l’exemple d’un dialogue ou le personnage serait défini par la balise <dt> et son dialogue par la balise : <dd>, mais uniquement dans les recommandations de html 4.01 et xhtml 1.0. Dans html 5, les listes de définitions ne doivent pas servir à mettre en forme un dialogue, puisqu’initialement la balise : <dialog> devait servir à cet effet. Cette balise ayant été retirée en septembre dernier sans être (encore ?) remplacée. On reste dans l’expectative…

Concrètement, quel usage est-il fait de la liste de définition dans les sites que nous consultons tous les jours ? Est-ce qu’une liste de diffusion peut être utilisée pour un menu de navigation ? A mon sens non, puisqu’il existe les listes ordonnées : <ol> et non ordonnées : <ul> qui me semblent plus appropriées. Est-ce qu’une liste de diffusion peut remplacer un titre : <dt> = <h1> et un paragraphe : <dd> = <p> ? Réponse : non, mais c’est souvent la solution que nous avons trouvé pour répondre aux demandes des services chargés du référencement qui souhaitaient structurer les pages des sites avec des balises : <h1> à <h6> mais éviter certaines parties annexes dans les plans de document (mise en avant de promotions, services, etc.)

La seule utilisation parfaitement adaptée que j’ai pu trouver pour ces balises (hormis les exemples donnés par le W3C) concerne la structuration d’une FAQ. <dt> pour la question et <dd> pour la réponse.

Est-ce qu’il ne faudrait pas créer un autre type de liste qui conviendrait mieux pour mettre en relation deux éléments comme acteur/personnage, auteur/titre de livre, action/résultat, etc. ? Ce qui, selon moi, n’est manifestement pas le rôle de la liste de définition telle qu’elle a été « pensée » initialement.

Qu’elle soit intuitive, claire, que le regroupement des catégories soit logique, que les risques d’erreurs soit limités, que les messages d’information soient clairs ?
Tout ça et bien d’autres choses encore.

Je voudrais aujourd’hui parler plus particulièrement des boutons d’actions que ce soit des boutons de validation de formulaire ou des liens de navigations.

En général et dans la plupart des sites professionnels il sont particulièrement mis en valeur (avec plus ou moins de succès) pour que l’internaute sache comment naviguer et comment valider ses formulaires. Dans la vraie vie, en appuyant sur un bouton on s’attend à ce qu’il s’enfonce ou du moins qu’il réagisse à notre action par un changement d’état ou par l’émission d’un son. Je me demande pourquoi cette convention parfaitement adaptée aux interfaces de sites web n’est pas appliquée systématiquement, surtout que pour les boutons de validation, le langage html intègre ce comportement par défaut ? Dans la plupart des cas le mode :hover et préféré au mode :active, si bien qu’on a l’impression d’avoir une réponse en décalage avec l’action. Je survole le bouton = changement d’état (voire état enfoncé), je clique = rien. ça peut paraitre anodin comme ça mais testez la différence sur un site qui se rapproche d’une interface physique avec des changement d’état au clic et vous me direz quelle version vous préférez.

Le site web Metalabdesign.com, est un bon exemple de mise en application de ce principe :

Pour un code html donné :

<div id="container">
    <div class="level1">
        <div class="level2">
            Texte centré en hauteur<br />
            sur plusieurs lignes
        </div>
     </div>
</div>

Appliquons un code css qui va permettre de considérer la div contenant le texte comme une cellule de tableau :

div{width:500px;}
#container{height:80px;background-color:red;display:table;}
.level1{display:table-cell;vertical-align:middle;}

Le conteneur (#container) est considéré comme étant l’élément table (cette ligne n’est pas obligatoire comme nous l’avons vu dans un autre article des Intégristes qui explique le fonctionnement du display:table), la div qui a la classe level1 est considérée comme étant une cellule de tableau et se comportera de la même manière. Pour centrer le texte en hauteur on lui applique le couple propriété/valeur vertical-align:middle.

Un petit tour des navigateurs les plus communément utilisés, nous permet de nous rendre compte que cette solution ne convient pas à Internet Explorer (6 et 7). Nous allons nous servir de la div.level2 qui n’avait aucune utilité dans l’exemple précédent pour appliquer le code CSS suivant uniquement à Internet Explorer en utilisant les commentaires conditionnels HTML :

<!--[if IE]>
<style type="text/css" media="screen">
div{width:500px;}
#container{height:80px;position:relative;background-color:red;}
.level1{position:absolute;top:50%;}
.level2{position:relative;top:-50%;}
</style>
<![endif]-->

Pour que le code css précédemment créé et qui fonctionne dans les navigateurs hors IE ne s’applique pas à IE, nous allons ajouter, les commentaires suivants :

<!--[if !IE]>-->

<!--<![endif]-->

Ce qui donne

<!--[if !IE]>-->
<style type="text/css" media="screen">
div{width:500px;}
#container{height:80px;background-color:red;display:table;}
.level1{display:table-cell;vertical-align:middle;}
</style>
<!--<![endif]-->

Vous allez certainement me poser ma question : pourquoi ne pas appliquer la deuxième solution à tous les navigateurs et pas uniqument à IE6 ?
Tout bonnement parce que la deuxième solution ne fonctionne que dans IE !

Plus d’exemples dans ce tutorial vraiment complet du blog In The Woods »

Pourquoi ce formulaire ne fonctionnait pas , Tout bonnement parce que les personnes qui sont auteurs du code ont préféré se servir de javascript pour la validation des données plutôt que d’opter pour la solution html du bouton de type submit (button ou input) . Le script utilisé ne prenant visiblement en charge que certains navigateurs dans un seul environnement (windows), il est impossible pour l’internaute de valider les données qu’il a entré minitieusement dans les 45 champs du formulaire.

Le problème ne se pose pas uniquement lorsqu’on travaille avec os Mac ou Linux comme environnement, il se pose également pour quiconque se sert d’un autre navigateur qu’Internet Explorer pour commander, par exemple, sur un site de voyages qui a le monopole du transport ferroviaire…

Comment faire pour ne pas exclure des clients potentiels de votre site ?

Construisons notre formulaire en plusieurs étapes :

 
1° étape :  la construction du formulaire en html

La balise <form> :  elle définit un formulaire dans une page web.

Ses attributs :

* method

-  method= »post », indique que les données sont stockées dans le corps de la requête,  le contenu du formulaire est envoyé au serveur en tant que bloc de données pour y être traité.

- method= »get », indique que les données sont codées dans l’url,  le contenu du formulaire est juxtaposé à l’adresse URL

* action

- action= »url », action indique l’adresse d’envoi

* enctype

Ce paramètre ne peut être utilisé qu’accompagné par la méthode post. Il définit le type d’encodage des données, par exemple :

- enctype= »application/x-www-form-urlencoded »,  encode le contenu du formulaire selon une forme url

- enctype= »text/plain », le contenu du formulaire est retourné en format texte.t texte lisible par le destinataire; option accompagnée le plus souvent de ACTION=mailto:

- enctype= »multipart/form-data », permet d’expédier un fichier attaché au message.

La balise <fieldset> : elle regroupe des éléments dans un formulaire, par exemple état civil, adresse, etc.

Ses attributs : 

- Tous les attributs habituels des autres balises (id, class, title, etc.)

<legend>

Les balises des champs des formulaires :

<input>

Cette balise dans ces différents type permet l’entrée des données, qu’elles soient libres (text), soumises à un choix (radio) ou pour la validation du formulaire (submit) 

Ses attributs de type : text, password, radio, checkbox, submit, reset, image, hidden, file, button.
Ses autres attributs : name, value, checked, disabled, readonly, size, maxlength, src (pour les input de type image), alt (pour les input de type image).

<textarea>

Comme son nom l’indique il s’agit d’une zone dans laquelle on peut saisir du texte (sur plusieurs lignes).

Ses attributs : name, rows, cols, disabled, readonly.

<select>

La balise <select> permet de présenter plusieurs options de choix sous forme d’une liste déroulante.

<option>

La balise <option> permet de définir une option dans un menu (select).

<optgroup>

Les options de même type peuvent être regroupées dans un groupe d’options.

<button>

La balise button (avec l’attribut type= »submit ») permet de valider les formulaires comme un input de type submit, tout en ayant la particularité de permettre d’insérer du code html (comme du simple  texte ou une image) entre sa balise ouvrante et sa balise fermante, ce qui laisse beaucoup plus de possibilités qu’un simple champs input.  Mais attention, dans Internet Explorer ce qui est compris entre <button> et </button> sera interprété comme étant la valeur du bouton, même si un attribut value indique une valeur différente, de plus internet explorer ne retournera pas exactement ce qui est entre les deux balises mais une interprétation de ce qui se trouve entre les deux balises.

Ses attributs de type : button, submit, reset.
Ses autres attributs : name, value, typename.

Concernant le type reset pour les boutons, qu’ils soient construit avec la balise <input> ou la balise <button>, l’utilité de cette option me semble pour le moins limitée, pourquoi voudrait-on remettre à zéro les champs d’un formulaire qu’on vient juste de remplir ? Ne risque-t-on pas d’effacer malencontreusement toutes les données saisies ? Un exemple parlant : essayez de remplir ce formulaire et de le valider ensuite… Sur quel bouton avez-vous été tenté de cliquer ?

L’attribut name des champs de formulaire permet d’identifier chacun des éléments du formulaire et est indispensable pour récuperer les données du formulaire (cet attribut est déprécié uniquement sur les balises suivantes : a, applet, form, frame, iframe, img, et map). L’ajout d’un id à chaque élément est nécessaire pour rattacher chaque champs à son label. Id ne fait pas double emploi avec name

La balise <label>

Littéralement, label signifie étiquette. Cette balise permet de rattacher un nom au champs d’un formulaire, elle permet également d’agrandir la zone de focus ou de clic, très pratique notamment pour les boutons radio ou des cases à cocher dont la zone de clic est réduite.

attribut : for

Un exemple de formulaire html conçu en suivant ces recommandations :

<form action="inscription.php" method="post">
     <fieldset class="etat-civil">
          <legend>Etat civil</legend>
         <label for="nom">Nom</label>
         <input id="nom" name="nom" type="text" /><br />
         <label for="prenom">Prénom </label>
         <input id="prenom" name="prenom" type="text" /><br />
         <label for="date-de-naissance">Date de naissance</label>
         <input id="date-de-naissance" name="date-de-naissance" type="text" />
     </fieldset>
     <fieldset class="adresse">
          <legend>Adresse</legend>
          <label>Rue</label>
          <input id="rue" name="rue" type="text" /><br />
          <label>Code postal</label>
          <input id="code-postal" name="code-postal" type="text" /><br />
          <label>Ville</label>
          <input id="ville" name="ville" type="text" />
     </fieldset>
     <button onclick="alert(this.value)">Valider</button>

Les éléments de formulaire sont de type inline, sauf les éléments <form> et <fieldset> qui sont de type bloc.

Selon les besoins de présentation du formulaire on pourra intercaler des éléments <div> ou <p> pour structurer le formulaire (le débat reste ouvert sur l’utilisation de l’une ou l’autre des balises)

2° étape : Ne pas oublier les bonnes pratiques !

• En cas de rejet des données saisies dans un formulaire, les champs contenant les données rejetées sont indiqués à l’utilisateur.
• En cas de rejet des données saisies dans un formulaire, toutes les données saisies peuvent être modifiées par l’utilisateur.
• Les champs obligatoires des formulaires sont indiqués.
• En cas de rejet des données saisies dans un formulaire, les raisons du rejet sont indiquées à l’utilisateur.
• Les étapes des processus comportant des interactions multiples (commande, formulaires répartis sur plusieurs pages, etc.) sont décrites et imprimables avant leur commencement.

La liste exhaustive des bonnes pratiques pour les formulaires est consultable sur le site des bonnes pratiques Opquast

3° étape : Utilisation du javascript : Ajout de fonctionnalités et vérification du format des données.

Javascript est défini comme une surcouche à html et doit donc être distinct de ce dernier selon la règle de séparation du contenu, de la forme et des comportements. Un formulaire pour être accessible doit pouvoir fonctionner sans javascript. Javascript n’étant là que pour apporter plus de conforts à l’utilisateur. On pourra donc tester si un champs est vide ou bien compléter, si une date, un code postal ou un numéro de téléphone est renseigné dans le bon format. Cette première « validation » javascript peut être faite soit lorsque le bouton valider est cliqué, soit au fur et à mesure de la saisie en utilisant la techno Ajax, la dernière solution étant la plus communément utilisée aujourd’hui.

Exemples de formulaires vérifiés avec javascript :

1. Formulaire d’inscription du site Remember the milk

   

2. Formulaire d’inscription du site Jamendo

   

Exemples d’Aide à la saisie avec javascript :

1. Formulaire d’inscription du site CDiscount

   

2. Formulaire d’inscription du site Twitter

   

4° étape : la validation des données

L’utilisation de javascript nous a permis de vérifier le formulaire sur différents points : champs obligatoires non renseignés, formats non conformes, etc. au fur et à mesure de la saisie sans envoyer de requête inutile au serveur. Toutefois, il ne faut pas perdre de vue que sans javascript ces éléments doivent également pouvoir être testés.

Ce que nous ne pouvons pas tester en javascript sera testé après l’envoi des données, par exemple : est-ce que l’identifiant choisi n’existe pas déjà dans la base de donnée ?

Une fois toutes ces données testées, elle pourront être ajoutées à la base de données.

Dernier test à effectuer : désactivez javascript dans votre navigateur pour vérifier que le formulaire est accessible !

Alors que les intégrateurs, développeurs, webmasters et au sens le plus large, les créateurs de sites web échangent sur la meilleure façon d’utiliser javascript pour maintenir un site accessible, les professionnels du référencement n’hésitent pas à conseiller à leurs clients de faire des liens en javascript ou à générer des parties de leur code html via javascript de manière à ne pas référencer certaines pages ou certaines parties de leur contenu dans le but de favoriser des pages au profit d’autres. Les robots n’étant pas à l’heure actuelle en mesure de comprendre et donc d’interpréter le javascript, les liens JS ne seront pas suivis et le contenu généré ne sera pas pris en compte. J’ai également lu dernièrement que les robots seraient (je mets cette information au conditionnel) en mesure de décrypter les url dans le code javascript et donc de suivre ces liens comme des liens html, ce qui oblige actuellement les référenceurs à adopter des méthodes de cryptages – dans la limite de ce qu’il est possible de faire en javascript – pour leurs url !

Cette pratique loin d’être confidentielle se répand comme une traînée de poudre sur les sites de e-commerce français où les liens <a href="link"> sont remplacés par des <span onclick="fonction()">. (L’exemple le plus flagrant en est donné sur la page d’accueil du site de vente en ligne rueducommerce.fr sur laquelle pratiquement aucun lien de type <a href="link"> n’est présent.)

Pour bien comprendre ce que ça implique, il faut d’une part rappeler que cette pratique va totalement à l’encontre des règles d’accessibilité les plus élémentaires :

En effet toute personne ayant javascript désactivé pour une raison ou pour une autre ne pourra pas afficher la page liée. Les personnes ayant javascript activé ne pourront pas utiliser le clic milieu de leur souris ou l’option ouvrir un nouvel onglet de leur menu contextuel. Ce procédé restreint donc les possibilités de l’utilisateur qu’il ait ou pas javascript activé dans son navigateur. Il est important de rappeler que la conception de pages avec le langage html répond à des normes : les standards du web, dont les recommandations sont rédigés par le W3C, organisme qui supervise le développement des standards du web, et pour que ces pages puissent fonctionner de façon satisfaisante dans les principaux navigateurs du marché, ces recommandations ou règles doivent être suivies. Il est également important de rappeler que de nombreuses applications et extensions, notamment celles de Firefox sont basées sur ce socle commun qu’il est primordial de respecter, faute de quoi l’utilisateur s’en trouve obligatoirement lésé.

Lisons ce qu’il est dit dans la documentation du groupe WAI du W3C, référence majeure pour l’accessibilité des sites web :

WCAG 1.0 (version par lagrange.net)

Guideline 6. S’assurer que les pages qui contiennent de nouvelles technologies se transforment de façon élégante.

6.3 S’assurer que les pages soient visibles lorsque les scripts, les applets ou autres artefacts programmables sont désactivés ou non supportés. Lorsque ce n’est pas possible, fournissez une information équivalente sur une page alternative. [Priorité 1]
Par exemple, assurez vous que les liens qui activent les scripts fonctionnent même lorsque ces derniers sont désactivés ou non supportés (par ex. Il ne faut pas utiliser « javascript: » comme cible des liens).

W3C : Techniques pour les règles d’accessibilité du contenu Web 1.0 (version par lagrange.net)

4.12.1 Scripts de transformation

Les développeurs de contenu doivent s’assurer que les pages sont accessibles avec les scripts désactivés ou dans des navigateurs qui ne supportent pas les scripts.

* Eviter la création de contenu à la volée par le client. Si un navigateur d’utilisateur ne gère pas les scripts, aucun contenu ne sera généré ou affiché. Cependant, Ceci est différent lorsqu’il s’agit d’afficher ou de cacher un contenu déjà existant en utilisant une combinaison de feuilles de style et de scripting ; S’il n’y a pas de scripts, le contenu sera tout de même affiché. Cela ne s’applique pas aux pages générées à la volée par le serveur et distribuées au client.
* Eviter la création de liens qui utilisent « javascript » pour l’URI. Si un utilisateur n’utilise pas les scripts, il sera alors incapable d’utiliser le lien car le navigateur ne pourra créé le lien.

Que recommande Google à ce sujet ?

Google (Centre d’aide Webmasters/propriétaires de sites web)

Si votre site contient du texte ou des liens cachés, il risque d’être considéré comme peu fiable, car il présente aux moteurs de recherche un contenu différent de celui destiné aux visiteurs […]

[…] Si votre site contient du texte et des liens cachés conçus pour induire les moteurs de rechercher en erreur, votre site peut être retiré de l’index Google et ne plus être affiché dans les pages de résultats de recherche. Lorsque vous évaluez votre site afin de vérifier s’il contient du texte ou des liens cachés, recherchez tout ce qui n’est pas facilement affichable par les visiteurs. Existe-t-il du texte ou des liens accessibles uniquement aux moteurs de recherche et non aux visiteurs ? […]

[…] Lorsque Googlebot indexe une page contenant un script JavaScript, il ne peut pas suivre ou indexer les liens cachés dans le script lui-même. L’utilisation d’un script JavaScript est une pratique Web totalement légitime. Toutefois, son utilisation dans le but de tromper les moteurs de recherche ne l’est pas. […]

Pour résumer, il n’est pas interdit d’utiliser des liens javascript dans la mesure où la page présentée aux moteurs de recherche est la même que celle présentée aux utilisateurs. Ce qui n’est pas le cas dans la mesure où les robots ne pouvant lire javascript considèrent que les liens n’existent pas et ne référencent pas la page liée…

Devons-nous considérer que puisque le nombre des visiteurs sans javascript est faible, il n’est plus utile de se préoccuper de faire du javascript non-intrusif ? Comment se maintenir dans un secteur où toutes les méthodes même les plus contestables sont utilisées pour maintenir un taux de visites important sur son site ? Est-il possible de rester concurrentiel en utilisant les bonnes pratiques et en maintenant un site accessible, sans pour autant négliger la partie référencement ?

Pour continuer la réflexion quelques liens utiles :

• Support Google : Conseils aux webmasters
• Vous aimez l’accessibilité ? Les moteurs de recherche aussi !
• Accessibilité et e-commerce : Pourquoi rendre son site accessible ?
• Target condamné pour l’inaccessibilité de son site aux non-voyants

Vous avez certainement lu comme moi, que tout ce que vous saviez sur les css étaient faux en lisant l’article de Digital Web par Rachel Andrew. Je n’ai pas lu le livre, mais à la lecture de l’article j’ai voulu tester une nouvelle manière de mettre en page mon code html. Avec l’arrivée d’IE8, on va pouvoir enfin utiliser les propriétés CSS display:table, display:table-row et autres display:cell. Et je me pose la question suivante : à quoi servent réellement ces propriétés ? Parce que si on a bataillé, argumenté et convaincu des dizaines de personnes que les tableaux c’est mal, c’est pas pour simuler des tableaux en CSS ! Justement l’auteure nous réponds à ce sujet :

L’élément table en HTML est une structure sémantique, il décrit des données. Par conséquent, l’élément table est à utiliser uniquement pour des données tabulaires, par exemple un tableau mettant en forme des informations financières. Ces informations seraient normalement stockées dans une feuille de calcul sur votre ordinateur, il faudrait probablement un tableau pour les présenter en HTML.

La valeur table de la propriété display, d’un autre côté est simplement une indication de la présentation à afficher dans le navigateur – elle n’a pas de signification sémantique. Utiliser un élément table pour votre mise en page donne l’information suivante au user-agent : ces données sont tabulaires. Utiliser plusieurs divs qui ont la propriété display avec les valeurs table ou table cell, ne dit rien de plus au user agent que demander de les rendre visuellement d’une certaine façon, s’il en a la capacité.

Donc pas de problème, du moment que notre code html reste sémantique, on peut y aller ?

Quels sont actuellement les moyens dont nous disposons pour mettre notre code html en forme ?

1. Mise en forme à l’ancienne

   Il y a quelques années (au temps de netscape 4 et IE 5.5), j’aurais fait (à peu près) une mise en forme de ce style :

   Mise en page en tableau

2. Mise en page avec des éléments flottants *

   Pour moi la façon la plus fluide de mettre une page en forme, et qui permet beaucoup de flexibilité.

   Mise en page avec des divs flottants

3. Mise en page avec des éléments en absolu *

   Pratique dans certains cas mais je ne la conseillerais pas, trop figée pour des sites qui évoluent en permanence.

   Mise en page avec des éléments en absolu

4. Mise en page avec des display:table

   L’article de Digital web présente cette façon de faire. En lisant l’article, ça a l’air simple. Bon sang, mais c’est bien sur ! Pourquoi n’avions nous pas pensé à cette façon de faire plus tôt ? Bon, ok, on l’oublie à cause d’IE6, mais parfois on aime bien se projeter dans le futur et essayer de nouvelles choses, juste pour le sport… Je reprends donc mon design minimaliste : un header, une colonne de gauche, une colonne de droite et un footer. Simple. Je me base sur mon intégration old school et essaie d’appliquer la méthode vue dans l’article cité ci-dessus. Pas besoin de reprendre l’intégralité du code des tableaux (thead, tbody, tfoot, tr, etc…) puisque les éléments manquants sont créés virtuellement par le navigateur.

   Une esquisse de résultat…

Essayons maintenant de faire un colspan… hum, comment fait-on ? Puisque les propriétés du tableau sont définies en CSS et pas en HTML ? Après maintes recherches je déclare forfait. Avez-vous la réponse ?

En reprenant l’article, je me rends compte que ce n’est pas évoqué. Les seuls cas envisagés sont simples voire simplistes. Ok pour un site perso, mais ce n’est vraiment pas adapté pour un environnement professionnel. Loin de révolutionner notre façon d’utiliser les CSS, cette démonstration reste pour moi rien de plus qu’un exercice de styles…

On devra certainement attendre longtemps avant de voir arriver des CSS spécialement dédiés à la mise en forme de page web, en attendant vous pouvez toujours aller voir le document de travail Advanced Layout du W3C.

* Des tas d’exemples de mise en page sur les sites suivants :

http://layouts.ironmyers.com/100_percent_Layouts/
http://blog.html.it/layoutgala/
http://sherina.blogsome.com/2008/07/29/10-css-layout-demos/
http://www.smashingmagazine.com/2007/01/12/free-css-layouts-and-templates
http://css-discuss.incutio.com/?page=CssLayouts
http://www.free-css.com/free-css-layouts/page1.php
http://www.code-sucks.com/css%20layouts/faux-css-layouts/
http://www.free-css.com/free-css-layouts/page1.php

• 50% des pages n’ont pas de doctype
• la proportion des types de page est de l’ordre  de 1 doctype strict pour 10 doctypes transitionnels
• 4,13% des pages sont conformes
• Les tableaux sont présents dans plus de 80% des documents, essentiellement pour faire de la mise en page et non pour présenter des données tabulaires

Autant dire que les automatismes ne sont pas acquis par tout le monde et que faire respecter les standards est un travail de longue haleine. Il n’est pas inutile de rappeler comment bien structurer ces pages et comment appliquer les bonnes pratiques. Ce que nous ne manquerons pas de faire dans nos prochains billets.

Cette idée nous a paru sympathique et séduisante et chez Les Intégristes nous avons choisi de l’adopter. Seulement voilà, en retournant sur le site cette semaine, nous avons été fortement étonnés d’être redirigés vers la page de téléchargement des deux dernières versions d’Internet Explorer, chez Microsoft. J’ai donc essayé de rechercher des informations et je n’ai rien trouvé à ce sujet, nulle part…

La traduction française du site ayant été faite par Le détracteur constructif, je suis donc allé leur poser la question :

Q:Bonjour,
Nous adhérons fortement, chez les “intégristes”, à l’idée de progressivement délaisser IE6 pour enfin évoluer vers d’autres possibilités d’intégration et de développement que ne permets pas IE6, alors forcément l’idée de “savethedeveloppers” nous parait sympathique. Cependant depuis quelques jours l’URL “http://www.savethedevelopers.org” renvoie vers “http://www.microsoft.com/windows/internet-explorer/download-ie.aspx” la page de téléchargement de la dernière version d’Internet Explorer. J’ai essayé de trouver des infos à ce sujet sans succès… Qu’en est-il ?

A:Wow en effet… Hmm il je me demande si le projet a été “avorté” par Microsoft, à grand coups d’argent. Je vais essayer de voir si j’ai encore mon contact avec les gens qui faisaient ce site, et je vous reviens là dessus…

Si tel est le cas, cette initiative doit être très récente parce que le dernier message posté sur Twitter par savethedeveloppers est daté du 15 octobre dernier : » New products for winter and site supporters added. »

Est-on en présence d’une affaire du type Mikerowsoft ? En tout cas chez Les Intégristes nous avons retiré ce script qui maintenant incite les internautes à télécharger exclusivement Internet Explorer…

Nous vous communiquerons plus d’informations dès que possible, si de votre côté vous pouvez éclairer notre lanterne n’hésitez pas à poster.