Спасибо большое за ваши замечания. Я просто новичёк совсем в деле вёрстки веб-страниц. Перечитаю ещё раз все ваши статьи.

Возможно недопонимание вышло из-за отсутствия CSS

Смею вас заверить, никакого недопонимания с моей стороны не могло возникнуть по одной простой причине: к семантической корректности структурной разметки CSS не имеет никакого отношения. Как следствие, все данные вам выше рекомендации остаются в силе.

при наведении на ячейку

К сожалению, вынужден констатировать, что вы хоть и не используете пресловутую табличную разметку как таковую, но мыслить продолжаете исключительно «таблично», визуально, а не структурно. По всей видимости вы не совсем внимательно ознакомились с содержанием представленной выше статьи.

будет отображаться "перейти в раздел..."

Настоятельно рекомендую вам прийти к пониманию, что HTML – это не привязанный к платформе язык. К примеру, браузер для слепых не показывает буквы, а читает их (причем к содержимому атрибута title это относится далеко не всегда). Да и на экране многих мобильных телефонов у вас тоже не будет отображаться «перейти в раздел».

Возможно недопонимание вышло из-за отсутствия CSS в примере кода написанного выше.

/*CSS файл*/

.cell {width: 240px; height: 240px; float: left; border-right: solid 1px #787878; border-bottom: solid 1px #787878; background: #949494;}

.cell a {display: block; height: 240px; color: #2a2a2a; text-decoration: none;}

.vimg {/* 3/2 */ width: 120px; height: 180px; margin-top: 15px; margin-bottom: 5px;}

.gimg {/* 4/3 */ width: 180px; height: 135px; margin-top: 60px; margin-bottom: 5px;}

Этот код отвечает за навигацию по разделам фотогалереи на главной странице. У IMG не указан атрибут alt т.к. глядя на css легко убедиться, что при наведении на ячейку будет в любом её месте отображаться "перейти в раздел...". Как посоветуете лучше организовать навигацию? (Если учесть что на главной странице будет всего 8 разделов).

Выскажите свои замечания по поводу такого кода.

Данный код семантически неверен в принципе.

Во-первых, судя по «перейти в раздел», все представленное вами выше есть ни что иное как блок навигации, который логичнее всего оформлять неупорядоченным списком. При этом элементы <h3>...</h3> здесь вообще не к месту.

Во-вторых, лично у меня возникают глубокие сомнения, что ваши элементы <img> несут в себе какую-то громадную смысловую нагрузку. Тем более, что атрибут alt у них пустой. Как следствие, гораздо логичнее представить их фоновыми изображениями для элементов <a>...</a> или <li>...</li>. Кроме того, с точки зрения семантики присутствие элемента <img> внутри элемента <h3>...</h3> – вообще нонсенс.

В-третьих, про использование элемента <br> вы можете прочитать чуть выше. Для организации переноса строки гораздо правильнее пользоваться CSS-свойством display.

<div id="categories">

<h3 class="cell" title="Перейти в раздел &laquo;1&raquo;">

<a href="1/index.html">

<img class="vimg" src="img/1.jpg" alt="" /><br />

1</a>

</h3>

<h3 class="cell" title="Перейти в раздел &laquo;2&raquo;">

<a href="/2/index.html">

<img class="vimg" src="/img/2.jpg" alt="" /><br />

2</a>

</h3>

</div>

Выскажите свои замечания по поводу такого кода. Просто необходимо чтобы надпись под рисунком была оформлена в виде заголовка h3.

Спасибо Вам большое, Константин. Вы пишите отличные статьи с большой ответственностью и невольно проникаешься к Вам с доверием и уважением. Я начинающий в этом деле, благодаря Вам - вёстка мне становится всё интереснее! :)

На момент выхода статьи (12 января 2008 года, если верить этому сайту), был уже выпущен стандарт XML 1.1

Вы совершенно правы. Я как-то упустил этот факт из виду, благодарю Вас за интересное замечание.

Стандарт XML (соответственно, XTHML) не предписывает писать пробела в пустом теге

http://webstandards.org.ru/exam/xhtml/document.html сообщает об ошибке парсинга XML во всех последних браузерах Opera, FF, Chrome(webkit). IE7, кажется, виснет, о Safari можно говорить как о браузере, использующем тот же webkit.

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

CSS, JS можно как и было лет 10 назад оформлять в комментарии, и это работает

Боюсь, что здесь Вы совершенно точно ошибаетесь.

Мне очень понравилась статья, очень хорошо написана

Есть несколько замечаний по тексту статьи, о которых не хотелось бы молчать

#---------------

На момент выхода статьи (12 января 2008 года, если верить этому сайту), был уже выпущен стандарт XML 1.1

#---------------

Стандарт XML (соответственно, XTHML) не предписывает писать пробела в пустом теге <some-xml-tag/>

[44]       EmptyElemTag       ::=       '<' Name (S Attribute)* S? '/>'

#---------------

О поддержке XHTML на сегодняшний день.

http://webstandards.org.ru/exam/xhtml/document.html сообщает об ошибке парсинга XML во всех последних браузерах Opera, FF, Chrome(webkit). IE7, кажется, виснет, о Safari можно говорить как о браузере, использующем тот же webkit.

#---------------

CSS, JS можно как и было лет 10 назад оформлять в комментарии, и это работает

<script lang="text/css">
<!--
...
-->
</script>

#---------------

Еще одним существенным применением XHTML являются стили для нестандартных тегов и собственно эти самые тэги: генерация части DOM-дерева без применения JS, который по-разному везде работает, а XSLT вроде как один.

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

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

И эти все элементы можно наглядно видеть в браузере

еще на этапе структуры. Иначе говоря, если вы еще не стилизовали форму, но уже просмотрели результат в браузере.

Если же бордюры будут отклюены, полноценная наглядность

исключена: будут видны только элементы управления: «стрелочки выпадушек» и скроллы(промотка).

Отличная статья!!!!!!!

Вы очень интересно и грамотно преподносите материал, спасибо вам огромное за вашу работу.

Жалко только что статей на вашем ресурсе мало.

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

Спасибо.

На моём новом сайте теги <b>, <i> "умерли", даже не увидев свет.

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

Но ведь никогда точно не знаешь, понадобится ли эта необходимость в будущем. ;)

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

