Archives pour la catégorie (X)HTML/CSS

HTML Media Capture : prenez des photos depuis un champ de formulaire

HTML Media Capture et l’attribut capture.
Mettez à profit les périphériques de votre mobile pour remplir les champ file

HTML5 apporte de nombreuses nouvelles fonctionnalités, notamment concernant les formulaires.

Nous allons voir dans ce billet la spécification HTML Media Capture.
Celle-ci permet d’élargir les capacités des champs de formulaires de type file.
Jusqu’à présent, les champs de formulaires de type file permettaient juste d’ouvrir une fenêtre pour récupérer dans le système de fichiers celui (ou ceux) à envoyer avec le formulaire.
Il est dorénavant possible d’utiliser ces mêmes champs pour utiliser l’un des périphériques de capture (audio, vidéo ou image) pour créer le fichier à envoyer.

Comment le mettre en œuvre ?
La mise en place d’un tel système est particulièrement simple.
Il suffit d’ajouter au champ un attribut capture et le tour est joué ! Cet attribut étant de type booléen, c’est-à-dire que sa seule présence (sans valeur ou quelle que soit sa valeur) suffit à indiquer au navigateur le comportement souhaité.

Enfin… il suffit… pas tant que ça en fait.
En réalité, l’attribut capture n’est pas suffisant, en effet, ce seul attribut ne permet pas de savoir quel type de media est demandé, donc quel périphérique utiliser.
Il est donc nécessaire de préciser aussi l’attribut accept avec une valeur correspondant au type mime souhaité.

Notez que l’attribut capture n’oblige pas l’utilisateur à utiliser un périphérique : il lui est demandé s’il veut envoyer un fichier existant ou s’il veut utiliser le périphérique approprié.

Exemples.
Voici les trois cas possibles d’utilisation à l’heure actuelle :

<form action="..." method="post" enctype="multipart/form-data">
    <!-- Pour une image (appareil photo) -->
    &lt;input type="file" name="image" accept="image/*" capture&gt;
    <!-- Pour une vidéo (caméra) -->
    &lt;input type="file" name="video" accept="video/*" capture&gt;
    <!-- Pour un son (micro) -->
    &lt;input type="file" name="son" accept="audio/*" capture&gt;
    &lt;input type="submit" value="Upload"&gt;
</form>

Compatibilité.
À l’heure actuelle, seuls les navigateurs pour mobiles et tablettes semblent supporter cette fonctionnalité.
Voir la table de compatibilité pour mobiles.
Mais gageons que les versions desktop des navigateurs vont l’implémenter rapidement.

Voir les spécifications du W3C (comprenant des exemples plus avancés).

Forcer le chargement d’un fichier en HTML5

Lorsque vous proposez une ressource aux visiteurs de votre site (images, documents PDF ou autres, etc.), les navigateurs vont essayer de les afficher via des fonctionnalités intégrées ou des extensions/plugins.
Or, si vous souhaitez juste proposer ces ressources au téléchargement, vous serez obligé de « forcer la main » au navigateur côté serveur :

En gros, la technique consiste à associer au fichier souhaité un en-tête HTTP Content-Disposition qui indiquera que celui-ci doit être téléchargé et non affiché.

Bien entendu, si votre page est uniquement en (X)HTML, vous êtes de la revue ! La seule technique possible est de transformer votre fichier dans un format qui ne peut être affiché par le navigateur (la technique la plus classique étant de le compresser en archive zip).

Mais cela, c’était avant.
Car désormais, HTML5 vous permet de rendre vos fichiers téléchargeables, quel que soit leur format, de façon très simple.

Il suffit d’utiliser l’attribut download.
Lire la suite

HTML5 : quelques nouveautés de l’API DOM pour JavaScript

La spécification HTML5 définit différents modules indépendants. Cette modularité a pour avantage de permettre de travailler sur certains aspects du standard sans avoir besoin de se soucier de l’état d’avancement des autres.
Parmi ces modules, l’API DOM est celui qui permet de définir les propriétés et méthodes disponibles en JavaScript pour manipuler le DOM.
Nous allons voir les différentes nouveautés particulièrement utiles de cette API.
Lire la suite

Personnalisez le menu contextuel avec Firefox

HTML5 redéfinit certains aspects et certaines balises du HTML.
Parmi les éléments qui retrouvent une nouvelle jeunesse figure la balise menu.
Bien sûr, évoquer cette balise ne présente que peu d’intérêt puisqu’elle n’est, à l’heure actuelle (et sauf erreur de ma part) reconnue par aucun navigateur…

Par aucun navigateur ? Vraiment ?

En fait, pas tout à fait : parmi les différentes utilisations de la balise menu, une est utilisable par Firefox depuis la version 8 : la personnalisation du menu contextuel lié à un élément de la page (ou de la page elle-même).

La syntaxe de la balise menu est la suivante :

<menu type="..." id="...">

type correspond au comportement attendu pour le menu et id l’identifiant du menu.
Cette balise peut (dans le cadre du menu contextuel) contenir soit des sous-menus représentés par une nouvelle balise menu soit des éléments de menu représentés par des balises menuitem.

