Что является удобством использования, доступностью, программой для чтения с экрана, или любой другой разработкой, функциональностью или перекрестными проблемами браузера с ?
Есть ли любая альтернатива для ?
И есть ли любой JavaScript/jQuery или методы серверной стороны, которые могут уменьшить удобство использования, доступность или проблемы для чтения с экрана с ?
Почему W3C не включал в Строгом XHTML, в то время как HTML 5 поддерживает
?
обновление:
Я нашел некоторые хорошие мысли здесь также: http://uxexchange.com/questions/1817/iframe-accessibility-and-usability-issues
Доступность:
Юзабилити:
Другие проблемы:
Если у вас один iframe, проблем не возникнет. Однако проблема усугубляется наличием нескольких окон iframe. Точка фокуса четко не доступна, а программы чтения с экрана недостаточно умны, чтобы найти визуальную корреляцию (по той же причине, по которой таблицы плохи для дизайна). ARIA - это попытка решить некоторые похожие проблемы. Ссылка на плагин YUI содержит дополнительную информацию.
Однако iframe все же находят свое место в дизайне. В одном проекте, с которым я работал раньше, страница содержала два фрейма (один из них был скрыт), а скрытый фрейм использовался для загрузки апплета аутентификации.Это не добавляет проблем с доступностью, поскольку внимание ограничено одним iframe, который, казалось бы, сливается со страницей
Почему W3C не включил iframe в XHTML Strict
Потому что в то время это было рассматривается как незаконнорожденный ребенок широко осуждаемого тега
. В принципе
имеет многие из тех же свойств, что и
, но на практике кажется, что это способствовало более изящному использованию, как правило, избегая наихудших проблем с навигацией и удобством использования, с которыми сталкивались интерфейсы набора фреймов.
Хотя HTML 5 поддерживает Iframe?
(a). Потому что, в отличие от
,
с тех пор оказался важным для смешанных документов, таких как те, которые включают рекламу, и многие типы веб-приложений. Есть еще проблемы, как упоминалось в других ответах, но обычно
рассматривается как необходимая функция, которая должна остаться. Это не относится к
, которая является «несоответствующей функцией» в HTML5 ( ближайший HTML5 попадает в категорию «строгих»).
(б). потому что авторы HTML5 в любом случае не особо заботятся о поощрении хорошей практики; речь идет о документировании того, что должны делать пользовательские агенты. Они включили в стандарт все устаревшие функции HTML4, а также множество других традиционных, но хитрых способов поведения браузера, включая все особенности разбора сломанных тегов.[в сторону: я очень удивлен, увидев, что последний аргумент, обсуждаемый в их списке, касается того, как следует обрабатывать элемент
- элемент, который буквально никто не использовал с тех пор, как элементы формы HTML 2.0 сделали его устарел в 1995 г.]
Учитывая ошеломляющие размеры и сложность HTML5, неудивительно, что они не захотели дополнительных усилий по объявлению более ограниченного профиля «строгого режима». Однако, когда работа подходит к концу, мне бы хотелось увидеть XHTML5 Strict или подобное усилие, чтобы немного уменьшить этот беспорядок. В нынешнем виде Хикси и его друзья сделали снимок всех мерзких взломов, которые браузер должен использовать для обеспечения совместимости сегодня, и сделали это стандартным требованием для всех браузеров в обозримом будущем, фактически оправдывая плохую практику.