Bruno Michel a écrit 3285 commentaires

La principale limitation de la CSS personnalisée est que cela se limite à la CSS et aux ressources liées à la CSS comme les images. Il n'est donc pas possible de modifier le markup HTML pour ajouter des classes ou ids qui manqueraient par exemple (on peut toujours me demander pour ça), ni réorganiser la page différemment.

Parce qu'ils n'ont rien à faire dans < head > ;-)

Plus précisément, il est recommandé de mettre les javascripts en bas de page pour optimiser le temps de chargement de la page. C'est d'ailleurs l'une des règles de YSlow : http://developer.yahoo.com/performance/rules.html#js_bottom

Un effet de bord intéressant est que cela force à écrire du javascript un peu plus proprement. On ne peut plus utiliser jQuery dans des scripts inline par exemple.

> Y a-t-il un framework javascript type jQuery/Mootools ou autre d'utilisé ?

Oui, on utilise la dernière version de jquery. Les javascripts sont inclus tout en bas de la page HTML, juste avant le </body>

L'installation de RoR n'est pas obligatoire du tout pour faire une feuille de style. On peut, au choix :

- utiliser la machine virtuelle proposée dans cette dépêche
- utiliser la fonctionnalité « feuille de style personnalisée » depuis http://alpha.linuxfr.org/ (se connecter, puis aller sur changer de style, rentrer l'URL de la feuille de style et cliquer sur OK).

Même si vous ne pensez pas soumettre de projets pour le concours, vous pouvez participer à le faire vivre :
- en proposant des idées de Killer Features HTML5 que vous aimeriez voir sur le site
- en suivant l'exemple de suizokukan, qui va nous proposer des images pour la page 404
- en testant la nouvelle version Rails sur http://alpha.linuxfr.org/

Là, je suis perdu. Qu'est-ce que tu appelles charité ?

Si je fais un don à framasoft, on peut effectivement penser que c'est en échange d'un service; Ça ne serait donc pas de la charité.

Si maintenant, je fais un don à l'April sans en tirer d'avantage, uniquement parce que je pense que c'est dans l'intérêt général, c'est du mécénat. Est-ce que ça rentre dans ta définition de charité ?

Si dans ma phrase précédente, on remplace April par le Secours Catholique, est-ce que cela change quelque chose ? Et si oui, en quoi ?

J'irais lire l'article du mondi diplomatique quand il sera disponible intégralement en ligne, mais pour le moment, je note juste qu'il y a 3 liens "Faire un don" sur la page en question.

Je connais bien RadiantCMS. Il est utilisé par Ruby France et ruby-lang.org, 2 sites où il m'arrive d'écrire du contenu.

Ça marche pas mal, mais je ne suis pas fan de la manière dont il organise le contenu. L'interface d'administration est aussi assez mal foutue à mon goût. Par exemple, sur ruby-lang.org, il faut s'armer de patience si on veut éditer une des news anglaises car il y en a beaucoup, que l'interface peut mettre plusieurs minutes à se charger et que la navigation n'est pas optimale.

Oui, il y a en a beaucoup, mais aucun ne sort du lot.

Si on prend l'exemple de Forgeos, il sert à faire des sites statiques (pas de notions d'utilisateurs, seuls les admins peuvent écrire des contenus), il n'est pas maintenu (pas de commit depuis plusieurs mois), le code fait peur à voir.

Pour les sites statiques, je recommande plutôt d'aller voir Locomotive : http://www.locomotiveapp.org/.

Je doute très fortement que Microsoft va utiliser la même stratégie pour F#. C'est un des langages supportés de base dans Visual Studio (les autres étant C, C++, C# et VB), ce qui est un engagement très fort de la part de Microsoft.

On peut de nouveau utiliser une CSS personnalisée venant de l'extérieur.

L'utilisation de Ruby on Rails n'est pas obligatoire.

Si tu peux faire ton idée avec juste du HTML statique, du JS et de la CSS, cela ne pose pas le moindre problème, je pourrais très facilement l'intégrer. S'il y a un peu de PHP, pareil, je peux facilement faire le portage.

Maintenant, si le code PHP est très important, la proposition ne sera pas éliminée mais il y aura des points en moins.

Si tu as un doute et que tu veux mon avis avant de te lancer, n'hésite pas à m'envoyer un mail à NoNo AT linuxfr DOT org.

