Re: pseudo-attributes

On Wed, Oct 29, 2008 at 2:50 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

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


Ah, duh.  Gotcha.  (Again, the fact that I use jQuery for all my DOM
manipulation shows through.  I've forgotten these little differences.  It's
all addClass(), removeClass(), toggleClass() to me.)


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


Ok.


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


I am, but it's due to a bad test-case.  Having fixed it, I can definitely
say "never mind".

Though this does bring up a question.  The data-* attributes are supposed to
be DOM attributes, right?  They don't have well-defined names, though.  If
arbitrarily-named attributes can be added to an element, manipulated via
scripting, etc., and more importantly, matched by a CSS attribute selector
(as you say they can in the next quote block below), then is there any real
difference between data-* and expandos?  Will data-* attributes be expensive
to check for as you say expandos are?  Or is it something special about one
of them living in the DOM and the other living in the js embedding?

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


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


Because of my horrible test-case, I assumed that the attribute selector only
went off of the original value specified in the page, and didn't respond to
scripts changing the value.  I have since learned I was wrong.


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


All right, so bear with me as I reason through this.  (Thank you for your
responses, btw.  You're always very helpful, Boris.)

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

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.

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

~TJ