Новое в CSS3: многоколоночность, flexbox, сеточная разметка

[grokru]

Спасибо, исправил.

[MaksimMukharev]

Который раз вижу этот грид и каждый раз он мне не нравится. Ничего не могу с собой поделать, но кажется он мне избыточным и убогим. Избыточным в том плане, что краткости и простоты в нем не больше, чем в таблицах, а убогим в том плане, что нужно самостоятельно много анализировать как все будет работать. Мы задаем кучу параметров, а в итоге толком не ясно какого размера блоки будут.

Вот пример:

#gridexample {
     display: -ms-grid;
    -ms-grid-rows: 30px 20px 10px;
    -ms-grid-columns: 30px 20px 10px;
}

Что в итоге мы получим? Первый блок будет 30х30, а последний 10х10? Тогда какая же это сетка? А может все будет 30х30, по самому большому размеру? Тогда зачем мы описываем остальные блоки?
А сколько действий нужно сделать, чтобы добавить еще один блок? А если во все это еще добавить растягивание контентом… Может я пока не понимаю чего-то и на самом деле все круто. Если так, то объясните, пожалуйста, человеческим языком как это будет работать на практике. Но пока я не хочу видеть это в стандарте.

[MaksimMukharev]

Так это и будет таблица. Мне всегда казалось, что суть сетки в некой закономерности повторения стандартизированных блоков. Здесь же мы не видим стандартизации, мы тупо описываем каждый блок. Давайте оставим таблицу.

То есть я бы скорее понял такой вариант:

#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;
}


Зачем так усложнять жизнь?

[MaksimMukharev]

Упс, что-то не то получилось. Вот так последний пример выглядеть должен:

#griditem:grid-item(1, 2) {
    -ms-grid-column-align: center;
}

[MaksimMukharev]

Еще одним важным свойством для грида, которое я не вижу — правило определяющее переполнение блока. Должно быть определено минимум два момента:

1) растягиваем ли мы сетку или просто занимаем соседний блок (правый, нижний)
2) растягивание блоков опять приведет к рушению сетки (снова таблица), значит нужно не просто растягивать блок, а делать это кратно шагу сетки.

[MaksimMukharev]

SelenIT2, тогда и надо говорить, что мы по сути не модульную сетку делаем (и вообще слово сетка запретить упоминать), а новый аналог таблицы. Про таблицу я согласен, тоже стоит дорабатывать, чтобы народ, наконец, с чистой совестью ее мог строить «дивные» таблицы.

Я и правда что-то размечтался, что речь идет именно о модульной сетке.

По поводу примера. Я хотел показать именно применение псевдокласса. По аналогии с имеющимися уже :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;
}

По поводу растягивания вопрос стоит поднимать только при условии, что речь идет о модульной сетке, а не таблице. С таблицей все ясно. Как задал ячейки, так они и будут связаны. Если один блок потянулся, то остальные тоже тянутся. Так контент в трехколоночной верстке позволяет растянуть боковые столбцы.

Если же речь о модульной верстке и фиксированных размерах блока, то правила нужны иные. Контент по определению будет занимать разное количество блоков, поэтому нужно как-то определить поведение других блоков в этом случае. То есть нужно как-то определять, что, например, средний блок с контентом будет занимать нижние блоки (течь вниз), а боковые блоки должны параллельно занимать схожий объем или смещаться вниз.

[MaksimMukharev]

Да, с псведоэлементом не срастается в этом случае. Нужна связь с физическим элементом. В целом теперь понятен ход MS в этой области. Ладно, сделаем вид, что выхода не было и поэтому все получилось именно так.

Я сейчас глянул Draft на W3C. Суть стала более понятна. И она как-то слегка расходится с первым скриншотом выше.

Хочется обратить внимание вот на эту картинку:



Здесь как раз все довольно строго выглядит. И выглядит даже не как таблица, а именно как набор направляющих в Фотошопе. Хотя, учитывая, что это физические блоки, не сложно предположить и наличие оформительских возможностей — граница, отступы, заливка… В Драфте еще упоминаются логичные для таблицы возможности — объединение ячеек. Короче, мы видим доработанную «дивную» таблицу. Плодим сущности. :-)

По футору отвечу ниже.

[MaksimMukharev]

Таблицы не могут, верно. Так стоит их просто научить этому. Нет нужды делать две реализации таблицы.

[VolCh]

Не стоит. Таблица — это логическая сущность, сетка — визуальная. Связывать логические иерархии и визуальные не всегда, как минимум, оправдано. В идеале структура html-кода никак не должна зависеть от того как мы хотим отобразить данные, в нём содержащиеся. Структура в такой трактовке нужна только для возможности задавать удобные (короткие и семантичные) селекторы, для выбора способа отображения.

