On 31 May 2007, at 05:28:57, Blake wrote:
In a way I could almost take Katrina's thinking a little further wrap
each fieldset in an li tag as part of an unordered list of
fieldsets, and insert an additional fieldset into each exisiting li.
Like so...
Keep it up and you'll get your page size
Keep it up and you'll get your page size back up to nested table
levels ;-)
I was expecting a response like that. As I said, it is over the top,
but it is an idea of how far things can go if you try too hard to
pursue semantics. Sometimes the goal post is a little too far away,
and we can only
It probably shouldn't be used for pairing as you describe, but rather a
group of inputs that all share some common-ground. In my case I use them
to contain groups of required versus non-required inputs as well as the
type of information sought (contact info, etc.).
Sorry to bring this up
On 30 May 2007, at 14:16:11, John Faulds wrote:
Sorry to bring this up again but I've been thinking a bit more
about this: a fieldset should be used to group related form
controls and each fieldset should have a legend, but what if you
have a form control that's not really related to
I had a very similar issue with my feedback form.
Eventualy I split it into three fieldsets: your feedback, your details,
and a privacy statement.
http://www.griffith.edu.au/cgi-bin/feedbackform.cgi
- Kane
[EMAIL PROTECTED] wrote on 30/05/2007 11:16:11 PM:
It probably shouldn't be used
On Wed, 30 May 2007 23:16:11 +1000, John Faulds wrote:
what if you have a form
control that's not really related to anything else? Do you put it in
a fieldset by itself? Then what do you do about the legend when in a
lot of cases it'll simply be duplicating what's in the label?
For
On 5/27/07, Katrina [EMAIL PROTECTED] wrote:
In some sense, the label and input are thematically related.
Interesting idea, and in a way I agree. However I still think, in
combination with fieldsets and appropriate form elements, that a ul is
an appropriate way to mark up form controls. For
Mike at Green-Beast.com wrote:
Katrina wrote:
I note that in Mike's example, he using
a br / in order to achieve a block-level
style visual. Surely that should be avoidable?
http://green-beast.com/gbcf/gbcf_form.php
Certainly it would be avoidable using label { display : block; } but I
Nick Fitzsimons wrote:
While I agree that use of lists, tables or definition lists is mere
abuse, a fieldset is for grouping thematically related controls and
labels:
http://www.w3.org/TR/html4/interact/forms.html#edef-FIELDSET
So a hypothetical (semantic!) form could/should look something
On 27/05/2007, at 7:58 PM, Katrina wrote:
My point being that fieldset could be used to wrap label and input
pairs?
No. fieldset is to group related controls, not labels and controls.
kind regards
Terrence Wood.
***
List
Terrence Wood wrote:
On 27/05/2007, at 7:58 PM, Katrina wrote:
My point being that fieldset could be used to wrap label and input pairs?
No. fieldset is to group related controls, not labels and controls.
From http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.10
The FIELDSET
The label associates the label-text with the input, i.e. their
realtionship is already firmly established and needs no other
confirmation.
The fieldset is to group together multiple inputs: to add stucture in long
complex forms.
Moreover, if multiple inputs are expected (since this is what the
and not given its own since it's
grouped in with the form itself (a whole-form control) so to speak.
Cheers.
Mike Cherim
- Original Message -
From: Katrina [EMAIL PROTECTED]
To: wsg@webstandardsgroup.org
Sent: Sunday, May 27, 2007 3:58 AM
Subject: Re: [WSG] dl v table for form layout
Hi,
I don't quite see how you get your possible interpretation.
To summarise what it says:
1. for implicit association, enclose the form control in the label.
2. if you use implicit association (i.e. enclose the form control in the
label) it can only contain one control element.
It is
Hi Stuart,
Stuart Foulstone schreef:
I don't quite see how you get your possible interpretation.
To summarise what it says:
1. for implicit association, enclose the form control in the label.
2. if you use implicit association (i.e. enclose the form control in the
label) it can only contain
On Behalf Of Sander Aarts
... English is not my native language adds to my misinterpretation though.
Welcome to the club ;)
---
Regards,
Thierry | www.TJKDesign.com
***
List Guidelines:
Karl Lurman wrote:
How am I going to highlight the label input
pair without a container div? A fieldset?
Hello Karl,
I will add a div or paragraph to a form if needed. A division in the form
normally marked by color or a border is okay (as that slight meaning will be
carried by the Div in
pFields marked with * (asterisk) are required./p
Yep, instructions are definitely the way to go with the 'required'. we
might even look at making instructions for the required as a
definition list (hahaha just for fun)
form
dl
dt*/dt
ddFields whose labels contain an asterisk require a
On 25/05/07, Karl Lurman [EMAIL PROTECTED] wrote:
Im not the biggest fan of a label 'around' an input. To me, it doesn't
make a lot of sense, but I know that its standard practice with a lot
of people. I understand that it gives us another means of
encapsulating our label/field pair, but again I
I think some people dont understand Forms to well.
Without a label how will you label what your inputs are to be used for?
On 5/25/07, Stephen Kelly [EMAIL PROTECTED] wrote:
On 25/05/07, Karl Lurman [EMAIL PROTECTED] wrote:
Im not the biggest fan of a label 'around' an input. To me, it
Good morning :-)
I should have expanded my example a little more since I do use the for
attribute in labels, even when directly (implicitly?) associated:
form
fieldset
legendSend us your contact info/legend
pFields marked with * (asterisk) are required./p
label
Hi,
The for attribute should NOT be used when the label tag encloses the
label text.
On Fri, May 25, 2007 2:45 pm, Mike at Green-Beast.com wrote:
Good morning :-)
I should have expanded my example a little more since I do use the for
attribute in labels, even when directly (implicitly?)
On 25 May 2007, at 15:40, Stuart Foulstone wrote:
The for attribute should NOT be used when the label tag encloses the
label text.
Why not?
The specification doesn't appear to forbid it. Does it cause problems
in any user agents?
--
David Dorward
http://dorward.me.uk/
Stuart Foulstone wrote:
Hi,
The for attribute should NOT be used when the label tag encloses the
label text.
What are the dangers?
Regards,
Barney
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
David Dorward wrote:
Why not?
In response to... Stuart Foulstone wrote:
The for attribute should NOT be used when
the label tag encloses the label text.
My question exactly. I can't see that it is in any way harmful.
Cheers.
Mike Cherim
Barney Carroll wrote:
Stuart Foulstone wrote:
Hi,
The for attribute should NOT be used when the label tag encloses the
label text.
What are the dangers?
Regards,
Barney
Hello,
Its probably not a danger per se for most people but if you ever use a
cms that writes out form fields
Sorry, I meant to say, when the label teg encloses the label text AND the
input.
However, on checking W3C acessibility guidelines, it appears I may be
wrong about this.
(http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms-labels )
But, in the W3C recomendations for form labels it gives
]
Sent: Friday, May 25, 2007 2:48 PM
Subject: Re: [WSG] dl v table for form layout
On 24 May 2007, at 22:01:52, Mike at Green-Beast.com wrote:
See a real (somewhat styled) example: http://green-beast.com/gbcf/
(Demo
Form)
Mike,
I've taken the liberty of accessing your demo page using Jaws 8
Stuart Foulstone schreef:
But, in the W3C recomendations for form labels it gives implicit/explicit
labels as two distinct methods (one not using the for).
(http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.9.1 )
On that page it also says To associate a label with another control
Medyk,
You clearly dont understand forms, i can tell by the way you said you dont
understand what a fieldset is for.
Before i go any further, ill say again, follow the standards set. In my
article i quoted a quote from W3C that says, tables should not be used for
layout purposes but for tabular
You put:
Using form doesn't exclude use of list or table
To me thats telling me 'oh yes you can use a table or list' The only time i
said
a table is fine forms is if its a dynamic spreadsheet or a calander.
Ive demonstrated the use of forms without tables, and when i get time i will
create an
Jamie Collins wrote:
You put:
Using form doesn't exclude use of list or table
To me thats telling me 'oh yes you can use a table or list' The only
time i said
a table is fine forms is if its a dynamic spreadsheet or a calander.
Of course you can use table or list within form as this is what
Bottom line is Yes you Can use a Table if its appropriate, but you cannot
use a table
to layout your form.
As for lists, if its a list, the yes you can contain your form in a list.
We are talking about people abusing this and using lists and tables when not
needed.
On 5/24/07, Mariusz Nowak
Mariusz Nowak wrote:
And other way - where it is written in
specs that forms cannot contain tabular
data? I would never use tables for anything
else as for tabular data.. and it may
happen that form constitutes tabular data.
In such case I think we should use table
element to structure
Mike at Green-Beast.com wrote:
I think may be some confusion, Mariusz, because so far this discussion has
been about putting a form in a separate structure such as a table or dl to
contain or organize the form, not about putting a structure (like a table)
in a form. It's the latter you seem to
Mike at Green-Beast.com wrote:
For a definition list I could only really come up with three examples:
1) A glossary
2) FAQs
3) An interview transcript (when combined with blockquotes).
(All have a sort of QA thing goin' on.)
Does a form not have a sort of QA going on then!? I think you gave
Sander Aarts wrote:
Does a form not have a sort of QA going on then!?
Hello Sander,
If one tries hard enough, it seems anything can be considered a list of
sorts.
For example: A web page is a list of headings and content paragraphs, but we
wouldn't use a list to layout an entire web page,
Hello Mike,
Mike at Green-Beast.com schreef:
If one tries hard enough, it seems anything can be considered a list of
sorts.
That might be true, but I hope you will agree that it's easier to
consider a form being a list than a whole page.
A form is a list of controls and their related
I found these awhile back and was hoping to roll something similar
back into my css framework:
http://dnevnikeklektika.com/uni-form/
I know that forms are a b*tch to get looking even slightly good on all
browsers, but frankly, tables are an old dog and dl's are just younger
dogs. Field sets are
@webstandardsgroup.org
To
wsg@webstandardsgroup.org
cc
Subject
Re: [WSG] dl v table for form layout
Hello Mike,
Mike at Green-Beast.com schreef:
If one tries hard enough, it seems anything can be considered a list of
sorts.
That might be true, but I hope you will agree that it's easier to consider
a form
Hello Mariusz,
substituting dt with label or
dd with input doesn't seem
right to me at all... you can't just swap
them
I'm not really saying to swap them. I'm not pro-list or -table for form
layout, I was just trying to pair the elements to show that form elements
can serve in the same way
The point of my comments, though, was what I have been saying all along. You
simply don't need additional structure to put a form on a page. All you need
are the form-related elements: Form, fieldset, legend, label, input
(varied), and textarea. Using these elements and CSS you can lay out a form
Only have safe sex with wombats they are promiscious and many have a
sexual transmitted disease clymidia.
You guys are sick today eating roots and leaves, off topic.
Tim
On 23/05/2007, at 8:37 AM, John Faulds wrote:
gay wombat sex is rightly prohibited in Australia
Mabye Australia doesn't
Ive put together a quick article regarding forms. Ive had to place it on
some random server at work for now.
http://www.viberate.co.uk/ws/styling-a-form/styling-a-form.html
Theres 3 pages in total, the last page goes through 3 methods of creating a
form with and without a DL. Its been created
Jamie Collins wrote:
http://www.viberate.co.uk/ws/styling-a-form/styling-a-form.html
http://www.viberate.co.uk/ws/styling-a-form/styling-a-form.html
I must say that I disagree with some points stated in these article,
shared also with stronger tone in previous posts (that is Tables for
forms =
@webstandardsgroup.org
To
wsg@webstandardsgroup.org cc
Subject
[WSG] dl v table for form layout
Hi all,
I am having a discussion with colleagues here at work (won't mention our
site as it stinks) about the best way forward for form layouts.
I have one person saying he will continue to use tables till
PROTECTED] On
Behalf Of Jamie Collins
Sent: 22 May 2007 08:46
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] dl v table for form layout
Kane, exactly what i was going to say.
And in no way, and i mean by no way should you use tables for forms, unless
its ment
for tabular date, the only way i can ever
respond to
wsg@webstandardsgroup.org
To
wsg@webstandardsgroup.org cc
Subject
[WSG] dl v table for form layout
Hi all,
I am having a discussion with colleagues here at work (won't mention our
site as it stinks) about the best way forward for form layouts.
I have one person saying
: 22 May 2007 18:10
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] dl v table for form layout
A table is for Tabular Date, a quote from the W3C Documentation:
Tables should not be used purely as a means to layout document content as
this may present problems when rendering to non-visual media
On Tue, 22 May 2007 14:28:02 +1000, Joshua Street wrote:
My vote generally goes in for tables. Use th cells appropriately and there's
a clear
relationship there. Definition lists are semantically on par, but often
harder to
implement/require effort to make them *look like a table* (which is
your page you need to take a
strong look at what you're doing.
Steve
--
*From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On
Behalf Of *Jamie Collins
*Sent:* 22 May 2007 18:10
*To:* wsg@webstandardsgroup.org
*Subject:* Re: [WSG] dl v table for form layout
A table
Steve Green wrote:
No, a form is not a list of form controls any more than a chapter of a
book is a list of paragraphs or a paragraph is a list of words. A
collection of form controls is a fieldset.
Definition lists are the new tables. People are just falling over
themselves trying to abuse
Tables for forms = NO
DL for forms = No
Its that simple .
On 5/22/07, Patrick H. Lauke [EMAIL PROTECTED] wrote:
Steve Green wrote:
No, a form is not a list of form controls any more than a chapter of a
book is a list of paragraphs or a paragraph is a list of words. A
collection of form
Steve Green wrote:
No, a form is not a list of form controls [...]
I agree. A form is not a list, nor is it tabular data. I know this was
originally a demonstration to show the lesser of two evils, but evil is evil
so less wrong still isn't right. What I don't understand is why there is
this
On Behalf Of Steve Green
Definition lists are the new tables. People are just falling over
themselves trying to abuse them in all kinds of inappropriate ways. To
paraphrase the previous message, a definition list is for lists of
definitions
I don't agree with this definition. For example, the
On 22 May 2007, at 20:40:41, Mike at Green-Beast.com wrote:
Steve Green wrote:
No, a form is not a list of form controls [...]
I agree. A form is not a list, nor is it tabular data. I know this was
originally a demonstration to show the lesser of two evils, but
evil is evil
so less wrong
On 23 May 2007, at 7:36 AM, John Faulds wrote:
I doubt there's any laws in Australia that prohibit me having sex with
a wombat - doesn't mean it's something that's OK to do though
Damn.
___
omnivision. websight.
http://www.omnivision.com.au/
Mabye Australia doesn't come across as being that progressive in other
parts of the world, but the only state where gay wombat sex would be
prohibited is Tasmania. ;)
/* Admin */
Folks,
I know it's early in Australia and most of us probably haven't had our
coffee yet, but please
Personally I think that form elements lend themselves to practically all
the semantic meaning you need. Labels and input elements are either
implicity or explicity linked (ie either labellabelnameinput
...//label or label for=myinput/labelinput id=myinput.../),
and then you have fieldsets as
/css/glass.css
- Kane
Breton Slivka [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
23/05/2007 08:14 AM
Please respond to
wsg@webstandardsgroup.org
To
wsg@webstandardsgroup.org
cc
Subject
Re: [WSG] dl v table for form layout
So when is this great festival of telling people what
there is also the issue of how it will display on a minimal browser not only
without table rendering but also without css rendering ...
It should still be possible to use the form.
.. at the end of the day I think that it what it comes down to - making it
work on any browser with any type of
Hi all,
I am having a discussion with colleagues here at work (won't mention our
site as it stinks) about the best way forward for form layouts.
I have one person saying he will continue to use tables till otherwise
informed.
I have another who uses none of the above, which you can imaging is
My vote generally goes in for tables. Use th cells appropriately and
there's a clear relationship there. Definition lists are semantically
on par, but often harder to implement/require effort to make them
*look like a table* (which is what people expect when filling out
forms, on paper or on the
Using the nbsp; for layout is the worst of the ideas and should not be
considered for the final form.
Tables, while frowned upon / argued over / etc, are still the most
reliable way to layout COMPLEX forms, for simple forms you don't need
tables at all. Do a search for accessible CSS form
with their controls.
- Kane
Benedict Wyss [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
22/05/2007 02:15 PM
Please respond to
wsg@webstandardsgroup.org
To
wsg@webstandardsgroup.org
cc
Subject
[WSG] dl v table for form layout
Hi all,
I am having a discussion with colleagues here
65 matches
Mail list logo