froidure_nicolas

Bienvenue sur le HUB !

Envisager un Club régional dans un premier temps peut être intéressant. Je connais au moins deux autres acteurs du Web qui seraient ravis d'en faire partie.

Si tu veux, on peut se rencontrer à ce sujet et voir ce qu'il est possible de faire. J'ai créé ma société il y a peu et c'est vrai qu'échanger les expériences ne peut être que bénéfique.

Mais, je pense que nous pouvons aller au delà du simple club. Je pense, par exemple, à une association de coopération industrielle régionale dont l'objectif serait de développer les compétences des entrepreneurs Web de la région du Nord-Pas-de-Calais.

Par exemple, j'anime un stand le 22 novembre au sein du lycée Robespierre à Lens sur l'accessibilité et le Web Mobile. J'ai pas trouvé de personne spécialisée en Web design pour m'y accompagner. Ce club m'aurait certainement permis de le faire. D'ailleurs, si ce jour là tu as du temps, tu peux passer et on discutera de ce projet.

J'utilise Notepad pour la gestion des gabarits et du PHP et mon composer pour la rédaction des pages en XHTML.

Je connais une entreprise belge qui est très réputée :

HONet

Bonjour à tous

Ce matin, en jetant un bref coup d'oeil sur le log d'ElitWork, j'ai trouvé ceci :

crawl-66-249-66-5.googlebot.com - - [14/Nov/2006:06:03:14 +0100] "GET /xhtml_tutoriel.html HTTP/1.1" 200 23815 "-" "Nokia6820/2.0 (4.83) Profile/MIDP-1.0 Configuration/CLDC-1.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)"

J'en conclue donc que Google est passé avec une configuration mobile sur mon site. Du coup, je suis allé sur le site de recherche spécial mobile et j'ai recherché "elitwork" en sélectionnant "Web Mobile", malheureusement, je ne trouve rien. Alors j'ai recherché sur le Web et Google a adapté la page aux mobiles.

Cependant, je ne vois pas de grande différence avec la source originale à part le remplacement (incompréhensible ?) des balises <strong> par <b> par exemple alors que la DTD est du XHTML. Bref, est-ce que l'un d'entre vous en sait plus sur la stratégie de Google sur ce point ?

J'ai voté un peu vite avec 50-100 mais pour le mois derniers, c'est 191 visites à partir du Hub.

Ton éditeur Wysiwyg va servir à quoi ? Je peux peut-être faire une exception pour les membres du HUB. Regardes ma signature.

Convertir Wikipedia n'est que convertir un langage en un autre, idem c'est faisable très facilement ne t'en déplaise.

Pas le peine de s'attarder sur ce point, chacun campe sur ses positions... ça ne mène nulle part...

Et tu l'utilises comment ton XHTML-à-la-mode ? En le servant comme text/html.

Donc je redis: http://www.hixie.ch/advocacy/xhtml.fr/ (mais lis-le jusqu'au bout cette fois)

Tu ne me fais pas découvrir cet article, mais pour te répondre, c'est un choix statégique. La seule chose que j'aurai à changer le moment venu, c'est l'entête. Utiliser le XHTML n'a pas que des inconvénients. L'auteur le dit lui même. Ce que moi je sais, c'est que dans un certain temps de nouvelles façons d'exploiter le web vont naître. Et qu'à ce moment là, tout ce qui ne sera pas en XHTML n'en profitera pas. Certes il existe des invonvénients à utiliser le doctype xhtml maintenant, mais ils sont minimes (voir transparents car personne ne s'en rend compte) par rapports aux avantages d'utiliser le xhtml plus tard. Et je ne souhaite pas me retrouver avec plusieurs dixaines de sites à modifier.

PS: J'apprecierai que tu modères tes propos et que tu arrêtes de me prêter des intentions que je n'ai pas.

Je pense que tu n'as rien compris au sens de ce message :

et en HTML strict ça fonctionnerait ?

Alors, j'entre mon XHTML ou mon HTML (ben oui, je dis XHTML car c'est ce que j'utilise, mais en HTML, c'est pareil) dans le champs textarea. Je poste le formulaire, je retire les balises incompatibles et je stocke dans la base. Les balises incompatibles dépendent du language. Ta question n'a donc pas de sens...

Je ne comprends pas ta réponse, visiblement tu as mal compris ce que je disais.

Toi non plus apparemment... C'est pourtant simple, apprendre le Wiki ou le BBCode, c'est aussi long que d'apprendre quelques balises XHTML...

Ça coûte quoi de faire 3 ou 4 requêtes SQL pour passer d'une syntaxe à une autre ?