Когда пишем html-код в идеале мы не должны задумываться о том, как он будет отображаться. Вывод html должен стать задачей только сервер-сайд программиста, как например, xml на клиентского xslt или json для клиентских js-шаблонизаторов. Общение сервер-сайд программиста и верстальщика должно происходить на уровне «добавь для таких-то данных такой-то класс/ид, чтоб мне не зависеть от того, что ты вдруг решишь поменять местами футер и хидер, и использовать селекторы классов, а не „третий потомок четвертого с конца тега li в ul идущим первым после body“

[MaksimMukharev]

Пример реалистичного использования — обычный аналог модульной сетки. Задаем шаг, получаем сетку. Размещаем блоки, задаем правила переполнения и радуемся.

Что в итоге мы можем получить:

— более формальную верстку, которая будет изначально способствовать созданию органичного дизайна
— упрощение правил описания за счет того, что все взаимодействия блоков будут изначально определены (не должно случаться так, что вдруг некий блок разорвало от слишком большой картинки или какой-то блок вдруг резко перескочил из правого края в левый)

Это было бы круто, не так ли? :)

[MaksimMukharev]

Что касается примера с модульной версткой, то косяк с наложением не столь логичен. В модульной сетке мы бы изначально определили, что меню по горизонтали занимает 2 блока, а контент занимает 10. И оба они переполняются вниз. Почесать затылок скорее всего пришлось бы с горизонтальным меню, где переполняться вправо уже нельзя, а строки хочется перенести.

Сложнее задача — задать связь. Чтобы меню, например, растягивалось по высоте также как и контент. С футором проще. На него давят, он смещается.

Вообще, в процессе дискуссии у меня родилось две новые мысли:

1. Нужно как-то определять отношения между элементами в CSS. То, что заменит -ms-grid-row: 1; и -ms-grid-column: 2;. Отношения у нас давно уже определяются в режиме выявления готовой связи — «body header», «strong+em», «p>strong». Нужно видимо добавить режим создания связи. Хотя, тут еще пойти разберись в каких таки отношениях два элемента должны состоять в итоге и кто за кем следует.

2. К черту модульную сетку! Строгая таблица вполне подойдет для счастья. Главное, чтобы не рассыпалась и не «текла», как это заметно на первом скриншоте в ИЕ10. А для счастья с модульной сеткой можно просто добавить возможность указать шаг увеличения размера.

[Fesor]

Насколько я помню они этот драфт предлагали только в качестве инструмента для своих метро-приложений. С этой штукой собрать интерфейс на плашках довольно просто.

[grokru]

Интересно было бы еще найти краткую «выжимку» различий между «старыми» и «новыми» флексбоксами

Спасибо за идею, возможно возьмусь за написание.

[Burantino]

Я недавно наткнулся на одно существенное(для меня) отличие:

— старые флексбоксы формально имели свойство «box-lines: multiple», но по факту все бразуеры игнорировали это свойство

— новые флексбоксы поддерживают flex-wrap, который реально работает как минимум в chrome 21/22.

Вкратце эта(вышеописанная) штука позволяет, например создавать IconView (а-ля проводник) из элементов различной высоты, заранее неизвестной высоты (float, как вы понимаете, перед такими ситуациями пасует)

Кроме того новый стандарт мне кажется более логичным, простым и в тоже время более гибким.

[Keyten]

> column-rule: 1em solid black; /* width, style, color */
Скорее всего здесь параметры можно располагать абсолютно произвольно (по крайней мере так в большинстве подобных свойств — border, outline, etc).

[Shirixae]

Я джва года ждал…

[kuchumovn]

Ничё не понял, зачем это всё нужно…

[kuchumovn]

От каких «костылей» избавляет вас этот «flexbox»?

[kuchumovn]

и каким образом?

[kuchumovn]

видимо, никаким

[kuchumovn]

по-моему это очевидно

[kuchumovn]

ну если так, то это гораздо круче float'ов и отрицательных margin'ов (делал такую разметку у себя, долго матерился).
в таком случае правильно ли говорить, что flex'ы — это нормальная замена таблицам в css?

[kuchumovn]

ок, спасибо

[Burantino]

Поезд уже ушёл, и далеко, но я всё-таки расскажу свою грустную историю использования flex разметки.

Дело было в Chromium (не путать с Chrome ). На радостях разбомбил свой js-layout который реализовывал стандартную north-west-center-east-south раскладку с изменяемыми ширинами. И забомбил всё на flex-ах. Код упростился, разметка стала волшебно-прозрачной — никаких врапперов-переврапперов. Но. Потом всё это пришлось отыгрывать обратно ( спасибо, SVN). А дело вот в чём — в центральной области у меня происходят массовые анимации. А во flex разметке у chromium'а отключается оптимизация рендеринга, если смотреть на DevTools, то каждый кадр он отрисовывает целиком, на всё окно. А та же анимация, но в float или absolute рендерится кусочками — только там где на экране произошло изменение. fps отличается очень сильно. Пришлось попрощаться с волшебной чёткостью разметки и вернуться к миксу из js'а, float'а и absolute'а.