m1rko 7 фев 2018 в 12:48

Современный CSS для динозавров

20 мин

70K

Веб-дизайн*Веб-разработка*CSS*HTML*Браузеры

Перевод

+35

Комментарии 41

aquamakc 7 фев 2018 в 12:58

Большое спасибо от динозавра.

+10

murzix 7 фев 2018 в 15:37

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

Подождём когда grid станет нормой.

sw0rl0k 7 фев 2018 в 17:33

По данным caniuse у гридов 86.59%. На мой взгляд, достаточный процент, для того, что бы в новых проектах использовать только CSS Grid

murzix 7 фев 2018 в 17:38

Это если у вас проектный подход. А если вы поддерживаете один большой проект со старой клиентской базой, то grid пока что оставляете для хипстеров — пущай обкатают =)

mSnus 8 фев 2018 в 07:21

Угумс. Скажите кому-то, что для удобства разработчиков вы отказались от 13% покупателей — и они сразу наймут другого разработчика.

VolCh 8 фев 2018 в 12:44

В корпоративных проектах разработчики могут настоять на использовании конкретных версий браузеров. Скажут бизнесу, что 13% времени они будут реализовать бизнес-требования, а 87% времени обеспечивать поддержку браузеров вроде IE10 и может быстро оказаться, что только одну версию одного браузера надо поддерживать.

a-tk 14 фев 2018 в 22:21

Эххх… Когда я бросил webdev, верстальщики матерились на IE6…

sw0rl0k 8 фев 2018 в 18:11

Ну у нас обязательная поддержка последних двух версий Хрома и ФФ, последней версии Сафари и Эджа. И всё. Бизнес принял спокойно. Никого не уволили.

Kopilov 8 фев 2018 в 23:53

Здорово, если последние две: это свежевышедшая и ESR

SelenIT3 12 фев 2018 в 11:37

Отказались от немерянной красоты любой ценой для 13% покупателей !== «отказались от 13% покупателей». Если у 87%, которые могут, будет быстро и сказочно красиво, а у 13% — попроще, чуть менее красиво, но так же быстро, никто не пострадает. Юзеры не сидят в 5 одновременно открытых браузерах и не сверяют попиксельное совпадение, они заходят на сайт и либо жмут кнопку заказа, либо нет.

Сайты не обязаны выглядеть одинаково во всех браузерах! Адаптивная верстка подразумевает адаптацию не только к разрешению экрана, но и к другим возможностям окружения юзера. Именно для этого придумали @supports.

mSnus 12 фев 2018 в 13:30

Тут вы правы. Однако я отвечал на комментарий

достаточный процент, для того, что бы в новых проектах использовать только CSS Grid

DarthVictor 9 фев 2018 в 19:28

98% у них. Просто caniuse не учитывает ЯндексБраузер.
Он даже для border-radius выдает 84% caniuse.com/#search=border-radius
Хотя в реальности он только на OperaMini не работает.

НЛО прилетело и опубликовало эту надпись здесь

DarthVictor 10 фев 2018 в 19:00

Вы про all tracked? Он у флексов в РФ 99.44%, если с префиксами.
upd. Пардон, перепутал, оригинальный комментарий был про гриды, а не флексы. Вы правы.

DmitryITWorksMakarov 8 фев 2018 в 09:19

Поддерживаю. Стало намного яснее.
А то с одной стороны динозавр, а с другой стороны как слепой котёнок шарашишься под табуреткой, а вокруг сплошные ножки: замуровали, демоны!

НЛО прилетело и опубликовало эту надпись здесь

EvilFox 7 фев 2018 в 20:28

По мне гриды снаружи (общий каркас/макет), флексы внутри (вспомогательные списки/блоки).
Но гриды всё ещё молодая технология, поэтому надо учитывать ЦА ресурса.
В целом неплохо написано тут: developer.mozilla.org/ru/docs/Web/CSS/CSS_Grid_Layout/Relationship_of_Grid_Layout

НЛО прилетело и опубликовало эту надпись здесь

VolCh 8 фев 2018 в 12:48

Они являются частью боксовой модели, описывающей отношения элементов контента внутри контейнера к которому применёно соответствующее свойство.

aPiks 7 фев 2018 в 20:53

Учитывая, что динозавры у нас не только разработчики, но и пользователи, Бутстрап 3 пока все еще актуален и в новых проектах, где важна поддержка как можно большего числа устройств, он все еще используется. Согласно аналитике посещаемость некоторых моих сайтов, с браузеров, которые не поддерживают гриды и тп, все еще около 14 %, это слишком много, чтобы забить на поддержку. Конечно, в идеальном мире, пользователи обновляют браузеры, сносят ХР и рьяно несутся устанавливать десятку, но в нашем мире куча старых смартфонов с дефолтными браузерами, пользователей ИЕ 8-9… и тд и тп.
Ну а если уж заговорили о препроцессорах, то неплохо было бы рассказать, что многие фишки препроцессоров уже внедрены в стандартный CSS и могут использоваться вот прям здесь и сейчас, так что не надо ставить сборщик, движок и тд… просто тыкай ф5 и смотри себе результат.

justboris 7 фев 2018 в 22:11

посещаемость некоторых моих сайтов, с браузеров, которые не поддерживают гриды и тп, все еще около 14 %

