RE: Attributes on Select Lists

Frank Rosendahl writes:
> as of my knowledge - u can't...
> In a <SELECT>, u can edit width, font-size, etc but not the "scrollkbar"
> (If its possible - i would really like to know - i've been trying to modify
> it myself...)

That's correct: you can't.

There is no standard that says what a SELECT looks like, and so it
hard for CSS to provide properties for it.

There are various possible approaches to fix that:

 1. Make an inventory of the various ways SELECTs are represented in
    different browsers (menu, list, combo-box, cyclic button, radio
    buttons...), make a property to let the designer choose which one
    he wants, and a set of properties for the various parts of that

    Question is: does this require every browser to support all of the
    different styles?

 2. Make the same inventory and sets of properties for each type of
    SELECT control, but leave the choice to the browser. The designer
    can set properties for each of the possible shapes of the control,
    he just doesn't know which of those will apply in which browser.

    Remark: this is what we are going to do for the scrolling
    mechanism that is associated with the 'overflow' property. Most
    mobile devices will use "marquee" when the box overflows, most
    desktop browsers will use scrollbars. We'll have properties to
    control how the marquee looks & moves, but not to force the
    browser to actually use marquee instead of scrollbars.

 3. Define a standardized user interface description language
    (something like XUL, e.g.) and create a file that describes the
    exact SELECT control you want in that language. Then bind that
    file to the SELECT element, like so:

        SELECT { behavior: url(my-select-control.ui) }

    It is powerful (you can create things never seen before), but also
    very complex, both for the designer and for the browser. Also we
    don't have such a language yet, although apparently you can fake a
    lot with Javascript (and SVG to draw the scrollbars?). But then
    again, do we want to require Javascript from every browser that
    supports CSS? (I have my Javascript turned off all the time, even
    in browsers that do support it.)

We have to do something, because XForms[1] is approaching, and it is
even more high-level then HTML forms. It expects some external
mechanism, presumably a style sheet, to define how a "selectOne"[2]
element looks in a browser, prints on paper or sounds on the phone...


  Bert Bos                                ( W 3 C )                              W3C/INRIA                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Thursday, 24 January 2002 13:31:12 UTC