Poor HTML /Continuer le Débat
Amha, cela n'intéressera jamais le W3C, ce n'est pas leur problème, ils ont d'autres chats à fouetter. Il faut monter un groupe de travail indépendant, réussir à y faire contribuer des gens qui comptent, que les gens écoutent et respectent. Il faut aussi réussir à y réunir des représentants des plus gros projets (libres ou non) susceptibles d'être intéressés (Wikis, CMS, Weblogs). Ensuite, dans ce groupe de travail, on fixe les objectifs, on discute, on regarde l'existant, on compare et dans 3 ans on a la première release de PoorHTML.
Perso, j'aime bien
[Textile] --François Hodierne
Ce n'est pas le problème d'intérêt ou pas. Le problème est plus une question de Process, si tu as des membres du W3C qui collectivement décide qu'il faille normaliser ceci parce-que c'est quelquechose qui a un impact sur le Web et les implémentations alors cela pourra se faire au W3C.
Je ne suis pas sur que ce soit totalement utile, dans le sens ou les langages textes des formulaires sont là par défaut d'outils auteurs convenables et d'implémentations d'éditions du côté serveur. --Karl Dubost
héhé, en théorie tu as entièrement raison, en pratique, on aura bientot 25 petits dialectes à la Wiki, Spip, etc ... et c'est l'inter-oppérabilité, les utilisateurs et les développeurs, qui en patiront. -- Stéphane Le Solliec
En revanche, il pourrait être intéressant d'associer toutes les langages déjà existants, la seule façon que cela fonctionne c'est que les principaux acteurs des outils implémentent cela... et là.... Soyons optimistes. Voici Grutaxt un produit et une liste de langages de ce type: --Karl Dubost
La syntaxe ressemble beaucoup à Setext, un langage qui existe depuis 1991 et est utilisé en particulier par TidBITS. Je penses d'ailleurs que leurs textes passeraient sans problème dans Grutaxt (voir
- a list of markup/data serialization languages, influenced by XML. If you know of something, that in your oppinion belongs to this page - I appreciate if you write me at paul@pault.com."
---
Le sujet est à la mode en ces derniers temps et a fait l'objet de débat sur la liste CSS française et sur wikini.net.
Cf. en particulier nos pages :
- sur l'aspect sécuritaire du HTML : http://www.wikini.net/wakka.php?wiki=HTMLPourLUtilisateur
- une synthèse sur les règles de formatage des différents moteurs de wiki : http://www.wikini.net/wakka.php?wiki=ReglesDeFormatageDesWikis
- un débat informel sur la page de Laurent Denis : http://www.wikini.net/wakka.php?wiki=LaurentDenis
Par ailleurs, il existe XHTML Basic : http://www.w3.org/TR/xhtml-basic/
XHTML Basic consists of the following XHTML modules:
- Structure Module* : body, head, html, title
- Text Module* : abbr, acronym, address, blockquote, br, cite, code, dfn, div, em, h1, h2, h3, h4, h5, h6, kbd, p, pre, q, samp, span, strong, var
- Hypertext Module* : a
- List Module* : dl, dt, dd, ol, ul, li
- Basic Forms Module : form, input, label, select, option, textarea
- Basic Tables Module : caption, table, td, th, tr
- Image Module : img
- Object Module : object, param
- Metainformation Module : meta
- Link Module : link
- Base Module : base
html basic ne répond pas au probleme, qui est, il est plus rapide d'ecrire [http://truc.com] que <a href="
Ben voila ! la preuve * 9 :o) Comme quoi pas besoin de reinventer la roue !
d'ailleurs les pseudos langages du wiki, wikini, phpbb, spip et cie sont pas tres difficiles a apprendre avec un minimum de concentration ;) ... et pour le webmaster du site : du HTML 4.0 ou sup. plein pot ! :o) -- Pierre Bernard
Bien sur c'est très facile à apprendre, mais le probleme c'est qu'il y en a 15, qu'il y en a un nouveau tous les jours, et qu'ils sont proches les uns des autres tout en ayant chacun leur petite subtilité, qui fait qu'au final, on confond facilement les différentes conventions d'écriture. C'est en plus un gros frein au partage et échange de contenu entre site (on pourrait faire de la transclusion transparente entre un site wiki et un site spip ou un weblog movabletype ...).
Je voulais juste expliquer en créant cette page qu'on est tous à notre façon en train d'essayer de combler un manque (un language qui serait à mis chemin entre le txt et le html, une sorte d'hyper-txt, ou d'html sans la lourdeur des tags) et que l'on crée pleins de petits dialectes, alors que la nécessité d'une langue commune à mis chemin entre le txt et le html, qui pourrait aussi etre utiliser par le mail, etc ... me semble réelle. Ben au final, on vera comment évolueront tous ces dialectes. -- Stéphane Le Solliec
Le travail commence maintenant Stéphane si tu veux ce genre de choses. --Karl Dubost
- Identification de tous les langages existants (Peut-être plus efficace de créer une petite base pour cela)
- Tableau comparatif des fonctionnalités avec chaque produit
- Contact de chacun des implémenteurs
- Etablissement d'une mailing-list les réunissant tous
- Développement du langage commun à tous
- Rédaction de la spec
- Phase d'implémentations dans leurs différents produits et Test Suite pour savoir si cela fonctionne bien partout.
- Correction de la spec
- Annonce en grande fanfare.
Ou....
- Identification de tous les langages existants (Peut-être plus efficace de créer une petite base pour cela)
- Tableau comparatif des fonctionnalités avec chaque produit
- Contact de chacun des implémenteurs
- Creation d'un format permettant de decrire l'organisation de chaque langage permettant des realisations de filtre facile.
Dans le 1er cas difficulté au niveau du temps que cela va prendre, il faut une personne pour piloter l'action et aller au front pour convaincre tous ses gens. Dans le 2nd cas plus facile de convaincre les développeurs mais ne facilite toujours pas l'utilisateur qui migre de langage en langage. Tu commences quand Stéphane ? -- Karl Dubost
Dès que je peux m'enfermer dans une chambre relativiste où une heure du temps de cette chambre correspond à une seconde du temps externe. Ou alors si je trouve un mécène qui veuille bien payer mes factures et mes Charges Sociales? le temps que mène le projet à terme. :-( -- Stéphane Le Solliec
Je passais par la, et a la lecture de cette discussion, je me pose une question : est-ce bien utile de vouloir unifier tout ca ? Je suis pret a parier que d'ici deux ans, tous les navigateurs auront un editeur visuel directement integre : quand on sera dans une zone de texte, on aura une barre d'outils, on pourra ajouter des liens, mettre en gras et tout le bazar. Et ca sera bien plus agreable a utiliser que :url:lien!truc etc. Ah oui, et il y aura aussi un correcteur orthographique et grammatical. Et le tout generera de l'HTML valide. Les navigateurs manquent de competition, ca serait vraiment pas tres complique a faire. -- Stephane Gigandet
C'est mon point Stephane Gigandet, il n'y a pas forcément nécessité de normalisation car comme tu le dis, l'édition dans les formulaires est une contrepartie à un manque d'outil. La deuxième génération de carnets Web entraînera la mort de Radio Userland, Movable Type, etc... malheureusement. En gros, il y a toujours l'idée et puis ensuite les précurseurs, tous les petits qui se développent et ensuite viennent les gros poissons : Microsoft, AOL, ou autres du moment. Ils fabriqueront un éditeur wysiwyg de carnets Web, etc... -- Karl Dubost
c'est contredit par la réalité d'aujourd'hui du développement de sites web. Des futurs produits wysiwyg qui vont soit disant nous permettre de développer nos weblogs facilement. C'est comme dire : ça sert à rien d'apprendre l'html, parce qu'il va bientot y avoir des outils qui nous permettent de développer les sites web en wysiwyg. A développer des pages web tous les jours, (au fur et à mesure, mon boulot devient d'ailleur de plus en plus développer ou installer des CMS) et 8 ans après le début de l'apparition des éditeurs wysiwyg (je pars de Page Mill? 1 d'adobe en 1995), les wysiwyg sont toujours aussi mal foutus. Un bon CMS à la SPIP ça éclate largement n'importe quel Dream Weaver?. Existe-t-il encore un seul site d'envergure qui soit développé avec Dream Weaver?. ;-) Je suis entièrement d'accord avec toi Karl dans la théorie, mais en pratique on est tous en train d'écrire cette page dans une pauv' textarea et en utilisant un dialecte bizaroïde mais pratique, et qui le serait encore plus s'il était standardisé. Mon envie de normalisation d'un PoorHTML est une simple envie de réponse à un problème pratique, même si c'est une entorse à la beauté conceptuelle du WWW imaginée par le W3. -- Stéphane Le Solliec
D'autant que après la normalisation de ce PoorHTML, il y aura des cms pour utiliser des raccourcis et il faudra un moteur ExtremelyPoorHTML2PoorHTML. La question peut être est celle ci : pourquoi y a-t-il des tags si compliqués en HTML? -- Olivier Legat
Les balises ne sont pas compliquées en HTML... Comparer n'importe quels langages de descriptions textuels. LaTeX et TeX sont plus compliqués au niveau du concept par exemple. Les ingénieurs en informatique font des choses plus compliqués que cela et les non ingénieurs ne devraient pas taper du code à la main. Et si tu veux que l'outil évolue, il se complexifie nécessairement. Au début, il y a eu la marche, puis l'homme a pris un subsitut appelé cheval, puis on a créé le vélo (première mécanisation), puis on a créé l'automobile... es-tu capable de construire une automobile ? non. Mais rien ne t'empêche de continuer à utiliser ton vélo. Et bien c'est pareil pour HTML, utilise le langage dont tu as besoin pour l'utilisation que tu veux en faire. Si tu n'as besoin que de p et ul et h1 utilise HTML 4.01 ou HTML 3.2 -- Karl Dubost
Offrir un editeur intégré (comme c'est déjà pratiquement le cas sur le navigateur le plus répandu) pose le problème de la cohérence ergonomique d'un site où sont amenés à publier un ensemble hétérogène de rédacteurs. Sauf si on limite en amont les capacités de l'éditeur en interdisant par exemple le changement de police... attendez une minute... mais ça fonctionne déjà comme ça... --- Olivier Legat
Les problèmes que tu soulèves ne sont que techniques. On peut très bien imaginer un éditeur wysiwyg qui fonctionne par système de templates et qui quand tu sauvegardes fait un cvs diff et n'autorise les transformations que dans les zones autorisées. Le problème le plus important est celui de l'échelle à Saumon. Comment remonter à la source de production, aux données originelles, venant par exemple d'une base de données, etc. --Karl Dubost
Il me semble avoir vu sur la page de
Je vous conseille le site de l'Oscom, institution qui a l'air de fédérer pas mal d'initiatives sur les CMS. --François Hodierne
Dernière modification le mardi 30 septembre 2003 7:59:33