Un forum... 3 ou 4 balises en BBCodes... C'est pas énorme, mais va-t-en convertir Wikipédia par exemple... Il est là le problème... Pou un site impopulaire ça ne pose effectivement pas de problème, mais il ne faut pas attendre d'avoir du succès pour réagir.

Tu vois vraiment deux concurrents donner aux utilisateurs des scripts pour migrer d'une solution à l'autre ? Allo ici la terre.

On sera encore obligés de pondre nos convertisseurs nous-mêmes pendant un bon moment encore.

Je te trouve contradictoire, tu parle de convertir comme une obligation, tu utilise le mot "encore" et pourtant, tu ne sembles pas souhaiter que ça change ???

Le HTML 3.2 est normalisé depuis pas mal d'années. Même l'HTML 2.0 l'était et l'est toujours.

Pourquoi préférer un XHTML à un HTML ? Avant d'avoir le plaisir de lire tes arguments, je sors les miens.

Je pense que c'est ça le noeud du problème, je pense que tu prépares tes arguments avant de comprendre les miens... Je te ramène donc quelques lignes au dessus dans ce message, à l'endroit où j'explique que je parlais du XHTML parceque c'est ce que j'utilise, mais que le HTML s'y prête très bien.

... pour le programmeur ou l'usager ?

Je suis autodidacte et c'est en voulant aller plus loin que j'ai acquis mon savoir faire. C'est au moment où j'ai cliqué droit et que j'ai affiché la source que je suis passé d'utilisateur à webmaster puis programmeur par effet boule de neige. Je pense qu'apprendre le BBCode ou le (X)HTML est au même niveau de complexité à part le fait que le (X)HTML peut servir à d'autres fins que de poster un message dans un forum. Dès lors, pourquoi se priver. C'est un peu comme l'histoire de l'esperanto. Il n'est pas utilisé car parler anglais, ça peut servir à parler entre personnes de différents pays, mais ça sert aussi à parler aux anglais. Alors que l'espéranto n'est fait que pour parler entre personnes de différents pays.

Et quand je saute 3 lignes, ça affiche du <br /><br /><br /> en veux-tu en voilà ?

Heu, ça, tout dépend si tu code proprement ou non... mais c'est une autre histoire. Essaies de sauter trois lignes sur le HUB...

L'idée c'est un seul navigateur pour tout le monde: Firefox ?

Encore une fois, je trouve que tu mets la charrue avant les boeux. Voici ma phrase :

- Sans compter l'utilisation d'éditeur WYSIWYG pour ces 20% comme le BBComposer pour les utilisateurs de Firefox qui vont d'ailleurs, je pense, se généraliser.

J'admet volontier qu'il manque un peu de ponctuation, mais cela dénote bien le fait que tu n'éxamine pas assez mes arguments pour les comprendre vraiment. Le "qui vont d'ailleurs se généraliser" se rapporte aux "éditeur WYSIWYG" et non à mon extension, je serai prétentieux pour croire que tous vont l'utiliser, si 1% des utilisateurs français de Firefox l'utilisaient, ça serait déjà une grande victoire pour moi.

Sans moi, merci. Il y a quelques années, Netscape était à peu près aussi honni que l'est Explorer aujourd'hui. Et Explorer apparaissait comme LE navigateur à adopter.

Aujourd'hui il est de bon ton d'haïr Explorer et de souhaiter 100% de stats Firefox..

..it's just an history repeating

Ceci n'a donc plus rien à faire dans le débat... Débat qui semble d'ailleurs mal parti pour aboutir à quelque chose d'autre que le scinisme ou l'ironie, malheureusement... C'est culturel en France...

Effectivement, c'est autre chose. Mais en même temps, je pense qu'il faut se rappeller la règle des 80 / 20.

80% des utilisateurs utilisent moins de 20% des fonctionnalités.

Combien de personnes utilisent vraiment ces balises ?

L'idée c'est de dire, pour 80% des utilisateurs, c'est strong, em, a, q et img.

Et pour les 20% qu'il reste, c'est du XHTML pur pour aller plus loin. Sans compter l'utilisation d'éditeur WYSIWYG pour ces 20% comme le BBComposer pour les utilisateurs de Firefox qui vont d'ailleurs, je pense, se généraliser.

En fait, on a cherché dans les BBCodes et le Wiki, ce qu'on avait sous les yeux, notre bon vieux HTML !

... ils auront une application open-sources mais qui sera loin d'être sécurisé. Et si ils se font "pirater", vers qui ils vont se tourner : moi.

