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

А пока вот вам поняшка. Всем Ы!

• Script-injected "async scripts" considered harmful - igvita.com
• PageSpeed Insights
• the script defer attribute ✩ Mozilla Hacks – the Web developer blog
• JavaScript: Defer Execution - with the defer attribute of the script element
• Очерёдность событий и синхронизация в JavaScript
• Погружение в темные воды загрузки скриптов / Хабрахабр
• Параллельная загрузка JavaScript и CSS без блокирования парсинга страницы / Хабрахабр
• Can I use... Support tables for script defer
• Issue: script[defer] doesn't work in IE<=9
• HTML5's async Script Attribute
• 4.12 Scripting — HTML Standard
• javascript - load and execute order of scripts - Stack Overflow

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

1) В файрфоксе вкладки можно прикреплять, тогда вкладка будет считаться "App tab", будет всегда прикреплена слева иметь приоритет выполнения скриптов такой же как активная вкладка. (В неактивных вкладках различные анимации и т.п. будут приостанавливаться). Но главную интересную фишку, я нашла недавно. Прикреплённые вкладки, например gmail могут мигать, оповещая пользователя об изменениях на странице. Мигает вкладка в том случае — если у данной страницы меняется title. Это легко проверить следующим кодом:

<script>
    // for firefox glowing pinned tab
    // window.setInterval  (function  (){document.title=Math.random  ();},500);
</script>

2) В случае с <input type="number">, если вы сами хотите оформить стрелочки инпута — движки webkit позволяют их отключать. Используйте вот такой код:

input::-webkit-outer-spin-button,
input::-webkit-inner-spin-button {
    /* display: none; <- Crashes Chrome on hover */
    -webkit-appearance: none;
    margin: 0; /* <-- Apparently some margin are still there even though it's hidden */
}

Хочу специально заметить что в случае полей ввода для цифр — не желательно использовать input type="text", так как на мобильных устройствах для этих полей будет показываться текстовая клавиатура, вместо числовой.

3) Firefox в 17й версии будет поддерживать крупные иконки сайтов в адресной строке, что не удивительно с появлением ретины. https://wiki.mozilla.org/Improve_display_of_location_bar_results. По ссылке есть макет концепта
 

Пока этого нет в nightly, но надеюсь скоро появится. Так что можете заранее начать переделывать иконки своих сайтов, если хочется =). Будьте первыми. Надеюсь другие браузеры так же будут использовать большие иконки в своём UI.

Замечу что это касается только favicon.ico. Для айпадика например вы можете задавать большие иконки, но для совершенно других целей.

With Apple's formatting (rounded corners, reflective shine)

<link rel="apple-touch-icon" href="somepath/image.png" />

Without reflective shine

<link rel="apple-touch-icon-precomposed" href="somepath/image.png" />

Ещё интересное про иконки:

• http://ru-webdev.livejournal.com/3212027.html
• http://artgorbunov.ru/bb/soviet/20120116/

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

<meta name="SKYPE_TOOLBAR" content="SKYPE_TOOLBAR_PARSER_COMPATIBLE" />
<meta content="telephone=no" name="format-detection">

Good news everyone! Сегодня мой коллега Алексей (mr.troll) сделал волшебную штуку: http://2s.ru/2012/t142_browser_suggest/demo1_ru.html
полноценный тулбар, который можно одной строчкой ставить на любой сайт.

Русский язык:
<script type="text/javascript" src="http://2s.ru/2012/t142_browser_suggest/browser_suggest_ru.js" charset="windows-1251"></script>

English:
<script type="text/javascript" src="http://2s.ru/2012/t142_browser_suggest/browser_suggest_en.js"></script>

Так что я предлагаю вам описание от автора. Которое правда весьма сумбурно, по сути это цитаты из логов скайпа. Я постаралась почти не цензурировать всю экспрессию, но оформить из этого нормальное описание. Плюс я помогла сделать пару demo и, главное, demo_bookmark, так чтобы можно было заранее примерить тулбар на любом известном вам сайте.

Avesome_Browser_Detection_And_Suggestion_Toolbar_Script

