Résumé

  • Le projet HTML 5.1 du W3C publié en mai 2013 décrivait dialog, showModal(), une pile de dialogues et un document bloqué. Son chapitre sur l’interaction rendait inertes les éléments situés hors du dialogue modal.
  • La recommandation candidate HTML5 de 2014 et la recommandation HTML 5.2 de 2017 ont poursuivi cette répartition des tâches. La norme HTML actuelle précise davantage le focus et les demandes de fermeture.

Un site d’actualité veut obtenir une confirmation avant de jeter les articles sauvegardés. Il sait dessiner un rectangle au centre de l’écran et poser une ombre sur le reste. Pourtant, quand le clavier continue de parcourir les liens de la page, le lecteur se retrouve dans deux conversations simultanées. La fenêtre dit « répondez-moi » ; le navigateur laisse la porte de derrière ouverte. La modalité se joue à l’endroit où l’on peut agir, pas à la couleur du voile gris.

Le projet HTML 5.1 du 28 mai 2013 donnait à dialog le rôle d’un espace où accomplir une tâche. show() ouvrait un dialogue ordinaire. showModal() faisait monter le dialogue tout en haut d’une pile tenue par le document, le plaçait dans la couche supérieure et bloquait le document. On voit déjà le contrat : le site fournit l’objet de la conversation ; le navigateur sait quelle conversation a la parole.

Le chapitre du même projet consacré à l’interaction explicitait ce blocage. Autour du dialogue modal, les autres nœuds deviennent inertes. Les commandes de la page attendent donc la fin de l’échange. Une équipe pouvait auparavant imiter cet effet avec ses propres morceaux de code. La spécification en faisait une responsabilité commune du navigateur. Un joli fond sombre n’avait plus à se faire passer pour un règlement de circulation.

Le portier devait aussi savoir accueillir et raccompagner. Le texte de 2013 pouvait choisir une commande autofocus à l’ouverture, traiter une demande d’annulation sur le dialogue supérieur et transmettre une valeur par close() et returnValue. Le navigateur sait fermer la porte ; l’application comprend ce que signifie le choix rendu. « Effacer » peut supprimer la liste de lecture, tandis qu’une sortie sans réponse la laisse intacte. Ces conséquences appartiennent au site qui a posé la question.

La recommandation candidate HTML5 de février 2014 conservait la pile, la couche supérieure et la logique d’annulation. La recommandation HTML 5.2 de décembre 2017 détaillait les étapes de mise au point du focus. Ces dates racontent l’écriture des règles. Elles permettent de voir comment le problème de la simple boîte dessinée est devenu une question de comportement du navigateur.

La différence entre show() et showModal() reste la meilleure épreuve. Un inspecteur non modal peut rester ouvert pendant que l’on lit l’article. Une confirmation modale demande, pour un instant, l’exclusivité. Le site choisit entre ces deux usages. La même élégance graphique peut habiller l’un et l’autre ; seule la manière dont le reste de la page attend révèle le contrat.

La norme HTML actuelle règle plus finement le focus initial, les valeurs de sortie et les actions capables de fermer un dialogue. Elle contient aussi requestClose() et closedby, arrivés après les premiers textes cités ici. Il faut les lire comme la suite d’une vieille question : lorsqu’une page interrompt quelqu’un, qui garde la porte, et comment le lecteur retrouve-t-il sa place ?

Le navigateur peut tenir la file et protéger le parcours au clavier. Il ne peut pas rendre nécessaire une interruption inutile. Le meilleur dialogue est bref, clair, puis s’efface assez vite pour que l’article redevienne le sujet principal.