Bon, assez d’explications théoriques, passons à la pratique avec un exemple :

<menu type="context" id="developpez">
   
  <menu>
     
     
     
     
  </menu>
</menu>

Dans cet exemple (relativement simple), nous ajoutons des liens vers developpez.com et différents forums du site.
Vous pouvez constater que le type de menu est context pour préciser qu’il s’agit de personnaliser le menu contextuel.
D’autre part, le sous-menu et les éléments des menus possèdent des attributs label indiquant le texte à afficher correspondant à chaque option.
Les éléments de menus possèdent quant à eux des attributs icon (image apposée à côté de l’élément) et onclick (action JavaScript à lancer au clic sur cet élément).

Pour autant, vous aurez beau ajouter cette portion de code dans votre page et faire des clics droits partout dans la page (sur Firefox bien entendu) pour tester, rien ne se passera !
En fait, nous avons oublié l’essentiel : déterminer à quel élément de la page le menu contextuel est associé.
Pour préciser cela, il suffit d’ajouter un attribut contextmenu à l’élément souhaité. La valeur de cet attribut doit correspondre à l’identifiant (attribut id) du menu.
Dans l’exemple suivant, nous posons cet attribut sur la balise body afin que le menu contextuel s’applique sur toute la page :

  <title>Menu contextuel</title>
   
    html, body{
      height: 100%
    }
    h1{
      text-align: center;
    }
   
 
 
  <h1>Exemple de menu contextuel personnalisé</h1>
  <div>Faites un clic droit dans la page pour voir les options ajoutées au menu contextuel.</div>
<menu type="context" id="developpez">
   
  <menu>
     
     
     
     
  </menu>
</menu>

Notre exemple est maintenant fonctionnel. Vous pouvez voir un exemple en ligne.

Comprendre la balise script

S’il est bien une balise qui est souvent mal utilisée en HTML, c’est la balise <script>.
Nous allons essayer dans ce billet de faire le point sur cette balise en comprenant pourquoi.

  • La syntaxe

La syntaxe de base est relativement simple et ne pose pas de problème :
 
Il est toutefois important de noter que même si elle ne possède pas forcément de contenu, elle reste susceptible d’en avoir (le script en lui-même) ce qui fait que contrairement à une balise mais à l’instar d’une balise , elle n’est pas autofermante et doit posséder une balise fermante.

  • Les attributs

L’attribut src ne pose habituellement pas de gros soucis.
Cet attribut correspond à l’URL à laquelle se trouve le fichier correspondant. Attention toutefois, dans le cas d’une URL relative, de bien comprendre où se trouve le script en fonction de l’URL effective (celle affichée par le navigateur) qui appellera le script. Attention donc par exemple aux include en PHP.

En revanche, deux attributs sont assez souvent confondus, il s’agit des attributs language et type.
Il faut déjà savoir que le premier est deprecated depuis HTML 4 alors qu’au contraire, le second est required. Cela signifie qu’il faut bannir language.
La syntaxe correcte devient donc
 
Mais alors, si l’attribut language est à bannir, pourquoi le retrouve-t-on si souvent ?
D’abord, parce que malheureusement, plusieurs facteurs empêchent de l’éradiquer.
Déjà, de nombreux scripts usuels sont bien référencés et recopiés tels quels bien que très anciens. Du coup, l’attribut se propage facilement.
D’autre part, peut-être surtout, parce que beaucoup ignorent la signification de cet attribut.
A la base, il servait à indiquer le langage et la version du langage de script utilisé. Cependant, aucune norme n’a été trouvée pour savoir ce qu’il pouvait bien contenir, ce qui a donc amené à ce qu’il soit déprécié. De toute façon, le seul langage de script universellement reconnu par les navigateurs est JavaScript (quelle que soit sa déclinaison : ECMAScript, JScript, …) donc l’information n’a que peu d’intérêt. De même, préciser une version à utiliser n’a pas vraiment de sens : JavaScript, pour des raisons de rétro-compatibilté ne perd pas de fonctionnalités, il ne fait qu’en accepter de nouvelles !

Note : en HTML5, l’attribut type n’est plus requis et dans cette version, la syntaxe
 
est désormais suffisante.

  • Le contenu

Pendant longtemps (et on retrouve encore couramment la syntaxe), les scripts étaient entourés soit de commentaires HTML soit d’entités CDATA :

<!--
    // Code JavaScript
-->

Là encore, la pratique remonte à un temps que les moins de 20 ans (voire plus !) n’ont pas connue !
Ces syntaxes, héritées du XML, servaient à l’origine à éviter que les navigateurs ne possédant pas d’interpréteur JavaScript (on ne parle pas de ceux qui ont JavaScript désactivé, bien de ceux pour lesquels JavaScript n’existe tout simplement pas !) n’essayent d’interpréter le contenu du script comme du HTML. De mémoire, on parle là de IE3 et de NS3. Il me semble que la part de marché de ces navigateurs atteint depuis longtemps un seuil qui rend cette technique quelque peu obsolète !

  • Où placer les scripts ?