Un aspect que je n'avais pas envisagé, mais qui risque effectivement d'être problèmatique... Sérieusement, se mettre à l'Open Source, c'est une bonne solution marketting, ça fait "vendeur", mais une mauvaise solution de fidélisation client.

Vous voyez vous réellement à devoir formater chaque post sur un forum avec toutes les balises du XHTML ?

Devoir utiliser les balises à chaque paragraphe, chaque retour à la ligne, et pire encore pour insérer un lien ou une image. Cela voudrait dire qu'en plus à l'heure du CSS on devrait connaître la feuille de style de chaque site, forum ou wiki pour pouvoir écrire dedans... (oui le centré, justifié, etc...).

Je parle de l'utilisation du XHTML à la manière des BBCodes, c'est à dire pour la création de textes en gras, de liens, d'images... etc...

Les retours à la ligne et paragraphes se font automatiquement !

Ce que je fais, c'est que j'ajoute un checkbox coché par défaut (ajouter les paragraphes et sauts de ligne automatiquement). L'utilisateur avancé ou qui utilise le BBComposer la décoche et l'utilisateur lambda peut taper son texte en toute transparence.

En fait, tu veux dire ce que Laurent Jouanneau disait ici: La syntaxe wiki n'est plus ce qu'elle était.

Pas exactement, mais on constate la même chose à propos du Wiki, mais, ce n'est pas difficile de tomber d'accord là dessus...

je ne suis pas d'accord avec ta pensée sur l'XHTML.

Comment peux-tu dire de l'utiliser sur un forum par exemple, ou un wiki ? C'est la porte ouverte à :

• des abus, utilisation abusive de Javascript vicieux, XSS, et compagnie :->>> Je ne recomande pas de mettre à la disposition des usagers toutes les balises XHTML, mais seulement quelques-unes, celles qui sont justement utiles dans un forum.
  
• une dégradation de la qualité de la page, il suffit d'une personne qui utilisera un <font> ou autre balise dépréciée :->>> Ca rejoins ce que je dis au premier point, la balise font ne fonctionnerai pas dans un forum en XHTML...
  
• une discrimination envers ceux qui ne savent pas écrire en HTML, je connais pas mal de "profanes" qui réussissent rapidement à écrire en BBCode ou en Wiki en ignorant tout de l'HTML. :->>> Le Wiki et le BBCodes, partant de ton principe serait une discrimination eux aussi, je ne comprends pas le sens de ce point pour toi...
  

Quant à stocker le code wiki en base de données c'est tout de même plus simple dans le cadre d'un CMS de stocker le contenu, quel qu'il soit, en base de données.

Le noeud du problème, c'est de savoir pour qui ça doit être simple, l'usager où le programmeur... Pour ma part, je pense que l'usager est roi.

Et un changement de CMS a toujours été une étape plus ou moins problématique.

Raison de plus pour que ça change !

Là où je suis d'accord en revanche, c'est qu'il faudrait une uniformisation des syntaxes: un BBCode pour tous (et pas un différent pour IPB, PunBB, PhpBB, MyBB, etc.) et un Wiki pour tous.

C'est là que le XHTML a un rôle à jouer car si on se contentait d'implémenter le XHTML, étant donné qu'il est déjà normalisé, cette dérive du code différent pour chacun serait aux oubliettes !

Par contre, dans l'article que tu donnais tout à l'heure, il y a un argument supplémentaire que je n'avais pas envisagé, mais apprendre le XHTML, c'est vrai que c'est utile, plus que le BBCode ou le Wiki. Le XHTML a d'autres applications que de créer des messages dans les forums. Et puis, le XHTML permet de créer des éditeurs WYSIWYG plus simplement.

Bref, je pense qu'il est plus simple de faire du XHTLM.

Voilà, j'ai découvert la syntaxe Wiki pour la première fois sur le forum XulFR. Je me suis dit, pourquoi pas ! Ca peut être sympa comme concept, ça permet d'éditer rapidement des listes etc...

Jusqu'à ce que je décide de créer un mode Wiki pour le BBComposer... Je me suis rendu sur l'Encyclopédie Wikipédia pensant que c'est là que je trouverai la meilleure façon d'implementer sa syntaxe.

Déjà, je me suis dit, ils éxagèrent... On a fait un procès aux BBCodes à cause de ses crochets et on en retrouve dans la syntaxe Wiki pour les URL ou les images... Je me suis dit qu'ils auraient dû mettre la syntaxe des BBCodes pour ça, y'a autant de crochets...

