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

Русский интернет (уже наконец) вовсю осваивает "дизайн через CSS", но многие все равно не понимают, почему именно надо дизайнить так, а не по-старому, через таблицы. Руководствуются, как часто бывает, тем, что это модно. А многие, в общем-то, и не спешат уходить от таблиц, не считая, что в них есть что-то плохое. Я собираюсь написать длинный цикл статей о веб-разработке новыми методами. Главная моя цель - структурировать на русском языке те знания, которых полно в разрозненном виде по всей сети.

В этой первой статье я постараюсь рассказать о самой сути современных стандартов разметки веб-страниц и о целях, которые преследовались при их написании. То есть, эта статья о том, "что это" и "зачем это", а не "как это".

Понятия

Для начала я хочу определиться с понятием "табличная верстка". Если вы начинали заниматься веб-разработкой в 90-е годы, то знаете, что верстать страницу можно было двумя способами: потоком или таблицами. Первый способ - это попросту отсутствие всякой верстки, когда один за другим сверху вниз идут заголовки и абзацы. А таблицы - это когда вся страница представляется в виде сетки, в которую в нужные места уже вставляются текст, картинки и другие таблицы. Причем, сама по себе структура этих <table>, <tr>, <td> позволяет создать сетку любой сложности.

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

Вот это:

<table width="100%" background="/i/bg_top.jpg" style="background-repeat: no-repeat;" border="0" cellspacing="0" cellpadding="0">
<tr>
  <td width="75%" valign="bottom">
    <img src="/i/_.gif" width="1" height="40" border="0" alt=""><br>
    <table border="0" cellspacing="0" cellpadding="0"><tr valign="top">
      <td><img src="/i/_.gif" width="25" height="1" border="0" alt=""><br></td>
      <td><a href="/"><img src="/i/logo.gif" width="213" height="90" border="0" alt=""></a><br></td>
      <td><img src="/i/slogan.gif" width="124" height="90" border="0" alt=""><br></td>
    </tr></table>
  </td>

  <td bgcolor="#ffffff" background=" "><img src="/i/_.gif" width="1" height="1" border="0" alt=""><br></td>
  <td width="25%" bgcolor="#0C2E82" background=" ">
    <table width="100%" border="0" cellspacing="2" cellpadding="2"><tr valign="top">
      <td align="center">
        <table width="90%" cellpadding="0" cellspacing="1" border="0">
        <tr valign="top">
          <td colspan="3"><span class="white small"><b>Персональный кабинет</b></span></td>
        </tr>

        <tr valign="top">
          <td><span class="white small">логин</span></td>
          <td><span class="white small">пароль</span></td>
          <td>&nbsp;</td>
        </tr>

... я и называю табличной версткой.

Проблема

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

Много кода

Табличная верстка занимает неприлично много места. Страница более-менее хорошо упакованного сайта легко может занимать и 80КБ, и 120КБ... Это без картинок. Все это выливается не только в медленную загрузку и отрисовку, но и в немаленькие деньги за трафик как для сайтов, так и для клиентов. Ведь если картинки хотя бы кешируются браузером, то всю верстку для каждой новой страницы он неминуемо грузит заново, как бы похожа на предыдущую та ни была (кто тут сказал слово "фрейм"? не надо...).

Трудная правка

Табличную верстку трудно править вручную. Несмотря на большое развитие визуальных редакторов кода, от этой проблемы они не спасают. Если ваш сайт - динамический, значит он собирается из кусков шаблонов. И значит шаблоны будут состоять из фрагментов таблиц. Если вам приходилось когда-нибудь смотреть в такой фрагмент и думать, относится ли вот эта </td> к вашей части или закрывает ячейку из верхней части шаблона, вы понимаете, о чем я говорю... Заодно прошу прощения, если причинил кому-то боль этими темными воспоминаниями.

Негибкий дизайн в разработке

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

Индексация поисковиками

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

Совместимость с устройствами

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

Веб придумывался не только для этого. Одной из идей была повсеместность, чтобы веб был доступен на бумаге, на мобильном телефоне, PDA, текстовом терминале, мог быть начитан голосом. Все это очень трудно с таблицами. Я бы даже сказал - невозможно, потому что искусственного интеллекта, способного отличить ячейку с навигацией от ячейки с основным содержимым, у нас пока еще так и нет.

Многие мне возражают, что, мол, кому вообще нужны эти 0,000...% пользователей, пользующиеся этой экзотикой? Я думаю, это во многом путание причины и следствия: потому и 0,000...%, что нет сайтов, которыми можно нормально пользоваться ненастольными средствами. Думаю, если эта ситуация будет меняться так, как сейчас меняется, мы уже скоро застанем время, когда веб на PDA будет казаться обычным делом.

Ну вот. Кажется, достаточно :-).

Что взамен

Взамен W3C - организация, занимающаяся стандартами для веба - предлагает нам две спецификации: HTML 4 и CSS 2. Я ни в коем случае не предлагаю вам их читать сейчас. Не вздумайте. Это точные детализированные справочники, и чтение их в качестве художественного произведения ничего, кроме головной боли и разочарования в жизненных идеалах, не принесет. Тем более, самой сути, зачем они обе существуют, там, в общем-то, и не объяснено.

Я и ссылки-то поставил всего-навсего потому, что должны же быть ссылки на спецификации в статье про HTML и CSS!

А суть состоит в том, что нам предлагается разделить "компот" и "мух" - содержимое и оформление страниц, и пользоваться для того и другого разными средствами. HTML - для описания содержимого, его структуры, а CSS - для оформления и верстки.

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

HTML 4 не является языком оформления веб-страниц.

Он является языком логической разметки страниц. Раньше, создавая HTML-документ, вы думали о том, что этот заголовок будет сделан жирной верданой золотистого цвета и отцентрован посредине большой темно-зеленой ячейки. Теперь все это предлагается выкинуть, и написать просто: <h1>Заголовок страницы</h1>. Выкидывается все, связанное с форматированием: шрифты, бордюры таблиц, цвет ссылок, отступы у <body>, фоны ячеек таблиц, центрирование...

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

<div id=header>
  <h1>Компания</h1>
  <small>Кульный девиз</small>
</div>

<div id=main>
  <p>Компания была основана...
</div>

<div id=sidebar>
  <ul>
    <li><a href="">Продукты</a></li>
    <li><a href="">Клиенты</a></li>
    <li><a href="">Контакты</a></li>
  </ul>
</div>

Фактически, то, что вы делаете теперь в HTML - это некая карта страницы, не более того. Структура. Даже вот тот <small> в заголовке означает не "<font size=1>", а "второстепенная по значению фраза внутри шапки, подзаголовок".

А вот уже дальше вы берете в руки CSS - язык стилей - и начинаете им раскладывать и оформлять всю эту структуру на странице.

Нет, CSS - это не смешной новый синтаксис, который придумали для того, чтобы убрать подчеркивания ссылок.

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

