Архивы: по дате | по разделам | по авторам

Мелкие пакости глобального кризиса

Архив
автор : АРТЕМИЙ ЛОМОВ    09.05.2000

Сегодня вряд ли кто возьмется оспаривать главенствующую роль HTML как основы Web, несмотря на то, что большие надежды в качестве претендента на это почетное звание в последнее время подает дуэт расширяемых языков XML и XSL, а некоторые сайты (см., например, www.metrius.com - сервер дизайнерской студии Metrius, когда-то носившей имя Verso) уже всецело базируются на технологии Macromedia Flash.


Нынешний HTML далеко ушел от своих ранних реализаций (речь идет об уровнях 1.0 и 2.0). Во многом благодаря стараниям Netscape и Microsoft в него за последние годы было внедрено огромное количество визуальных, оформительских возможностей, что, с одной стороны, казалось бы, хорошо - ведь с их появлением Web-дизайнеры смогли полнее реализовывать свои фантазии. Но с другой стороны, именно в этом и кроется главная причина кризиса языка HTML - его сегодняшняя сущность никак не вяжется с концепциями, заложенными Тимом Бернерсом-Ли и Дэниэлом Коноли десять лет назад. Дело в том, что на заре становления Web от него требовалось главным образом содержание, а форма была лишь второстепенным, утилитарным аспектом. Поэтому HTML изначально создавался как язык чисто логической разметки, предоставляя возможность браузеру по своему усмотрению определять внешний вид документа, и в этом смысле носил лишь декларативный, рекомендательный характер.

В итоге тот факт, что одна и та же Web-страница может выглядеть совершенно по-разному в различных браузерах, является абсолютно закономерным, тем не менее, сегодня дизайнеров и Web-мастеров это, понятно, не устраивает. Масла в огонь подливает еще и то, что в двух самых известных браузерах находят отражения идеи, зачастую идущие вразрез с официальными стандартами. Общеизвестно, что Internet Explorer и Netscape Navigator поддерживают свои собственные теги и атрибуты тегов HTML, которых нет ни в одном DTD, - это, очевидно, следствие конкуренции, когда каждый из производителей, стремясь заманить пользователей, "впихивает" в свой продукт все больше разнообразных "вкусностей" и "красивостей".

Несовместимостей у IE и NC хоть отбавляй. Взять хотя бы поддержку Explorer'ом сценариев на языке VBScript и технологии ActiveX на фоне полного отсутствия подобного в Netscape, или же поддержку браузером от AOL слоев, которых нет в майкрософтовском произведении. Рассматривать все возможные "разногласия" - дело неблагодарное, ибо новые версии браузеров сыплются нам на голову чуть ли не каждые полгода, а патчи к ним плодятся, как грибы после дождя. В этой статье мы посмотрим на проблему в другом ракурсе - сделаем акцент не на несовместимостях как таковых, а на глобальных аспектах, а также некоторых странностях либо откровенных багах в различных версиях IE и Netscape (только русскоязычных) и, разумеется, на том, как в каждом конкретном случае минимизировать побочный эффект.

Форматирование текста

Скажем сразу: при помощи HTML оформить текст Web-страницы с соблюдением всех типографских правил не удастся. Главная тому причина - невозможность использования некоторых сугубо необходимых символов, например кавычек-"елочек" или длинного тире, обусловленная различием их кодов в разных кодировках и тем, что даже предусмотренные в HTML мнемонические подстановки для специальных символов (такие как « » и —) многие версии браузеров соотносят с текущей кодировкой документа, а не с набором символов, принятым стандартом для языка HTML - Latin-1.

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



     Текст первого абзаца
      Текст второго абзаца



Если внешний вид текста не слишком важен, целесообразно принять существующие правила.

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

<p>
     Текст первого абзаца
<br>
     Текст второго абзаца
</p>

Теперь отметим странности конкретных браузеров. В Internet Explorer 5.0, к примеру, неразрывный пробел, следующий за знаком дефиса (а именно этот символ чаще всего используется в качестве тире), отнюдь не является неразрывным. Так, использование конструкции

AAA - BBB

не гарантирует, что BBB не будет перенесено на новую строку. Более того, если перенос будет сделан, перед BBB в начале строки появится отступ из одного пробела. Совет здесь только один: неразрывных пробелов справа от дефисов лучше вообще не ставить.

А в Netscape Navigator 4.06 почему-то возникают трудности с такой насущной вещью, как выравнивание абзацев по ширине. Код

Текст абзаца



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

Internet Explorer 4.0 по непонятной причине игнорирует alt-тексты тега , определяющего "горячие зоны" графических изображений, используемых в качестве карт ссылок (между прочим, атрибут alt является обязательным в соответствии со стандартом HTML). Если каким-либо alt-текстом был снабжен тег <img>, вставляющий в Web-страницу изображение, при наведении на тег курсора мыши отображается только этот текст. К сожалению, поделать с этим ничего нельзя.

Приграничная зона

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

Впрочем, в двух "главных" браузерах проблема легко решается: Internet Explorer поддерживает атрибуты topmargin, bottommargin, leftmargin и rightmargin тега , а Netscape Navigator - параметры marginwidth и marginheight того же тега, причем все они могут мирно сосуществовать в одном документе (поскольку вс§, что браузер не понимает, он игнорирует). При помощи этих атрибутов можно установить даже отрицательные величины отступов.