Mais bon, j'ai continué ma prog... Je me suis aperçu, par ailleurs, que chez XULfr, le gras se notait comme ça : __gras__, chez Wikipédia, come ça : ''gras''. J'ai dit, bon tant pis pour Xulfr...

Je retourne sur Wikipédia et je me rend compte que pour les textes en indice et en exposant, là, on utilise du html : <sub> <sup>... Alors, je vous dit pas le mix, je décide de faire un support Wiki sommaire car il devenait impossible de mixer toutes les originalité de chacun.

Enfin, je tombe sur cette page qui explique le Wiki sous Dotclear... Alors là, je pète un cable ! Une syntaxe encore complètement différente...

Ma question est donc :

Si aujourd'hui nous sommes sur le chemin de la standardisation grâce au W3C, je constate que sous l'étendard de je ne sais quelle simplicité d'utilisation (ça me fait rire ! faîtes un tour dans le bac à sable de Wikipédia pour apprecier la symplicité... ou encore, sur le lien de la syntaxe DotClear cité plus haut), on joue les apprentis standardisateurs par ci, par là. On en est réduit à faire de la conversion...

Je sais pas pour vous, mais moi, ça me rapelle quelque chose ! Et bizarrement, cela intervient au moment ou tout le monde est plus où moins d'accord sur l'utilité du standard.

Alors moi, mine de rien, je me demande si certains ne font pas semblant de jouer le jeu des standards et bloquant finalement l'utilisateur avec (pardonnez-moi l'expression, mais je n'ai pas trouvé d'autre mots) du code propriétaire !

Alors j'adresse ce message à tous ceux pour qui les standards importent vraiment, ne vous laissez pas prendre au piège ! Le XHTML existe ! Servez-vous en !

Pour moi, les deux seules solutions potables (mais pas non-plus parfaites) sont les suivantes :

• Utiliser le XHTML pur et simple, soit directement, soit dérivé de façon à mieux le parser (comme les XBBCodes).
  
• Utiliser le Wiki, mais très modérément (ne pas devenir plus compliqué que le BBCode...) en proposant toujours une alternative XHTML. Et, enfin, et surtout, ne pas stocker le Wiki dans la base de donnée !!! Changer de CMS peut devenir un vrai cauchemard !
  

Le Wiki n'est pas fait pour faire de la publication, il est trop limité et sa compléxification devient un vrai b..... car chacun fait à sa sauce. Pour un forum, soit, mais pas plus.

Entièrement de l'avis de Dadou.

A mon avis une application propriétaire abandonnée est bien plus problématique...

Bien au contraire ! Une application open-source abandonnée combine les inconvénients ! D'une part, son code est ouvert donc les failles sont plus faciles à trouver, et d'autre part, le développement étant arrêté, il n'y a pas de correctif à mettre en place.

Alors que dans le cas d'une application propriétaire, certes, il n'y a pas de suivi de l'application, mais au moins, ses failles ne sont pas publiques. Et dans l'hypothèse où la boîte se casse la gueule, alors c'est que l'application est pas très utilisée et donc, par extension, qu'elle ne fait pas l'objet de convoitises de la part des acteurs du hacking.

Quand à l'effet de mode, il est bien présent. Avant, tout le monde ne jurait que par PHPNuke... Aujourd'hui, qui encore l'utilise ? Et demain ? Les CMS, même les propriétaires, sont voués à être abandonnés car il y aura toujours mieux. C'est dans quelques années que les gens subiront le choix du libre aujourd'hui.

En fait, ca peut être un problème si le projet est abandonné ou rencontre une évolution qui fait qu'une mise à niveau s'impose (dans ce car, les anciennes versions ne sont plus mises à jour malgré la découverte de failles).

Il y a aussi la tendance fashion victim des acteurs du libre qui passent de projets en projets et qui abandonnent les anciens projets pour en faire des nouveaux. Cet effet turn-over me laisse perplexe sur la perrennité d'un CMS open-source.

Je suis de l'avis de Dadou, et pourtant, cela serait si simple, un système à la update.rdf de Firefox... et une tâche cron quotidienne, par exemple...

Ok, merci, même si je ne comprends pas trop le déplacement vu qu'on parlait justement de sécurité...

C'est à n'y rien comprendre...

De plus, depuis, j'ai reçu un message sur la ML PHP d'OVH concernant un site Joomla piraté :

HRP> Bonsoir,

HRP> J'ai eu des pb aussi avec joomla mais sur un dédié.

HRP> Vas sur http://www.joomlafrance.org/ le forum et sécurité.

HRP> Tu y trouveras toute la liste des composants leurs failles et les

HRP> updates.

HRP> La 1.0.11 est je crois la dernière avant la 1.0.5 beta