хотя я не уверен, что сейчас скорость обработки HTML на мобильных настолько актуальна

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

По какой причине и куда она пропала – на сегодняшний день затрудняюсь даже предположить

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

Но все это только в том случае, если вероятность возникновения такой необходимости действительно существует.

Но ведь никогда точно не знаешь, понадобится ли эта необходимость в будущем. ;)

Весьма интересное решение, но на практике, как мне кажется, малоприменимое по причине практически полного отсутствия в Сети well-formed-контента.

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

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

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

это 2 разных аргумента, а не следствие второго из первого

I beg your pardon. Я действительно неверно истолковал некоторые аспекты вашей точки зрения.

В случае необходимости можно воспользоваться XSL преобразованиями

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

дать возможность указывать браузеру по умолчанию для большей скорости обрабатывать XHTML как application/xhtml+xml, а в случае, если XHTML документ не well-formed, то заново обрабатывать страницу, как text/html

Весьма интересное решение, но на практике, как мне кажется, малоприменимое по причине практически полного отсутствия в Сети well-formed-контента. Полагаю, что именно по этой причине разработчики HTML5 решили пойти по другому пути, который подразумевает создание четких правил обработки различных ошибок.

согласно правилам и условиям проекта webstandards.org.ru

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

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

Да, но здесь же мы выбираем не между PHP и Java, а между HTML и XHTML. Поэтому, по 2м вышеизложенным причинам я и голосую за XHML (но только как text/html).

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

Вы меня неправильно поняли. "В случае необходимости можно воспользоваться XSL преобразованиями" и "W3C валидатор будет сообщать об ошибках неформальных правил" — это 2 разных аргумента, а не следствие второго из первого. Проверять W3C валидатором неформальные правила (вроде незакрытых тегов) можно конечно же без преобразований XSL (да и я не представляю, что за XSL преобразования могут быть для проверки XHTML документа валидатором).

Так или иначе, идеи XML во «фронтэнде» веба не сработали, развитие XHTML зашло в тупик. Это стало очевидным еще несколько лет назад.

Тут я с Вами согласен, т.к. считаю, что веб должен обеспечивать максимальную доступность и сайт не должны лежать из-за незакрытого тега и отдыхающего админа. Хотя и здесь, по идее, есть выход — дать возможность указывать браузеру по умолчанию для большей скорости обрабатывать XHTML как application/xhtml+xml, а в случае, если XHTML документ не well-formed, то заново обрабатывать страницу, как text/html. Это, по идее, позволит быстрее обрабатывать страницы мобильным и т.п. устройствам, в тоже время оставляя возможность просмотра сайта даже в случае XML ошибок.

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

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

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

