Tous les articles pour HTML5

  • Séparations des rôles du HTML / CSS / JavaScript et mise en application

    Cet article fait office de conventions d'architecture d'un site web orienté composant pour la partie cliente, peu importe la technologie d'implémentation finale, de manière à ce que le code soit valide, performant et maintenable par des développeurs front-end, des développeurs back-end ainsi que des pousseurs de contenu. Ces techniques étant en constantes évolution, et les problématiques évoluant au fur et à mesure de mes itérations créatives, cet article est voué à se compléter et changer.

    Contenu, apparence et comportement
    Contenu, apparence et comportement

  • Utiliser la balise Link dans la balise Body

    Par convention, on a toujours utilisé la balise <link> dans la balise <head>. Cette balise est utilisée —entre autre— pour permettre aux navigateurs de lire et d'appliquer les instructions CSS depuis une feuille CSS.

    Par convention dis-je ? Pas réellement car :

    • Côté W3C, la balise <link> telle qu'elle a été créée n'est valide W3C en HTML4, xHTML ou HTML5 uniquement si elle est appelé dans la balise <head>.
    • Côté technique, une propriété CSS est appliquée sur un élément du DOM quand il est rendu sur la page uniquement si elle a été interprétée avant de rencontrer cet élément. Si une feuille CSS est lu en pied de page donc, c'est-à-dire après le rendu d'un élément, il y aura un phénomène de FOUC très dérangeant si la page est demandée depuis un réseau bas débit.

    Exemple : Ainsi le code suivant est valide :

    <head>
      ...
      <link rel="stylesheet" type="text/css" href="example/css.css" media="screen" />
      ...
    </head>
    

    mais

    Exemple : le code suivant est invalide :

    <body>
      ...
      <link rel="stylesheet" type="text/css" href="example/css.css" media="screen" />
      ...
    </body>
    

    Cependant, puisque l'affichage du contenu de la page est mis en attente tant que les fichiers href des <link> ne sont pas téléchargés et analysés par le navigateur, cela participe à ralentir l'affichage du contenu des pages aux yeux de l'utilisateur ce qui mène parfois les outils comme PageSpeed ou GTmetrix a demander de placer les feuilles CSS très lourdes après l'analyse du DOM.

    Mais puisque cela n'est pas valide, comment faire pour placer la balise <link> en pied de balise <body> ?


  • Utiliser les Media Queries CSS3 dans l'attribut style

    Autant vous annoncer la mauvaise nouvelle tout de suite, il n'est pas possible d'utiliser les Media Queries dans l'attribut des balises HTML style. Ainsi le code suivant ne fonctionnera pas...

    <div>
        <img 
            src="image/que/je/veux/decaller/seulement/quand/elle/flotte.png" 
            style="@media(min-width: 768px){float:left margin:-4px 16px 8px -24px;}">
        <p>J'aimerai faire flotter à gauche l'image ci-dessus uniquement sur 
        les grands écrans. Comme les valeurs de `margin` sont ajustées uniquement 
        aux propriétés de cette image (-4px 16px 8px -24px), il n'existe pas de
        classe  HTML-driven comme créer un `.float-left` (à l'avance) qui répondrait 
        exactement à mon besoin.</p>
    </div>
    

    ...c'est comme ça !

    Dans ce cas, comment faire pour gérer des propriétés CSS ponctuellement en utilisant les Media Queries ? Cela est très utile pour le remplissage de contenu pour ajuster des images ou encore manager des background-image.

    La solution n'est pas l'attribut style des balises HTML mais la balise <style> elle même !


  • Bootstrap est une régression pour un développement Front-end de qualité

    Pourquoi je n'utilise pas Bootstrap ? Cela peut sembler une « évolution » de nos méthodes de travail front-end, mais gare au loup et attention de ne pas tomber dans un travers que le W3C tente d'enrayer au fur et à mesure des évolutions HTML et CSS.

    Commençons par le commencement. Qu'est-ce que Bootstrap ? Comme pleins d'autres « Bibliothèque » ou « Framework » CSS dans la même veine, Bootstrap est un outil permettant d'augmenter la productivité des développeurs front-end le maîtrisant, dans le but de fournir le plus rapidement possible un rendu visuel ergonomique et si possible responsive.

    Mon problème ne vient pas tant de sa finalité qui est louable, mais bel et bien de la mise en œuvre technique qui permet d'atteindre cette finalité. Pour être concis avant de développer : l'utilisation faites de Bootstrap est une régression pour un travail front-end de qualité.

    Je ne compte persuader personne, et à défaut de convaincre, je vais au moins vous expliquer mon point de vue.


  • Bien gérer la localisation des sites en CSS3 et HTML5

    Il y a des solutions simples pour gérer avec une feuille CSS l'affichage de différentes langues. Vous vous êtes peut-être déjà confronté à un problème similaire : votre super menu s'affichant en ligne est parfait dans la langue des Vulcains avec une taille de caractère mais malheureusement ne l'ai plus avec la langue des Na'vis.

    Quand votre site sera déployé pour des localisations différentes, les feuilles CSS ne pourront alors pas être les mêmes et vous allez maintenir autant de fichiers différents que de localisation ? C'est ce que vous ferriez en faisant un très mauvais choix. Arrêtons-nous 5 minutes pour explorer une piste bien pratique pour assurer la maintenance d'une feuille CSS et de ces différentes localisations.


  • Les concepts autour du Responsive Web Design

    Le « Responsive Web Design » comme son nom l’indique est le concept de « Responsive Design » adapté au Web. Il est parfois raccourci par le terme « RWD » ou simplement par « Responsive ».

    Responsive Web Design
    Source : www.tridentdesign.com

    Dans la majorité des cas d’utilisations, il est utilisé comme raccourci pour désigner la version Mobile d’un site web originalement conçu pour un écran d’ordinateur.

    La vérité est que le Responsive Web Design n’est qu’un des nombreux concepts appliqués à un site web pour le rendre « utilisable agréablement » sur mobile tout en sachant qu’il ne se limite pas qu’aux mobiles et qu’il vaut tout aussi bien pour :

    • une tablette,
    • une phablette (terminal intermédiaire se situant entre le smartphone et la tablette),
    • un ordinateur et tous ses types d’écrans (HD, 3D, tactile),
    • une télévision numérique,
    • un tableau de bord de voiture,
    • une console de jeu portable,
    • …et tout appareil capable d’afficher un site web par l’intermédiaire d’un navigateur web.

    En plus du fait que Responsive Web Design ne signifie donc pas obligatoirement « version mobile », il est le porte étendard d’une liste de concept comme l’« Adaptative Web Design ». Difficile de comprendre ce dont on parle réellement quand il est question de Responsive Web Design.


  • Les balises h1 multiples autorisées en HTML5

    C'est suite à plusieurs conversations m'invitant à ne pas utiliser de multiples balises h1 dans mes intégrations HTML (et plus récemment une demande « insistante » sur le fait de ne pas le faire) que je me vois forcé de marcher sur les pas de Raphaël Goetter -qui avait déjà abordé le sujet- pour expliquer pourquoi : en plus d'être tout à fait valide, cette pratique est bénéfique.

    Tout document HTML5 dispose de cloison de contenu (Sectionneur de contenu) que sont article, aside, nav et section. Ces zones de contenu peuvent chacune contenir une balise header et footer (ne cloisonnant pas elles-mêmes le contenu) et de multiple éléments de titrage (Titre en HTML) allant de h1 à h6.

    Bien que l'utilisation de plus d'une balise h1 ai pu rationnellement laisser à débattre (même si techniquement les standards ne l'interdise pas), les recommandations et même l'interdiction d'une telle pratique ne sont plus pertinentes et rationnelles à l'heure du HTML5.


Lire dans une autre langue