Firefox devrait effectivement offrir la possibilité d'ouvrir les fichiers markdown, mais c'est une demande à faire dans le bugzilla de Mozilla, pas ici (en fait, elle existe déjà et ça doit se retrouver en cherchant bien). En attendant, il est possible d'utiliser l'extension Ouvrir dans le navigateur.
C'est maintenant les mêmes tailles de police pour les contenus et commentaires, que ce soit sur desktop (police plus grande) ou sur mobile (police plus petite).
Tu devrais faire un patch plutôt que de donner un fichier css, car sinon la maintenance est impossible.
Je confirme, ça serait effectivement bien plus simple pour moi si ça peut être un fichier .scss qui importe la feuille de style de base de RonRonnement.
Donc je vais faire une entrée pour revenir à quelque chose de plus logique (respecter la taille de l'utilisateur), tu vas, grace à ton argument pour accepter l'entrée précédente, rechanger.
Ou pas. Ton entrée de suivi va très probablement finir avec un score négatif et je pourrais la fermer en invalide et l'oublier.
donc c'est bien ce que je disais : pas d'étude, juste un choix arbitraire.
Évidemment que c'est arbitraire. Je m'appuie sur les quelques retours que j'ai et j'essaye de faire pour le mieux. Si je devais faire une étude avant d'écrire une ligne de code pour LinuxFr.org, ça ferait longtemps que le site serait mort…
Non, d'une part, tous les sites ne sont pas en largeur fixe et, d'autre part, même quand ils sont en largeur fixe, ce n'est pas toujours la même largeur.
Les études d'ergonomie montrent que pour les contenus textuels un peu long, les gens préfèrent généralement que les textes fassent entre 50 et 80 caractères par ligne. Mais ça ne concerne qu'une partie des sites web. Pour des sites de photo (flickr), des sites avec plein de colonnes (trello), les sites d'ecommerce avec plein de produits liés (up-selling, cross-selling & co), on cherche au contraire à tirer profit du maximum de largeur. C'est donc aussi logique que les gens naviguent en plein écran mais souhaitent que les sites à fort contenus textuels aient une limite sur la largeur maximale.
En fait, ça ressemble surtout à "les gens sont des idiots, il ont des fenêtre plus grandes que ce qu'ils veulent".
Non, c'est juste que les gens utilisent leur navigateur pour aller sur d'autres sites que LinuxFr.org et qu'ils n'ont pas envie de redimensionner leur navigateur à chaque site qu'ils visitent.
voila donc le retour da la largeur de fenêtre arbitrairement (qui es-tu pour dire que 66 caractère c'est bien pour moi?) choisie par le webmaster
Oulà, moi, je n'en ai aucune idée de ce qui est bien pour toi. Je propose juste une feuille de style par défaut et j'essaye qu'elle convienne au plus grand nombre de lecteurs du site. Mais tu as tout liberté d'adapter le site comme tu l'entends, que ce soit en utilisant une feuille de style par défaut, en surchargeant les styles via les extensions de ton navigateur, en passant par les flux ATOM ou weboob.
Effectivement, ça va motiver à copier la CSS pour enlever cette limite arbitraire.
Tu peux juste utiliser une feuille de style personnalisée qui fait @import de la feuille de style standard et surcharge cette limite. L'avantage par rapport à recopier toute la CSS est de profiter des futurs changements sur la feuille de style par défaut sans avoir à faire quoi que ce soit (bon, OK, ça peut aussi être vu comme un inconvénient).
Ce n'est pas un mal en soit, mais pas la peine de se cacher derrière une "demande des visiteurs".
Moi, perso, ça m'allait bien avant. J'avais régulièrement des gens qui me disaient qu'il faudrait limiter la largeur maximale et je leur répondais de faire une entrée dans le suivi. Le jour où cette entrée est arrivée, je n'avais plus trop d'excuse pour ne pas le faire.
J'avais fait une entrée dans le truc adéquat qui avait été suivi d'aucune rectification et qui a même été simplement effacé.
Humm, ça doit dater de la version templeet du site. Depuis que le site est passé à Ruby on Rails début 2011, on ne supprime plus les entrées du suivi (à part les très rares cas de spam). Au pire, on les marque en invalide si on pense qu'il y a des raisons de ne pas le faire. Et même là, l'auteur de l'entrée du suivi peut la réouvrir et poster un commentaire pour nous faire changer d'avis. Un exemple récent : http://linuxfr.org/suivi/amelioration-du-systeme-des-norloges-sur-la-tribune#comment-1526114.
Si tu es un administrateur ou nono<, n'hésite surtout pas à cloner le dépôt pour lui donner une meilleure visibilité, voire, soyons fous, à centraliser le dépôt avec le reste !
[^] # Re: De plus, on ne peut pas échaper la backquote en fin de balisage teletype
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi «backslash backquote» dans un bloc de code reproduit tout l’article. Évalué à 3 (+0/-0).
Non, par contre, on peut taper
pour obtenir
echo `whoami`
.[^] # Re: Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Taille de police incohérente. Évalué à 3 (+0/-0).
Oui, c'est pour mieux mettre en avant les contenus et leurs commentaires associés.
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Revenir en haut de la page ne fonctionne plus. Évalué à 3 (+0/-0).
Regression introduite dans https://github.com/nono/linuxfr.org/commit/25df3f5a#diff-124550826d9681746ee4f226e3d685d5R260 et corrigée par https://github.com/nono/linuxfr.org/commit/a6f02b9074ae8166cb71ba5e49a28a1ea4de5bd8
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Taille de police trop petite sur la Tribune. Évalué à 3 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/a6f02b9074ae8166cb71ba5e49a28a1ea4de5bd8
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Ajouter une case « urgent » pour la publication. Évalué à 3 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/f45a79fdc1224412c7794beb0a6b65b8919fd172
# Persona n'a pas décollé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Browserid. Évalué à 3 (+0/-0).
Persona, anciennement Browserid, n'a pas réussi à prendre. Mozilla a annoncé qu'ils ne financeraient plus de nouvelles fonctionnalités dessus, les développeurs ont été réaffecté sur d'autres projets. Source : http://identity.mozilla.com/post/78873831485/transitioning-persona-to-community-ownership
On peut voir sur https://github.com/mozilla/persona/graphs/commit-activity que le développement n'avance quasiment plus depuis.
Ça et le fait que cette entrée n'ait qu'un score de 2 me font fermer cette entrée.
[^] # Re: encore quelques bugs aussi
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Quelques nouveautés sur votre site web préféré. Évalué à 3.
Oui, beau raté de ma part. C'est maintenant corrigé !
# Extension pour Firefox
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Firefox essaie de télécharger les .md. Évalué à 4 (+0/-0).
Firefox devrait effectivement offrir la possibilité d'ouvrir les fichiers markdown, mais c'est une demande à faire dans le bugzilla de Mozilla, pas ici (en fait, elle existe déjà et ça doit se retrouver en cherchant bien). En attendant, il est possible d'utiliser l'extension Ouvrir dans le navigateur.
# Marges réduites
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Marges inutiles. Évalué à 3 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/84d76ffecbdfc11804ef54b17e96ebd8bf52523d
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Taille de police incohérente. Évalué à 3 (+0/-0).
C'est maintenant les mêmes tailles de police pour les contenus et commentaires, que ce soit sur desktop (police plus grande) ou sur mobile (police plus petite).
cf https://github.com/nono/linuxfr.org/commit/731631fab494e350bc66f6e508f7e9deb2388156
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Rédaction de dépêche sur mobile. Évalué à 3 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/84d76ffecbdfc11804ef54b17e96ebd8bf52523d
[^] # Re: Patch?
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Nouvelle CSS basée sur RonRonement. Évalué à 3 (+0/-0).
Je confirme, ça serait effectivement bien plus simple pour moi si ça peut être un fichier
.scss
qui importe la feuille de style de base de RonRonnement.[^] # Re: largeur limite
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Quelques nouveautés sur votre site web préféré. Évalué à 6.
Ou pas. Ton entrée de suivi va très probablement finir avec un score négatif et je pourrais la fermer en invalide et l'oublier.
Évidemment que c'est arbitraire. Je m'appuie sur les quelques retours que j'ai et j'essaye de faire pour le mieux. Si je devais faire une étude avant d'écrire une ligne de code pour LinuxFr.org, ça ferait longtemps que le site serait mort…
[^] # Re: largeur limite
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Quelques nouveautés sur votre site web préféré. Évalué à 4.
Non, d'une part, tous les sites ne sont pas en largeur fixe et, d'autre part, même quand ils sont en largeur fixe, ce n'est pas toujours la même largeur.
Les études d'ergonomie montrent que pour les contenus textuels un peu long, les gens préfèrent généralement que les textes fassent entre 50 et 80 caractères par ligne. Mais ça ne concerne qu'une partie des sites web. Pour des sites de photo (flickr), des sites avec plein de colonnes (trello), les sites d'ecommerce avec plein de produits liés (up-selling, cross-selling & co), on cherche au contraire à tirer profit du maximum de largeur. C'est donc aussi logique que les gens naviguent en plein écran mais souhaitent que les sites à fort contenus textuels aient une limite sur la largeur maximale.
# Pourquoi pas
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Statistiques détaillées sur les user-agents. Évalué à 4 (+0/-0).
Ça pourrait être l'occasion de re-tester des alternatives à webalizer comme awstats ou piwik.
[^] # Re: largeur limite
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Quelques nouveautés sur votre site web préféré. Évalué à 3.
Non, c'est juste que les gens utilisent leur navigateur pour aller sur d'autres sites que LinuxFr.org et qu'ils n'ont pas envie de redimensionner leur navigateur à chaque site qu'ils visitent.
[^] # Re: largeur limite
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Quelques nouveautés sur votre site web préféré. Évalué à 4.
Oulà, moi, je n'en ai aucune idée de ce qui est bien pour toi. Je propose juste une feuille de style par défaut et j'essaye qu'elle convienne au plus grand nombre de lecteurs du site. Mais tu as tout liberté d'adapter le site comme tu l'entends, que ce soit en utilisant une feuille de style par défaut, en surchargeant les styles via les extensions de ton navigateur, en passant par les flux ATOM ou weboob.
Tu peux juste utiliser une feuille de style personnalisée qui fait
@import
de la feuille de style standard et surcharge cette limite. L'avantage par rapport à recopier toute la CSS est de profiter des futurs changements sur la feuille de style par défaut sans avoir à faire quoi que ce soit (bon, OK, ça peut aussi être vu comme un inconvénient).[^] # Re: largeur limite
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Quelques nouveautés sur votre site web préféré. Évalué à 4.
Moi, perso, ça m'allait bien avant. J'avais régulièrement des gens qui me disaient qu'il faudrait limiter la largeur maximale et je leur répondais de faire une entrée dans le suivi. Le jour où cette entrée est arrivée, je n'avais plus trop d'excuse pour ne pas le faire.
[^] # Re: largeur limite
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Quelques nouveautés sur votre site web préféré. Évalué à 3.
Oui, je vais convertir cette taille en
ex
, c'est effectivement plus logique.[^] # Re: ouais...
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Quelques nouveautés sur votre site web préféré. Évalué à 3.
Humm, ça doit dater de la version templeet du site. Depuis que le site est passé à Ruby on Rails début 2011, on ne supprime plus les entrées du suivi (à part les très rares cas de spam). Au pire, on les marque en invalide si on pense qu'il y a des raisons de ne pas le faire. Et même là, l'auteur de l'entrée du suivi peut la réouvrir et poster un commentaire pour nous faire changer d'avis. Un exemple récent : http://linuxfr.org/suivi/amelioration-du-systeme-des-norloges-sur-la-tribune#comment-1526114.
# Effectivement
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Bug d'interaction entre les maths et les blocs de préformatés. Évalué à 3 (+0/-0).
J'ai modifié le journal en question pour utiliser des fenced code blocks. C'est un contournement, le temps de trouver une solution à ce bug.
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Réduction de discussion.png. Évalué à 3 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/b3c9a86e9a6f3adcee2a964dd060a834e574d2b9
# Bug
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Dépêche marqué comme visité si on télécharge le contenu au format Markdown. Évalué à 3 (+0/-0).
C'était un bug et c'est maintenant corrigé.
Cf https://github.com/nono/linuxfr.org/commit/938ea6896b529c9829e9ed2b1e5f982824d3e1e3
# Fait
Posté par Bruno Michel (site web personnel) . En réponse au journal Toi aussi installe ton propre linuxfr en trois lignes de bash... et contribue!. Évalué à 10.
Bonne idée, le fork est là : https://github.com/linuxfrorg/ansible-linuxfr.
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi En rédaction/modération, les dépêches affichent le code HTML. Évalué à 3 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/98ae2cfdce56d5157db8860147cc7c76e10b0778