Лично я сомневаюсь, что истинное предназначение технологии XSL заключается в преобразовании документов с целью их последующей проверки валидатором. Если уж на то пошло, для проверки соблюдения неформальных правил есть гораздо более простой способ, не требующий каких-либо XSL-преобразований: необходимо просто быть честным и отправлять XHTML-документы клиенту с правильным типом содержимого application/xhtml+xml. В этом случае в качестве валидатора будет выступать практически любой современный браузер.

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

Так или иначе, идеи XML во «фронтэнде» веба не сработали, развитие XHTML зашло в тупик. Это стало очевидным еще несколько лет назад.

Поясните, пожалуйста, что означает xml:lang="ru" и lang="ru" ?

Эти атрибуты определяют язык документа. Первый атрибут предусматривается спецификацией XML. Второй атрибут является стандартным атрибутом HTML и в данном конкретном случае указывается для обеспечения совместимости со старыми пользовательскими агентами (на всякий случай).

Это ведь не обязательный параметры?

Совершенно необязательные, но весьма полезные.

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ru" lang="ru">...</html>

Поясните, пожалуйста, что означает xml:lang="ru" и lang="ru" ?

Язык чего определяется в первом и втором случае?

Это ведь не обязательный параметры?

Хорошая статья, Константин.

Только, если исходить из того, что без разницы по какому стандарту верстать (HTML или XHML), лишь бы придерживаться синтаксически верной разметки и следовать «неформальным "правилам хорошего тона"» (фактически формальным для XML), то выходит как раз, что верстать лучше сразу в XHML, т.к. в случае необходимости можно воспользоваться XSL преобразованиями и W3C валидатор будет сообщать об ошибках неформальных правил (вроде незакрытого тега и значения атрибута без кавычек), о которых он не сообщает при указании DOCTYPE HTML.

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

Спасибо большое и за те ответы, что дали выше. Буду разбираться.

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

Ждем с нетерпением новых статей. В интернете не видел ничего подобного по подробности и логичности изложения по сравнению с этими статьями. Надеюсь, не перехвалю. Но польза от статей - очень большая. Доброе дело делаете!

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

Что это, как не разметка структуры документа блоками?

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

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

Постойте, разве не вы приводили в пример код:

<div id="header">
  <h1>Название проекта</h1>
  <p>Краткое описание проекта</p>
</div>

<div id="content">
  <h2>Название публикации</h2>
  <p>Содержание публикации</p>
</div>

<div id="footer">
  <address>Контактная информация</address>
  <p>Информация об авторских правах</p>
</div>

Что это, как не разметка структуры документа блоками?

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

А не является ли визуализацией использование блоков?

Конечно, является. Именно поэтому необходимо верстать не блоками, а семантически.

У меня при верстке определенная задача - задать структуру документу. И, понятное дело, задать её можно лишь двумя способами - определив место для верхней части сайта либо блоком, либо ячейкой таблицы. Второй вариант не семантичен. Следовательно, я могу использовать лишь первый вариант.

Я, возможно, неверно понимаю термин визуализация. Как недостаток верстки таблицами вы указали следующее:

Неоправданное использование таблиц уже само по себе является определенной визуализацией (безотносительно CSS).

А с другой стороны

А не является ли визуализацией использование блоков?

Конечно, является. Именно поэтому необходимо верстать не блоками, а семантически.

То есть и то, и другое является визуализацией. А это - вроде как зло?

Вы предлагаете для каждого <tr> указывать его класс

Да, предлагаю.

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

.height41px {

height:41px;

}

?

И чья же это проблема? Веб-стандартов или тех, кто попросту «не владеет»?)

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

Это означает разметку структуры документа блоками, что и соответствует смыслу блоков.

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

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

Без определенных знаний и умений вообще все всегда сложнее.

А не является ли визуализацией использование блоков?

Конечно, является. Именно поэтому необходимо верстать не блоками, а семантически.

Вы предлагаете для каждого <tr> указывать его класс

Да, предлагаю.

пишу вам комментарий, и "три волшебных буквы" указываю всегда верно во второй раз

По определенным соображениям «три волшебных цифры» имеют срок годности (с момента открытия веб-страницы), который составляет 15 минут.

Кстати, если вам не сложно - вкратце гляньте на сайт http://acronis09.narod2.ru/

Не сложно, но обсуждать верстку конкретных проектов предпочтительнее на форуме.

Да, именно блочно, а не семантично, так как тогда о семантике как таковой не слышал.

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

По-крайней мере, такая дилемма стоит у тех, кто не владеет всей полнотой информации и привык действовать как научился в интернете.

И чья же это проблема? Веб-стандартов или тех, кто попросту «не владеет»?)

