Hi Fred!
You vetoed my first proposal, so please let me know if I was able to
convince you that it is the best short term solution. Or if you are at
least fine with my alternative proposal.
yuppie wrote:
This is what I propose:
- I'll fix the issue in Zope 3.2, 3.3 and trunk by making
Hi Benji!
Benji York wrote:
yuppie wrote:
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.
The for attributes in labels
-default widgets like the radio and
checkbox widgets and in display widgets. They might not be used as often
as the other widgets and therefor less maintained.
Philipp:
* we now explicitly state a contract that has been assumed implicitly
before
yuppie:
I think this would be the case if we
Gary Poster wrote:
On Nov 12, 2006, at 7:30 AM, yuppie wrote:
This is already broken for choice checkbox and radio widgets. In these
cases we have no 1:1 relationship between widget labels and controls.
(Though sometimes additional 1:1 labels within the widgets do work.)
an aside
Hi Philipp!
Philipp von Weitershausen wrote:
yuppie wrote:
Looking at the output generated by formlib, I got the impression
nobody cares much about valid output.
formlib's standard template is horrible. zope.app.form's rendering is
much better. I have no idea why formlib uses its own
Hi!
I found a simpler solution:
yuppie wrote:
Pointing the label to a specific input field would not be very useful.
AFAICS the widget's label tag should have no 'for' attribute at all.
Instead, each value text should be a label. Something like this::
labelWIDGET_LABEL/label
div class
branches?
Cheers,
Yuppie
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
.
Cheers,
Yuppie
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Hi Stephan!
Stephan Richter wrote:
On Friday 08 September 2006 04:12, yuppie wrote:
Are there good reasons why these changes were not backported?
I volunteer to backport some fixes I'm missing in Zope 3.2, but that's
no general solution for keeping the current stable branch maintained
trunk and Zope 3 trunk to the new versions of ZConfig
and ZEO
4.) fix http://www.zope.org/Collectors/Zope/1507 and
http://www.zope.org/Collectors/Zope3-dev/383
I'd volunteer to do the necessary changes in Zope 2.
Any comments? Any volunteers for the other tasks?
Cheers,
Yuppie
BTW: Why
10 matches
Mail list logo
