Почему я не должен использовать фреймы HTML?

Я не использовал фреймы с 1998 года. Они кажутся плохой идеей, и во всем моем развитии у меня никогда не было ситуации, когда фреймы были правильным решением или даже достойным решением.

Однако теперь я работаю с внутренним веб-приложением, написанным другой группой, и весь сайт построен в виде заголовка, левого меню, правого содержимого - набора фреймов.

Для одного, когда VPN'd в моей сети я постоянно получаю сообщение "website.com/frames.html" не может быть найдено. "Это не происходит, когда я во внутренней сети.

Во-вторых, приложение имеет встроенную систему электронной почты/сообщений. Количество непрочитанных сообщений отображается в рамке меню слева как "Сообщения (3)", но счет не обновляется при чтении сообщений. Разработчик сказал мне, так как это было в кадре, мне нужно было щелкнуть правой кнопкой мыши по меню и "Обновить". Серьезно????

Итак, мой вопрос, связанный с программированием, заключается в том, какие у вас причины для использования фреймов на веб-сайте?

ОТВЕТЫ

Ответ 1

Хотя они решили проблему в то время, когда они были созданы (обновляя часть "страницы", сохраняя на месте не обновляющуюся часть), фреймы часто подвергались критике с точки зрения удобства использования с самого начала, поскольку они прерывают общий функции браузера, такие как:

  • закладок и копировать и вставлять URL-адреса для совместного использования
  • печать страницы, отображаемой на экране
  • перезагрузка страницы: поскольку URL-адрес вообще не изменен, вас часто возвращают на домашнюю страницу сайта или набор фреймов по умолчанию; ручная перезагрузка некоторых фреймов возможна, но не очевидна для пользователя.
  • кнопки "назад" и "вперед" неоднозначны: отмените/измените последнее изменение кадра или перейдите в последний раз, когда изменилась строка URL?

Самое тяжелое бремя избегания наборов фреймов, включая один и тот же контент на каждой странице, тривиально решить, если вы используете какой-либо серверный язык для генерации вашего HTML-кода, даже если все, что он предоставляет, является "серверной частью". В отличие от наборов фреймов серверная сторона может встречаться в любом месте страницы; создание сайта с серверным скриптовым языком или системой шаблонов также имеет и другие очевидные преимущества.

По-прежнему существует преимущество в том, что можно обновлять небольшие области страницы без перезагрузки всего содержимого, что может быть достигнуто с помощью AJAX. Это иногда заставляет людей создавать интерфейсы со всеми проблемами наборов фреймов, описанными выше, но это вряд ли является аргументом в пользу наборов фреймов. Опять же, сайт, построенный с хорошо спроектированной функциональностью AJAX, может достичь того, что даже не начинают обращаться к наборам фреймов.

Ответ 2

Одна из веских причин избежать фреймов сегодня - они устарели в HTML 5: Глава 11 Устаревшие функции

11.2 Несоответствующие функции

Элементы в следующем списке полностью устарели и не должны быть используемые авторами:

[...]

рамка

фреймов

NOFRAMES

Вместо этого используйте iframe и CSS или используйте серверную часть для генерировать полные страницы с различными включенными частями инвариантов.

Ответ 3

Причина №1? Пользователи ненавидят их.

Даже если они предлагают преимущества в других областях (разделение кода, дизайн приложения, скорость и т.д.), они являются частью пользовательского интерфейса. Если пользователи не одобряют, не используйте их.

Ответ 4

Рамки были смутно полезны, когда у вас был статический веб-сайт, чтобы, например, не повторять меню навигации на всех страницах. Он также уменьшил общий размер страницы.

Оба эти аргумента устарели сейчас: сайты не стесняются обслуживать толстые страницы, и большинство из них динамически построены, поэтому включение таких навигационных частей (или статуса и т.д.) не имеет проблем.

Часть "почему" ответила выше, частично на ваш собственный вопрос (вы нажимаете ограничение, хотя его можно переопределить с помощью немного JS).

Ответ 5

Причина моего номера 1 для использования фреймов заключается в том, что они нарушают функцию закладки (ака любимой) браузеров.

