Дурная наследственность

Как уже упоминалось, главным достоинством таблиц является возможность упра­влять положением элементов с точностью до пиксела. Недостатки же этой технологии более разнообразны. Пре­жде всего, хотя содержимое ячеек можно позиционировать относительно друг друга и относительно точки привязки всей таблицы, положение этой последней относительно границ окна броузера, к сожалению, непостоянно и может «плавать» с заметной амплитудой в зависимости от теку­щего размера окна, базового кегля текста, величины полей (стр. 194) и проч.

Если сравнивать табличную верстку с возможностями, пре­доставляемыми CSS, то ближайшим аналогом таблицы будет относительное (relative), а не абсолютное позиционирова­ние. Если не учитывать тот факт, что таблица (как блочный элемент, стр. 240) всегда начинает собой новый абзац, то координаты размещенного в таблице элемента отсчиты­ваются именно от той позиции, которую он занимал бы в отсутствие таблицы и в которой теперь расположена точка привязки этой таблицы.

Конечно, чаще всего с помощью таблиц моделируется именно абсолютное позиционирование относительно гра­ниц окна: чтобы свести на нет влияние нетабличного материала, в таблицу заключается вся страница, так что мириться приходится только с неодинаковостью ее внеш­них полей (как я уже писал, величина этих полей точному контролю не поддается). При этом, однако, ощутимым ста­новится другой недостаток этой технологии: броузер может выводить на экран таблицу только тогда, когда ему известны габариты всех ячеек, — т. е. не раньше, чем из сети догру­зятся все изображения, тексты и HTML-код, составляющие таблицу. Результатом может стать раздражающая задержка с выводом информации на экран.

Сообщив броузеру заранее ширину и высоту всех размеща­емых в таблице изображений с помощью атрибутов height и width тега IMG, эту задержку можно сильно сократить —

но только в том случае, если размеры указаны, опять-таки, для всех без исключения изображений. Даже одна графическая вставка неизвестных броузеру размеров задержит вывод всей страницы до тех пор, пока не придет из сети начало соответствующего графического файла, по которому броузер сможет определить его габариты. Поэтому атрибуты height и width абсолютно обязательны для жесткого табличного дизайна. В академическом же стиле, наоборот их следует избегать — как потому, что атрибуты эти не входят в стандарт HTML 2.0, так и потому, что жесткое указание размеров графики иногда не позволяет прочесть alt-тексты графических вставок тем пользователям, ко­торые отключили в своих визуальных броузерах загрузку графики.

Тот факт, что в таблице положение любого элемента зависит от размещения всего остального материала, делает этот прием позиционирования весьма чувствительным к ошибкам разметки, так же как и к различиям (увы, су­ществующим) между алгоритмами верстки таблиц в визуальных броузерах. Конечно, в этой области совместимости гораздо больше, чем, к приме­ру, в CSS, — вполне естественно, что производители броузеров обращают особое внимание на механизм, ответственный за форматирование подавля­ющего большинства страниц в Интернете. И все же нужно отдавать себе отчет в том, что этот прием (по-английски его бы стоило назвать «trick» или даже «hack») по своей логической обоснованности очень напоминает строительство дома из пакетов из-под сока.

Двойное дно

Еще один недостаток табличного позици­онирования — невозможность наложения элементов друг на друга (иными словами, расстояние между двумя объектами не может быть отрицательным). Изобретательные дизайне­ры и здесь нашли выход из положения: неповторяющиеся фоновые изображения (стр. 283) становятся в их компози­циях самостоятельным слоем, содержимое которого так или иначе соотносится с элементами переднего плана. К сожа­лению (стр. 194), совмещения с точностью до пиксела при этом достигнуть не удается; однако и то, что есть, позволяет добиться интересных результатов (пример 1). Прием этот вполне допустим в тех случаях, когда он пре­следует чисто художественные цели. Иногда, однако, в фон выносится часть значимой информации страницы, в неко­торых случаях — текст и даже ссылки, реализуемые с по­мощью прозрачных графических вставок, залинкованных и наложенных на нужные области фона. Такое трюкачество одобрить уже нельзя — «выпавшая на дно» информация безвозвратно теряется для невизуальных броузеров и ав­томатических сборщиков информации: ведь даже если бы у фонового изображения был свой alt-текст, его место

в линейном текстовом эквиваленте страницы определить было бы невозможно.

Белое место

Возможности табличной верстки были бы сильно ограничены, если бы дизайнер не мог управлять расстоянием между содержимым ячеек. Интервалы вокруг всех ячеек одновременно можно менять с помощью атрибутов cellspacing и cellpadding тега TABLE (чаще всего оба эти атрибута обнуляются). Но чтобы раздвинуть всего некое заранее заданное расстояние отдельно взятую пару объектов, между ними нужно поставить какую-то распорку.

