Комментарии 33
Тухловато… Но пусть делают, посмотрим, что выйдет.
К моему возмущению, в прошлом году выкинули idref combinator. В результате как отсутствует напрашивающаяся возможность стилизовать label, относящийся к input[type=«check»], в зависимости от состояния последнего, так её и не предвидится.
«:has» — очень интересный селектор. Долгожданная реализация «parent-селектора», о необходимости которого было столько дискуссий. Далеко не худшим способом реализовали, надо сказать, другие варианты были тухлее.
Не, не впечатлили.
Куча вещей, которые можно сделать препроцессорами, пара сомнительных мелких нововведений и :has, который, конечно, всем хотелось (да и мне тоже), но который стооолько геммороя принесет. И с быстродействием, и с починкой кривой верстки.
Куча вещей, которые можно сделать препроцессорами, пара сомнительных мелких нововведений и :has, который, конечно, всем хотелось (да и мне тоже), но который стооолько геммороя принесет. И с быстродействием, и с починкой кривой верстки.
Нормальный родительский селектор решили не делать значит
А в чём разница?
На мой взгляд это тот, который первым приходит в голову при словосочетании «родительский селектор» и работает от элемента, например a ^ div. С производительностью не было никаких проблем.
Плюс, весь код (стили состояния элемента и зависимые стили родителя от этих состояний) был бы собран в одном месте. Хотя это вопрос сложный. При большом количестве зависимостей от потомков, удобнее их было бы собирать на родительском элементе
Плюс, весь код (стили состояния элемента и зависимые стили родителя от этих состояний) был бы собран в одном месте. Хотя это вопрос сложный. При большом количестве зависимостей от потомков, удобнее их было бы собирать на родительском элементе
Не думаю, что по скорости это отличается от
:has
, по сути — это две формы указания того, что применять селектор надо не к конечному элементу, а к элементу, который находится в середине.Так а чем это отличается от div:has(a), кроме формы написания?
<table> <col span="2"> <col class="selected"> <tr><td>A <td>B <td>C <tr><td colspan="2">D <td>E <tr><td>F <td colspan="2">G </table>
Как понимаю, это аналог такого?
<table>
<col span="2"></col>
<col class="selected"></col>
<tr>
<td>A</td>
<td>B</td>
<td>C</td>
</tr>
<tr>
<td colspan="2">D</td>
<td>E</td>
</tr>
<tr>
<td>F</td>
<td colspan="2">G</td>
</tr>
</table>
Я имею в виду отсутствие закрывающих тегов.
Закрывающий не обязателен в некоторых случаях: www.w3.org/TR/html/tabular-data.html#the-td-element
Кстати, в таком стиле (без закрывающих тэгов), если я не путаю, уже давно можно писать код) хотя я до сих пор не заимел такой привычки. Я сейчас проверил, да, браузер нормально воспринимает подобные махинации) Интересно, есть где-нибудь статья на эту тему?
Интересно, а прокатит ли что-то типа этого в JS?
Вместо небогоугодного, но безальтернативного (кроме кучи кода)
node.querySelectorAll('.parent:has(::scope)');
Вместо небогоугодного, но безальтернативного (кроме кучи кода)
jQuery(node).parents('.parent');
Вот что мне не понятно, так это то, почему до сих пор блуждание по тегам невозможно унифицировать на единой платформе?! Есть XPath, jQuery, нативные JS getElementById, выбор элементов в CSS, добавим ещё всякие библиотечные решения да ещё основу — регулярные выражения. При этом, в сущности, ищут все по одному и тому же дереву документа, но каждый норовит изобрести что-то своё. Понятно, что CCSникам сложно, наверное, оперировать XPath, но этот зоопарк — ещё больше запутывает ситуацию. Уж лучше избрать какую-то, пусть сложную, но единую основу поиска по дереву документа.
В старенькой статье тоже неплохо описаны плюшки: habrahabr.ru/post/167333/
Тест css4 селекторов в браузере: css4-selectors.com/browser-selector-test/
Тест css4 селекторов в браузере: css4-selectors.com/browser-selector-test/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что нового в CSS селекторах 4-го уровня?