Les derniers articles de ce Blog

La balise HTML script permet de définir quand le code JavaScript dans votre page est exécuté. Les attributs HTML5 async et defer sont à présent supportés par Firefox, Chrome, Safari et Internet Explorer 10+ (sinon ils sont ignorés) et permettent de modifier le comportement de chargement des scripts. Voici de courtes explications sur les différences de chaque appel.

Lire la suite

On me demande souvent quelle est la structure JavaScript que j'utilise pour développer mes sites web. C'est une question à laquelle je ne sais jamais si un simple « jQuery » suffit ou si l'on s'attend à m'entendre répondre « MooTools », « jQuery UI », « Backbone », « Knockout », « AngularJs » ou je ne sais quelle autre composant/librairie/framework JavaScript Front-end extraordinaire !

Au delà du fait que l'utilisation de ses ressources précédemment citées dépend du fait que l'on souhaite réaliser un site web ou un outil web ou une application web etc. je finis toujours par expliquer que j'utilise ma propre architecture JavaScript à travers toutes les différentes pages d'un site web.

Je vais donc vous livrer à travers cet article l'architecture JavaScript que j'ai adopté. Afin de la comprendre pas à pas, j'utiliserai comme fil conducteur la réalisation d'un site vitrine. Ma façon de structurer le JavaScript client n'est pas absolue mais elle vous permettra de comprendre la logique derrière mes différents sites dont vous trouverrez les sources sur GitHub ou même du moteur NodeAtlas.

Lire la suite

Cet article est une adaptation du Google JavaScript Style Guide en FR. Je n'applique pas nécessairement moi-même toutes les bonnes pratiques listées ci-dessous mais si vous ne vous êtes jamais posé la question : « Comment maintenir un code gardant l'équilibre entre lisibilité et performance avec mon équipe ou les personnes susceptibles de relire mon code » cet article peut s'avérer intéressant. Si vous avez déjà vos pratiques : c'est peut-être l'occasion (comme pour moi) d'en revoir certaines.

Lire la suite

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.

Lire la suite

On parle souvent de la grande vélocité de Node.js et de son brillant avenir. Mais il n'est pas toujours judicieux de l'utiliser. Pour certains cas d'utilisations, c'est le meilleur choix à faire (application web temps réel). Pour d'autres cas, ça le deviendra mais c'est encore un peu tôt (CMS web). Et pour d'autre il ne sera jamais réellement adapté (intelligence artificielle). Voici l'adaptation française d'un article de Felix Geisendörfer, contributeur Node.js. Il nous explique de manière pragmatique comment raisonnablement et rationnellement il est possible d'utiliser Node.js pour son business.

« Maintenant que vous êtes au point sur l'utilisation de Node.js, il est temps de convaincre votre boss. Enfin peut-être. J'ai eu l'occasion de conseiller différente entreprise sur la question : Node.js est la bonne technologie ? Et parfois, la réponse est tout simplement non.

Ce guide est ma collection opiniâtre des conseils pour ceux d'entre vous qui veulent savoir si Node.js fait sens pour leur entreprise, et si oui, comment convaincre la direction.

Lire la suite

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 ».

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’au mobile 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.

Lire la suite

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 (sectioning content) 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 (heading) 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 la suite