Если установить на странице нулевые поля рабочей области сверху и снизу, вставить в документ таблицу высотой 100% и заполнить одну из ячеек такой же высоты каким-нибудь простым графическим фоном, можно увидеть, что фон этот явно не дотягивает до нижней границы окошка Internet Explorer 4.0. Теперь нажимаем кнопку "Обновить" - и что вы думаете, все становится на свои места! Эффект имеет место, когда фоновый рисунок небольшой по высоте.

В Netscape Navigator даже кнопка "Обновить" не поможет - ячейка упорно не хочет занимать 100% высоты окна браузера. Можно, конечно, установить отрицательную величину полей атрибутом marginheight тега , но это повлечет появление нежелательной полосы прокрутки справа.

Рекомендую в этом случае сделать фоновый рисунок крупнее. В Explorer'е это помогает.

Премудрости табличного дизайна

В последнее время стало модным создавать Web-страницы с жестким табличным размещением. Это позволяет делать страницы постоянной ширины (в пикселах) независимо от разрешения экрана, что, в свою очередь, позволяет безболезненно заверстывать графику фиксированного размера. Ширина таблицы выбирается обычно равной 580-620 пикселам, дабы сайт можно было смотреть при экранном разрешении 640x480 без горизонтальной прокрутки.

Псевдотрехмерные рамки, предусмотренные в стандартном HTML и задаваемые атрибутом border тега <table>, выглядят весьма убого, что заставило Web-дизайнеров изобретать довольно запутанный прием создания рамок путем игры с атрибутом cellspacing того же тега, применяя различные цвета фона для всей таблицы в целом (он как раз и служит цветом рамки) и для ее ячеек в частности. Но в Netscape указанные цвета нельзя сделать отличными друг от друга: при использовании атрибута cellspacing остается "пустое" место, заполняемое фоном, принятым для всей страницы целиком. Но и тут выход был найден, правда, еще более заковыристый: нужный эффект достигается применением вложенных таблиц: сначала формируется таблица 1x1, заполняемая необходимым цветом фона, а уже в нее помещается основная таблица с заданным значением cellspacing. К примеру, вот такую конструкцию можно использовать для создания таблицы размером 3x3 ячейки с темно-красным (#990000) цветом рамки и бледно-желтым (#ffffcc) цветом фона:

<table bgcolor="#990000" width="600" cellspacing="0" cellpadding="0" border="0">
<tr>
<td>
<table width="600" cellspacing="1" cellpadding="0" border="0">
<tr align="center" bgcolor="#ffffcc">
<td>Строка 1, ячейка 1</td>
<td>Строка 1, ячейка 2</td>
<td>Строка 1, ячейка 3</td>
</tr>
<tr align="center" bgcolor="#ffffcc">
<td>Строка 2, ячейка 1</td>
<td>Строка 2, ячейка 2</td>
<td>Строка 2, ячейка 3</td>
</tr>
<tr align="center" bgcolor="#ffffcc">
<td>Строка 3, ячейка 1</td>
<td>Строка 3, ячейка 2</td>
<td>Строка 3, ячейка 3</td>
</tr>
</table>
</td>
</tr>
</table>

Разумеется, таким способом можно создавать и сложные таблицы с использованием атрибутов colspan и rowspan.

Локальные странности

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

Казалось бы, ну чем может отличаться локальная работа браузера от работы в "зоне Интернета" (терминология Microsoft)? Но и тут, оказывается, своя специфика.

Я, например, сохраняю свои HTML-страницы в кодировке KOI-8R, но системе Windows 98, в которой имею счастье работать, она чужда. В именах файлов своих Web-проектов я использую только латиницу, но каталог, где они размещены, называется по-русски. Если в Internet Explorer 4.0 попробовать при установленной кодировке KOI-8R перейти по ссылке c одной страницы просматриваемого сайта на другую, ничего не выйдет, хотя, если переключиться в CP-1251, ссылки работают нормально, разве что на экране нельзя ничего прочитать. При этом в HTML-коде страниц все ссылки относительные, названий конкретных папок там и близко нет! Все остальные браузеры - IE5 и Netscape - не глючат подобным образом.

Наверное, нужно вспомнить старые добрые времена всемогущей DOS и называть каталоги латинскими буквами... И чтоб не больше восьми символов, а то еще переполнение где-нибудь произойдет!

Netscape, однако, тоже не без странностей. Если попытаться выделить фрагмент текста на странице, открытой в этом браузере, скопировать его в буфер обмена, а затем вставить, скажем, в Word, то форматирование полученного "куска" будет соответствовать виду фрагмента не в окне Navigator'а, а в исходном HTML-документе. То есть, например, если Web-мастер имеет привычку набивать HTML не сплошным текстом, а периодически (по достижении края экрана) переходить на новую строку, да еще и делать в начале строк отступы из нескольких пробелов для удобочитаемости, все лишние знаки перекочуют туда, куда не следовало бы.

Это, так сказать, пища для размышлений. HTML с ростом версии становится все более запутанным, а ошибок и несовместимостей в браузерах со временем меньше не будет. В статье я изложил то, что у меня наболело. У кого есть чем поделиться, милости прошу на webmaster@lomov.agava.ru.



© ООО "Компьютерра-Онлайн", 1997-2021
При цитировании и использовании любых материалов ссылка на "Компьютерру" обязательна.