шрифты как раз убоднее раскрашивать чем каждый SVG в отдельности
Зачем каждый SVG раскрашивать? В спрайте у path fill="currentColor" и всё - иконка вставленная из спайта через <svg><use href="id"></use></svg> прекрасно красится через CSS color так же как и шрифтовая иконка
Да тут как удобнее, у нас в одном проекте используются шрифты, благо иконок там не сказать чтоб сильно много, они разбиты по разным шрифтам пачками по десятку-двум штук (ну например по разделам сайта) и собраны в https://icomoon.io/. Но добавление иконок или правка по факту это обновление шрифта полностью, и перегрузка его на клиентах может происходить довольно долго из кешей браузера, если специально ему не выставлять что-то типа номера версии, но это опять же еще и править стили с font-face.
В другом проекте для новой верстки мы использовали svg-спрайты. Это проще, меняется только спрайт-файл, который в текстовом формате svg по факту и его проще править, проще автоматически генерировать и т.п.
Еще одна особенность шрифтов в том, что в разных OS растрирование шрифтов таки разное, более того, даже в Windows оно зависит от настроек CrearType, и для не особо больших размеров иконок это может давать забавные артефакты (например под OSX/MacOS шрифты рендерятся чуть жирнее, а в Linux вообще технология сглаживания отличная от всего). SVG же практически одинаково рендерятся на разных платформах
А systemd умеет перенаправлять stdout/stderr в соответствующие логи? Напомню - условный скрипт не умеет ничего списать в логи сам, ему и не надо. Понятно, что в systemd в данный момент много перекрывающего с supervisord, но он и вышел когда никакого systemd не было
Проблема шрифтов - их нельзя делать цветными, то есть красится через стиль все целиком. Вернее (как у гугла) их можно сделать разноцветными, но не перекрашивать через CSS. SVG спрайты могут содержать что угодно, и цветные иконки, и перекрашиваемые через fill="currentColor". Ну а сами спрайты можно вгружать в body как статику из файлов через JS (они еще и браузером кэшируются).
Другая проблемка шрифтовых иконок, особенно подвязанных через <i> - это инлайновость элемента по-определению, контроль за его размером через CSS это отдельная боль, тут и геометрия и font-size, и что начнется, если оно не очень совпадает и имееет прозрачный фон лучше не показывать. В этом смысле <svg><use> гораздо удобнее
Ладно VGA на видяшках нет современных, так еще и DVI-D остался разве что на 3050 и то не везде. А счастливым обладателям 2k мониторов с DVI-D Dual Link Only (Apple Cinema Display 30" например) приходится искать не дешевые активные конвертеры DisplayPort -> Dual Link DVI
Такой "TW-псевдо-CSS" совершенно спокойно будет рабоать и изначально зеленый квадратик станет при разрешении 640px синим, а на 768px красным и при навдении полупрозрачным
Их "рекомендация" не делать так – всего лишь рекомендация, да и причины сильно надуманны (по-моему мнению). Способов использования TW дохера и больше, нам нравится @apply потому что позволяет:
Смиксить TW в HTML и TW в CSS через тот самый @apply, то есть можно подверстать какой-то прототип быстро прямо в html, а потом при необходимости перенести все в исходник TW-CSS. Если хочется.
Компилятор TW проверяет использование всех классов в исходных html/js файлах, на выходе не будет неиспользованных стилей. То есть в любом случае по html файлам надо генерить CSS компиляторов от TW. А если использовать полный TW-CSS со всеми фичами, это охереть какой раздутый CSS.
Как раз управление псевдоэлементами внутри исходного описания класса, и поведением на разных разрешениях тоже в одном этом месте. (написав в одном месте у класса w-full sm:w-1/2 md:w-1/3 мне надо копировать в каждый блок медиа все эти переопределения и т.п.)
TW дает упрощенную нормализованную систему базовых величин типа размера шрифтов, отступов и т.п. Плюсом темы с пользовательскими цветами например (по факту это тоже переменные). И для этого не надо вспоминать как там оно вообще устроено в CSS, не надо копаться в доке работает ли какая-то современная фича и где, никаких вендор префиксов и другой ереси для не профессионального верстальщика.
Преимущество в том, что всякие псевдоэлементы и поведение можно указать прямо в коде элемента или класса, не создавая для этого хтрые портянки из классов в css
Ну считайте, цена CS3 MC в том древнем году это 30 месяцев вашей нынешней подписки.
С одной стороны подписка удобнее, с другой удобнее офф-лайн покупка всего сразу. Хоть даже без обновлений. Подписка была бы удобнее если бы деньги брались за факт использования, к примеру если я не запускал в этом месяце никакой продукт - то и платить я за это не должен по идее.
Ну я всеж про «ручки» применительно к программным продуктам. У них аналогично приборчикам могут быть «ручки», в результате изменения положения которых - поведение программы может меняться. По сути эти самые «ручки» либо переменные в конфиге, либо какие-то feature flags
Зачем каждый SVG раскрашивать? В спрайте у path fill="currentColor" и всё - иконка вставленная из спайта через <svg><use href="id"></use></svg> прекрасно красится через CSS color так же как и шрифтовая иконка
Отлично. Не особо разбирался в таких фичах, ибо исторически какие-то вещи работали и работают в супервайзоре когда systemd даже в планах не было
Да тут как удобнее, у нас в одном проекте используются шрифты, благо иконок там не сказать чтоб сильно много, они разбиты по разным шрифтам пачками по десятку-двум штук (ну например по разделам сайта) и собраны в https://icomoon.io/. Но добавление иконок или правка по факту это обновление шрифта полностью, и перегрузка его на клиентах может происходить довольно долго из кешей браузера, если специально ему не выставлять что-то типа номера версии, но это опять же еще и править стили с font-face.
В другом проекте для новой верстки мы использовали svg-спрайты. Это проще, меняется только спрайт-файл, который в текстовом формате svg по факту и его проще править, проще автоматически генерировать и т.п.
Еще одна особенность шрифтов в том, что в разных OS растрирование шрифтов таки разное, более того, даже в Windows оно зависит от настроек CrearType, и для не особо больших размеров иконок это может давать забавные артефакты (например под OSX/MacOS шрифты рендерятся чуть жирнее, а в Linux вообще технология сглаживания отличная от всего). SVG же практически одинаково рендерятся на разных платформах
А systemd умеет перенаправлять stdout/stderr в соответствующие логи? Напомню - условный скрипт не умеет ничего списать в логи сам, ему и не надо.
Понятно, что в systemd в данный момент много перекрывающего с supervisord, но он и вышел когда никакого systemd не было
Ну городить systemd обвязку для какого нить условного скрипта на nodejs/python/php с контролем его работы это лютый оверхед как по мне.
Проблема шрифтов - их нельзя делать цветными, то есть красится через стиль все целиком. Вернее (как у гугла) их можно сделать разноцветными, но не перекрашивать через CSS. SVG спрайты могут содержать что угодно, и цветные иконки, и перекрашиваемые через fill="currentColor". Ну а сами спрайты можно вгружать в body как статику из файлов через JS (они еще и браузером кэшируются).
Другая проблемка шрифтовых иконок, особенно подвязанных через <i> - это инлайновость элемента по-определению, контроль за его размером через CSS это отдельная боль, тут и геометрия и font-size, и что начнется, если оно не очень совпадает и имееет прозрачный фон лучше не показывать. В этом смысле <svg><use> гораздо удобнее
Ладно VGA на видяшках нет современных, так еще и DVI-D остался разве что на 3050 и то не везде. А счастливым обладателям 2k мониторов с DVI-D Dual Link Only (Apple Cinema Display 30" например) приходится искать не дешевые активные конвертеры DisplayPort -> Dual Link DVI
Ну Гонгконг конечно КНР, но Keenetic это, внезапно, имеет российские корни
Вы не поверите – оно так всё там и работает
before:bg-green sm:before:bg-blue md:before:bg-red md:before:hover:bg-opacity-50
Такой "TW-псевдо-CSS" совершенно спокойно будет рабоать и изначально зеленый квадратик станет при разрешении 640px синим, а на 768px красным и при навдении полупрозрачным
Их "рекомендация" не делать так – всего лишь рекомендация, да и причины сильно надуманны (по-моему мнению). Способов использования TW дохера и больше, нам нравится
@apply
потому что позволяет:Смиксить TW в HTML и TW в CSS через тот самый
@apply
, то есть можно подверстать какой-то прототип быстро прямо в html, а потом при необходимости перенести все в исходник TW-CSS. Если хочется.Компилятор TW проверяет использование всех классов в исходных html/js файлах, на выходе не будет неиспользованных стилей. То есть в любом случае по html файлам надо генерить CSS компиляторов от TW. А если использовать полный TW-CSS со всеми фичами, это охереть какой раздутый CSS.
Как раз управление псевдоэлементами внутри исходного описания класса, и поведением на разных разрешениях тоже в одном этом месте. (написав в одном месте у класса
w-full sm:w-1/2 md:w-1/3
мне надо копировать в каждый блок медиа все эти переопределения и т.п.)TW дает упрощенную нормализованную систему базовых величин типа размера шрифтов, отступов и т.п. Плюсом темы с пользовательскими цветами например (по факту это тоже переменные). И для этого не надо вспоминать как там оно вообще устроено в CSS, не надо копаться в доке работает ли какая-то современная фича и где, никаких вендор префиксов и другой ереси для не профессионального верстальщика.
Преимущество в том, что всякие псевдоэлементы и поведение можно указать прямо в коде элемента или класса, не создавая для этого хтрые портянки из классов в css
Например
И получим ссылку в которой сразу указано прведение при наведении, а еще у нее спереди зеленый квадратик в псевдоэлементе before
Слишком длинные кострукции заменяются на кастом классы через директиву
@apply.
Например
Можно поменять на
С указанием во входном css файле
Ну считайте, цена CS3 MC в том древнем году это 30 месяцев вашей нынешней подписки.
С одной стороны подписка удобнее, с другой удобнее офф-лайн покупка всего сразу. Хоть даже без обновлений. Подписка была бы удобнее если бы деньги брались за факт использования, к примеру если я не запускал в этом месяце никакой продукт - то и платить я за это не должен по идее.
Знакомо, но в моем случае это всего одна ночь, когда сдох монитор, а под рукой был только чб от рипа :-)
Ну я всеж про «ручки» применительно к программным продуктам. У них аналогично приборчикам могут быть «ручки», в результате изменения положения которых - поведение программы может меняться. По сути эти самые «ручки» либо переменные в конфиге, либо какие-то feature flags
Не в курсе сколько лет автору, но я про ручки тожне не понял. Они у приборов еще и 100 лет назад были, их не дергают, их крутят, понимаешь
Обезьянки и Stylus немного для разного, но вполне могут дополнять друг друга.
Очень смешно.... Сколько там в год подписка на MasterCollection?
А тут разок заплатил полтора килобакса. Не, в 2024 года CS3 конечно не очень актуальная версия, но вполне рабочая и без всех этих AI свисто-перделок
для intel/nvidia не скажу, у amd это конечно sapphire/powercolor
Резинистое это литьевые полиуретаны разве что. Ну и окончательная жесткость там всеж регулируется количеством "отвердителя"