Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 48
Ну вот смотрю я на это, придумывают всякое, что зачастую никому не нужно (цвет rebeccapurple, hwb и прочее), а самой обычной вложенности, совершенно очевидной и самой нужной фичи, которая есть в каждом существующем препроцессоре, как не было, так и нет. Грустно.
Да, тут не поспоришь.
Что значит нет? Cssnext — это лишь набор плагинов для PostCss, с таким же успехом вы можете подключить и вложенность и остальные фишки. Поглядите на сайте postcss, это будущее, которое возможно уже сегодня.
postcss — это постпроцессор, а не оригинальный css. Точно так же как babel, в котором хоть декораторы можно включить, которые в ES7 есть, но это не значит что оно будет в стандарте. Лично я в драфте вложенности не видел, может ткнёте носом, пожалуйста?
я в драфте вложенности не виделБыло предложение от
Ну черновик, прямо скажем, говнистый. Синтаксис мне откровенно не нравится. У less, у sass\scss, stylus почти идентичный синтаксис, не понимаю, почему нельзя было его взять? Но нет, у нас «свой путь»… (с)
Насколько я понимаю, опасаются неоднозначностей, которые усложняли (и, соответственно, замедляли) бы механизм разбора CSS-кода, вынуждая его «заглядывать вперёд» (look ahead), чтобы отличить вложенное правило от обычного объявления:
Кроме того, стараются максимально обезопасить себя от проблем обратной совместимости в будущем: препроцессор при необходимости можно исправить, а синтаксис CSS — практически нет.
Preprocessors are okay with needing arbitrary lookahead to parse CSS. Browsers aren’t — they want fast, parallizable parsing, and that means fixed, small amounts of lookahead.В этом плане вложенные блоки мне импонируют больше (скорее всего, в собственном препроцессоре я бы сделал так же), чем необходимость предварять каждое вложенное правило амперсандом, как это было в изначальных предложении и соответствующем черновике.
Кроме того, стараются максимально обезопасить себя от проблем обратной совместимости в будущем: препроцессор при необходимости можно исправить, а синтаксис CSS — практически нет.
Ну так уже на многолетней практике с препроцессорами разработчики убедились, что никаких подводных камней в синтаксисе с амперсандами нету. Единственные проблемы есть (были) в less из-за конфликтов «собак» с какими-либо специфическими медиа-выражениями. По-моему sass хоть прямо сейчас бери и основывай на его синтаксисе новый стандарт, всё работает без каких-либо проблем. Единственное — синтаксис циклов, условий и прочего немного не нравится, но с этим можно свыкнуться.
подводных камней в синтаксисе с амперсандами нету.Подводных камней нет, просто неудобно и не оч. DRY каждое вложенное правило предварять амперсандом: проще добавить один вложенный блок (
{…}), внутрь которого поместить произвольное количество правил без ведущего амперсанда.Амперсанд — это конкатенация правил. С другой стороны смысл есть в скобочной вложенности, убедили, только амперсанд погибче будет.
Пример из scss
На выходе:
Т.е. амперсанд означает лишь предыдущее правило плюс указанное, можно им складывать куски классов, а можно обходиться без него, управляя вложенностью самому.
.blog {
...
&-comment {
..
}
a { ... }
@at-root .some {
}
}
На выходе:
.blog {
...
}
.blog-comment {
...
}
.blog a {
...
}
.some {
...
}
Т.е. амперсанд означает лишь предыдущее правило плюс указанное, можно им складывать куски классов, а можно обходиться без него, управляя вложенностью самому.
Одно другому не мешает. Польза амперсанда как универсальной возможности сослаться на родительский селектор (например, для обозначенных вами целей) несомненна, он неоптимален именно для обеспечения простой вложенности правил. Иначе говоря, лучше так:
чем так:
.example {
color: red;
{
.a {}
.b {}
.c {}
}
}
чем так:
.example {
color: red;
& .a {}
& .b {}
& .c {}
}
Зачем во втором примере нужны амперсанды? Это изврат по-моему.
Будет всё тоже самое.
.example {
color: red;
.a {}
.b {}
.c {}
}
Будет всё тоже самое.
Из моего второго комментария:
опасаются неоднозначностей, которые усложняли (и, соответственно, замедляли) бы механизм разбора CSS-кода, вынуждая его «заглядывать вперёд» (look ahead), чтобы отличить вложенное правило от обычного объявления.
А т.е. боятся, что один и тот же символ (амперсанд) означает разное поведение. В одном случае вложенность html тегов (a > b), в другом — вложенность css деклараций (.a.b). Я понял.
С точностью до наоборот: амперсанд в названии свойства присутствовать не может, поэтому его наличие в начале селектора вложенного правила и устраняло бы неоднозначность. Например, CSS-парсеру здесь:
чтобы понять, что color — это не имя свойства, а селектор вложенного правила, необходимо было бы просмотреть код до открывающей фигурной скобки.
А здесь:
по амперсанду сразу понятно, что это не имя свойства, а селектор.
.example {
color {}
}
чтобы понять, что color — это не имя свойства, а селектор вложенного правила, необходимо было бы просмотреть код до открывающей фигурной скобки.
А здесь:
.example {
& color {}
}
по амперсанду сразу понятно, что это не имя свойства, а селектор.
Я с вами совершенно согласен, особенно по поводу вложенности, но вот по поводу цвета rebeccapurple не соглашусь. Почитайте причину по которой данный цвет был добавлен ( meyerweb.com/eric/thoughts/2014/06/19/rebeccapurple ) и если после этого вы считаете что это не нужно было делать то я уже и не знаю как вас назвать…
И все-таки грустно, что для подобных вещей нужны sass, cssnext, postcss etc.
Я вот не очень понимаю как это работает. Допустим calc(). Он сейчас есть у 76% пользователей из тех что переписал caniuse. У части из них он без поддержки половины функционала. С вот этой штукой из статьи он у них как-то работать начнёт? Вот прям на opera mini и ie8? А можно пример? Не такой где calc( 1px + 2px), а хотя бы width: calc( 50% — 20px).
Я думаю, максимум что здесь может зафаллбечить плагин, это заменить в калке переменные на реальные значения. Ну или, как Вы уже указали, посчитать простые выражения.
Могу в качестве примера привести грид-сетку.
:root{
--fullWidth: 100%;
}
.col-11 {
width: calc(var(--fullWidth)/12*11);
}
.col-10 {
width: calc(var(--fullWidth)/12*10);
}
.col-9 {
width: calc(var(--fullWidth)/12*9);
}
...
Вопрос комментатора выше скорее заключается в том, как плагин поможет тем у кого calc не поддерживается в принципе? Какие фолбэки используются в данном случае?
На вопрос, я так понимаю, уже ответили. Вся фишечка именно в переменных, в данном случае --fullWidth. Сам же calc() остаётся таким же как и был, но автоматически прописывается ещё и с префиксами для старых версий. Выходит что уже сейчас можно писать код, который когда-нибудь в далёком будущем будет работать без танцев с бубнами, но сейчас может дать не очень полезный результат. В том же примере azat-io использование calc() не имеет практического смысла, в конечном коде его не будет, он схлопнется сам.
Улучшенный синтаксис медиа-запросовПо-моему, улучшенный синтаксис, это когда
Позволяет использовать выражения >= и <= вместо min-width и max-width в медиа-запросах.
@media (width >= 500px) and (width <= 1200px) { /* Ваши стили */ }
@media (500px <= width <= 1200px) , а так — один фиг, что min-width, что width <=.Цвет rebeccapurpleВот это вот вообще не следовало сюда включать.
Псевдокласс :notСледует указать, что этот псевдокласс уже существует и успешно используется. В CSS4 только добавляется возможность указать список.
Единицы remУ Вас даже линк ведёт на спецификацию CSS3. Так что оно делает здесь?
По мне так это все высосано из пальца. Практически все из этого или есть в существующих препроцессорах, или достигается миксинами, или просто поддерживается большинством браузеров (тот же rem). По сути из всего списка действительно полезная и новая вещь — это пользовательские селекторы (не уверен, но вроде в less, sass, stylus такого нет). Хотя только из-за этого я вряд ли пересяду со stylus'а.
Фишка cssnext, в том, что это набор простых плагинов для Postcss, то есть добавление других возможностей очень просто и быстро. Что-то дописать в stylus сложно и требует гораздно большего времени и экспретизы, так что если все пойдет хорошо, то postcss станет таким неким двигателем прогресса для css, как трансшпилеры для javascript. Ну и следующий бутстрап будет на postcss, так что если ничего нового не придумают, то уверен, что появится просто реализация stylus на postcss( кстати близкая реализация к scss уже есть на их сайте), и stylus как отдельный проект закроется
Если рассматривать с точки зрения фронтенд разработчика, то вообще без разницы, использовать ли less/sass/stylus или postcss с плагинами. Но тут такая беда: css сам по себе — это не более, чем просто таблица стилей, что ярко показывает расшифровка аббревиатуры. Тут не нужны какие-то супер-пупер плагины, а достаточно того, что уже есть в препроцессорах, а именно переменных, автопрефиксов, в редких случая циклов, вложенности и замены некоторых свойств на их более совместимые со старичками конструкции (необходимость которых падает с каждым днем со скоростью, сравнимой со скоростью развития postcss).
Итого лично я стал бы использовать postcss в том случае, если он ИЗ КОРОБКИ и БЕЗ ДОПОЛНИТЕЛЬНОЙ НАСТРОЙКИ ПЛАГИНОВ давал бы мне больше, чем stylus. Но stylus (с 1 модулем kouto-swiss) уже дает мне все, что нужно. Если углубляться, то stylus, к тому же, дает объективно больше, чем остальные препроцессоры.
А зачем мне «язык программирования» для css? Я считаю, что оно того не стоит и роль postcss в будущем написания стилей сильно преувеличена.
Все это, конечно, только мое мнение, но сложено оно исходя из опыта реальной работы и прочтения кучи статей на тему.
Итого лично я стал бы использовать postcss в том случае, если он ИЗ КОРОБКИ и БЕЗ ДОПОЛНИТЕЛЬНОЙ НАСТРОЙКИ ПЛАГИНОВ давал бы мне больше, чем stylus. Но stylus (с 1 модулем kouto-swiss) уже дает мне все, что нужно. Если углубляться, то stylus, к тому же, дает объективно больше, чем остальные препроцессоры.
А зачем мне «язык программирования» для css? Я считаю, что оно того не стоит и роль postcss в будущем написания стилей сильно преувеличена.
Все это, конечно, только мое мнение, но сложено оно исходя из опыта реальной работы и прочтения кучи статей на тему.
Да, и по поводу JavaScript: «трансшпилеры» (если имеются в виду всякие TypeScript и CoffeeScript) — это редкая кака, вызванная неспособностью людей после классических ООП языков понять концепцию прототипов. Ну нету в JS классов, смиритесь с этим, люди! Так нет, в JS зачем-то добавляют классы, хотя их там быть не должно… Нет, там, безусловно, есть удобные штуки вроде скобочной нотации анонимных функций, но зачем мне все это, если у меня есть IDE с автодополнением, а на выходе один хрен мы получаем JavaScript? Тоже, в общем, непонятно мне это.
Вброс, конечно, сильный :) Но думаю с тем, что тесты на том же coffescript смотрятся куда красивее, вы ведь спорить не будете?
Ну и es6 смотрели? Вот ведь глупые, синтаксический сахар для классов то все-таки ввели, темный люди :(
Ну и es6 смотрели? Вот ведь глупые, синтаксический сахар для классов то все-таки ввели, темный люди :(
Да, лично я считаю, что это неверный шаг, так как он по-прежнему является именно «сахаром», даже на уровне языка в случае с ES6. Прототипы-то все равно никуда не делись, в итоге они и получаются! И это нужно понимать при программировании на JS, и как раз это то, в чем не все с ходу разбираются (и себя я тоже подразумеваю, я долго доходил до философии JS после Java и C#, да и не совсем уверен, до конца ли я дошел), а ключевое слово class в JS только ставит палки в колеса при понимании этого.
Нет, я не могу спорить с очевидным — код с сахаром может (но может и нет) выглядеть более читаемым, но это не должно достигаться путем подмены понятий, так как ведет к фундаментальному непониманию.
Да и, кстати, с выходом ES6 отпадет необходимость использовать «трансшпилеры», если, конечно, те не придумают какую-то убер-фичу.
Нет, я не могу спорить с очевидным — код с сахаром может (но может и нет) выглядеть более читаемым, но это не должно достигаться путем подмены понятий, так как ведет к фундаментальному непониманию.
Да и, кстати, с выходом ES6 отпадет необходимость использовать «трансшпилеры», если, конечно, те не придумают какую-то убер-фичу.
Я вас расстрою, но классы давно поддерживаются Хромом из коробки.
Я писал и на ES6 (плюс некоторые плюшки из ES7, декораторы, использовал в качестве экспериментов с контрактным программированием): https://github.com/SerafimArts/ES7-Sandbox и на Coffee, и на чистом JS, и на TypeScript.
И знаете что скажу? CoffeeScript зачастую намного приятнее использовать. Просто наличием автоматического ретурна, постусловий (some if true, вместо if true then some) и самое главное — циклов for in + for of, вот без последнего реально очень тяжко жить. Безумно тяжко. А без классов обойтись вполне возможно, пара вложенных замыканий и вперёд.
И знаете что скажу? CoffeeScript зачастую намного приятнее использовать. Просто наличием автоматического ретурна, постусловий (some if true, вместо if true then some) и самое главное — циклов for in + for of, вот без последнего реально очень тяжко жить. Безумно тяжко. А без классов обойтись вполне возможно, пара вложенных замыканий и вперёд.
> По мне так это все высосано из пальца. Практически все из этого или есть в существующих препроцессорах
Стандарт по-любому лучше зоопарка препроцессоров. Даже если этот стандарт в черновиках.
Ну а если все это высосано из пальца, то зачем тогда нужны сегодняшние препроцессоры?
Стандарт по-любому лучше зоопарка препроцессоров. Даже если этот стандарт в черновиках.
Ну а если все это высосано из пальца, то зачем тогда нужны сегодняшние препроцессоры?
Сорри за эмоции, но. Кто, их мать, придумал такой страшный синтаксис для переменных? Функция var, в которую нужно передать имя переменной, которое начинается двойным дефисом? Какого… нужен этот var? Почему решили использовать двойной дефис вместо понятного всем доллара?
Еще меня несколько расстраивает отсутствие вложенных правил, как в scss. Прийдется по-прежнему повторять колбасу из селекторов из раза в раз.
$variable
vs
var(--variable)
Еще меня несколько расстраивает отсутствие вложенных правил, как в scss. Прийдется по-прежнему повторять колбасу из селекторов из раза в раз.
Формально символ доллара не использован, т. к. принцип работы CSS-переменных сильно отличается от того, как работают переменные в препроцессорах. Символ доллара зарезервирован для возможного использования в синтаксисе глобальных констант.
CSS-переменные даже называются сейчас не переменными, а пользовательскими нестандартными свойствами (Custom Properties). Для нестандартных свойств, в свою очередь, всегда использовался префикс в виде дефиса, который для пользовательских свойств просто удвоен.
CSS-переменные даже называются сейчас не переменными, а пользовательскими нестандартными свойствами (Custom Properties). Для нестандартных свойств, в свою очередь, всегда использовался префикс в виде дефиса, который для пользовательских свойств просто удвоен.
А в чем прелесть этого пака? Например, перед PreCSS? Только в том, что он опирается на синтаксис, который, возможно, станет потом стандартным? Но ведь фича PostCSS именно в гибкости, а
Последний, кстати, включен в cssnano — один из немногих действительно интересных паков, потому что такие сборники все-в-одном, мне кажется, все же не самый лучший подход. Лучше подбирать действительно нужное под себя и конкретный проект…
var(--variable) действительно ужасно. При этом есть postcss-media-minmax, позволяющий писать, как говорил выше extempl, @media (500px <= width <= 1200px), есть pixrem, есть тот же postcss-calc, которые возвращает уже вычисленное значение. Последний, кстати, включен в cssnano — один из немногих действительно интересных паков, потому что такие сборники все-в-одном, мне кажется, все же не самый лучший подход. Лучше подбирать действительно нужное под себя и конкретный проект…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Используем возможности CSS4 уже сегодня с cssnext