Только вот непонятна исходная задача. Допустим, отформатировать на цсс получилось и вывести через content тоже. Дальше то что с числом будет. Если нужно просто на него смотреть, то ок. Если копировать, то уже вроде как неудобно (хотя я мало работал с такими задачами).
Тут уже имеем, то что имеем. Авторы спеки решили сделать вот так. И обвязать всю логику вокруг CSS-переменных. Мне лично такой подход нравится, так как ложится в мой опыт работы с вёрсткой. Я вижу, как текущая реализация сочетается с другими нативными фичами. Возможно, если бы ушли в усложнение селекторов, было бы лучше, но кто уж теперь скажет.
Прикладываю скриншот того, как из этого же календаря можно сделать сложный индикатор, привязанный к этапам проведения какого-то мероприятия, причём вообще без JS. То есть крутим страницу и закрашиваются дни, соответствующие этапам, причём разные этапы можно подсветить по-разному.
Само число из инпута будет JS забирать и передавать куда-то в CSS. А вот может ли дальше CSS его отформатировать как вам надо? Кажется, что да, условной логикой проверяете отрицательное или нет, если отрицательное, то загоняете в abs() , и выводите в псевдоэлемент через content, там же можно и скобочки добавить, и перекрасить как вам нужно
для примера из статьи всё будет ок. решение на цсс-логике всеядно к разметке, если номера дней размечены правильно (неважно, дата-атрибутами или заинлайненными переменными).
дискуссия ушла в сторону разметки, а цсс-логике то на разметку всё равно
Так у вас никто не отбирает логику вычисления переменных в JS – делайте с ними что хотите. Задача — упростить рендеринг. Она решается цсс-логикой. Но если хотите в цикле бегать по элементам — пожалуйста
с другой стороны, текущий подход к условной логике в CSS позволяет писать "тупой код", которой понятен многим. появляется возможность динамически вычислить какой-то промежуточный флаг и запульнуть его в стилевой запрос. а вот решение на сложных селекторах такой возможности не дало бы, да и очень многих отпугнуло сложностью
я из всех реакций на эту статью не вижу ни одной, где бы говорилось — "обожемой, какой сложный код, как в нём тяжело разобраться". в основном все пишут про непривычность подхода и про то, что "логике" в цсс не место. и это хороший знак. получается у ребят из гугла получилось сделать просто
Теперь отдельно про content. Наверное это можно, но мне тут больше нравится идея — оставить простой контент в разметке. И для доступности, и да и просто как-то логичнее. Таким образом мы дни внутри ячеек можем отображать, как нам больше нравится, хоть с тем же ведущим нулём. А уже в дата-атрибутах вынести в том виде, который удобнее для JS
По поводу сиблинг-индексов. Там мы упрёмся в ряды таблицы, они будут мешать. Либо, если делать плоской структурой, будем страдать с ситуациями, когда первый день месяца не совпадает с понедельником. И придётся вводить какое-то дополнительное смещение в каждом месяце, и вычитать его из значения sibling-index
Тем не менее, в реальной жизни есть реальная сущность — неделя. Если эту реальную сущность явным образом зашить в разметку, работать с ней будет проще. Если не зашить в разметку и потом вычислять, то будет сложнее.
Ну и опять же, в чем смысл делать плоский список дней? Чисто ради сложно nth-child селектора? =)
Да в целом ту же логику можно и на data-атрибутах сделать, обновлённый attr то их умеет считывать. Тут ведь ещё какое дело — весь этот инлайнинг скорее всего будет делаться в рантайме на живом дом-дереве. Скрипт инициализирует компонент, пробежится по шаблону, проставит нужные атрибуты и будет себе их спокойно менять. И что он там проставил — дата-атрибуты или заинлайненные через style css-переменные — не особо и важно. Тем более, что и в традиционных реализациях на JS точно также дом-дерево дополнительно допиливается при инициализации, чтобы скрипту было удобнее.
Тут всё-таки важно отличать, что предлагают тащить в CSS: всю бизнес-логику или сложную логику отображения. В данном случае речь о логике отображения.
И, да, стилезвые запросы и рейндж-синтаксис уже в спеках, уже в интеропах и уже в браузерах. Так что возможности есть, и использовать их будут. Вопрос, как именно.
То что решение вам кажется хуже, это нормально, у каждого своё мнение. Я считаю, что оно не хуже и не лучше, оно просто непривычное. Но с точки зрения разделения поведения и отображения — оно лучше. А вообще, помнится, мало кто протестовал, когда анимацию начали выносить в css, полосатые таблички тоже вынесли в css, и так далее
Естественно бизнес-логика крутится в JS. В исходном состоянии CSS-переменные в стилях можно инициализировать нулями и ничего не будет выделено
Когда диапазон выбран, просто устанавливаются значения переменных на корневом элементе. Можно сделать и через дата-атрибуты. Не надо ползти внутрь и в цикле вешать классы. То есть упрщается логика рендеринга. Да, вроде бы избавились всего от одного цикла, но для этого не надо писать тонну CSS, так как всё делается в одну строчку
Так я выше задал два вопроса к решению на селекторе:
1) как в этом решении удобно двигать даты диапазона? селектор — штука статичная. сидеть генерить цсс правила и перезаписывать их в каком-то спецтеге стайл. не перебор ли?
2) как все эти смещения высчитывать внтри nth-child?
Понятно, что когда есть задача — выделить статичный диапазон — там и селектором можно. А если задача — сделать удобное апи для динамического изменения диапазона, то вряд ли селекторы будут хороши. А вот CSS-логика выглядит и простой, и удобной
Вот тут и начинается развлекуха – "А давайте вместо нормальной таблицы будем имитировать её плоской списочной структурой"
Но даже после замены таблицы плоским списком тегов остаются вопросы: - А как удобно менять диапазоны дат? Селекторы с помощью JS ведь нельзя менять. - Как правильно вычислять коэффициенты внутри nth-child? Ведь надо ещё учитывать сдвиг первого числа месяца, когда первое число не попадает на понедельник.
И вы уверены, что вам за такую вёрстку ваш JS-разработчик потом скажет спасибо? =)
Вполне. Какую-то часть js знать придётся, но в остальном всё меняется на инструменты и конструкции самого реакта. Таким же образом раньше появлялись верстальщики на бутстрапе, а сейчас верстальщики на тейлвинде, хотя тейлвинд ближе к исходным конструкциями css, чем бутстрап
Всё, что угодно можно освоить самостоятельно. Это не критерий фундаментальности. Но для текущего веба, когда все сидят на конкретных высокоуровневых инструментам, знание любой чистой технологии, причём глубокое, уже можно считать фундаментальным.
Что касается вашей задачи, ну это частный пример, который никак не относится к профессиональной деятельности фронтендера
Только вот непонятна исходная задача. Допустим, отформатировать на цсс получилось и вывести через content тоже. Дальше то что с числом будет. Если нужно просто на него смотреть, то ок. Если копировать, то уже вроде как неудобно (хотя я мало работал с такими задачами).
Тут уже имеем, то что имеем. Авторы спеки решили сделать вот так. И обвязать всю логику вокруг CSS-переменных. Мне лично такой подход нравится, так как ложится в мой опыт работы с вёрсткой. Я вижу, как текущая реализация сочетается с другими нативными фичами. Возможно, если бы ушли в усложнение селекторов, было бы лучше, но кто уж теперь скажет.
Прикладываю скриншот того, как из этого же календаря можно сделать сложный индикатор, привязанный к этапам проведения какого-то мероприятия, причём вообще без JS. То есть крутим страницу и закрашиваются дни, соответствующие этапам, причём разные этапы можно подсветить по-разному.
Само число из инпута будет JS забирать и передавать куда-то в CSS. А вот может ли дальше CSS его отформатировать как вам надо? Кажется, что да, условной логикой проверяете отрицательное или нет, если отрицательное, то загоняете в
abs(), и выводите в псевдоэлемент черезcontent, там же можно и скобочки добавить, и перекрасить как вам нужнодля примера из статьи всё будет ок. решение на цсс-логике всеядно к разметке, если номера дней размечены правильно (неважно, дата-атрибутами или заинлайненными переменными).
дискуссия ушла в сторону разметки, а цсс-логике то на разметку всё равно
Так у вас никто не отбирает логику вычисления переменных в JS – делайте с ними что хотите. Задача — упростить рендеринг. Она решается цсс-логикой. Но если хотите в цикле бегать по элементам — пожалуйста
с другой стороны, текущий подход к условной логике в CSS позволяет писать "тупой код", которой понятен многим. появляется возможность динамически вычислить какой-то промежуточный флаг и запульнуть его в стилевой запрос. а вот решение на сложных селекторах такой возможности не дало бы, да и очень многих отпугнуло сложностью
я из всех реакций на эту статью не вижу ни одной, где бы говорилось — "обожемой, какой сложный код, как в нём тяжело разобраться". в основном все пишут про непривычность подхода и про то, что "логике" в цсс не место. и это хороший знак. получается у ребят из гугла получилось сделать просто
Теперь отдельно про content. Наверное это можно, но мне тут больше нравится идея — оставить простой контент в разметке. И для доступности, и да и просто как-то логичнее. Таким образом мы дни внутри ячеек можем отображать, как нам больше нравится, хоть с тем же ведущим нулём. А уже в дата-атрибутах вынести в том виде, который удобнее для JS
По поводу сиблинг-индексов. Там мы упрёмся в ряды таблицы, они будут мешать. Либо, если делать плоской структурой, будем страдать с ситуациями, когда первый день месяца не совпадает с понедельником. И придётся вводить какое-то дополнительное смещение в каждом месяце, и вычитать его из значения sibling-index
Тем не менее, в реальной жизни есть реальная сущность — неделя. Если эту реальную сущность явным образом зашить в разметку, работать с ней будет проще. Если не зашить в разметку и потом вычислять, то будет сложнее.
Ну и опять же, в чем смысл делать плоский список дней? Чисто ради сложно nth-child селектора? =)
Да в целом ту же логику можно и на data-атрибутах сделать, обновлённый attr то их умеет считывать. Тут ведь ещё какое дело — весь этот инлайнинг скорее всего будет делаться в рантайме на живом дом-дереве. Скрипт инициализирует компонент, пробежится по шаблону, проставит нужные атрибуты и будет себе их спокойно менять. И что он там проставил — дата-атрибуты или заинлайненные через style css-переменные — не особо и важно. Тем более, что и в традиционных реализациях на JS точно также дом-дерево дополнительно допиливается при инициализации, чтобы скрипту было удобнее.
Тут всё-таки важно отличать, что предлагают тащить в CSS: всю бизнес-логику или сложную логику отображения. В данном случае речь о логике отображения.
И, да, стилезвые запросы и рейндж-синтаксис уже в спеках, уже в интеропах и уже в браузерах. Так что возможности есть, и использовать их будут. Вопрос, как именно.
То что решение вам кажется хуже, это нормально, у каждого своё мнение. Я считаю, что оно не хуже и не лучше, оно просто непривычное. Но с точки зрения разделения поведения и отображения — оно лучше. А вообще, помнится, мало кто протестовал, когда анимацию начали выносить в css, полосатые таблички тоже вынесли в css, и так далее
Естественно бизнес-логика крутится в JS. В исходном состоянии CSS-переменные в стилях можно инициализировать нулями и ничего не будет выделено
Когда диапазон выбран, просто устанавливаются значения переменных на корневом элементе. Можно сделать и через дата-атрибуты. Не надо ползти внутрь и в цикле вешать классы. То есть упрщается логика рендеринга. Да, вроде бы избавились всего от одного цикла, но для этого не надо писать тонну CSS, так как всё делается в одну строчку
Тут инлайнинг надёжнее. Ну или дата-атрибуты
Хорошо, сделали списком. Что дальше? Как менять диапазон?
Так я выше задал два вопроса к решению на селекторе:
1) как в этом решении удобно двигать даты диапазона? селектор — штука статичная. сидеть генерить цсс правила и перезаписывать их в каком-то спецтеге стайл. не перебор ли?
2) как все эти смещения высчитывать внтри nth-child?
Понятно, что когда есть задача — выделить статичный диапазон — там и селектором можно. А если задача — сделать удобное апи для динамического изменения диапазона, то вряд ли селекторы будут хороши. А вот CSS-логика выглядит и простой, и удобной
ну поживите без выходных и радостного ожидания пятницы, а потом обсудим ваш опыт =)
полностью теряется важная сущность — неделя, остаётся просто плоский список дней месяца
Вот тут и начинается развлекуха – "А давайте вместо нормальной таблицы будем имитировать её плоской списочной структурой"
Но даже после замены таблицы плоским списком тегов остаются вопросы:
- А как удобно менять диапазоны дат? Селекторы с помощью JS ведь нельзя менять. - Как правильно вычислять коэффициенты внутри nth-child? Ведь надо ещё учитывать сдвиг первого числа месяца, когда первое число не попадает на понедельник.
И вы уверены, что вам за такую вёрстку ваш JS-разработчик потом скажет спасибо? =)
А как быть с диапазоном дней, который попадает в разные ряды таблицы?
Вполне. Какую-то часть js знать придётся, но в остальном всё меняется на инструменты и конструкции самого реакта. Таким же образом раньше появлялись верстальщики на бутстрапе, а сейчас верстальщики на тейлвинде, хотя тейлвинд ближе к исходным конструкциями css, чем бутстрап
Всё, что угодно можно освоить самостоятельно. Это не критерий фундаментальности. Но для текущего веба, когда все сидят на конкретных высокоуровневых инструментам, знание любой чистой технологии, причём глубокое, уже можно считать фундаментальным.
Что касается вашей задачи, ну это частный пример, который никак не относится к профессиональной деятельности фронтендера