rash

Боюсь, что нет. Картинки фиксированного размера? Кладите их под png-маску. Старо, дубово, но сделает то, что вам надо. Если размер нефиксированный — возможно, поможет canvas, но тут я не советчик.

Что касается привязки к структуре, то сейчас постараюсь привести пример, который это покажет. Надуманный, конечно, но, надеюсь, наглядный. Есть какой-нибудь блок b-promo. В нем есть красивая кнопка-ссылка на продукт, b-promo__link. Со временем появилась необходимость продвигать несколько продуктов, для чего в блоке были созданы вкладки, в корень вложили еще один элемент — b-tabs. При нынешнем подходе, даже внутри b-tabs ссылки b-promo__link будут оформлены как надо (если не повлияют наследуемые стили, но тут осторожность и внимательность нужна в любом случае). При вашем — .b-promo > .link уже перестанет работать. То есть это просто уменьшит универсальность. Такой подоход тоже может оказаться уместным, но в ограниченном количестве случаев. Вероятно, в БЭМ во главу угла поставлена универсальность в этом случае. При текущем положении вещей в браузерах будут выбраны все элементы, а уже на следующем шаге будут отфильтрованы только элементы верхнего уровня. Это эффективнее, чем просматривать все уровни как в селекторе .block .item, поскольку просматривать необходимо только один уровень, но менее эффективно, чем просто выбрать все .item в документе. Вы не знаете? И я не знаю. Но это ведь не значит, что ничто не мешает.

1. От IE 6 еще недавно нельзя было отказаться. 2. Это привязка к структуре (если элемент может лежать как в корне блока, так и в подэлементе, потребуется два селектора). 3. Ну и наконец (в большинстве случаев не так важно) — этот селектор менее эффективен, хоть и достаточно быстр по сравнению со многими другими.

Мне разгребать не приходилось, но видеть — видел, конечно. А кто-то говорил, что технология сама по себе не допускает неправильного, неуместного или просто неумелого применения? Испортить можно любую идеологию. Если не понимать ее. То же ООП всегда правильно применяется и никогда не приносит проблем вместо решений? Значит ли это, что идеология плоха? Нет.

Разумеется. Помогает.

Выучить CSS и использовать БЭМ, ясное дело.

А вот из этих ваших слов можно сделать вывод, что крупнее домашней страницы (разумеется, это метафора) вам вряд-ли приходилось что-то поддерживать. Просто от масштаба проекта моно зависит. Что хорошо для городского портала — может совершенно не подходить для крупного сервиса, и наоборот. Разумеется, полностью перенять гугло-яндексовый подход на среднем проекте может даже оказаться вредным, как и использовать подход к клиентской части домашней страницы на высоконагруженном и быстроразвивающемся сервисе. Просто у меня есть возможность сравнить. Вы, похоже, рассуждаете умозрительно.

Да если нужно только это, то и jQuery незачем, тянуть несколько десятков кб только ради того, что в нативном js будет записано в 8—10 строк. Переключение классов, один блок прячем, другой показываем.

А в чем говнокод? В том, что ее минимизировали? CSS как CSS для продакшена. Нет, это я к вот этому, например: .w-sport__addon{padding-bottom:8px} .w-sport__addon .b-dropdown__visible{padding:5px 9px 0 0} .w-sport__addon .b-dropdown__popup .b-dropdown__visible{padding:1px 9px 4px 7px} Действительно, очень рационально! Контекстом переопределять одно и то же стилевое свойство. И при этом в документации на сию "систему ООП" писать про контекстное наследование - "ФИ!"... Как там? "Если поместим блок в другое место кода, стили все равно будут работать!"? Эээ, а ничего, что если перенести блок b-dropdown в другое место, он продолжит работать, и если перенести w-spot в другое место, он тоже будет работать? Тем более, что скорее всего именно этот случай относится к конкретной странице, и не влияет на эти же блоки на других страницах, то есть это не в глобальном определении блока, а в более локальном переопределении написано. Ничего ужасного не вижу. Описан общий случай, и уточнен в конкретной ситуации. Вполне ОК. Тем более, что контекстные селекторы плохи в общем случае, но они могут быть полезны в некоторых ситуациях. К примеру, "html body div ul li a {…}" — плохо, но ".b-list_highlighted_yes .b-list__item {…}" — нормально. Гм, опять же, на специфичности завязан тот минимум, который необходим не во вред. Ну и я не уверен, что отчетливо понимаю, что там под капотом, и почему на выходе получается тот или иной код. К тому же не каждый сервис обязан использовать последние наработки, может где-то устаревший код, где-то устаревший инструментарий и т. п. Как идеологический подход — штука хорошая. На практике не всегда удается использовать все в полной мере, я уверен. Так почти всегда и везде бывает, «добро пожаловать в наш дерьмовый мир обратно» © Масяня.

А в чем говнокод? В том, что ее минимизировали? CSS как CSS для продакшена.

Да, про меню мне тоже интересно. Вижу в них как недостатки, так и преимущества, но чтобы только недостатки - это как-то чересчур.

Забавно, что многие задачи, помеченные как зло, при нормальном приготовлении ничего страшного собой не представляют. Где вы находите только ужасных применений, чтобы делать такие выводы?

Ой, ошибаетесь, впрочем как и я года полтора-два назад. БЭМ как технология, может (даже точно) нужен не всем, а вот от его составляющей - подхода АНБ точно никому хуже не будет. Подход полезный, простой, и позволяет избежать многих глупостей при следовании простым правилам. А почему этот подход и технология поначалу у многих верстальщиков вызывают неприязнь - мне искренне не понять. И даже при том, что сначала я относился так же, сейчас объяснить себе причину не могу.

В вашем случае нужно что-то вроде .b-slider__title-emphasis, но не .b-slider__title__emphasis, в этом все дело.

Тогда обертку и марджин 4 px для IE (в IE можно полагаться на 4 px в большинстве случаев), для остальных - box-sizing

box-sizing: border-box для инпута не поможет?

вообще-то type="hidden" решило бы вашу проблему так, как надо.

А вам точно нужно два обработчика? Не получится обойтись одним, который будет выполнять разные действия, в зависимости от того, какая кнопка была нажата?

Обычно делаю поиском и заменой в редакторе. Можно искать и заменять в выделенном тексте. Если редактор умеет макросы, то для HTML достаточно 4-х проходов (<, >, &, "), делается запуском одного макроса или скрипта. Вообще в этом слчае можно не заменять >, но для визуального порядка я все равно заменяю.

Никогда не перестану удивляться, сколько всего не знаю. Ну это, впрочем, нормально А как?

Да, уверен. Делается это с помощью :target (SelenIT уже указал ссылку на описание), и во всяком случае в вебкитах при этом навигация работает нормально. В остальных не проверял даже, демонстрировали-то в хроме

Гм, а вот это правда уже интереснее Как-то никогда не сомневался, что в рамках css 2.1 - только одну.

1. знаю ответ 2. Media queries? 3. можно без js %)

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

Спасибо. После такого вопроса теперь остро чувствую необходимость выучить все, что знал, но забыл, еще раз