html5

Non, ce n’est pas le titre du prochain box office, mais bien la triste réalité avec HTML5 aujourd’hui. Pour ceux qui ne suivent pas HTML5, la spécification est pratiquement complète et il ne manque vraiment pas grand chose pour qu’on puisse justifier de faire le grand saut vers ce langage prometteur.

Il reste encore certains trucs sur lesquels ils doivent s’entendre et le codec à utiliser pour l’utilisation de la vidéo (<video>) fait parti de ce qui n’est pas coulé dans le béton.

En effet, il existe actuellement la guerre entre 2 codecs : H.264 et Ogg Theora Codec.

H.264

Le codec coûte 5 millions/année (oui oui) et il est utilisé par Apple (Safari) et Google (Chrome)

OGG

Codec open source actuellement utilisé par Firefox et Opera.

Microsoft dans tout ça? À ce jour, nous ne savons toujours pas vers quel codec ils vont se tourner.

Bon, le choix n’est pas très difficile à faire. OGG devrait être adopté par tous et l’histoire se terminerait là, mais ça ne semble pas être aussi simple. Google semble dire que le Ogg Theora Codec n’est pas encore tout à fait au point et qu’il est préférable de se tourner vers H.264 pour l’instant. Si vous vous souvenez, l’année dernière Google a acheté On2 Technologies qui est une importante compagnie créant de la compression vidéo de haute qualité. On2 Technologies a créé le VP3 Codec qui est la base du Ogg Theora Codec. Étrange? Google fait rarement quelque chose pour rien.

Il est clair pour moi que Google ne veut pas utiliser le codec Ogg puisqu’ils doivent être en train d’en développer un qui sera également open source. Nous risquons d’en savoir plus à ce sujet en 2010.

Tweet This Post

Récemment, j’ai vu passer certains trucs dans mon Twitter concernant les transitions en CSS3. Le premier exemple que j’avais vu ne m’avait guère impressionné, mais je m’y suis un peu plus intéressé et voilà que je trouve cela beaucoup plus convainquant.

Compatibilité

Pour l’instant, les transitions en CSS3 sont compatibles sur Safari 4 et Chrome 3.

Les propriétés à connaitre

transition-property : détermine sur quelle propriété CSS nous voulons que la transition soit appliquée (ex : background, color, etc)

transition-duration : détermine la durée de la transition

transition-timing-function : détermine l’accélération/décélération de la transition

transition-delay : détermine le délai avant que la transition s’effectue

Raccourci/Shorthand

selecteur  {
    transition: opacity 2s ease-in;
}

Voici deux exemples sur les transitions CSS :

Demo 1

Demo 2

Vous pouvez télécharger ci-dessous les deux exemples que j’ai faits avec les transitions.

Télécharger le premier exemple sur les transitions CSS.

Télécharger le deuxième exemple sur les transitions CSS.

Que va amener les transitions CSS ? Ces nouvelles possibilités vont nous amener à délaisser encore une fois Flash. Je dis encore une fois, puisqu’HTML5 nous amène déjà à le délaisser. Nous n’avons qu’à penser à la balise <video> entre autre. Il ne sera plus nécessaire d’avoir recours à Flash et d’absolument utiliser Javascript pour ajouter plus d’interactivité dans nos sites Web. Les transitions CSS « vont faire la job » pour créer des animations de base.

Avec toutes ces nouvelles possibilités, il n’y aura plus d’excuse pour abuser de Flash dans nos sites Web…

Voici un excellent site Web pour voir différents exemples sur les transitions en CSS3 :

http://www.alsacreations.com/tuto/lire/873-transitions-css3-animations.html

Pour en savoir davantage sur les transitions en CSS3, je vous invite également à lire la spec du W3C.

Tweet This Post

Court billet pour ceux et celles qui n’ont jamais réussi à faire valider leur embed Flash.

Voici un code qui vous rendra valide par le W3C :

<object type="application/x-shockwave-flash" data="movie.swf"
width="500" height="500">
    <param value="movie.swf" />
</object>

Source prise d’un débat sur comment valider Flash : http://forums.hostmysite.com/about497.html

Enjoy and share!

Tweet This Post

Voici la suite du billet formulaires HTML5 partie 1. Ce billet comporte deux exemples reprenant les attributs décrient dans la première partie. Vous remarquerez que ces deux formulaires ressemblent beaucoup à ceux que vous pouvez construire en HTML4 ou XHTML.

