Почему W3C не включает Iframe в XHTML Strict
Потому что в то время его считали подонком у широко оскорбленной метки <frame>. В принципе, <iframe> обладает многими из тех же свойств, что и <frame>, но на практике это стимулирует использование более со вкусом, как правило, избегая худших проблем навигации и удобства использования, с которыми сталкивались интерфейсы фреймов.
В то время как HTML 5 поддерживает Iframe?
(а). Потому что, в отличие от <frame>, <iframe> с тех пор оказался незаменимым для смешанных документов, таких как рекламные объявления, и для многих типов веб-приложений. Как и в других ответах, проблемы все еще существуют, но, как правило, <iframe> рассматривается как необходимая функция, которая останется здесь. Это не относится к <frame>, который является «несоответствующей функцией» в HTML5 (ближайший HTML5 попадает в любой «строгий»).
(б). потому что авторы HTML5 все равно не заботятся о поощрении хорошей практики; речь идет о документировании того, что должны делать пользовательские агенты. Они добавили в стандарт все устаревшие функции HTML4, а также множество других традиционных, но изворотливых действий в браузере, включая каждую последнюю причину разбора супа с битыми тегами. [в сторону: я очень удивлен тем, что последний аргумент, обсуждаемый в их списке, показывает, как должен обрабатываться элемент <isindex> - элемент, который буквально никто не использовал, так как элементы формы HTML 2.0 сделали его устаревшим в 1995 году.]
Учитывая ошеломляющий размер и сложность HTML5, неудивительно, что им не потребовалось дополнительных усилий для объявления более ограниченного профиля «строгого режима». Однако, когда работа подходит к концу, я хотел бы увидеть XHTML5 Strict или аналогичные усилия, чтобы уладить часть этого беспорядка. В нынешнем виде Хикси и Чамс сделали снимок каждого неприятного хака, который браузер должен внедрить сегодня для обеспечения совместимости, и сделали его стандартным требованием для всех браузеров в обозримом будущем, эффективно оправдывая плохую практику.