W3C home > Mailing lists > Public > www-style@w3.org > October 2008

Re: pseudo-attributes

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 29 Oct 2008 12:50:53 -0700
Message-ID: <4908BE9D.9050805@mit.edu>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: www-style@w3.org

Tab Atkins Jr. wrote:
> While I doubt anyone uses [class] instead of .class, this is again a 
> fair point in general.  It would break sites using that *if* they are 
> changing a property dynamically but expecting the styling to not 
> change.

Well, the reason [class] would break is that the DOM property is called 
"className", not "class".

> Well, right now David's property is just hacking a single DOM property 
> into the pseudoclass syntax.  We already have a small number of these.


> Now, for a general proposal, I'm not sure I see anything wrong with it 
> applying to expandos.

Well, except this is actually very expensive to check for (much more so 
than a predefined set of DOM properties that have layout effects anyway).

> This would be a necessity, actually, with html5's 
> introduction of the entire class of @data-* attributes, which are 
> effectively language-blessed expandos

I think you're mixing up expando JS properties and DOM attributes again..

> and being able to hook 
> styles off of them as well would eliminate a lot of extra work

But you can already do that using attribute selectors.

> As for a single property being set to different values in different 
> languages, I wasn't aware this was a possibility (to be fair, I've never 
> used anything other than js for client-side scripting).

Well, the point is that "expando" properties are just a hashtable (or 
list or whatever) of name/value pairs that aren't actually part of the 
DOM: they just live in the JS embedding.  Which means that code in other 
languages touching the same DOM generally speaking doesn't see them.

> However, any problems that may occur here are already present in existing CSS, as the 
> class selector (among others) keys off of the DOM value rather than the 
> attribute value.

I'm not sure what you mean by "DOM value" here.  The class selector most 
certainly matches based on the string value of the attribute.

> If this is a possible issue, how is it currently 
> resolved with classes?  We can apply the same reasoning to a general DOM 
> property selector.

You're talking about arbitrary JS properties above, though, not DOM 

Received on Wednesday, 29 October 2008 19:51:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:40 UTC