Re: Pseudo-Classes :button and :input

> On 9/17/09 7:40 PM, Tobias Herp wrote:
Boris Zbarsky wrote:
> Hold on.  You argument was that this proposal is better than attribute 
> selectors "because IE doesn't support them".

No, not really. In my initial post, I not even mentioned IE.
Unfortunately, we have very often the requirement to support old IEs which indeed don't support them, and thus use classes.

> ... so that's not an argument against 
> attribute selectors.

I don't oppose attribute selectors.  But just to style very ordinary buttons, you have to use three of them already (for reset, button and submit types), and an additional element selector for "real" buttons.

HTML5 input types like number, date etc. could contain a textual input /and/ a button-like part; in these cases, there would arise the same design problem as with file inputs, but without the (real or not) security threat.
 
> 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, maybe. I'm not sure whether this is necessary with labels instead of input areas; but of course a browser could recognize a :button-input pseudo-class and ignore it for file inputs.

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

Seems like they (at least try to) take the lead when supporting web standards (leaving out Opera here)

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

Of course I'd be interested in concurring suggestions.
IMO HTML shouldn't bother about styling issues (like in the Bad Old Days, when the font tag was invented).

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

Maybe the button situation is not bad enough to motivate the use of pseudo-classes; but for textual input it is, and HTML5 will make it worse.
So, why should we establish a pseudo-class for textual input only?

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

Only what I wrote:
- :textual-input to match any textual input
  (except file input if you must)
- :button-input to match any button input (where appropriate, and
  with the possible exception of file controls)

> Not quite.  You also have:
> 
>    input[type=""]
>    input[type="foopy"]
>    input[type="123"]

Well, of course the pseudo-classes would apply only to known types.
Browsers wouldn't know how to render type="foopy" either, would they?

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

The size of nightmares matters ;-)

> > ... as of HTML 5, input[type="file"] is a *label* and a button
> > (...) and thus simply prevents text being entered manually.
> 
> Right.  Like I said, that's the direction browsers are moving in anyway.

Fine; this way, file controls become at least /less/ dangerous.

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

We don't need to decide this here.  The standard could allow user agents to ignore the styling for file input.  I assume most browsers will honor them and ensure safety in another way.

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

If the user "clicks here", the system's file selection dialog will pop up. I don't suggest to make this behavior changeable (this would be beyond the scope of CSS, anyway).

What do you expect users to think?
"I don't know what the heck is going on;
let's choose an interesting file and see what happens?"

(Ok, in a country like the USA where people must be told not to dry their pets in their microwave ovens, this might be an option)

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

We could restrict the use of certain properties for sub-elements (probably necessary for file inputs only); black list:

visibility
display
position

If we are /really/ paranoid, we can use a white list instead, containing e.g.

border
color
background-color
padding
vertical-align
font

and require the parent input element to expand until they are large enough for all contained children, and a minimum contrast for the color settings.

We have properties already which are honored in certain contexts only, e.g. depending on border-collapse (for table elements).

> > But even you are a mortal man, and sometimes you're wrong.
> 
> Sure.  This might well be one of those cases.  ;)  We'll see.

It's always a pleasure to discuss with co-mortals.

-- 
Tobias

Received on Friday, 18 September 2009 10:37:48 UTC