[Html-widget] Creating separate fieldsets in a form

[Michael Gray]

On Tue, 29 Aug 2006, Bogdan Lucaciu wrote:

> I'm using trunk with the new updates, they seem to work very nice (for
> my needs anyway :) ).

Excellent!

> the fact that an id is always generated, although I rarely need an id,
> so the DOM namespace gets severly poluted with useless ids:

I'd be interested in others' opinions on this.  labels and inputs need
to rendezvous via ids (for some styles, anyway) so in that respect
automatic ids are helpful.  But they do get cumbersome.

> Whenever I add a fieldset element in the widget, it is rendered directly
> as <form> children. But if I add a non-fieldset element, a fieldset is
> automatically created to hold it (default behaviour in the earlier
> version) , but the other fieldsets don't get embedded in this automatic
> main fieldset, but go right under it. So the result is something like:
> ... 
> This is very simply corrected if I add the main fieldset manually, and
> put the other fieldsets and the submit button in it.

I would say that is the recommended way to use the 'new' non-back-compat 
HTML::Widget.

> the obvious bugfix is to render the elements in the order they were
> added (don't put the submit button on top if it was added after those
> fieldsets)

If that can be done without breaking the back compat, it would be good.

> Besides that, a DWIM behaviour (for me anyway) would be these elements
> should be syblings in the DOM Tree:
> $w->element('Fieldset');
> $w->element('Fieldset');
> $w->element('Submit');

Kind of - but I see the default fieldset as for back compat, it's better 
to specify it - or one of the other valid containers as per XHTML strict 
- explicitly.

> I don't know if it was clear enough, I can write a test if needed.

A test would be good, but no promises that back-compat, sane new 
behaviour, and this extension to implicit main fieldset, can all be 
reconciled! :-)

-- 
Michael