C’est la rentrée, il est temps de reprendre un peu la veille HTML et CSS.
Voici quelques découvertes peu usitées, à venir ou déjà présentes dans nos navigateurs.
Connaissez-vous les attributs formaction et form ?
Les formulaires HTML offrent peut-être plus de possibilités que vous ne le pensiez, et cela simplifie beaucoup certaines tâches.
Par exemple l’attribut formaction qui s’ajoute aux boutons de soumissions de vos formulaires et qui permet d’indiquer une page de destination différente au formulaire. On peut donc très facilement prévoir des boutons multiples, avec certains qui opèrent un traitement différent du bouton principal.
Ce qui peut être très pratique dans les paniers de commandes, où les boutons de suppression ne mènent pas au même endroit que le bouton de confirmation de commande.
L’attribut est bien supporté à partir d’IE 10, donc aucune raison de s’en priver. Autrement, il faudra faire comme avant, s’appuyer sur l’attribut name du bouton pour détecter côté serveur vers où rediriger.
Bien sûr, formaction est accompagné de plein de petits copains qui opèrent sur le même fonctionnement ; avec (entre autres) formmethod et formnovalidate.
L’attribut form quand à lui (pas la balise, attention) n’est actuellement pas supporté par IE (Edge inclus) mais il permettra à l’avenir (ou si votre support le permet) d’associer un champ ou un bouton à un formulaire distant, sans avoir besoin d’être englobé par celui-ci.
Là encore, nul doute que ce sera utile dans les paniers de commandes, où se mêlent difficilement tableaux de données et formulaires.
Et puisque nous en parlons, peut-être serait-il pertinent d’y ajouter un élément output au total de votre panier de commande ? Oui ? Non ?
Le rythme vertical plus facilement ?
Actuellement, composer avec un rythme vertical en CSS est compliqué. Cela demande pas mal de rigueur d’une part, et d’autre part certaines situations ne permettront pas d’assurer des hauteurs de contenus maitrisées (tableaux, images contribuées, formulaires…)
Avec line-height-step, il me semblait que cela faciliterait les choses. Malheureusement cette propriété ne s’applique qu’aux éléments « en ligne » et n’ajoute pas d’espaces après les contenus, mais modifie au contraire les hauteurs de lignes.
Nul doute que ça facilite le travail de calculs sur les hauteurs de lignes et les marges des éléments ; mais de ce que j’en ai compris pour l’instant, ça ne révolutionne en rien le travail sur les grilles horizontales. Dommage.
Une démonstration est disponible ici pour que vous puissiez vous faire votre avis.
Comment se justifier ?
Toujours sur un sujet typographique, Mozilla et Internet Explorer (à partir du 11) implémentent la propriété text-justify. Elle permet de décider sur vos textes justifiés si les espaces modifiés seront entre les lettres (inter-character) ou entre les mots (inter-word).
Je trouve que l’option « entre les lettres » est agréable, mais peut-être vaut-il mieux à l’heure actuelle laisser le navigateur choisir lui-même l’option la plus adaptée.
Si vous utilisez un navigateur compatible, vous pouvez regarder ma démonstration sur CodePen (et la mettre en pause au survol avec l’aide de animation-play-state).
FOUT et FOIT sont dans un bateau
Typographie toujours, la propriété font-display va enfin nous permettre de décider le comportement d’affichage de nos polices personnalisées lors du chargement. Actuellement il faut s’en remettre aux choix navigateurs ou ruser via Javascript…
Avec font-display (encore en grande partie non-supporté, mais ça bouge justement), il sera possible de choisir directement via CSS si la police personnalisée non-chargée :
- est remplacée par du blanc (
auto) ; - est remplacée par une police non-personnalisée (
swap) ; - est remplacée par une police non-personnalisée si le temps d’attente est trop important (
fallback) ; - est carrément facultative (
optional).
Ma préférence va pour fallback mais dans tout les cas il restera intéressant de travailler au mieux les correspondances entre les polices.
Le guide de référence au sujet du chargement des polices se trouve quant à lui ici (en anglais).
Pour ceux qui n’utilisent pas encore flexbox
Si vous êtes dans ce cas, vous utilisez sans doute les flottants pour réaliser vos colonnages. Et qui dit float dit bien souvent clearfix.
Cette technique se simplifie doucement en fonction de l’évolution du parc navigateur et il n’est plus d’usage d’y ajouter l’habituel zoom: 1 qui n’est utile que pour IE inférieur à 9.
Idem, pour le pseudo-élément ::before qui peut-être supprimé. Mais attention, il permet aussi d’éviter la fusion des marges, et dans ce cas, il n’est pas encore possible de s’en affranchir.
À l’avenir flow-root (bien qu’ayant un comportement d’affichage légèrement différent) viendra sans nul doute remplacer tout cela.
Garder le focus ?
Pas facile de concilier accessibilité et design quand il est question du focus. Sur ce sujet épineux, le pseudo-sélecteur :focus-ring tente d’apporter une réponse intelligente en demandant directement au navigateur de remonter le contexte d’utilisation de l’élément courant.
C‘est encore très mal supporté, mais l’idée plaît bien et on trouve des polyfill JS intéressants dès à présent.
focus-within est quand à lui, un autre pseudo-sélecteur, qui permet de cibler directement le parent d’un élément ayant le focus clavier. Il bien mieux supporté et fonctionne partout sauf avec IE et quelques navigateurs mobiles.
Les exemples habituels montrent des formulaires avec un highlight sur les zones actives. J’ajouterais que cela pourrait être également très pratique pour afficher/masquer les zones de navigation rapide en haut de document.
Elements queries
Si vous jouez beaucoup avec les media-queries, il ne vous aura pas échappé qu’il serait parfois préférable de voir ses composants réagir à leurs dimensions intrinsèques plutôt qu’à celle du navigateur.
Il est déjà possible de s’amuser un peu en jouant avec min-width et max-width comme l’a brillamment démontré Rémi Parementier en fouillant la question du responsive pour les emails.
Pour ceux qui souhaiteraient prendre de l’avance, sachez que de nouvelles unités dédiées sont en cogitation : ew et eh (parmi d’autres). Elles s’utilisent comme vw et vh mais font cette fois référence à l’élément courant plutôt qu’au viewport. Il existe déjà des polyfill JS, mais c’est encore trop tôt selon moi.
Contrôle de formulaires
Avez-vous déjà joué avec l’attribut pattern ? Cet attribut permet de contrôler finement vos attentes sur les données saisies par vos utilisateurs dans champs de formulaires.
Pour un contrôle de mot de passe, on peut par exemple s’assurer que celui-ci comprenne bien au moins une lettre majuscule et un chiffre. C’est une mauvaise pratique, mais ça me faisait un bon exemple.)
Il faudra par contre en passer par l’utilisation des regex…
Pour les amateurs de vidéos
Quelques chaînes proposent maintenant des contenus dédiés métier. C’est en anglais et c’est généralement très intéressant :
Vous en avez d’autres ?
Rendez-vous pris pour le début de l’année scolaire prochaine (ou avant ?) pour un nouveau petit billet fourre-tout sur la veille HTML et CSS.
