W3C home > Mailing lists > Public > www-style@w3.org > September 2009

Re: Pseudo-Classes :button and :input

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 17 Sep 2009 20:47:10 -0400
Message-ID: <4AB2D88E.1040306@mit.edu>
To: Tobias Herp <Tobias.Herp@gmx.de>
CC: www-style@w3.org
On 9/17/09 7:40 PM, Tobias Herp wrote:
> Boris Zbarsky schrieb:
>> On 9/16/09 4:58 PM, Tobias Herp wrote:
>>> Yes. But you can't rely exclusively on attribute selectors currently
>>> anyway since IE doesn't support them
> (... which apparently isn't true for ie8, see below ...)
>> It doesn't support your new proposal either.
> Not very surprisingly, since it is a /new/ proposal.
> *Every* new feature of a new standard will be unsupported for some time
> in some browsers. This is notx a serious argument.

Hold on.  You argument was that this proposal is better than attribute 
selectors "because IE doesn't support them".  I was just pointing out 
that it doesn't support either one, so that's not an argument against 
attribute selectors.

> But there are no objections at all against the formatting of the textual
> input parts (whenever present, depending on the browser), right?

Textual input parts?  You mean of a file control?  The styling you can 
apply to anything in the file control will likely always be severely 
restricted is all I'm saying.

> Ok, we know now that ie8 supports (or at least claims to support) all of
> CSS 2.1 (last time I tested the printing features --
> page-break-after:avoid etc. -- with Seamonkey or Firefox, they didn't
> really work).

Gecko doesn't really support the page-break stuff, nor claim to support 
it.  Not sure what that has to do with IE.

> So you agree it would be a good thing to have at least the
> :textual-input pseudoclass, right?

And have it match text inputs?  It might be, yes.  Or some other way to 
do it, whether provided by CSS itself or HTML.

> And you didn't tell me *which* solution for buttons you mean

I don't see an overriding need for a single pseudoclass (say) that 
matches all the different kinds of buttons, since they're simple to 
select with existing selectors (unlike text inputs, which are a huge 
pain to select with existing selectors, if it's even possible at all I 
suspect it just isn't possible, in general).

> As far as they have textual input parts, these could surely be affected
> by rules for :textual-input.

Possibly.  My point was that it sounds like you're going to want a much 
richer model for styling form controls in general if Web Forms happens.

> With HTML 5, we /need/ a possibility to catch several input types at
> once. Currently, we only have input[type="text"],
> input[type="password"], the textual part of input[type="file"], and
> textarea.

Not quite.  You also have:


and so forth.  Those are all text inputs per HTML4 (and HTML5, last I 

> Without something like :textual-input, writing style sheets for HTML 5
> forms will become a nightmare.

Probably.  Even with just that it might be a nightmare.

> By the way, as of HTML 5, input[type="file"] is a *label* and a button
> (http://dev.w3.org/html5/spec/Overview.html#attr-input-type-file-keyword)
> and thus simply prevents text being entered manually.

Right.  Like I said, that's the direction browsers are moving in anyway.

> Thus, with HTML5 there is definitely *no* reason whatsoever anymore to
> disallow button formatting for file controls.

Possibly.  I'm not completely convinced that it's safe to allow 
arbitrary styling (which is NOT the same thing as "formatting", by the 
way) for file control buttons.

> And you passed over my proposed sentence for the standard which would
> require conforming browsers to take care to prevent the abuse of file
> input fields

It doesn't really prevent abuse so much.  It's a mitigation strategy, 
but it doesn't make it clear to the user "if you click here, you will be 
uploading a file".

> For browsers, there would be no problem to honor a :button-input rule
> for file input as soon as they prevent manual input

I'm not sure I agree with you.

By the way, if we allow styling of that button, hypothetically, how 
should position:fixed on the button be handled?  display:none?  Other 
interesting styles?

> But even you are a mortal man, and sometimes you're wrong.

Sure.  This might well be one of those cases.  ;)  We'll see.

Received on Friday, 18 September 2009 00:47:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:39 UTC