Я уже несколько лет читаю статьи с призывами "Остановим IE6", "Поместим кнопочку, чтобы апгрейдили" и т.п. Даже Microsoft сделала пару сайтов по этому поводу. Отдельные сайты протестуют против отдельного IE6. Везде пишут поучаствовать — но никто не предлагает как. В лучшем случае делают прямоугольные баннеры "stop ie" — большого размера. Причём страшные, что пиздец. А пользователи ie6 — не ходят на сайты посвящённые протесту ie6 — они ходят на сотни других интересных сайтов.

Я бы рад был поучаствовать раньше — но блин меня останавливало 3 момента:

1. Куда приткнуть злосчастный баннер, если нет места. 
2. Если тулбар — то его надо самому верстать, и он точно сломает вёрстку тех элементов, которые абсолютно позиционированы от границ body. 
3. Почему только ie? Мне вот недавно сказали, что у одного из сайтов едет вёрстка в Opera 9 — я даже отвечать не стал. Плюс, нельзя человеку советовать, например, обновить ie8 до ie9, если у него XP. 

Ещё мне никогда не нравились ссылки, потому что по ссылкам "Скачайте новый браузер бесплатно" — всегда вирусы или реклама. Поэтому в тулбаре вместе со ссылкой я пишу кратко, как обновить браузер из самого браузера. Плюс тулбар сделан неброским.

Demo

• http://2s.ru/2012/t142_browser_suggest/demo1_ru.html — обычная страница с body margin:10px; и border-top. Можно видеть что тулбар не влияет на все внутренние отступы у body.
• http://2s.ru/2012/t142_browser_suggest/demo2_ru.html — demo, с футером, который всегда внизу =)
• http://2s.ru/2012/t142_browser_suggest/demo_bookmark_ru.html — демо, где вы можете добавить букмарк, на панель закладок и с её помощью примерить тулбар на любой сайт.

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

var stable_browsers={'Explorer':10,'Firefox':15,'Opera':12,'Chrome':22};

Если не задавать версии в ручную, то по умолчанию используется следующее:

var stable_browsers={'Explorer':8,'Firefox':4,'Opera':10,'Chrome':10};

Это вариант когда обновить предлагается совсем уж старое п.о. Все цифры, разумеется можно указывать дробно, например 'Opera':11.64.

Сложнее всего было сделать корректный тулбар под ie6+, так что под ie6-7 не так красиво как под ie8 и обычные браузеры.
Особенность тулбара — в том что он никак не херит существующую вёрстку:
http://2s.ru/2012/t142_browser_suggest/demo2_ru.html — пример — где вёрстка с абсолютно позиционированным блоком справа, и футером точно внизу страницы.

Тулбар подстраивается так — чтобы не затронуть никакие стили body — он как бы подвигает весь body и все его элементы вниз. Весь день на это потратил. На сайте игры (*название вырезано. прим. Елена, потому что пока сырая альфа.*) будет примерно этот же тулбар + не будет показываться блок входа вообще в случае IE. Вместо него ещё одно предупреждение.

Сам тулбар — в DOM лежит вне body. Т.е. он как бы прямой потомок <html>. А самому <html> задаётся paddingTop, а body -  position:relative. Для ие6-7 к сожалению нельзя создавать элементы прямо в <html> приходится сувать в body. Но вёрстка от этого не сильно пострадает. В ие6-7 и без тулбара вёрстка страдает =)) Т.е. он всё равно ведь будет позиционироватся над body. Т.е. с отрицательным margin. А paddingTop у <html> работает и в ие6. (Прим. Елены: Вот например скриншот usabili из ie6, в тех местах где вёрстка поехала — тулбар не виноват. Замечу, что как раз тут видно что все абсолютно позиционированные элементы сверху — очень правильно сдвинуты тулбаром вниз).

Так же js содержит в себе png градиент, для ie8+ и нормальных браузеров. в ие 6-7 градиент делается через filther, поэтому я его красненький сделал. Сами иконки браузеров правда не вшил пока в код, а так бы совсем хорошо было.
Как-то распространить надо бы. Я залил это в открытый репозиторий на https://bitbucket.org/mr_troll/bs_toolbar/ может кто форкнет. А так же теперь добавлен репозиторий на GitHub — https://github.com/mr-troll/bs_toolbar