Comme je l’avais mentionné, il n’y a rien de très complexe dans les nouveautés concernant les formulaires en HTML5. Les nouveautés vont surtout nous permettre de valider plus rapidement les champs de nos formulaires.

<form id="presetForm1" method="post" action="">
    <ul>
        <li><label for="txtName">courriel</label></li>
        <li><input class="text" type="email" id="txtName" maxlength="100"
        autofocus required /></li>
        <li><label for="txtPass">mot de passe</label></li>
        <li><input class="text" type="password" id="txtPass"
        required /></li>
        <li><label for="txtNom">nom</label></li>
        <li><input class="text" type="text" id="txtNom" value="Optionel..."
        onfocus="this.value='';"/></li>
        <li><label for="txtDate">date de naissance (ex: 1900-03-27)
        </label></li>
        <li><input class="text" type="date" id="txtDate" /></li>
        <li><label for="txtTel">téléphone (ex: 514-123-4567)</label></li>
        <li><input class="text" type="tel" id="txtTel" value="Optionel..."
        onfocus="this.value='';" /></li>
        <li><label for="txtUrl">site web</label></li>
        <li><input class="text" type="url" id="txtUrl" maxlength="250"
        value="Optionel..." onfocus="this.value='';" /></li>
        <li><input class="submit" type="submit" value="Send" /></li>
   </ul>
</form>

Observations sur l’exemple

Le champ courriel contient les attributs « autofocus » et « required » ce qui veut dire qu’en arrivant sur la page, c’est sur ce champ que le pointeur de notre souris sera. Ce champ est également obligatoire avec l’attribut required. De plus, le champ est de type « email » ce qui indique qu’il faut nécessairement entrer un courriel dans ce champ.

Le champ password est obligatoire avec l’attribut required.

Le champ date de naissance est de type « date » ce qui indique qu’il faut nécessairement entrer une date au format (Year-Month-Day) dans ce champ.

Le champ téléphone est de type « tel » ce qui indique qu’il faut nécessairement entrer un numéro de téléphone dans ce champ.

Le champ site web est de type « ul » ce qui indique qu’il faut nécessairement entrer une url dans ce champ.

Les nouveaux attributs et valeurs de l’attribut type sont assez simples. Nous comprenons rapidement leurs utilisations. Dans un billet futur, je ferai un exemple en intégrant Javascript aux nouveaux formulaires d’HTML5.

Tweet This Post

À une certaine époque, il était « à la mode » d’utiliser des tables pour créer les gabarits de nos sites Web. Nous savons aujourd’hui que cette pratique est dépassée et qu’il est préférable d’utiliser les <div> ou encore les nouvelles balises d’HTML5 si vous avez commencé à programmer en ce langage.

Aujourd’hui, je vous propose un exemple tout simple d’une utilisation des tables tout en ayant en tête l’accessibilité de ce dernier. Il suffit de rajouter deux éléments pour aider certaines personnes ayant un handicap quelconque à profiter de votre site. J’utilise rarement les tables dans mes projets car l’occasion ne se présente pas. Dans l’application en ligne que je suis en train de concevoir avec d’autres personnes, il y a plusieurs tableaux et c’est une bonne occasion de mettre en pratique ce que je vais proposer ci-dessous.

L’attribut summary

Cet attribut de la balise <table> aide grandement à la compréhension du tableau en question. En ajoutant cet attribut qui décrit sommairement votre tableau, les gens utilisant des « screen reader » pourront immédiatement savoir de quoi ça parle. Pour la plupart d’entre-nous, le tableau nous paraît évident puisque nous le voyons, mais essayé d’imaginer ce que ça peut être pour une personne aveugle qui parcours votre site Web.

Voici un exemple :

<table summary="Présentation des statistiques des ventes du dernier
trimestre. Le tableau contient trois rangées et deux colonnes.">
...
</table>

La balise <caption>

Cette balise sert à définir le titre de votre tableau. Elle doit être placée immédiatement après la balise <table> avant vos <th>, <tr> et <td>. Par défaut, elle est placée en haut au centre avant toutes les cellules. Il suffit de jouer un peu avec CSS pour lui donner un peu plus de style. En ajoutant cette balise, c’est la façon la plus accessible de donner un titre à votre tableau.

Exemple :

<table summary="Présentation des statistiques des ventes du dernier
trimestre. Le tableau contient trois rangées et deux colonnes.">
    <caption>Statistiques des ventes du trimestre de l’année 2009</caption>
    <tr>
        <td>...</td>
        <td>...</td>
    </tr>
    ...
