I am working on a pure data entry screen that contains 30+ input
fields. One of the requirements is that the page needs to be designed
so that everything can fit on one screen with no scrolling.
In the past I would have used tables to control field placement, this
tightly. I have looked around the Web for examples of CSS usage to
layout forms, but have not been able to find anything with near the
volume of fields that need to be placed.
Another complication is that fields are grouped in different
containers, where each container can be toggled between view/edit mode
allowing for the data to be updated using AJAX.
Is absolute positioning the best way to go to get the control I need?
Does anyone know of a good example I can take a look at?
Dan, Let me be the first one to say, what others are probably going to
say ,
this is the Rails list , not a css group
That said take a look at this plugin http://agilewebdevelopment.com/plugins/cssformbuilder . Personally I
haven’t
used it but it looks like something that might help you.
The other place to go is http://css-discuss.incutio.com/
Aside from the mail list with plenty of knowledgable people there are
other
resources there.
Last but not least, maybe absolute is the way to go and maybe it isn’t.
It
could be a whole series of floats. Seriously
I am working on a pure data entry screen that contains 30+
input fields. One of the requirements is that the page needs
to be designed so that everything can fit on one screen with
no scrolling.
You probably didn’t gather the requirements but this doesn’t seem like a
CSS or presentation issue – this seems more like a usability and
information architecture issue, no? I mean, thirty form fields and you
have to make it all fit on a moving target like screen resolution?
Without knowing more, it sounds like maybe the information and data
input flow could be made simpler or a little more user-friendly?
In the past I would have used tables to control field
placement, this tightly. I have looked around the Web for
examples of CSS usage to layout forms, but have not been able
to find anything with near the volume of fields that need to
be placed.
Nothing wrong with using tables in this case. As long as it’s labeled
correctly and makes semantic sense, why not use a table?
Another complication is that fields are grouped in different
containers, where each container can be toggled between
view/edit mode allowing for the data to be updated using AJAX.
Hide and show fields via CSS and AJAX sounds good but again, I might
push to simplify things a little first.
It doesn’t make semantic sense. Tables are supposed to be used to
display tabular data, not for controlling placement of other elements.
I agree that tables are for displaying tabular data but what gives you
the impression that form fields are not allowed? From the HTML 4.01
spec:
"
11.1 Introduction to Tables
The HTML table model allows authors to arrange data – text,
preformatted text, images, links, forms, form fields, other tables, etc.
– into rows and columns of cells.
"
Reference: Tables in HTML documents
Nothing wrong with using tables in this case. As long as it’s labeled
correctly and makes semantic sense, why not use a table?
It doesn’t make semantic sense. Tables are supposed to be used to
display
tabular data, not for controlling placement of other elements. But, as
someone already said, this is hardly the place to argue the point.
If you want to make a (mostly) semantically sound cross-browser
table-less
form…
You might try using labels, inputs, and br’s. (The br is why I consider
it
-mostly- not completely semantically sound) In your CSS, display the
label
and input as blocks and float them left. Set a fixed width on the
label.
Then follow them with a br, which has clear:left applied to it in your
css.
I was going to write a quick summary of my thoughts on why you
shouldn’t use tables for forms, but then remembered this link
Essentially, use a table if you wish, but you will find it easier to
change the look at a later date (without touching markup) using more
semantic means…
I agree with the example, but it also illustrates my issue. I am
working on a pure data entry screen for clerks that key hundreds of
applications a day. The form contains a slew (30+) of fields. Data
entry clerks want absolutely no scrolling, so all of the labels and
fields must be on one screen.
I have found a ton of blogs/articles documenting the flexibility of
using CSS to layout the form elements, but they only have a few fields
on their examples and there is always a ton of whitespace.
It is probably due to my limited CSS skills, but I have found it very
difficult to get a tight layout with the number of fields I am working
with. Even things as fundamental as having more than one label on one
line without breaking has proven difficult. I would certainly like to
use CSS and not tables, but I just haven’t found much to work off of.
I forgot to mention that the 4.01 isn’t specific to XHTML, but rather
HTML, and was last updated in 1997 so I wouldn’t put to much emphasis
on it unless you have a specific reason.
You can always use absolute positioning to lay out all controls where
you
want them. Just beware of text resize (font increasing / decreasing) or
window resize.
It goes like this:
on parent element (div box) set “position: relative”
on every label / input / select / textarea :
set “position: absolute”, explicit width and height and proper “top” and
“left” offsets.
Absolute positioning will be relative to parent element (with position:
relative).
I haven’t had coffee yet, so excuse me if this is just silly or crazy.
In order to save space and fit all 30 fields on one page, how about the
following:
Text can be bunched a lot closer to each other than form fields, and
still be readily distinguishable. Now, if you take the idea of
pagination links, normally you can see say 3 links before and after the
current active link. How about having fields, that are 3 before/after
the current active field as fields, and having the rest of the fields,
replaced using ajax, with smaller text (“label” and “value”) so you will
always have 7 fields on the page, but you will have an increasing number
of completed “text”-fields above the active fields and a deminishing
number of "text"fields below the active fields.
Example
label — value as text
label — value as text
label — value as text
label — value as text
label — field for entry
label — field for entry
label — field for entry
label — field for entry
label — value still empty
label — value still empty
label — value still empty
label — value still empty
label — value still empty
After the next data entry, there will be 5 text-lines, above the active
fields, and only 4 below them. Similar to moving a magnifying glass over
the data…
It is probably due to my limited CSS skills, but I have found it very
difficult to get a tight layout with the number of fields I am
working with. Even things as fundamental as having more than one
label on one line without breaking has proven difficult. I would
certainly like to use CSS and not tables, but I just haven’t found
much to work off of.
I’m all for using CSS where it fits. In your case it does not. To me CSS
look like its authors were only concerned with the layout of pretty
pages and didn’t take into account what it takes to layout forms. Why
are there not layout managers?
Tables are actually what comes closest. The beauty is that they even
adapt well to font sizes changed by the user and user stylesheets in
general. Their only drawback is that a form is not strictly tabular
data, presumably resulting in “non-semantic” markup. Big deal,
considering the alternative. You may be able to get an effect similar
to using tables with the help of positioning voodoo, but my guess is
that it won’t look the same on all browsers, will only work at a
specific font size and will utterly break in the presence of user
stylesheets. I challenge anyone to prove me wrong with a robust,
good-looking multi-column form layout using only CSS as implemented in all latest-generation browsers.
30 fields… That’s a fair few. I would approach this by making good
use of the fieldset tag to seperate out the fields into groups, i.e.
personal details, work details, likes/dislikes, etc… This would make
the info on the page more readable and semantically useful. You could
also then give these fieldsets different IDs and then use javascript
to hide and show them when necessary.
Use Fieldset. I totally forgot about it but I’m at a conference this
week
where I saw a great presentation about fieldset. It can be quite simple
and
is a great way to make semantic markup.
First name
Last name
…
You can use to do line breaks or you can make the labels block
elenments and float the input fields to the left… or right, or
whatever
works for you.
Not my idea but it makes a lot of sense and I’ll begin using this
technique
soon.
I’ve been experimenting with high-volume field-entry mechanisms in CSS
recently, so I can develop my own standardised admin generation tools.
I came up with a simple system (I like simple, it’s more likely to work
and easier to update.)
1: Use an unordered list for each name/value pair.
2: Enter each list-item as Fieldname
3: Fix the width of ‘label’ and ‘input’ elements.
4: ‘float: left’ your list elements.
5: if a list element has a class of ‘RowStart’, make it ‘clear: left’
You now have complete control over the sizes of elements as a whole.
You can create arbirary length rows of inputs to save space, and
they’ll gracefully pop underneath eachother if you scale down the
window. With tables they’ll squash up until unreadable, or go off the
edge of the page.
You can even use ‘em’ units for element sizes instead of pixels, to
ensure you don’t suffer from page text resizing.
For large fieldnames you could create and class names
which make double-sized or triple-sized fields.
I only came up with it all over the weekend so I haven’t destructively
tested it yet, but feel free to ask if you want some exmple code. It
works on Mac and PC so far.
Also, have a look at the Ajax Scaffold Generator project, which uses a
similar technique and has been designed by a UI pro, so is probably
quite scalable and browser-compliant.
As for everything being on the same page, I say that’s less important
for speedy entry than making sure your tab ordering is sensible. But
that’s not the spec.
(Nope, still no excuse to use tables for non-tabular data. Any blind
clerks would be screwed. It’s just lazy.)
I came up with a simple system (I like simple, it’s more likely to
work and easier to update.)
1: Use an unordered list for each name/value pair.
2: Enter each list-item as Fieldname
3: Fix the width of ‘label’ and ‘input’ elements.
4: ‘float: left’ your list elements.
5: if a list element has a class of ‘RowStart’, make it ‘clear: left’
That may indeed work when all input elements are more or less the same
size. How do you handle text areas and multi-selects that are so large
that they need to span multiple rows/columns?
You now have complete control over the sizes of elements as a whole.
You can create arbirary length rows of inputs to save space, and
they’ll gracefully pop underneath eachother if you scale down the
window. With tables they’ll squash up until unreadable, or go off the
edge of the page.
A liquid layout is great for a page presenting content. It’s less great
for forms. For forms I’d require that elements retain their relative
positions, i.e., that an element always has the same neighbors – left,
right, top, bottom.
A liquid layout is great for a page presenting content. It’s less great
for forms. For forms I’d require that elements retain their relative
positions, i.e., that an element always has the same neighbors – left,
right, top, bottom.
You make some good points. I usually use fixed layouts for content
presentation - liquid layouts can easily look a bit geeky for general
consumption. However, liquid layouts appear to make more sense for
multiple field entry systems. As you can’t rely on the user’s screen
being the same size as yours (unless you’re deploying to a rigidly
specced internal set-up of some kind, which you could be with a banking
system), building in some flexibility where screen width is concerned
is usually a good move. I like the idea of offering more functionality
to people who can use it and degrading gracefully for people who can’t.
On the other hand, if your problem is that your fields DON’T MAKE SENSE
unless aligned in a particular position both vertically and
horizontally relative to the other fields, then you have a case for
calling it tabular data. Certainly, in that case other forms of CSS
styling will fall over… Tables are already designed to do just that.
And can also be programatically created and CSS styled.
Just make sure that you’re labelling each field properly with a tag, I suppose.
4: ‘float: left’ your list elements.
5: if a list element has a class of ‘RowStart’, make it ‘clear: left’
Another tool I’ve used for form layout, which I still use where
appropriate are definition lists:
for the label,
for the
input(s). (You can have multiple
elements for each
.)
Drawback: No way to group these items together in the
, it’s a flat
structure. However, I think it’s more lightweight and semantic than
.
But, if this is intended just for horizontal layout I don’t see how
making lists is semantically better than plainly saying “this is a
row”. Using unordered list is possibly less semantic than just using
tables, or groups of tables & fieldsets.
After all, forms can be semantically considered tabular data: in the
simplest case, the form’s parts can be thought of as name (label) and
value (input) pairs, which might otherwise be considered columns in a
spreadsheet or otherwise…
CSS doesn’t solve the problem of aligning several items into columns
based on the widest element. If you have to fix the width of the label
to a static value (em or px), you have to figure out what is your
widest label to fix to. Too fragile and horrible to maintain. You will
spend much more time reworking it when a longer label shows up than if
you had used tables and allowed the matrix to scale as needed.
If you want things to line up in columns, use the only tool that’s
available in HTML for automatically associating elements into columns:
. You can even identify and classify your table cells, and use
table header
where appropriate to make it more semantic and give
you styling hooks. Don't throw tables away completely: they're not the
perfect solution, but they're not all bad and sometimes they're
perfectly appropriate.
I definitely would not recommend one massive Web 1.0 compliant table
with row/colspans etc… Try to keep it lightweight and break it down
into chunks as appropriate.
On the other hand, if your problem is that your fields DON’T MAKE
SENSE unless aligned in a particular position both vertically and
horizontally relative to the other fields, then you have a case for
calling it tabular data.
That’s actually not what I was thinking about. Rather, I have in mind a
setting where users are spending a significant percentage of their
working time in an applications. These people very quickly get
acquainted with where input elements are spatially located and it would
hinder their work to send them looking around after they have changed
the window or font size.
For casual users, on the other, liquid, scrolling and otherwise “pretty”
layouts may well be more appropriate.
