Re: pseudo-attributes

All right, hopefully last round of questions.

On Thu, Oct 30, 2008 at 2:13 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> 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.


If I'm reading it right, all of the data-* attributes are there, and dataset
is merely a convenience attribute.  Without it, you'd always have to use
array notation to access those properties, due to the hyphen in the names..
Frex, elem["data-id"] vs elem.dataset.id.


>  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.
>
>> 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.


Ok.  So, DOM attributes can be matched against easily (we do that now).
Expando properties cannot without performance penalties (and they'd
introduce wierdness due to language-specificness).  So what about simple DOM
properties (as opposed to the attributes)?  That's of course what David's
asking for the in OP.  Can arbitrary DOM properties be matched against
efficiently?  If so, then we can address David's request in a generic way,
and also open up the ability to match against further properties without
having to go through the whole process again.


>  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...


Yes, that's what I was meaning.

~TJ