SelenIT

Но пересекается с устоявшимся понятием DOM-элемента. Опять путаница. Лично я представляю себе Line-box именно как виртуальный, воображаемый контейнер — да, калькулироемой (по содержимому) высоты, да, побочный продукт, но в конечном итоге — тот же прямоугольник. При vertical-align: top/bottom базовая линия курит в сторонке, работают именно "две линии, ограничивающие пространство между ними" (воображаемые, но всё же)

Всё-таки "inline box" — не строчный (строчный это "line box", "inline" именно что "внутристрочный" или "встраиваемый в строку") и не элемент (один текстовый элемент может генерировать несколько инлайн-боксов, если разрывается на несколько строк) Поэтому и вопрос — как сделать перевод максимально понятным, но не в ущерб точности (и не плодя путаницы). От схожих понятий при этом, видимо, никуда не деться...

Друзья и коллеги, предлагаю побрейнстормить давнюю холиворную тему — как же всё-таки правильно переводятся те или иные понятия CSS-спецификаций. Например, есть такая Visual Model, в основе которой лежит понятие "box". Грубо, "box" — это прямоугольный "кирпич" или "ящик", который как-то встраивается в "мозаику" других подобных прямоугольников, заполняющую в итоге прямоугольник экрана. Одному элементу в DOM-дереве может соответствовать от нуля до бесконечности "ящиков", а иногда "ящики" возникают из ниоткуда сами, без всякого элемента. "Ящики" бывают разных типов: те, что объединяют несколько строк, те, что являются строкой, и те, что встраиваются в строку (не считая элементов таблицы и всякой экзотики). Некоторые переводы (типа этого) предлагают называть эти "ящики" "блоками". Но фокус в том, что слово "блок" (block) в спецификации уже есть и означает лишь один из видов этих "ящиков", со специфичным поведением. Если переводить и "box", и "block" словом "блок", у нас появятся "блочные блоки", "строковые блоки", "строчные блоки" и "инлайн-блоки" — и всё перечисленное будет принципиально разными вещами ("block box", "line box", "inline box" и "inline block" в оригинале). По-моему, это не просто путаница, это реальный бардак! Другие переводы (напр. "почти что канонический" перевод Пирамидина) путаницу между "блоками" и "боксами" не создают. Но есть возражения против самого слова "бокс" (фактически грубой кальки). Кроме того, некоторые уже привыкли к "Box model" (той самой, что бывает 'border-box' aka "историческая" и 'content-box' aka W3C-шная или "мир наизнанку") как к "блочной модели". Хотя "боксовая модель" распространена немногим меньше — 15.9k результатов в Гугле против 28.6k для "блочной". Примечание: оба процитированных перевода — древний CSS2, а не актуальный CSS2.1, но блочная/боксовая модель у них практически одна и та же Еще остается путаница между "line box" и "inline box", поскольку "inline" очень часто переводят как "строчный". Хорошо хоть на htmlbook.ru этой проблемы нет, у нас "inline" переводят как "встроенный" (имхо, еще точнее было бы "встраиваемый", лично мне нравится и вариант "внутристрочный" из перевода по первой ссылке выше). Правда, другая путаница всё равно есть(. Но тема не о ней, а о том, как бы минимизировать новую путаницу в будущем... Какие будут соображения?

Если клиент дополнительно заплатил за «валидность CSS» (которой по определению не бывает) — то да, вполне вариант . Как говорится, «за ваши денежки — любой каприз»...

Вообще-то структура будет в любом случае — при отсутствии «секционирующих» элементов document outline строится по заголовкам. Каждый заголовок такого же уровня, как и предыдущий, открывает новую секцию (неявно), каждый заголовок более «мелкого» уровня — новую подсекцию. Но с явным выделением секций, да, структура гораздо нагляднее и предсказуемее. А с выделением навигации в специализированный блок (который, если верить «евангелистам» семантики, скринридеры для слепых смогут "пропустить" при загрузке и продиктовать опять по запросу юзера) — особенно.

Ошибка 1: внутри label не может быть ссылки (и вообще ничего интерактивного, кроме самого input-a), при клике на ссылку внутри label браузер получает взаимоисключающие команды (активировать контрол и одновременно перейти на др. адрес?) и сходит с ума; Ошибка 2: чтобы переключатели действовали как связанная группа, у них должен быть одинаковый name.

Я имел в виду именно автора таблицы, а не автора темы . То, что я процитировал — грубейшая ошибка, показывающая полное незнание им (автором таблицы) смысла и предназначение (X)HTML: говорить, что <blockquote> (блочная цитата) предназначена "для создания отступа" — всё равно, что говорить, что h1 нужен, чтобы "делать текст очень крупным и жирным", а пальцы предназначены исключительно для ковыряния в носу И вообще при таком сжатии информации неизбежна потеря деталей. На моё имхо, такой объем можно и запомнить, а остальное лучше подсмотреть в хорошем справочнике, а еще лучше — в спецификации Кстати, в самих спецификациях тоже есть сводные таблицы (со ссылками на подробности): http://www.w3.org/TR/html401/index/elements.html — HTML 4.01/XHTML 1.x http://www.whatwg.org/specs/web-apps/current-work/multipage/section-index.html#elements-1 — HTML5 http://www.w3.org/TR/CSS/#indices — CSS Вот им уже можно доверять

Похоже, это ucoz своей рекламы напихал перед <html>. Соответственно, <head> со всем содержимым по факту оказался в <body> (у которого открывающий тег необязателен, но он открывается автоматически перед любым выводом), и, естественно, это воспринимается как ошибка.

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

...значит, проблема в одном из инклюдов (кот. в статичном HTML, закономерно, не подключаются), логично? ...что и требовалось доказать

Скорее всего, перед тайтлом что-то выводится. Может, всего-навсего BOM-метка. Соответственно, всё ниже этого места оказывается не в <head> страницы, а в <body>.

AARGH!!! Не берусь судить качество инфографики (хотя то, что без лупы с ней работать некомфортно — имхо, факт), но в (X)HTML автор не разбирается. По современным спецификациям собрать подобное затруднительно из-за их объемистости. А чем родной htmlbook не угодил?

PHP страницу точно обрабатывает?

Уже валидно. Остальное всё верно. P.S. А надо ли в этой задаче зацикливаться на отношениях "предок-потомок"?

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

border-spacing тоже понимают все браузеры (кто не понимает — уже давно не браузер, а недоразуменIE). Зато border-spacing позволяет задавать разные отступы между столбцами и строками

Замена cellspacing'а в CSS — border-spacing для table, cellpadding-а — padding для td. Поскольку border-spacing не работает в IE7-, до недавнего времени вместо border-spacing: 0 использовался border-collapse: collapse — это тоже убирает зазоры между ячейками, но с побочными эффектами (напр. перестает работать border-radius для ячеек), т.к. меняется вся модель построения таблицы.

На моё имхо, этой структуре header вообще не нужен. Заголовок там вполне самодостаточный, никаких особых вводных/навигационных подсказок лично я не наблюдаю, к тому же явно вся article целиком является одной цельной ссылкой. В этих по факту полутора абзацах еще и отдельный header выделять — по-моему, излишество. KISS-принцип рулит!

IE, надо полагать, свалился в Compatibility View и работает в режиме IE7 (нужно убрать в настройках Tools — Compat. View Settings — Display Intranet... и, на всякий случай, поставить метатег X-UA-Compatible IE=Edge)? В IE8+ нет никаких проблем и так. В IE7-, насколько я в курсе, со стандартным доктайпом никак не решается, но, по-моему, на них уже можно смело забивать. А вообще для такой структуры точно таблица нужна?

Как вариант — общественные работы. Тут же. Бросил мусор мимо урны и попался — торжественно и прилюдно получил из рук стража порядка "Nimbus-2000" и вперед, подметать всю улицу от предыдущей урны до следующей. Как в школе . Ну а за сопротивление/попытку сбежать — уже адм. арест и далее по нарастающей...

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

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

При такой записи — никого.

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

float: left тоже лишний, по-моему. По той же причине.