Если Вы внимательно ознакомитесь с еще одной публикацией, Вы наверняка сможете осознать, что никакой «верстки блоками», равно как и «верстки таблицами», в природе не существует. Существует «семантическая верстка» и «неряшливое безобразие с полным отсутствием логики».

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

Если надлежащим образом ознакомиться с моделью визуального форматирования CSS, понять «что куда поедет» будет так же легко, как и при использовании таблиц.

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

Неоправданное использование таблиц уже само по себе является определенной визуализацией (безотносительно CSS). Т.е. в данном случае мы уже не можем полноценно отделить структуру от оформления.

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

Ваше главное заблуждение заключается в том, что «один столбец» (пусть даже с несколькими строками) не является таблицей по определению. Рекомендую обратить особое внимание на словосочетание «нескольких колонок».

Ваша правда. Получается, таблица из одной колонки - скорее, ненумерованный список.

Теоретически использование HTML-атрибута style, конечно же, допускается. Тем не менее, настоятельно рекомендую не злоупотреблять подобными решениями. К тому же практика показывает, что «всего один раз» имеет большие шансы превратиться со временем в «несколько раз».

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

h1 {

color:red;

margin:5px 0px;

}

и потом в случае надобности дописывать <h1 style="margin-top:6px"> , чем создавать под такой случай класс, мучаясь, как бы назвать это извращение.

Или другой пример. Мы создаем таблицу, у которой первая строка имеет высоту 43 пикселя, вторая 27, третья 35 и так далее. Вы предлагаете для каждого <tr> указывать его класс, или все же логичнее написать <tr style="height:43px">?

Кстати, четвертый раз пишу вам комментарий, и "три волшебных буквы" указываю всегда верно во второй раз, первый раз не принимает. Пишу в Mozilla Firefox 3.5.5

Хорошая статья. Ох и тяжко будет переучиваться...

Кстати, если вам не сложно - вкратце гляньте на сайт http://acronis09.narod2.ru/

Старался создавать блочно... Да, именно блочно, а не семантично, так как тогда о семантике как таковой не слышал, а только о приоритете верстки блоками над таблицами.

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

<div style="clear:both"> и ужасаюсь :) Вообще, все же есть дилемма между семантической версткой и версткой, хорошо отображающейся в браузерах. По-крайней мере, такая дилемма стоит у тех, кто не владеет всей полнотой информации и привык действовать как научился в интернете...

Сам всегда верстал таблицами. Теперь пытаюсь освоить блоки.

Если Вы внимательно ознакомитесь с еще одной публикацией, Вы наверняка сможете осознать, что никакой «верстки блоками», равно как и «верстки таблицами», в природе не существует. Существует «семантическая верстка» и «неряшливое безобразие с полным отсутствием логики».

За год верстки таблицами я уже всюду вижу таблицу

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

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

Если надлежащим образом ознакомиться с моделью визуального форматирования CSS, понять «что куда поедет» будет так же легко, как и при использовании таблиц.

при таблицах визуализация так же отделяется и переносится в стили

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

Является ли табличная верстка в данном случае - не семантичной?

Ответ на этот вопрос находится чуть выше: «табличной верстки» на самом деле попросту не существует.

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

Ваше главное заблуждение заключается в том, что «один столбец» (пусть даже с несколькими строками) не является таблицей по определению. Рекомендую обратить особое внимание на словосочетание «нескольких колонок».

Всякий ли стиль нужно переносить в отдельный файл CSS?

Теоретически использование HTML-атрибута style, конечно же, допускается. Тем не менее, настоятельно рекомендую не злоупотреблять подобными решениями. К тому же практика показывает, что «всего один раз» имеет большие шансы превратиться со временем в «несколько раз».

Спасибо за статью. Объем порадовал - лучше подробнее да побольше, чем отделаться словами - так не верстают. Спасибо за разъяснение слов "семантика" и "валидность".

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

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

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

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

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

Вот пример. У нас есть сайт со списком новостей. Соответственно, можно этот список сверстать как таблицу - 1 столбец, множество ячеек, в каждой ячейке - новость (дата, тело, заголовок и так далее); а можно - блоками (каждый блок - заголовок, дата, тело и так далее). Является ли табличная верстка в данном случае - не семантичной?

А если не является, и нужно верстать блоками, то почему тогда та же таблица из Excel в один столбец уже верстаться должна таблицей?

Вот эта грань мне кажется очень не резкой...

И вопрос немного не в тему. Всякий ли стиль нужно переносить в отдельный файл CSS?

Словом, у нас есть заголовки, и мы делаем их так:

<h4>Заголовок<h4>

и в css файле пишем следующее:

h4 {

font-size:1.2em;

color:blue;

}

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

то есть у нас

