🚲 Tanguy Ortolo a écrit 12504 commentaires

on en est ou du remboursement de l'OS sur un PC neuf ?

Légalement, au même point qu'avant : les lois ont un peu changé, mais la vente liée ou forcée telle qu'elle est pratiquée partout est interdite, le constructeur doit rembourser pour réparer son délit, mais fait tout pour l'éviter et pour pas mal d'entre eux il faut aller au tribunal.

Politiquement, au même point qu'avant : toutes les familles politiques au pouvoir ont promis de faire bouger les choses et aucune n'a rien fait.

En pratique, à peu près au même point qu'avant, sauf que la machine est plus rodée des deux côtés : les constructeurs sont habitués à ce genre de plainte et il ne faut donc plus passer par la juridiction de proximité ou par un avocat non spécialisé, mais au contraire passer directement au civil — je crois — avec un avocat spécialiste du sujet.

Le problème est que le seul moyen d'agir actuellement est de multiplier les plaintes, ce qui n'est que peu intéressant pour les particuliers, vu que ça demande du temps et que ça coûte généralement plus que ça ne rapporte. C'est en fait un problème général pour des consommateurs face à des entreprises, qui pourrait être réglé par des actions de groupe, mais comme pour la vente liée, toutes les familles politiques au pouvoir ont promis de mettre en place un cadre d'actions de groupe et aucune n'a jamais rien fait pour cela.

Non, on ne s'en fout pas. Les gens débranchent peut-être leur cerveau lorsqu'ils sont devant un écran, mais si on ne leur fournit pas les moyens de faire de leur ordinateur une utilisation intelligente, rien ne changera à leur comportement sauf en pire.

Les gens n'utilisent pas, sauf les spécialistes ou les gens qui savent, qui ne sont pas nombreux, c'est la pire des justifications pour retirer des fonctionnalités. Si on appliquait ça partout, il n'y aurait plus aucune quincaillerie sur Terre et on n'apprendrait plus à lire.

Certainement, mais la mauvaise utilisation est majoritaire, et comme ce n'est pas l'utilisateur qui choisit, ce qu'il reste comme option, c'est la désactivation pure et simple.

Il y a encore des gens pour croire sérieusement qu'avec JavaScript, ça va plus vite ? Essaie de désactiver JavaScript pendant quelques jours, tu devrais vivre une véritable révélation… Pas mal de sites avec lesquels on s'est habitué à une certaine lenteur deviennent fulgurants dès qu'on a désactivé l'interpréteur.

Non, enfin si, un logiciel en HTML c'est mieux si ça fonctionne, même de façon dégradée, sans JavaScript, évidemment.

Mais mon propos d'origine, c'était plutôt : j’abhorre les page Web à contenu intrinsèquement statique qui sont inutilisables sans JavaScript.

KDE : il y a une boîte de configuration avec tous les moteurs de recherche (et la liste est déjà bien longue par défaut).

Et pour en ajouter ? Notamment pour en ajouter de peu connus, par exemple le moteur de recherche du wiki de mon travail ?

Epiphany : tu ajoutes un signet avec un URL et la liste apparaît dans la barre d'adresse quand tu entres quelque chose, et il y a une clef dconf avec une URL par défaut.

Pas utilisable par un non-geek donc.

Au passage, ce n'est que la moitié d'OpenSearch ça.

L'autre moitié, c'est un format formel structuré, non HTML, de présentation des résultats d'une recherche. Ce serait très utile pour deux cas :

1. les barres latérales de recherche, façon SeaMonkey ;
2. les petits écrans.

Sauf que la maladie habituelle du Web a sévit : les gens ne savent plus utiliser que le HTML, et ont complètement oublié que des formats structurés pouvaient être utiles.

Comment font les autres ?

Facebook : Quasiment toutes les fonctionnalités requièrent JavaScript : l'ajout de contenu avec un éditeur de qualité, le chat, la mise à jour du contenu en temps réel, les actions qui ne rechargent pas la page (Ajax quoi…).

Et lire seulement un article rédigé par quelqu'un ? Aucune raison de nécessiter JS, or pour avoir essayé, sans JS ils n'affichent pas tout, ou l'affichent mal il me semble.

Google : La complétion est obligatoirement en JavaScript. La complétion HTML5 est un peu légère. Pour le reste, JavaScript n'apporte pas grand chose.

JavaScript pas du tout indispensable donc, en théorie. Or depuis certains endroits — genre depuis mon travail, mais pas depuis chez moi, allez comprendre — Google n'affichent rien, mais alors rien du tout, pas même de page d'accueil, si JS n'est pas activé.

Wikipedia : L'éditeur d'articles est une horreur sans JavaScript. Et l'édition d'articles, c'est un peu le principe de base de wikipedia.

Alors déjà, il y a des gens qui n'ont pas du tout besoin des fonctionnalités JS de l'éditeur, genre moi. Et ensuite, celui qui lit un article sans vouloir l'éditer n'a vraiment pas besoin de JS. Mais ça tombe bien, Wikipédia c'est plutôt bien codé : sans JS, c'est utilisable.

