HTML - FAQteam

Обсуждение багов, глюков и прочих насекомых, выползающих из наших любимых броузеров при попытке скормить им Hypertext Markup Language. Здесь происходит борьба с таблицами, драка с отступами и избиение шрифтов.

  1. Ширина содержимого и отступы броузеров по умолчанию.
  2. Как вывести документ в своем фреймсете.
  3. Background таблиц в Netscape.
  4. Об атрибуте ALT.
  5. В какой кодировке лучше писать веб-страницы.
  6. Использование meta-тегов description и keywords.
  7. Об использовании кавычек в атрибутах тегов.
  8. Фокусировка курсора на просматриваемых фреймах.

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

Ответ: Лучше всего представить все эти значения в виде таблицы.

Броузер Разрешение Ширина безопасная Ширина максимальная LEFTMARGIN (MARGINWIDTH) TOPMARGIN (MARGINHEIGHT)
IE3 640x480 610 614 10 (default) 16 (default)
620 624 0 0
800x600 770 774 10 (default) 16 (default)
780 784 0 0
IE4 640x480 600 600 10 (default) 15 (default)
620 620 0 0
800x600 760 760 10 (default) 15 (default)
780 780 0 0
NN4 640x480 610 616 8 (default) 8 (default)
618 632 0 0
800x600 770 776 8 (default) 8 (default)
778 792 0 0

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

Под разрешением понимается следующее: окно броузера при данном разрешении развернуто на весь экран (не полноэкранный режим в случае IE4) при стандартных установках Windows.

MARGINWIDTH и MARGINHEIGHT в Netscape - довольно ненадежная штука. Если обнулить, например, эти значения, то все равно останутся границы по 3 пиксела. Есть, конечно, обходной путь - использовать один большой фрейм.

 Внимание: И при максимальной и при "безопасной" ширине не появляется горизонтальная линейка прокрутки (при данных значениях margin), но если содержимое прижато вплотную к правой границе, в IE3 и NN4 то, что находится между максимальной и безопасной шириной никто и никогда не увидит (горизонтальной линейки-то нет!) если высота страницы такова, что появляется вертикальная линейка прокрутки (почти всегда). Более того, в IE3 этого при любых обстоятельствах никто не увидит - вертикальная линейка прокрутки всегда на экране, и содержимое прячется за ней.

Следует также помнить о том, что у разных пользователей разный размер окна браузера, и области в которой показывается html-страница. Это также зависит от многих причин:

  • автоматически прячется панель задач в Windows;
  • панель задач находится сбоку, присутствуют дополнительные панели других програм (например MS Office);
  • в окне браузера спрятана строка адреса;
  • кнопки без подписей или также спрятаны;
  • браузер находится в режиме full screen.

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

 Проверено на : IE3, IE4, NN4+ под Windows.


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

Ответ: В этом и похожих случаях используется простой скрипт, который вставляется обычно в начале документа. Его можно реализовать по-разному. Самый простой способ, наверное, в проверке, не является ли свой фрейм по совместительству и фреймом верхнего уровня:

<script type="text/javascript"><!--
if (top==self) location.href="index.html"  // index.html- фреймсет
//--></script>

Можно также проверять длину массива фреймов в top-фрейме:

<script type="text/javascript"><!--
if (! top.frames.length) location.href="index.html"
//--></script>

Возможен также вариант с проверкой имени фрейма, которое ему давалось во фреймсете. Например, файл с фреймсетом выглядит так:

<frameset rows="30,*">
  <frame src="a.html" name="navigation">
  <frame src="b.html" name="main">
</frameset>

тогда в файле b.html можно использовать следующий код:

<script type="text/javascript"><!--
if (self.name!="main") top.location.href="index.html"
//--></script>

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

 Примечания: Все эти способы не сработают, если в броузере пользователя отключен JavaScript. Если ваша страница использует JS для более серьезных целей, и без него ее выводить не имеет смысла, вы можете это вычислить и принять некоторые меры, вставив в заголовке HTML-файла (между тегами <HEAD> и </HEAD>) такой код:

<noscript>
<meta http-equiv="refresh" content="0; URL=alternat.html">
</noscript>

а файл alternat.html может выглядеть так:

<html>
А не включили бы вы себе JavaScript, а?
</html>

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

 Проверено на : IE4, IE5, NN4+ под Windows, NN4.06 под Linux.


Вопрос:  Я на своей странице сделал таблицу с background="картинка.jpg". В IE все получается нормально, а в NN этот background вырисовывается заново в каждой ячейке по-отдельности. Что делать?