Общепринятый способ изготовления распорок (тот самый, изобретенный Сигелем) основан на том, что, если указан­ные в атрибутах width и height размеры изображения не совпадают с его естественными размерами (записанными в самом GIF- или JPEG-файле), броузер обязан масштаби­ровать это изображение до размеров, указанных в HTML. Достаточно, таким образом, взять полностью прозрачный GIF-файл минимальных размеров — 1 на 1 пиксел — и при­писать ему требуемую ширину (не забыв указать height=l, чтобы подавить пропорциональное увеличение высоты) или, соответственно, высоту (не забыв width=l) — и мы полу­чим невидимую графическую вставку требуемых размеров, вполне годящуюся на роль распорки.

Достаточно иметь единственную копию такого однопиксельного GIF'a на весь сайт; HTML-файлы могут содержать сколько угодно не мешающих друг другу ссылок на эту копию с указанием разных размеров. Важно также не забы­вать указывать alt="" при всех таких распорках (как и при любой другой служебной графике), чтобы не раздражать «исподним» визуального форматирования тех, кому нужен лишь текстовый образ вашей страницы.

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

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

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

Для горизонтальной раздвижки символов текста лучше пользоваться не графическими распорками, а неразрывае­мым пробелом. Последовательность символов   в любом месте документа (в том числе, кстати, и в заглавии, стр. 199) воспроизводится броузером как одиночный текстовый про­бел, который, в отличие от обычных пробелов, не сливается с соседними пробелами, не исчезает в конце строки и в на­чале абзаца, а главное — не позволяет броузеру вставить перенос строки между символами, вплотную к которым он стоит (отсюда и его название — «неразрываемый пробел» не позволяет разорвать строку).

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

Фэйсом об тэйбл

Каждый из броузеров имеет свой довольно сложный алгоритм выбора размеров ячеек и раз­мещения материала в них в зависимости от натуральных размеров материала в ячейках, «рекомендованных» размеров ячеек (атрибуты height и width тега TD) и наличия неко­торых особых случаев вроде групп ячеек, объединенных по горизонтали или вертикали (атрибуты colspan и rowspan того же тега). Расследование нюансов, странностей и просто

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

• Не полагайтесь на «рекомендательные» размеры для от­дельных ячеек; если вам нужно, чтобы ячейка имела определенную ширину и высоту, вставьте в нее соот­ветствующих размеров распорку. Без атрибута width в теге TD нельзя обойтись только тогда, когда нужно ограничить ширину ячейки, содержащей текст (причем I результат будет соответствовать ожиданиям, только если текста этого хватает при данной ширине хотя бы на одну полную строку).

Имеет смысл зафиксировать также общую ширину са­мой внешней таблицы, определяющей габариты всей страницы: атрибуту width соответствующего тега TABLE обычно присваивается значение 100% для «резинового» и около 580 пикселов для жесткого табличного дизайна (стр. 193). Более того, без жесткого (в пикселах) зада­ния ширины в теге TABLE таблица, содержащая слитые по горизонтали ячейки, иногда совершенно необъясни­мым образом «распухает», так что ее ширина превосходит сумму ширин распорок во всех ячейках.

• При необходимости можно сращивать несколько ячеек по горизонтали (атрибут colspan тега TD), но только в том случае, если ширины участвующих в операции столбцов жестко заданы распорками в других ячейках; если же, наоборот, жестко задана только ширина объ­единенной ячейки, на правильное распределение этой ширины между столбцами рассчитывать не приходится. По этой же причине объединять ячейки по вертикали не рекомендуется вообще — лучше пользоваться вложенны­ми таблицами (рис. 52).

• В сложных случаях, когда таблица упорно не хочет вести себя как задумано, можно подсветить границы ячеек, заменив в заголовке border=0 на border=l, — удоб­ное средство отладки, аналогичное временной замене невидимых распорок на видимые (см. выше). Учтите, что появляющаяся рамка добавляет по одному пикселу ширины и высоты на каждую ячейку, так что общие габариты таблицы изменяются.

Рис. 52

Условия задачи: ячейка А должна иметь пе­ременную высоту, так как со­держит текст; ячейка В со­держит графическую вставку и должна точно соответство­вать ей по размерам; высота ячейки С, следовательно, долж­на быть равна разности высот ячеек А и В. Попытка решить задачу с помощью rowspan=2 в ячейке А к успеху не при­водит; как ни старайся, ячей­ка В выходит выше, чем надо, а С упорно не дотягивает до нужной высоты Жесткая рас­порка в С делу не поможет, так как искомая высота С за­висит от А и, следовательно, есть величина непостоянная; не помогает и установка фикси­рованной величины height для ячейки В. Можно попробовать вообще отказаться от разделе­ния ячеек В и С, слив их в одну и отогнав изображение наверх с помощью valign=top; если, однако, вам нужна разлиновка или же другой фоновый цвет в В, не обойтись без вложенной одноячеечной таблицы вокруг изображения. (Те же проблемы встают, хотя и реже, и при го­ризонтальном расположении — ячейки чаще имеют переменную высоту, чем ширину.)

Поиск по сайту: