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 :) ).
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
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
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:
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! :-)


Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 7 of 8 | next ›
Discussion Overview
grouphtml-widget @
categoriesperl, catalyst
postedAug 26, '06 at 3:37a
activeSep 20, '06 at 1:52p



site design / logo © 2018 Grokbase