Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 49
Ну вот сейчас начнется как с браузерами: CSS 20
Этот код будет делать фон страницы красным, при наведении курсора на ссылку с классом .styleSwitcher, находящуюся в хедере. Для достижения подобного эффекта, не используя родительский селектор, без JS не обойтись.
:)
А стиль для body? :-/
Надо поменять слиль для parent.
Надо поменять слиль для parent.
Весьма остроумно, но всё же это костыль: у Вас вместо изменения фона страницы на ней размещается крупный слой, накрывающий настоящий фон.
Это решение поневоле полагается на то, что другие аналогичные «фоновые» элементы не провалятсяпод его z-index.
Это решение поневоле полагается на то, что другие аналогичные «фоновые» элементы не провалятся
«Опыт работы: программирование на CSS версий 4, 5, 6»
Вот ведь парадокс: CSS с каждой версией всё обрастает и обрастает фичами, а верстать от этого почему-то легче не становится.
Похоже на то, что за CSS плотно взялись какие-то кодеры-маньяки, которых надо гнать из W3C поганой метлой. Чувствуется типично кодерский подход — вместо того, чтоб выявить и решить реальные проблемы, они криво патчат костылями отдельные случаи и добавляют побольше разных «прикольных фич», причём каждый ещё и тянет одеяло на себя, т.ч. многие из этих фич частично перекрываются и/или противоречат друг другу.
Неужели так трудно разогнать этих оторванных от реальности людей и привлечь наконец дизайнеров/верстальщиков? Разыскали бы уже в сети пару десятков типичных шаблонов вёрстки, и переделали CSS так, чтоб из этих шаблонов поисчезало бы наконец многокилометровое шаманство.
Похоже на то, что за CSS плотно взялись какие-то кодеры-маньяки, которых надо гнать из W3C поганой метлой. Чувствуется типично кодерский подход — вместо того, чтоб выявить и решить реальные проблемы, они криво патчат костылями отдельные случаи и добавляют побольше разных «прикольных фич», причём каждый ещё и тянет одеяло на себя, т.ч. многие из этих фич частично перекрываются и/или противоречат друг другу.
Неужели так трудно разогнать этих оторванных от реальности людей и привлечь наконец дизайнеров/верстальщиков? Разыскали бы уже в сети пару десятков типичных шаблонов вёрстки, и переделали CSS так, чтоб из этих шаблонов поисчезало бы наконец многокилометровое шаманство.
Для упрощения верстки, W3C уже придумали Flexbox. Вот и станет легче верстать, когда сможем спокойно его использовать.
Дорвались не кодеры-маньяки, а программисты браузерописатели. Процесс придумывания фичи гораздо интереснее, чем возможность ее использования.
На все мои попытки унифицировать все управление потоком я получил замечательный ответ: «Not invented here».
На все мои попытки унифицировать все управление потоком я получил замечательный ответ: «Not invented here».
Как раз сегодня в очередной раз сокрушался, что
Но пока… увы…
CSS не позволяет стилизовать label, связанный с input:checked и наткнулся на эти новые селекторы. Родительский селектор позволяет сослаться на label, если input в него обёрнут, а если они связаны через атрибуты for и id, поможет привлечение не упомянутого здесь ссылочного комбинатора: label! /for/ input:checkedНо пока… увы…
JetBrains: WebStorm, phpStorm… cssStorm?!
Как-то не впечатляет CSS4, понимаю, что это только начальные наброски, но все-же нужных мне вещей не видать.
Хотелось бы видеть развитие в сторону сокращения кода и уменьшения дублирования. Понимаю что в LESS это уже сделано, но я думаю что ребята из W3C могли бы много ещё напридумывать.
Классно бы также иметь возможность окрашивать фоновые изображения. Так-как теперь пошла мода на одноцветные иконки. Суть в том, чтобы например при наведении на иконку не загружалась та же иконка с другим цветом, а она просто перекрашивалась. Экономия ресурсов налицо.
Хотелось бы видеть развитие в сторону сокращения кода и уменьшения дублирования. Понимаю что в LESS это уже сделано, но я думаю что ребята из W3C могли бы много ещё напридумывать.
Классно бы также иметь возможность окрашивать фоновые изображения. Так-как теперь пошла мода на одноцветные иконки. Суть в том, чтобы например при наведении на иконку не загружалась та же иконка с другим цветом, а она просто перекрашивалась. Экономия ресурсов налицо.
computational complexity этого селектора
есть O(1) — если элемент <a> имеет :hover и он внутри <body> использовать данный стиль на нем.
Но вот здесь
subject of the selector есть уже body элемент. Т.е. computational complexity определения стиля для <body> элемента
уже O(N) где N это количество DOM элементов внутри body. Т.е. для того чтобы определить стиль <body> элемента CSS processor будет вынужден сканировать всех DOM детей <body> вглубину.
В настоящее время сложность определения стилей всех элементов на странице есть O(N*S)
где
N — количество DOM элементов;
S — количество CSS rules.
Но с введением данной фичи сложность становится квадратичной O(N*N*S).
Что означает что первый же залетевший дятел («вебмастер Вован») разрушит цивилизацию. Хотите DDoS атак вашего любимого браузера? — их будет у вас.
body a:hover {
background: red;
}
есть O(1) — если элемент <a> имеет :hover и он внутри <body> использовать данный стиль на нем.
Но вот здесь
body! a:hover {
background: red;
}subject of the selector есть уже body элемент. Т.е. computational complexity определения стиля для <body> элемента
уже O(N) где N это количество DOM элементов внутри body. Т.е. для того чтобы определить стиль <body> элемента CSS processor будет вынужден сканировать всех DOM детей <body> вглубину.
В настоящее время сложность определения стилей всех элементов на странице есть O(N*S)
где
N — количество DOM элементов;
S — количество CSS rules.
Но с введением данной фичи сложность становится квадратичной O(N*N*S).
Что означает что первый же залетевший дятел («вебмастер Вован») разрушит цивилизацию. Хотите DDoS атак вашего любимого браузера? — их будет у вас.
Я не вижу причин, почему должен измениться способ поиска совпадений. Ищем совпадения так же, применяем стили к другому элементу.
Что сейчас происходит при отработке hover события на скажем <a> элементе (мышь приехала на a):
1. сбросить текущий стиль a элемента и его descendants.
2. Найти новый стиль поддерева:
a. для всех С детей проверить все S правил (CSS) на предмет applicability к данному элементу.
b. если стиль поменялся сделать refresh региона занимаемого <a>
c. если новый стиль изменяет размеры то сделать relayout контейнера(ов).
Если же мы добавляем
Скажем есть такие правила:
Последнее правило читается так: «при mouse hover на любом <a> внутри документа установить border-bottom:2px для всех <a> в документе. Так как border-bottom:2px изменяет размер элемента то мы вынуждены не только пересчитать все стили <a> элементов в документе (а это full scan DOM tree+full window refresh) но и пересчитать layout всего документа. Т.е. тривиальный mouse move поверх документа скушает нашу батарейку весьма быстро.
Еще про вычислительную сложность
1. сбросить текущий стиль a элемента и его descendants.
2. Найти новый стиль поддерева:
a. для всех С детей проверить все S правил (CSS) на предмет applicability к данному элементу.
b. если стиль поменялся сделать refresh региона занимаемого <a>
c. если новый стиль изменяет размеры то сделать relayout контейнера(ов).
Если же мы добавляем
body! a:hover конструкцию то на каждое событие a:hover мы вынуждены делать a), b) и c) для всего дерева (документа). Причем возможных оптимизаций сего безобразия практически нет.Скажем есть такие правила:
a:link { border: none; }
body! > a:hover a:link { border-bottom:2px solid; }
Последнее правило читается так: «при mouse hover на любом <a> внутри документа установить border-bottom:2px для всех <a> в документе. Так как border-bottom:2px изменяет размер элемента то мы вынуждены не только пересчитать все стили <a> элементов в документе (а это full scan DOM tree+full window refresh) но и пересчитать layout всего документа. Т.е. тривиальный mouse move поверх документа скушает нашу батарейку весьма быстро.
Еще про вычислительную сложность
А про константы в CSS ничего не слышно?
Есть две альтернативных идеи:
Одна моя «CSS constants»: wiki.csswg.org/ideas/constants
и «CSS variables» изначально предложенная Daniel Glazman: dev.w3.org/csswg/css-variables/
Отличия: мои «CSS constants» это фактически иплементация аналогичной фичи из LESS. Крайне простая в иплементации, работает на уровне CSS парсера и не требует никаких изменений где либо еще. «CSS constants» имплементированы и активно используются в моих HTMLayout и Sciter.
«CSS variables» это на самом деле run-time фича — все properties которые используют некую CSS variable могут быть изменены путем изменения этой variable через CSSOM. Фича достатчно сложная в плане имплементации и требует доработки CSSOM.
Если принять общий набор use cases для CSS constants и variables за 100% то в 95% случаев «CSS constants» достаточно. Но как я понимаю народ все хочет найти perfect solution. Резюме: нескоро мы эту фичу иметь будем.
Одна моя «CSS constants»: wiki.csswg.org/ideas/constants
и «CSS variables» изначально предложенная Daniel Glazman: dev.w3.org/csswg/css-variables/
Отличия: мои «CSS constants» это фактически иплементация аналогичной фичи из LESS. Крайне простая в иплементации, работает на уровне CSS парсера и не требует никаких изменений где либо еще. «CSS constants» имплементированы и активно используются в моих HTMLayout и Sciter.
«CSS variables» это на самом деле run-time фича — все properties которые используют некую CSS variable могут быть изменены путем изменения этой variable через CSSOM. Фича достатчно сложная в плане имплементации и требует доработки CSSOM.
Если принять общий набор use cases для CSS constants и variables за 100% то в 95% случаев «CSS constants» достаточно. Но как я понимаю народ все хочет найти perfect solution. Резюме: нескоро мы эту фичу иметь будем.
Не понимаю, почему нужно изобретать велосипед с селекторами, при этом в упор игнорировать вещи, которые придуманы триста лет назад, опробированы на реальных продуктах, вылизаны как у кота фаерболы? Ну почему нельзя взять формат записи xPath для определения селекторов и навсегда закрыть эту тему? Мало того, писать ничего не нужно, все уже написано и работает. Спека готовая лежит, под носом. Нет, давайте обязательно придумаем свой xpath, но с бриджем и няшечками…
Слово «унификация», видать, авторам не знакома…
Слово «унификация», видать, авторам не знакома…
NIH же
Хочу селектор this для использования в querySelector:
Или даже так:
Только вот не могу придумать, как таким же образом выбрать все сестринские элементы (как в jQuery.fn.siblings).
children = document.querySelectorAll( ':this > *' );
next = document.querySelectorAll( ':this + *' );
Или даже так:
parent = el.querySelector( '*! > :this' ); // аналог el.parentNode
Только вот не могу придумать, как таким же образом выбрать все сестринские элементы (как в jQuery.fn.siblings).
В Sciter работают вот такое:
:root в Element.select это this элемент, и поиск всегда идет по поддереву — детям данного элемента.
siblings будет так
document.querySelectorAll это глобальный поиск и иммеет крайне ограниченную функциональность из-за этого.
var children = elem.selectAll( ":root > *" ); :root в Element.select это this элемент, и поиск всегда идет по поддереву — детям данного элемента.
siblings будет так
var siblings = elem.parent.selectAll( ":root > *" ); document.querySelectorAll это глобальный поиск и иммеет крайне ограниченную функциональность из-за этого.
Вообще, мне кажется, что синтаксис с восклицательным знаком или знаком доллара — совершенно не гибок. Лучшим вариантом был бы новый псевдокласс :has. Пример: взять все элементы li из ul, в котором есть li.active.
ul:has(li.active) > li
Как это сделать с описанным в статье селектором?
Да, это отразится на производительности, но селектор по родителю сам по себе не производителен: web-standards.ru/articles/parent-selector/
ul:has(li.active) > li
Как это сделать с описанным в статье селектором?
Да, это отразится на производительности, но селектор по родителю сам по себе не производителен: web-standards.ru/articles/parent-selector/
Оба моих комментария наталкивают на одну мысль: стоит разделить спецификации CSS селекторов с селекторами, используемыми в JS, а, точнее, первые сделать подмножеством вторых.
Восклицательный знак, если смотреть с точки зрения привычности, более-мене логичен, ИМХО.
Он немного перекликается с !important, поэтому при первом взгляде, сразу видно, что вот этот элемент явно важнее остальных, и правила будут применяться именно к нему.
Мне кажется, что верстка с использованием родительского селектора априори будут запутывать, поэтому нужна ли тут дополнительная гибкость — большой вопрос.
Он немного перекликается с !important, поэтому при первом взгляде, сразу видно, что вот этот элемент явно важнее остальных, и правила будут применяться именно к нему.
Мне кажется, что верстка с использованием родительского селектора априори будут запутывать, поэтому нужна ли тут дополнительная гибкость — большой вопрос.
Честно говоря, мне безразлично то, каким образом будет обозначаться текущий вид родительского селектора, будь то восклицательный знак или знак доллара. Дело тут в слабости самой идеи: можно выбрать «предыдущий в селекторе» элемент и всё. Всё. Нельзя выбрать элементы из этого, нельзя выбрать следующий за ним… Одни только нельзя.
Кроме этого, я всё-таки предположу, что псевдокласс был бы сильно читабельнее, так как восклицательный знак или знак доллара заставляет дольше вчитываться в то, что несет в себе селектор. Скажем, нам надо взять в диве с классом .block ul, который содержит li.active.
В текущем виде это выглядело бы так:
div.block ul! li.active {}
Каждый разработчик привык к тому, что последним элементом в селекторе является тот, к которому применяются стили, но не в этом случае. В этом случае как раз-таки было бы удобно иметь псведокласс:
div.block ul:has(li.active)
Здесь сразу видно, что последним элементом селектора является ul с некоторыми характеристиками.
Другой вопрос в том, что нам может понадобиться не только селектор «имеет», но и селектор «следующий за». Скажем, нам надо выбрать ul, за которым следует p:
div.block ul! ~ p
:has(), как видно, здесь не подходит. Так как это мысли в слух, предлагаю поразмышлять об универсальном селекторе, работающему по принципу «туда-сюда».
Одним из вариантов, пришедшим в мою голову, является другой псевдокласс, скажем, matches-selector:
div.block ul:matches-selector( ~ p )
Читабельность, конечно, хуже.
Для еще большей универсальности и немного улучшенной читабельности, хорошим вариантом было бы добавить обязательно включаемый в этот псевдокласс качестве аргумента псевдоэлемент ::this
div.block ul:matches-selector( ::this ~ p )
Пока пишу этот комментарий, убеждаюсь, что утверждение спецификации — дело не простое, уж очень много спорных моментов.
Кроме этого, я всё-таки предположу, что псевдокласс был бы сильно читабельнее, так как восклицательный знак или знак доллара заставляет дольше вчитываться в то, что несет в себе селектор. Скажем, нам надо взять в диве с классом .block ul, который содержит li.active.
В текущем виде это выглядело бы так:
div.block ul! li.active {}
Каждый разработчик привык к тому, что последним элементом в селекторе является тот, к которому применяются стили, но не в этом случае. В этом случае как раз-таки было бы удобно иметь псведокласс:
div.block ul:has(li.active)
Здесь сразу видно, что последним элементом селектора является ul с некоторыми характеристиками.
Другой вопрос в том, что нам может понадобиться не только селектор «имеет», но и селектор «следующий за». Скажем, нам надо выбрать ul, за которым следует p:
div.block ul! ~ p
:has(), как видно, здесь не подходит. Так как это мысли в слух, предлагаю поразмышлять об универсальном селекторе, работающему по принципу «туда-сюда».
Одним из вариантов, пришедшим в мою голову, является другой псевдокласс, скажем, matches-selector:
div.block ul:matches-selector( ~ p )
Читабельность, конечно, хуже.
Для еще большей универсальности и немного улучшенной читабельности, хорошим вариантом было бы добавить обязательно включаемый в этот псевдокласс качестве аргумента псевдоэлемент ::this
div.block ul:matches-selector( ::this ~ p )
Пока пишу этот комментарий, убеждаюсь, что утверждение спецификации — дело не простое, уж очень много спорных моментов.
Нельзя выбрать элементы из этого, нельзя выбрать следующий за ним…
Напрашивается использование скобок для группировки. Типа так:
(fieldset!>legend) p{…}
то, о чём ты тут рассуждаешь было придумано ещё в мезозое и называется «оси». очень хорошо они описаны теми самыми «старперами» из w3c в спецификации xpath. рекомендую почитать для расширения кругозора. citforum.ru/internet/xpath/xpath02.shtml
XPath в массе своей имеет computation complexity ранга P-hard т.е. O(Nk) где k это некое число явно больше 1.
Т.е. XPath можно использовать для скажем там однократного исполнения/обработки.
Но для ситуации CSS — набор правил описывающих состояние системы и система подверженна частым изменениям (UI events, etc.) — XPath явно тяжел.
Т.е. XPath можно использовать для скажем там однократного исполнения/обработки.
Но для ситуации CSS — набор правил описывающих состояние системы и система подверженна частым изменениям (UI events, etc.) — XPath явно тяжел.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Взгляд в будущее: CSS4