Plusieurs écoles s’affrontent à ce niveau.
Une chose est sure : il est demandé de séparer les différentes couches du document : le HTML pour le contenu, le CSS pour la mise en forme et le JavaScript pour l’ergonomie (ou le le comportement). Ainsi, insérer ses scripts en plein milieu du document est assez maladroit.
Pendant un temps, les bonnes pratiques recommandaient de placer les scripts entre les balises <head> et de les initialiser via l’événement onload de l’objet window.
Cette façon de procéder est plutôt satisfaisante mais l’événement onload implique que l’ensemble du contenu de la page soit chargé avant de lancer les scripts (donc y compris les éléments dits remplacés : images, iframes, object, etc.) et comme les pages Web deviennent de plus en plus gourmandes en ressources externes, cela fini par nuire à l’expérience utilisateur.
Différentes techniques existent pour pallier cela, entre autre, l’utilisation de l’événement DOMContentLoaded, mais qui n’est pas (encore) suffisamment universel pour être totalement satisfaisant.
La problématique est que pour pouvoir utiliser un script, il faut que les éléments du DOM qu’il va utiliser existent au moment où il est appelé. Une solution efficace est alors de placer les scripts juste avant la fermeture du document (avant la balise </body>), ce qui permet d’être sûr que les éléments du DOM ont été créés et de conserver la notion de séparation des couches.
Gardez toutefois à l’esprit que quelle que soit la solution choisie, elle aura une importance majeure lors de l’écriture de codes destinés à être réutilisés.

Contribuez à l’épanouissement des rubriques (X)HTML et CSS

Bonjour,

Si vous êtes passionné par les technologies HTML/XHTML et CSS et désireux d’apporter votre contribution à la communauté, n’hésitez pas à nous contacter.

Quelle que soit votre disponibilité, toute aide est un atout avec des possibilités de contributions multiples :

  • Rédaction de Questions/Réponses pour la F.A.Q (X)HTML/CSS ;
  • Traduction d’articles existants en Anglais (par exemple) ;
  • Le développement de nouvelles sources susceptibles d’être ajoutées à la Galerie CSS ;
  • Modération sur les forums HTML/XHTML et CSS ;
  • Critiques de livres.

Si l’expérience vous intéresse toujours, vous pouvez nous contacter via l’e-mail css[at]redaction-developpez.com afin de participer de près ou de loin à l’évolution de ces deux merveilleuses rubriques.

L’équipe (X)HTML/CSS.

Le brouillon du HTML 5 publié !!!

Bonjour,

Pour votre information, le brouillon (draft) du HTML 5 a été publié hier par le W3C : http://www.w3.org/TR/html5/. La spécification a considérablement grossi. Elle définit toujours des balises et des attributs et la façon de les utiliser, mais également des API et le DOM. En attendant de vraiment se plonger dedans, on pourra consulter la page suivante qui indique les différences avec le HTML 4 : http://www.w3.org/TR/2008/WD-html5-diff-20080122/. Ce qui suit s’appuie largement sur ce document.

Lire la suite

Mise à jour de la page Outils (X)HTML

Un petit billet pour vous informez que la page outils (X)HTML a subi une mise à jour. Désormais, elle contient 45 outils tels que :

  • Des éditeurs;
  • Des extensions diverses;
  • Des services en ligne;
  • Des validateurs de code (X)HTML;
  • etc.

Si vous utilisez d’autres outils que vous trouvez pratiques, utiles, n’hésitez pas à me les communiquer en commentaires ou dans le sondage Éditeur utilisé pour faire du HTML. Je me ferai un plaisir de les ajouter ;)

Enfin, je profite de ce billet pour vous annoncer la mise à jour de notre page Cours et Tutoriels, n’hésitez pas à la consulter.

Mise en ligne de la nouvelle page Cours PHP

J’ai finalement pris le temps de terminer la nouvelle mise en page des cours et tutoriels PHP. Les cours sont maintenant mieux répartis en catégories, donc plus faciles à retrouver. J’en ai profité pour mettre un peu à l’écart les cours obsolètes, mais vous pouvez toujours les consulter si vous le voulez.

Vous pouvez poster ici vos commentaires et consulter cette page si vous souhaitez rejoindre la Rédaction pour ajouter vos articles à la liste.

http://php.developpez.com/cours/

La rubrique CSS ouvre sa galerie

En projet depuis bien longtemps déjà, la galerie CSS vient enfin de voir le jour.

Elle a pour but de mettre à votre disposition des sources prêtes à être intégrées dans tous vos développements Web.

Pour son ouverture, vous y trouverez un ensemble de menus (verticaux, horizontaux, etc) et quelques modèles de mise en page.

Vous y aurez également la possibilité de générer en ligne vos menus grâce aux générateurs qui sont mis à votre disposition, pour certains d’entres eux.

Si vous souhaitez que l’une de vos sources y soit intégrée, n’hésitez pas à nous la proposer dans le forum Contribuez.

L’équipe CSS