Так что в идеале, можно будет вбить список минимально допустимых версий и ставить этот скрипт вообще на каждый сайт.
Т.е. в самом мягком варианте — показывать тулбар только для ie6-7, firefox< 3, Opera< 10, Chrome <10 (владельцы интернет магазинов редко любят у себя лишние тулбары,  но всегда можно договориться).
Если владелец сайта не против инноваций — то можно и для ie8 показывать и для FF<10, Opera<11.5, и Chrome<18.

Спрайты

Как уже говорилось, градиент тулбара уже вшит в js-код. Но спрайты браузеров пока нет. Вот они:

browser_logos-32.png для ie7+ и остальных, и browser_logos-32.gif для ie6, вы можете найти и заменить их в коде, если предпочитаете хранить их на своём сайте.

Послесловие

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

P.S. Добавилась поддержка Английского языка и гитхаб репозиторий.

Как сказал Якоб Нильсен (Jakob Nielsen) в своей недавней статье «Computer Screens Getting Bigger» — экраны компьютеров становятся больше. (На что кстати сослался Лебедев =)).
Дословно, гуру юзабилити сказал следующее: "Дизайнеры должны начать экспериментировать со способами утилизировать горизонтальное пространство экрана, и создавать веб-страницы с улучшенным взаимодействием для людей с большими и широкоэкранными мониторами. (Они так же должы использовать методы, такие как responsive design, для продолжения поддержки маленьких экранов, которые будут с нами до конца десятилетия)".

И вот вопрос вам, дорогие читатели — как мы можем это сделать?

В моей практике, я использовала несколько простых приёмов:

• Если у вас есть, каталог товаров — вы можете использовать float или inline-block, чтобы разместить их на экране.
• Вы можете использовать css media queries или их js-эквиваленты, например чтобы сделать размер текста или картинок больше и т.п.
• Вы можете просто задать свойства min- и max-width для вашей обёртки контента (такой как body). Я так делаю в вёрстке блога, чтобы задать размер статей между 1000 и 1200px по ширине, для меня 1200 — это предел читабельной ширины строки текста. Так же я делаю для магазинов, чтобы при разрешении 1920px они не выглядели плохо.
• Если ваш сайт, на самом деле веб-приложение, например онлайн игра, тогда вам нужно принимать целый комплекс мер, который относится к разработке пользовательского интерфейса, особенно оптимизируя сайт под мобильные устройства, так что я спрашиваю не о них.
• Так же потихоньку разрабатывается свойство css text-size-adjust. Говорят на уровне префиксов кроме мозиллы уже поддерживается в -webkit- и -ms-, возможно можно использовать его.

Итак, вы владелец сайта, например блога, такого как мой, или магазина. Если вам гипотетически потребуется оптимизировать его для использования на мониторах шириной 2000 или 4000px, что бы вы использовали?

Или, представьте, что все дисплеи в мире шириной 4000px (не говорим про планшетки), может ли это изменить всю парадигму сайтостроительства? Какие изменения в интерфейсе браузеров могли бы произойти?

Вступление

У меня чувство досады от того что данные представлены в сети не в виде "данных". Что такое "данные"? Это то что может понять компьютер. ... Я хочу представить себе мир, в котором все разместили свои данные в сети.
Тим Бернерс Ли (Руководитель W3C, 2009, конференция TED).

Семантическая вёрстка — это когда я верстаю таблицами и думаю о таблицах. Или что-то типа того.
Алексей Шилов aka mr.troll.

Четыре года назад мы даже не думали о HTML5 (а многие ждали XTML 2.0).
Три года назад нам сказали, что HTML5 непременно к 2020 году будут использовать.
Два года назад мы узнали, что HTML5 уже можно использовать.
Год назад оказалось, что HTML5 давно все используют.
Сегодня, всё что не имеет доктайпа <!doctype html> выглядит остатками мамонтов  (и пахнет точно так же).

Html5 принёс нам много-много всяких спецификаций и технологий. И хотя главное назначение html5 — это расширение мультимедийных возможностей браузера (в черновиках html5 назывался как Web Applications), всякие video и audio теги, их кодеки, canvas и WebGL, инкапсуляция (sandboxing) ифреймов и объектов, и т.п.  — всё это довольно скучные для обсуждения вещи. То, что действительно интересно обсуждать — это новые семантические теги — nav, article, section, header, footer, и дюжину других.

