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

À propos de l'auteur

Stephanie est technicienne de 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…
En savoir plus sur
Stéphanie
…

Que ce soit une entrée pour rechercher un site Web ou un champ de saisie de texte et un bouton d'envoi pour commentaires sur un blog ou 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 constituent la base de l'interactivité sur le Web. 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 extrêmement facile à 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 qui accompagnent les contrôles natifs, tels que l'accessibilité et la sécurité. 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 conduits là où nous en sommes aujourd'hui, l'état actuel de leur utilisation et un bref aperçu du travail effectué pour corriger cet espace.

Une brève histoire 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.

Alors que les nouveaux fournisseurs commençaient à itérer sur leurs nouveaux navigateurs, chacun commença à implémenter de nouvelles balises HTML pour aider à remplir présentent des lacunes et commencez à prendre en charge des éléments tels que des 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 celui-ci.

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

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

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 standardisée t 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 ne définissait pas les différentes parties des contrôles ni 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 les 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 pas Ce n'est même pas un 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 pouvait être stylé.

Mais à mesure 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 une exigence à l'époque.

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

«CSS2.1 ne définit pas quelles propriétés s'appliquent aux contrôles de formulaire et aux cadres, ni comment 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 niveau futur de CSS peut le préciser davantage. »

Conformité UA Spécification CSS 2.1, W3C

Il a été laissé entièrement aux agents utilisateurs de fournir 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 .

Alors que les développeurs ont commencé à demander le contrôle du style de divers contrôles, une proposition pour l'apparence La propriété a été incluse, mais supprimée 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 elle n'a jamais été mise en œuvre comme prévu et la prise en charge d'un navigateur à l'autre varie énormément.

Les développeurs ont commencé à utiliser apparence: aucune; 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 que apparaît: aucun; 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 ne pas pouvoir styliser les contrôles de formulaire.

Travailler avec des contrôles HTML sur le Web moderne

Avec le rythme auquel le Web évolue, vous pourriez penser que ce problème de style des contrôles de formulaire serait plus proche d'être résolu, ou du moins plus facile qu'il ne l'était 10-15 il y a des années. 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 bucket de nécessitant un CSS hacky ou ne peuvent toujours pas être stylés du tout par CSS .

] Bien que les contrôles de formulaire ne prennent plus de style ou de dépendance technique sur le 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 . La racine de ce problème réside dans la manière dont la spécification a été écrite à l'origine pour les contrôles de formulaire en 1995.

La spécification initiale n'a jamais normalisé les parties qui composent chaque contrôle de formulaire, elle a seulement normalisé la méthode pour entrer des données dans un document HTML et pour que ces données soient utilisées pour effectuer une action conduisant les navigateurs à définir la manière dont ils ont chacun construit leurs contrôles de formulaire. Chaque contrôle de formulaire avait un objectif standardisé, mais la façon dont cet objectif était construit dépendait de l'interprétation.

Sans parties standardisées, essayer d'ouvrir les différentes parties de contrôles plus complexes pour permettre aux développeurs d'avoir plus de contrôle sur le style crée des problèmes avec compatibilité du navigateur. Si un seul navigateur a implémenté l'accès à différentes parties d'une sélection pour personnaliser complètement l'apparence, cela est finalement inutile pour le développeur si l'objectif final est que les contrôles soient rendus de la même manière dans tous les navigateurs.

Mais le rendu de l'incohérence et de l'incapacité à le style cohérent d'un navigateur à l'autre n'est pas la seule chose qui manque aux développeurs dans les contrôles de formulaire natifs. Il y a un manque d'extensibilité avec les contrôles natifs. Les développeurs ne peuvent pas ajouter ou supprimer des fonctionnalités aux contrôles natifs.

L'élément vidéo en est un bon exemple:

L'attribut controls est le seul moyen d'afficher ou de masquer les contrôles de lecture pour l'élément vidéo sans possibilité de personnaliser ou d'étendre ce qui est affiché. Vous obtenez soit tous les contrôles vidéo, soit aucun, ce qui conduit à une mauvaise expérience avec l'élément natif.

Entre un manque de contrôle sur le style et un manque d'extensibilité, il n'est pas étonnant que les développeurs aient abandonné les contrôles natifs et se sont mis à les reconstruire

Cependant, lors de la reconstruction à partir de zéro, un développeur doit prendre en compte toutes les différentes pièces qu'il a besoin de rajouter dans le contrôle pour atteindre la parité avec les fonctionnalités d'un contrôle natif à tester en premier lieu. Avec l'accessibilité, par exemple, il ne s'agit pas simplement d'ajouter les rôles ARIA ou attributs appropriés, car ARIA ne fournit que la sémantique qui relie les différentes parties aux API d'accessibilité appropriées. La fonctionnalité du clavier permettant de parcourir un contrôle et un focus doit être ajoutée au-dessus d'ARIA. JavaScript peut être nécessaire pour certaines de ces fonctionnalités, les développeurs doivent donc prendre en compte ce qu'il advient de ce contrôle si un utilisateur a désactivé JavaScript. Il y a des implications en termes de performances à prendre en compte, car plus de JavaScript est ajouté aux contrôles.

