For ease of grouping and alignment I have always laid out contact forms in a table. Now, in HTML 5 and with inline design, I am being steered away from ever using tables.
Are tables still okay for forms or, if not, what’s the recommended way to lay out a form with various elements in box model?
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
I am being steered away from ever using tables.
Certainly not for these sorts of elements.
What you are being steered away from is using tables as a page layout method. Which Express uses as default and what you get if you turn the CSS Layout button off in Pro.
David
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
Okay. So no problem having a table inside a box inside a box etc.?
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
no problem having a table inside a box inside a box
Nope
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
I of course will disagree on principle - tables are fine for table data and
forms are fine for form data, but they’re not swappable. In the case of
using a table to structure a form, said table IS a layout table.
But since I am not in a preaching mood, I will just grumble lowly and let
you carry on in the hope that someday - after you’ve mastered html5 and
inline design stuff - that you will notice how woefully incomplete Freeway
Pro treats both data tables and forms, and how this omission has influenced
many a FWP web designer to cut corners and lower standards. Maybe then you
will find another, better way to create these elements.
Ernie Simpson
no problem having a table inside a box inside a box
Nope
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
Taking what Ernie said even further: one of the practical issues with using a table to hold/layout/position a form is the bloated markup required to do so. Tables require a lot of code with little semantic payoff which is not what you want with a form. Forms on the other hand can be (when built correctly) a semantic powerhouse which, among other things, can be especially useful for people using screen readers (think accessibility). All that table markup messes with what should be a coherent form structure.
Is it easier to use a table? Sure, it can be. Is it the right tool for the job? Uh, no. As Ernie suggested, easier doesn’t mean better.
Todd
I of course will disagree on principle - tables are fine for table data and
forms are fine for form data, but they’re not swappable. In the case of
using a table to structure a form, said table IS a layout table.no problem having a table inside a box inside a box
Nope
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
I’ve seen a number of different recommendations for form layout over the years. Some suggest an ordered list, others use the label as a container, or set the label to display:block to create a visual separation. If have long been a fan of styling the label like this:
label {
width: 120px;
float: left;
text-align: right;
margin-right: 8px;
}
This gets you a nice aligned label/field construction, but it still requires that you wrap each label/field pair in a container element, so you can clear the float.
How about you? What’s your preferred format for a form?
Walter
On Nov 16, 2013, at 1:06 PM, Todd wrote:
Taking what Ernie said even further: one of the practical issues with using a table to hold/layout/position a form is the bloated markup required to do so. Tables require a lot of code with little semantic payoff which is not what you want with a form. Forms on the other hand can be (when built correctly) a semantic powerhouse which, among other things, can be especially useful for people using screen readers (think accessibility). All that table markup messes with what should be a coherent form structure.
Is it easier to use a table? Sure, it can be. Is it the right tool for the job? Uh, no. As Ernie suggested, easier doesn’t mean better.
Todd
http://xiiro.comI of course will disagree on principle - tables are fine for table data and
forms are fine for form data, but they’re not swappable. In the case of
using a table to structure a form, said table IS a layout table.no problem having a table inside a box inside a box
Nope
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
For ease of grouping and alignment I have always laid out contact forms in a table.
Which is why I said yes - not because the semantics are right or wrong.
We can all argue until we are blue in the face about what is ‘Best Practise’ but when we are talking about ‘ease of use/construction’ then what is the problem?
Lets face it the average FW user is here because of ‘ease of use’.
D
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
Let me ask my question again. Those of you who have a preference in truly semantic form layout, what’s your flavor? Actions can turn any regular construction into any other regular construction. (Given a reasonably “normal” Freeway layout, we can extract the fields and generate the necessary labels and semantic structure to make a form really sit up and bark.)
I know how I like to lay things out here, but if I made an Action with that structure, you’d all have to follow my lead. I am interested in learning other ways to scale this fish.
Walter
On Nov 16, 2013, at 2:57 PM, DeltaDave wrote:
For ease of grouping and alignment I have always laid out contact forms in a table.
Which is why I said yes - not because the semantics are right or wrong.
We can all argue until we are blue in the face about what is ‘Best Practise’ but when we are talking about ‘ease of use/construction’ then what is the problem?
Lets face it the average FW user is here because of ‘ease of use’.
D
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
I agree, that’s very true.
But I also felt the original poster’s statement/question of "no problem having a table inside a box inside a box” warranted an answer that included both sides, because yes, there really are legitimate problems with that approach. What’s the harm in providing him with both options and letting him make his own informed decision rather than jumping on the path of least resistance by default? He did ask, after all. People will always do what they want but at least we can help increase awareness of potential pitfalls for those who may not be aware of them. I’m trying to raise the bar of understanding, not lower it.
Todd
Lets face it the average FW user is here because of ‘ease of use’.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
An ordered list? Interesting. I never tried that one.
I don’t have a set method but usually I float the label, though I have sometimes used display: block. When necessary I like to give my forms the full semantic treatment with fieldsets, legends and labels (of course). But at a minimum I normally use fieldsets and labels.
Todd
I’ve seen a number of different recommendations for form layout over the years. Some suggest an ordered list, others use the label as a container, or set the label to display:block to create a visual separation. If have long been a fan of styling the label like this:
label {
width: 120px;
float: left;
text-align: right;
margin-right: 8px;
}This gets you a nice aligned label/field construction, but it still requires that you wrap each label/field pair in a container element, so you can clear the float.
How about you? What’s your preferred format for a form?
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
Todd - I agree with giving both sides of the story but the original question was really about whether or not a table inserted inline was going to cause construction issues. Not semantic ones.
Walter - I am leaning toward the floated fixed width label method.
D
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
Thanks D: You’re right about the original question, and your original answer remains the most useful. This is principally because it’s the only one I understand, unfortunately 
—or perhaps (as you also correctly identified) I’m one of those WYSIWYG ‘ease of use’ designers.
However, I would be interested in a basic how-to for the floated fixed width label method.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
At 14:57 -0500 16/11/13, DeltaDave wrote:
For ease of grouping and alignment I have always laid out contact
forms in a table.Which is why I said yes - not because the semantics are right or wrong.
We can all argue until we are blue in the face about what is ‘Best
Practise’ but when we are talking about ‘ease of use/construction’
then what is the problem?Lets face it the average FW user is here because of ‘ease of use’.
And do we want the web to be like an art gallery with some pictures
hung with the most artistic side facing the wall? Surely the ‘art’
of a web page should be the side that people see.
If a screen reader makes a better job of interpreting a complex CSS
form page than a simple table one the the fault lies with the
pedantic designer of the screen reader rather than the page designer.
You can’t get much more logical than a table with form fields and
titles in it.
David
–
David Ledger - Freelance Unix Sysadmin in the UK.
email@hidden
www.ivdcs.co.uk
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
Most screen readers are clumsy, expensive, and illogical brutes – I have no love for them at all. But tables are a crude hack to provide semantic structure to a form which might otherwise only make sense to a sighted visitor. And a CSS layout is simpler and less burdened with non-informational markup than a table structure. Consider this comparison, both of which render the same (given a style rule for the label as I posted earlier in this thread):
<ol class="form">
<li>
<label for="name">Name</label>
<input type="text" name="name" id="name"/>
</li>
<li>
<label for="email">E-mail</label>
<input type="email" name="email" id="email"/>
</li>
</ol>
Contrast that with this (and I’m adding a label formatting classname, but this could easily be much more code if you inlined the text-align: right style to each of the “label” cells):
<table border="0" cellspacing="5" cellpadding="5">
<tr>
<td class="label">
<p>Name</p>
</td>
<td>
<input type="text" name="name" id="name"/>
</td>
</tr>
<tr>
<td class="label">
<p>E-mail</p>
</td>
<td>
<input type="email" name="email" id="email"/>
</td>
</tr>
</table>
So here you have a whole lot more “furniture” surrounding the only parts of the form that really matter – the labels and their fields. And in the latter, you don’t have a true label, but rather a piece of text that only relates to the field in the context of the table – the relationship has to be inferred, rather than being made explicit through the for= relationship.
Worse than this would be if you didn’t use a table at all. Because Freeway drives its output order by stacking alone, it is perfectly possible to end up with the label and the field miles apart in the source, with nothing but the for= relationship to bind them together – and that’s only if you figure out how to create a label in Freeway 6 (not the most intuitive placement of a control I have ever seen). If you were the traditional “visual only” designer, you might be done when it looks right, yet be rejecting the needs of a whole chunk of your audience.
Semantics are not just for the eggheads, they really do make more sense in a lot of different contexts.
Walter
On Nov 17, 2013, at 9:44 AM, David Ledger wrote:
If a screen reader makes a better job of interpreting a complex CSS form page than a simple table one the the fault lies with the pedantic designer of the screen reader rather than the page designer. You can’t get much more logical than a table with form fields and titles in it.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
As I have been rightly accused on occasion of being overly acerbic, I will
reply by just saying that if Freeway Pro made it as easy to produce
semantically nice forms and data tables as it does to birth their current
grotesque counterparts, then we wouldn’t be writing stupid shit. If all we
care about is easy, then why not at least easy and usefully acceptable?
That would make everyone happy (except for the programmers whom I expect
would complain how un-easy the expectation may be).
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options