</table>

Rien de compliqué eh? En ajoutant ce qui est mentionné ci-haut, vous vous assurerez que vos tableaux sont plus accessibles à tous.

Voici un lien intéressant pour en savoir davantage sur l’accessibilité des tableaux en HTML : http://www.usability.com.au/resources/tables.cfm

Et vous, quels sont vos trucs pour rendre vos tableaux plus accessibles?

Tweet This Post

De nos jours, quel site web ne contient pas un formulaire sur au moins une de ces pages? Personnellement, je crois que je ne pourrais pas en nommer. Les formulaires se retrouvent sur des millions de pages sur la toile. Une des nouveautés d’HTML5 que j’attends avec impatience est les formulaires “2.0”. Cette nouveauté va grandement simplifier la programmation de nos formulaires actuels.

Les formulaires actuels

Actuellement, il peut être laborieux de créer un formulaire pour un site web. Si nous le concevons intelligemment, nous devons avoir recours à d’autres langages comme Javascript/PHP/ASP et s’assurer d’effectuer plusieurs vérifications.  Sans vérification, l’usager peut entrer n’importe quoi et le formulaire devient inutile. Par exemple, il nous faut vérifier si l’usager entre un courriel valide ou encore si l’usager n’entre pas des lettres dans le champ téléphone. Les programmeurs utilisent normalement des « regexp » pour faciliter la validation des formulaires.

Les formulaires en HTML5

Ils ne sont pas vraiment différents que dans la version actuelle d’HTML, mais ils ont quelques ajouts intéressants que je vais décrire ci-dessous.

Les nouveaux attributs intéressants de balise <input>

autocomplete : Cet attribut peut permettre l’autocomplétion sur un champ texte par exemple. L’autocomplete est devenu assez populaire avec AJAX. Nous n’avons qu’à penser au moteur de recherches de Google qui nous suggère des mots lorsque nous commençons à taper des lettres. Il peut avoir la valeur « on » ou « off ».

autofocus : Met le focus sur l’élément en question. En arrivant sur une page, le pointeur est placé sur le champ ayant l’autofocus.

multiple : Permet d’entrer plusieurs valeurs.

pattern : Attribut fort intéressant qui permettra d’entrer une expression régulière (regexp). L’expression régulière entrée servira à valider la valeur entrée dans le champ en question.

Il y en a plusieurs autres, mais ceux que je viens de décrire risquent d’être plus utilisés.

Ce qui est également fort intéressant, c’est les nouvelles valeurs que peut prendre l’attribut « type ». Cet attribut permet de spécifier quel type de champ nous utilisons dans notre formulaire (texte, bouton radio, etc).

Voici certaines valeurs intéressantes que peut prendre l’attribut type :

url : En spécifiant cette valeur, nous indiquons que nous devons entrer une adresse de site web.

tel : En spécifiant cette valeur, nous indiquons que nous devons entrer un numéro de téléphone.

email : En spécifiant cette valeur, nous indiquons que nous devons entrer un courriel.

date : Nous devons spécifier une date au format suivant : 1900-03-27

number : La valeur entrée dans le champ doit absolument être un nombre. Aucune chaîne de caractères.

Et les autres : search, month, week, time, datetime, datetime-local, range et color pour ne pas les nommer.

Comme vous le voyez, beaucoup de nouvelles choses dans les formulaires. Rien de très complexe, mais il y aura sans aucun doute beaucoup de tests à faire pour s’assurer que tout fonctionne correctement. À noter également que ces nouveautés ne sont pas encore prises en compte par Firefox. Vous pouvez par contre vous amuser sous Chrome 3  et Safari 4.

Je vous reviens la semaine prochaine avec la suite de ce billet sur les formulaires en HTML5. Vous y découvrirez entre autres des exemples mettant en pratique les nouveautés décrites plus haut.

Pour plus de détails, je vous invite fortement à regarder la spécification d’HTML5 sur les formulaires.

Tweet This Post

Vendredi passé, je reçois un message d’un client potentiel qui serait intéressé à mes services pour la conception du design de son site web corporatif. Il a vu certains de mes travaux et aime mon style, etc ,etc. Le client habite à Toronto et parle anglais. Voilà une belle occasion de pratiquer mon franglais et d’avoir un client en dehors du Québec. Je réécris au client en question en lui demandant plus d’information sur ce qu’il voudrait. Il me montre un croquis quelconque pour me donner une idée de départ.

