Si tu n'utilises ni Firefox, ni KDE c'est très bien, mais ce n'est pas une bonne raison pour ne pas utiliser Qt, parce que pour le coup l'utilisation de GTK par Qt fonctionne très bien.
On gere ca certainement bien mieux que Linux oui, c'et garanti a 100% vu que les package managers sous Linux n'utilisent pas de systeme a base de transaction
Je suis plutôt d'accord avec tes réponses dans l'ensemble, mais là tu mens effrontément. Utilisateur exceptionnel de Fedora (je ne connais vraiment pas es rouages) je peux pourtant te garantir que « yum » (au moins dans Fedora 13) utilise les transactions (il l'affiche même). Et ça marche, ça ma sauvé une install ou le portable a surchauffé (pas de mauvaise foi, il fait la même chose sous Windows) et s'est éteint.
HS: En fait, dans ce cas précis, contrairement à Vista, Fedora s'est même payer le luxe d'un arrêt d'urgence en quelques secondes au moment de la surchauffe, là où Vista meurt d'un coup. Je ne savais même pas que c'était possible.
Oui, mais dans ta démo, L (= π) est irrationnel, donc π ne s'écrit pas sous la forme d'une fraction de nombres entiers.
Ça n'enlève rien à la qualité de la démonstration qui montre bien que que les chevaux ne volent pas, même montés sur des oiseaux… chercher à les faire voler se réduit à un problème de quadrature du cercle.
Tu t'es trompé, la vidéo a changé ou c'est CLive qui fait du prosélytisme pro-logiciel (et codec vidéo) libre ? Dans la vidéo que j'ai vue, FF est le grand gagnant !
au serveur S qui peut être weloveourdictator.org ou deathtothedictator.org
Si les deux sont obligés d’utiliser le même certificat et donc doivent appartenir à la même personne, ça limite vraiment les possibilités de cacher un site derrière un autre (je vois mal les torturés monter un site avec leurs bourreaux pour garantir que ni les uns ni les autres ne savent qui regarde quoi, surtout que le détenteur du certificat peut tout déchiffrer, c'est ballot).
À part l’exemple de Wikipedia qui n’est qu’une vitrine vers une console de contrôle du monde, tu as des exemples où la confusion entre plusieurs noms possible peut apporter quelque-chose concrètement ?
Bon, dès ce soir, je commence à me générer des certificats clients pour Wikipedia, ce sera peut-être long par force brute, mais si ce que tu dis est vrai, le jeu en vaut la chandelle… ☺
Oui, j'avais oublié ça parce-que ça implique du coup que tous les noms partagent le même certificat. Je répondais en réaction à tu peux seulement connaître l'ip du serveur avec lequel la personne communique (et le port), or avec HTTPS, on connaît le certificat en plus (mais effectivement pas directement le nom).
Donc ne pas voir transiter le nom n'apporte pas de confidentialité supplémentaire, on sait quand-même chez qui tu consultes les infos (le même détenteur du certificat), alors qu'avec la seule IP, sur des serveurs mutualisés ça serait très différent. Seulement dans ce cas, HTTPS offrirait plus de confidentialité que le nom qui circule en clair, ce n'est pas le cas, donc sans minimiser l'intérêt d'HTTPS, il n'apporte rien de ce côté là (même si ma réponse trop rapide était fausse).
En pratique, ça ne change pas grand-chose, parce-que du coup le serveur doit répondre en HTTPS avant de savoir avec quel nom il est consulté, donc en HTTPS : 1 IP = 1 nom.
En fait, j'ai court-circuité une explication dans le journal. De la même manière que GTK quand aucune méthode d'entrée n'est spécifiée, IBus n'utilise pas XIM mais sa propre méthode d'entrée quand le mode de saisie par mots n'est pas activé. Du coup, IBus souffre des mêmes limitations et ne prend pas en compte la configuration des entrées X.org. Pas de « $HOME/.XCompose » avec IBus, et ses tables de compositions ne sont pas synchronisées avec X.org, d'où l'intérêt du greffon IBus XKBC (lien dans le journal) qui devrait résoudre ce problème.
Du coup, par défaut, j'ai le choix entre le confort de mes combinaisons de touches via la composition de X, ou la possibilité de saisir des caractères mathématiques par mots LaTeX. Comme je n'utilise que des langues à alphabets courts et pas de chinois ou de japonais, je préfère bénéficier par défaut de mes réglages de composition que de la saisie par mots. Évidemment, avant que je découvre ces problèmes j'utilisais IBus en permanence (et c'est ce que doivent faire tous les utilisateurs de GTK qui n'ont jamais vu les limites du mode de saisie par défaut).
Non, « Contrôle + Espace » ça sert juste à basculer le mode de saisie dans le cas où tu utilises déjà une méthode d'entrée comme IBus. Heureusement qu'en l’utilisant tu peux toujours taper des caractères normaux et que tu as bien deux modes de saisie. Maintenant, tu verras que tu peux aussi choisir avec le menu des champs de saisie une autre méthode d'entrée, auquel cas « Contrôle + Espace » n'aura plus d'effet mais les autres points abordés fonctionneront.
Pour activer XIM manuellement par exemple, il faut choisir dans le menu la méthode d'entrée « Méthode de saisie X » pour GTK en français ou XIM dans Qt en anglais (désolé, je n'ai pas sous la main d'appli Qt francisée où il est possible de changer la méthode d'entrée).
Le jour ou une distro viendra avec 40000 logiciels (pas paquets, logiciels) à jour, on pourra commencer (seulement commencer) à dire que le système de dépôt rempli son rôle
Ah parce que, selon toi, le rôle d'un système de dépots, le but ultime, c'est forcément d'avoir plein de logiciels ?
Pour abonder dans ce sens, combien de fois ai-je utilisé aptitude pour trouver le nom d'un logiciel à conseiller à mes collègues sous Windows ! À chaque fois, malgré les quelques faux-positifs qui ne sont pas portés sous Windows, le logiciel que je trouve est mieux adapté à leur besoin que le gratuiciel qu'ils ont mis un temps fou à repérer sur les sites de téléchargement (ou le truc craqué que leur a filé un autre collègue).
Au final c'est bien, ça a même convaincu certains de quitter Windows complètement. Les autres se contentent des quelques logiciels libres que je leur ai conseillé ainsi puisque (et c'est tant mieux) cette méthode de recherche ne renvoie que des logiciels libres.
Et surtout, contrairement à ce que dit Zenitram, il n'y a aucune incohérence entre suivre les versions sur un site dédié et utiliser un gestionnaire de paquets. En effet, les versions ne sont pas forcément les mêmes (et j'ai déjà expliqué pourquoi ça ne me gêne pas plus que ça), et le public n'est pas tout à fait le même. Là où le gestionnaire de paquets est censé être utilisé par tous les utilisateurs, seuls ceux qui veulent chercher un peu plus loin, les développeurs et les curieux utilisent Freshmeat.
Par exemple, personnellement, je regarde beaucoup Distrowatch alors que l'essentiel des annonces concerne des versions bêta, c'est que j'ai envie de tester les nouveautés, éventuellement de remonter des bugs, mais ce n'est pas pour autant que veux tout tout de suite dans ma Debian. C'est valable avec d'autres logiciels, même en tant que non développeur, il m'arrive de compiler certaines applis depuis les dépôts Git (ou SVN, c'est pas moi qui choisis), et ça ne m'empêche pas d'utiliser au quotidien la version distribuée par Debian qui est souvent plus stable et plus intégrée au reste de la distro.
Tu as l'air de connaitre un minimum de choses sur la question (ce que laissent supposer tes interventions). Pourquoi ne pas initier une réflexion/comparatif sur ces différents systèmes de package: recenser, détailler, comparer... pour qu'il soit possible ensuite de spécifier/réaliser l'évolution vers un meta-package.
De toute façon, je ne crois pas que ce serait la bonne solution. La fabrication de paquet n'est pas toujours aisée, et elle gagnerait à être simplifiée pour beaucoup de distros, cependant je trouve ça très bien si les développeurs ne font leurs paquets eux-même. L'intérêt des paquetages, ce n'est pas leur format, mais le travail d'intégration à la distribution que font les mainteneurs (sauf pour Ubuntu ☺).
La course au numéro de version, c'est un peu le truc qui ne sert à rien. Je ne me plains pas chque fois que je vois une fonctionnalité ajoutée dans le SVN d'un projet et qu'elle n'est pas encore dans ma distro. Déjà, je dois attendre que la sortie d'une version par les développeurs, et ensuite les mainteneurs fabriquent le paquet et apportent toute leur connaissance des rouages de la distro. je considère que ça fait partie du cycle de développement. Après, pour les testeurs ou lors d'une fonctionnalité vraiment intéressante, j'apprécie que les développeurs me dépannent en sortant des verisons précompilées (et plutôt pas sous la forme de paquetages) des « nightly builds », mais c'est normal si ce n'est pas dans la distro.
Quand est-ce que'ont remet en question le principe des dépôts avec un format propre à chaque distro dans son coin et que donc le "collectif" n'arrive pas à suivre? Je sais, tabou tout ça... Ne surtout pas parler de ce qui ne marche pas...
Ce n'est pas tabou, c'est juste que ça marche très bien pour l'utilisateur et que ça évite la multiplication des tiers de confiance lors de la distribution d'un programme. Maintenant, les développeurs qui font eux-même leur paquet, c'est un truc que je n'ai jamais vraiment compris, en tant qu'utilisateur ça m'a toujours compliqué les choses :
- je dois installer le paquet en tant que super-utilisateur, alors que je pourrais tester le programme en tant qu'utilisateur simple ;
- il manque toujours plein de distributions ;
- les devs se plaignent de devoir faire ce boulot que je ne leur demande pas ;
- si ça marche sous Windows, c'est parce-qu'en cas de soucis les dévs n'hésitent pas à fourguer avec le programme tout un paquet de choses qui seraient des dépendances sous Linux. Eh ben moi ça m'irait bien un programme pré-compilé dans un répertoire avec des bibliothèques liées statiquement ou un wrapper qui définit un LD_LIBRARY_PATH comme le proposent beaucoup d'éditeurs de logiciels proprios sous Linux. C'est simple pour l'utilisateur comme sous Windows, et au moins, ça laisse la fabrication des paquets à ceux qui font ça bien.
Je ne sais pas s'il existe encore des gens pour ne pas saisir la référence, voilà de quoi comprendre : http://www.arobase.org/spam/monty-python.htm (avec texte original et traduction pour les anglophobes).
les images sur des pages web ça a d'autres usages que une photo OU des éléments de décoration [...] comme dans des pages dites interactives
Une image rend interactif ? Même dans une page interactive, une image reste une image. Peut-t-elle être autre chose qu'un contenu (auquel cas le alt est nécessaire et justifié) ou de la présentation (qui devrait partir en CSS) ?
indispensable à la page. mais inutile pour un non-voyant.
Oui, donc rien à voir avec l'accessibilité du coup s'il existe des trucs indispensables mais que ça ne concerne pas les non-voyants et qu'ils ont pas à le savoir (après tout c'est pas ta faute s'ils y voient rien, hein).
c'est ballot, c'est explicitement prévu et conseillé par la norme
Oui, c'est même ce à quoi je répondais. Avec le contexte d'un tel conseil, ça veut dire en gros, « ne le faîtes pas, après si vous voulez être valide avec le schéma normalisé sans comprendre pourquoi, la solution est de mettre un truc vide ». Normalement si t'as bien fait ton boulot en amont (séparation de la CSS) ça n'arrive pas.
forcer la main à de nombreux pisseurs de code qui ne s'en servaient pas du tout.
Ceux qui ne s'en servaient pas en mettent maintenant un vide… Personnellement je m'en fous, ce n'est pas plus accessible dans un cas que dans l'autre (donc pas pire). Par contre je trouve intelligent que la norme considère qu'une image dispose nécessairement d'un texte alternatif. Après si en tant qu'auteur TU considères que les aveugles, les navigateurs consoles, les moteurs de recherche et autres ne méritent pas d'accéder à l'information, eh ben tu décris rien dans le alt.
Si moi je considère que les gens qui utilisent des navigateurs respectueux des standards n'ont pas à lire tout ce que j'écris, alors je mets du texte dans des commentaires XML en exploitant des bugs de parsing d'IE. J'ai des documents valides, lisibles que sous IE… Ben c'est pas ce que prévoit la norme, ça te choque ?
Le point où je suis en désaccord avec moi-même dans ma réponse précédente, c'est la comparaison avec le poids des images. C'est vrai que ça peut ne pas être négligeable comme le soulignait Zenitram. Maintenant, dans la mesure où ça s'adresse aux images CONTENUES dans la page, c'est normal qu'elles soient accessibles à tous, et donc cette surcharge me paraît tout à fait justifiée.
[^] # Re: Résolution perso
Posté par jyes . En réponse au journal gtk-qt-engine, firefox, firefox et firefox :(. Évalué à 6.
[^] # Re: j'ai du loupé un episode mais
Posté par jyes . En réponse au journal Pour utiliser Windows, utilisez Linux (bis). Évalué à 4.
Je suis plutôt d'accord avec tes réponses dans l'ensemble, mais là tu mens effrontément. Utilisateur exceptionnel de Fedora (je ne connais vraiment pas es rouages) je peux pourtant te garantir que « yum » (au moins dans Fedora 13) utilise les transactions (il l'affiche même). Et ça marche, ça ma sauvé une install ou le portable a surchauffé (pas de mauvaise foi, il fait la même chose sous Windows) et s'est éteint.
HS: En fait, dans ce cas précis, contrairement à Vista, Fedora s'est même payer le luxe d'un arrêt d'urgence en quelques secondes au moment de la surchauffe, là où Vista meurt d'un coup. Je ne savais même pas que c'était possible.
[^] # Re: Je comprends pas
Posté par jyes . En réponse au journal Pour utiliser Windows, utilisez Linux (bis). Évalué à 2.
[^] # Re: Youpi !
Posté par jyes . En réponse au journal Le successeur de TeX. Évalué à 6.
[^] # Re: Youpi !
Posté par jyes . En réponse au journal Le successeur de TeX. Évalué à -1.
Ça n'enlève rien à la qualité de la démonstration qui montre bien que que les chevaux ne volent pas, même montés sur des oiseaux… chercher à les faire voler se réduit à un problème de quadrature du cercle.
[^] # Re: Web != Internet
Posté par jyes . En réponse à la dépêche Comment accéder à Internet (un guide de 2025). Évalué à 10.
[^] # Re: C'est quoi ce truc ???
Posté par jyes . En réponse au journal Le successeur de TeX. Évalué à 4.
https://linuxfr.org/comments/1140407.html#1140407
[^] # Re: D'après des tweets, cette annonce est un Joke.
Posté par jyes . En réponse au journal Le successeur de TeX. Évalué à 8.
J'attends ici un nouveau fil de commentaires comme :
https://linuxfr.org/comments/1140256.html#1140256
[^] # Re: SpiderMonkey pas responsable
Posté par jyes . En réponse au journal Retour vers le passé autour de Flash 9. Évalué à 3.
Autre exemple de lenteur FF :
http://www.youtube.com/watch?v=OIZUdZdFzOo
Tu t'es trompé, la vidéo a changé ou c'est CLive qui fait du prosélytisme pro-logiciel (et codec vidéo) libre ? Dans la vidéo que j'ai vue, FF est le grand gagnant !
[^] # Re: Drogue ?
Posté par jyes . En réponse au journal Le figaro : gentoo [a une] redoutable pointe de vitesse. Évalué à 10.
[^] # Re: Intérêt d'HTTPS ?
Posté par jyes . En réponse au journal HTTPS Everywhere. Évalué à 2.
Si les deux sont obligés d’utiliser le même certificat et donc doivent appartenir à la même personne, ça limite vraiment les possibilités de cacher un site derrière un autre (je vois mal les torturés monter un site avec leurs bourreaux pour garantir que ni les uns ni les autres ne savent qui regarde quoi, surtout que le détenteur du certificat peut tout déchiffrer, c'est ballot).
À part l’exemple de Wikipedia qui n’est qu’une vitrine vers une console de contrôle du monde, tu as des exemples où la confusion entre plusieurs noms possible peut apporter quelque-chose concrètement ?
Bon, dès ce soir, je commence à me générer des certificats clients pour Wikipedia, ce sera peut-être long par force brute, mais si ce que tu dis est vrai, le jeu en vaut la chandelle… ☺
[^] # Re: Intérêt d'HTTPS ?
Posté par jyes . En réponse au journal HTTPS Everywhere. Évalué à 2.
Donc ne pas voir transiter le nom n'apporte pas de confidentialité supplémentaire, on sait quand-même chez qui tu consultes les infos (le même détenteur du certificat), alors qu'avec la seule IP, sur des serveurs mutualisés ça serait très différent. Seulement dans ce cas, HTTPS offrirait plus de confidentialité que le nom qui circule en clair, ce n'est pas le cas, donc sans minimiser l'intérêt d'HTTPS, il n'apporte rien de ce côté là (même si ma réponse trop rapide était fausse).
[^] # Re: Intérêt d'HTTPS ?
Posté par jyes . En réponse au journal HTTPS Everywhere. Évalué à 2.
En pratique, ça ne change pas grand-chose, parce-que du coup le serveur doit répondre en HTTPS avant de savoir avec quel nom il est consulté, donc en HTTPS : 1 IP = 1 nom.
[^] # Re: L'UTF-8 sa krash du fe
Posté par jyes . En réponse au journal Méthodes d’entrée pour les applications graphiques, de XIM à GTK en passant par IBus et UIM. Évalué à 0.
[^] # Re: SCIM vs IBus
Posté par jyes . En réponse au journal Méthodes d’entrée pour les applications graphiques, de XIM à GTK en passant par IBus et UIM. Évalué à 3.
Du coup, par défaut, j'ai le choix entre le confort de mes combinaisons de touches via la composition de X, ou la possibilité de saisir des caractères mathématiques par mots LaTeX. Comme je n'utilise que des langues à alphabets courts et pas de chinois ou de japonais, je préfère bénéficier par défaut de mes réglages de composition que de la saisie par mots. Évidemment, avant que je découvre ces problèmes j'utilisais IBus en permanence (et c'est ce que doivent faire tous les utilisateurs de GTK qui n'ont jamais vu les limites du mode de saisie par défaut).
[^] # Re: SCIM vs IBus
Posté par jyes . En réponse au journal Méthodes d’entrée pour les applications graphiques, de XIM à GTK en passant par IBus et UIM. Évalué à 4.
Pour activer XIM manuellement par exemple, il faut choisir dans le menu la méthode d'entrée « Méthode de saisie X » pour GTK en français ou XIM dans Qt en anglais (désolé, je n'ai pas sous la main d'appli Qt francisée où il est possible de changer la méthode d'entrée).
[^] # Re: commentaire inutile
Posté par jyes . En réponse au journal Ah le français !. Évalué à 3.
https://help.ubuntu.com/community/GtkComposeTable
[^] # Re: LaTeX, c'est bien !
Posté par jyes . En réponse à la dépêche Sortie de LyX 1.6.6 et LyX 2.0-α4. Évalué à 3.
[^] # Re: Jobs tout puissant
Posté par jyes . En réponse au journal Vulnérabilité du greffon Flash : 64 bits piégés. Évalué à 6.
[^] # Re: fin annoncée...
Posté par jyes . En réponse au journal La fin de Freshmeat.net. Évalué à 3.
Pour abonder dans ce sens, combien de fois ai-je utilisé aptitude pour trouver le nom d'un logiciel à conseiller à mes collègues sous Windows ! À chaque fois, malgré les quelques faux-positifs qui ne sont pas portés sous Windows, le logiciel que je trouve est mieux adapté à leur besoin que le gratuiciel qu'ils ont mis un temps fou à repérer sur les sites de téléchargement (ou le truc craqué que leur a filé un autre collègue).
Au final c'est bien, ça a même convaincu certains de quitter Windows complètement. Les autres se contentent des quelques logiciels libres que je leur ai conseillé ainsi puisque (et c'est tant mieux) cette méthode de recherche ne renvoie que des logiciels libres.
[^] # Re: fin annoncée...
Posté par jyes . En réponse au journal La fin de Freshmeat.net. Évalué à 8.
Et surtout, contrairement à ce que dit Zenitram, il n'y a aucune incohérence entre suivre les versions sur un site dédié et utiliser un gestionnaire de paquets. En effet, les versions ne sont pas forcément les mêmes (et j'ai déjà expliqué pourquoi ça ne me gêne pas plus que ça), et le public n'est pas tout à fait le même. Là où le gestionnaire de paquets est censé être utilisé par tous les utilisateurs, seuls ceux qui veulent chercher un peu plus loin, les développeurs et les curieux utilisent Freshmeat.
Par exemple, personnellement, je regarde beaucoup Distrowatch alors que l'essentiel des annonces concerne des versions bêta, c'est que j'ai envie de tester les nouveautés, éventuellement de remonter des bugs, mais ce n'est pas pour autant que veux tout tout de suite dans ma Debian. C'est valable avec d'autres logiciels, même en tant que non développeur, il m'arrive de compiler certaines applis depuis les dépôts Git (ou SVN, c'est pas moi qui choisis), et ça ne m'empêche pas d'utiliser au quotidien la version distribuée par Debian qui est souvent plus stable et plus intégrée au reste de la distro.
[^] # Re: Explication?
Posté par jyes . En réponse au journal Petit coup de gueule contre les distributions grand public. Évalué à 5.
Tu as l'air de connaitre un minimum de choses sur la question (ce que laissent supposer tes interventions). Pourquoi ne pas initier une réflexion/comparatif sur ces différents systèmes de package: recenser, détailler, comparer... pour qu'il soit possible ensuite de spécifier/réaliser l'évolution vers un meta-package.
De toute façon, je ne crois pas que ce serait la bonne solution. La fabrication de paquet n'est pas toujours aisée, et elle gagnerait à être simplifiée pour beaucoup de distros, cependant je trouve ça très bien si les développeurs ne font leurs paquets eux-même. L'intérêt des paquetages, ce n'est pas leur format, mais le travail d'intégration à la distribution que font les mainteneurs (sauf pour Ubuntu ☺).
La course au numéro de version, c'est un peu le truc qui ne sert à rien. Je ne me plains pas chque fois que je vois une fonctionnalité ajoutée dans le SVN d'un projet et qu'elle n'est pas encore dans ma distro. Déjà, je dois attendre que la sortie d'une version par les développeurs, et ensuite les mainteneurs fabriquent le paquet et apportent toute leur connaissance des rouages de la distro. je considère que ça fait partie du cycle de développement. Après, pour les testeurs ou lors d'une fonctionnalité vraiment intéressante, j'apprécie que les développeurs me dépannent en sortant des verisons précompilées (et plutôt pas sous la forme de paquetages) des « nightly builds », mais c'est normal si ce n'est pas dans la distro.
[^] # Re: Explication?
Posté par jyes . En réponse au journal Petit coup de gueule contre les distributions grand public. Évalué à 1.
Ce n'est pas tabou, c'est juste que ça marche très bien pour l'utilisateur et que ça évite la multiplication des tiers de confiance lors de la distribution d'un programme. Maintenant, les développeurs qui font eux-même leur paquet, c'est un truc que je n'ai jamais vraiment compris, en tant qu'utilisateur ça m'a toujours compliqué les choses :
- je dois installer le paquet en tant que super-utilisateur, alors que je pourrais tester le programme en tant qu'utilisateur simple ;
- il manque toujours plein de distributions ;
- les devs se plaignent de devoir faire ce boulot que je ne leur demande pas ;
- si ça marche sous Windows, c'est parce-qu'en cas de soucis les dévs n'hésitent pas à fourguer avec le programme tout un paquet de choses qui seraient des dépendances sous Linux. Eh ben moi ça m'irait bien un programme pré-compilé dans un répertoire avec des bibliothèques liées statiquement ou un wrapper qui définit un LD_LIBRARY_PATH comme le proposent beaucoup d'éditeurs de logiciels proprios sous Linux. C'est simple pour l'utilisateur comme sous Windows, et au moins, ça laisse la fabrication des paquets à ceux qui font ça bien.
[^] # Re: Présent!
Posté par jyes . En réponse au journal Ce bug ne sera pas corrigé car nous ne pouvons pas le reproduire. Évalué à 2.
http://www.arobase.org/spam/monty-python.htm (avec texte original et traduction pour les anglophobes).
[^] # Re: pour la forme,
Posté par jyes . En réponse au journal Appel à l'accessibilité GNU. Évalué à 2.
Une image rend interactif ? Même dans une page interactive, une image reste une image. Peut-t-elle être autre chose qu'un contenu (auquel cas le alt est nécessaire et justifié) ou de la présentation (qui devrait partir en CSS) ?
indispensable à la page. mais inutile pour un non-voyant.
Oui, donc rien à voir avec l'accessibilité du coup s'il existe des trucs indispensables mais que ça ne concerne pas les non-voyants et qu'ils ont pas à le savoir (après tout c'est pas ta faute s'ils y voient rien, hein).
c'est ballot, c'est explicitement prévu et conseillé par la norme
Oui, c'est même ce à quoi je répondais. Avec le contexte d'un tel conseil, ça veut dire en gros, « ne le faîtes pas, après si vous voulez être valide avec le schéma normalisé sans comprendre pourquoi, la solution est de mettre un truc vide ». Normalement si t'as bien fait ton boulot en amont (séparation de la CSS) ça n'arrive pas.
forcer la main à de nombreux pisseurs de code qui ne s'en servaient pas du tout.
Ceux qui ne s'en servaient pas en mettent maintenant un vide… Personnellement je m'en fous, ce n'est pas plus accessible dans un cas que dans l'autre (donc pas pire). Par contre je trouve intelligent que la norme considère qu'une image dispose nécessairement d'un texte alternatif. Après si en tant qu'auteur TU considères que les aveugles, les navigateurs consoles, les moteurs de recherche et autres ne méritent pas d'accéder à l'information, eh ben tu décris rien dans le alt.
Si moi je considère que les gens qui utilisent des navigateurs respectueux des standards n'ont pas à lire tout ce que j'écris, alors je mets du texte dans des commentaires XML en exploitant des bugs de parsing d'IE. J'ai des documents valides, lisibles que sous IE… Ben c'est pas ce que prévoit la norme, ça te choque ?
Le point où je suis en désaccord avec moi-même dans ma réponse précédente, c'est la comparaison avec le poids des images. C'est vrai que ça peut ne pas être négligeable comme le soulignait Zenitram. Maintenant, dans la mesure où ça s'adresse aux images CONTENUES dans la page, c'est normal qu'elles soient accessibles à tous, et donc cette surcharge me paraît tout à fait justifiée.