Ответ: Действительно, в Нэтскейпе получается такая штука. Один из способов избежать этого заключается в следующем. Необходимо существующую таблицу вложить в еще одну таблицу размером в одну ячейку и задать в качестве одного из параметров в этой новой таблице ваш background. А в исходной таблице этот параметр необходимо заменить на background="". Выглядеть это будет примерно так:

<table background="картинка.jpg" width="ширина_таблицы" border="0"
  cellspacing="0" cellpadding="0">
<tr><td>
  <table background="" width="100%">
    <tr><td>текст</td><td>текст</td></tr>
    <tr><td>текст</td><td>текст</td></tr>
  </table>
</td></tr>
</table>

 Примечания: Консорциум W3C упоминает об возможности использования параметра background только для элемента <body>. Данный параметр для элемента <table> отсутствует. Также в некоторых браузерах (Opera и др.) он игнорируется для элемента <table>.

 Проверено на : IE 4.0+, NN 4.5, Opera 4 под Windows.


Вопрос:  Я слышал, что если в html-документе есть картинки, то у них обязательно должен присутствовать атрибут alt. Зачем он нужен?

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

Почему его надо указывать всегда? Представьте, что вы на своей странице использовали графику для форматирования страницы. Пользователям подобных браузеров будет неудобно читать вашу страницу -- и там, и тут появятся ни к чему не относящиеся надписи: "empty.gif", "polosochka.gif", "kvadratik.jpg". Особенно будет неприятно пользователям речевых браузеров. В этих случаях всегда указывайте alt="", тогда эти надписи или их звуковой эквивалент не будет воспроизводиться, и вы избавите пользователей от подобного мусора.

Наоборот, если картинка несет важную смысловую нагрузку, например, заголовки, пункты меню, иллюстрации, то просто необходимо эти надписи или названия иллюстраций дублировать альтернативным текстом. Например, вот так: <img src="title.jpg" alt="Добро пожаловать!">. Тогда и пользователи подобных браузеров узнают, что же вы хотели им сказать, и легко смогут воспользоваться пунктами меню, в которых применялась графика.

 Примечания: Консорциум W3C рекомендует всегда использовать альтернативный текст для элементов <img> и <area>.

 Проверено на : ИЕ 4, ИЕ 5, НН 4.51, Опера 3.62, Lynx под Windows


Вопрос:  В какой кодировке мне лучше писать Веб-страницы?

Ответ: Если выбор стоит между Win-1251 и KOI-8, можете выбирать любую из них в качестве стандарта -- они официально зарегистрированы, распространены и поддерживаются большинством броузеров. Пишите в чем вам удобно -- кодировки должны быть проблемой броузера. Но при всем этом кодировка всегда должна быть указана тэгом <meta... > и/или HTTP-заголовком.

 Примечания: Если вопрос стоит ребром (например, большинство броузеров, зафиксированных в логах серверов, не имеют поддержки Unicode), чтобы угодить пользователям наверняка, надо исходить из платформы несчастных (чаще всего это Win32), кодировку ставя подобающую -- вот ужасное наследие серверов с автоопределением кодировки.

В свое время признание KOI-8 как стандартной сетевой кодировки (http://koi8.pp.ru/) сыграло очень важную роль для Рунета. Если вы и сейчас в силах придерживаться этого стандарта -- почему бы вам не сделать это?

 Внимание: Прежде чем использовать удобную вам кодировку, убедитесь, что в настройках Веб-сервера не стоит жесткой привязки расширений файлов к кодировкам. Несмотря на то, что у части современных броузеров кодировка в <meta... > играет приоритет над указанной в HTTP-заголовке, глюки в случае несоответствия кодировки ее указанию неизбежны.


Вопрос:  Нужно ли прописывать на каждой своей странице meta-теги description и keywords? Даст ли мне это преимущество при запросах на поисковых серверах?

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

К примеру, AltaVista на эту тему сообщает (перевод не дословный):

...Нет, вы, конечно, можете заполнять эти meta-теги, и это, конечно, даст некоторый результат... В своем роде... Но для нашего поискового механизма гораздо важнее информация, расположенная в заголовке страницы и в первых нескольких ее строках. Просто давно уже прошли времена, когда поисковые системы могли индексировать страницы в основном по этим meta-тегам - теперь поисковые системы, стали полнотекстовыми, т.е. индексирующими ВСЕ содержание страниц, включая даже подписи (alt) к картинкам. Т.е. теперь вам не удастся запудрить мозги поисковой системе, 500 раз написав слово "sex" в списке ключевых слов - все эти уловки (даже мелкий или одинаковый с цветом фона текст) давно обходятся грамотно написанными поисковыми механизмами...

Здесь под заголовком понимается именно содержимое тега <TITLE> в <HEAD>-части страницы, а не просто жирно написанное название наверху страницы.

Яндекс дал по этому поводу еще более ценную информацию:

Описание страниц (description) лучше все же прописывать на своих страницах - именно оно и будет выводиться в результатах поиска, рядом со ссылкой на вашу страницу. Что касается ключевых слов, то тут ситуация следующая. Ключевые слова, сами по себе, имеют гораздо меньший вес, чем, скажем, заголовок страницы, или само ее содержание (чем ближе текст к началу страницы, тем больший "вес" он имеет). Т.е. добавив множество ключевых слов (по теме и не по теме) - вы особых результатов не добьетесь. Весомый выигрыш дает совпадение ключевых слов указанных в keywords с основным текстом страницы (ну и с заголовком естественно). Ну и, конечно же, эти ключевые слова должны будут совпадать с запросом пользователя на поисковом сервере ;)

