SelenIT

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

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

psywalker, насколько я понял объяснения корифеев, <article> — это любой блок информации, который можно целиком выдрать со страницы и воткнуть в какой-то другой контекст (напр., RSS-ленту), причем смысл его от этой процедуры не изменится. Т.е. критерий применимости <article> — самодостаточность. А про неявные секции — это п. 4.4.1 спеки HTML5. Для каждой страницы создается план, или схема документа (document outline), все элементы типа sectioning context (article, aside, nav и section) и все заголовки (кроме находящихся в элементах со своей собственной структурой разделов — blockquote, details, fieldset, figure и td) создают новую отметку (новый пункт) в этой схеме. И для этого плана/схемы два заголовка одного уровня, идущих друг за другом в одном контексте, равнозначны (семантически эквивалентны) двум последовательным <section> с заголовком любого уровня в начале каждой из них. В спеке по ссылке есть три примера создания одного и того же плана — один с одними заголовками и два с явными секциями. Правда, в спеке советуют выделять секции явно — якобы для простоты поддержки. Но мне кажется, там, где структура и без них самоочевидна, добавочные элементы, по факту не прибавляющие к семантике, наоборот вносят лишнюю сложность и подпадают под 2-е правило Светланы... rediskavet, тем, что браузеру придется выводить его в анонимном блоке уровня абзаца, а анонимные блоки гораздо сложнее стилизовать, чем явные (по отдельности — вообще невозможно). Структура HTML предполагает иерархичность: блоки абзацев — абзацы — текстовое содержимое абзацев. Нарушать эту иерархию — всё равно, что выкладывать штабель из коробок с каким-то товаром (напр. чайниками) вперемежку с чайниками без коробок. Оно, конечно, может и не развалиться... но когда в коробках всё, как-то спокойнее Хотя, если твердо знаешь, что делаешь — на обертке вполне можно и сэкономить.

Я бы, если честно, ни во что не оборачивал. Формально, да, последовательность стадий процесса ложится в семантику <ol>, но возня со стилизацией этого дела под нормальный текст (если я верно понимаю задачу) не стоит своих трудозатрат. Последовательность заголовков на одном уровне в рамках единого контекста сама по себе более-менее отражает последовательную зависимость, никакой паук/агрегатор портить эту последовательность не станет. Так что острой необходимости во что бы то ни стало делать это списком я не вижу. <article> тут однозначно не годится — стадия процесса не самостоятельная сущность, в отрыве от целого процесса она бессмысленна. <section>, в принципе, подходит, но заголовки и так создают неявные секции. И еще мелочь, но не нравятся мне ни во что не обернутые картинки между блоками. Strict-валидатору они тоже часто не нравятся. Хотя это, наверное, наш с ним личный пунктик...

Если впасть в другую крайность, мы все поголовно станем святыми аскетами и уйдем в горы медитировать. И некому станет делать сайты и смотреть их. Тяга к крайностям — сама по себе вещь негативная. Нужен здоровый баланс. Хотя картинку можно немного оптимизировать... раза примерно в три навскидку — это да, пожалуй

Маркер — да. На крайний случай, заменить фоновой картинкой. Не работает в нем селектор "+" (соседний элемент).

Единообразием разметки и неподдержкой IE6-?

Можно и без классов (если не учитывать 3% антиквариата).

Как вариант, preg_replace(array("/(\r?\n){2,}/", "/\r?\n/"), array('<br><br>', '<br>'), $message)

Вариант с заменой в одном месте цвета заголовка и фона какой-нибудь плашки указанным способом не реализуется, единое регулирование размера и отступа под него — тоже. Да и вообще у такой группировки с разносом разных свойств одного блока по десятку мест читабельность еще та, экономим на одном за счет другого. Переменные могли бы легко решить эту проблему без большого усложнения, ничего на самом деле не усугубляя. Хотя и способов "отстрелить себе ногу" они тоже добавят — увы, оборотная сторона почти любого прогресса. По-моему хуже точно не будет. Весь нынешний бардак останется как есть, но добавится единообразная возможность обращаться к готовым переменным вместо нудного конструирования значений по частям (эти вечные "+'px'"), а также достаточно ясный механизм создания/обновления этих переменных (действие которых автоматом применится ко всему сайту). Т.е. опционально разнести разные виды работы со стилями в два более-менее независимых слоя. По-моему, может оказаться удобно (особенно там, где нужно поменять большую кучу свойств у кучи элементов сразу, а классов на все ситуации не заготовишь)...

-moz-column-count/-webkit-column-count в соответствующих браузерах... для остальных, AFAIK, только скриптами. Вот здесь какой-то, судя по отзывам, неплохой вариант на JQ предложили...

Насколько я в курсе, да — написав отдельное правило a:hover { background: transparent; } или a:hover { font-size: 100%; }. Чтобы до IE6 дошло, что при наведении со ссылкой что-то происходит, и он обратил внимание на ее потомков. Но стоит ли сегодня вообще отдельно заморачиваться из-за этого динозавра? )

