Эту статью, как и прошлую, и будущую, мы держим в памяти :)
Просто я не уверен, стоит ли в включать в дайджесты отдельные части большого материала, если позже их можно будет выложить как цельный результат (например, как тот же Инлайновый контекст форматирования)
Ссылки на статьи и переводы с вашего ресурса есть практически в каждом нашем дайджесте ;)
На счет проблемы в переводчиках, то проблема не столько в их наличии, сколько в дефиците свободного времени :(
Ну оно-то ясно, что многие штуки будут работать в последних вебкитах и опере, возможно в ФФ, но это на уровне прототипов. На коммерческих и клиентских проектах все равно не получится использовать.
Стоит также отметить, что для одиночных тегов, не содержащих в себе контент, псевдоэлементы особо не поюзаешь. Т.е. всякого рода img, input, br пролетают
Надеюсь, что прежде чем они закинут этот гриб на мусорный остров или городскую свалку, сначала исследуют весь его рацион, а то возможно помимо полиуретана он не прочь полакомиться человеченкой, а то что-то такое открытие напоминает начало ужастиков девяностых :)
Отличная база для создания своего статического фреймворка.
Плюс, рекомендую смотреть версию с комментариями, там для каждого тега и свойства расписано, почему сделано так, а не иначе. И высосано оно не из пальца, а за каждой техникой лежит серьезный рисерч. Например, тот же метод image replacement, который здесь как-то обсуждался.
Среди его разработчиков, кстати, такие товарищи как Nicolas Gallagher и Paul Irish
Для того, чтобы селекторы не действовали на более широкий круг элементов, как раз и следует давать уникальные названия классам.
А в вашем методе проблема может всплыть в случае, если даже немного изменится структура тегов. При имплементации дизайна на сложных cms такое возможно. Или в будущем какой-нибудь программист, которому передали проект, решит поменять местами теги по запросу клиента. Или сеошник попросит .title заменить на (чисто гипотетическая ситуация). Во всех этих случаях прямая наследованность будет нарушена и дизайн сломается.
Я не спрорю, что «>» — часто полезная штука, но не следует опираться на нее при верстке целых логических блоков.
Просто я не уверен, стоит ли в включать в дайджесты отдельные части большого материала, если позже их можно будет выложить как цельный результат (например, как тот же Инлайновый контекст форматирования)
На счет проблемы в переводчиках, то проблема не столько в их наличии, сколько в дефиците свободного времени :(
Give me a kiss to build a dream on
And my imagination will thrive upon that kiss
Sweetheart, I ask no more than this
A kiss to build a dream on…
Плюс, рекомендую смотреть версию с комментариями, там для каждого тега и свойства расписано, почему сделано так, а не иначе. И высосано оно не из пальца, а за каждой техникой лежит серьезный рисерч. Например, тот же метод image replacement, который здесь как-то обсуждался.
Среди его разработчиков, кстати, такие товарищи как Nicolas Gallagher и Paul Irish
А в вашем методе проблема может всплыть в случае, если даже немного изменится структура тегов. При имплементации дизайна на сложных cms такое возможно. Или в будущем какой-нибудь программист, которому передали проект, решит поменять местами теги по запросу клиента. Или сеошник попросит .title заменить на (чисто гипотетическая ситуация). Во всех этих случаях прямая наследованность будет нарушена и дизайн сломается.
Я не спрорю, что «>» — часто полезная штука, но не следует опираться на нее при верстке целых логических блоков.
Возможно, пару новых ресурсов пригодятся
Сейчас не уверен, как сделать адекватный экспорт в гугл-ридере с сохранением структуры и всего такого