Skyduino:~#
Articles
Uncategorized

La syntaxe HTML c’est vraiment la misère

Bonjour tout le monde !

J’étais en train de réfléchir à un algorithme permettant de transformer un morceau de texte quelconque en une série de jolis paragraphes HTML, quand j’ai réalisé quelque chose de très très bête : la syntaxe HTML n’est pas faite pour être utilisée par des humains.

À la fin de cet article, vous en serez vous aussi convaincu 😉

Mise en situation

Quand j’écris un article, comme celui que vous êtes en train de lire actuellement, je ne fais qu’écrire des lignes de texte séparées par des lignes vides qui délimitent les différents paragraphes de l’article final.
La plupart du temps, je n’utilise aucune balise HTML dans mes articles, excepté un lien, une image, un titre ou une mise en gras, par-ci, par-là, de temps en temps.
Mais récemment, certains auront remarqué que je me suis mis à faire des titres (des vrais), des sommaires et des listes dans mes articles, en HTML donc.

Pour le site v2, je compte faire des articles avec une mise en page encore plus recherchée. J’ai donc de nouveaux besoins, par exemple le besoin de faire des bandeaux (des petites bannières entre deux paragraphes qui permettent d’attirer l’attention du lecteur sur un point important).

Actuellement, la syntaxe des bandeaux que j’utilise est la suivante :

<div class="panel panel-warning">
    <div class="panel-heading">
        <h1 class="panel-title">Attention : ceci est le titre du bandeau</h1>
    </div>
    <div class="panel-body">
        <p>Ici ce trouve le texte du bandeau</p>
    </div>
</div>

(démo en ligne)

Les bandeaux ne font pas partie de la syntaxe HTML. Ce ne sont que des assemblages d’autres balises structurelles et d’un peu de CSS pour donner des couleurs. En conséquence de quoi, faire un bandeau en HTML demande beaucoup de balises, du CSS et un minimum de connaissances en syntaxe HTML.
Il en va de même pour énormément d’outils rédactionnels couramment utilisés par les web-rédacteurs partout dans le monde. Les notes de bas de page en sont un bon exemple.

La syntaxe HTML est l’équivalent pour le web de la syntaxe assembleur pour les ordinateurs

Quand on regarde la syntaxe HTML de plus prés, on se rend compte qu’il s’agit, ni plus ni moins, que d’un langage machine, comme l’assembleur.

Wikipedia est très claire sur ce qu’est un langage machine :

Le langage machine, ou code machine, est la suite de bits qui est interprétée par le processeur d’un ordinateur exécutant un programme informatique. C’est le langage natif d’un processeur, c’est-à-dire le seul qu’il puisse traiter.

Si on voit le navigateur web comme un processeur, les balises HTML comme des instructions et la page web comme un programme … la définition d’un langage machine est parfaitement respectée.

En 2015, si un développeur lambda code un programme en assembleur, c’est obligatoirement un barbu asocial qui ne comprend rien aux « langages modernes » (aka langages de « haut niveau »).
Par contre, un rédacteur web qui écrit ses articles en HTML, ça ne pose aucun problème à personne. Alors que pour le coup, le travail d’un rédacteur (web ou non) n’est pas de s’inquiéter d’un quelconque langage de mise en forme, mais bien du texte qu’il écrit.

Imaginez une seule seconde que les utilisateurs de Word ou LibreOffice soient obligés d’écrire leur document en utilisant la syntaxe OpenDocument (justement utilisait par ces deux éditeurs de texte) et que l’éditeur à proprement parlé ne fasse que de la prévisualisation. Ce serait vraiment la misère, pas vrai ?
C’est pourtant bien ce qu’il se passe actuellement avec la syntaxe HTML.

Les éditeurs WYSIWYG ne sont pas la solution

Les éditeurs WYSIWYG (« What You See Is What You Get », « Vous obtenez ce que vous voyez » en bon français) ne sont pas la solution au problème du HTML.
Même si la W3C travaille sur le sujet. Même si ça parait être la solution idéale parce que cela ressemble de très prés à un éditeur de texte classique. Cela n’est clairement pas la bonne solution.

