с другой стороны, текущий подход к условной логике в 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, чем бутстрап
Всё, что угодно можно освоить самостоятельно. Это не критерий фундаментальности. Но для текущего веба, когда все сидят на конкретных высокоуровневых инструментам, знание любой чистой технологии, причём глубокое, уже можно считать фундаментальным.
Что касается вашей задачи, ну это частный пример, который никак не относится к профессиональной деятельности фронтендера
Касаемо базовых знаний по чистому и глубокому HTML и CSS в вузах — это утопия. Там такого просто нет, оно никуда в программу не ложится.
По JS ещё могут что-то глубокое дать, так как это более вузовская тема. И народ любит позаползать в фундаментальную теорию.
Но чтобы в вузе глубоко разбирали вёрстку, ну или хотя бы глубоко заползали в алгоритмы раскладки (типа флексбокса), опираясь на спеки — такого почти нигде нет. А ведь разбор фундаментальных алгоритмов на базе первоисточников — это и есть уровень вуза.
ну, когда рынок стравливает низкоквалифицированные кадры с перегретыми зарплатами, больно становится всем. так-то ведь нездоровая была ситуация, когда "мидл" с 2 годами опыта, а по факту сборщик-на-реакте-из-готовых-компонентов получал 150+. а откуда там навыков и глубокого понимания просто чистого js возьмётся на такую зп, даже не говоря о владении всем стеком фронта (чистая вёрстка, чистый 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, чем бутстрап
Всё, что угодно можно освоить самостоятельно. Это не критерий фундаментальности. Но для текущего веба, когда все сидят на конкретных высокоуровневых инструментам, знание любой чистой технологии, причём глубокое, уже можно считать фундаментальным.
Что касается вашей задачи, ну это частный пример, который никак не относится к профессиональной деятельности фронтендера
Касаемо базовых знаний по чистому и глубокому HTML и CSS в вузах — это утопия. Там такого просто нет, оно никуда в программу не ложится.
По JS ещё могут что-то глубокое дать, так как это более вузовская тема. И народ любит позаползать в фундаментальную теорию.
Но чтобы в вузе глубоко разбирали вёрстку, ну или хотя бы глубоко заползали в алгоритмы раскладки (типа флексбокса), опираясь на спеки — такого почти нигде нет. А ведь разбор фундаментальных алгоритмов на базе первоисточников — это и есть уровень вуза.
ну или он очень специфичный и собеседущие сами про такие тонкости не знают =) это не про отличие блочных и строчных спрашивать
ну, когда рынок стравливает низкоквалифицированные кадры с перегретыми зарплатами, больно становится всем. так-то ведь нездоровая была ситуация, когда "мидл" с 2 годами опыта, а по факту сборщик-на-реакте-из-готовых-компонентов получал 150+. а откуда там навыков и глубокого понимания просто чистого js возьмётся на такую зп, даже не говоря о владении всем стеком фронта (чистая вёрстка, чистый js, фреймор). вот от всей этой красоты и избавляются радостно
Кстати вот метафора с одномерной и двумерной сеткой — одна из самых неудачных, которая появлялась во фронтенде, но прижилась так, что не выжечь
Надо еще каверзный вопрос про ссылку, в которую можно положить див, добавить