- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 13 Feb 2014 11:02:59 -0800
- To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- Cc: www-style list <www-style@w3.org>
On Thu, Feb 13, 2014 at 10:54 AM, Daniel Glazman <daniel.glazman@disruptive-innovations.com> wrote: > On 13/02/14 19:16, Tab Atkins Jr. wrote: >> That sentence makes no mention of it being invalid in CSS, and I'm >> strongly against Selector syntax being officially valid only in some >> contexts. Browser implementations might not ever *implement* this >> selector, but if they do, it should be recognized in CSS as well. (It >> just doesn't do anything.) > > "doesn't do" is too underspecified for me. That was just a casual description in the email. The spec defines it sufficiently - ::attr() never generates boxes. > We need to know if this is > going to create a empty rule in the OM, a non-empty rule in the OM > with specified values available, or nothing at all. I suspect there > will be some resistance from browser vendors to create an OM instance > if it's never used by the layout. I'd love to be proven wrong but > honestly, I would completely understand the footprint argument. After > all, we still don't store unknownrules or comments in the OM, and that > explanation is a part - only a part but still - of the reason why we\ > don't. I don't understand why you'd infer any of this weird behavior. If you wrote this in your stylesheet: #foo::attr(title) { color: red; } It would be a valid rule that just had no effect on your document, exactly the same as: #foo::before { color: red; } (Note the lack of 'content', so no box generated.) This behavior falls out of the definitions in the spec. We don't need any further information, as far as I can tell. ~TJ
Received on Thursday, 13 February 2014 19:03:46 UTC