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

Re: Pseudo-Classes :button and :input

From: Tobias Herp <Tobias.Herp@gmx.de>
Date: Fri, 18 Sep 2009 01:40:02 +0200
Message-ID: <4AB2C8D2.5000506@gmx.de>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: www-style@w3.org
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 not a serious argument.

By the way, I update my proposal to :textual-input and :button-input.

>> The effort of /one/ additional selector is rewarded with nicely
>> formatted file upload controls.
> As I keep saying I don't expect Firefox to allow web pages to style the
> insides of file upload controls.

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

>> What do you consider more likely: That IE supports attribute selectors
>> (which seems to be difficult and wouldn't solve the file input issue
>> anyway), or that two little additional pseudo-classes (all major
>> graphical browsers know about pseudo-classes, and almost all format
>> buttons) are supported?
> I have no idea.  Why not ask the IE team?

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

> I know for every single other browser attribute selectors are a heck
> more likely to be supported.

Of course, because they are already part of the standard.

>>> It wouldn't be hard to implement.  The question is whether it's worth
>>> implementing and adding to the web platform in general.
>> Since it solves a very common problem, I do think it's worth it.
> The problem already has a solution for buttons, though.  As I said, for
> text controls there's a much stronger reason for this.

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

And you didn't tell me *which* solution for buttons you mean; all you
say is you decline any formatting of file upload buttons, which is a
WONTFIX rather than a RESOLVED.

>>> Not really; Gecko would still not allow the styling of internal parts of
>>> a file input, for example.
>> Why?  "It wouldn't be hard to implement".
> Because we don't think it's in our users' best interests.  It would be
> trivial to implement: I'd just remove the extra code that currently
> prevents it.  But there's a reason we have that code.

I. Am. Not. Convinced.
(of that reason; like I explained at length in another mail)

And there are solutions, like opening a file popup dialog as soon as the
file input field gains focus (which is done already).

>> Well, input fields are inline elements, textareas are blocks
> Not at all.  They're both replaced inlines from the CSS point of view
> (more or less; they do have useful baselines in some browsers, etc).  I
> suggest testing this with the following markup:
>   data:text/html,Some text<textarea></textarea>Some text
> Sure doesn't behave like a block!

I see, you are right.  In my printout of the CSS 2.1 standard, sample
style sheet for HTML 4.0, textarea is missing.  It's a little
contra-intuitive because you take a textarea if you need more than one

>> but when e.g. changing the background color for :focus, I'd treat them
>> just the same.
> Sure.  I understand the use cases....
> What about the 15 other types of form controls in HTML5?

As far as they have textual input parts, these could surely be affected
by rules for :textual-input.  If they have button-like input parts,
these could be affected by rules for :button-input, at least when no
security objections apply (see below).

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.  With HTML 5, there are the additional type values:

search, tel, url, email,
which will be (or at least contain) textual input fields for sure;

datetime, date, month, week, time, datetime-local, number, color,
which might contain textual input fields, depending on the
implementation (and very likely will, since otherwise the choice of a
value for such fields would become cumbersome in many cases).

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

>> It is simple (while sometimes cumbersome, since input[type="submit"]
>> input[type="button"] and button are to be considered) for all buttons
>> *but* those in input[type="file"].
> Which UAs don't want to allow styling in any case.  At least Gecko doesn't.

By the way, as of HTML 5, input[type="file"] is a *label* and a button
and thus simply prevents text being entered manually.

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

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 (which is really simple, or the threat is totally unrelated
to style questions but rather involves scripting).

For browsers, there would be no problem to honor a :button-input rule
for file input as soon as they prevent manual input; for reset, button
and submit types it doesn't introduce any new risk. No reason to not
support it.

>> ???
>> (Sorry, I can't follow you here)
> I would strongly oppose allowing web pages to select and style parts of
> file inputs in Gecko.  Not sure how to be more clear about it....

Sorry, I didn't search the web for you before
(good job with this Lenin guy! ;-)

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

Received on Friday, 18 September 2009 06:47:28 UTC

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