Comments 46
UFO just landed and posted this here
Который раз вижу этот грид и каждый раз он мне не нравится. Ничего не могу с собой поделать, но кажется он мне избыточным и убогим. Избыточным в том плане, что краткости и простоты в нем не больше, чем в таблицах, а убогим в том плане, что нужно самостоятельно много анализировать как все будет работать. Мы задаем кучу параметров, а в итоге толком не ясно какого размера блоки будут.
Вот пример:
Что в итоге мы получим? Первый блок будет 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, по самому большому размеру? Тогда зачем мы описываем остальные блоки?
А сколько действий нужно сделать, чтобы добавить еще один блок? А если во все это еще добавить растягивание контентом… Может я пока не понимаю чего-то и на самом деле все круто. Если так, то объясните, пожалуйста, человеческим языком как это будет работать на практике. Но пока я не хочу видеть это в стандарте.
UFO just landed and posted this here
Так это и будет таблица. Мне всегда казалось, что суть сетки в некой закономерности повторения стандартизированных блоков. Здесь же мы не видим стандартизации, мы тупо описываем каждый блок. Давайте оставим таблицу.
То есть я бы скорее понял такой вариант:
Который автоматом делает стандартизированную сетку.
Еще понял что меня раздражает. То что условие для правила 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) растягивание блоков опять приведет к рушению сетки (снова таблица), значит нужно не просто растягивать блок, а делать это кратно шагу сетки.
UFO just landed and posted this here
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;
}
По поводу растягивания вопрос стоит поднимать только при условии, что речь идет о модульной сетке, а не таблице. С таблицей все ясно. Как задал ячейки, так они и будут связаны. Если один блок потянулся, то остальные тоже тянутся. Так контент в трехколоночной верстке позволяет растянуть боковые столбцы.
Если же речь о модульной верстке и фиксированных размерах блока, то правила нужны иные. Контент по определению будет занимать разное количество блоков, поэтому нужно как-то определить поведение других блоков в этом случае. То есть нужно как-то определять, что, например, средний блок с контентом будет занимать нижние блоки (течь вниз), а боковые блоки должны параллельно занимать схожий объем или смещаться вниз.
UFO just landed and posted this here
Да, с псведоэлементом не срастается в этом случае. Нужна связь с физическим элементом. В целом теперь понятен ход MS в этой области. Ладно, сделаем вид, что выхода не было и поэтому все получилось именно так.
Я сейчас глянул Draft на W3C. Суть стала более понятна. И она как-то слегка расходится с первым скриншотом выше.
Хочется обратить внимание вот на эту картинку:
Здесь как раз все довольно строго выглядит. И выглядит даже не как таблица, а именно как набор направляющих в Фотошопе. Хотя, учитывая, что это физические блоки, не сложно предположить и наличие оформительских возможностей — граница, отступы, заливка… В Драфте еще упоминаются логичные для таблицы возможности — объединение ячеек. Короче, мы видим доработанную «дивную» таблицу. Плодим сущности. :-)
По футору отвечу ниже.
Я сейчас глянул Draft на W3C. Суть стала более понятна. И она как-то слегка расходится с первым скриншотом выше.
Хочется обратить внимание вот на эту картинку:
Здесь как раз все довольно строго выглядит. И выглядит даже не как таблица, а именно как набор направляющих в Фотошопе. Хотя, учитывая, что это физические блоки, не сложно предположить и наличие оформительских возможностей — граница, отступы, заливка… В Драфте еще упоминаются логичные для таблицы возможности — объединение ячеек. Короче, мы видим доработанную «дивную» таблицу. Плодим сущности. :-)
По футору отвечу ниже.
UFO just landed and posted this here
Таблицы не могут, верно. Так стоит их просто научить этому. Нет нужды делать две реализации таблицы.
UFO just landed and posted this here
Не стоит. Таблица — это логическая сущность, сетка — визуальная. Связывать логические иерархии и визуальные не всегда, как минимум, оправдано. В идеале структура html-кода никак не должна зависеть от того как мы хотим отобразить данные, в нём содержащиеся. Структура в такой трактовке нужна только для возможности задавать удобные (короткие и семантичные) селекторы, для выбора способа отображения.
Когда пишем html-код в идеале мы не должны задумываться о том, как он будет отображаться. Вывод html должен стать задачей только сервер-сайд программиста, как например, xml на клиентского xslt или json для клиентских js-шаблонизаторов. Общение сервер-сайд программиста и верстальщика должно происходить на уровне «добавь для таких-то данных такой-то класс/ид, чтоб мне не зависеть от того, что ты вдруг решишь поменять местами футер и хидер, и использовать селекторы классов, а не „третий потомок четвертого с конца тега li в ul идущим первым после body“
Когда пишем html-код в идеале мы не должны задумываться о том, как он будет отображаться. Вывод html должен стать задачей только сервер-сайд программиста, как например, xml на клиентского xslt или json для клиентских js-шаблонизаторов. Общение сервер-сайд программиста и верстальщика должно происходить на уровне «добавь для таких-то данных такой-то класс/ид, чтоб мне не зависеть от того, что ты вдруг решишь поменять местами футер и хидер, и использовать селекторы классов, а не „третий потомок четвертого с конца тега li в ul идущим первым после body“
UFO just landed and posted this here
Пример реалистичного использования — обычный аналог модульной сетки. Задаем шаг, получаем сетку. Размещаем блоки, задаем правила переполнения и радуемся.
Что в итоге мы можем получить:
— более формальную верстку, которая будет изначально способствовать созданию органичного дизайна
— упрощение правил описания за счет того, что все взаимодействия блоков будут изначально определены (не должно случаться так, что вдруг некий блок разорвало от слишком большой картинки или какой-то блок вдруг резко перескочил из правого края в левый)
Это было бы круто, не так ли? :)
Что в итоге мы можем получить:
— более формальную верстку, которая будет изначально способствовать созданию органичного дизайна
— упрощение правил описания за счет того, что все взаимодействия блоков будут изначально определены (не должно случаться так, что вдруг некий блок разорвало от слишком большой картинки или какой-то блок вдруг резко перескочил из правого края в левый)
Это было бы круто, не так ли? :)
UFO just landed and posted this here
Что касается примера с модульной версткой, то косяк с наложением не столь логичен. В модульной сетке мы бы изначально определили, что меню по горизонтали занимает 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. А для счастья с модульной сеткой можно просто добавить возможность указать шаг увеличения размера.
Насколько я помню они этот драфт предлагали только в качестве инструмента для своих метро-приложений. С этой штукой собрать интерфейс на плашках довольно просто.
UFO just landed and posted this here
Интересно было бы еще найти краткую «выжимку» различий между «старыми» и «новыми» флексбоксами
Спасибо за идею, возможно возьмусь за написание.
UFO just landed and posted this here
Я недавно наткнулся на одно существенное(для меня) отличие:
— старые флексбоксы формально имели свойство «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'а.
Sign up to leave a comment.
Новое в CSS3: многоколоночность, flexbox, сеточная разметка