HRP> La faille doit venir de ce que tu as ajouté.

HRP> Bon courage

HRP> JP

Merci pour cette info. Il y a en effet pas mal de composants qui présentent des

failles de sécurité. Je viens d'en mettre à jour quelques uns...

Joannes de KOSTER

Concrètement, je dirai que le logiciel libre n'est pas plus sûr que le logiciel propriétaire. Je pense simplement qu'il est plus facile de trouver une faille dans un logiciel libre que dans un logiciel propriétaire.

Maintenant, ce n'est pas un problème si on fait des mises à jours fréquentes, mais cela nécessite des connaissances... Et donc, une maintenance régulière... et donc, un dépendance.

Note du modérateur : Splitté de la discussion CMS, web-agency : complémentaire ?, car là on rentre dans un débat à part entière...

Je suis tombé par hasard sur ceci :

http://www.zdnet.fr/actualites/informatiqu...9,00.htm?xtor=1

Je crois qu'il a raison et ça corrobroe avec ce que je disais plus haut sur la sécurité des logiciels Open Source.

Le BBComposer doit encore être amélioré et subit un bug de la version 2.0 de Firefox qui empêche le pointage direct d'un élément textarea... Pas de bol, c'est le noeud de mon extension... J'ai fait un patch de correction temporaire... Je pense faire une adapt à la syntaxe Wiki pour que tout soit supporté.

Mais pour en revenir à nos moutons, j'attend avec impatience une adaptation pour ModX... Pour Spip, c'est déjà fait, mais si tu veux, tu peux améliorer ça car comme je n'utilise que mon CMS, je ne suis pas prêt de faire le test pour voir si ça marche.

Bah, je pense que ça ne vaut pas la peine de continuer cette discussion. On a chacun fait nos choix en matière de création de sites...

La seule chose qui est sûre, c'est que si un CMS Open Source était vraiment abouti, alors tout le monde y plancherai plutôt que de faire chacun dans son coin sa petite sauce...

Pour les innovations dont je te parlais, je pourrai citer les captcha vocal que beaucoup n'ont pas encore créé ou encore, le BBComposer que je propose à mes clients et que j'utilise en ce moment pour rédiger ce message.

D'ailleurs, j'en profite pour passer un petit message aux membres du HUB qui peuvent le télécharger gratuitement.

C'est une excellente initiative, je pense que l'accessibilité n'est pas assez connue encore. Je m'en suis rendu compte avec mon BBComposer qui nécessite un champs textarea avec un id. Et encore un bon nombre de forums et CMS ne l'utilise pas (et donc, par extension, n'utilisent pas <label for="...">).

C'est regrettable, mais bon, des initiatives comme la tienne peuvent inverser la tendance.

Effectivement, c'est un point de vue. mais dans le cas où tu adoptes un CMS tu ne peux pas prédir son évolution et donc ton activité dépend d'une communauté qui peut tout aussi bien s'éteindre du jour au lendemain ou encore, prendre une orientation en contradiction avec la politque commerciale de ta société... Bref, avoir mon propre CMS c'était aussi conserver mon indépendance et prendre les orientations qui me plaisent.

Ca me permet de marquer un temps d'avance dans certains domaines par rapport à mes concurrents qui peuvent devenir des arguments commerciaux redoutables.

Et puis, chacun sait que dérrière une communauté de développeur, en général, il y a un "noyau dur" de quelques "élus" qui fond le plus gros du travail... Ca peut largement être égalé voir devancé par une équipe de développeurs dans une société privée.

Quand aux extensions faîtes par des développeurs qui n'ont pas vraiment participé à l'écriture du noyau, c'est autant de failles potentielles... et donc, rarement un gage de qualité, surtout pour les plus marginales...

XCMS occupe 586 Ko (600 135 octets) dont 124 Ko (127 538 octets) pour les fichiers sons (alphabet + chiffres) et 289 Ko (296 212 octets) pour le fichier .ttf des polices du captcha.

Les images ne sont pas pris en compte (mais il y en a très peu comme il est en XHTML et CSS... C'est juste des boutons pour faire joli, mais pas nécessaires.

En fait, je pensais à ça en posant la question car les requête du genre tarifs site internet doivent être fréquentes...

De plus, étant donné que je pratique pas des prix faramineux, je me dis que ça pourrait attirer une clientèle, mais en même temps, j'ai peur que les clients se mettent à en vouloir trop...

Je me tâte à savoir si je ne vais pas créer un deuxième site plus commercial avec les tarifs.

Le problème, c'est que ce n'est pas accessible aux handicapés visuels...