Pull to refresh

Comments 19

Использовал пользовательские свойства в стиле для Stylish, переоформлял 4pda в тёмные цвета и несколько личных проектов. Смысл был в том, чтобы разделить стили на два файла — в одном задаётся оформление для конкретного сайта, во второй вынесены цвета для формата HSL и применяется он для всех сайтов, таким образом правя цвета в одном файле — я могу изменить оформление сразу для нескольких сайтов. И у пользователей не возникает проблем с обновлением базового стиля, потому как править его нет причин.
У вас есть сведения, что от этого браузер работает хуже? )
Есть общепринятые правила и мне кажется их следует придерживаться при написании кода для широкой публики.
У меня тоже есть свои JS извращения: двойные кавычки, отступ из четырех пробелов. Но приходиться сдерживаться :)
Если отказаться от привычки выдавать свои пристрастия за правила, то жизнь становится немного проще )
нет общепринятых правил. Есть правила принятные на конктретном проекте, не более. Плюс подходы типа CSSModlues лучше работают именно с camelCase нотацией
Разве не кажется по крайней мере логичным использовать стилизацию близкую к нативной?
А насчет общепринятости — у стайл гайдов airbnb на гитхабе в сумме почти 100к звездочек. И это я не говорю про практически идентичные гайды гугла. Имхо этого достаточно что бы считать эти правила общепринятыми.

А что, это единственный критерий? Сочувствую вашим коллегам.

я правильно понимаю, что переменную надо заводить специально для определенного селектора? в чем смысл, кроме дублирования кода?
тут либо примеры не удачные, либо сам функционал еще не доведен до объективно-полезного.
Нет. Пользовательские свойства могут также наследоваться. В следующей статье об этом и будет рассказано. И примеры подобраны с целью показать, что можно сделать теоретически. Практические примеры будут в другой статье.

Главное преимущество пользовательских свойств, в том что они наследуются и переопределяется в Dom. Это гораздо круче переменных в препроцессора.

Если на вашем проекте много пользователей с IE11, не применяйте пользовательские свойства. Я мог бы рассказать, как сделать фоллбэки...

А с этого места поподробнее? А то я заюзал как-то полиффил но как-то криво он работал
Можно:
— использовать supports или отдельную версию для IE 11, но тогда раздувается код
— можно использовать PostCSS плагины, и довольствоваться ограниченными возможностями

Поэтому если есть IE11 или другие браузеры, которые не поддерживают пользовательские свойства, то лучше отложить свое желание для другого проекта

Фоллбэки это не полифиллы, а дублированные свойства без использования переменных:


.main {
  color: #212121;
  background: #fafafa;
  color: var(--main-color);
  background: var(--main-bg);
}

Ну и у полифиллов есть ограничения, для работы css-vars-ponyfill пользовательские свойства должны быть только в root:


:root {
  --a: var(--b);
  --b: var(--c);
  --c: 10px;
}

div {
  padding: calc(2 * var(--a));
}
Спасибо, в css-vars-ponyfill то что свойства должны быть в :root меня и смутило когда я его тестил, это практически весь цымес от кастомных переменных и теряется, когда нужно в зависимости от элемента дом задать определенные значения правилам. Видимо для IE11 нет и не будет полноценного полифилла.
Вообще интересное нововведение, но преимуществ перед Sass не вижу, задавать значения переменных в коде == сойти с ума в правках на больших проектах. Все что указали — переменной Sass нет в браузере, а какой выигрыш если бы была?
Преимущество перед sass в том, что переменные

— следуют структуре dom:

Простой пример: сейчас можно делать сайты где можно переключать дневную/ночную тему. В принципе в sass это решается, но с переменными становится вообще просто.

пример на sass
a {
	color: blue;
}

.content {
	background: white;
	color: black;
}

/* далее фактически идет дифф оригинального цсс */
html[data-theme="night"]{
	a {
		color: red;
	}

	.content {
		background: black;
		color: white;
	}
}


пример с custom properties
html {
	--background: white;
	--color: black;
	--link-color: blue;
}

html[data-theme="night"] {
	--background: black;
	--color: white;
	--link-color: red;
}

/* далее идет общий цсс */
a {
	color: var(--link-color);
}

.content {
	background: var(--background);
	color: var(--color);
}



На простом примере плохо видно преимущество, но на сложной верстке, первый пример превратится в кучу копипасты в переопределением где надо будет отслеживать и думать о том какой элемент вложен в какой, либо просто генерить два .css, а второй пример так и останется plain списком, но тут можно будет поспорить про производительность.

— динамические:

пример с js
html {
	--content-ratio: 70%;
}

.content{
	width: var(--content-ratio);
}

.sidebar{
	width: calc(100% - var(--content-ratio));
}

contentRangeInput.addEventListener("change", (e) => {
	document.documentElement.style.setProperty("--content-ratio", `${contentRangeInput.value}%`);
})



Я думаю понятно, что sass переменные и custom properties это не конкуренты. Вторые обладают динамикой, что дает намного больше преимуществ чем просто сохранение рассудка в стилизации документа.
Преимущества пользовательских свойств:
— можно менять значение в медиа-запросах (пример в статье с переключением цвета и текста)
— без костылей работает calc (я помню был баг либо в Less, либо в Sass)
— работают с атрибутами (пример в статье с svg)
— меньше писать кода для состояний hover, focus и т.п

И сравнение пользовательских свойств с Sass переменным некорректно. Они могут спокойно существовать вместе
К примеру вот такого на препроцессорах не сделаешь.

.icon {
  --size: 18px;
  
  width: var(--size);
  height: var(--size);

  @media (max-width: 400px) {
     --size: 16px;
  }

}


Плюс не забыаем, что css в браузере отлично управляется через js. А значит мы можем меня ть значения каких-либо css переменных в рантайме
Sign up to leave a comment.