Quelles sont la facilité d'utilisation, l'accessibilité, lecteur d'écran ou tout autre développement, la fonctionnalité, problème croix navigateur avec iframe?
-
20-09-2019 - |
Question
Quels sont la facilité d'utilisation, l'accessibilité, lecteur d'écran, ou tout autre développement, la fonctionnalité ou les questions transversales navigateur avec <iframe>
?
est-il une alternative pour <iframe>
?
Et sont-il des techniques JavaScript / jQuery ou côté serveur qui peut diminuer la convivialité, l'accessibilité, ou des problèmes de lecture d'écran avec <iframe>
?
Pourquoi le W3C non inclus <iframe>
en XHTML Strict, alors que HTML 5 supports <iframe>
?
Mise à jour:
Autres conseils
Pourquoi W3C pas inclus dans Iframe XHTML Strict
Parce qu'à l'époque, il était considéré comme un enfant bâtard de l'étiquette <frame>
largement décrié. En principe <iframe>
a beaucoup des mêmes propriétés que <frame>
, mais dans la pratique, il semble avoir encouragé une utilisation plus bon goût, ce qui évite généralement le pire des problèmes de navigation et de facilité d'utilisation que les interfaces frameset ont souffert.
Alors que HTML 5 est compatible avec iFrame?
(a). Parce que, contrairement à la <frame>
, <iframe>
a depuis avéré essentiel pour les documents mixtes tels que ceux dont les annonces, et de nombreux types d'applications Web. Il y a encore des problèmes, comme mentionné dans d'autres réponses, mais en général le <iframe>
est considéré comme un élément nécessaire qui est là pour rester. Ce n'est pas vrai <frame>
, qui est une « fonction non conforme » en HTML5 (le plus proche HTML5 arrive à une sorte de « stricte »).
(b). parce que les auteurs de HTML5 ne se soucient pas tant d'encourager les bonnes pratiques de toute façon; il s'agit de documenter ce que les agents utilisateurs doivent faire. Ils ont jeté toutes les fonctionnalités obsolètes de HTML4 dans la norme, ainsi que beaucoup d'autres le comportement du navigateur traditionnel, mais y compris tous les louches dernière bizarrerie de l'étiquette cassée analyse syntaxique de la soupe. [De côté. Je suis très amusée de voir le dernier argument qui a discuté sur leur liste étant la façon dont l'élément <isindex>
doit être manipulé - un élément qui littéralement personne n'a utilisé depuis les éléments de formulaire de HTML 2.0 ont rendu obsolète en 1995]
Compte tenu de la taille et de la complexité stupéfiante de HTML5, il est pas vraiment surprenant qu'ils ne voulaient pas l'effort supplémentaire de déclarer un profil « mode strict » plus limité. Comme le travail se termine, bien que, j'aimerais voir un effort XHTML5 strict ou similaire à tailler une partie de ce gâchis. En l'état actuel, Hixie et chums ont pris un instantané de chaque bidouille méchant un navigateur doit mettre en pour la compatibilité d'aujourd'hui, et fait une exigence standard pour tous les navigateurs dans un avenir prévisible, la mauvaise cautionner le pratique.
Si vous avez un Iframe, il y aurait peu de problème. Cependant, plusieurs iframes aggravent le problème. Un point de mise au point est pas clairement disponible et les lecteurs d'écran ne sont pas assez intelligents pour trouver une corrélation visuelle (même raison pour laquelle les tables sont mauvais pour la conception). ARIA est une tentative faits pour résoudre certains problèmes similaires. YUI plug-in lien a plus d'informations.
Cependant iframes ne trouvent leur place dans la conception. Dans un projet, je travaillais auparavant, la page contenait deux iframes (l'un d'eux caché) et le cadre caché a été utilisé pour télécharger une applet d'authentification. Cela n'ajoute pas de difficultés d'accessibilité que le point d'attention est limitée à un seul iframe qui se confond avec la page seemlessly