W3C home > Mailing lists > Public > www-style@w3.org > November 2010

RE: [css3-ui] styling of form elements

From: Belov, Charles <Charles.Belov@sfmta.com>
Date: Fri, 12 Nov 2010 15:32:20 -0800
Message-ID: <E17F75B6E86AE842A57B4534F82D03769C328F@MTAMAIL.muni.sfgov.org>
To: "www-style list" <www-style@w3.org>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>
Tab Atkins Jr. wrote on Friday, November 12, 2010 3:00 PM
> On Tue, Nov 9, 2010 at 1:29 PM, Belov, Charles 
> <Charles.Belov@sfmta.com> wrote:
> > This post is to check on planned abilities for styling form 
> elements 
> > and to suggest some if they have not been previously 
> suggested.  The 
> > use case is for people with physical or conceptual 
> disabilities or on 
> > small-screen devices who have trouble with drop-down menus or small 
> > multi-select windows, to be able to override certain choices of a 
> > website for form fields.
> >
> > The proposed styles would cover the following features:
> >
> > - Render each element in a selection menu as a list of 
> radio buttons.
> > - Render each element in a multi-select menu as a list of 
> check boxes.
> >
> > Obviously, there would likely be other changes to the page layout 
> > needed in a user style sheet that did this, but this would 
> be a way to 
> > make certain form elements more accessible.
> >
> > Sorry about the lack of specificity in the subject.  I 
> tried to find a
> > CSS3 spec responsible for forms but couldn't.
> 
> (Sorry for not replying to this earlier - I think I 
> accidentally archived it, because the post below is exactly 
> what I had intended to send originally.)
> 
> The spec in question is the UI module.  It doesn't go into 
> great depth about styling form elements in its current level, 
> but Tantek is working on Level 4 as part of his work at 
> Mozilla, which should expose the guts of form elements more 
> explicitly for styling.

Found it, thanks, Tab.  This is exactly what I was looking for.

I respectfully suggest revising http://www.w3.org/TR/css3-ui/#appearance0 for clarity
such that the example for radio-group uses the same set of content as pop-up-menu, and that list menu have two examples.  The current list-menu value allows only a single select; I suggest adding a second, multi-select, example using the same set of content as checkbox-group. 

As for my larger issue, what I would expect the UI behavior to be is that the existing HTML4 code used to produce the existing pop-up-menu, list-menu and radio-group examples could all have their rendering overridden such that use of the appearance property would force any of those three sets of HTML code to render and behave like any of the other two.  Similarly, the checkbox-group HTML code could be styled using the appearance property to look like a multi-select version of the list-menu HTML code and vice-versa.

I would expect the user agent to respect however I styled it.

That does raise the question, what is the UA to do if somebody styles a pop-up-menu as checkbox-group, that is, swaps the expectation of a single response with a multiple response.  I suppose it would be handled as it is now if I were to mess with an URL string such as http://www.nextmuni.com/predictor/simpleStopSelector.shtml?a=sf-muni&r=2 to change it to http://www.nextmuni.com/predictor/simpleStopSelector.shtml?a=sf-muni&r=2&r=5; if the receiving server can handle the request, it handles the request.  If not, it doesn't.

Similarly, if somebody styles a checkbox-group as a pop-up-menu, the end-user will only get one choice.  Not a problem, unless the server requires more than one choice be made.  In either case, not a UA problem. 

Hope this helps,
Charles Belov
SFMTA Webmaster
Received on Friday, 12 November 2010 23:34:17 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:34 GMT