Hello, 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? Thanks, Dan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
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 Hope this helps. Stuart On 10/18/06, Dan Munk <danmunk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > Hello, > > 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? > > Thanks, > Dan > > > > >-- http://en.wikipedia.org/wiki/Dark_ambient --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
> 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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
> 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. Tyler On 10/18/06, Dean Matsueda <dmatsueda-1n2u0cAa2q8@public.gmane.org> wrote:> > > > 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. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
> It doesn''t make semantic sense. Tables are supposed to be used todisplay 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: www.w3.org/TR/html401/struct/tables.html --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
You know... I never read that. Thanks for bringing it my attention. On 10/19/06, Dean Matsueda <dmatsueda-1n2u0cAa2q8@public.gmane.org> wrote:> > > > 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: www.w3.org/TR/html401/struct/tables.html > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Hi Dan, 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 http://clagnut.com/blog/241/ 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... Have a read, well worth it. Mark. On 18/10/06, Dan Munk <danmunk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Hello, > > 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? > > Thanks, > Dan > > > > >-- www.markpanay.com - Jargon Free Development www.menscookeryclub.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
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. On 20/10/06, Mark Panay <markpanay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hi Dan, > > 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 > http://clagnut.com/blog/241/ > > 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... > > Have a read, well worth it. > > Mark. > > On 18/10/06, Dan Munk <danmunk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > Hello, > > > > 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? > > > > Thanks, > > Dan > > > > > > > > > > > > > -- > www.markpanay.com - Jargon Free Development > www.menscookeryclub.com >-- www.markpanay.com - Jargon Free Development www.menscookeryclub.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Hi Mark, 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. Thanks and sorry for the off-topic thread, Dan Mark Panay wrote:> Hi Dan, > > 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 > http://clagnut.com/blog/241/ > > 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... > > Have a read, well worth it. > > Mark. > > On 18/10/06, Dan Munk <danmunk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > Hello, > > > > 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? > > > > Thanks, > > Dan > > > > > > > > > > > > -- > www.markpanay.com - Jargon Free Development > www.menscookeryclub.com--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
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: 1. on parent element (div box) set "position: relative" 2. 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). On 10/24/06, Dan Munk <danmunk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > Hi Mark, > > 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. > > Thanks and sorry for the off-topic thread, > Dan > > > Mark Panay wrote: > > Hi Dan, > > > > 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 > > http://clagnut.com/blog/241/ > > > > 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... > > > > Have a read, well worth it. > > > > Mark. > > > > On 18/10/06, Dan Munk <danmunk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > Hello, > > > > > > 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? > > > > > > Thanks, > > > Dan > > > > > > > > > > > > > > > > > > > -- > > www.markpanay.com - Jargon Free Development > > www.menscookeryclub.com > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Hi Dan
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....
I think I am going to grab that coffee :)
Ivor
Dan Munk wrote:> Hi Mark,
>
> 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.
>
> Thanks and sorry for the off-topic thread,
> Dan
>
>
> Mark Panay wrote:
>
>> Hi Dan,
>>
>> 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
>> http://clagnut.com/blog/241/
>>
>> 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...
>>
>> Have a read, well worth it.
>>
>> Mark.
>>
>> On 18/10/06, Dan Munk
<danmunk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>>> Hello,
>>>
>>> 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?
>>>
>>> Thanks,
>>> Dan
>>>
>>>
>>>
>> --
>> www.markpanay.com - Jargon Free Development
>> www.menscookeryclub.com
>>
>
>
> >
>
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---
Dan, 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. Hope this helps a little. Mark. On 24/10/06, Dan Munk <danmunk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Hi Mark, > > 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. > > Thanks and sorry for the off-topic thread, > Dan > > > Mark Panay wrote: > > Hi Dan, > > > > 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 > > http://clagnut.com/blog/241/ > > > > 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... > > > > Have a read, well worth it. > > > > Mark. > > > > On 18/10/06, Dan Munk <danmunk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > Hello, > > > > > > 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? > > > > > > Thanks, > > > Dan > > > > > > > > > > > > > > > > > > > -- > > www.markpanay.com - Jargon Free Development > > www.menscookeryclub.com > > > > >-- www.markpanay.com - Jargon Free Development www.menscookeryclub.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On Tuesday 24 October 2006 06:11, Dan Munk wrote:> 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''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. Michael -- Michael Schuerig mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org http://www.schuerig.de/michael/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
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.
<form>
<fieldset id="user_info">
<label for="first_name">First name</li><input
name="first_name"
id="first_name" />
<label for="last_name">Last name</li><input
name="last_name"
id="last_name" />
</fieldset>
...
</form>
You can use <br /> 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.
On 10/24/06, Mark Panay
<markpanay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:>
>
> Dan,
>
> 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.
>
> Hope this helps a little.
>
> Mark.
>
> On 24/10/06, Dan Munk
<danmunk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > Hi Mark,
> >
> > 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.
> >
> > Thanks and sorry for the off-topic thread,
> > Dan
> >
> >
> > Mark Panay wrote:
> > > Hi Dan,
> > >
> > > 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
> > > http://clagnut.com/blog/241/
> > >
> > > 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...
> > >
> > > Have a read, well worth it.
> > >
> > > Mark.
> > >
> > > On 18/10/06, Dan Munk
<danmunk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > >
> > > > Hello,
> > > >
> > > > 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?
> > > >
> > > > Thanks,
> > > > Dan
> > > >
> > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > www.markpanay.com - Jargon Free Development
> > > www.menscookeryclub.com
> >
> >
> > >
> >
>
>
> --
> www.markpanay.com - Jargon Free Development
> www.menscookeryclub.com
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---
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 <label for="blah">Fieldname</label><input type="text" name="blah" id="blah" /> 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 <label> and <input> 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.) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On Tuesday 24 October 2006 14:50, Ben wrote:> 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 <label for="blah">Fieldname</label><input > type="text" name="blah" id="blah" /> > 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. Michael -- Michael Schuerig mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org http://www.schuerig.de/michael/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Here is a great article on accessible, CSS-driven forms using <fieldset> http://www.alistapart.com/articles/prettyaccessibleforms -rich Brian Hogan wrote:> 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. > > <form> > <fieldset id="user_info"> > <label for="first_name">First name</li><input name="first_name" > id="first_name" /> > <label for="last_name">Last name</li><input name="last_name" > id="last_name" /> > </fieldset> > > ... > </form> > > You can use <br /> 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. > > On 10/24/06, Mark Panay <markpanay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > Dan, > > > > 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. > > > > Hope this helps a little. > > > > Mark. > > > > On 24/10/06, Dan Munk <danmunk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > Hi Mark, > > > > > > 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. > > > > > > Thanks and sorry for the off-topic thread, > > > Dan > > > > > > > > > Mark Panay wrote: > > > > Hi Dan, > > > > > > > > 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 > > > > http://clagnut.com/blog/241/ > > > > > > > > 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... > > > > > > > > Have a read, well worth it. > > > > > > > > Mark. > > > > > > > > On 18/10/06, Dan Munk <danmunk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > Hello, > > > > > > > > > > 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? > > > > > > > > > > Thanks, > > > > > Dan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > www.markpanay.com - Jargon Free Development > > > > www.menscookeryclub.com > > > > > > > > > > > > > > > > > > > -- > > www.markpanay.com - Jargon Free Development > > www.menscookeryclub.com > > > > > > > > > ------=_Part_4786_8318560.1161692771671 > Content-Type: text/html; charset=ISO-8859-1 > X-Google-AttachSize: 5310 > > 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.<br><br><form><br> <fieldset id="user_info"> > <br> <label for="first_name">First name</li><input name="first_name" id="first_name" /><br> <label for="last_name">Last name</li><input name="last_name" id="last_name" /> > <br> </fieldset><br><br>...<br></form><br><br>You can use <br /> 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. > <br><br>Not my idea but it makes a lot of sense and I''ll begin using this technique soon.<br><br><div><span class="gmail_quote">On 10/24/06, <b class="gmail_sendername">Mark Panay</b> <<a href="mailto:markpanay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"> > markpanay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Dan,<br><br>30 fields... That''s a fair few. I would approach this by making good > <br>use of the fieldset tag to seperate out the fields into groups, i.e.<br>personal details, work details, likes/dislikes, etc... This would make<br>the info on the page more readable and semantically useful. You could<br> > also then give these fieldsets different IDs and then use javascript<br>to hide and show them when necessary.<br><br>Hope this helps a little.<br><br>Mark.<br><br>On 24/10/06, Dan Munk <<a href="mailto:danmunk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"> > danmunk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org</a>> wrote:<br>><br>> Hi Mark,<br>><br>> I agree with the example, but it also illustrates my issue. I am<br>> working on a pure data entry screen for clerks that key hundreds of<br>> applications a day. The form contains a slew (30+) of fields. Data > <br>> entry clerks want absolutely no scrolling, so all of the labels and<br>> fields must be on one screen.<br>><br>> I have found a ton of blogs/articles documenting the flexibility of<br>> using CSS to layout the form elements, but they only have a few fields > <br>> on their examples and there is always a ton of whitespace.<br>><br>> It is probably due to my limited CSS skills, but I have found it very<br>> difficult to get a tight layout with the number of fields I am working > <br>> with. Even things as fundamental as having more than one label on one<br>> line without breaking has proven difficult. I would certainly like to<br>> use CSS and not tables, but I just haven''t found much to work off of. > <br>><br>> Thanks and sorry for the off-topic thread,<br>> Dan<br>><br>><br>> Mark Panay wrote:<br>> > Hi Dan,<br>> ><br>> > I was going to write a quick summary of my thoughts on why you > <br>> > shouldn''t use tables for forms, but then remembered this link<br>> > <a href="http://clagnut.com/blog/241/">http://clagnut.com/blog/241/</a><br>> ><br>> > Essentially, use a table if you wish, but you will find it easier to > <br>> > change the look at a later date (without touching markup) using more<br>> > semantic means...<br>> ><br>> > Have a read, well worth it.<br>> ><br>> > Mark.<br>> ><br>> > On 18/10/06, Dan Munk < > <a href="mailto:danmunk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org">danmunk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org</a>> wrote:<br>> > ><br>> > > Hello,<br>> > ><br>> > > I am working on a pure data entry screen that contains 30+ input<br>> > > fields. One of the requirements is that the page needs to be designed > <br>> > > so that everything can fit on one screen with no scrolling.<br>> > ><br>> > > In the past I would have used tables to control field placement, this<br>> > > tightly. I have looked around the Web for examples of CSS usage to > <br>> > > layout forms, but have not been able to find anything with near the<br>> > > volume of fields that need to be placed.<br>> > ><br>> > > Another complication is that fields are grouped in different > <br>> > > containers, where each container can be toggled between view/edit mode<br>> > > allowing for the data to be updated using AJAX.<br>> > ><br>> > > Is absolute positioning the best way to go to get the control I need? > <br>> > > Does anyone know of a good example I can take a look at?<br>> > ><br>> > > Thanks,<br>> > > Dan<br>> > ><br>> > ><br>> > > ><br>> > ><br> > > ><br>> ><br>> > --<br>> > <a href="http://www.markpanay.com">www.markpanay.com</a> - Jargon Free Development<br>> > <a href="http://www.menscookeryclub.com">www.menscookeryclub.com</a><br>> > <br>><br>> ><br>><br><br><br>--<br><a href="http://www.markpanay.com">www.markpanay.com</a> - Jargon Free Development<br><a href="http://www.menscookeryclub.com">www.menscookeryclub.com</a><br><br> > ------=_Part_4786_8318560.1161692771671----~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Michael Schuerig wrote:> 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 <label for=''blah''> tag, I suppose. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On Tuesday 24 October 2006 17:46, Ben wrote:> Michael Schuerig wrote:> 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. Michael -- Michael Schuerig mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org http://www.schuerig.de/michael/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Ben wrote:> 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 <label for="blah">Fieldname</label><input > type="text" name="blah" id="blah" /> > 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''Another tool I''ve used for form layout, which I still use where appropriate are definition lists: <dt> for the label, <dd> for the input(s). (You can have multiple <dd> elements for each <dt>.) Drawback: No way to group these items together in the <dl>, it''s a flat structure. However, I think it''s more lightweight and semantic than <ul>. 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: <table>. You can even identify and classify your table cells, and use table header <th> 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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---