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 the
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:
If they
On Nov 12, 2006, at 7:30 AM, yuppie wrote:
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-cont
Hi Fred!
Fred Drake wrote:
AFAICS the biggest problem are the poorly maintained widgets in
zope.app.form.
Poorly maintained? I don't think that's it. While many were
developed quickly and are questionable, a lot of the problem is the
interfaces. They just aren't conducive to building robus
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 are
On 11/11/06, yuppie <[EMAIL PROTECTED]> wrote:
Well. I can't see why Zope 3 has to ship with two completely different
implementations of widget rows and I don't like the formlib template
either. But this is not the code that causes validation errors.
I can't say that I like any of the form-gene
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 are used heavily in zope.testbrows
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 horrid
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 horrid template any
way, it could simply have used wi
Hi Fred!
Fred Drake wrote:
On 11/10/06, yuppie <[EMAIL PROTECTED]> 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. ;)
N
On 11/10/06, yuppie <[EMAIL PROTECTED]> 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. ;)
There's valid according to the D
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::
WIDGET_LABEL
spam
h
12 matches
Mail list logo