О семантических тегах

Неделю назад (точнее уже три недели назад) вышла статья "Let’s Talk about Semantics (by HTML5 Doctor)", я настоятельно рекомендую с ней ознакомиться прежде чем читать далее.

Откуда же взялись эти семантические теги? Компании Google и Опера выборочно изучили примерно 4 миллиона популярных страниц в интернете, отчёт о результатах доступен например здесь: http://dev.opera.com/articles/view/mama-markup-report-part-2/.

Вот топ 10 самых популярных значений атрибутов Name и Id :

В своей статье, HTML5Doctor, нас убеждают в том, что основываясь именно на данных списках и были приняты решения о внесении новых тегов в спецификацию HTML5. Однако, из таблицы видно что это не совсем так. Я очень люблю id="footer" или id="content" — но я никогда не использовала id="article". Значение "article" — находиться на 186 месте в рейтинге значений класса и на 728 месте в рейтинге значений id. Т.е. данные атрибуты используют меньше чем 0.1% вебмастеров из статистики. Я считаю что это очень показательные цифры, я не могу понять почему html5doctor ссылается на них.

Так откуда же появились новые теги? Если ответить коротко — они просто придуманы редактором спецификации html5 Яном Хиксоном (Ian Hickson). Когда я спросила его об этом два года назад, он ответил примерно следующее:

Element names in HTML have little relationship to the usage of those names
in reality, to be honest. I wouldn't pay too close attention to the
meaning of the element names in common conversation; only their definition
in the spec matters.
- Ian Hickson (16 Mar 2010)

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

Также есть множество веб-разработчиков, которые считают, что в вёрстке названия как-то связаны с той ролью, которую выполняет тег. Я сама вкладываю в термин "семантика" именно такое значение. Было бы логично предполагать, что если тег a — означает anchor, h1 — заголовок первого уровня, abbr — аббревиатуру, то и тег menu — можно было бы использовать для меню, nav — для любого обособленного блока со ссылками на другие страницы и навигации по сайту, header — как шапку страницы, article хмм... как статью, а section — какую-то часть содержания, например той же статьи. Однако же можно привести примеры вёрстки, где, по спецификации, данные теги будут обозначать совершенно другое, и наоборот, можно привести примеры, где все значения соответствуют совершенно другим тегам.
Например тот же Ян Хиксон не рекомендует использовать тег <menu type="list"> для разметки меню. Вместо этого советуется <nav><ul></ul></nav> и т.п. Так же по спецификации возможно не рекомендуется использовать <nav> для разметки такой навигации как "хлебные крошки" и формы поиска, хотя для меня это было бы семантично (о чём я не раз писала три года назад тут и тут).

Что же я думаю по поводу новых семантических тегов? У них есть ряд положительных свойств:

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

Но есть и ряд и недостатков:

• Названия элементов — не связаны с их значением. Например article — это любой объект который сам по себе представляет какой-то контент, а section — это группирующий элемент, например когда нужно связать много <article> воедино. (Тут важно группировать по смыслу, а не как визуальную обёртку ). Вместо <article> безусловно лучше был бы <zoidberg>.
• Никто честно не говорит вслух — почему верстальщик должен использовать семантические элементы вместо div? Единственный ответ — "для поисковых роботов". Самому верстальщику — долгие раздумья, над тем какой тег использовать, приносят больше вреда чем пользы, imho. (За исключением конечно того, что таблицы надо верстать таблицами, а списки — списками. Прочие тривиальные вещи объяснял, например, Вадим Макеев, однако его объяснение про html5 не очень внятное). Веб-браузерам довольно всё равно какую кашу из тегов написал верстальщик. Прочие браузеры, типа машин Брайля — в России например составляют 0% от общего числа. Поэтому вёрстка html5 тегов — важна для роботов, и только.
• Описания довольно размыты и их толкование во многом субъективно. В html 4.01 было меньше разночтений.
• Очень мало примеров. В идеале — нужно создать сайт, html5samples — где собрать типовые примеры вёрстки различных сайтов. Блога, Каталога, Магазина и т.п. С подсветкой при наведении того, какие теги использовались и описанием почему. Если бы были конкретные примеры — тогда бы и html5doctor.com был бы не нужен. Вот Bruce Lawson например сделал html5 тему для wordpress, уже хоть что-то.