Все это в равной степени справедливо и для поискового сервера Апорт. Да и остальные сервера, я думаю, не сильно отличаются в плане обработки meta-тегов...

Ну а если прямо отвечать на поставленный вопрос - стоит ли заполнять meta-теги keywords и description? Да, стоит. Существует гораздо больше "за" чем "против" (собственно, "против" только одно - увеличивается объем странички). Но, как и всегда, пользоваться этим инструментом нужно с умом.

Приведу несколько итоговых советов:

  1. Каждая страница сайта должна иметь уникальный набор ключевых слов и описание - нет смысла описывать ВСЕ ключевые слова, касающиеся темы сайта, на странице какого-либо узкоспецифичного раздела.
  2. Все указанные на странице слова (и текст описания) должны встречаться в тексте самой страницы - такое совпадение и дает все преимущество от использования этих meta-тегов. Еще лучше если ключевые слова, текст описания и текст вашей страницы находят отражение в заголовке страницы. Именно текст заголовка имеет наибольший "вес" при подсчете релевантности (адекватности запросу) страницы - потому обязательно прописывайте заголовок страниц, а так же позаботьтесь о его уникальности - нет никакого смысла все страницы раздела называть именем этого раздела - подберите именно такое название, которое наиболее полно отражает текст конкретной страницы.
  3. Самое главное правило - не пытайтесь обмануть при помощи этих meta-тегов поисковую машину или пользователя. Повторения слов поисковыми серверами уже давно не учитываются. Я уже не говорю о попытках загнать в keywords слова из списка самых популярных запросов - такие выкрутасы тоже легко отслеживаются.

 Примечания: Вот такими могли бы быть эти самые теги для этой статьи:

<META name="description" content="Об использовании meta-тегов description и keywords">
<META name="keywords" content="meta мета description keywords search поиск">

Вопрос:  Вот хожу брожу по интернету и никак не могу понять: "Так нужны эти кавычки или нет?!"

Ответ: Как всегда, однозначно на этот вопрос никто вам не ответит...

Исходить можно из двух принципиально различных позиций:

  1. Универсальность
  2. Правильность - соответствие стандартам ("Чистота кода")

Разъясню все по порядку.

Итак - "Универсальность". Что мы имеем? Все браузеры уже давно прекрасно понимают любые атрибуты и без кавычек.

Вот лично я, например, ставлю их только для подписей к картинкам (alt="...") и в путях ссылок (src="...", href="..."), хотя и там и там, насколько я знаю, их тоже можно не прописывать (в случае если строка не содержит пробелов, разумеется).

Теперь посмотрим на "правильность".

Стандарт HTML 4.0 вещает:

In certain cases, authors may specify the value of an attribute without any quotation marks. The attribute value may only contain letters (a-z and A-Z), digits (0-9), hyphens (ASCII decimal 45), periods (ASCII decimal 46), underscores (ASCII decimal 95), and colons (ASCII decimal 58). We recommend using quotation marks even when it is possible to eliminate them.

что в переводе на русский значит:

В некоторых случаях разработчики могут указывать значения атрибутов без каких бы то ни было кавычек. Это возможно если значение атрибута не содержит никаких других символов кроме английских букв (a-z и A-Z), цифр (0-9), дефисов (десятичный ASCII-код 45), точек (ASCII 46), символов подчеркивания (ASCII 95) и двоеточий (ASCII 58). Тем не менее, мы рекомендуем использовать кавычки в любом случае.

Стало быть, стандарт HTML рекомендует нам ставить эти кавычки везде, где только можно. Но, как видно, особо за исполнением рекомендаций никто не следит... Но есть и другой стандарт, который становится все стандартней и стандартней с каждым днем - XML. Рано или поздно он должен стать основным стандартом в Веб-строительстве. Так вот XML-парсеры как раз таки строго следят за соблюдением правил - и потому кавычки ставить попросту придётся.

