L'expérimentation Bespin
Par Laurentj le dimanche, février 22 2009, 19:08 - Technologies Web - Lien permanent
Comme vous le savez certainement, un nouveau projet est sorti des laboratoires de Mozilla : Bespin. C'est un éditeur de code en ligne. En découvrant ses entrailles, j'ai été bluffé par le fait qu'ils utilisent l'élément canvas pour faire le rendu.
Utiliser canvas signifie qu'ils n'utilisent pas les mécanismes d'édition existant dans les navigateurs, mais ont tout ré implémenté en javascript :
- mécanisme de sélection
- gestion du curseur
- gestion du clavier
- affichage du texte
- transaction manager (undo/redo)
- etc.
Mais pas tout. Pas encore en tout cas.
- pas de vrai copier collé. Je veux dire par là : le contenu copié ne peut être copié dans une autre application. Et cela va être compliqué à implémenter à mon avis puisque il s'agit d'une page web et qu'une page web a des restrictions à cause des problématiques de sécurité (pas d'API javascript pour envoyer des données dans le presse papier du système il me semble)
- la gestion du clavier : ils sont obligés de reprogrammer tous les raccourcis claviers courants, et là encore, cela va être compliqué pour certains, à cause toujours du fait que les possibilités d'une page web sont limités vis à vis du système.
- la prise en charge du clavier vis à vis des alphabets et cie : je me demande encore si ils vont arriver à tenir compte de tout les types de claviers, des alphabets etc.. Quid du support de l'IME par exemple ?
- Quid de l'accessibilité ? Parce que finalement, canvas, c'est comme une image. Le texte est pour le moment stocké dans des variables javascript. Cet éditeur vaut donc 0 en terme d'accessibilité. Ils envisagent toutefois de stocker le texte dans le DOM, à l'intérieur de l'élément canvas. De ce fait, il sera accessible aux outils d'aide à la navigation (comme les lecteurs d'écrans). Mais j'ai un doute quant à la bonne prise en charge par ces mêmes outils de ce texte. Possible que des attributs ARIA aideront...
Bref, ayant bossé moi même 4 ans dans le code de l'éditeur HTML interne de Firefox, et vu la complexité de certaines choses (comme le support de l'IME et autre), je me dis que pour que Bespin arrive au niveau des éditeurs "desktop", ils ont du chemin à parcourir, voir des impossibilités.
Cependant, pour réaliser un éditeur de code qui tienne la route dans une page web, il est clair qu'en l'état actuel de la technologie web, canvas me semble la meilleure option. Les développeurs s'en sont d'ailleurs largement expliqué (premier billet, deuxième billet).
Mais j'aurai préféré qu'un éditeur de texte soit implémenté directement dans le navigateur. Cela aurait permis d'une part de réutiliser les mécanismes internes d'édition et d'accessibilité dans les navigateurs, et d'éviter donc de réinventer la roue.
<textarea type="rich" syntax="cpp.xml" options="indent:4; indent-type=space">
machin->truc()
</textarea>
Ça aurait eu plus de gueule non ? Et surtout beaucoup plus léger dans la page web. (Resterait à standardisé cette fonctionnalité, c'est vrai). Et cela n'aurait pas empêché d'avoir ce mécanisme de service web qui existe dans bespin pour interagir avec un serveur afin d'apporter d'autres fonctionnalités, comme l'on déjà fait des développeurs d'éclipse.
Mais bon, je rêve, je rêve...
Commentaires
Tu ne rêves pas tant que ça, voici ce que l'on peut lire à la fin du deuxième post de Ben Galbraith à propos de l'utilisation de canvas :
"we’re already talking with standards folks and browser folks about how best to pull some of these ideas back into the browsers."
http://benzilla.galbraiths.org/2009...
A mon sens ils ont fait ce qu'il fallait : fournir l'implémentation avant d'essayer de la faire standardiser.
Sinon tes questions sur l'accessibilité en soulèvent d'autres pour moi. Comment ils font les développeurs aveugles ? Un lecteur d'écran ça me parait bien insuffisant...
PS: le textarea est trop étroit dans les commentaires.
>fournir l'implémentation avant d'essayer de la faire standardiser.
Une implémentation, ça ne se standardise pas. Tu standardises plutôt des specifications ;-) Disons que Bespin est une experimentation, et elle va permettre de détecter les manques en terme d'API qu'il faudra specifier (et donc standardiser) et implémenter dans les navigateurs.
>Comment ils font les développeurs aveugles ? Un lecteur d'écran ça me parait bien insuffisant...
Ils ont aussi un clavier braille par exemple... Mais pour "rendre" ce qu'il y a à l'écran, il n'y a que les lecteurs d'écrans.
>le textarea est trop étroit dans les commentaires.
en attendant, utilise un navigateur qui te permette de changer la taille des textarea, ou firefox + l'extension resizeable textarea ;-)
Il y a eu si je ne me trompe pas des intégrations de Scintilla avec Mozilla (pour Komodo je crois), mais je ne sais pas si le code a jamais été libre.
Cette solution serait effectivement la meilleure, mais limitée à un seul navigateur. Je ne pense pas qu'on fasse entrer dans une spec les caractéristiques d'un IDE à intégrer aux navigateur.
Un des avantages de la solution basée sur Canvas est qu'elle est théoriquement multi-plate-forme. Pour réaliser un bon éditeur basé sur Canvas, il faudra sans doute faire évoluer la spec Canvas, mais ça me semble plus envisageable que de définir dans HTML5 ce que pourrait être un "textarea riche".
PS: d'accord avec lrbabe, la textarea de saisie de commentaire est beaucoup trop petite. Heureusement qu'on vit dans un monde hackable où Firebug ou Stylish permettent de corriger ça ;)
@clochix:
>Il y a eu si je ne me trompe pas des intégrations de Scintilla avec Mozilla (pour Komodo je crois), mais je ne sais pas si le code a jamais été libre.
bien sûr que si : http://openkomodo.org
>Je ne pense pas qu'on fasse entrer dans une spec les caractéristiques d'un IDE à intégrer aux navigateur.
je n'ai pas parlé d'un IDE, mais d'un éditeur, de fonctions d'éditions évoluées.
>Un des avantages de la solution basée sur Canvas est qu'elle est théoriquement multi-plate-forme.
oui, mais l'utiliser pour tout et n'importe quoi (ici un éditeur), c'est ne pas aller dans le bon sens selon moi.
Si canvas est utilisé ici, c'est bien à cause du manque de fonctionnalité dans les éditeurs présents dans les navigateurs.
>il faudra sans doute faire évoluer la spec Canvas,
Faire évoluer canvas ?? canvas, c'est une image. Je ne vois pas le rapport entre une image et un éditeur. Une API pour faire de l'édition n'aurait aucun sens dans la spec canvas
>mais ça me semble plus envisageable que de définir dans HTML5 ce que pourrait être un "textarea riche".
C'est pas plus envisageable, dans la mesure où l'objectif de canvas n'est pas d'apporter des fonctions d'édition, et dans la mesure ou la spec de canvas est presque figée. Ça aurait bien plus de sens d'améliorer les spécifications des fonctions d'édition de textarea, puisque textarea, c'est déjà un éditeur de texte ! Apporter des options sur le textarea pour apporter la coloration syntaxique, l'affichage des numéros de lignes, la configuration de l'indentation et autres, seraient bien plus logique à apporter sur une balise textarea que sur canvas (qui, je le rappel encore une fois, n'est concrètement qu'une image modifiable).
Pareil, même si Bespin est impressionnant techniquement, pour la plate-forme Mozilla je persiste à penser qu’un vrai composant d’édition de code serait préférable, et que Scintilla serait de loin le meilleur candidat : léger, performant, complet (coloration syntaxique, pliage de code, auto-complétion, etc.).
Le problème du binding Scintilla d’ActiveState (scimoz) c’est qu’il est particulièrement merdique à utiliser hors d’une application Komodo, et que Mozilla ne voit pas l’intérêt de bosser sur ce composant. À ce titre, Bespin c’est mieux que rien — même si c’est loin d’être satisfaisant pour la plate-forme Mozilla en général.
PS : bien pratique cette extension Resizeable Textarea, merci pour l’info ! ;-)
https://addons.mozilla.org/fr/firef...
+1 pour l'intégration dans le navigateur.
J'explique la même approche pour le wysiwyg ici :
http://bbcomposer.elitwork.com/phil...
Mais bon, les habitudes vont bon train.