1) a) Heu oui c'est ça, c'est mon serveur apache que je configure moi même. Il est installé dans mon arrière cour, là où j'ai une ligne T1. Ca vallait l'investissement pour afficher la doc du GOTO++.
b) On s'est mal compris. Imagine que le gars est en train de regarder la liste des fonctions texte. Il clique sur NombreDeLettres. Paf ça s'affiche dans le cadre de droite. Mais finalement c'est pas ce qu'il voulait, donc il clique sur bananasplit. Si j'avais pas utilisé de cadre, il aurait été obligé de scroller jusqu'au bon endroit dans le menu jusqu'à retrouver le lien alors que là il était immédiatement accessible.
D'ailleurs les applications utilisent souvent ce genre de présentation (exemple : le panneau de config de Mozilla). C'est pas parce qu'une "application" est en HTML qu'elle échape aux règles d'accessibilité.
2) Templeet n'utilise pas de cache pour toutes les pages my/, à ma connaissance en tout cas (d'ailleurs c'est à ça que sert le my). Et c'est normal, puisqu'elles changent tout le temps et qu'il faudrait en fait une copie en cache du site pour chaque utilisateur ! Et puis que des données soient en cache n'empêche pas qu'il faut les envoyer = bande passante encore !
De toute façon j'ai que 30 Mo sur mon hébergeur donc le cache n'est pas envisageable (surtout si dans chacune des milliers de page je dois rajouter le menu !).
Bref l'accessibilité aux non voyant c'est bien mais c'est pas une raison pour être allergique anti cadre. Autant avoir les deux. Une solution pour les non voyants (et les moteurs de recherche) et une solution pour les autres.
[^] # Re: Amaya 8.0-pre avec SVG animation
Posté par Sidoine de Wispelaere . En réponse à la dépêche Amaya 8.0-pre avec SVG animation. Évalué à 1.
b) On s'est mal compris. Imagine que le gars est en train de regarder la liste des fonctions texte. Il clique sur NombreDeLettres. Paf ça s'affiche dans le cadre de droite. Mais finalement c'est pas ce qu'il voulait, donc il clique sur bananasplit. Si j'avais pas utilisé de cadre, il aurait été obligé de scroller jusqu'au bon endroit dans le menu jusqu'à retrouver le lien alors que là il était immédiatement accessible.
D'ailleurs les applications utilisent souvent ce genre de présentation (exemple : le panneau de config de Mozilla). C'est pas parce qu'une "application" est en HTML qu'elle échape aux règles d'accessibilité.
2) Templeet n'utilise pas de cache pour toutes les pages my/, à ma connaissance en tout cas (d'ailleurs c'est à ça que sert le my). Et c'est normal, puisqu'elles changent tout le temps et qu'il faudrait en fait une copie en cache du site pour chaque utilisateur ! Et puis que des données soient en cache n'empêche pas qu'il faut les envoyer = bande passante encore !
De toute façon j'ai que 30 Mo sur mon hébergeur donc le cache n'est pas envisageable (surtout si dans chacune des milliers de page je dois rajouter le menu !).
Bref l'accessibilité aux non voyant c'est bien mais c'est pas une raison pour être allergique anti cadre. Autant avoir les deux. Une solution pour les non voyants (et les moteurs de recherche) et une solution pour les autres.