Re: pseudo-attributes

L. David Baron wrote:
> Here's an idea for a future level of selectors, which I proposed a
> few days ago in
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016544.html
>
>
> There are some things, like the values of form controls such as text
> inputs, that are rather like attributes (in that they have string
> values), except they're not actually attributes in the markup.  The
> various forms of attribute selectors would all make sense on these
> things.
>
> The one I'm suggesting here would be a :value pseudo-attribute,
> representing the current value of a text control.  (The value
> attribute in HTML represents the default value, not the current
> value.)
>
> With this, one could, for example, style inputs that don't have
> anything in them:
>
>   input.mandatory[:value=""] { background: red; }
>
> or be used to implement a proposed "placeholder" attribute that
> contained text that should be shown until something was entered:
>
>   <input id="search" type="text" placeholder="Search this site">
>
>   input#search[:value=""] {
>     content: attr(placeholder); /* assuming 'content' works */;
>   }
>
> -David
>
>   
David,

selector input#search[:value=""] implies that UA will be forced to 
resolve the style of the element on each character typed in the input element.

That I think would be too much.

We have solved this problem by delegating value of :empty flag calculation to the behavior 
under the particular input. So style changing is triggered only when the input becomes not empty. 
Some of input elements (in particular type="text" and type="select") support also 
novalue="..." attribute. Combination of :empty and @novalue gives enough options in most of cases. 
We decided to do this by DOM attribute because usually text that needs to presented to the
user is unique from control to control.

And yet, logically  

input#search[:value=""] { content:"some value"; }

is an equivalent of just

<input #search value="some value" />

I mean it is not clear what css::content should be mapped to
in inputs.


||--
Andrew Fedoniouk.

http://terrainformatica.com

Received on Thursday, 16 October 2008 19:35:11 UTC