Вот баг про это: bugs.webkit.org/show_bug.cgi?id=60752
Хотя он и закрыт прошлым годом но до Андроидов и iOS эти изменения не дошли и по всйе видимости не дойдут.
CSS Grid Layout и CSS3 Template Layout уже в общем-то объеденены. Теперь это просто CSS Grid Layout.
Легче от этого не стало. Вообще все layout managers должны быть под одной крышей и задаваться одним property. Сейчас — каша. Один, например multi-column, задается своим отдельным свойством columns, другие почему-то через display. display вообще нельзя использовать для задания LM т.е. способа раскладки *детей* а не самого элемента по отношению к его соседям.
Ну упомянутый выше CSS Flexible Box Layout фактически вводит новые units через flex() функцию.
Еще один упомянутый выше модуль Grid Layout вводит еще одни flex units с именем fraction units.
Вообще эта каша с разными layout modules и разными способами описания flexibility в них наводит на грустные мысли по отсутствию царя в голове.
flex-box решает фактически одну единственную проблему — один единственный тип layout manager —
flex-flow:row. Да и то как-то коряво если честно.
Например flexbox для ячейки таблицы или элемента списка описать невозможно ибо td { display: flexbox; /* ломает оригинальный display:table-cell */ }
li { display: flexbox; /* display:list-item */ }
Честно говоря я так и не понял.
Из частной переписки с некоторыми Мозиллоидами понял что они бы и рады имплементировать мой вариант вместо CSS Flexible Box Layout но по всей видимости какие-то политические или финансовые мотивы не дают им это сделать. Кстати люди из Мозиллы и Оперы в обсуждении этого модуля практически не участвуют. В основном Tab Atkins из Google и Алекс Могилевский из Microsoft.
CSS Flexible Box Layout это в общем-то их старая фича по имени XUL flexes ( и ) которая решала flexibility c помощью специального markup. Попытка перенести этот подход механически в CSS ничего хорошего не дает и не даст. Собcтсвенно тот же подход (и я думаю та же судьба ожидается) что и с попыткой CSS-лизации механизма s. HTML таблицы имеют нужную «резиновость» (в горизонтальном и вертикальном направлении) но их CSS эквивалент (display:table & friends) уже потерял flexibility.
Не всегда то что делает -webkit есть самое разумное.
(Я вообще не понимаю как там решения принимаются ибо webkit это и GC и Safari и yandex и пр.)
Как-то пару лет назад предложил вот Flow и Flex Units как средство для построения «резиновых» layouts. Что называется дешево и сердито — одно CSS свойство и один length-alike unit.
В результате получается каша из спецификаций которые перекрывают по фичам друг друга. В каждой из приведенных спецификаций наличествуют flex units в разных формах.
Так как означенные товарищи являются представителями организаций-членов w3c т.е. финансируют этот самый w3c то переубедить их в устранении этого зоопарка возможным не представляется.
Т.е. решения принимаются не по принципу технической грамотности, а по скажем так удобства того или иного решения для конкретного движка. Это в лучшем случае. В худшем — политика.
Как-то было модно пинать IE за то что они всё не так и много своего добавили. И запинали в конце концов. Но prefixed properties это de facto все тот же IE way но для всех остальных вендоров.
Хотели шастя всем и бесплатно, а получилось как всегда. Только теперь пинать будут авторов, а не конкретную макивару по имени MS.
Если рынок требует «всё и сразу» а prefixed properties запрещены то это заставит вендоров быстрее договариваться в W3C CSS WG по поводу рекомендаций. Хоть какая-то мотивация будет.
Никакие public builds не должны включать prefixed properties. И все.
prefixed properties должны быть видны только в эксприментальных сборках типа nightly и developer's builds и пр.
Как только достигнут статус CR для конкретного CSS3 модуля — всё, можно его добавлять в public builds. И в том виде что он описан.
Любой другой вариант и есть тот базар что мы наблюдаем.
«Зачем веб-программисту знать что такое стёк и куча?»
JavaScript использует managed heap. веб-программисту знать что это такое обязательно. Это если программисту а не web designer'у. Особенно на mobile платформе. Google for «javascript memory leak» если интересно.
CSS selector для псевдоэлементов пишется так: elem::before, elem::after, elem::first-line, elem::marker и т.д. Смотрим: www.w3.org/TR/selectors/#pseudo-elements
Элементы это сущности (boxes как правило) сгенерированные CSS процессором дополнительно или в помощь отображению конкретного DOM элемента.
Псевдо-классы же есть средство описания стиля отображения(rendering) run-time состояний самих DOM и псевдо- элементов. Примеры: elem:hover, elem:visited, elem:invalid, etc.
Хотя он и закрыт прошлым годом но до Андроидов и iOS эти изменения не дошли и по всйе видимости не дойдут.
Вот можно проверить: terrainformatica.com/w3/webkit-attr-sel.htm
Легче от этого не стало. Вообще все layout managers должны быть под одной крышей и задаваться одним property. Сейчас — каша. Один, например multi-column, задается своим отдельным свойством columns, другие почему-то через display. display вообще нельзя использовать для задания LM т.е. способа раскладки *детей* а не самого элемента по отношению к его соседям.
Еще один упомянутый выше модуль Grid Layout вводит еще одни flex units с именем fraction units.
Вообще эта каша с разными layout modules и разными способами описания flexibility в них наводит на грустные мысли по отсутствию царя в голове.
flex-flow:row. Да и то как-то коряво если честно.
Например flexbox для ячейки таблицы или элемента списка описать невозможно ибо
td { display: flexbox; /* ломает оригинальный display:table-cell */ }
li { display: flexbox; /* display:list-item */ }
Из частной переписки с некоторыми Мозиллоидами понял что они бы и рады имплементировать мой вариант вместо CSS Flexible Box Layout но по всей видимости какие-то политические или финансовые мотивы не дают им это сделать. Кстати люди из Мозиллы и Оперы в обсуждении этого модуля практически не участвуют. В основном Tab Atkins из Google и Алекс Могилевский из Microsoft.
CSS Flexible Box Layout это в общем-то их старая фича по имени XUL flexes ( и ) которая решала flexibility c помощью специального markup. Попытка перенести этот подход механически в CSS ничего хорошего не дает и не даст. Собcтсвенно тот же подход (и я думаю та же судьба ожидается) что и с попыткой CSS-лизации механизма s. HTML таблицы имеют нужную «резиновость» (в горизонтальном и вертикальном направлении) но их CSS эквивалент (display:table & friends) уже потерял flexibility.
(Я вообще не понимаю как там решения принимаются ибо webkit это и GC и Safari и yandex и пр.)
Как-то пару лет назад предложил вот Flow и Flex Units как средство для построения «резиновых» layouts. Что называется дешево и сердито — одно CSS свойство и один length-alike unit.
Но как-то команде MS в лице Алекса Могилевского и Tab Atkins от GC это показалось черезчур простым.
Поэтому товарищи родили это вот http://www.w3.org/TR/css3-flexbox/. Все фичи Flow и Flex Units это не покрывает поэтому требуется еще это вот www.w3.org/TR/css3-grid/ от MS и частично это вот www.w3.org/TR/css3-layout/
В результате получается каша из спецификаций которые перекрывают по фичам друг друга. В каждой из приведенных спецификаций наличествуют flex units в разных формах.
Так как означенные товарищи являются представителями организаций-членов w3c т.е. финансируют этот самый w3c то переубедить их в устранении этого зоопарка возможным не представляется.
Т.е. решения принимаются не по принципу технической грамотности, а по скажем так удобства того или иного решения для конкретного движка. Это в лучшем случае. В худшем — политика.
Хотели шастя всем и бесплатно, а получилось как всегда. Только теперь пинать будут авторов, а не конкретную макивару по имени MS.
Никакие public builds не должны включать prefixed properties. И все.
prefixed properties должны быть видны только в эксприментальных сборках типа nightly и developer's builds и пр.
Как только достигнут статус CR для конкретного CSS3 модуля — всё, можно его добавлять в public builds. И в том виде что он описан.
Любой другой вариант и есть тот базар что мы наблюдаем.
По мне так TIScript как-то по-гуманнее выглядит.
Для тех кому интересно то вот еще одна статья про TIScript vs JS
JavaScript использует managed heap. веб-программисту знать что это такое обязательно. Это если программисту а не web designer'у. Особенно на mobile платформе. Google for «javascript memory leak» если интересно.
CSS selector для псевдоэлементов пишется так:
elem::before,elem::after,elem::first-line,
elem::markerи т.д. Смотрим: www.w3.org/TR/selectors/#pseudo-elementsЭлементы это сущности (boxes как правило) сгенерированные CSS процессором дополнительно или в помощь отображению конкретного DOM элемента.
Псевдо-классы же есть средство описания стиля отображения(rendering) run-time состояний самих DOM и псевдо- элементов. Примеры:
elem:hover,elem:visited,elem:invalid, etc.