Comme dans tous les langages de modélisation, les outils de génération graphique de code n’ont jamais eu bonne réputation.
Demandez à un développeur C/C++ ce qu’il pense de FlowCode par exemple (non, en réalité ne le faite pas, vous le regretteriez), vous aurez les oreilles qui sifflent pendant un moment.

Utiliser une interface graphique pour générer du HTML, ce n’est pas résoudre le problème, c’est juste le contourner, le dissimuler.
La vraie solution au problème serait d’avoir un langage de haut niveau par dessus HTML. Quelque chose qui fasse office de couche d’abstraction entre le HTML interprété par nos navigateurs et le texte saisi par le rédacteur.

Si je mets en gras du texte dans mon éditeur de texte, cela ne devrait pas générer bêtement une balise strong, mais générer un marqueur pour dire « ici il faudra que l’affichage se fasse en gras ».
On me rétorquera : « oui, mais c’est déjà ce que fais la balise strong ! ». Ce à quoi je répondrai : « vous n’avez rien compris au problème ».

Si j’ajoute une note de bas de page dans mon éditeur, chose que la syntaxe HTML ne gère pas nativement, que va-t-il se passer ?
Dans un WYSIWYG classique, celui-ci générait bêtement une ancre en bas de page et un lien au niveau de l’appel de la référence.
Au final, je n’ai pas fait une note de bas de page. J’ai juste ajouté de manière détournée une ancre et un lien vers cette ancre.

« OK ce n’est pas une vraie note de bas de page. Mais au moins ça marche ! »

Certes, ça marche. Enfin, jusqu’au jour où le rédacteur voudra avoir les notes de bas de page dans un encadré séparé sur le site web.
À ce moment-là, toute l’équipe informatique esquissera un grand sourire forcé en se disant « comment on va faire la différence entre un lien et une note de bas de page !? ».

Les créateurs de la syntaxe BBCODE avaient compris le problème

La syntaxe BBCODE ressemble à la syntaxe HTML. La syntaxe BBCODE s’interprète quasiment comme la syntaxe HTML.
Mais qu’on ne se trompe pas, la syntaxe BBCODE n’est PAS du HTML. C’est un langage au-dessus de HTML.

En BBCODE vous pouvez faire des choses comme : [code language= »python »]# du code python[/code]
Cela ne ce traduit pas bêtement par une balise HTML code. Il y a un préprocesseur qui interprète la syntaxe BBCODE, fait divers traitements et génère du HTML à la fin.

L’avantage de la syntaxe BBCODE c’est son abstraction forte avec la syntaxe HTML.
Si j’ai envie d’ajouter une balise [warning title= »Attention à ne pas faire … »]… Du texte important concernant un point important … [/warning], je peux.
Et même si cela se traduit par plusieurs centaines de balises HTML au final, le rédacteur lui n’utilise qu’une unique balise.

On peut détester la syntaxe BBCODE pour de multiples raisons, mais elle possède des atouts qu’on ne peut lui retirer.

Le BBCODE n’est cependant pas la solution idéale …

Même si la syntaxe BBCODE permet de s’affranchir des limites de la syntaxe HTML et d’avoir un langage de plus haut niveau pour le rédacteur, ce n’est pas pour autant la solution miracle.

Le rédacteur a toujours besoin de saisir des balises plus ou moins complexes au milieu de son texte. Et la syntaxe de ces balises, leurs effets et leurs disponibilités d’un site à un autre n’est garantie par aucune norme.

La solution « miracle » serait un langage de rédaction de haut niveau, facile à retenir, rapide à écrire, simple à interpréter et facilement extensible.
Mais un tel langage n’existe pas … encore.

… de même que Markdown, reStructuredText, Textile, etc.