Jusque là, tout va bien. Je lui dis d’accord et qu’à partir des précisions qu’il m’a données, je vais lui envoyer une soumission. J’oubliais… Le client mentionne dans un de ses courriels une précision que je redoute de plus en plus et qui est dans ce genre : « c’est juste un petit contrat.. un petit site web.. rien de très compliqué ». Quand j’entends ce genre de propos, j’ai toujours une lumière qui s’allume dans ma tête et qui me dit : WARNING, qu’est-ce qu’il entend par petit et rien de très compliqué? Soit que le client connait vraiment le web ce qui est rarement le cas ou bien justement, il croit connaître ça et que pour lui, rien n’est vraiment complexe (vous savez le genre de propos qui laisse pratiquement sous entendre : «Ben voyons, mon neveu de 12 ans fait des sites web et il dit que c’est facile! »).

Je lui fais donc un prix assez bas puisqu’il m’avait mentionné que son budget était également limité et aussi parce que j’ai plutôt tendance à avoir des contrats plus techniques ces temps-ci. Un contrat de design va faire du bien. Le client me réécrit que le prix est plus élevé qu’il aurait pensé et me demande s’il serait possible de baisser le prix. Ah bon… Pourtant mon prix n’était pas élevé. Je lui propose un compromis. Je baisse votre prix, mais vous afficher un lien vers mon portfolio en bas de votre interface. Le client décide finalement de laisser tomber puisque pour lui, c’est encore trop élevé. Quelles conclusions dois-je tirer de tout ça? Mes prix sont trop élevés? Honnêtement, je ne crois pas. Je sais ce que je vaux et je ne suis pas excessif. Ce scénario se répète souvent auprès d’amis designer ou autres personnes travaillant dans le domaine du web. Il m’amène souvent à croire que nous ne sommes pas pris au sérieux dans notre métier. Pour moi, il y a 2 types de client : le client X et le client Y.

Le client X reconnaît que nous avons une ou plusieurs expertises. Il sait que nous travaillons forts pour nous améliorer et que nous tentons chaque jour de ne pas perdre le fil d’un domaine qui est en constante évolution.

Et il y a le client Y… Ce même client qui ne connaît pas vraiment le web et ne nous prend pas au sérieux. Le client Y essaie de nous faire croire que tout est simple et que tout est facile.

Si j’ai un problème avec mon lavabo, j’appelle un plombier car il/elle est expert. Il a des expertises. C’est loin d’être gratuit, mais lui et moi savons très bien que je ne peux pas répondre au besoin que j’ai actuellement. Je paye pour un service et je suis satisfait par la suite. C’est la même chose dans le web. Tu as un besoin. Tu cherches un/une expert et tu dois t’attendre à payer un minimum pour obtenir des services de qualité.

Tweet This Post

L’article d’aujourd’hui concerne la nouvelle balise <time> en HTML5 qui va encore une fois améliorer la sémantique de nos pages web.

La balise <time> sert à indiquer l’heure ou la date. Jusque là, tout est simple.

Elle contient deux attributs : pubdate et datetime.

L’attribut pubdate est un booléen et indique une date de publication. S’il est présent, il faut spécifier la date entre <time></time>. Un article peut contenir au maximum un élément <time> ayant l’attribut pubdate (quand même logique…).

Si l’attribut datetime est présent (ex : datetime= « 2009-10-12 »), il n’est pas nécessaire que notre élément <time> contienne quelque chose. Dans le cas contraire, nous devons spécifier la date et l’heure avec l’élément <time>.

Son utilisation

La balise <time> peut être utilisée à plusieurs endroits différents dépendamment du contenu de notre site. Pour prendre à nouveau l’exemple d’un blog, la balise <time> en HTML5 pourrait être intégrée dans l’en-tête de nos articles pour indiquer la date de publication.

Voici 4 exemples de l’utilisation de la balise <time>  :

<p>Je devrais arriver à <time>19h30</time>.</p>

Avec l’attribut pubdate

<header>
    <h3>Is HTML5 a FLASH killer?</h3>
    <p>Publié le <time pubdate>2009-10-12</time></p>
</header>

Avec l’attribut datetime

<p>Écrit le <time datetime=”2009-10-12”></time></p>

Avec l’attribut pubdate et datetime

<p>Publié <time pubdate datetime=”2009-10-12”>aujourd’hui</time></p>

Dans le dernier cas ci-dessous, nous ferions un rendu de la date dynamiquement à l’aide d’un autre langage de programmation.

<p>Publié <time pubdate datetime=”2009-10-12”></time></p>

