Re: pseudo-attributes

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

> Tab Atkins Jr. wrote:
>
>> Consider my earlier words as imprecise, then.  I am proposing that
>> attribute selectors use the DOM property values, rather than the written
>> attribute values, at least in html.
>>
>
> This would introduce a really bizarre difference between HTML and other
> languages.


A fair criticism.


> It would also break any site using something like [class=foo].


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.  In my case,
before this email I assumed that .foo and [class="foo"] were exactly
identical in terms of matching.


>
>  We already have :checked relying on a DOM value rather than an attribute
>> value
>>
>
> Right, but it doesn't reuse the existing attribute syntax.  Hence David's
> proposal to create a new syntax to refer to things like this. Making it work
> for arbitrary properties is an interesting thought, but would you limit this
> to DOM properties?  Or also expandos?  What about cases where a property
> would be an expando in one browser but a DOM property in another?  What
> about cases when an property is set to different values in different
> languages, in environments that support that?
>
> Trying to define a blanket rule here that sort of makes sense is going to
> be very very difficult.


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.  This would be a necessity, actually, with html5's
introduction of the entire class of @data-* attributes, which are
effectively language-blessed expandos if I understand correctly.  These are
to be used for local scripts to play with, and being able to hook styles off
of them as well would eliminate a lot of extra work in setting and unsetting
classes alongside value changes (frex, changing @data-brightness from 5 to 4
might require removing the data-brightness-5 class and adding the
data-brightness-4 class).

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

~TJ