Комментарии 24
Я вас разочарую, но я об этом год с лишним назад писал, и даже там мне указали, что идея вторична :)
habrahabr.ru/company/uprock/blog/198322/
habrahabr.ru/company/uprock/blog/198322/
И если говорить серьезно — использование хотя бы одного nth-child (и тем более nth-last-child) в стилях включают более сложный механизм работы css-селекторов. Лучше отказаться, наконец, от поддержки ie8 и 9(только 9й поддерживать на самом деле бред — у него доля даже меньше, чем у восьмого), и перейти на flex-box. Где есть justify-content: space-around/space-between. Я вообще сейчас с react заигрываю, там вообще инлайновые стили приветствуются, а значит — можно точно узнать количество потомков через js.
А такие костыли лучше использовать разве что для таких гемморойных и странных задач, как расстановка элементов равномерно по кругу (в моем посте есть такой пример)
А такие костыли лучше использовать разве что для таких гемморойных и странных задач, как расстановка элементов равномерно по кругу (в моем посте есть такой пример)
Про флексбокс согласен, а инлайновые стили это всё-таки совсем другая степь, их сложнее поддерживать, переносимость и повторяемость тоже хуже, чем у таких вот решений.
Что касается nth-child и скорости, насколько я понял, у вебкитовского движка есть встроенная оптимизация, и она насовсем отключается, если где-либо используются дочерние селекторы (включая +). Но эта оптимизация вообще странная какая-то, и как её результативность померять, неясно.
Не совсем, там идет работа с tree-traversal(сдвиг вправо по списку потомков) и tree-aware(узнать свое положение среди потомков) селекторами.
Я сам не до конца в курсе деталей, но если по сути смотреть — селектор отрабатывает следующим образом: есть конечный узел, который берется из кэша (мапа id-шников, мапа классов, мапа элементов), дальше берется его CSS path и сверяется на матчинг. Соответственно, если в браузере используются еще и сложные пути селекторов, такой матчинг не отработает, и подключается сложная логика.
Я сам не до конца в курсе деталей, но если по сути смотреть — селектор отрабатывает следующим образом: есть конечный узел, который берется из кэша (мапа id-шников, мапа классов, мапа элементов), дальше берется его CSS path и сверяется на матчинг. Соответственно, если в браузере используются еще и сложные пути селекторов, такой матчинг не отработает, и подключается сложная логика.
У флексбокса есть существенные недоработки на уровне концепции. При всех его больших достоинствах он частично разочаровывает на практике.
Можно ли узнать, чем он вас разочаровал?
вероятно, разнообразными глюками в работе во всех браузерах, которые лечатся исключительно адовыми костылями на js)
Мне очень нравится флексбокс, но при всех его достоинствах — реализация во всех браузерах глючный кусок гуано, причем запах и цвет у всех разный напрочь. Я когда глубоко с ним работал (кастомные сложные лейауты, настраиваемые пользователем, через флексбокс) — впервые с 2012 года что ли написал хуки на юзерагент.
Мне очень нравится флексбокс, но при всех его достоинствах — реализация во всех браузерах глючный кусок гуано, причем запах и цвет у всех разный напрочь. Я когда глубоко с ним работал (кастомные сложные лейауты, настраиваемые пользователем, через флексбокс) — впервые с 2012 года что ли написал хуки на юзерагент.
Странно, я заметил только глюки в хроме с местами некорректным рендерингом скроллбаров.
Пока вглубь не лезть — все хорошо.
Да, именно. Скролл не пашет. А как вам, допустим, факт, что в этой верстке элемент не будет отображаться? Просто потому что процентная высота внутри элемента не отрабатывает. И это самый лайтовый из багов, он лечится тупо вотчдогом, который вручную проставляет width и height из clientWidth и clientHeight родителя.
Да, именно. Скролл не пашет. А как вам, допустим, факт, что в этой верстке элемент не будет отображаться? Просто потому что процентная высота внутри элемента не отрабатывает. И это самый лайтовый из багов, он лечится тупо вотчдогом, который вручную проставляет width и height из clientWidth и clientHeight родителя.
<div class="flex-grid">
<div class="flex-item">
<div id="victim" style="height: 100%">...</div>
НЛО прилетело и опубликовало эту надпись здесь
Почти уверен, что вы неправильно готовите.
Покажите пример на jsfiddle.
Покажите пример на jsfiddle.
Да, немного криво объяснил. Берется % не от непосредственного родителя, а от флекс-элемента.
codepen.io/anon/pen/MYqaBP?editors=110
Смотрите, внутри первого .flexItem:
На calc можно не смотреть, это для примера подцеплено, без calc будет абсолютно идентичный глюк.
Футер — не виден, хотя должен быть виден: 50px + (100% — 100px) + 50px = 100%, по стандартам css — такие три блока должны помещаться внутри родителя.
Происходит это потому что 100% расчитывается не от элемента, а от родительского контейнера. Можете поинспектировать, если хотите.
Лечится вложенными контейнерами с ручным расчетом размеров по ресайзу.
codepen.io/anon/pen/MYqaBP?editors=110
Смотрите, внутри первого .flexItem:
<header style="background: red;height: 50px"/>
<main style="background: green;height: calc(100% - 100px)"/>
<footer style="background: red;height: 50px"/>
На calc можно не смотреть, это для примера подцеплено, без calc будет абсолютно идентичный глюк.
Футер — не виден, хотя должен быть виден: 50px + (100% — 100px) + 50px = 100%, по стандартам css — такие три блока должны помещаться внутри родителя.
Происходит это потому что 100% расчитывается не от элемента, а от родительского контейнера. Можете поинспектировать, если хотите.
Лечится вложенными контейнерами с ручным расчетом размеров по ресайзу.
Вы неправильно понимаете спецификацию codepen.io/anon/pen/dPqGRW
flex-direction действует только на непосредственных потомков.
Т.е. для достижения того, что вы хотите, нужно .flexItem также добавить flex-direction: column
flex-direction действует только на непосредственных потомков.
Т.е. для достижения того, что вы хотите, нужно .flexItem также добавить flex-direction: column
Нет-нет. .flexItem — это не display: flex, это обычный display: block, я разве неверно понимаю спецификацию и так нельзя делать?
Можно, но вложив еще один див внутрь дива с display: block (как в вашем варианте) на него уже не действуют правила флексбокс, если можно так выразиться.
Еще раз, flex-direction устанавливает ось только для непосредственных потомков.
И я показал в своем варианте, как можно достичь того, что вы хотите.
Еще раз, flex-direction устанавливает ось только для непосредственных потомков.
И я показал в своем варианте, как можно достичь того, что вы хотите.
Самое главное — нет никакого контроля над переносом блоков на следующую строку.
Кроме того, очень не хватает режима распределения блоков внутри контейнера по центральным точкам, а не по межинтервалам (аналог функции distribute в ФШ).
Ну и плюс глюки, как сказали выше. Причем, что интересно, больше всего в вебките. Сейчас примера под рукой нет, но там что-то было с высотой в 100%. И это был именно баг, поскольку я нашел его в багтрекере.
У меня сложилось впечатление, что сейчас флекс это какое-то решение ни рыба ни мясо. В простых случаях можно обойтись и без него, а в сложных — он, решив одни проблемы, добавит новых.
Кроме того, очень не хватает режима распределения блоков внутри контейнера по центральным точкам, а не по межинтервалам (аналог функции distribute в ФШ).
Ну и плюс глюки, как сказали выше. Причем, что интересно, больше всего в вебките. Сейчас примера под рукой нет, но там что-то было с высотой в 100%. И это был именно баг, поскольку я нашел его в багтрекере.
У меня сложилось впечатление, что сейчас флекс это какое-то решение ни рыба ни мясо. В простых случаях можно обойтись и без него, а в сложных — он, решив одни проблемы, добавит новых.
Меня во флексе немного напрягает выравнивание последней строки при justify-content: space-between.
Например у меня 11 элементов в 4 ряда, три первых ряда будут выглядеть великолепно (по три элемента в строке), но в последней строке будет всего два элемента и их прижмет к разным краям. Образуется дыра по середине, не буду спорить на тему верности такого подхода, но клиентам как правило это очень не нравится.
В качестве решения я наталкивался на совет добавить к коллекции элементов недостающее количество и установить этим вспомогательным элементам height:0.
Мне это не очень понравилось, по первых не всегда можно определить сколько именно элементов может понадобиться. Во вторых это не всегда удобно, например если элементы генерирует cms.
Был бы признателен, если бы вы предложили вариант получше.
Например у меня 11 элементов в 4 ряда, три первых ряда будут выглядеть великолепно (по три элемента в строке), но в последней строке будет всего два элемента и их прижмет к разным краям. Образуется дыра по середине, не буду спорить на тему верности такого подхода, но клиентам как правило это очень не нравится.
В качестве решения я наталкивался на совет добавить к коллекции элементов недостающее количество и установить этим вспомогательным элементам height:0.
Мне это не очень понравилось, по первых не всегда можно определить сколько именно элементов может понадобиться. Во вторых это не всегда удобно, например если элементы генерирует cms.
Был бы признателен, если бы вы предложили вариант получше.
Кто же спорит) Я увидел статью эту, поискал её переводы на хабре, не нашёл и решил перевести. Тем лучше, что многие про это уже знают.
поселектатьЗаписал в личный словарь
Вчера весь день верстал с применением этой техники, круто и снижает потребность в JS'е, но LESS файлы стали выглядеть страшно.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Количественные CSS селекторы