Eh bien OpenSearch, ça sert à ça, ou plus précisément, à deux cas :

1. Je suis sur un site, et il se trouve qu'il fournit un moteur de recherche, interne ou externe, peu importe : Firefox me propose de l'ajouter facilement à sa liste.
2. Je suis sur un annuaire de moteurs de recherche, et pour chaque moteur listé, il y a un lien : en cliquant dessus, ça l'ajoute à la liste de Firefox.

Pas forcément sans une goutte de JS, mais simplement qui fonctionne sans JS. Un très bel exemple est RoundCube, un webmail qui est tout à fait utilisable sans JavaScript, et qui avec JavaScript ajoute des fonctionnalités pas indispensables. Et pour les mauvais exemples, des tas de sites Web qui poussent le vice jusqu'à charger leurs styles par JavaScript, et donc ne ressemblent à rien quand on a désactivé l'interpréteur.

Heu… C'est un principe d'ergonomie de base d'adapter l'interface à l'utilisateur et pas l'inverse.

Parfois on doit faire l'inverse. Quand l'utilisateur prend spontanément de mauvaises habitudes, l'interface doit décourager celles-ci, pas les encourager en les rendant plus faciles encore.

Peut-être que certaines choses ne sont pas possibles à faire autrement qu'avec une page web dynamique. Je pense à Google Maps par exemple.

C'est pour ça que j'ai écrit « sauf cas particuliers », en pensant justement à ce qui ne peut pas être fait sans JavaScript.

Quand, dans un site, tu mets un <link rel="search" href="http://search.example.com/?q=%s"/>, ces navigateurs proposent d'ajouter le moteur de recherche à sa liste ?

Ah, ça valait le coup de préciser. À ma connaissance : non.

C'est surtout un raisonnement normalisateur : presque tout le monde fait comme ça donc on n'a pas à permettre de faire autrement. Heureusement qu'on n'applique pas ce raisonnement partout, sinon dans deux ans on n'aura plus de barre d'URL — ce qui fera la joie des faussaires.

Non non non. En 2013 le nombre de sites codés avec deux pieds gauches, qui sont inutilisables sans JavaScript, a augmenté en effet, mais attention à ne pas déplacer le problème : sauf cas particuliers, le problème ne vient pas du blocage de JS mais de l'incompétence du concepteur du site.

Sauf que ce n'est reconnu nulle part. OpenSearch, on aime ou pas mais c'est le seul standard, et il fonctionne bien comme ça. Il permet de stocker : nom du moteur de recherche, description, icône… Après, pourquoi pas publier un outil pour fabriquer des descriptions OpenSearch à partir de chaînes comme ça ?

Non, mais la barre de recherche ne sert pas qu'à demander à Google, hein. Perso, j'utilise aussi : DuckDuckGo, Wikipédia en français, Wikipedia en anglais, Wiktionnaire en français, le wiki de la boîte où je travaille et OpenStreetMap.

perso, j'aime bien voir l'url avant de cliquer

Elle s'affiche dans une zone éphémère en bas de la page.

C'est bien, mais pas top ça :

• aucune découverte OpenSearch, il faut se les palucher ;
• pas possible de relancer facilement une recherche sur un autre moteur.

Ah, génial, je viens d'essayer et ça fonctionne à merveille ! Bon, eh bien je sais quel est le prochain paquet Debian que je ferai. Enfin, quand j'aurai rattrapé mon retard dans pas mal de choses tout de même…

C'est à régler dans le profil de l'administrateur.

Pour les articles, il faut tout de même un peu de structure externe, avant d'en faire des pages Web, puisqu'il faut pouvoir y identifier : le titre, la description et les mots-clefs — pour les mettre dans l'en-tête HTML —, le chapô — pour l'afficher sur les pages composites — et le corps.

Donc du HTML, pourquoi pas, et c'est d'ailleurs ce qui est utilisé là où c'est pertinent, à savoir pour le chapô et le corps, mais dans une structure en JSON ou autre — système de fichier par exemple : un répertoire pour l'article et un fichier par composant ! —, c'est indispensable.

Je pense pour ma part que l'utilisation de XML n'est pas très appropriée pour les données d'un blog. En effet, qu'a-t-on ? Des articles, des mots-clefs, des catégories et des commentaires. Le plus efficace à mon avis :

• un fichier par article, avec par exemple une structure à la RFC-822 dans le plus pur style de Debian pour stocker titre, chapo et corps ;
• pour les catégories et mots-clefs : un répertoire à chaque fois, avec les articles liés dedans, et dans chaque article un champ indiquant ses catégories et mots-clefs ;
• pour les commentaires : un fichier par article, éventuellement le même que celui de l'article lui-même, avec les commentaires ajoutés à la fin.

Mais les auteurs de PluXml ont fait un choix un peu différent. Ça ne me dérange pas outre mesure, surtout compte tenu du fait qu'ils sont presque les seuls à avoir résisté à la basededonnite aiguë qui sévit dans le mont du ouaibe.