Oui, le système de karma a été simplifié.

Ce que l'on appelle le karma sur la version templeet correspond généralement aux XP, un score qui évolue à coup de + ou de- au fil du temps (exemple : une personne dont la dépêche est acceptée gagne 50XP). Mais parfois, ça sert aussi à désigner la note moyenne des commentaires sur 15 derniers jours (exemple : tu n'as pas assez de karma pour poster un journal).

Au final, les règles sont compliquées et même nous, admins, ne sommes pas sûrs de toujours comprendre comment cela fonctionne (en fait, pour ma part, je suis même de ne pas tout y comprendre).

Du coup, le système a été refait mais il va me falloir du temps pour l'ajuster.

Markdown ne propose rien pour faire ça de base. Par contre, l'implémentation de markdown utilisé ici (discount) permet de faire ça. Toutes les dépêches assez longues auront automatiquement une table des matières sans que l'auteur n'ait rien à faire.

Tu fais référence au logo ?

Le logo est un cas particulier : les admins du site changent de temps en temps le logo et nous souhaitons que ce changement s'applique à toutes les feuilles de style par défaut. Après, si vraiment le logo ne convient pas à une feuille de style en particulier, il reste toujours possible de passer par le !important.

> J'espère qu'il y aura comme actuellement la possibilité de changer la feuille de style (j'utile actuellement la zenburn).

Oui, cette possibilité va rester. D'ailleurs, toutes les propositions de CSS pour le concours seront proposées via ce mécanisme.

> Est-ce qu'il va encore y avoir une « une » en première page ?

Oui, je viens de mettre une dépêche à la une sur alpha d'ailleurs.

> Va-t-on toujours pouvoir « replier » les commentaires en cliquant sur « x » comme actuellement ?

Oui. Il y a un bug qui fait que ça ne marche pas juste là, mais je vais corriger ça rapidement.

> Est-ce qu'il y a des normes à suivre ou, au contraire, exclues, comme C.S.S. 3 ?

On peut utiliser les dernières nouveautés de CSS3. La seule contrainte, c'est que le site reste utilisable avec les navigateurs actuels.

> Est-ce que l'intitulé « Da Linux French Page » demeure ou bien disparaît-il complètement avec la migration ?

Je ne sais pas s'il va disparaître complètement, mais il est en tout cas bien moins mis en avant.

> La section « entretiens » existe-t-elle encore ?

Pas pour le concours. Peut être qu'on le fera revivre après, mais ce n'est pas sûr du tout.

> - Est-ce que le balisage de la version alpha et plus ou moins définitif ?

Oui. Si des personnes ont besoin de nouvelles classes CSS, je les ajouterais, mais je vais essayer de ne pas casser le balisage existant.

> si on fait un habillage pas mal mais sans killer feature particulière, c'est disqualifiant ?

Non.

> On peut lire un peu partout que le W3C insiste sur le fait que HTML5 est à l'état de draft et pas prêt pour la production.

Oui et non, la position du W3C est plus élaborée que ça. Par exemple, à Paris Web, 2 membres du W3C ont fait une présentation autour d'HTML5 et nous ont encouragés à nous y mettre.

La spec est encore en draft pour un certain temps, mais la spec couvre énormément de choses dont certaines sont déjà très matures et utilisables. Dans certains cas, la spec HTML5 est même beaucoup plus proche du fonctionnement des navigateurs existants que les précédentes specs, car les navigateurs ne faisaient pas ce qui est écrit dans HTML 4 ou XHTML (pour de bonnes raisons) et HTML5 est venu documenter cet état de fait.

D'autres parties sont plus récentes mais se dégradent très bien (HTML5 forms par exemple).

Enfin, il y a des parties à éviter car elles ne sont pas implémentées dans les navigateurs actuels et ne se dégradent pas bien (un exemple : les attributs sandbox et seamless des iframes).

> Qu'est-ce qui vous a motivé à franchir le pas ?

Il y a déjà plein de choses que l'on peut utiliser dans HTML5 sans problème et qui sont de réelles avancées. Ce serait vraiment dommage de s'en priver.

Voilà un exemple de ce que cela donne quand on laisse des gens éditer du HTML : http://validator.w3.org/check?uri=http%3A%2F%2Flinuxfr.org%2(...) (si un modéro en a le courage, ce serait bien de corriger).

Je ne souhaite pas qu'il y ait plusieurs syntaxes wiki sur le nouveau site. C'est plus compliqué techniquement et surtout, ça ne va pas être pratique du tout pour les relecteurs qui vont devoir éditer des dépêches dans différentes syntaxes.

Je n'ai pas non plus envie de laisser les gens éditer du HTML. Pour avoir passé pas mal de temps à examiner les contenus pour les importer dans la version RoR, on a une quantité assez impressionnante d'HTML non valide. Il y a des gens qui ne savent pas écrire du HTML et qui font donc ce qu'ils peuvent. Mais la plus grande source d'erreurs vient de typos : un guillemet au mauvais endroit sur un attribut href, une balise fermante , des balises pas fermées, fermées deux fois, mal fermées, fermées mais pas ouvertes, des balises ; la liste est longue.

Maintenant, sur le choix de la syntaxe wiki, je préfère la syntaxe creole. C'était même elle qui était utilisée aux débuts de la version RoR. Mais quand les AMR ont découvert la première version, ils ont été relativement d'accord pour dire que la syntaxe creole n'est pas assez connue et qu'il faudrait utiliser une syntaxe plus populaire.

J'ai tenu un temps puis je me suis rangé à leur avis au début de l'année (janvier ou février). Il y a une discussion, qui a tourné au vote entre markdown et mediawiki. Au final, markdown a gagné d'une voix (quelque chose comme 10 à 9).

Bonne question :-)