В html есть клёвые "стерильные" элементы div и span названия которых ничего не значат. (С большой натяжкой div можно расшифровать как division). Я считаю эти имена лучше подходят для html тегов чем "семантические" названия.

WAI-ARIA и Микроформаты

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

<div style="font-size:30px;">some big big caption</div>

Несмотря ни на что — это полноценная html разметка. А затем вуаля

<div style="font-size:30px;" role="heading" aria-level="2">some big big caption</div>

Разметка показывает, что теперь это осмысленный заголовок второго уровня (конечно для тех же целей есть <h2>).

Либо у вас был такой код:

<h3>Елена Лунная</h3>
<address>askme@usabili.ru</address>

Который легко можно превратить в визитную карточку

<div class="vcard">
    <h3 class="fn n">
        <span class="given-name">Елена</span>
        <span class="family-name">Лунная</span>
    </h3>
    <address class="email">askme@usabili.ru</address>
</div>

У микроформатов преимуществ гораздо больше:

• Нет никакой иллюзии в том что они используются в основном для поисковиков и других ботов.
• Описания микроформатов всегда конкретны. Т.е. на каждый случай — свой микроформат.
• Они отлично документированы.
• В составлении микроформатов (например от Schema.org) активно участвуют сами поисковые системы — как следствие они уже хорошо поддерживаются ими.
• Их проще понять

Из недостатков:

• Их сложнее запомнить (если под рукой нет ссылки на wiki)
• Они занимают больше места чем теги. (Однако когда не было CSS, всевозможное оформление занимало ещё больше места в html коде).

Эксперимент

Итак... После статьи на html5doctor я решила поставить небольшой эксперимент, касающийся в основном html5 тегов. Я сделала вот такой макет страницы каталога онлайн магазина:

и спросила некоторых известных людей как бы они её сверстали, по пунктам. Текст письма был примерно такой:

I have a question about semantic markup online store pages .
I'm wondering which tags you would use for the following items (see
attachment picture):
1) a horizontal menu of links to different pages
2) the entire block containing the page header (logo, cart block, and a
horizontal menu).
3) the block containing the search filters (the most important
navigation in curtain shop)
4) one filters block
5) block containing shop items
6) block of one items (which includes photo, item title, etc.)
7) pagination
8) page footer.

Can I quote your answer in my blog?

Thank you.

Данный вопрос я послала разным веб-евангелистам. Многие конечно не ответили (например html5doctor, работа у них такая, не отвечать на вопросы) — это нормально. Однако не ответил кое-кто кто обещал — это досадно. Впрочем я не буду называть тех кто не ответил, лучше поприветствуем тех кто смог ответить. Итак:

Итак. Кто из моих дорогих читателей любит сложные задачи? В награду, обещаю вам большую статью с моими скучными рассуждениями о семантике html5-элементов в начале недели. =)

Задание простое, но интересное. Художница нарисовала рамку диалога, для новой онлайн игры. (ссылка http://usabili.ru/news_imgs/151/border7.png ). Требуется сверстать её на прозрачном фоне, примерно вот так:

1. Рамка должна растягиваться по высоте и ширине. Либо в зависимости от контента, либо при заданной ширине и высоте контейнера.
2. Не обязательна поддержка IE. (т.е. вы можете использовать любые современные CSS технологии: мультибекграунды, border-image и т.п)
3. Чем меньше html-тегов тем лучше (Надеюсь у вас получиться сделать что-то элегантнее чем таблица на 9 ячеек =)).
4. Чем меньше отдельных файлов графики — тем лучше. (ну, про "css спрайты" вы в курсе).
5. Без яваскриптов
6. Сам контейнер будет всегда с position:absolute (это может упростить вам задачу)

Через неделю подведём итоги.

P.S. Кстати я снова открыла комментирование статей без регистрации.

Неделю назад, мой друг и коллега Джелу спросил меня, как я отношусь к разметке Schema.org и правильно ли в целях продвижения использовать разметку для картинок которую предлагает яндекс в разделе справки — «Schema.org для Яндекс. Картинок».