<h4 style="margin-top:5px">Заголовок<h4>

Должны ли мы выносить все это в отдельный css, если такой случай встретиться у нас всего один раз на сайте?

То есть надо ли писать

<h4 class="otstup">Заголовок<h4>

.otstup {

...

}

ну или

#otstup {

...

}

Как вы считаете?

Константин, спасибо огромнейшее за статью. В свете прочитанных до этого статей, где было галопом по свету, в этой статье очень подробный анализ, и многое стало ясно и понятно. Еще раз спасибо огромное!

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

зачем переходить на платную CMS, которая имеет очевидные недостатки

Полагаю, что как минимум по двум причинам:

1. Гарантия и безопасность (что особенно важно для коммерческих проектов).

2. Удобный пользовательский интерфейс (дело вкуса).

А все «очевидные недостатки», как оказалось, при желании и определенном умении легко исправляются.

команда разработчиков побольше

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

модули разработаны давно и постоянно дорабатываются

Лично я предпочитаю писать собственные программные компоненты и модули. Иначе говоря, в CMS NetCat меня привлекает исключительно и только ядро.

Всё же непонятно, зачем переходить на платную CMS, которая имеет очевидные недостатки, а не присмотреться к бесплатной, например Drupal, у которой и команда разработчиков побольше, и модули разработаны давно и постоянно дорабатываются.

подскажите плз скрипт который направлет ie на index.html при нвозможности открыть xhtml(для вапа).заранее спс

Действительно хорошая статья для начинающего. Получаешь общее представление о стандартах и языках. Спасибо автору.

надо так

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Базовый документ для практических занятий по верстке</title>

Все это уже обсуждалось чуть выше: Ваша точка зрения целиком и полностью совпадает с мнением разработчиков Спецификации HTML 4.01.

Тем не менее, те самые некоторые браузеры, о которых Вы говорите, обычно определяют кодировку документа совсем даже не по указанному в элементе <meta> значению, а по соответствующему HTTP-заголовку, который посылается сервером.

Поскольку подобные заголовки с информацией о кодировке должен посылать любой нормальный сайт, информация, содержащаяся в элементе <meta>, является всего лишь «запасным вариантом», очередность которого по моему скромному мнению не имеет принципиального значения.

В конце концов, даже если элемент <meta> с информацией о кодировке будет располагаться до элемента <title>...</title>, все равно ему будут предшествовать элементы <head>, <html>, а также определение типа документа.

а как сделано в оранжевой кнопке браузера "подписаться на рсс" пункты меню "добавить закладку в делициоус"?

Если писать так

<title>Базовый документ для практических занятий по верстке</title>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

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

надо так

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

<title>Базовый документ для практических занятий по верстке</title>

чем он плох?

Плох он тем, что в данном конкретном случае будут отключены границы у всех элементов в документе. То есть совсем у всех, включая элементы управления (input, textarea и т.п.), что далеко не всегда удобно и приемлемо.

Вот ты предлагаешь обнулять свойства так:

* {margin: 0px; padding: 0px;}
img {border: none;}

а я на некоторых сайтах видела такой способ:


* {margin: 0px; padding: 0px;border: none;}


чем он плох?

а за статью спасибо :) побольше бы писал!!!!

Не важно кто это сделал и как.

Главное, что результат на моих глазах.

Совершенно бескорыстный сайт.

На который приятно заходить.

Скажите как можно увидеть символ BOM?

BOM-сигнатура по своей природе не предназначается для того, чтобы ее можно было «увидеть». Рекомендую Вам удалить ее с помощью соответствующих средств в Dreamweaver или Notepad++.

Я получил предупреждение от валидатора насчет BOM-сигнатуры,

но в документе никакого символа не видно. Скажите как можно увидеть символ BOM?

Как в этом случае ссылаться этим файлам на main.css

Указывать путь от корня веб-сайта:

<link href="/css/main.css"...

Большое спасибо за статью.

Поверьте, в отдельной папке CSS-файлу будет уютнее

А что, если «неглавные» html-файлы также должны лежать в отдельной папке. Как в этом случае ссылаться этим файлам на main.css, который также лежит в поддиректории?

Ирония в том, что я видел больше невалидных xHTML (даже strict) доукментов, нежели HTML4 Strict.

«Строгий порядок и аккуратность» — это миф xHTML. Никто не мешает закрывать кавычки в HTML, делать правильныу вложенность тегов, и т.д.

В html5 можно будет писать <br> или <br/>, кому как нравится, все будут счастливы.

Кстати, это первый блог о вебе что я вижу, который проходит валидацию (-:

И стоит тут html4