SelenIT

Варианты с inline-block и центрированием в строке требуют конкретной высоты этой строки, для 100%-го блока это не пройдет. Здесь, на мое имхо, лучше такой метод применить...

По-моему, для min-width одноразовый экспрешн — не панацея. При ресайзе окна привычное поведение нарушится. Вот какой монстр у меня получился: width:expression( this.tmp=document.body.createTextRange(), this.tmp.moveToElementText(this), this.tmp.boundingWidth > 300 || (this.tmp.getClientRects().length > 1 && parentNode.clientWidth > 320) ? 'auto' : '300px' ); Тут замеряется размер текстового содержимого дива, и если оно не умещается в фиксированную ширину в одну строчку, а снаружи место есть, то ставится автоширина, иначе (мало контента в одну строчку или снаружи нет места, даже если внутри контент переносится на новую строку) ставится минимальная фиксированная. Лимит внешней ширины задан с запасом (320px вместо ожидаемых 310), потому что есть небольшой интервал (когда ширина внешнего контейнера меньше или равна лимиту, но больше реальной ширины самой широкой строки текста в блоке), в котором условие в скобках может выполняться, и блок становится уже лимита. Правда, процессор грузит немилосердно, так что много таких блоков лучше не заводить. Возможно, добрая старая "распорка" в этом смысле надежнее...

Иногда такая фигня бывает в IE с курсивом (font-style:italic). Я обычно по-тупому лечил паддингом в пару пикселей...

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

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

1) где закрывающая </td>? Раз уж стоит доктайп XHTML, так надо соблюдать веллформность... 2) width="310px" — какой это язык?

Из разряда "for fun", наверное, можно классику вспомнить: домики из бордеров (раз и два), CSS-портреты Гомера Симпсона и Джорджа Буша...

