Attrs on widgets composed of more than one HTML input

[Iwan]

Hi there,

I have a question regarding, shall I say, policy regarding where
attributes are placed on widgets (and MultiWidgets) that are rendered
as more than one HTML input.

Should what's passed in attrs be put on the individual inputs, or on
one encapsulating element (such as a div or an ul).

My question is sparked by a problem we have with
newforms.widgets.RadioSelect. Currently, it will render itself as a
<p>, followed by a <ul> of radio inputs (this is if you as_p on the
form):

<p><label for="id_x">Option:</label> </p>
<ul>
<li>
<label>
<input value="A" name="x" id="id_x_0" type="radio"> Option A
</label>
</li>
<li>
<label>
<input value="B" name="x" id="id_x_1" type="radio"> Option B
</label>
</li>
</ul>

We need to be able to add a stylesheet to set the list-style for that
list (so list items do not get bullets, which is otherwise the
default).

To do that we need to add a class attribute to the ul (See ticket
#4080 - thought it to be a bug). In the meantime, however, ticket
#3870 implemented things differently.

I need to know whether #3870 is correct (from a design perspective) in
its assumption that the args you pass to a widget should be applied to
all its "constituent parts"? I think it makes more sense to give it a
div or something and apply the args to one conceptual thing...

One way or another, I'd like to know what changes we can suggest to
fix the problem of being able to style the ul of a RadioSelect...

Thanks
-i

[~Kender]

Along this same line, there's another issue with the RadioSelect
widget.. It makes use of a rendering (returned by the render method)
but the class is hardcoded in the method, so there's no way to supply
an alternative renderer except to subclass both classes (the renderer,
and the RadioSelect widget). Being able to supply a new rendering
object would allow easier customization of the appearance of the
RadioSelect widget. Then it's just a matter of subclassing
RadioFieldRenderer and overriding the __unicode__ method.

Thanks,
Chad Simmons

[Malcolm Tredinnick]

Please open a ticket in Trac for things like this. Bug reports and
enhancement requests on the mailing list are very easy to forget about.
Items in Trac don't get lost.

Thanks,
Malcolm