Re: pseudo-attributes

Tab Atkins Jr. wrote:
> Though this does bring up a question.  The data-* attributes are 
> supposed to be DOM attributes, right?

Not as far as I can see.
http://www.w3.org/html/wg/html5/#custom-data-attribute talks about
having a single DOM property called "dataset" which will give access to
the values of the data-* attributes via a string name->value mapping.
It's basically just like getAttribute/setAttribute/removeAttribute but
it does automatic insertion of "data-" into the names.

> Or is it something special about one of them living in the DOM and
> the other living in the js embedding?

Basically, yes.

> That is, what's the practical difference between an arbitrary DOM 
> attribute and an arbitrary expando attribute?

The former is aready handled by the DOM code (for storage, etc), which
can then notify the style system about all attribute changes.

The latter involves installing language-level watchpoints in the JS
engine, with a corresponding performance penalty.  It can be done, but
I'm not sure it's worth the price.

> So, we have an <input> with a value attribute.  I type into the 
> <input>.  The DOM property named value changes.  The DOM attribute 
> @value does not.  Thus, we can't use [value] to match against what we 
> type into the <input>.

Yep.

> Now, I add some JS.  When I click a button, it alters the element's DOM 
> property named className.  This *does* change the DOM attribute @class.  
> Thus, we *can* use [class] to match against the changes the script makes.

Right.  Note that if your JS changed the defaultValue property of the
input that would change its @value, and you could match on that.  The
issue that prevents attr matching on the user input is that user input
is not reflected in an attribute.

> What I'm curious about is what the difference here arises from, why 
> there is such a difference, and how we can get around it.

In order, (1) because the DOM spec specified it that way, (2) possibly
because it was felt that reflecting "transient" user input in the DOM
didn't make any sense (but I wouldn't place money on this; I wasn't
there) and (3) that's what David's proposal was about.

> If it turns out that we really just need to special-case these things in 
> pseudoclasses, so be it.  I'd prefer to create a more generic method, 
> though, that won't require the working group to add it into a 
> specification and for me to wait several years for all relevant browsers 
> to implement it before I can use it, if it is at all possible.

You'd end up waiting no matter what, unless you mean waiting every time 
another item of information that's not stored in an attribute wants to 
be exposed via CSS...

-Boris

Received on Thursday, 30 October 2008 19:14:24 UTC