OK, the "Generalizing frame/widget framework a bit" thread had lots of
good things to say.  I'm attaching a patch in two parts that, IMHO,
represents the group consensus.  This is relative to Quixote 0.7a2; my
previous patch in this direction is withdrawn.

Part 1 adds a new instance attribute 'html_attrs' to Widget.  There's a
corresponding keyword argument to the constructor of all Widget classes,
which expects a dictionary.  This dictionary gets (almost) no special
treatment; if you want to use Python keywords like 'class' as HTML
attribute names, no problem:

  TextWidget(..., html_attrs={'class': "mystyle"})

The render() method of each Widget class is responsible for including
html_attrs in the rendered output.  Most Widget classes only output a
single tag, so it's pretty obvious where the specified attributes go.
Some (namely the SelectWidget-derived classes) have multiple tags;
html_attrs generally affects the top-level, outermost tag, eg. 
in a {Single,Multiple}SelectWidget.  RadiobuttonsWidget is the oddball:
html_attrs is included with every "" tag.

This introduces several backwards incompatibilities with what we've seen
in the Quixote 0.7 series so far: StringWidget's 'size' and 'maxlength'
attributes and constructor keyword arguments are gone, as are
TextWidget's 'rows', 'cols', and 'wrap', and so forth.  Note that this
only affects code written to the quixote.form2 API, so I have no qualms
about the incompatibility.

Part 2 adds a convenience function, quixote.html.htmlattrs(), that can
be useful in building a dictionary to pass to the various Widget
constructors.  This is where special handling of 'class' takes place.
(It also downcases attribute names.)  For example,

  TextWidget(..., html_attrs=htmlattrs(maxlength=40,
                                       class_="mystyle",
                                       onChange="...JS code..."))
is equivalent to

  TextWidget(..., html_attrs={ 'maxlength': 40,
                               'class': "mystyle",
                               'onchange': "...JS code..." })

Choose your preferred level of syntactic sugar.  htmlattr() is not
really necessary, but could be convenient.

Oh yeah, part 2 also beefs up the docstring for our old friend
htmltag(), and changes how 'css_class' is special-cased.  IMHO, with the
addtion of htmlattrs() we can completely remove the special-casing of
'css_class': see the comment I've added.

        Greg
--
Greg Ward                          http://www.gerg.ca/
What the hell, go ahead and put all your eggs in one basket.