[whatwg] Comments on styling form elements

[Ryan Cannon]

One subtle grammar point: the sentence, "It is recommended that form 
controls remain faithful to the look and feel of the system's global 
user interface, though." Should omit the word "though."

Also, it would appear that the absence of any guidelines here would 
cause more problems than the simple addition of new input types would 
solve. For example, some UAs regard the background of a radio button as 
the color inside the button, while others color the box surrounding the 
button. Currently, web designers are hard pressed to integrate forms 
into design, as some elements can be styled and others cannot. WHATWG 
should consider some general language concerning the guidelines of how 
widgets interact with stylesheets.

In order to preserve user understanding of forms and their functions, 
WHATWG should insist that UAs perform in one of the following ways:
- Allow styling form elements: The UA must allow for the styling of all 
form elements using and external style language.
- Disallow styling of form elements: The UA must ignore style rules for 
all form elements with the exception of those properties controlling 
layout, position, size and visibility.

Although this may be beyond the scope of the specification, it would be 
better to provide some guidelines, for consistent form styling, as web 
developers will refuse to use certain widgets if they cannot integrate 
them easily into their product. An example for visual UAs:

- For character input and button types (|text 
<http://www.whatwg.org/specs/web-forms/current-work/#text>|, |password 
<http://www.whatwg.org/specs/web-forms/current-work/#password>|, |email 
<http://www.whatwg.org/specs/web-forms/current-work/#email>|, |uri 
<http://www.whatwg.org/specs/web-forms/current-work/#uri>|, 
date-related, time-related, button, reset, submit and |number 
<http://www.whatwg.org/specs/web-forms/current-work/#number>| input 
types), the UA should respect the background-color as the background of 
the form widget and the color as the text-color of the widget.
- For non-character-input types (radio, checkbox, range) UAs should 
utilize the background-color and color properties to style the widget 
itself, and not the whitespace surrounding it, which should be inherited 
from the parent element. For example, the default HTML checkbox and 
radio inputs would be styled as follows:
input[type="checkbox"], input[type="radio"] {
    background-color: white;
    border: 2px inset;
    color: black;
}
In this example, changing the color property would alter the color of 
the checkmark or dot appearing in the respective widgets when selected.
- For the select element, file input type and other more complex 
widgets, user agents should implement background-color and color 
properties similar to character input types and utilize the :before or 
:after pseudo-classes to style their other parts, for example, a default 
stylesheet in HTML 4.1 would read:
input[type="file"], select {
    background: white;
    border: 2px inset;
    color: black;
}
input[type="file"]:after, select:after {
    background: #CCC;
    border: 2px outset;
    color: black;
    font-size: .8em;
    padding: .1 em .2ex;
    text-align: center;
}
input[type="file"]:after {
    content: "browse...";
}
select:after {
    content: "v"
}

Of course, I am not the pro at specification language, but I hope you 
understand the theory behind my comments. Thank you for your time.
-- 

Ryan Cannon
Freelance Web Design
RyanCannon.com <http://ryancannon.com/?refer=email>
(989) 463-7060