- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 27 Feb 2014 10:34:02 -0800
- To: Jirka Kosek <jirka@kosek.cz>
- Cc: Simon Pieters <simonp@opera.com>, Simon Sapin <simon.sapin@exyr.org>, www-style <www-style@w3.org>
On Thu, Feb 27, 2014 at 9:42 AM, Jirka Kosek <jirka@kosek.cz> wrote: > On 27.2.2014 18:26, Tab Atkins Jr. wrote: >>> But as there is already inconsistency between type selectors ("E" >>> selects E elements in any namespace) and attribute selectors ("[A]" >>> matches elements that have A attribute in no namespace) >> >> That's due to default namespaces, not anything fundamental. It's also >> not an *internal* inconcistency - "E" and "*" both select using the >> default namespace in type selectors, while attribute selectors don't >> have a "*" at all, and so can't be inconsistent internally. > > But if there is no default namespace in CSS, then namespace treatment of > "E" and "[A]" is very different. No, it's exactly the same. If you don't explicitly declare a default namespace, the default namespace is "*". Everything I said is still true. >>> I don't think >>> that special treatment of "*" as wildcard in ::attr(*) will do any harm. >>> After all this behaviour can be brought back to attribute selectors -- >>> "[*]" will match element that has at least one attribute. >> >> If attribute selectors allowed "[*]", it would match an element with >> at least one attribute *in the null namespace* (to be consistent with >> the behavior of plain attribute names). You'd have to write [*|*] to >> select an element with any attribute whatsoever. > > Although I can follow you reasoning, I don't consider such behaviour of > * really useful and logical. Probably due to my 15 years experience with > XPath. :-) > > If you really think that having ::attr(*) for all attributes will result > in dead kittens, let's move on and have ::attr() for choosing all > attributes. Hey, it's even less typing! Let's move on with this, yeah. ~TJ
Received on Thursday, 27 February 2014 18:34:49 UTC