L'accessibilité mobile est déjà faite dans la spec HTML5. Le mobile est une terminal HTML. Le PC est un terminal HTML. La tablette est un terminal HTML. Le lecteur d'écran est un terminal HTML. C'est pour un terminal HTML que je préfère coder mes sites, et non pour un support précis.
Ainsi, sur mobile, eh bien le terminal agence tout seul le site (vive flex & autres media queries). Les préférences du navigateur & donc de l'utilisateur sont exploitées au maximum: elles seront surement plus adaptées que les bricolages du webmaster (qui sinon, code son site par rapport à son propre PC).
Si tu fais un site full-canvas tartiné de JS, oui, tu seras *obligé* de rajouter du framework pour compenser tous les effets de bords dus à la perte de la notion de page HTML. Le terminal mobile sait mieux que moi comment optimiser sa bande passante, à condition de lui déclarer les choses et non de les lui imposer. C'est le terminal mobile qui saura ne pas rafraichir automatiquement la page (par exemple) si le Wifi est désactivé. S'il ne sait pas le faire, c'est un bogue du *navigateur* et non du site (les deux rôles sont, je trouve, trop souvent mélangés).
@niahoo: Au fond, je n'ai pas l'intention de tester le codage d'un site mono-page à coup de framework, car du point de vue utilisateur, je n'aime pas cela. Jongler entre des frames, c'est de la navigation pour moi (utilisateur). Si elle ne te plait pas, c'est ton/le navigateur qu'il faut améliorer, pas le site, car ce n'est pas son rôle.
Tu fais surement la même description avec du HTML classique et du CSS. Le JS va juste servir à poser les éventuelles classes manquantes au bon moment.
D'accord pour ton exemple sur l'historique, mais maintenant, tu peux te prendre tout autant la tête pour la navigation dans un textarea, pour le scroll dans la page (flèches clavier, barre, tactile, molette quadri, bouton souris 4 enfoncé + déplacement, etc).
Et un quizz sur *l'accessibilité* qui nécessite justement du JS pour "Démarrer le quizz",ça commence bien!
"Chargement du quiz... " Non mais sérieux, vous allez faire comment pour me dire que ça, c'est de l'optimisation? Ce genre de truc, déjà, peut parfaitement être dans la page de base (c'est ce qui devrait d'ailleurs être fait: les "question suivante", ou "démarrer le quizz" ne sont que de la présentation). n'allez pas dire "ça optimise car on charge moins de trucs": mettre le formulaire sur 1 seule page, ça chargera moins et si on fait un quizz, c'est pas pour s'arrêter en route.
Quand bien même on pourrait s'arrêter, c'est quoi la différence ici avec une iframe? Mis à part que, en AJAX, vous allez mélanger tous les contextes de la page et rendre impossible l'affichage de deux frames identiques (car, par exemple, ces frames ont un élément avec le même ID car elle apparait 2x dans la page)?!
Bon, allez, crotte, désolé mais un quizz de "bonne pratique comme ça", juste non. Le lien pour agrandir l'image est un monceau de javascript: chez moi, un lien que tu cliques avec le bouton centrale s'ouvre dans un nouvel onglet, point. C'est pas une daube de frame JS mélangée au contenu de la page avec un bouton "Fermer" qui n'a rien à foutre ici.
Ainsi, sur mobile, eh bien le terminal agence tout seul le site (vive flex & autres media queries). Les préférences du navigateur & donc de l'utilisateur sont exploitées au maximum: elles seront surement plus adaptées que les bricolages du webmaster (qui sinon, code son site par rapport à son propre PC).
Si tu fais un site full-canvas tartiné de JS, oui, tu seras *obligé* de rajouter du framework pour compenser tous les effets de bords dus à la perte de la notion de page HTML. Le terminal mobile sait mieux que moi comment optimiser sa bande passante, à condition de lui déclarer les choses et non de les lui imposer. C'est le terminal mobile qui saura ne pas rafraichir automatiquement la page (par exemple) si le Wifi est désactivé. S'il ne sait pas le faire, c'est un bogue du *navigateur* et non du site (les deux rôles sont, je trouve, trop souvent mélangés).
@niahoo: Au fond, je n'ai pas l'intention de tester le codage d'un site mono-page à coup de framework, car du point de vue utilisateur, je n'aime pas cela. Jongler entre des frames, c'est de la navigation pour moi (utilisateur). Si elle ne te plait pas, c'est ton/le navigateur qu'il faut améliorer, pas le site, car ce n'est pas son rôle.
Tu fais surement la même description avec du HTML classique et du CSS. Le JS va juste servir à poser les éventuelles classes manquantes au bon moment.
D'accord pour ton exemple sur l'historique, mais maintenant, tu peux te prendre tout autant la tête pour la navigation dans un textarea, pour le scroll dans la page (flèches clavier, barre, tactile, molette quadri, bouton souris 4 enfoncé + déplacement, etc).
Et un quizz sur *l'accessibilité* qui nécessite justement du JS pour "Démarrer le quizz",ça commence bien!
"Chargement du quiz... " Non mais sérieux, vous allez faire comment pour me dire que ça, c'est de l'optimisation? Ce genre de truc, déjà, peut parfaitement être dans la page de base (c'est ce qui devrait d'ailleurs être fait: les "question suivante", ou "démarrer le quizz" ne sont que de la présentation). n'allez pas dire "ça optimise car on charge moins de trucs": mettre le formulaire sur 1 seule page, ça chargera moins et si on fait un quizz, c'est pas pour s'arrêter en route.
Quand bien même on pourrait s'arrêter, c'est quoi la différence ici avec une iframe? Mis à part que, en AJAX, vous allez mélanger tous les contextes de la page et rendre impossible l'affichage de deux frames identiques (car, par exemple, ces frames ont un élément avec le même ID car elle apparait 2x dans la page)?!
Bon, allez, crotte, désolé mais un quizz de "bonne pratique comme ça", juste non. Le lien pour agrandir l'image est un monceau de javascript: chez moi, un lien que tu cliques avec le bouton centrale s'ouvre dans un nouvel onglet, point. C'est pas une daube de frame JS mélangée au contenu de la page avec un bouton "Fermer" qui n'a rien à foutre ici.