Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 46
Который раз вижу этот грид и каждый раз он мне не нравится. Ничего не могу с собой поделать, но кажется он мне избыточным и убогим. Избыточным в том плане, что краткости и простоты в нем не больше, чем в таблицах, а убогим в том плане, что нужно самостоятельно много анализировать как все будет работать. Мы задаем кучу параметров, а в итоге толком не ясно какого размера блоки будут.
Вот пример:
Что в итоге мы получим? Первый блок будет 30х30, а последний 10х10? Тогда какая же это сетка? А может все будет 30х30, по самому большому размеру? Тогда зачем мы описываем остальные блоки?
А сколько действий нужно сделать, чтобы добавить еще один блок? А если во все это еще добавить растягивание контентом… Может я пока не понимаю чего-то и на самом деле все круто. Если так, то объясните, пожалуйста, человеческим языком как это будет работать на практике. Но пока я не хочу видеть это в стандарте.
Вот пример:
#gridexample {
display: -ms-grid;
-ms-grid-rows: 30px 20px 10px;
-ms-grid-columns: 30px 20px 10px;
}
Что в итоге мы получим? Первый блок будет 30х30, а последний 10х10? Тогда какая же это сетка? А может все будет 30х30, по самому большому размеру? Тогда зачем мы описываем остальные блоки?
А сколько действий нужно сделать, чтобы добавить еще один блок? А если во все это еще добавить растягивание контентом… Может я пока не понимаю чего-то и на самом деле все круто. Если так, то объясните, пожалуйста, человеческим языком как это будет работать на практике. Но пока я не хочу видеть это в стандарте.
Так это и будет таблица. Мне всегда казалось, что суть сетки в некой закономерности повторения стандартизированных блоков. Здесь же мы не видим стандартизации, мы тупо описываем каждый блок. Давайте оставим таблицу.
То есть я бы скорее понял такой вариант:
Который автоматом делает стандартизированную сетку.
Еще понял что меня раздражает. То что условие для правила CSS описывается в виде параметров:
Что, нельзя было это сделать как-то более логично? Что-то вроде:
#griditem:grid-item(1, 2) {
-ms-grid-column-align: center;
}
Зачем так усложнять жизнь?
То есть я бы скорее понял такой вариант:
#gridexample {
display: -ms-grid;
-ms-grid-row-height: 30px;
-ms-grid-column-width: 30px;
}
Который автоматом делает стандартизированную сетку.
Еще понял что меня раздражает. То что условие для правила CSS описывается в виде параметров:
#griditem1 {
-ms-grid-row: 1;
-ms-grid-column: 2;
-ms-grid-column-align: center;
}
Что, нельзя было это сделать как-то более логично? Что-то вроде:
#griditem:grid-item(1, 2) {
-ms-grid-column-align: center;
}
Зачем так усложнять жизнь?
Упс, что-то не то получилось. Вот так последний пример выглядеть должен:
#griditem:grid-item(1, 2) {
-ms-grid-column-align: center;
}
Еще одним важным свойством для грида, которое я не вижу — правило определяющее переполнение блока. Должно быть определено минимум два момента:
1) растягиваем ли мы сетку или просто занимаем соседний блок (правый, нижний)
2) растягивание блоков опять приведет к рушению сетки (снова таблица), значит нужно не просто растягивать блок, а делать это кратно шагу сетки.
1) растягиваем ли мы сетку или просто занимаем соседний блок (правый, нижний)
2) растягивание блоков опять приведет к рушению сетки (снова таблица), значит нужно не просто растягивать блок, а делать это кратно шагу сетки.
SelenIT2, тогда и надо говорить, что мы по сути не модульную сетку делаем (и вообще слово сетка запретить упоминать), а новый аналог таблицы. Про таблицу я согласен, тоже стоит дорабатывать, чтобы народ, наконец, с чистой совестью ее мог строить «дивные» таблицы.
Я и правда что-то размечтался, что речь идет именно о модульной сетке.
По поводу примера. Я хотел показать именно применение псевдокласса. По аналогии с имеющимися уже :nth-child, :first-child и т.д.
То есть полный пример должен выглядеть правильно так:
По поводу растягивания вопрос стоит поднимать только при условии, что речь идет о модульной сетке, а не таблице. С таблицей все ясно. Как задал ячейки, так они и будут связаны. Если один блок потянулся, то остальные тоже тянутся. Так контент в трехколоночной верстке позволяет растянуть боковые столбцы.
Если же речь о модульной верстке и фиксированных размерах блока, то правила нужны иные. Контент по определению будет занимать разное количество блоков, поэтому нужно как-то определить поведение других блоков в этом случае. То есть нужно как-то определять, что, например, средний блок с контентом будет занимать нижние блоки (течь вниз), а боковые блоки должны параллельно занимать схожий объем или смещаться вниз.
Я и правда что-то размечтался, что речь идет именно о модульной сетке.
По поводу примера. Я хотел показать именно применение псевдокласса. По аналогии с имеющимися уже :nth-child, :first-child и т.д.
То есть полный пример должен выглядеть правильно так:
#gridexample {
display: -ms-grid;
-ms-grid-row-height: 30px;
-ms-grid-column-width: 30px;
}
#gridexample:grid-item(1,2) {
text-align: center;
}
По поводу растягивания вопрос стоит поднимать только при условии, что речь идет о модульной сетке, а не таблице. С таблицей все ясно. Как задал ячейки, так они и будут связаны. Если один блок потянулся, то остальные тоже тянутся. Так контент в трехколоночной верстке позволяет растянуть боковые столбцы.
Если же речь о модульной верстке и фиксированных размерах блока, то правила нужны иные. Контент по определению будет занимать разное количество блоков, поэтому нужно как-то определить поведение других блоков в этом случае. То есть нужно как-то определять, что, например, средний блок с контентом будет занимать нижние блоки (течь вниз), а боковые блоки должны параллельно занимать схожий объем или смещаться вниз.
Да, с псведоэлементом не срастается в этом случае. Нужна связь с физическим элементом. В целом теперь понятен ход MS в этой области. Ладно, сделаем вид, что выхода не было и поэтому все получилось именно так.
Я сейчас глянул Draft на W3C. Суть стала более понятна. И она как-то слегка расходится с первым скриншотом выше.
Хочется обратить внимание вот на эту картинку:
Здесь как раз все довольно строго выглядит. И выглядит даже не как таблица, а именно как набор направляющих в Фотошопе. Хотя, учитывая, что это физические блоки, не сложно предположить и наличие оформительских возможностей — граница, отступы, заливка… В Драфте еще упоминаются логичные для таблицы возможности — объединение ячеек. Короче, мы видим доработанную «дивную» таблицу. Плодим сущности. :-)
По футору отвечу ниже.
Я сейчас глянул Draft на W3C. Суть стала более понятна. И она как-то слегка расходится с первым скриншотом выше.
Хочется обратить внимание вот на эту картинку:
Здесь как раз все довольно строго выглядит. И выглядит даже не как таблица, а именно как набор направляющих в Фотошопе. Хотя, учитывая, что это физические блоки, не сложно предположить и наличие оформительских возможностей — граница, отступы, заливка… В Драфте еще упоминаются логичные для таблицы возможности — объединение ячеек. Короче, мы видим доработанную «дивную» таблицу. Плодим сущности. :-)
По футору отвечу ниже.
Таблицы не могут, верно. Так стоит их просто научить этому. Нет нужды делать две реализации таблицы.
Не стоит. Таблица — это логическая сущность, сетка — визуальная. Связывать логические иерархии и визуальные не всегда, как минимум, оправдано. В идеале структура html-кода никак не должна зависеть от того как мы хотим отобразить данные, в нём содержащиеся. Структура в такой трактовке нужна только для возможности задавать удобные (короткие и семантичные) селекторы, для выбора способа отображения.
Когда пишем html-код в идеале мы не должны задумываться о том, как он будет отображаться. Вывод html должен стать задачей только сервер-сайд программиста, как например, xml на клиентского xslt или json для клиентских js-шаблонизаторов. Общение сервер-сайд программиста и верстальщика должно происходить на уровне «добавь для таких-то данных такой-то класс/ид, чтоб мне не зависеть от того, что ты вдруг решишь поменять местами футер и хидер, и использовать селекторы классов, а не „третий потомок четвертого с конца тега li в ul идущим первым после body“
Когда пишем html-код в идеале мы не должны задумываться о том, как он будет отображаться. Вывод html должен стать задачей только сервер-сайд программиста, как например, xml на клиентского xslt или json для клиентских js-шаблонизаторов. Общение сервер-сайд программиста и верстальщика должно происходить на уровне «добавь для таких-то данных такой-то класс/ид, чтоб мне не зависеть от того, что ты вдруг решишь поменять местами футер и хидер, и использовать селекторы классов, а не „третий потомок четвертого с конца тега li в ul идущим первым после body“
Пример реалистичного использования — обычный аналог модульной сетки. Задаем шаг, получаем сетку. Размещаем блоки, задаем правила переполнения и радуемся.
Что в итоге мы можем получить:
— более формальную верстку, которая будет изначально способствовать созданию органичного дизайна
— упрощение правил описания за счет того, что все взаимодействия блоков будут изначально определены (не должно случаться так, что вдруг некий блок разорвало от слишком большой картинки или какой-то блок вдруг резко перескочил из правого края в левый)
Это было бы круто, не так ли? :)
Что в итоге мы можем получить:
— более формальную верстку, которая будет изначально способствовать созданию органичного дизайна
— упрощение правил описания за счет того, что все взаимодействия блоков будут изначально определены (не должно случаться так, что вдруг некий блок разорвало от слишком большой картинки или какой-то блок вдруг резко перескочил из правого края в левый)
Это было бы круто, не так ли? :)
Что касается примера с модульной версткой, то косяк с наложением не столь логичен. В модульной сетке мы бы изначально определили, что меню по горизонтали занимает 2 блока, а контент занимает 10. И оба они переполняются вниз. Почесать затылок скорее всего пришлось бы с горизонтальным меню, где переполняться вправо уже нельзя, а строки хочется перенести.
Сложнее задача — задать связь. Чтобы меню, например, растягивалось по высоте также как и контент. С футором проще. На него давят, он смещается.
Вообще, в процессе дискуссии у меня родилось две новые мысли:
1. Нужно как-то определять отношения между элементами в CSS. То, что заменит -ms-grid-row: 1; и -ms-grid-column: 2;. Отношения у нас давно уже определяются в режиме выявления готовой связи — «body header», «strong+em», «p>strong». Нужно видимо добавить режим создания связи. Хотя, тут еще пойти разберись в каких таки отношениях два элемента должны состоять в итоге и кто за кем следует.
2. К черту модульную сетку! Строгая таблица вполне подойдет для счастья. Главное, чтобы не рассыпалась и не «текла», как это заметно на первом скриншоте в ИЕ10. А для счастья с модульной сеткой можно просто добавить возможность указать шаг увеличения размера.
Сложнее задача — задать связь. Чтобы меню, например, растягивалось по высоте также как и контент. С футором проще. На него давят, он смещается.
Вообще, в процессе дискуссии у меня родилось две новые мысли:
1. Нужно как-то определять отношения между элементами в CSS. То, что заменит -ms-grid-row: 1; и -ms-grid-column: 2;. Отношения у нас давно уже определяются в режиме выявления готовой связи — «body header», «strong+em», «p>strong». Нужно видимо добавить режим создания связи. Хотя, тут еще пойти разберись в каких таки отношениях два элемента должны состоять в итоге и кто за кем следует.
2. К черту модульную сетку! Строгая таблица вполне подойдет для счастья. Главное, чтобы не рассыпалась и не «текла», как это заметно на первом скриншоте в ИЕ10. А для счастья с модульной сеткой можно просто добавить возможность указать шаг увеличения размера.
Насколько я помню они этот драфт предлагали только в качестве инструмента для своих метро-приложений. С этой штукой собрать интерфейс на плашках довольно просто.
Интересно было бы еще найти краткую «выжимку» различий между «старыми» и «новыми» флексбоксами
Спасибо за идею, возможно возьмусь за написание.
Я недавно наткнулся на одно существенное(для меня) отличие:
— старые флексбоксы формально имели свойство «box-lines: multiple», но по факту все бразуеры игнорировали это свойство
— новые флексбоксы поддерживают flex-wrap, который реально работает как минимум в chrome 21/22.
Вкратце эта(вышеописанная) штука позволяет, например создавать IconView (а-ля проводник) из элементов различной высоты, заранее неизвестной высоты (float, как вы понимаете, перед такими ситуациями пасует)
Кроме того новый стандарт мне кажется более логичным, простым и в тоже время более гибким.
— старые флексбоксы формально имели свойство «box-lines: multiple», но по факту все бразуеры игнорировали это свойство
— новые флексбоксы поддерживают flex-wrap, который реально работает как минимум в chrome 21/22.
Вкратце эта(вышеописанная) штука позволяет, например создавать IconView (а-ля проводник) из элементов различной высоты, заранее неизвестной высоты (float, как вы понимаете, перед такими ситуациями пасует)
Кроме того новый стандарт мне кажется более логичным, простым и в тоже время более гибким.
> column-rule: 1em solid black; /* width, style, color */
Скорее всего здесь параметры можно располагать абсолютно произвольно (по крайней мере так в большинстве подобных свойств — border, outline, etc).
Скорее всего здесь параметры можно располагать абсолютно произвольно (по крайней мере так в большинстве подобных свойств — border, outline, etc).
Я джва года ждал…
Ничё не понял, зачем это всё нужно…
Поезд уже ушёл, и далеко, но я всё-таки расскажу свою грустную историю использования flex разметки.
Дело было в Chromium (не путать с Chrome ). На радостях разбомбил свой js-layout который реализовывал стандартную north-west-center-east-south раскладку с изменяемыми ширинами. И забомбил всё на flex-ах. Код упростился, разметка стала волшебно-прозрачной — никаких врапперов-переврапперов. Но. Потом всё это пришлось отыгрывать обратно ( спасибо, SVN). А дело вот в чём — в центральной области у меня происходят массовые анимации. А во flex разметке у chromium'а отключается оптимизация рендеринга, если смотреть на DevTools, то каждый кадр он отрисовывает целиком, на всё окно. А та же анимация, но в float или absolute рендерится кусочками — только там где на экране произошло изменение. fps отличается очень сильно. Пришлось попрощаться с волшебной чёткостью разметки и вернуться к миксу из js'а, float'а и absolute'а.
Дело было в Chromium (не путать с Chrome ). На радостях разбомбил свой js-layout который реализовывал стандартную north-west-center-east-south раскладку с изменяемыми ширинами. И забомбил всё на flex-ах. Код упростился, разметка стала волшебно-прозрачной — никаких врапперов-переврапперов. Но. Потом всё это пришлось отыгрывать обратно ( спасибо, SVN). А дело вот в чём — в центральной области у меня происходят массовые анимации. А во flex разметке у chromium'а отключается оптимизация рендеринга, если смотреть на DevTools, то каждый кадр он отрисовывает целиком, на всё окно. А та же анимация, но в float или absolute рендерится кусочками — только там где на экране произошло изменение. fps отличается очень сильно. Пришлось попрощаться с волшебной чёткостью разметки и вернуться к миксу из js'а, float'а и absolute'а.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Новое в CSS3: многоколоночность, flexbox, сеточная разметка