Figma и разработка дизайна.
Так вышло, что вчера у нас заказали разработку интернет-магазина. Вообще в последнее время меня настигает какая-то совершенно неожиданная череда событий в жизни, но это проиcшествие не ожидал никто, конечно. Можно считать, то первый год обучения программированию закачивается первым коммерческим проектом для меня и @syth0le.
Но не в этом суть! Хочу рассказать о Figma. Этот инструмент мне казался очень популярным, но как оказалось, для некоторых людей это просто откровение.
Я использую Figma во всех своих проектах - начиная от разработки сайтов и заканчивая дизайном приложений. Мой стаж работы в Photoshop и Illustrator на данный момент - 6 лет, что огромная цифра для моего возраста (а я напомню, что мне 19). За эти 6 лет я успел закончить более 2 тысяч работ, выполнить десятки заказов на фрилансе, посотрудничать с крупными блогерами, и как бы я не любил этот инструмент, сейчас я всё сильнее отказываюсь от него и перехожу в Figma. Но почему?
1. Лаконичность инструментов и простота.
Мне явно есть с чем сравнить и я могу сказать, что тут Figma далеко впереди. Интерфейс не перегружен, но при этом есть все самые необходимые инструменты, которых хватает в 99% случаев. Интерфейс программ Adobe перегружен. Да, функций действительно больше и они достаточно полезны в некоторых ситуациях, но разработчикам UI эти инструменты просто не нужны.
2. Удобный экспорт.
Удобный экспорт - это что-то, люди с опытом меня поймут. В то время, как в Figma экспорт футажа проходит в 3 клика, в продуктах Adobe с этим огромные проблемы, о которых даже зарекаться страшно. Без перебирания всех слоёв экспортировать отдельный объект на столько удобно, как в Figma, просто невозможно.
3. Figma бесплатен.
Может и не очень актуально в потребительском секторе СНГ, но всё же, например, для бизнеса это очень серьёзный удар. Тут без комментариев.
4. Совместная работа.
Над одним проектов в едином поле может работать сразу несколько дизайнеров. Это очень удобно, в разы ускоряет процесс разработки и скорость обмена информацией.
5. Встроенная система контроля версий.
Можно посмотреть кто, когда и как что-то изменил в проекте.
6. Возможность запустить презентационный макет на смарфоне/пк.
На примере приложений: хотите посмотреть как оно будет смотреться в самом смартфоне? Просто соедините действия нужных кнопок и перемещайтесь со своего устройства по готовому макету (пункт звучит как рекламная интеграция, горжусь собой)ᅠ
7. Удобная браузерная версия, она прекрасна.
Ничем не отличается от Desktop версии, потребляет мало ресурсов. Идеально, в общем-то.
Вот такой рассказ вышел. Без лишних слов и с чистой совестью рекомендую использовать Figma всем, это очень качественный и удобный инструмент для всех дизайнеров.
#web #mobile #progress #design
Так вышло, что вчера у нас заказали разработку интернет-магазина. Вообще в последнее время меня настигает какая-то совершенно неожиданная череда событий в жизни, но это проиcшествие не ожидал никто, конечно. Можно считать, то первый год обучения программированию закачивается первым коммерческим проектом для меня и @syth0le.
Но не в этом суть! Хочу рассказать о Figma. Этот инструмент мне казался очень популярным, но как оказалось, для некоторых людей это просто откровение.
Я использую Figma во всех своих проектах - начиная от разработки сайтов и заканчивая дизайном приложений. Мой стаж работы в Photoshop и Illustrator на данный момент - 6 лет, что огромная цифра для моего возраста (а я напомню, что мне 19). За эти 6 лет я успел закончить более 2 тысяч работ, выполнить десятки заказов на фрилансе, посотрудничать с крупными блогерами, и как бы я не любил этот инструмент, сейчас я всё сильнее отказываюсь от него и перехожу в Figma. Но почему?
1. Лаконичность инструментов и простота.
Мне явно есть с чем сравнить и я могу сказать, что тут Figma далеко впереди. Интерфейс не перегружен, но при этом есть все самые необходимые инструменты, которых хватает в 99% случаев. Интерфейс программ Adobe перегружен. Да, функций действительно больше и они достаточно полезны в некоторых ситуациях, но разработчикам UI эти инструменты просто не нужны.
2. Удобный экспорт.
Удобный экспорт - это что-то, люди с опытом меня поймут. В то время, как в Figma экспорт футажа проходит в 3 клика, в продуктах Adobe с этим огромные проблемы, о которых даже зарекаться страшно. Без перебирания всех слоёв экспортировать отдельный объект на столько удобно, как в Figma, просто невозможно.
3. Figma бесплатен.
Может и не очень актуально в потребительском секторе СНГ, но всё же, например, для бизнеса это очень серьёзный удар. Тут без комментариев.
4. Совместная работа.
Над одним проектов в едином поле может работать сразу несколько дизайнеров. Это очень удобно, в разы ускоряет процесс разработки и скорость обмена информацией.
5. Встроенная система контроля версий.
Можно посмотреть кто, когда и как что-то изменил в проекте.
6. Возможность запустить презентационный макет на смарфоне/пк.
На примере приложений: хотите посмотреть как оно будет смотреться в самом смартфоне? Просто соедините действия нужных кнопок и перемещайтесь со своего устройства по готовому макету (пункт звучит как рекламная интеграция, горжусь собой)ᅠ
7. Удобная браузерная версия, она прекрасна.
Ничем не отличается от Desktop версии, потребляет мало ресурсов. Идеально, в общем-то.
Вот такой рассказ вышел. Без лишних слов и с чистой совестью рекомендую использовать Figma всем, это очень качественный и удобный инструмент для всех дизайнеров.
#web #mobile #progress #design
🔥1
Нужен ли Bootstrap.
В front-end есть такой вечный холивар на тему Bootstrap'a. Очень часто я стал слышать мнение, что на самом деле Bootstrap не нужен и надо бы верстать без него. Сегодня попробую подробнее разобраться в том вопросе.
Ну и чтобы истину было гораздо проще вычленить, я предлагаю рассмотреть плюсы и минусы фреймворка:
1. Во-первых, плюсом будет унификация и стандартизация. Bootstrap будет понятен любому разработчику после вас, а код будет читаемым.
2. Во-вторых, фреймворк очень эффективен при быстрой разработке. Все классы уже готовы, нужно просто правильно распределить их по документу.
3. В третьих, не нужно изобретать свой велосипед. Часто начинающие разработчики пишут свои велосипеды, а это не имеет никакого смысла в коммерческой разработке, будем честны. Чаще всего новый продукт можно собрать из кусков других проектов и это вполне нормально, а главное - быстро и дёшево.
4. Неплохая адаптивность из коробки.
Ну и недостатки:
1. Нужно разбираться. Много есть классов, которые необходимо знать и уметь использовать. А для их изучения нужно время, это часто отпугивает людей.
2. Многие классы вообще не используются в разработке проекта. Тем более, если проект серьезный, то функционала фреймворка будет уже недостаточно и придётся так или иначе писать собственные стили.
3. Уменьшается скорость загрузки страницы, это иногда очень значительный показатель.
Как итог, ну нужен конечно. Лично по моему мнению, естественно. Нет смысла изобретать свои велосипеды от проекта к проекту, гораздо проще один раз выучить Bootstrap и понимать, что речь не идёт о полноценной замене файла каскадных стилей. Берём лучшее из двух миров и бед не знаем, я так считаю 🙂
#web #design
В front-end есть такой вечный холивар на тему Bootstrap'a. Очень часто я стал слышать мнение, что на самом деле Bootstrap не нужен и надо бы верстать без него. Сегодня попробую подробнее разобраться в том вопросе.
Ну и чтобы истину было гораздо проще вычленить, я предлагаю рассмотреть плюсы и минусы фреймворка:
1. Во-первых, плюсом будет унификация и стандартизация. Bootstrap будет понятен любому разработчику после вас, а код будет читаемым.
2. Во-вторых, фреймворк очень эффективен при быстрой разработке. Все классы уже готовы, нужно просто правильно распределить их по документу.
3. В третьих, не нужно изобретать свой велосипед. Часто начинающие разработчики пишут свои велосипеды, а это не имеет никакого смысла в коммерческой разработке, будем честны. Чаще всего новый продукт можно собрать из кусков других проектов и это вполне нормально, а главное - быстро и дёшево.
4. Неплохая адаптивность из коробки.
Ну и недостатки:
1. Нужно разбираться. Много есть классов, которые необходимо знать и уметь использовать. А для их изучения нужно время, это часто отпугивает людей.
2. Многие классы вообще не используются в разработке проекта. Тем более, если проект серьезный, то функционала фреймворка будет уже недостаточно и придётся так или иначе писать собственные стили.
3. Уменьшается скорость загрузки страницы, это иногда очень значительный показатель.
Как итог, ну нужен конечно. Лично по моему мнению, естественно. Нет смысла изобретать свои велосипеды от проекта к проекту, гораздо проще один раз выучить Bootstrap и понимать, что речь не идёт о полноценной замене файла каскадных стилей. Берём лучшее из двух миров и бед не знаем, я так считаю 🙂
#web #design
🔥1
Список доступных хештегов:
Основные:
#theory — общая теория программирования, разбор теоретических вопросов с собеседования
#quiz — короткий вопрос на свободную тему в разработке с вариантами ответов
#useful — просто полезные вещи
#blog — посты в формате блога обо мне / на свободную тему
Подгруппы:
#javascript — всё, связанное с языком
#typescript — аналогично👆
#code — посты во встроенным в текст кодом, готовые примеры
#vite — посты, которые так или иначе затрагивают сборщик
#web — всё, касательно web разработки
#principles — принципы проектирования
#react — всё, касательно React
#patterns — всё о паттернах
#data — всё о данных и манипуляциях с ними
#news — новости
#python — всё, связанное с этим языком
#mobile — мобильная разработка
#design — штучки для дизайна
#github — интересности с гита
#chatbot — мои боты и всё, что с ними связано
Основные:
#theory — общая теория программирования, разбор теоретических вопросов с собеседования
#quiz — короткий вопрос на свободную тему в разработке с вариантами ответов
#useful — просто полезные вещи
#blog — посты в формате блога обо мне / на свободную тему
Подгруппы:
#javascript — всё, связанное с языком
#typescript — аналогично
#code — посты во встроенным в текст кодом, готовые примеры
#vite — посты, которые так или иначе затрагивают сборщик
#web — всё, касательно web разработки
#principles — принципы проектирования
#react — всё, касательно React
#patterns — всё о паттернах
#data — всё о данных и манипуляциях с ними
#news — новости
@deprecated
#python — всё, связанное с этим языком
#mobile — мобильная разработка
#design — штучки для дизайна
#github — интересности с гита
#chatbot — мои боты и всё, что с ними связано
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Markdown и о документации к коду.
Для разогрева после перерыва начнём с достаточно простой, но интересной темы. Для многих не очевидно что такое markdown, да и вовсе большинство знакомы с ним на основе
Я говорю о нестандартных для многих способах применения. Одна из главных фишек markdown - его легкая транскрипция в другие более сложные языки разметки. А это значит, что ваш размеченный текст может быть легко преобразован в, например, HTML, XML и т.д. (для этого, кстати, есть уже готовые библиотеки почти для всех популярных языков программирования). Всё зависит от ваших задач, но чаще всего даже транскриптор писать самому далеко не обязательно. Также markdown максимально упрощён и даже имеет вокруг себя кучу графических интерфейсов, которые позволят сделать классную разметку даже компьютерному динозавру.
Всё это значит лишь то, что такой простой инструмент может стать классным подспорьем в ведении документации, отчётности, создании контента и почти любой другой работе с текстом.
Один из реально достойных примеров - сайт веб стандартов. Лично для меня было удивлением, что все статьи на сайте - просто отрендеренные markdown файлики из их репозитория с гитхаба. Решение простое, но гениальное и интуитивно понятное. Каждый желающий просто создаёт файл разметки и статья на сайте готова. Любые изменения уже существующих файлов или добавление новых файлов в репозиторий мгновенно отобразятся на сайте. Таким образом, управление контентом не требует никаких изощрений, вложений, лишней работы и, к тому же, централизовано. По сути, из-за markdown, гитхаб - панель управления контентом для вашего сайта.
Но в названии всё же есть о документации. К чему это я? К тому, что существует 1001 инструмент для создания документации на основе markdown. Чего только стоят, например, Swagger и Markmap. Первый позволяет максимально быстро и просто, а что главное - читаемо, создать качественную документациию к любому REST API, а второй позволит визуализировать markdown в виде интерактивного mind map. Если вам не требуется отдельный инструмент для документирования, то пользоваться markdown можно в чистом виде, тот же гитхаб сделает всё за вас и преобразует текст в понятные и красивые файлы.
И реализовать ведь можно действительно всё что угодно:
— управление контентом
— создание отчётности о тестировании
— любая документация
— редакторы разной направленности (переводим разметку в презентации, например)
— заметки
— выведение статистики (преобразование текста в графики)
— и так далее
Простота и лёгкость в изучении - ключевые в этом плане качества. Сконцентрируйтесь на наполнении, а не на мыслях о внешнем виде. Не нужно ничего выдумывать - просто используйте markdown.
Какие-то такие мысли.
#design #useful #web #github
Для разогрева после перерыва начнём с достаточно простой, но интересной темы. Для многих не очевидно что такое markdown, да и вовсе большинство знакомы с ним на основе
README.md
файлов на гитхабе, например. Но на самом деле это куда более масштабная технология в моём понимании. Если пойти по теории, то Markdown - это очень легкий язык разметки для обычных человеческих текстов. Большинство воспринимают этот язык разметки не слишком серьёзно, что, как мне кажется, немного ошибочно. В моём понимании markdown достоин куда больше внимания, чем многие думают.Я говорю о нестандартных для многих способах применения. Одна из главных фишек markdown - его легкая транскрипция в другие более сложные языки разметки. А это значит, что ваш размеченный текст может быть легко преобразован в, например, HTML, XML и т.д. (для этого, кстати, есть уже готовые библиотеки почти для всех популярных языков программирования). Всё зависит от ваших задач, но чаще всего даже транскриптор писать самому далеко не обязательно. Также markdown максимально упрощён и даже имеет вокруг себя кучу графических интерфейсов, которые позволят сделать классную разметку даже компьютерному динозавру.
Всё это значит лишь то, что такой простой инструмент может стать классным подспорьем в ведении документации, отчётности, создании контента и почти любой другой работе с текстом.
Один из реально достойных примеров - сайт веб стандартов. Лично для меня было удивлением, что все статьи на сайте - просто отрендеренные markdown файлики из их репозитория с гитхаба. Решение простое, но гениальное и интуитивно понятное. Каждый желающий просто создаёт файл разметки и статья на сайте готова. Любые изменения уже существующих файлов или добавление новых файлов в репозиторий мгновенно отобразятся на сайте. Таким образом, управление контентом не требует никаких изощрений, вложений, лишней работы и, к тому же, централизовано. По сути, из-за markdown, гитхаб - панель управления контентом для вашего сайта.
Но в названии всё же есть о документации. К чему это я? К тому, что существует 1001 инструмент для создания документации на основе markdown. Чего только стоят, например, Swagger и Markmap. Первый позволяет максимально быстро и просто, а что главное - читаемо, создать качественную документациию к любому REST API, а второй позволит визуализировать markdown в виде интерактивного mind map. Если вам не требуется отдельный инструмент для документирования, то пользоваться markdown можно в чистом виде, тот же гитхаб сделает всё за вас и преобразует текст в понятные и красивые файлы.
И реализовать ведь можно действительно всё что угодно:
— управление контентом
— создание отчётности о тестировании
— любая документация
— редакторы разной направленности (переводим разметку в презентации, например)
— заметки
— выведение статистики (преобразование текста в графики)
— и так далее
Простота и лёгкость в изучении - ключевые в этом плане качества. Сконцентрируйтесь на наполнении, а не на мыслях о внешнем виде. Не нужно ничего выдумывать - просто используйте markdown.
Какие-то такие мысли.
#design #useful #web #github
Сказ о том, как я HTML в JPG конвертировал...
Обычно, когда я пишу посты в канал, я использую фотошоп для создания картиночки к нему. Эта картинка присутствует у подавляющего большинства постов и я думаю для многих это уже неотъемлемая часть стиля всего канала. И часто эта самая картинка — большая проблема для меня. Для её создания мне нужен сам фотошоп, время, куча ненужных действий и вот это вот всё неприятное. И пусть я делаю всё это по шаблону, который подготовил заранее, даже тут моя лень находит способ помешать мне. А лень — двигатель прогресса, это уж точно.
В общем, проблем несколько:
— Лень
— Занимает относительно много времени и не приносит удовольствия
— Посты можно оформить только с ПК
— Я счастливый обладатель MacBook на M1, так что для нормальный работы в Photoshop нужно тратиться на лицензию
Я решил найти другое решение: бесплатное, быстрое, удобное и кросс-платформенное. И нашел.
Для решения задачи я хотел использовать
Ну и, соответственно, я решил использовать
Я быстро накатил первую попавшуюся из поиска библиотеку node-html-to-image, воспользовался неплохой документацией, сверстал максимально странный, но рабочий макет и вот, мой
В итоге, процесс создания картинки максимально упрощён. Я могу оформить пост с любого устройства, где поддерживается клиент телеграмма (то есть даже с утюга), мне не нужно платить за подписку на Photoshop и я даже могу делегировать создание постов на кого-то куда проще.
Всё это написано крайне криво, неказисто, без нормальной архитектуры и, даже, как такового код-стайла, в паре файликов. Но оно работает. И мне этого достаточно. Я не вижу смысла тратить время на вылизывание кода, которым буду пользоваться только я, это элементарно экономически не выгодно. Но если вдруг перед кем-то встанет такая-же задача, то на моё решение можно посмотреть здесь.
Можно было написать лучше, может быть на питоне это генерировалось бы за миллисекунды, мне плевать. Оно работает и выполняет свою задачу более чем удовлетворительно. Картинка к этому посту уже сделана через бота. Сравнив её с прошлыми, где все сделаны вручную, я думаю, вы оцените качество результата. Можете, кстати, поискать на картинке пасхалку. Милая штука, на мой взгляд.
Делюсь. Вот. Спасибо за прочтение, это правда важно для меня.
#blog #useful #github #design #chatbot
Обычно, когда я пишу посты в канал, я использую фотошоп для создания картиночки к нему. Эта картинка присутствует у подавляющего большинства постов и я думаю для многих это уже неотъемлемая часть стиля всего канала. И часто эта самая картинка — большая проблема для меня. Для её создания мне нужен сам фотошоп, время, куча ненужных действий и вот это вот всё неприятное. И пусть я делаю всё это по шаблону, который подготовил заранее, даже тут моя лень находит способ помешать мне. А лень — двигатель прогресса, это уж точно.
В общем, проблем несколько:
— Лень
— Занимает относительно много времени и не приносит удовольствия
— Посты можно оформить только с ПК
— Я счастливый обладатель MacBook на M1, так что для нормальный работы в Photoshop нужно тратиться на лицензию
Я решил найти другое решение: бесплатное, быстрое, удобное и кросс-платформенное. И нашел.
Для решения задачи я хотел использовать
Python
, но решение это было не лучшее. Нет нормального API
для работы с DOM
элементами, нужна песочница для запуска браузера, работает медленнее, а самое главное - на Python
у меня гораздо меньше опыта. Я реализовал рабочий вариант на imgkit
достаточно быстро, но он не устроил меня, код удалён. Ну и, соответственно, я решил использовать
node js
. Я имею куда больше опыта c node
и javascript
, так что рабочее решение, которое по моим тестам работало быстрее решения на Python
в 7.5 раз, было готово меньше чем через 20 минут. Я быстро накатил первую попавшуюся из поиска библиотеку node-html-to-image, воспользовался неплохой документацией, сверстал максимально странный, но рабочий макет и вот, мой
html
конвертируется в изображение за, в среднем, 2.4 секунды. Ещё за полчаса я изучил библиотеку node-telegram-bot-api и создал на основе скрипта-генератора удобный для себя интерфейс для управления им. Теперь картинки к моим постам генерируются на бесплатном хостинге heroku
, и делают они это через API
бота в телеграм. Процесс выглядит так. В итоге, процесс создания картинки максимально упрощён. Я могу оформить пост с любого устройства, где поддерживается клиент телеграмма (то есть даже с утюга), мне не нужно платить за подписку на Photoshop и я даже могу делегировать создание постов на кого-то куда проще.
Всё это написано крайне криво, неказисто, без нормальной архитектуры и, даже, как такового код-стайла, в паре файликов. Но оно работает. И мне этого достаточно. Я не вижу смысла тратить время на вылизывание кода, которым буду пользоваться только я, это элементарно экономически не выгодно. Но если вдруг перед кем-то встанет такая-же задача, то на моё решение можно посмотреть здесь.
Можно было написать лучше, может быть на питоне это генерировалось бы за миллисекунды, мне плевать. Оно работает и выполняет свою задачу более чем удовлетворительно. Картинка к этому посту уже сделана через бота. Сравнив её с прошлыми, где все сделаны вручную, я думаю, вы оцените качество результата. Можете, кстати, поискать на картинке пасхалку. Милая штука, на мой взгляд.
Делюсь. Вот. Спасибо за прочтение, это правда важно для меня.
#blog #useful #github #design #chatbot
Адаптивная и отзывчивая вёрстка
Вёрстку под разные устройства можно грубо разделить на два вида. Вёрстка бывает либо адаптивная, либо отзывчивая.
Оба подхода решают одну и ту же задачу — качественного и удобного отображения контента страницы на разных экранах одинаково хорошо. Контент сайта должен быть доступен пользователю вне зависимости от того, пользуется он ноутбуком, планшетом или смартфоном.
Адаптивная вёрстка — та вёрстка, где для каждого из типов устройств существует собственный макет. В основном, используются фиксированные размеры элементов, а переходы между «устройствами» при изменении размеров окна браузер выглядят рвано, поскольку происходят скачками от запроса к запросу.
Создаются опорные точки при помощи запросов в CSS, выглядит это примерно так:
При отзывчивой вёрстке существует лишь один макет, например, только для мобильных устройств или только для компьютеров, а всё остальное строится отзывчиво относительно изначального макета. Есть даже специальные названия для подходов к разработке, например, Mobile First Design или же Desktop First Design. Особенность такой вёрстки заключается в полной адаптивности под любые устройства и плавность переходов между ними, хотя целевой платформой является что-то одно — либо смартфон, либо компьютер.
Что лучше? Точно ответить нельзя. Субъективно, отзывчивая вёрстка выглядит куда более приятно, но она дороже и дольше в разработке. Всё зависит от конкретных требований проекта и задачи, которую вы собираетесь решать. Иногда поставленные задачи лучше выполнит отдельная мобильная версия. Или вообще приложение вместо сайта.
Спасибо за прочтение, это важно для меня ❤️
#web #theory #mobile #design #useful
Вёрстку под разные устройства можно грубо разделить на два вида. Вёрстка бывает либо адаптивная, либо отзывчивая.
Оба подхода решают одну и ту же задачу — качественного и удобного отображения контента страницы на разных экранах одинаково хорошо. Контент сайта должен быть доступен пользователю вне зависимости от того, пользуется он ноутбуком, планшетом или смартфоном.
Адаптивная вёрстка — та вёрстка, где для каждого из типов устройств существует собственный макет. В основном, используются фиксированные размеры элементов, а переходы между «устройствами» при изменении размеров окна браузер выглядят рвано, поскольку происходят скачками от запроса к запросу.
Создаются опорные точки при помощи запросов в CSS, выглядит это примерно так:
.block {
display: grid;
}
@media (max-width: 768px) {
/* стили для экранов шириной до 768px */
.block {
grid-template-columns: 1fr;
}
}
@media (min-width: 768px) and (max-width: 1024px) {
/* для ширины экрана от 768px до 1024px */
.block {
grid-template-columns: repeat(1, 3fr);
}
}
@media (min-width: 1024px) {
/* для ширины экрана более 1024px */
.block {
grid-template-columns: repeat(1, 6fr);
}
}
При отзывчивой вёрстке существует лишь один макет, например, только для мобильных устройств или только для компьютеров, а всё остальное строится отзывчиво относительно изначального макета. Есть даже специальные названия для подходов к разработке, например, Mobile First Design или же Desktop First Design. Особенность такой вёрстки заключается в полной адаптивности под любые устройства и плавность переходов между ними, хотя целевой платформой является что-то одно — либо смартфон, либо компьютер.
Что лучше? Точно ответить нельзя. Субъективно, отзывчивая вёрстка выглядит куда более приятно, но она дороже и дольше в разработке. Всё зависит от конкретных требований проекта и задачи, которую вы собираетесь решать. Иногда поставленные задачи лучше выполнит отдельная мобильная версия. Или вообще приложение вместо сайта.
Спасибо за прочтение, это важно для меня ❤️
#web #theory #mobile #design #useful
❤29👍16🤔2🐳2🖕1
This media is not supported in your browser
VIEW IN TELEGRAM
Что такое префиксные свойства и зачем они нужны?
Префиксные свойства — это особые свойства CSS, которые дублируют некоторые стандартные CSS свойства для обеспечения совместимости с различными браузерами.
Изначально префиксные свойства были придуманы для одной простой вещи — кроссбраузерной вёрстки. Но в последнее время идет активное обсуждение отказа от этого подхода и выравнивания названия свойств между браузерами, поэтому это уже не так актуально.
Что интереснее, префиксные свойства позволяют работать с экспериментальными фичами браузера, например изменять скроллбары:
Также есть специальные инструменты, которые называются автопрефиксерами. Такие утилиты автоматически добавляют все необходимые префиксные свойства к вашему CSS коду, поэтому многие даже не задумываются о том, что префиксные свойства в целом существуют, так как эти инструменты уже давно входят в стандартную поставку многих шаблонов и фреймворков.
В целом, префиксные свойства в современном мире — это экспериментальная экзотика. Работать с ними так, как предполагалось изначально, вы уже вряд ли будете, так как все вопросы кроссбраузерности стилей уже давно решаются автоматически.
Спасибо за прочтение, это важно для меня ❤️
Пример с кастомными скроллбарами
#web #theory #web #design
Префиксные свойства — это особые свойства CSS, которые дублируют некоторые стандартные CSS свойства для обеспечения совместимости с различными браузерами.
Изначально префиксные свойства были придуманы для одной простой вещи — кроссбраузерной вёрстки. Но в последнее время идет активное обсуждение отказа от этого подхода и выравнивания названия свойств между браузерами, поэтому это уже не так актуально.
Что интереснее, префиксные свойства позволяют работать с экспериментальными фичами браузера, например изменять скроллбары:
/* ширина скроллбара */
::-webkit-scrollbar {
width: 10px;
}
/* задний фон */
::-webkit-scrollbar-track {
background: #f1f1f1;
}
/* ползунок */
::-webkit-scrollbar-thumb {
background: #888;
}
/* ползунок при наведении */
::-webkit-scrollbar-thumb:hover {
background: #555;
}
Также есть специальные инструменты, которые называются автопрефиксерами. Такие утилиты автоматически добавляют все необходимые префиксные свойства к вашему CSS коду, поэтому многие даже не задумываются о том, что префиксные свойства в целом существуют, так как эти инструменты уже давно входят в стандартную поставку многих шаблонов и фреймворков.
В целом, префиксные свойства в современном мире — это экспериментальная экзотика. Работать с ними так, как предполагалось изначально, вы уже вряд ли будете, так как все вопросы кроссбраузерности стилей уже давно решаются автоматически.
Спасибо за прочтение, это важно для меня ❤️
Пример с кастомными скроллбарами
#web #theory #web #design
🔥20👍11❤5🐳3🤓1