Занятно, у меня 10-й Хром в юзерагенте показывает Webkit/534.16, а 5-й Сафари — Webkit/533.20.25. Неужели у Сафари всё еще впереди?..

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

По той спеке, что я видел — скорее всего, либо ничему, дефолту (поскольку объявление должно идти раньше всех правил, т.е. в примере явная ошибка), либо, на худой конец, значению из первого блока (второй блок стоит не на месте и не должен на что-либо влиять, а значения переменных в DOM — readonly). Но правильная спека должна явно разруливать такие вопросы. Для логики представления достаточно удобно, на такие вещи, как подгонка под размеры окна или смену ориентации айфона/айпада, его декларативный синтаксис ложится удобнее, чем увешивание объекта окна скриптовыми обработчиками (имхо). Да и менюшки выпадающие многоуровневые на нем вон уже сколько лет программи фигачат...

prowoke, вам уже намекнули, что тень нужно применять не к элементу с height:100% (высотой с окно браузера), а к его потомку с min-height:100% (не меньше высоты окна). В коде по ссылке сейчас это .wrapper. А отдельная обертка .shadow, по-моему, вообще не нужна...

Мда, дооптимизировались ребята . Стиль применяется не только к непосредственному соседу, но и ко всем последующим элементам, совпадающим с ним по тегу и классу. И, что обидно, существующие тесты его не ловят — у W3C классы различаются и поэтому всё ОК, а CSS3.info не додумался проверить несколько однотипных элементов (первый сработал — и ладно). Тщательнее нужно тестировать, тщательнее! Интересно, что замена B + I на B:nth-child(1n) + I приводит его в чувство (видимо, заставляет честно пересчитать ноды). Еще более интересно, что B:nth-child(n) + I (по идее, эквивалентная записи с единицей перед n, и в FF4 это так) не работает вообще В общем, вот такой он загадочный зверек, этот чемпион в HTML5test-е

Картинка — сущий децл в сравнении с видеотрафиком, от которого каналы и то не коллапсятся. А страница получается гораздо теплее и человечнее. Пусть будет!

Сдвиг по фазе у того, кто назвал константы @variables . Наверное, влияние XSLT сказалось, хотя там роль переменных совсем другая, и с точки зрения ФП они действительно переменные. Но в CSS пока по факту единственное, где они действительно могут меняться — это для разных @media. Может, к релизу спеки какой-нибудь порядок наведут... Кстати, что забавно, ценой небольшого вывиха пары извилин подобное практически осуществимо и на технологиях вчерашнего-сегодняшнего дня P.S. Черновик спеки про переменные цитирую по этому изданию — ничего актуальнее, увы, не нашел.

Great Rash, не, с переменными константами чуть иначе: @variables { ThemeColorLight: #fe8d12; ThemeColorDark: #000033; FooterHeight: 100px; } .content { background-color: var(ThemeColorLight); color: var(ThemeColorDark); padding-bottom: var(FooterHeight); } .footer { background-color: var(ThemeColorDark); color: var(ThemeColorLight); height: var(FooterHeight); position: absolute; bottom: 0; }

Насчет именованных констант (и кто назвал их переменными?) согласен со Светланой, они нужны (пары "цвет — фон" или "размер — соответствующий отступ", что часто встречается при прижатии футера, удобно редактировать в одном месте). Насчет генерации контента скорее соглашусь с Great Rash — вещь спорная (особенно без единообразия в обработке такого контента — напр., нумерации заголовков или кавычек вокруг цитат — при копировании из браузеров в буфер и т.п.). Имхо, генерация как таковая была бы уместнее в разметке (какой-нибудь атрибут типа counted, особенно пригодился бы для заголовков в новой модели секционирования из HTML5), а в CSS хватило бы привязки для оформления результата генерации. Но вот генерация оформительских блоков (не участвующих в DOM и практически не сказывающихся на ней, но позволяющих применять к себе оформительские эффекты независимо от основного блока) — это мега-здорово. Пожалуй, двух таких блоков на элемент (:before и :after) порой бывает маловато...

Баг, судя по всему. Причем именно в режиме CSS3 — под CSS2.1 (где это свойство тоже есть) оно валидируется. Надо писать в их багзиллу.

Имхо, всё же меньшее зло по сравнению с оформлением с помощью растровых картинок (всеми этими двумерными раздвижными дверями и т.п.). Для всяческих кнопочек, табов, нестандартных полей форм и прочего подобного безобразия. А если SVG-шку завернуть в data-url через urlencode (браузеры, кажись, позволяют), то из нее при нужде можно и цвета-размеры скриптом выковырять и подправить...

Мило! У меня на первой работе номер офиса был такой же, с тех пор приятное чувство связано с этим кодом ответа

На Маке так? Без аддонов? Впрочем, тема в любом случае не о нем... )