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