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.

Pas le peine de s'attarder sur ce point, chacun campe sur ses positions... ça ne mène nulle part... 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 : 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... Toi non plus apparemment... C'est pourtant simple, apprendre le Wiki ou le BBCode, c'est aussi long que d'apprendre quelques balises XHTML... 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. 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 ??? 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. 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. 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... 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. 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. 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 !

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.

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.

Pas exactement, mais on constate la même chose à propos du Wiki, mais, ce n'est pas difficile de tomber d'accord là dessus... 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... 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. Raison de plus pour que ça change ! 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. 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é : 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...