Что в этом хорошего

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

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

Общий стиль для всего сайта

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

Маленький размер страниц

Несмотря на то, что все равно в файлах суммарно остается и содержимое, и оформление, сам синтаксис CSS ведет к меньшему размеру файлов. Например, если вы (или ваш Dreamweaver) для каждой ссылки в коде раньше писали:

<font face="Verdana, Arial, Sans-Serif" color="#880000" size="2"><b><a href=""></a></b></font>

то теперь вы напишите в HTML:

<a href=""></a>

и в CSS:

a {Font:Bold 10pt Verdana, Arial; Color:#880000;}

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

Даг Бауман как-то провел эксперимент, перевел заглавную страницу сайта Microsoft на CSS, получил уменьшение объема с 40КБ до 15КБ.

Кеширование оформления

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

К этому стоит добавить, что многие картинки, которые раньше делались тегами <img> при дизайне с использованием стилей переходят тоже в правила CSS'ного файла. И большинство браузеров кеширует эти картинки агрессивней, чем те, которые сидят в HTML: он за ними даже не ходит на сервер проверять, изменились ли они, если не изменился стилевой файл.

Свободное расположение содержимого в файле

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

Удобное структурирование дизайна

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

Легче скриптовать

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

Легче думать

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

Разные представления

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

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

Добро пожаловать в реальность

Думаю, к этому моменту наиболее циничныереалистично мыслящие читатели уже давно мне не верят. Слишком уж все как-то радужно выходит. И вы правы. В реальности все, конечно, слегка по-другому.

Первое, что сильно портит малину - это реализация всех этих стандартов в выпускающихся браузерах. Подумайте, спецификация CSS 2 была написана в 1998 году, а реальные крупные сайты, построенные с его использованием, стали появлятся что-то где-то в 2002-2003 годах. Это от того, что примерно только в это время браузеры с новыми движками, вокруг которых крутились прогрессивно мыслящие разработчики, начали переходить из стадии "оно компилируется!" в стадию "можно показывать людям". Однако и сейчас, что в Gecko-браузерах (Firefox и другие), что в Opera, что в Safari и Konqueror, полно ошибок в реализации CSS. Не говоря уж об IE, ошибки которого никто не правил уже 4 года. А это значит, что вам, как веб-разработчику, который желает всем этим заниматься, придется привыкать не только к новой парадигме (!), что само по себе трудно, но и учить новые отвратительные хаки, как заставить тот или иной (точнее, по большей части - только тот) браузер работать вменяемо.

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


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

Итак, если я вас заинтересовал - ждите новых статей в категории Web. А также - оставляйте свои комментарии.


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

Комментарии: 84 (feed)

  1. Денис Перехрест

    отличная статья!
    все это мы конечно проходили года два назад, но новичкам будет полезно почитать...

  2. Rad

    Всё правильно. CSS - правильное направление. У таблиц другие задачи.

    Вот если бы ещё те кто участвует в стандартизации действительно в ней участвовали, ну в смысле на полную, и не выдумывали своих интерпретаций, то жить стало бы легче, жить стало бы веселей :)

    А то вся красота/лёгкость кодинга с CSS сводится на нет этими хаками, подводками.

    ps: насчёт принятия цээсэса осликом у меня был страшный сон ;)

  3. huNTer

    А как трудно переучиваться с табличной верстки на div-ную! Так и хочется вставить табличку-другую. Сам до сих пор свой сайт не переверстал :(

  4. Иван Сагалаев

    Вот об этом переучивании я собираюсь написать отдельно :-). Это "изменение сознания" действительно способно убить все желание этим заниматься.

  5. [...] “Компот” и “мухи” веб-разработки В этой статье описываются преимущества CSS-вёрс [...]

  6. agat

    Тут меня недавно спрашивали как сделать «модные распорки» на div'ах… думал убью :)

  7. Юрий

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

  8. brahmann

    Очень полезная статья для новичков! ... спасибо, многое прояснилось.. :) удачи пиши.

  9. Roy

    Основная проблема не в лени, а в браузерах!
    переучиться легко, тк сложности в css нет, он даже легче html-ля!

  10. Kaban

    Очень рад, что поздно стал учить хтмл. Таблицы запарили. Буду учить дивы.

  11. Роман

    Зачастую дизайнеры рисуют такОе, что иногда призадумаешься, возможна ли верстка в HTML4/CSS2. Хотелось бы побольше примеров нагруженных дизайнов.

    Статья хорошая, согласен во всем!

  12. NoNamer

    А кто сказал что нельзя совчестить CSS с таблицами? Так ли уж нужны эти DIV'ы? Ну в некоторых случая нужны, не спорю... но их (случаев) так мало... =)

  13. Иван Сагалаев

    Речь, прежде всего, не о том, использовать DIV или TABLE. Это одно из самых больших заблуждений многих, кто начал знакомиться с CSS'ным дизайном. И об этом у меня будет отдельная статья. Просто, планов, как обычно, больше, чем времени :-)

  14. Slastik

    А как насчет того что некоторые ярые поклонники ЦСС, даже обычные таблицы верстают дивами, разумно ли это?

  15. Иван Сагалаев

    Это кошмарно :-). Особенно мне нравятся вещи типа "бестабличный календарь".

    Я, отчасти, и начал всю эту бодягу, потому что очень уж много поклонников, которые, не разобравшись, начинают делать, а потом говорят везде,что, мол, видели мы этот ваш CSS, он ничем не лучше таблиц. Вот я и попытаюсь разъяснить, что и куда.

  16. aaoi

    Хороший текст. Спасибо. Дам почитать дизайнерам. А то у меня сейчас просто кошмар с

  17. aaoi

    </td> =)

  18. ganges

    "А то вся красота/лёгкость кодинга с CSS сводится на нет этими хаками, подводками."

    ИМХО, это тоже преувеличение. Если отказаться (ну для начала хотя бы) от пиксельной точности (Мейер много раз повторял, что CSS, в общем-то язык описаний не пиксельной точности) то этими "хаками" вообще пользоваться не придется.

    Во-вторых, не такие уж они "страшные" эти "хаки", really :)

    например body {text-align:center;}

    или

    html>body.homepage #blah {property:value;}

    - достаточно простой код, а считается "хаком". Есть, конечно и более сложные последовательности символов из * и / так называемые фильтры, но их достаточно один раз запомнить, что у вас однозначно получится, потому что такой фильтр решить может серьезную проблему например с ИЕ 5.0Win, - это запоминается :)

    А что касается самой "парадигмы".... Времена, когда верстал таблицами я вспоминаю с содроганием. Это что-то похожее на ночной кошмар, в котором завтра - диплом, а он не написан еще. И вставать надо - писать, вперед, tr td tr td tr td, как дятел - ужас тихий.

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

    Контроль такого уровня и глобальности невозможно достичь при использовании метода табличной верстки.

  19. GVA

    А я опять не согласен... с одним абзацем. :) Тем, который называется «Свободное расположение содержимого в файле». Там написано, что сначала загружается контент, а не навигация и это есть гуд.

    Давайте смоделируем ситуацию. Сижу на диа-лапе (это слово я сам придумал :), идеальная скорость 56К, реальная - 49К, да ещё разделить на 3 - 4 (количество одновременных коннектов в разные места). Удручающая ситуация, не правда ли? Задумываюсь о чём-то более скоростном за те же деньги - иду, соответственно на сайт своего любимого ISP - http://www.dn.farlep.net/. И наблюдаю такую картину: загружается контент (масса новостей техподдержки, которые меня не интересуют), загружается реклама, новостная колонка, и только в последнюю очередь - меню. Это всё, как вы наверное догадались, происходит не моментально. Не верите? Попробуйте сами!

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

  20. Иван Сагалаев

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

  21. Лобанов Леонид

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

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

    Зачастую дизайнеры рисуют такОе, что иногда призадумаешься, возможна ли верстка в HTML4/CSS2.
    Вот-вот. В этом-то и минус. А даже если можно сверстать в CSS, как только ты вложил третий уровень DIV, можешь забывать про "отделение контента от оформления". Потому что эта вложенность уже неотьемлимая часть дизайна.

  22. Лобанов Леонид

    А вот и ещё по поводу CSS. Посмотрите дизайн этой страницы в Opera. Поля для воода имени, мыла, сайта улезли вверх.

  23. Mic

    Лови!
    CSS Zen Garden

    Фишка в том, что на этом сайте выложена туча разных CSS дизайнов одной и той же HTML страницы. Народ там изголяется как может.
    По этому же сайту выпущена книжка - офигенная.

    Вот тебе еще один пример ;)
    http://www.dotBookmark.com

  24. Mic

    Oops!

    My comment shuld be related to the post:

    "Роман: 19.06.05 13:24
    Зачастую дизайнеры рисуют такОе, что иногда призадумаешься, возможна ли верстка в HTML4/CSS2. Хотелось бы побольше примеров нагруженных дизайнов."

  25. BOLK

    Кстати, есть JavaScript-набор "IE7" (не путать с бетой браузера, которая недавно вышла), который позволяет использовать в IE CSS2.

  26. Сергей

    Наверное, Иван, вы такой сторонник div'ов, потому что используете WP :) (кстати у вас отсутствует закрывающие head, body и html).

  27. Иван Сагалаев

    Странная связь :-). На самом деле нет. Заниматься CSS-версткой я стал куда раньше, чем открыл блог, даже написал об этом в первом посте. А WP я выбрал совсем не из-за шаблона с div'ами. По большей части потому, что о нем очень хорошо отзывались блоггеры, которых я читал в то время. И не жалею.

    Насчет тегов. Да у head и body (да и у многих других) закрывающие теги в HTML опциональны.

  28. Женя

    Считаю что это одна из самых приятных статей которые я читал за последнее время по дизайну. Искал именно такую статью, так как уже давно стал замечать что верстальщики все чаще используют div в коде. Нашел эту статью после вчерашних ковыряний таблиц. td tr td tr td tr...Под конец так достало, что лег спать. Так и не разместил все на странице так, как хотелось. Запутался. Так что теперь буду разбираться в CSS более тщательно, а не просто для задания стиля для элементов <a>...</a>

  29. Sniff

    Веб придумывался не только для этого. Одной из идей была повсеместность, чтобы веб был доступен на бумаге, на мобильном телефоне, PDA, текстовом терминале, мог быть начитан голосом. Все это очень трудно с таблицами.

    Вот уж не понимаю, как это CSS дизайн поможет пользователям с текстовыми терминалами и голосовыми браузерами (это вообще глупость полная). Да и для мобильных утройств, и для ПДА. Идея в том, чтобы сделать для них разные css, и везде все будет отображаться корректно? Ну это ж понятно, что неправда - ибо окажется тут же, что проблема не только в css файле, а еще и в самом html - для мобильных надо будет и графику другого размера готовить, и дизайн в широком смысле менять (одними параметрами css не обойдешься).

    Пролема скорее относится к разделению данных и их представления, а значит, ее решение - скорее XML\XSLT - вот что ДЕЙСТВИТЕЛЬНО может решить эти проблемы. А вовсе не CSS, не так ли?

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

    А дивы с дизайном, он, наверное, прекрасно отличает от дивов с контентом? :)

  30. Иван Сагалаев

    Вот уж не понимаю, как это CSS дизайн поможет пользователям с текстовыми терминалами и голосовыми браузерами (это вообще глупость полная).
    Да и для мобильных утройств, и для ПДА.

    Одна из возможностей CSS - определять разные стили для разных устройств (http://www.w3.org/TR/CSS21/media.html#media-types)

    А вот свойства конкретно для голоса: http://www.w3.org/TR/CSS21/aural.html

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

    Подготовка графики другого размера большой частью тоже относится в CSS, так как именно туда относится вся оформительская графика.

    Кардинальная смена дизайна - тоже не проблема. Опера со своим Small Screen Rendering и PDAize Даниеля Глазмана адаптируют произвольные сайты под мобильные экраны, даже те сайты, которые для этого не предназначены. А уж сам автор может сделать с дизайном все, что угодно.

    Пожалуйста, не стоит думать, что CSS - это для цветов и рамок. CSS'ом можно делать полностью весь дизайн. Читайте мой "Учебник", там через пару статей я собираюсь сделать большой практический пример.

    Пролема скорее относится к разделению данных и их представления, а значит, ее решение - скорее XML\XSLT - вот что ДЕЙСТВИТЕЛЬНО может решить эти проблемы. А вовсе не CSS, не так ли?

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

    • не таскать оформление по сети, а загрузить его один раз
    • изменять оформление отдельно на клиенте

    А дивы с дизайном, он, наверное, прекрасно отличает от дивов с контентом? :)

    Смысл в том, что нет такого - "дивы с дизайном". Все, что есть в HTML - контент.

  31. Sniff

    Одна из возможностей CSS - определять разные стили для разных устройств (http://www.w3.org/TR/CSS21/media.html#media-types)

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

    Кардинальная смена дизайна - тоже не проблема. Опера со своим Small Screen Rendering и PDAize Даниеля Глазмана адаптируют произвольные сайты под мобильные экраны, даже те сайты, которые для этого не предназначены. А уж сам автор может сделать с дизайном все, что угодно.

    Так опера адаптирует, или css управляет этим?
    Опера адаптирует, но согласись - это убыточный путь. Невозможно автоматически эти вещи правильно адаптировать - необходим человеческий фактор, человек должен как-то задавть разницу для рендеринга на мобильном устройстве.

    Пожалуйста, не стоит думать, что CSS - это для цветов и рамок. CSS’ом можно делать полностью весь дизайн. Читайте мой “Учебник”, там через пару статей я собираюсь сделать большой практический пример

    Я и не думаю.
    Однако я также далек от мысли, что в html-е "чистый контент" а в css - "чистый дизайн".
    Или я ошибаюсь? Действительно ли меняя ТОЛЬКО css можно добиться АБСОЛЮТНО любого представления данных из html? И не окажется ли так, что если это возможно, то для этого html будет выглядть в точности как XML для обработки XSLT?

    Не совсем. CSS как раз специально придумывался для разделения данных и представления.

    Это действительно так? Думаю, что ДАННЫЕ они не хотело отделять от представления. Скорее задать варианты представления для данной разметки. Хотя, после эволюции в css2 и далее - возможно. Но что-то мне кажется, что изначально у них такой цели не было. А есть какие-то подтверждения этой идеи Мне казалось, что css это некое отражение реляционной модели - вывесли повторяющиеся вещи в отдельную сущность, а подставлять только идентификатор, для у меньшения объема и бОльшей структурированности.
    Ну, и навскидку могу привести еще два таких решения на другом уровне. Взять ту же связку XML\XSLT - она для чего-то другого предназначена?
    В чем разница? Накладывать дизайн на контент на стороне клиента? Вместо стороны сервера? Все равно надо будет дать серверу понять для какого устройсква отдавать css.

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

    • не таскать оформление по сети, а загрузить его один раз
    • изменять оформление отдельно на клиенте

    Почему же минус. Я же не говорю - отдавать все в одном файле. XSLT вовсе не исключает использование css для всех реляционных выгод. XSLT просто позволяет не только подключить другой css в зависимости от ситуации, но и сменить состав и разметку контента для последующей обработки css.
    Не таскать с собой - это исключительно отражение реляционной модели. А вовсе не отделение дизайна от контента. То есть, это приходится сделать, но конечному пользователю от этого ни холодно, ни жарко - разделение есть благо для программиста.
    А вот насчет целесообразности изменять оформление отдельно на клиенте готов поспорить. То есть, это, конечно же, возможно, но я не думаю, что это актуальная нужна пользователей, и этой фичей пользуется более чем 0.1% всех пользователей. Так что это слабый аргумент, имхо.

    Вооюще мне это слегка напоминает возню с русскими кодировками году в 98-99. Когда на каждом сайте были линки alt koi-8 win mac - сервер отдавал контент в другой кодировке. Там была ситуация, когда программисты считали, что это их проблема, и админы тоже так считали, и ввели например в ответы сервера указание кодировки, на некоторых проксях происходила дополнительная перекодировка, и так далее. И все тянули одеяло на себя - апач имел модуль по перекодировке отдаваемого контента, программисты реализовывали все перекодировки своими силами, страдали пользователи, которые, порой вообще ничего не могли прочитать (как и спочтой то же самое было - дикий барлак с кодировками и автоматическими перекодировками на шлюзах)
    Время все расставило на свои места - метатеги дают понять браузеру какой кодировкой пользоваться, веб-сервера не вмешиваются.
    Вот и с разделением на дизайн-контент все технологии сейчас наперебой предлагают свои средства по разделению дизайна и данных. И мне (чисто субъективно) кажется, что в конце концов это разделение ляжет вовсе не на css.
    А истина, как обычно, где-то рядом...

  32. Иван Сагалаев

    Но в реальности дял разных устройст будет меняться не столько дизайн, сколько контент. Например, концепция управления и навигации при просмотре сайта на мобиле - она же совершенно другая, вообще ничего общего с ПК-шными браузерами, считай, не имеет.
    Впору ли только css-ами обойтись?

    Ну почему совершенно другая... Навигационное меню - оно и есть меню. А вот как его расположить, какого размера сделать и куда засунуть, это как раз CSS'у под силу.

    Да и дело в том, что потребность менять контент прелести CSS не отменяет. CSS отделяет представление от контента. С этого момента менять то и другое по отдельности становится проще. А уж что именно надо менять зависит от ситуации.

    Так опера адаптирует, или css управляет этим?
    Опера адаптирует, но согласись - это убыточный путь.

    Не... Это я о том, что внешним CSS можно даже переформировать чужой сайт. Именно это делает тот extension, на который я сослался вторым. Как точно работает Опера - не знаю, но подозреваю, что тоже CSS'ом с добавлением каких-то скриптовых решений.

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

    Действительно ли меняя ТОЛЬКО css можно добиться АБСОЛЮТНО любого представления данных из html?

    Абсолютно - конечно нельзя :-). Всесильных технологий еще не существует. Но с CSS'ом можно делать действительно очень много. С примерами опять же - будут, сейчас руки не доходят :-)

    И не окажется ли так, что если это возможно, то для этого html будет выглядть в точности как XML для обработки XSLT?

    Скорее всего так и окажется. Правильный HTML (или XHTML), как я и пишу в статье, должен представлять собой просто структуру сайта. И да, на него можно будет при этом натравить и XSLT, в том числе. Но так это ж хорошо! Это не взаимоисключающие технологии. XSLT - серверная часть, пусть она генерит HTML из частного XML'а, или если на сервере и так все лежит в XHTML, то пусть, скажем, генерит из него RSS. Я же касаюсь именно части, когда HTML приходит на клиент. Там CSS незаменим.

    Это действительно так? Думаю, что ДАННЫЕ они не хотело отделять от представления. Скорее задать варианты представления для данной разметки.

    Разметка - это и есть описание структуры данных. Я не вижу противоречий...

    Отделение содержимого от представления - это вообще основная идея HTML4 и CSS с самого начала. Сложно сейчас найти конкретную ссылку по этому поводу, но участники рабочей группы CSS зудят об этом по всем местам уже много лет :-)

    Вооюще мне это слегка напоминает возню с русскими кодировками году в 98-99. Когда на каждом сайте были линки alt koi-8 win mac

    :-). Мне как раз текущие реалии это напоминают :-). Все эти кнопочки "версия для PDA", "версия для печати" - это же то же самое. CSS это все красиво отменяет. Стили для PDA и для печати прописываются в заголовке странице и браузер тихо применяет то, что нужно, не напрягая пользователя.

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

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

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

  33. Sniff

    ОК, я не спорю - css это очень круто и правильно, но вот представим себе такую ситуацию.
    Есть сайт, который надо затачивать и под ПК и под мобилы.
    С шрифтами и графикой мне, допустим, все понятно.
    Но вот наприме layout. Пусть у нас две колонки, в левой навигация, в правой контент какой-то. Это для ПК. А для мобилы я хочу, чтобы навигация была снизу после контента.
    То есть, что меня смущает. Насколько я понимаю (буду рад ошибиться), но есть как бы приоритетное направление (слева направо, сверху вниз) вдоль которого удобно размещать элементы контента, следующие в этом порядке.
    То есть, вопрос такой - если блоки контента мне надо будет разместить в порядке, не совпадающем с тем, в котором они расположены в html - не будет ли css слишком уж офигенно сложным для реализации такого? Как это вообще прийдется в css реализовывать? Через z-index?

  34. Иван Сагалаев

    Есть у CSS несколько средств для раскладки (четыре, по большому счету). 3 из них - прямой поток, float'ы и так называемые CSS-таблицы действительно зависят от порядке элементов в HTML. Четвертый - абсолютное позиционирование, и он как раз от порядка совершенно не зависит.

    Я их потихоньку здесь описываю. Уже написал про позиционирование и прямой поток, про float'ы пишу сейчас. И дальше буду продолжать.

    В качестве примера могу привести меню в этом самом блоге. То, которое прилеплено к левому верхнему краю. Если посмотреть в HTML, то оно расположено после основного контента и после сайдбара, перед самым footer'ом. CSS'а для этого потребовалось совсем немного:

    #menu {   Position:Absolute; Right:0; Top:0;   Margin:0; Padding:0; }
    
    #menu LI {  
      List-Style:None;  
      Float:Left;  
      Margin-Left:-13px;  
    }
    
    #menu A {  
      Text-Decoration:None;  
      Display:Block;  
    }
    
    #menu A,  
    #menu .current {  
      Padding:0.25em 26px 0.5em 26px;  
    }
    

    Кроме того, с конкретными вопросами в духе "как сделать" приглашаю в форум.

  35. Sniff

    пошел учить матчасть :)

  36. Sniff

    Сходиол, почитал, и тут же наткнулся на

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

    Главная проблема состоит в том, что координаты и размеры бокса можно задать только относительно содержащего блока, в котором он лежит. А очень часто хочется другого.
    то есть, все не так уж волшебно, как хотелось бы. Все-таки порядок выдачи контента существенно влияет на дальнейшую обработку css-ом. То есть, по-настоящему абстрагироваться от данных дизайну всеже не удается, я правильно понял?

  37. Sniff

    Ну, в общем-то так все почти и делается. Если посмотреть в код этой страницы и поискать там id="menu", то можно увидеть, что оно расположено далеко внизу, после комментариев и представляет собой обычный список . Между тем, визуально оно расположено в правом верхнем углу, вписанное в заголовок. Это, вот, та самая свобода.

    Но все же CSS’ом можно сделать не все, что угодно. У него есть ограничения, которые я периодически уже упоминал:
    - нельзя привязать позицию элемента к другому произвольному элементу (например, я не смогу впихнуть меню между постом и комментариями)
    - нет нормального вертикального выравнивания
    - и т.д.

    То есть, ответ скорее “да”. Но не совсем :-)

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

  38. Иван Сагалаев

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

  39. Sniff

    Всесильных - то понятно, серебряной пули нет. Другой вопрос, когда фанаты какой-то технологии стремяться "перетянуть одеяло на себя" и пытаются решать этой технологией задачи, которые на самом деле не очень удобно ей решать, но можно через приличный изврат. Это то, о чем я говорил, приводя пример русских кодировок, перекодируемых через модуль апача - его адепты решили, что это их задача. Как показало время - были неправы. Точно так же, как мне кажется, css очень хорош для выделения в отдельную сущность характерных стилевых вещей, и даже в состоянии местами взять на себя полностью роль подачи контента, но все же не стоит считать это панацеей, ибо проблем с таким экстремальным восприятием css - более чем достаточно, взять те же закругленные края у блоков. То есть я вполне верю, что можно как-то сильно извратиться и сделать это чистым css, но действительно ли это правильное решение, а не слепая вера в святость css и порочность таблиц? Думаю, никто не будет спорить, что такой элемент проще будет реализовать все-таки через таблицу? Проще - если, конечно, нет таблофобии?
    А учитывая, что реализация css в ТОМ браузере не грозит улучшением в ближайшие пару лет - а значит, через полгода прийдется все делать уже под три основных браузера...
    Все это, разумеется, не проблемы css - ибо это всего лишь рекомендация от w3c, но жизнь же вносит свои коррективы...

  40. Sniff

    Кстати, еще по поводу цитат

    Табличная верстка занимает неприлично много места.

    Это я бы поспорил. Имеется в виду, как я могу предположить, не табличная верстка, а безcssная, да? Когда стили не вынесены в отдельную сущность?
    Потому как собственно таблицы отнимают отнюдь не неприлично много места, не так ли?

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

    Есть подтверждения, или это только догадка? Потому как если почистить тэги (что, как я подозреваю, делают спайдеры), то контент останется в точности такой же. Тем более, что автоматически сделать это просто супер-легко - очистить теги. Все, что не оформительское - суть контент, и он остался.
    В чем же, собственно, проблема?

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

    Веб придумывался не только для этого. Одной из идей была повсеместность, чтобы веб был доступен на бумаге, на мобильном телефоне, PDA, текстовом терминале, мог быть начитан голосом. Все это очень трудно с таблицами. Я бы даже сказал - невозможно, потому что искусственного интеллекта, способного отличить ячейку с навигацией от ячейки с основным содержимым, у нас пока еще так и нет

    Почему это таблицы предназначены только для больших экранов? В чем проблема с маленькими экранами? Тем более, что в широком смысле - это просто средство организации даных, не вижу связи с устройством вывода.
    Я уже молчу, про то, что что когда придумывался веб, еще не было мобильных телефонов (во всяком случае - массовых), PDA и голосовых браузеров.
    Про "помощь распространенных браузеров" - это тоже я бы еще посмотрел, на скольки браузерах нормально отрисуются таблицы, и на скольки - css.
    Ну, и про искуственный интеллект, я уже говорил, да? К рассматриваемой проблеме аргумент не имеет ни малейшего отношения, правда? :)

  41. m_Stasuk

    Классная статья. И следующие статьи классные. Спасибо автору! :)

  42. Николай

    В принципе, я понимаю, что автор наверняка пряв, ратуя за новое и прогрессивное. С другой стороны, я абсолютно не вижу никакой экономии по сравнению с грамотной табличной версткой в том случае, если все атрибуты тегов вынесены в css. надо, конечно идти опытным путем. Попробовать переверстать и взвесить что ли...

  43. Николай

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

  44. BeGeMOD

    Уже 2 года мучаюсь с таблицами, действительно кошмар и полный бред, тэгов так много, что приходиться всё время вставлять комменты, что где начинаеться и где заканчиваеться.
    А эта статься мне открыла глаза, что css'ом можно сделать нормальный дизайн.
    Большое спасибо автору:)

  45. fx

    Насчет тегов. Да у head и body (да и у многих других) закрывающие теги в HTML опциональны.

    This page is not Valid HTML 4.01 Strict!
    Result: Failed validation, 15 errors
    Скажите МАСТЕР - как вы достигли такого мастерства? :)

  46. Иван Сагалаев

    Я некоторое время назад уже высказывался по поводу ценности валидации: http://softwaremaniacs.org/blog/2005/10/02/well-formed-valid-conformant/

  47. Tomaz

    <blockquote cite=""><p>поисковики ... из-за близости информации к началу файла могут дать ей побольше очков релевантности.</p></blockquote>

    Важно также понимать насколько может помочь такая оптимизация. Существуют 2 вида параметров оптимизации - "onpage" и "offpage". Та, о которой идет речь, являетсяодним из параметров "onpage" оптимизации. Так вот, специалисты говорят, что соотношение весов первой ко второй из эмпирических наблюдений примерно 20/80. Иными словами, если на странице с точки зрения поисковика все идеально, то мы получим 20% от общего эффекта оптимизации под поисковыке машины.

    Разметка - всего лишь один из параметров оптимизации, причем не главный. В основном влияет плотность и распределение ключевых слов на странице. Опять же, можно принять влияние разметки в 20 - 30% от тех 20 общего эффекта. ВИмеет по максимуму 0.2*0.3 = 6%.

    Скажем, при использовании таблиц, поисковики будут понимать контент в 2 раза хуже. Значит при ипользовании блоков будем иметь 3% улучшение результатов поиска. Эффект есть, но чаще всего он не имеет решающего значения.

  48. Tomaz

    Только что наткнулся на статью http://www.mikeindustries.com/blog/Майка Дэвидсона, посвященную выяснению влияния чистого семантически правильного кода и позиций в поисковиках. Был поставлен эксперимент с разными страницами, верставшимися таблицами и по-стандартам.

    Итог статьи:

    The findings do support my initial suspicions about web standards as they relate to SEO though: that they matter about as much as a cheap umbrella in a hailstorm. That is to say: “kind of”.

    Перевод на русский:
    "Результаты подтверждают мои начальные подозрения насчет веб стандартов в заимосвязи с SEO: они помогают так же как дешевый зонт во время шторма с градом. Иными словами: 'в какой-то степени'".

    P.S. Майк Дэвидсон был руководителем и инициатором проектов по переводу крупных порталов на рельсы веб-стандартов.

  49. Djun

    А вот я вебдизайнер. Я делаю сложные (можно сказать - максимально сложные макеты. На них есть фоны, накладывающие сверху риснуки, элементы разбросанные (но разбросанные упорядочнено)... мне нужно ПОПИКСЕЛЬНАЯ точность выравнивания всего это. И 100%предсказумость результата.
    Все эти дивные штучки, дизайн от контента, цсс... все это конечно здорово. Но, простите, что подходит для блога на ворлдпрессе, то крайне плохо подходит для корпоротивного дизайна.
    Абы как выравнять куски я не могу. Изучать прорву хаков и особенностей реализации цссов под 5 разных браузеров - не имею ни времени, не желания.
    Делать все простенько я не могу - не купят. А вы не замечали что абсолютное большинство блогов выглядят както однотипно простенько - даже на тоже дзен-гардене вроде и по разному - но принцип один везде чуствуется, создается ощущение, что выйти за границы определенные они выйти не могут, как не пыжаться? Т.е. получается, что цсс и дивная верстка - пока что УШЕРБНЫ. При всей своей гибкости, они не имеют другой важной гибкости - гибкости как инструмента верстка дизайна. Т.е. они хороши для контент проектов, традиционно имеющих упрощенный поточный трех-четырех колоночный дизайн. При попытке создать корпоротивный сайт, после часовой верстки можно столкнуться с тем, что этот браузер не будет делать эту фичу... и все равно переделывать под таблицы...
    Так что, при всем моем согласии что "правильно" - это именно как вы и написали, согласится со своевременностью перехода не могу.

    К тому же, чисто по фичам. Давайте уж не будем так ярко вещать ярлыки и использовать преувеличения.

    Много тексте: Табличная верстка занимает неприлично много места. Страница более-менее хорошо упакованного сайта легко может занимать и 80КБ, и 120КБ… Это без картинок. Все это выливается не только в медленную загрузку и отрисовку, но и в немаленькие деньги за трафик как для сайтов, так и для клиентов...

    Ну уж! "легко" занимать 80кб и 120 кб она будет если на нем текстовый кусок на 20 и 100кб соотвественно. В приведенных вариантах цсс как правило будет уменьшать размер до 70 и 110 кб... учитывая что эти текстовые кб еще не плохо сожмуться при передачи (гдето в два-три раза) эффект не велик.
    Если вы имели в виду паталогические случаи - когда страница сохранена из фронтпейджа или ворда с кучами сложных абстраций в духе (фонт-фамили=, колор=,бордер=,алигн=,фонт-сайз=.э..) для каждого абзаца, то тут во первых не тот случай, а случай потологии, к реальности отношения не имеющий. а во вторыхо как раз счас все сделают цсс таблицу для стилей текста и будут юзать Div class=стильфорtxt для именно стилей текста а не позиционирования отностиельно других кусков.
    И разница между дивным дизайном и табличным будет, но совсем не радикальная - с десяток процентов, даже меньше. В конце-концов, в цсс отсутвие необходимости описывать вложенность таблиц компенсируется необходимость подробно описывать каждый кусок кода. А таблице при грамотной верстке и использование гарантированно работающих кусков цсс (т.е. опять же только стилевых) весят тоже не много.

    Трудная правка.
    Согласен. Иногда понять нагромождение тр и тд очень тяжело. Но тут помогают средства ВЗВИГ - я их держу только для того чтобы в клинических случаях понять, где косяк с пропушенным /тр ;). По статистике пригождается где то раз в три-четыре месяца, и то для чужого кода.
    В своем, если иметь привычку коментить все важные куски, проблем особых нет.
    Но мелкие возникают постоянно, тут, для меня, один из важнейших плюсов цсс.

    Негибки дизайн
    Тоже верно. Но и на это есть прием - никто не верстает сайт до окончательно утверждения макета. И потом, совершенно не обязательно что от ввода нового куска все развалиться. У меня еще не было случая, чтобы изза внесения нового банера приходилось много переверстывать - обычно 5минут уходит. А специфика такова, что "внести на сайт новый элемент" - рядовая задача.
    Т.е. поймите - я согласен с претензией, но не согласен с лихачеством, которым вы присвоили простоенькой технической задаче стутс очень важной.

    Индексация.
    В целом верно, но тоже не глобально. Об этом уже говорили в коментах.
    Плюс, вы, вероятно мало представляете как рабатают поисковики, раз считаете что отделить контент от дизайна "невозможно". Как же по вашему поисковики индексировали до 1998года?:))))
    Задача эта куда проще, чем может показаться - на пальцах технлогию отделения контента от табличного дизайна можно свести к алогоритму всего в несколько абзацев длинной. Его реалзиция програмно, думаю, займет не больше тысячи-двух строк кода.

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

    Вот так то. И решаюший плюс таблиц - в них я могу то, что не могу в цсс. Точка.

    А вот плюсы ЦССов вы расписали очень неплохо - как раз по теме. Вам просто надо поубавить фанатизма - просто помните, что и корпоротивные сайты тоже имеют право на существование. Как и изощренный дизайн вообще. И таблицы пока незаменимы. Возможно - к сожалению.

    А вообще сайт ваш оч. понравился. Дельно, с толком, с примерами, актуально и востребованно. Удачи в вашем деле;)

  50. [...] Вторая лекция: Введение в «дизайн через CSS» “Компот” и “мухи” веб-разработки, CSS’ные боксы, Иван Сагалаев [...]

  51. Vladson

    Замечу что "трафик" можно экономить не только переносом "оформления" в отдельный CSS файл, но и сжатием этого файла (даже если на сервере не стоит mod_deflate или его аналогов, можно реализовать сжатие на РНР или Perl) что выгодно как для посетителей, так и для веб-мастеров которые платят за исходящий "трафик"

    Что касается высказывания Djun

    ПОПИКСЕЛЬНАЯ точность выравнивания всего это

    То тут гараздо больше влияет опыт верстальщика, т.к CSS при грамотном его использовании позволяет делать грандиозные "фишки"...

  52. Alligator

    Я вообще не понимаю о чем спор могет быть!!!:)
    дело в том, что для разных дизайнов и разных задач идет своя нарезка, если сайт резиновый, - то див! а если он статический, - то тэйбл!
    иногда(бывает но редко) это нужно совместить, не так чтобы добавить кусочок таблици или дива туда или туда, а реально совместить. это уже другой вопрос как правильно это сделать)
    Что касается цсс то я бы вообще сказал что без него нельзя однозначно(не в понятии обойтись а впонятии удобства, а я бы хотел еще и цсс2 разрулить - вот это былобы класс). Это 3 разные вещи (див, табл, цсс) первые две совсем разные, а 3- может быть и там и там независимо.

  53. Rod

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

  54. Александр

    Прочитал статью и комментарии. Статья отличная, а вот некоторые комментарии передергивают текст статьи и с этим новоприобретённым смыслом фразы сами же и спорят. Чудаки

  55. Liman

    Прочитал серию ваших "текущих заметок" на http://www.i2r.ru , они мне, как человеку который далёк от всего этого-чайник, но я научусь :) , очень многое разьяснили. Примите моё БОЛЬШОЕ СПАСИБО за ваш труд.

  56. С.Б.

    Большое спасибо за отличную статью!
    В планах прочитать все, что Вы написали по CSS.
    Жаль только, что нет "версии для печати", которая подходит для PDA.

  57. Tomaz

    Жаль только, что нет “версии для печати”, которая подходит для PDA.

    Это удар ниже пояса :)

  58. Иван Сагалаев

    Зубоскалы :-)

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

  59. ценовой поисковик

    Иван, я читаю Вашу статью в самом конце 2006 и поражаюсь, как она все еще актуальна.
    Вот сижу и прямо по Вашим статьям переделываю полностью дизайн с табличного в CSS.

    Сердечное СПАСИБО.

  60. Григорий

    В общем и целом – грамотно и со вкусом. ;) Вот только, «Табличную верстку трудно править вручную. Несмотря на большое развитие визуальных редакторов кода, от этой проблемы они не спасают. Если ваш сайт - динамический, значит он собирается из кусков шаблонов. И значит шаблоны будут состоять из фрагментов таблиц».

    Конечно, есть и такие саты, но возникают они от серости или лени программиста. Уже давно код безо всяких проблем отделяют от шаблона страницы и более того, шаблон делают единым файлом.
    Т.е. я бы заметил, что если ваш сайт динамический и собирается из кусков шаблонов, то вам еще надо долго учится. ;)
    Одним из ярых проповедников такого подхода является некто Дмитрий Котеров, можете ознакомиться с его трудами (в частности и по этому вопросу) на http://www.dklab.ru Но это уже чисто программерский вопрос.

  61. akerka

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

  62. Евгений

    Прочитав Вашу статью, сделал трехколоночный "резиновый" сайт с крайними колонками фиксированной ширины. Результаты можно посмотреть здесь - http://baltstroy-2000.ru/ . По результатам скоро разражусь статейкой. В указанном сайте использовал кое-какие Ваши дизайнерские приемы, о чем честно упомянул в футере сайта. Спасибо огромное.

  63. Mike Ozornin

    2Евгений.

    По-моему, писать внизу страницы «Дизайн — Иван Сагалаев, Евгений Дорстер» — сильная подстава Ивану (:

  64. Евгений

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

  65. qewerty

    Хоть статья довольно старая, всё равно захотелось оставить коментарий. :)

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

  66. Александр

    Прошло 2 года, как была написана статья. Читая статью в 2005-ом, казалось, в скором времени все эти восторги и умиления новой концепцией в сайтостроительстве повсеместно воплотятся в реальную жизнь. И мы узрим её победное шествие по всей планете.

    Но те маленькие червоточины, о которых автор слегка упомянул вскользь повествования, оказались серьёзнейшим препятствием для полного перехода на новую концепцию. В настоящее время это возможно только путем примитивизации художественного оформления страниц. Это относится, прежде всего, к "резиновому" дизайну с ограничениями для непомерно больших или непомерно малленьких мониторов (от мобильника к бигскринам). Заказчик страниц желает удовлетворить любой свой каприз к поведению контента на странице. При этом для него это не просто "оформленная информация". Он желает ГЕЙМ, сюжет, действо. Ни нынешние браузеры, ни CSS2 не позволяют сделать это чистой, как слеза дивной версткой. Иногда одноячеечная таблица спасает от километров кроссбраузерного кода и скриптов.

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

  67. Иван Сагалаев

    Ни нынешние браузеры, ни CSS2 не позволяют сделать это чистой, как слеза дивной версткой

    Они, тем не менее, позволяют делать рабочие решения. То, что они не идеальны, наверное, обидно, но не настолько, чтобы выкинуть преимущества. За два года мы не продвинулись вперед, это правда, но и текущее состояние неплохо.

    Иногда одноячеечная таблица спасает от километров кроссбраузерного кода и скриптов.

    "Километры" — это явное преувеличение. Моя практика показывает, что количество вещей, которые трудно делать в CSS примерно одинаково с количеством вещей, которые трудно делать таблицами. От чего-то приходится отказываться и в том, и в другом случае, и мне пока больше нравится CSS'ная версия происходящего. Например прямо сейчас мы в Яндексе готовим к выпуску сервис, у которого основные блоки страницы естественным образом увеличиваются, если в дополнительных блоках вдруг нет контента. Я не могу представить себе что-то такое с таблицами.

  68. Александр

    От чего-то приходится отказываться и в том, и в другом случае..

    Да. Согласен. Только как часто это приходится делать? Та же Опера с её "пониманием" процентной высоты внутреннего, бокса по отношению к динамически "естественно" меняющейся высоте относительно спозиционированного контейнерного? А как часто приходится вертикально позиционировать и контейнерные боксы и цепочку "вложенных матрешкой" в них контентных боксов, когда их размеры (высота и ширина) заранее не определены?
    Это песня, это оперетта как в партии HTML, так и в партитуре CSS с дирижированием JS или expression. Хорошо еще, если у клиента не выключено "выполнение сценариев" и не организован параноидально высокий уровень безопасности.

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

    А в идеале мечта - пишеш HTML, думая только о слоге и информации и ВСЁ. Остальное отдать художнику, аниматору и CSS.

  69. CepeLLlka

    Может кто нить обьяснить чем отличается одноячеячная таблица от дива? Пожалуйста..

  70. Иван Сагалаев

    Ну много чем отличается...

    • в div меньше тегов: <div></div> вместо <table><tr><td></table>
    • обычный блок допускает раскладку своего контента по мере загрузки, таблица же должна загрузиться целиком
    • к блоку не применяется вертикального выравнивания
    • табличный бокс обжимается по своему контенту, а обычный блок — прижимается по ширине к контейнеру
    • таблицу нельзя float'ить (если я ничего не путаю)
    • у таблицы есть семантическое значение (по крайней мере формально), у div — нет

    Еще я мог что-то забыть...

  71. Дмитрий

    Может немного и запоздалый комментарий на комментарий Djun от 3.02.06.

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

    Абсолютно не хочу переходить на личности, да и, возможно он сам поменял свое отношение к CSS. Хочу сказать о другом. Все так называемые Web-дизайнеры (не верстальщики, кодеры и пр, а именно, что дизайнеры) свою суть ведут от полиграфии, где нарисовал и забыл. Им можно посоветовать делать сайт одной большой картинкой с ImageMap для ссылок - так всё будет пиксель в пиксель, а еще всякие тени и прочие маленькие, никому не заметные, но очень важные детальки. А если они в детстве были фанатами мультфильмов (а кто не был), то делать сайт на Flash.

    Я это к чему. К тому, что большинство Web-дизайнеров не являются Web-дизайнерами - для них что плакат, что визитка, что сайт - одно и то же. Хотя, по-уму, даже визитка от плаката отличается, не говоря о сайте, который является не картинкой, а именно что текстом. Поэтому, если бы Web-дизайнер понимал немного в верстке (как и обычный дизайнер должен хоть немного разбираться в цветоделении), то не было бы такой ситуации, когда "В ДИВах вообще не возможно, а в случае таблиц получится еще штук 5 вложенных".

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

  72. Евгений

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

  73. Mirkus

    Согласен с комментарием Дмитрия.
    Автору спасибо за учебник.
    Очень легко стало работать над проектами,
    с поддержкой как браузеров мобильных телефонов
    так и компьютерных браузеров.
    Отпала необходимость создавать 2 версии сайта.
    Достаточно иметь 2 css файла.
    Спасибо.

  74. Собак

    Учебник написан в 2005 году, ну а я только сейчас начну изучать css, вообще давно недоволен таблицами, пора от них уходить. (особенно, когда проихсодит вкладка из пяти таблиц одна в одной)

  75. [...] а форматировалось и оформлялось эксклюзивно CSSом как учил Иван Григорьевич. На основании определенных рабочих моментов и родился [...]

  76. Akim A. Khalilov

    css правильный выбор.
    Плюс немного умения и опыта - в результате вы впереди.

    Что касается css3 - хотелось бы про него почитать(только на русском..) :( вот..

    буду ждать продолжения статей

  77. Roman Efremov

    Отличная статья! Студентам буду давать в качестве примера того, какие нужно читать учебники. Спасибо, Иван.

  78. Mariik

    В своей статье Вы привели примеры типичных заблуждений и мифов.
    Оспорить можно буквально каждое слово:
    "Табличная верстка занимает неприлично много места." - Ну это вообще не серьезно..Кто простите мешает вынести весь лишний мусор типа "cellspacing" "cellpadding" и тп в цсс? Никто.

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

    "Индексация поисковиками" - вообще не выдерживает критики.
    Поисковик прекрасно умеет отделять хтмл код от содержимого.
    И поверьте моему опыты - поисковику всё равно как именно Вы сверстали сайт. Не верите? Ну так задумайтесь, как тогда существовал инет до появления боксовой верстки.

    Так же в своей статье Вы привели много мифов про удобство верстки на дивах.

  79. Nikita Seleckis

    У вас тут немного поехал размер текста в статье. Или это так задумано? :) Бразуер Сафари

  80. Ivan Sagalaev

    Спасибо, поправил. При конвертации базы текст немножко поломался, видимо...

  81. Дмитрий

    Много чего искал в сети по HTML и CSS но только вот эта статья наконец то открыла глаза (точнее проявило во мне понимание досканальное) на то как и где надо использовать HTML, CSS

    Спасибо автору и Респект!!!

  82. Вячеслав Брагин

    Хорошо если бы каждый принимающий участие в дискусси, указывал ГОД! Т.к. на дворе 2012, а я только в конце понял, что это было сказано в 2005... Хотя многие факторы и сейчас имеют место. В любом случае статья полезная. Респект!

  83. Ivan Sagalaev

    Год поста указан в самом начале. Поскольку дискуссия идёт не сама по себе, а как комментарии к посту, то всё это относится именно к тому времени.

  84. Konstantin

    Октябрь, 2013 Комментарии же для всех? Не только для Ивана. Знаете, а мне понравилось изложение во всех материалах Ивана Сагалаева, за что ему огромное спасибо - все ясно, четко по-полочкам и без пафоса, со своей долей иронии и юмора по теме веб-программирования. Как по мне - супер! О вкусах же не спорят.

    Я верстал, до сегодняшнего дня исключительно в формате табличной верстки, и к CSSу относился, как правильно заметил Иван (скажу своими словами) как к "приблуде". Почитал офсайты с исходники по CSS, по CSS2, а как это все интегрировать не имея комплексного восприятия технологии, а лишь частичное? Методом "тыка" не получается. Нет "вида сверху". Именно его я нашел в статьях Ивана. Не подумайте, что оды пишу - просто, человек сделал для меня полезное дело, и я его благодарю как могу. Не знаю как кто, но я понял, что мне демонстрируются конкретные работающие примеры с краткими пояснениями, что да как, но только не тупо, как в на офсайте... а живо. Видно, что человек на практике с этим работает.

    Спасибо, Иван. Мир Вашему дому.

    P.S: Критика - хорошая штука, а конструктивная критика еще и поучительная. Бывает достают, "забрасывают камнями", говорю: бросайте побольше, мне для стройки камни ох как нужны. Смеются. :).

Добавить комментарий

Format with markdown