Я до этого не обращала внимания что там нового у яндекса, а оказалось новый формат разметки они уже с ноября прошлого (2011) года поддерживают. А ввели его Google, Microsoft и Yahoo аж в июне. Что ж, обычные микроформаты сказала я, глянув один раз на пример. Глянув на пример второй раз я заметила что микроформаты как раз необычные. И более того, используют кажущуюся невалидной с точки зрения html разметку. Об этом я и хочу сегодня рассказать, надеюсь статья будет интересной.

Сегодня, мой друг и коллега Cavin прислал мне ссылку на статью с хабра — «Браузеры запутались в блочной модели для таблиц». Я считаю, что эта статья в полной степени показывает мои мысли о том, что в россии специалистов любого профиля очень мало.

Некий царь призвал трёх мудрецов и попросил объяснить следующий факт:
«почему, если в кувшин, доверху наполненный водой, опустить рыбу, вода не выливается».
Двое мудрецов представили подробнейшее обоснование. Третий опустил в кувшин рыбу. И вода вылилась.

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

Сегодня я зашла таки, на рекламированный Вадимом Макеевым портал Web-Standards.ru. И, на удивление обнаружила там перевод заметки «Why we don’t have a parent selector» Джонатана Снука, написанная, что символично, 10 октября прошлого года (10.10.10). Собственно вот ссылка на сам перевод — «Почему у нас нет селектора по родителю» 20.09.11.

Сама статья бесспорно хорошая, в ней говорится вообще о том как писать быстрый код, почему селектор потомков медленный, почему селектор родителя был бы ещё медленнее, однако не говорится почему собственно есть хоть одна причина такой селектор не сделать. Да, это будет медленно. Да, всем понятно что селектор по id самый быстрый. Но в любом случае мы говорим о миллисекундах машинного времени. Обычно этим можно принебречь если сайт нагружен картинками и потоковым видео.

Собственно я бы не стала об этом писать если бы не прочитала ещё в сентябре черновик селекторов четвёртого уровня. Т. е. то, что мы будем называть CSS4.
Ссылка: http://www.w3.org/TR/2011/WD-selectors4-20110929/#overview
В самом низу указан родительский селектор: $E > F , который выбирает элемент E, родитель элемента F.

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

Заключение

Безусловно, в тех проектах, в которых важна скорость работы в браузере — нет места подобным селекторам. Пример: проект, который я сейчас разрабатываю, расчитан на использования только в современных браузерах полностью исключая IE6-8, и возможно IE9 из-за их низкой скорости работы с dom; и тем не менее, в оформлении используются только селекторы id и класса; в яваскриптовом коде большинство селекторов заменены с jquery на нативные и т. п.

Т. е. каждый разработчик обязан представлять себе где и сколько времени отнимает выполнение его кода (css, js, html). Но при этом инструменты для того чтобы сделать «быстро и сразу» должны быть. Например на главной странице моего блога, менее 400 элементов в DOM, использование тормозящего селектора в данном случае вообще не будет заметно.

Спасибо что читаете мой блог! =)

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

http://usabili.ru/labs/css_opacity_bug.html — посмотрите эту страницу, на ней видно что у абсолютно позиционированного элемента внутри с прозрачностью, не работает z-index относительно другого элемента с прозрачностью. Т. е. он оказывается под ним, и соответственно красная ссылка в нём не доступна для клика. Красная ссылка в этом примере обрабатывается так как будто имеет z-index:0 или даже меньше, хотя это не так. Причём, при убирании свойства opacity у любого из элементов, или при перемещении элемента со ссылкой из прозрачного — ссылка становится рабочей.
Всё что говорится по этому поводу в спецификации css3: «If an element with opacity less than 1 is positioned, the ‘z-index’ property applies as described in [CSS21], except that ‘auto’ is treated as ‘0’ since a new stacking context is always created. See section 9.9 and Appendix E of [CSS21] for more information on stacking contexts». В упомянутых выше ссылках я не смогла найти точного ответа. Чтобы разобраться я отправила письма Яну Хигсону (hixie), который рекомендовал задать вопрос в лист рассылки www-style@w3.org, и Дэвиду Арону (dbaron), который ответил в топике багзиллы.

Ниже я публикую ответ этой загадки (пока в непереведённом виде):