Catégories
Plugin et site web

Le passé, le présent et l'avenir des contrôles de formulaire HTML natifs – Smashing Magazine

A propos de l'auteur

Stephanie est technologue en conception et gestionnaire de programme pour les expériences de développement Microsoft Edge. Son travail de conception et de gestion de programme s'est concentré sur…
Plus à propos
Stéphanie

Travailler avec des contrôles de formulaire HTML natifs a été un tel problème pour les développeurs Web, du style à leur extension, les limitations sont si grandes que d'innombrables heures de développement ont été passées à les recréer. Mais pourquoi les contrôles de formulaire sont-ils si difficiles à utiliser?

Dans cet article, Stephanie plonge dans le passé en remontant au début du HTML et en retraçant l'évolution des contrôles de formulaire jusqu'au présent et l'état actuel de leur utilisation. Elle partage ses réflexions et jette un aperçu de ce que l'avenir nous réserve pour travailler avec ces éléments essentiels du Web.

Qu'il s'agisse d'une entrée pour rechercher un site Web ou d'un champ de saisie de texte et d'un bouton d'envoi pour les commentaires sur un blog ou d'une case à cocher pour accepter les termes et conditions d'un site Web, les contrôles de formulaire sont parmi les composants les plus courants et fournissent la base de l'interactivité sur la toile. Ils sont partout en ligne et le sont depuis le début du HTML.

Ils ont été introduits dans la spécification HTML 2.0 en 1995, mais, malgré leurs origines précoces, la facilité avec laquelle les développeurs peuvent les styliser ou les personnaliser varie de très simple à presque impossible. Cela a conduit les développeurs à abandonner complètement ces contrôles natifs et à en créer des personnalisés à partir de zéro, ce qui peut être problématique et prendre du temps.

Les contrôles créés à partir de zéro ne disposent pas des fonctionnalités fournies avec les fonctionnalités natives, telles que l'accessibilité et la sécurité, il y a donc une pléthore de travail supplémentaire pour rendre les contrôles personnalisés accessibles et sécurisés. Nous examinerons l'historique des contrôles de formulaire qui nous ont menés là où nous en sommes aujourd'hui, l'état actuel du travail avec eux et un bref aperçu du travail effectué pour réparer cet espace.

Un bref historique des contrôles HTML

Après la sortie du premier navigateur Web au début des années 90 de Tim Berners-Lee appelé WorldWideWeb (renommé plus tard Nexus), plusieurs autres navigateurs Web étaient en cours de développement et mis à la disposition du public. Mais la spécification HTML préliminaire était extrêmement basique à l'époque, avec seulement une poignée de balises disponibles pour le balisage de texte.

Au fur et à mesure que les nouveaux fournisseurs ont commencé à itérer sur leurs nouveaux navigateurs, chacun a commencé à implémenter de nouvelles balises HTML pour aider à combler les lacunes des fonctionnalités et commencer à ajouter la prise en charge d'éléments tels que les images et d'autres éléments interactifs. Cela a créé une fracture croissante dans le HTML car il n'y avait pas encore de norme ou de spécification pour cela.

En 1993, Berners-Lee et Dan Connolly avaient travaillé à la définition de la première spécification pour HTML, mais le projet a expiré au début de 1994. Le premier groupe de travail HTML a été créé après l'expiration de ce premier projet et a achevé la première spécification pour HTML 2.0 qui allait devenir le base des normes HTML à l'avenir.

La spécification HTML 2.0 a pris note du paysage actuel des fonctionnalités HTML sur différents navigateurs et, plutôt que de casser le Web, a inclus dans la spécification les fonctionnalités déjà disponibles dans les navigateurs.

HTML 2.0 a donné au Web les premières spécifications de fonctionnalité de formulaire pour les types de formulaires suivants:

  • form
  • input (type=):
    • text
    • password
    • radio
    • image
    • hidden
    • submit
    • reset
  • select
  • option
  • textarea

