[Zope3-dev] Re: browser widgets: items widgets and label tags

[yuppie]

Hi Fred!


Fred Drake wrote:
> On 11/10/06, yuppie <y.2006_ at wcm-solutions.de> wrote:
>> While pointing the label to the div element that contains the input
>> fields is not very useful, this seems to be valid HTML::
> 
> Sorry for not replying earlier, but I wanted to have time to think
> before responding.  ;)

No problem. Thanks for your feedback!

> There's valid according to the DTD (the XML definition of validity),
> and there's valid according to the specification.  DTDs aren't able to
> specify the constraint documented in the specification document; in
> this case, that means the DTD can be used to help detect invalid HTML
> documents, but not determine whether an HTML document is valid.  More
> expressive schema languages could be used to produce a more useful
> schema definition.
> 
> Given that the specification clearly states that the "for" attribute's
> value be an ID for a control, I must conclude that referring to the ID
> of a <div> or other non-control element causes the HTML to be invalid.

I agree with your analysis, but I'm not sure I agree with your conclusions:

Looking at the output generated by formlib, I got the impression nobody 
cares much about valid output. I would be happy if formlib would return 
HTML that validates in a validator. Adding additional complexity for 
getting the label issue perfectly right doesn't fit much to the rest of 
the code. And I doubt any browser will have trouble with 'for' 
attributes pointing to a non-control element.

>> Making sure that radio and checkbox widgets have a div tag with the
>> required ID is a simple bugfix. No API changes are required and
>> zope.formlib still can use the widget name in the 'for' attribute.
> 
> Regardless of the HTML specification, this is a semantic change in the
> contract of the IWidget API.  So it's a change, just not in the set of
> attributes and methods and their signatures.
> 
>> So IBrowserWidget's __call__ method *has to* return a snipped that
>> contains a tag with the widget's name as ID. All widgets that don't
>> follow that rule have to be fixed.
>>
>> If there are no objections, I'll make the required changes on 3.2
>> branch, 3.3 branch and trunk.
> 
> I object; this is still a change to the contract.

Well. It depends on the point of view. This seems to be the implicit 
contract. The templates in zope.formlib and in zope.app.form use the 
widget name in the 'for' attribute, so they depend already on that 
behavior. Making this contract explicit by fixing the description in the 
interface doesn't mean to change the contract. Or does it?

> You were on the right track with your first proposal.  There's a need
> for widgets to provide more information to support integration in a
> form.  Unfortunately, adding an attribute to the IWidget or other
> existing interfaces doesn't work well, since it makes it harder to
> write code that supports multiple versions of Zope.

So there is no way to fix interfaces? Are all interfaces completely 
frozen? (I still have to make myself familiar with the Zope 3 policies.)

> Another way to expose the required information is to create a new
> interface and provide adapters for the existing widgets (possibly by
> simply implementing the new interface on the existing widgets).  A
> form that's aware of the new interface can use the additional
> information.
> 
> The new interface could look something like this:
> 
>    class IWidgetControlInformation(zope.interface.Interface):
>        labelControlId = zope.schema.TextLine(
>            title=_("Label control id"),
>            description=_("Id of the control element that should be"
>                          " associated with any <label> element rendered"
>                          " for the widget."),
>            required=False,
>            )
> 
>        focusControlId = zope.schema.TextLine(
>            title=_("Focus control id"),
>            description=_("Id of the control element that should be"
>                          " focused when the form is initially rendered."
>                          " Since each widget may suggest an element for"
>                          " the initial focus, this should only be regarded"
>                          " as a hint."),
>            required=False,
>            )

This looks like overkill to me. No use case comes to my mind where 
focusControlId would be different to labelControlId.

But if Zope 3 policies require a new interface for changes like that and 
if we really want to stick that close to the HTML specification I'm fine 
with adding IWidgetControlInformation.


Cheers,

	Yuppie