многие фишки препроцессоров уже внедрены в стандартный CSS и могут использоваться вот прям здесь и сейчас,

Переменные в CSS поддерживаются примерно теми же браузерами, что и гриды. Какое-то противоречие получается между двумя абзацами вашего комментария.

dom1n1k 7 фев 2018 в 22:38

Нативные переменные совершенно не взаимозаменяемы с препроцессорными.

justboris 8 фев 2018 в 10:57

Да, отличия есть, но задача "избавиться от повторяющихся значений и задавать константы в едином месте" решается и там и там одинаково.

dom1n1k 8 фев 2018 в 21:34

Отличия не просто есть, они принципиальные. Вся суть, соль и цимес нативных переменных в том, что они динамические.
Это одновременно и супер-достоинство, и супер-недостаток. Достоинство потому что это очень крутая фича, которая позволяет иной раз избавиться от сотен строк лишнего кода. Недостаток — потому что не полифилится. И пока что сидим курим бамбук.

EvilFox 10 фев 2018 в 19:33

не полифилится

Есть частичный полифил:
codepen.io/aaronbarker/full/MeaRmL
Форк с улучшениями:
gist.github.com/SahAssar/53a796f9aa5f89f9f16c92ca2607cdf6
+ по мелочи:
gist.github.com/frenkel/709d6d54d638f419e9ff2d148ee53287

dom1n1k 10 фев 2018 в 20:56

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

Denis_Davydenko 8 фев 2018 в 15:18

То что нужно! Спасибо за статью.

chinara 8 фев 2018 в 16:04

Спасибо! Понравился перевод! (было бы здорово, если перевели про javascript, который был упомянут в статье)

justboris 8 фев 2018 в 16:15

Уже есть: https://m.habrahabr.ru/company/mailru/blog/340922/

chinara 8 фев 2018 в 16:48

Спасибо!

IsaNesquik 8 фев 2018 в 17:12

Для меня, как человека, который никак не может вникнуть в «магию» CSS, свойство CSS grid — это манна небесная.

jeka_odessit 9 фев 2018 в 02:59

Ага, сколько у нас гугл выдает результатов по запросу «How do I center my website» — аж 16+ миллионов. А чтобы формочка была по центру вертикальному и горизонтальному? Сколько там костылей для старых IE, ФФ и прочих, плюс тысячи вариантов для мобильных девайсов. А всего то человек хочет Х пикселей шириной/высотой и по центру!

А синтаксис этих решений, явно не дает ~~нормальному человеку~~ диназавру понять причем тут автоматический отступ (margin: auto).

justcooldude 8 фев 2018 в 19:51

Интересно. Может в будущем появится уникальный язык оформления. Вообще отличающийся от текущих мастодонтов, делающий упор на динамику, асинхронность. Отличием от методологии того же React'а, Vim'а будет непосредственная интеграция в броузерные движки, унификация функционала… Ну, мечтать не вредно, как говорится.
Я, честно говоря, не думаю, что веб-разработчику стоит выносить мозг абсолютно всем, что есть на текущий момент. В любое время все может перекрутиться. А устаканивание притормаживается повышенной конкуренцией (что имеет свои плюсы по части инноваций).

jeka_odessit 9 фев 2018 в 02:47

Спасибо за статью. Работал на фронтенде много в 2004-2006гг. Много изменилось как я погляжу. Создается впечатление что ФЕ все никак не может себя найти. Фреймворков для ФЕ как грибов после дождя. Что из этого выбирать для будущего проекта, например который будет заточен под последний chrome/ff/ie/opera?

Что пугает, это куча приблуд которые нужно запускать до, после и вовремя разработки: lassc, npm, bower, gulp, grunt, webpack(?) и прочее — не совсем радует.

Я старый динозавр, помню до «ajax», мы динамически айфреймы создавали, постили туда ХМЛ, submit-тили этот ХМЛ и потом считывали из этого фрейма, т.к. нужно было чтобы без «browser refresh» фитчи работали =)

VolCh 9 фев 2018 в 12:48

Что пугает, это куча приблуд которые нужно запускать до, после и вовремя разработки: lassc, npm, bower, gulp, grunt, webpack(?) и прочее — не совсем радует.

"Нужно" — неправильное слово. Всё можете делать по старинке, эти "приблуды" лишь помогают экономить время. По крайней мере в теории ) А так пишите CSS, HTML и JS под целевые браузеры и не парьтесь :) Только не удивляйтесь, если у коллег-конкурентов будут меньшие сроки разработки и меньшая скорость работы приложений при прочих равных:)

НЛО прилетело и опубликовало эту надпись здесь

questpc 13 фев 2018 в 20:47

Если речь идет об относительно свежих Chrome / Firefox и даже Edge, то значительная часть ES6 и большая часть CSS3 там поддерживается нативно. Так что под них вполне можно программировать без зоопарка утилит на node.js. Другое дело что IE11 продолжает поддерживаться до 2020 года, а в нем даже arrow functions нет.

rexen 11 фев 2018 в 12:18

А есть пост-процессоры, которые кушают програмер-френдли grid, а на выхлопе дают пусть и кошмарный винегрет из хаков margin/float, но зато с максимальной поодержкой зоопарка браузеров?
Разработчикам же всё равно, что будет лежать на сервере. Лишь бы «исходники» были доступны.