À ce stade, certains lecteurs hurleront que de telles solutions existent.
Suivant les préférences de chacun, la solution miracle se nommera Markdown, reStructuredText, Textile, wikiMarkup, etc.
La vérité est qu’aucune de ces « solutions miracles » n’est vraiment miraculeuse.

Markdown par exemple, n’est rien de plus qu’un meta langage construit par dessus HTML. La norme d’origine est criblée de trous, et la plupart du temps il faut revenir aux balises HTML pour faire la moindre mise en forme un poil plus complexe qu’une mise en gras ou en italique.
Si de grands sites comme StackOverflow ou Github n’avaient pas répandu la « mode Markdown », vous n’auriez jamais entendu parler de Markdown, comme – j’en suis sûr – beaucoup n’ont jamais entendu de reStructuredText, Textile ou encore de la syntaxe Wiki.
Ajouter à cela que le créateur de la syntaxe Markdown n’a jamais entendu parler de la règle « There should be one– and preferably only one –obvious way to do it. », il n’est pas étonnant qu’il existe en Markdown trois façons différentes de faire un simple titre (et donc trois façons différentes de se tromper en faisant un simple titre).

Plus poussé que Markdown (et plus propre), on trouve la syntaxe reStructuredText.
Le seul regret que j’ai par rapport à la syntaxe reStructuredText, c’est sa complexité et son utilisation à tort et à travers de l’indentation.
Quand on travaille avec un éditeur de code qui gère l’indentation d’un simple appui de la touche tabulation, ce n’est pas un problème.
Essayez maintenant d’indenter du texte à la main dans Word ou LibreOffice, ou pire, dans une zone de texte HTML. Bonne chance et courage.
Dans le meilleur de cas, c’est très long, dans le pire, c’est impossible (si vous n’avez pas une police monospace par exemple).

Quant à la syntaxe Textile … je vais me faire massacrer par les aficionados du Textile, mais …
Je ne vois absolument aucun avantage à devoir typer chaque bloc de texte avec une balise. Cela revient à écrire du HTML/BBCODE sans les balises fermantes.
Et histoire d’enfoncer le clou, avoir des balises textuelles comme « bc. » est pour moi d’une bêtise sans nom. Si on ne plus faire la différence entre les balises de mise en forme et le texte, c’est qu’il y a un gros problème dans la syntaxe elle-même.

Mon avis personnel

Personnellement, je pense qu’on (les rédacteurs de documents, en ligne ou non) manque cruellement d’une syntaxe de haut niveau permettant d’écrire du texte riche tout en ayant une syntaxe simple et rapide à écrire. Une syntaxe qui permettrait de profiter pleinement des mêmes fonctionnalités qu’un éditeur de texte classique, sans l’éditeur de texte.

C’est mon avis. Je sais que certains ne seront pas du même avis et s’accrocheront de toutes leurs forces à leur WYSIWYG, BBCODE ou Markdown.
Pour moi, il serait grand temps que des rédacteurs et des développeurs se grattent la tête tout ensemble autour d’une table pour concevoir une syntaxe générique d’écriture de texte riche sans éditeur de texte complexe.

Discussion