Строго говоря, текущим стандартом W3C уже сейчас является не HTML, а XHTML, который использует синтаксис XML.

Ну и еще одна сторона "правильности" - она все же перекликается с "универсальностью": очень старые, или очень "правильные" браузеры могут и не понимать атрибуты, заданные без кавычек - вряд ли стоит обращать внимание на такие браузеры, но если уж придираться...

Итак: все самые распространенные сейчас браузеры прекрасно понимают значения атрибутов, не заключенные в кавычки - отсюда следует, что можно придерживаться либо указанных правил их простановки (alt="...", src="...", href="...") или вовсе их не ставить. Но не стоит забывать об XML на который возможно в скором времени придется пересаживаться самому и переводить все свои сайты - тогда вам может аукнуться решение обойтись без кавычек.

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

Вот и выбор - соответствие стандартам или некоторая экономия места и опрятный внешний вид кода? Окончательное решение как всегда за вами!

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

 Что еще почитать: Об атрибуте ALT


Вопрос:  Что должен сделать вебмастер, чтобы читателю было удобнее читать страницы в окнах с фреймами?

Ответ: Обычно этим вопросом не задаются вебмастера при изготовлении окон с фреймами. Пользователи же замечают, что, кликнув мышью на ссылке во фрейме навигации, фокус курсора в том фрейме и остаётся. Если читатель страницы постоянно пользуется мышью для прокрутки основного фрейма, то это незаметно, если же нажмёт кнопку PgDn или Down Arrow, то результат налицо - вместо прокрутки вызванной страницы он получает прокрутку фрейма навигации.

Известно, что автоматически фокус передаётся с помощью метода JavaScript focus(), применяемого к окну или фрейму. Следовательно, если его установить при каждой ссылке, задача будет решена:

<base target=main>
...
<a href="..." onclick="setTimeout('top.frames.main.focus()',499)">
  [ссылка для главного фрейма]
</a>
,где вместо "main" следует подставить имя главного фрейма, в котором происходит просмотр страниц многофреймового окна. Это имя указывается в теге <base target=main> и в тегах верхней, фреймовой страницы - <frame name=... target="main" ...> (предполагается, что читатель этой статьи знает, как его использовать).

Кроме простой передачи фокуса здесь установлена задержка передачи (100-500 мс) затем, чтобы она могла сработать в IE5.0 (возможно, такая же потребность и в IE 4.0). Так как после обработки прерывания не отменяется действие по клику (не стоит return false;), то передача фокуса не помешает выполнить обычный вызов ссылки (href="...").

Неудобство в том, что если ссылок много, то обработок прерываний надо описывать в каждой ссылке. Можно, конечно, сделать немного короче:

<script>function fo(){setTimeout('top.frames.main.focus()',499);}</script>
...
<a href="..." onclick="fo()">[ссылка для главного фрейма]</a>

Но для браузеров 4-х версий и выше удобнее использовать механизм перехвата прерываний (для NN) и всплывания событий (для IE). Тогда при создании страницы навигации не нужно заботиться о правильном написании каждой ссылки. Вся обработка передачи фокуса помещается до тела страницы:

<script language=javascript1.2><!--
function cli(ev){top.frames.main.focus();}
if(navigator.appName=='Netscape'){captureEvents(Event.CLICK); onClick=cli;}
//--></script>
</head>
<body bgcolor=... ... onclick="setTimeout('top.frames.main.focus();',499);">

Код, расположенный в <body>, работает в IE, а код в тегах <script> - в NN4. Надо сказать, что разработчики NN3-4 уже пытались частично решить эту задачу без джаваскрипта - можно заметить, что кликание по ссылкам во фрейме навигации, что интересно, не переводит фокус во фрейм навигации, это выполняется только при клике на пассивных элементах фрейма. Тем не менее, если уж фокус оказался во фрейме навигации, то перехват прерывания, обрабатываемый функцией cli(), помогает перенести его в главный фрейм.

 Примечания: Чтобы перевод фокуса работал в NN3 и Opera 3, обработчики прерываний надо будет писать в каждой ссылке или сделать функцию передачи фокуса, как указано в первых 2 примерах. Однако, сегодня (февраль 2002) ориентация на удобство работы с этими браузерами не актуальна, тем более, что пользователям таких браузеров часто приходится отключать JavaScript, чтобы он не создавал ошибок на страницах, не ориентированных на эти браузеры.

 Проверено на : IE 5.0, 5.5, 6.0; NN 3.01, 4.04, 4.76, 6.2; Mozilla 6; Opera 3.62, 4-6.


Valid HTML 4.0! Made with CSS
Все вопросы и пожелания сюда или сюда