Il faut voir que j'ai commencé la réécriture il y a presque 2 ans et il faut donc tenir compte du fait que j'ai fait le choix en fonction de ce qui se faisait à l'époque et non pas de ce qui se fait maintenant.

Mon langage de prédilection est le Ruby, j'ai donc commencé par regarder s'il y avait des CMS en Ruby qui pouvaient convenir. À l'époque, il n'y avait rien de vraiment probant (et encore aujourd'hui, les CMS en Rails, ce n'est pas vraiment ça).

J'ai donc commencé à aller voir ailleurs. Dans beaucoup de cas, ça ne faisait pas grand chose des fonctionnalités demandés pour LinuxFr.org : la tribune, les commentaires sous forme d'arbre de discussions, différencier les nouveaux commentaires des commentaires déjà lus, etc. Du coup, quitte à devoir tout recoder, je préfèrais partir sur du Ruby on Rails plutôt qu'un CMS existant dans notre langage que je ne maitrise pas forcément aussi bien.

Après, il y a deux ou trois CMS qui auraient pu convenir. Je me rappelle surtout du cas de Drupal. J'avais commencé à regarder la chose et avais eu l'occasion de participer à un apéro Drupal (IIRC, c'était une des rencontres qui a permis la création d'une communauté Drupal française, réunie maintenant sur drupalfr.org).

J'ai donc pu avoir des retours de gens qui utilisaient Drupal couramment, voir qui contribuaient au développement. Et ces retours m'avaient fortement refroidis. Je ne me souviens plus précisément des propos, mais c'étaient du genre : tiendra pas la charge ; moi, j'attendrais la prochaine version de Drupal ; faudra sûrement sacrifier quelques fonctionnalités ; etc.

Bref, à l'époque, le choix le plus sûr m'avait paru Ruby on Rails que je maitrisais bien. Si je devais refaire ça aujourd'hui, je procéderais de la même façon mais je ne suis pas sûr que la décision finale serait la même.

> Ce n'est pas un bug mais je me posais cette question: est-il possible que le retour en arrière dans l'historique du navigateur soit annihilé d'une manière ou d'une autre lorsqu'on a posté un commentaire ?

Je ne suis pas sûr de comprendre ce que tu veux dire par "annihiler le retour arrière", mais si tu postes un contenu puis que tu appuies sur le bouton retour arrière, le contenu ne sera pas reposté. Rien de bien magique, j'utilise la bonne vieille technique que l'on appelle parfois Post-Redirect-Get.

> Par contre, je viens d'essayer et je n'arrive plus à changer de css, un bug ? ça marchait pourtant ça...

Humpf, probablement un bug. J'ai fait un ticket sur github [https://github.com/nono/linuxfr.org/issues#issue/39], que je vais essayer de regarder rapidement.

Si tu ne souhaites pas créer de compte sur github (ce que je peux comprendre), je t'encourage à créer une entrée sur le tracker actuel: https://linuxfr.org/tracker/.