А я как раз считал, что вся эта (местами действительно не совсем здоровая) суета вокруг семантики — именно ради сторонних программ (поисковые боты, скринридеры и т.п.). Спорно. Например, есть таблица-календарь (кстати, таблица он или список — отдельный давний холивор, а там на второй строчке <tr><td colspan="3">Нет данных</td><td>Дождик</td>... Если считать colspan чистой визуальщиной, получится, что дождик был во вторник, а он был в четверг... Ну да . Я про такое: <p>Чайлды body:</p> <ol> <li>header</li> <li>сontent</li> <li>nav</li> <li>footer</li> </ol> В описании кода это действительно упорядоченное однородное перечисление. В самом коде явно нет, слишком разные роли у этих элементов Как минимум, что данная страница как-то связана со всем перечисленным и все перечисленное имеет на ней примерно один порядок важности. А-ля этакое урезанное до неприличия облачко тегов.Кстати, контекст может задаваться и не текстом, а опять же разметкой. Любой список ссылок в вышеупомянутом nav из HTML5 автоматически становится основным навигационным блоком сайта (если находится на самом верхнем уровне иерархии) или вспомогательным навигационным блоком статьи (если находится в ейном section-е). Хотя, справедливости ради, формализация этой иерархии секций, статей и вспомогательных блоков остается запутанной, несмотря на все попытки авторов стандарта... Впрочем, это всё — тоже имхо .

А вот уже не факт. По крайней мере по сообществу гуляет страшилка, что какой-то шибко умный агрегатор вполне может сложить LI-шки из UL в свою базу в произвольном порядке (напр., в том, как они встретились на первом из обработанных ресурсов). А вот для OL ему уже придется изворачиваться как угодно, но порядок сохранять . Не совсем, имхо. Список списков — это аналог jagged-массива (как в C#), а таблица по крайней мере пытается строить из себя настоящий двумерный. Похоже, да не совсем то (особенно при наличии colspan-ов и т.п.). А, речь о текстовом описании кода некоторой ноды, типа "вот у нас body, а вот его детки: сначала header, потом content, потом где-то сбоку nav и в самом конце footer"? В таком контексте, конечно, список, причем упорядоченный.

Набор абзацев — это поток. Как идут, так и прочитаются — хоть человеком, хоть ботом. А вот набор ссылок — это ветвление, выбор. И логика этого выбора во многом зависит от... <тут всегда кончается мой дефолтный словарный запас и часто начинается холивор по семантике :)> Видал я и такое . Но тут я не согласен насчет однородности и равнозначности, т.к. контент явно приоритетен перед колонтитулами. Так что здесь списки — действительно перегиб (ну да, маразм. Таблица — двумерный список, TDшка принадлежит и TR-ке, и COL-у (как это формализовать в потоковом HTML — черт ногу сломит, вот и получилось то, что получилось). Порядок там зафиксирован вертикальной сеткой. Выходит — да, список, но непростой, UL/OL для его выражения недостаточно... Произвольные чайлды — не являются, т.к. ничего не известно об их отношениях (точнее, могут и являться, но не факт . Оно может подразумеваться. Например, для списка товаров в магазине (независимо от его оформления) очевидно неявное оглавляющее предложение "Мы продаем:" Вышесказанное — ИМХО. Он совсем для другого. То меню — это "как бы нативный" контрол для клиентских приложений.

Набор ссылок набору ссылок рознь . "Хлебные крошки" тоже подпадают под это определение, но там важна последовательность, между соседними элементами есть иерархическая связь. А тут элементы однородны и равнозначны, жесткого порядка у них нет (автобренды можно сортировать по алфавиту, а можно по популярности). Свойствами самих ссылок (rel и все такое) этого отношения, имхо, не выразить, а вот помещением их в соотв. контейнер — вполне, и unordered list, как по мне, по смыслу подходит на роль такого контейнера лучше всего. А почему бы нет? Людям все равно (спасибо CSS!), а ботам всяко проще парсить разметку, чем делать синтаксический разбор разговорного языка . А то еще получится, как здесь...

Насколько я в курсе, синтаксические правила CSS изначально были сделаны гибкими и готовыми к расширению, с грамотной защитой от непредвиденностей, и практически не меняются. Но "CSS-валидатор" проверяет еще и буквальное соответствие словарям. А словари эти имеют тенденцию меняться (даже CSS2.1 еще не утвержден, а уж CSS3 и подавно — одни модули добавляются, другие исчезают, сливаясь с соседями), "валидатор" может и не поспевать за этими изменениями. Так что, имхо, любые сообщения валидатора (и ошибки, и ворнинги) — в первую очередь повод лишний раз свериться со спецификацией. Если актуальная спецификация (напр., эта) ничего не имеет против — можно не только смело пользоваться, но и гордо вешать значок "валидный CSS", а команде поддержки "валидатора" отписывать багрепорт

Может, там все-таки был short_open_tag=Off и автор кода так "креативно" спрятал бажный кусок кода от выполнения, "типа закомментарил"?

+1 . Просятся они туда.

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

Если я не путаю — контекстом форматирования (наличием или отсутствием такового).

Первый работает всегда, второй — только если не запрещен соотв. настройкой.

В IE8 как минимум tbody можно вырвать, если впридачу к display:block указать position:absolute. Видимо, наследие движка с очень старых времен (судя по комментам к старинному примеру, где как раз используется display:block для tbody и tr, недавно игрался с подобным делом. Хотя, имхо, с точки зрения CSS это явный баг — переопределение display должно для всего работать одинаково.

У того же Сергея Чикуенка есть замечательная библиотечка rocon, где это уже решено. Я пробовал, мне нравится

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

http://chikuyonok.ru/2009/06/float-columns/

По доктайпам — отличаются требованиями к коду и режимом отображения в браузере. Strict включает в браузере самый стандартный режим отображения, но под ним iframe, target для ссылок, инпуты в форме без оборачивания в промежуточный блочный элемент и еще некоторые вещи будут считаться невалидными. При Transitional разрешено больше, но для него современные браузеры включают не стандартный, а "полустандартный" режим. По идее, он отличается от стандартного только поведением картинок в ячейках таблиц, но иногда в нем бывают и другие приколы. Иногда приходится выбирать, что важнее — формальная валидность или строгость отображения (в браузерах невалидные при Strict фичи все равно работают, хотя злоупотреблять этим не стоит. В свете новых тенденций, есть смысл глянуть в сторону нового доктайпа <!DOCTYPE html>. Он не только тоже дает полностью стандартный режим, но и легализует многое из реально полезных вещей, бывших невалидными в предыдущих спецификациях (напр., autocomplete="off" для полей форм и свои атрибуты для данных). Правда, по нему пока не умеют валидировать ни FF-овское расширение-валидатор, ни большинство редакторов, да и онлайновые валидаторы еще могут менять определение валидности для него. Но как бы за этим будущее По кодировкам — как было сказано выше, UTF-8 современнее и универсальнее, это дефолтная кодировка для XML (и, соответственно, XHTML). К вышеназванным ее плюсам я бы добавил возможность вставлять символы типа тире, «русских кавычек» и т.п. прямо в виде символов (а не —, « и т.п.) и меньше подводных камней при работе с AJAX. Недостатки — чуть больший размер файлов (gzip почти сводит разницу на нет), лишняя BOM-метка в начале файла при сохранении Блокнотом (исправляется нормальными редакторами) и подобные мелочи — постепенно теряют актуальность. 4-5 лет назад еще были проблемы с поддержкой UTF-8 в PHP и MySQL, но в актуальных версиях, насколько я знаю, таких проблем практически нет (а в ожидаемых не будет вообще). Однобайтные кодировки (Win-1251 в том числе) были актуальны в эпоху узких каналов и слабого серверного "железа", но сейчас их эпоха неумолимо подходит к концу (имхо). По метатегам — адекватный содержанию description полезен безусловно, т.к. google очень часто именно его использует в качестве пояснения к ссылке в результатах. Роль keywords сейчас минимальна (говорят, что поисковики не сколько поднимают страницы с адекватными кейвордами, сколько штрафуют за их явное несоответствие контенту.

Тем не менее, официальный тестсьют до сих пор в статусе пре-альфа. К тому же в процессе "демонстрации неубогости движка" обнаружилось изрядное кол-во багов в самих тестах — и тех, что были до MSовской "добавки" и в добавленных. То-то синтаксис clip выглядит таким нелогичным. Хотя... принятая модель упрощает расчет размера видимой части, для динамических картинок неизвестного заранее размера это может быть и плюсом. Идеально было бы, если бы стандарт поддерживал обе возможности... может, на 3-м или 4-м уровне CSS и введут, вместе с непрямоугольными областями?

По-моему, MSу просто нет особого интереса возиться над браузером -- прямой прибыли ведь он им не приносит, вот и делают "лишь бы было". ОСи-то у них по-любому покупать будут, даже без дефолтного браузера вообще (интересно, кстати, будет глянуть, как оно будет выглядеть в реале в Европе. Но с приближением 7-й "винды" MSу, во-первых, понадобился дополнительный стимул для переманивания юзеров с прежних ее версий, а во-вторых, рекламной кампании стало мешать то самое пренебрежительное отношение профессионалов ко встроенному браузеру. Вот и понадобился браузер, который можно было как минимум пропиарить по важным для профессионалов статьям — например, поддержке стандартов. А в ходе этого дела выяснилось, что "измерить" эту поддержку-то и нечем толком, кроме улыбки Acid2 и иже с ним... так что пришлось заодно и самому стандарту помочь "повзрослеть" Понятно, что разным платформам поневоле приходится идти на какой-то компромисс и в конечном итоге развиваться конвергентно. Просто иногда мне кажется, что если б MS и W3C не встали в позу конфронтации изначально, а заняли бы позицию конструктивного сотрудничества и сообща выдали вместо нынешнего CSS2 реалистичную общеприемлемую спеку (с пресловутым box-sizing:border-box и прочим), веб бы выиграл. Хотя десктопное направление MS, действительно, могло бы и слегка потерять...