С технологией, которая существует сегодня, фреймы устарели. Но если ваш старый проект все еще использует их, вы можете обновить сообщения с помощью ajax.

Ответ 6

Просто из-за повального увлечения iPad сотового телефона не означает, что высокофункциональные полнофункциональные сайты внезапно "устарели", а те, кто решил сделать устаревшие устаревшие фреймы, похоже, являются теми же жалобщиками, которые никогда не выяснили свой полный потенциал в первое место, или, может быть, они лоббисты мегакорпоративных производителей сотовых телефонов и планшетов, которые не могли быть обеспокоены тем, чтобы сделать приличный браузер, способный работать в браузере, для своих многопользовательских экранов.

По общему признанию, iFrames может обрабатывать простые задания, такие как прокрутка и/или отображение отдельных сегментов в одной странице, и я использую их для этого на моем собственном веб-сайте на основе фреймов, но чтобы заставить их работать, а также основы для сам сайт - это кошмар. Поверьте мне, я знаю, потому что мой веб-сайт является одним из самых сложных сайтов на основе наборов фреймов в Интернете, и я смотрел на плюсы и минусы переноса всего этого на iFrames. Кошмар - это преуменьшение.

Я уже слышу, как нытики говорят: "Ну, почему ты так построил это в первую очередь?"... и ответ: А: Потому что я не ленив. и B: поскольку сайт на основе фреймов является наиболее функциональным, визуально привлекательным и удобным для пользователя форматом для сайта, основанного на информации, сотнями страниц контента, которые не должны полагаться на сервер. Под этим я подразумеваю, что внешняя реклама может быть просмотрена прямо с флеш-накопителя. Нет необходимости в MySQL или PHP.

Вот некоторые из проблем, с которыми я столкнулся:

  • Возражение к потерянным страницам может быть легко обработано с помощью JavaScript.
  • Возражение относительно закладок не имеет значения, если вы не используете все фреймы.
  • Конкретная закладка содержимого может быть обработана с помощью функции JavaScript "Добавить закладку"
  • Возражение в отношении SEO легко обрабатывается XML-картой сайта и JavaScript.
  • Укладка динамически размерных кадров намного проще и надежнее со стандартными наборами фреймов.
  • Таргетирование и замена вложенных наборов фреймов из внешнего фрейма проще со стандартными наборами фреймов.
  • Внутренние скрипты, такие как JavaScript-поиски и не зависящие от сервера корзины покупок, которые слишком сложны для файлов cookie, не кажутся возможными с iFrames, или, если они есть, это еще больше хлопот, чтобы заставить их работать, чем использовать стандартные фреймы.

Все, что сказано, мне нравится одностраничное обращение iFrames, и когда они действительно могут делать все то же самое для моего сайта так же легко, как и стандартные кадры, то я буду мигрировать. В то же время эта глупость о том, что они "устарели", столь же неприятна, как и другие так называемые "апгрейды", которые они навязывали нам на протяжении многих лет, не думая об этом на всем пути.

Итак, что все это сводится к вопросу о том, использовать ли фреймы или нет? Ответ заключается в том, что все зависит от того, что вы хотите сделать на своем сайте, и на какой платформе он будет в основном просматриваться. В какой-то момент становится нецелесообразным работать многостраничный сайт без каких-либо фреймов или интеграции iFrame. Однако, если вы просто создаете базовую страницу профиля, которая хорошо отображается на мобильном телефоне или планшете, не беспокойтесь о наборах фреймов.

Ответ 7

Они почти всегда заставляют людей сердиться. Что еще вам нужно?

Ответ 8

Кадры действительно полезны в некоторых случаях. Если вы создаете локальную веб-страницу, которая служит только для чтения, интерактивности не требуется, и веб-сайт не будет публичным в Интернете, все причины не использовать фреймы удаляются. Например, руководство пользователя для приложения, которое разработано исключительно в html, фреймах, действительно полезно для сохранения оглавления слева простым и простым способом. Также, если у вас есть правильная навигация внутри веб-сайта, то неоднозначность кнопки "Назад" полностью удаляется.