La spécification normalisait la méthode permettant aux utilisateurs de saisir des données dans un document HTML et la manière dont ces données devaient être utilisées pour effectuer une action telle que la connexion à un site Web. Cependant, il n'a pas défini les différentes parties des contrôles ou comment chaque contrôle serait construit et rendu dans le navigateur.

Limitations techniques et de style

En 1995, il n'y avait pas encore de langage de style établi, c'est là que le premier style de limitations avec des contrôles de formulaire est entré en jeu. Les navigateurs devaient s'appuyer sur le système d'exploitation pour styliser et rendre les contrôles de formulaire, ce qui signifiait à l'époque qu'il y avait une dépendance au système d'exploitation à la fois techniquement et stylistiquement.

Ce n'était pas quelque chose que les développeurs pouvaient accéder pour personnaliser, et il n'y avait même pas de moyen de le faire sans un langage de style. Bien que l'idée des feuilles de style dans les navigateurs existe depuis 1990 avec le navigateur initial de Berners-Lee, tous les navigateurs apparus dans les années 90 n'offraient pas aux développeurs un moyen de styliser les choses. S'ils le faisaient, ils limitaient fortement ce qui était stylé.

Mais alors que le Web prospérait et que CSS était établi comme langage de style, les contrôles de formulaire étaient toujours hors de propos lorsqu'il s'agissait de les styliser ou de les personnaliser. Ils étaient censés refléter le système d'exploitation sur lequel ils se trouvaient. Ce niveau de style et de personnalisation n'était pas obligatoire à l'époque.

La spécification CSS 2.1, qui oscillait entre l'état de brouillon de travail et la recommandation de candidat de 2004 à 2010, précisait même que les navigateurs n'avaient pas à appliquer CSS aux contrôles de formulaire.

«CSS2.1 ne définit pas quelles propriétés s'appliquent aux contrôles de formulaire et aux cadres, ni comment le CSS peut être utilisé pour les styliser. Les agents utilisateurs peuvent appliquer des propriétés CSS à ces éléments. Il est recommandé aux auteurs de traiter ce support comme expérimental. Un futur niveau de CSS peut préciser cela plus en détail. »

Conformité UA, spécification CSS 2.1, W3C

Il incombait entièrement aux agents utilisateurs de définir le style des contrôles de formulaire. Même si plusieurs navigateurs sont devenus disponibles sur les systèmes d'exploitation, le rendu n'était pas cohérent entre les navigateurs.

<img srcset = "https://res.cloudinary.com/indysigner/image/fetch/f_auto,q_auto/w_400/https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/bee0fa57 -1c83-4c63-8432-13486f12df7a / boutons-456bereastreet.jpg 400w,
https://res.cloudinary.com/indysigner/image/fetch/f_auto,q_auto/w_800/https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/bee0fa57-1c83-4c63- 8432-13486f12df7a / boutons-456bereastreet.jpg 800w,
https://res.cloudinary.com/indysigner/image/fetch/f_auto,q_auto/w_1200/https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/bee0fa57-1c83-4c63- 8432-13486f12df7a / boutons-456bereastreet.jpg 1200w,
https://res.cloudinary.com/indysigner/image/fetch/f_auto,q_auto/w_1600/https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/bee0fa57-1c83-4c63- 8432-13486f12df7a / boutons-456bereastreet.jpg 1600w,
https://res.cloudinary.com/indysigner/image/fetch/f_auto,q_auto/w_2000/https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/bee0fa57-1c83-4c63- 8432-13486f12df7a / boutons-456bereastreet.jpg 2000w "src =" https://res.cloudinary.com/indysigner/image/fetch/f_auto,q_auto/w_400/https://cloud.netlifyusercontent.com/assets/344dbf88- fdf9-42bb-adb4-46f01eedd629 / bee0fa57-1c83-4c63-8432-13486f12df7a / boutons-456bereastreet.jpg "tailles =" 100vw "alt =" Un groupe de natifs