14 réflexions sur “La syntaxe HTML c’est vraiment la misère

  1. Salut Skywodd,

    En ce qui me concerne, travaillant dans la création d’outils de publication WEB, le seul « remède » quant à l’abstraction de l’aspect de présentation des documents sur internet est l’utilisation d’un formalisme XML à ta sauce sur lequel tu appliques des XSLt pour créer ton rendu. Cela permet effectivement de donner des noms logiques aux différentes parties de ton document et de les transformer pour leur diffusion sur différents supports comme les tablettes, smartphones, PC… Et surtout cela te garantit d’avoir toujours tes documents « propres » sans l’aspect présentation qui de toute façon est dépendant du support de diffusion !

    Pour ma part je structure en XML en donnant des noms du style blablabla et j’applique dessus un XSLt pour générer le code HTML 5 pour un peu de responsive ou encore un XSLt-FO pour avoir un PDF…

    Publié par Marc Hisette | 15 juin 2015, 7 h 31 min
    • C’est exactement ce que fait LibreOffice avec OpenDocument.

      Le problème avec du XML et un schéma maison, c’est qu’il faut obligatoirement un GUI pour éditer le document. Et ça c’est pas envisageable pour remplacer une textarea en HTML …

      Publié par Skywodd | 15 juin 2015, 9 h 47 min
      • Ah, je n’avais pas compris que c’était pour directement rédiger l’article sur une page WEB… c’est effectivement une problématique bien souvent rencontrée dans les interfaces WEB ! Le seul moyen c’est de passer par des éditeurs écris en JS comme « CodeMirror » par exemple mais trouver celui qui fait tout bien comme on veut c’est une autre paire de manches…

        Publié par Marc Hisette | 15 juin 2015, 9 h 53 min
  2. Pour faire du html tout en simplifiant l’écriture, il y a des solutions comme jade. Pas besoin de fermer les balises, la syntaxe du css peut être utilsée pour déclarer les classes.
    Pour reprendre ton exemple, tu pourrais écrire. C’est moins lourd mais ce n’est qu’une simplification.

    div(class=panel panel-warning »)
    .panel-heading
    h1.panel-title Attention : ceci est le titre du bandeau
    .panel-body
    p Ici ce trouve le texte du bandeau

    Après pour faire de la rédaction, il existe latex.

    Publié par Jonathan | 15 juin 2015, 11 h 48 min
    • Je vois pas l’intérêt d’avoir une syntaxe balisée, sans réelles balises.
      Je suis vraiment le seul à trouver ça crade de ne pas pouvoir différencier le texte des balises !?

      Sinon pour latex … la blague 😉
      Je me vois bien demander à mes lecteurs d’écriture sur le forum avec la syntaxe Latex 🙂

      Publié par Skywodd | 3 juillet 2015, 15 h 07 min
  3. Salut. As-tu essayé BLUEFISH ?

    Publié par Michel | 16 juin 2015, 10 h 11 min
  4. Salut Skywood,

    « Certes, ça marche. Enfin, jusqu’au jour où le rédacteur voudra avoir les notes de bas de page dans un encadré séparé sur le site web.
    À ce moment-là, toute l’équipe informatique esquissera un grand sourire forcé en se disant « comment on va faire la différence entre un lien et une note de bas de page !? ». »
    Alors là, je ne te suis pas du tout. Pour moi que le principe reste le même, que les notes soient dans un encadré ou non.

    Pour moi le désavantage des éditeurs WYSIWYG, c’est qu’ils sont parfois très compliqués et qu’il faut toujours passer un temps supplémentaire pour la mise en page. Mais sur le web comme par exemple avec Gmail, je les trouve très biens. Donc là, le désavantage du WYSIWYG par rapport au BBCODE ou au Markdown, c’est la rapidité. En effet il est bien plus rapide de taper « 🙂 » que d’aller chercher un smiley dans un gestionnaire… Mais je pense que la principale raison qui fait que les éditeurs WYSIWYG sont si rare sur le web, c’est qu’il est beaucoup plus facile de programmer un convertisseur BBCODE vers HTML, qu’un éditeur WYSIWYG en javascript.

    « Le rédacteur a toujours besoin de saisir des balises plus ou moins complexes au milieu de son texte. »
    Je ne vois pas de quelles balises complexes tu veux parler, tu peux me donner un exemple ?

    « La syntaxe de ces balises, leurs effets et leurs disponibilités d’un site à un autre n’est garantie par aucune norme. »
    À moins que l’on veuille publier son article ou autre sur plusieurs sites, ce qui reste assez rare, cela n’est pas censé poser problème.

    Pour revenir au BBCODE, il est vrai que la syntaxe pourrait être revu. Je te l’accorde. Et en ce qui concerne le Markdown, il a l’avantage d’être plus rapide que le BBCODE, mais je suis d’accord avec toi sur le fait que la syntaxe n’est pas très propre.

    « La plupart du temps il faut revenir aux balises HTML pour faire la moindre mise en forme un poil plus complexe qu’une mise en gras ou en italique. »
    C’est vrai, c’est par exemple le cas si tu veux mettre de la couleur, mais il avouer qu’il est rare d’utiliser de la couleur dans un article, tutoriel ou autre.

    Au final, mon choix se porterait plutôt vers le Markdown, mais reréfléchi. Et comme parfois il peut être difficile de modifier du Markdown (comme par exemple si on veut ajouter un détail dans un tableau complexe mais que celui-ci n’est pas assez long), le must selon moi serait de faire un éditeur avec un onglet WYSIWYG et un onglet Markdown. Et cela est d’or est déjà ajouté à ma liste de projets.

    @+

    Publié par texom512 | 16 juin 2015, 13 h 42 min
    • >> Alors là, je ne te suis pas du tout. Pour moi que le principe reste le même, que les notes soient dans un encadré ou non.

      Si je veux extraire les notes de bas de page (ou n’importe quoi d’autre), je dois être en mesure de différencier une note de bas de page du reste du document.
      Si les notes de bas de page sont déclarées avec une balises dédiés, pas de problème. Chaque occurrence de la balise est une note de bas de page.
      Si les notes de base de page sont déclarées via un assemblage de balises standards, c’est de suite plus compliqué. Comment faire la différence entre un lien interne dans le document et une note de bas de page si rien ne permet de les différencier ?
      Il y a bien des solutions envisageable mais rien de solide. C’est là tout le problème justement.
      C’est comme avoir un code assembleur et vouloir revenir au code source C d’origine, c’est impossible à réaliser correctement.

      >> Pour moi le désavantage des éditeurs WYSIWYG, c’est qu’ils sont parfois très compliqués et qu’il faut toujours passer un temps supplémentaire pour la mise en page. Mais sur le web comme par exemple avec Gmail, je les trouve très biens. Donc là, le désavantage du WYSIWYG par rapport au BBCODE ou au Markdown, c’est la rapidité. En effet il est bien plus rapide de taper « 🙂 » que d’aller chercher un smiley dans un gestionnaire…

      Un WYSIWYG complet est une vrai usine à gaz et d’un point de vue implémentation, c’est une horreur (mapping DOM, etc.).
      Le principal avantage des WYSIWYG, c’est que l’utilisateur lambda ne connaissant rien à HTML, aux smiley et autre « weberies », peut faire ce qu’il veut sans plus de recherche.
      Le principal désavantage des WYSIWYG, c’est la lourdeur du process d’édition (la rapidité comme tu dis) et la lourdeur d’implémentation.

      Gmail n’utilise pas un WYSIWYG. Gmail utilise une simple zone de texte améliorée avec des raccourcis pour les différentes balises.
      C’est une sorte de WYSIWYG, mais en version ultra simpliste.
      L’idée est bonne, mais je me vois mal rédiger un article complexe avec 😉

      WordPress et plein d’autres sites utilisent un système similaire avec une zone de texte entourée de boutons de raccourcis pour les différentes balises.
      Contrairement à Gmail on se retrouve vraiment avec les balises dans le texte. C’est une zone de texte avec raccourcis, ni plus ni moins.
      Markitup par exemple permet de faire cela rapidement pour n’importe quel syntaxe (html, bbcode, markdown, wiki, etc.).

      Avantages : c’est rapide et léger.
      Désavantages : il faut connaitre la syntaxe utilisée sous peine de se retrouver avec n’importe quoi à la sortie. De plus, il n’est pas possible d’avoir 200 boutons de raccourcis, donc certaines balises sont forcément à saisir soi même à la main.

      >> Je ne vois pas de quelles balises complexes tu veux parler, tu peux me donner un exemple ?

      Pour moi div est une balises complexe par exemple (d’un point de vue rédacteur). En BBCODE il n’existe aucune balise p ou div.
      Un web-rédacteur ne devrait pas avoir à structurer un document (comme avec l’exemple dans l’article). C’est le boulot des dévs et des web-designers de définir comment doit s’afficher un document, pas du rédacteur.

      >> À moins que l’on veuille publier son article ou autre sur plusieurs sites, ce qui reste assez rare, cela n’est pas censé poser problème.

      Ok, si tu réfléchis d’un point de vue rédacteur interne au site.
      Pas ok, si tu réfléchisse d’un point de vue rédacteurs externe au site (forum, commentaires, etc).

      Exemple avec Markdown : certains sites utilisent des syntaxes maisons pour certaines mises en forme avancées.
      Sur un site –texte– va te sortir de texte barré, chez d’autre site du texte entre tirets et chez d’autre se sera ~~texte~~ qui te sortira du texte barré. Au final, si tu participes sur plusieurs sites, tu finis par ne plus savoir quelle syntaxe est valide sur tel ou tel site.
      Et crois moi, c’est très énervant de devoir jongler avec plusieurs variantes d’une même syntaxe.

      >> Pour revenir au BBCODE, il est vrai que la syntaxe pourrait être revu. Je te l’accorde. Et en ce qui concerne le Markdown, il a l’avantage d’être plus rapide que le BBCODE, mais je suis d’accord avec toi sur le fait que la syntaxe n’est pas très propre.

      Ce n’est pas une question de propreté, mais une question de normalisation.
      Markdown est une super syntaxe, mais le peu d’élément syntaxique disponible ne couvre pas les cas d’usage courant.
      C’est comme fabriquer une cafetière que ne sort que de l’eau chaude. C’est pratique pour ce faire un thé, mais pour l’usage de base (faire du café), on a vu mieux.

      >> C’est vrai, c’est par exemple le cas si tu veux mettre de la couleur, mais il avouer qu’il est rare d’utiliser de la couleur dans un article, tutoriel ou autre.

      Pour la couleur, j’ai envie de dire : pas grave. Mettre du texte en couleur, ce n’est pas un cas d’usage courant pour un rédacteur. Il faut se rappeler que certaines personnes ne voit pas correctement les couleurs.
      Un rédacteur ne devrait jamais avoir besoin de mettre du texte en couleur dans un article. Par contre faire du texte souligné, en exposant, etc. ça c’est utile.

      >> Au final, mon choix se porterait plutôt vers le Markdown, mais reréfléchi. Et comme parfois il peut être difficile de modifier du Markdown (comme par exemple si on veut ajouter un détail dans un tableau complexe mais que celui-ci n’est pas assez long), le must selon moi serait de faire un éditeur avec un onglet WYSIWYG et un onglet Markdown. Et cela est d’or est déjà ajouté à ma liste de projets.

      Perso je pense que la meilleure solution serait d’avoir une syntaxe sans balise à la Markdown, mais avec un jeu de balises normés riche pour éviter les implémentation maison. Et des zone de texte avec des boutons de raccourcis pour les nouveaux utilisateurs.
      Idéalement il faudrait que la syntaxe puisse être utilisée avec ou sans police monospace (donc exit toute forme d’indentation) et sans avoir à faire plus de trois caractères « non texte » par action (pour accélérer la saisie).

      Publié par Skywodd | 3 juillet 2015, 16 h 48 min
  5. @skywodd: t’as pensé au LaTeX? \loin{\pastaper}

    Publié par f4grx | 18 juin 2015, 10 h 32 min
  6. En meta-langage je trouve le Ruby on Rails assez efficace.
    Certes pour de la simple mise en forme ça fait usine à gaz mais on peut créer des sites, des blogs, etc … en quelques lignes.

    Publié par Cr30s | 2 juillet 2015, 12 h 52 min

Rétroliens/Pings

  1. Pingback: [PySkCode] Réinventons la roue carrée, mais avec des jantes chromées | Skyduino - Le DIY à la française - 23 novembre 2015

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

Skyduino devient Carnet du Maker

Le site Carnet du Maker remplace désormais le blog Skyduino pour tout ce qui touche à l'Arduino, l'informatique et au DIY.