Et puis il y a du temps pour les développeurs à tester l'accessibilité, les performances et la sécurité, des éléments qui sont intégrés aux contrôles natifs, et ils peuvent ne pas toujours avoir le support pour tester correctement ces éléments sur tous les navigateurs.

Ce n'est pas non plus une situation où un développeur peut écrire ce code une fois et en finir avec lui.

Lorsqu'un développeur crée ces éléments personnalisés, ils doivent également être maintenus à long terme. Que faire si une partie du code utilisé est obsolète de la plate-forme Web qui rompt les fonctionnalités? Et si les exigences d'accessibilité changent ou évoluent? Et s'il y a une vulnérabilité de sécurité? Le coût de la maintenance des éléments personnalisés au fil du temps peut finir par être plus coûteux et plus long.

L'état actuel du travail avec les contrôles sur le Web moderne est que d'innombrables heures de développement sont perdues pour réécrire les contrôles à partir de zéro, car éléments personnalisés en raison d'un manque de flexibilité dans la personnalisation et l'extensibilité des contrôles de formulaire natif . C'est une lacune énorme dans la plate-forme Web et ce depuis des années. Enfin, quelque chose est en train d'être fait à ce sujet.

Résolution des problèmes liés aux contrôles de formulaire

Greg Whitworth a mené des recherches sur les contrôles de formulaire tout en travaillant sur l'équipe de la plate-forme Web Microsoft Edge l'année dernière pour tout valider nous avons entendu franchement des développeurs: que les contrôles de formulaire natifs sont difficiles à utiliser et ne répondent pas à leurs besoins.

Dans une enquête initiale qui a réuni 1 400 répondants, l'une des questions posées était de savoir quels contrôles de formulaire les créer.

Les 3 premiers étaient:

1. Sélectionnez (10,7%)
2. Case à cocher (10,2%)
3. Date (9,5%)

L'une des questions de suivi posées aux répondants était " pourquoi recréez-vous des contrôles de formulaire? » et voici les 3 réponses les plus fréquentes:

• 36,6% ont déclaré ne pas pouvoir modifier suffisamment l'apparence
• 31,6% voulaient ajouter des fonctionnalités
• 27,3% ont déclaré des incohérences dans le navigateur

Les incohérences du navigateur dans le contexte des contrôles sont généralement liées à l'apparence. Si nous regroupons ces répondants avec ceux qui ont indiqué «ne pouvait pas changer suffisamment d'apparence», c'est plus de 60% des répondants qui sacrifient l'accessibilité et les performances intégrées avec les commandes natives en raison de l'apparence.

Interface utilisateur ouverte

Il y a un énorme opportunité de résoudre cet espace problématique pour les développeurs et il est extrêmement important que ceux qui sont en mesure de trouver une solution pour cet espace le fassent de la bonne manière. Cela signifie travailler sur des propositions de normes et des projets de normes en public et avec les commentaires de la communauté.

Open UI est une initiative du Web Incubator Community Group qui entreprend la tâche de documenter les composants de contrôle dans les systèmes de conception et analyser la terminologie du système de conception pour trouver des modèles et des similitudes qui aideront à définir le chemin des normes et du support natif dans le navigateur. Ce travail est mené par des fournisseurs de navigateurs, des auteurs de framework, des mainteneurs de systèmes de conception et est ouvert à la participation de toute personne intéressée par cet espace.

Cette initiative ne vise pas à standardiser l'apparence d'un contrôle de formulaire, mais à standardiser les noms de contrôle de formulaire, leurs parties, états et comportements. Cela implique de nombreuses recherches pour chaque contrôle, l'exploration des cas d'utilisation, des fonctionnalités et des fonctionnalités que les développeurs ajoutent à leurs composants personnalisés et le choix du moment où cette fonctionnalité ajoutée équivaut à un nouveau contrôle ( 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 n'importe quelle partie d'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 de système de conception.

Standardisation sans rupture du Web

Observation comme différentes solutions pour permettre la personnalisation de l'interface utilisateur de contrôle ont évolué au cours des derniers mois, l’une des préoccupations soulevées 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 peuvent 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 éléments comme les iframes seront bloqués) et personnaliser l'interface utilisateur sans avoir à reconstruire quoi que ce soit à partir de zéro.

Le but ultime est de offrent aux développeurs un degré élevé 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.

A Promising Future

Developers and web designers 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 du problème, il existe 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 à explorer des contrôles tels que .

Ils peuvent sembler être une partie petite ou arbitraire du Web, mais les contrôles HTML fournissent la fonctionnalité pour se connecter à un site Web ou passer une commande, et sont essentiels à l'écosystème Web sur lequel nous comptons aujourd'hui. [19659006] Des mesures significatives sont prises pour résoudre les problèmes que les développeurs rencontrent depuis des années avec ces composants et pour mettre en place des normes qui permettront la personnalisation

Dans les équipes de navigateurs, nous investissons dans cet espace parce que les commentaires des développeurs étaient tellement cohérents et abondants. Si vous travaillez sur le Web et que vous souhaitez contribuer à faire avancer cet espace, je vous invite à vous impliquer dans Open UI ou pour fournir des commentaires sur l'explication initiale pour la personnalisation de l'interface utilisateur des contrôles . Nous voulons nous assurer que nous prenons en considération les besoins de tous les développeurs et que nous prenons les bonnes décisions tout en poursuivant cet espace.

(jw, ra, il)