Un autre exemple serait d’utiliser la balise pour nos tweets sur Twitter. En effet, après chaque tweet nous retrouvons l’heure à laquelle notre tweet a été publié.

Ex :

<ul id="twitter_update_list">
    <li>Comment « plugger » subtilement des mots-clés comment HTML5
    dans mon blog. <time>1 hour ago</time></li>
</ul>

La balise <time> en HTML5 sera de plus en plus utilisée dans les futurs sites web. Elle peut sembler complexe au début, mais une fois que nous comprenons bien la distinction entre les attributs pubdate et datetime, nous pouvons bien l’exploiter. C’est une autre balise avec laquelle les développeurs pourront s’amuser avec Javascript, PHP, etc.

Vous pouvez également consulter la spécification du W3C sur HTML5 concernant la balise <time>.

Tweet This Post

Comme vous le savez, je m’intéresse beaucoup à HTML5 et à CSS. Jusqu’à maintenant, j’avais quelque peu délaissé la future version de CSS pour me consacrer à HTML5 (et mes 10 000 projets personnels, mais bon…).

Aujourd’hui, je vous offre une nouveauté de CSS3 que j’attends depuis un bon moment et qui risque de me faire sauver de l’argent sur les tylenols. Depuis que je fais du design web, il m’est arrivé de me casser la tête en CSS pour faire certains trucs. Non pas que je ne connais pas CSS, mais plutôt parce que la version actuelle a été négligé.

En effet, il n’est pas possible avec la version 2 de CSS d’appliquer plusieurs images en background à un même élément. Pourquoi? Aucune idée. Il est pourtant évident que tous aurait bénéficié de pouvoir le faire. Heureusement que CSS3 va être terminé un jour…

Voici donc comment appliquer plusieurs backgrounds à un même élément en CSS3 :

#twitterWidget {
	/* L'ORDRE POUR PLACER LES BACKGROUNDS EST IMPORTANTE */
	background-image:    url(../images/box-bg-top.jpg),
                             url(../images/box-bg-middle.jpg),
                             url(../images/box-bg-bottom.jpg);
	background-position: top left, center center, bottom left;
	background-repeat:   no-repeat, repeat, no-repeat;
}

Dans notre exemple, nous avons 3 images différentes. Une pour le haut, une autre pour le milieu et finalement une pour le bas. Il suffit de séparer nos déclarations par des virgules pour appliquer plus d’un background à un élément. Aussi simple que cela.

Remarque : L’ordre dans lequel nous plaçons nos backgrounds est important. Il est préférable de suivre cet ordre logique : top, middle, bottom.

À noter que les backgrounds multiples ne sont pas pris en compte par Firefox 3.5. Je vous conseille donc de faire les tests sous Chrome 3.0 et Safari 4.

Télécharger l’exemple des backgrounds multiples en CSS3.

Voici le lien pour voir l’exemple en ligne : http://ins.pire.me/open-source/css3/exemple01-background/demo.html

L’icône Twitter utilisée à été créé par la designer Mirjami Manninen.

Tweet This Post

Ayant travaillé sur plusieurs projets impliquant du code CSS, je me suis rendu compte qu’il arrivait rapidement que l’on ne se retrouve plus dans ses propres fichiers. Ce n’est pas nécessairement dû à des mauvaises pratiques, mais plutôt au fait qu’un fichier CSS peut rapidement devenir volumineux. En effet, il suffit d’avoir environ 5 sections pour que l’on commence à devoir user de la barre de défilement pour parcourir nos fichiers.

Il existe une technique toute simple permettant de rechercher rapidement dans nos fichiers CSS et c’est d’utiliser des FLAGS. Les FLAGS sont des mots-clés que l’on peut placer au début de nos sections.

Ex :

/* ---------------------------------------------------
Navigation principale  =navPrin
----------------------------------------------------*/
nav {…}
nav ul {…}
nav ul li {…}

En mettant un = devant le mot-clé, il suffit de rechercher =navPrin pour facilement trouver la section d’un seul coup. Nous nous assurons également d’être positionné au début de la section que l’on recherche et d’éviter de passer d’une occurrence à une autre. Toujours en pensant en fonction d’HTML5, vous risquez d’avoir plusieurs occurrences de la balise header, nav ou footer. Il est donc d’autant plus utile d’utiliser les FLAGS CSS pour trouver nos sections rapidement.

Et vous, quelles méthodes utilisez-vous pour vous retrouver facilement dans vos fichiers CSS?

Tweet This Post