Alexander-K: это значит, что у слоя остаются видимы только те пиксели, которые темнее пикселей под слоем.
Вот вам пример: joxi.ru/LQ2KpajCyvKqAj — серый фон, красно-белый слой на нём.
Если поставить darken, то красный цвет останется виден (т.к. он темнее серого фона), а белый исчезнет (т.к. он, соответственно, светлее): joxi.ru/752akLJSgkjvr0
В общем, в вашем случае, думаю, проще всего обратиться к дизайнеру с просьбой нормально подготовить лого к вёрстке, либо вырезать эти дырки самому. Либо, если лого относительно фона никак не смещается, свести его с фоном. Потому что режимы наложения в CSS пока что не поддерживаются (хотя будут).
Вообще, хороший дизайнер должен это знать и не использовать режимы наложения для таких вот ухищрений в случаях, когда слой нужен отдельно.
Роман: текст в псевдоэлемент в данном случае — не вариант, потому что текст является подписью к картинке. Как вы будете content псевдоэлемента указывать извне, не в css?)
Алексей Лебедев: дело не в красоте кода, а в расширяемости и поддерживаемости. Поскольку в обоих вариантах вы используете глобальную функцию, особой разницы между ними я не вижу (ну, разве что, в случае с on вы сможете обработчик убить, если понадобится).
Антон Мудренок: в общем, мой ответ немного не в тему, потому что он скорее не про "как нарисовать", а про то, как потом с этим полем взаимодействовать. Т.е. эта штука предоставляет достаточно удобное управление гексами, сетка основана на rgb-координатах. Правда, автор, похоже, забросил проект — уже давно никаких новостей по нему нет :(
Иван Антонов: а какая разница? Он просто сравнивает исходный файл с закэшированным. Если поставить там флаг optimizeMemory, то сравнивать будет по контрольной сумме. Я его нарыл вот в этой статье, если что: ymatuhin.ru/front-end/see_into_gulp — там много ещё чего полезного. Но сам мой сборщик работает на основе статьи, которую я указал в первом комменте, и я его постепенно наращиваю всякими фишками.
Чего там осваивать и настраивать, сейчас статей на хабре море по этой тематике. Вот, к примеру, самая популярная: habrahabr.ru/post/250569
Правда, в представленном в ней варианте сборщика есть недостатки:
— Не глотает ошибки, т.е. при любом неправильно написанном коде вылетает livereload и watch, что при прямых руках и наличии гугла правится мгновенно;
— Пересобирает даже не изменившиеся файлы, что легко решается с помощью gulp-cached;
— Не собирает спрайты (что тоже допиливается очень легко с помощью соответствующих пакетов).
А ещё можно воспользоваться yeoman.io , где очень много разных вариантов сборщиков под любые запросы.
Иван Антонов: совмещать их на одном проекте достаточно глупо, на мой взгляд. БЭМ слишком самодостаточен (я про bem-tools и прочие приколы), чтобы дополнять его совершенно другой с идеологической точки зрения разработкой. А вот в зависимости от требований проекта использовать либо одно, либо другое — уже более оптимально. Но учить придётся и то и то тогда :)
Valery Semenencko: мне готовые примеры не очень подходили, из-за большой переизбыточности кода и стилей в них, а так же из-за КРЕАТИВНОСТИ наших замечательных дизайнеров, которые либо не делают сетку вообще из каких-то своих соображений, либо делают какую-то хитрую свою. Т.е. всё равно пришлось бы много переделывать в стилях этих фреймворков.
Просто со временем у меня для большинства типовых элементов выработались некоторые паттерны, которые мне показались удобными, и которые я стал переносить из проекта в проект.
Проекты у нас достаточно небольшие в основном, поэтому тот же БЭМ был бы слишком громоздким, и пришлось придумать свою достаточно простую систему организации стилей, которая в связке с этими самыми html-паттернами и дала эти переиспользуемые кусочки.
А вот с переопределением уже созданных кем-то стилей зачастую морока та ещё, и своя методология тут не помогает: приходится либо использовать неправославный !important, либо через девтулс смотреть вес селекторов и как-то его перебивать своими. Либо уже лезть в их стили и убивать то, что мешает, но это во многих случаях опасно делать: есть вероятность использования этих стилей в каком-то совершенно другом месте, где всё возьмёт и полетит в таком случае.
Назар Мокринский: спасибо за наводку, при случае обязательно их попробую) Выглядит интересно. Правда, полно споров по поводу совмещения стилей, вёрстки и скриптов в одном месте. Но в обсуждениях Реакта споры точно такие же, а инструмент тем не менее крутой.
Назар Мокринский: да пользуются все, просто все понимают разные вещи под этим. Да и я от проекта к проекту под словом "компонент" зачастую понимаю разные вещи. В данном случае я имел в виду готовую структуру кода, которую привык использовать, скажем, для форм. Определённые названия классов для всех инпутов и контролов, определённую переиспользуемую структуру вёрстки, плагин валидации, заранее настроенный на всё это. Ну, это в случае с формами. В случае с другими вещами — аналогично.
Точно-точно, разработка в разы ускоряется. У меня, к примеру, есть стандартный набор веб-компонентов, который постоянно пополняется, и они очень легко переиспользуются. Особенно когда используешь методологию (БЭМ, MCSS, или что-то своё), очень легко подключать компонент в новый проект, остаётся только его стилизовать, и он уже работает.
Вот вам пример: joxi.ru/LQ2KpajCyvKqAj — серый фон, красно-белый слой на нём.
Если поставить darken, то красный цвет останется виден (т.к. он темнее серого фона), а белый исчезнет (т.к. он, соответственно, светлее): joxi.ru/752akLJSgkjvr0
В общем, в вашем случае, думаю, проще всего обратиться к дизайнеру с просьбой нормально подготовить лого к вёрстке, либо вырезать эти дырки самому. Либо, если лого относительно фона никак не смещается, свести его с фоном. Потому что режимы наложения в CSS пока что не поддерживаются (хотя будут).
Вообще, хороший дизайнер должен это знать и не использовать режимы наложения для таких вот ухищрений в случаях, когда слой нужен отдельно.