Alors que les développeurs ont commencé à demander le contrôle du style de divers contrôles, une proposition de appearance property a été inclus, mais supprimé par la suite de la norme CSS Basic User Interface Module Level 3. La proposition d'apparence était censée «fournir des mécanismes CSS supplémentaires pour simuler l'apparence de divers éléments de formulaire standard», mais n'a jamais été réellement mise en œuvre telle qu'elle a été conçue et la prise en charge d'un navigateur à l'autre varie énormément.

Les développeurs ont commencé à utiliser appearance: none; pour supprimer tous les styles natifs et tenter d'appliquer leur propre CSS aux contrôles de formulaire. Cependant, l'incohérence dans ce qui peut être stylisé à travers différents contrôles de formulaire une fois appearance: none; est appliqué varie considérablement et de manière incohérente d'un navigateur à l'autre, et ne résout pas le problème réel de l'impossibilité de styliser les contrôles de formulaire.

Utilisation de contrôles HTML sur le Web moderne

Avec le rythme auquel le Web évolue, vous pourriez penser que ce problème lié au style des contrôles de formulaire serait plus proche d'être résolu, ou du moins plus facile qu'il y a 10 à 15 ans. Alors qu'une poignée de contrôles de formulaire peuvent être facilement stylisés par CSS, comme l'élément bouton, la plupart des contrôles de formulaire tombent dans un seau nécessitant un CSS hacky ou ne peuvent toujours pas être stylés par CSS.

Bien que les contrôles de formulaire ne prennent plus de style ou de dépendance technique vis-à-vis du système d'exploitation et utilisent la technologie de rendu moderne du navigateur, les développeurs sont toujours incapables de styliser certains des éléments de contrôle de formulaire les plus utilisés tels que vs combobox en est un excellent exemple). Nous nous attendons à ce que le travail effectué dans Open UI s'intègre à d'autres groupes de travail en transmettant des recommandations et en classant les problèmes dans les lieux appropriés pour faire avancer ce travail.

Si vous souhaitez vous impliquer dans une partie de l'Open UI, consultez le référentiel GitHub et les problèmes en suspens. Non seulement c'est un excellent projet dans lequel plonger vos orteils si vous êtes intéressé par le travail sur les normes, mais les contributions et la recherche contribueront à résoudre un énorme problème pour les développeurs et même les concepteurs. Si vous êtes un concepteur qui travaille avec des commandes et des composants, cet espace vous est également ouvert car ce travail s’intègre aux cadres du système de conception.

Normaliser sans casser le Web

En observant l'évolution des différentes solutions permettant la personnalisation de l'interface utilisateur de contrôle au cours des derniers mois, l'une des préoccupations qui s'est posée concernait la rupture des contrôles natifs déjà disponibles sur le Web.

Les contrôles natifs existants continueront de fonctionner, mais avec la proposition actuelle, il y aura du code supplémentaire que les développeurs pourront utiliser pour styliser des parties arbitraires du contrôle natif, ajouter du contenu arbitraire dans n'importe quelle partie du contrôle natif (avec des limitations, des choses comme les iframes seront bloquées ) et personnalisez l'interface utilisateur sans avoir à reconstruire quoi que ce soit à partir de zéro.

Le but ultime est de fournir aux développeurs un haut degré de flexibilité sur l'apparence et l'extensibilité des contrôles. Le document explicatif initial sur l'activation de l'interface utilisateur de contrôle personnalisé est maintenant disponible pour examen public. C'est le premier pas vers la normalisation; ces changements sont conduits et introduits dans les organismes de normalisation en raison des commentaires des développeurs, alors prenez un moment pour lire l'explication et les questions ouvertes et faites part de vos commentaires ou réflexions sur GitHub.

Un avenir prometteur

Les développeurs et les concepteurs Web demandent depuis des années des contrôles améliorés et une flexibilité de style, mais lorsque nous en arrivons vraiment au cœur, il y a tellement de cas d'utilisation et de fonctionnalités d'extensibilité différents que les développeurs ont implémentés dans des composants personnalisés, en particulier lorsque nous commençons. pour explorer des commandes comme