RE: [Openinteract-dev] RE: Further work on forms/layout (Was: RE: Building upon your 'CSS-Only, Table-less Forms'?)

[Jeff H. <je...@je...>]

Teemu,

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> From: Teemu Arina
> 
> A note about info/help boxes next to forms, I've seen
> in plone they have info boxes so that when you have
> focus in a certain element, the help for the element
> appears right next to the element as a layer. This way
> the layout remains compact and clean.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

I've never really liked the way Plone does it.  Perhaps something similar,
but better.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> You might also want to have:
> 
> (year, month, day) (hour, minute, second)
> (year, month, day) (hour, minute)
> (hour, minute)
> (hour, minute, second)
> 
> Then the ordering of year, month, day should be based on
> users localization settings (OI2 developers problem).
> Hours might also have [AM]/[PM] option dropdown for US.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

Agreed.  I can add some simple styling to accommodate any of the above
varieties.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> >>     +--------+      +--------+
> >>     |foo     |      |bah     |
> >>     |bar     | [>>] |quux    |
> >>     |baz     | [->] |        |
> >>     |bom     | [<-] |        |
> >>     |        | [<<] |        |
> >>     |        |      |        |
> >>     +--------+      +--------+
> 
> With some javascript and replacing the form elements
> with simple divs this is possible to implement as a
> drag & drop version as well, eliminating the need for
> arrows. Non-js could be implemented with just one
> ctrl-selectable select list element.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

Drag and drop does not remove the need for arrows.  Each is necessary to
address the assortment of user interaction styles.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > I'll need more information on what you mean by
> > "View"-versions.
> 
> I guess Salve means read-only versions. For date field,
> we will have e.g. "11th June 2005". Read-only in forms
> is probably implemented with the readonly property of
> form elements or with hidden fields together with a div
> or something to display the contents of the hidden 
> field(s).
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

Ah, so I'll need some very basic styling to address both read-only fields
and other markup used to display read-only data.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > I'm not quite sure how this applies to forms, which is
> > what I'd like to limit my involvement to.
> 
> Well if it's possible to separate a long form into
> multiple segments, each segment accessible through a
> tab without reloading the page.  Non-javascript version
> could just display the complete form on a single page.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

Ah, now I understand.  My extensive experience building complicated forms
has taught me that you can't really effectively do a multi-page form all
client-side without enormous amounts of JavaScript.  It seems the more data
the form must collect the more "conditional" elements found later in the
form become.  My personal opinion is that if you have a need to break
something into multiple pages, it's best to keep that functionality strictly
server-side.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > Yeah, it'd definitely have to be lightweight.  The
> > dynarch version is nice, but definitely not fast.
> 
> So far as I know this is the best one there is out there
> in the Open Source domain which works accross multiple
> different browser versions.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

Personally, if something can't be done about the speed, I'd rather just not
use it at all.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> >>     - default-layout.css
> >>     - default-menus.css
> >>     - default-content.css
> >>     - default-forms.css
> 
> We had layout.css and markup.css to separate positioning
> (margins, paddings etc) from display (colors, borders
> etc).
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

In my own development I usually break my styles down like so:

Linked:
  tags.css
  layout.css
  form.css
Imported:
  tags.import.css
  layout.import.css
  form.import.css

Optionally, I'll add a home.css after layout.css in the linked section and
home.import.css in the imported section after layout.import.css for the
homepage if the styling that page demands is sufficiently different.

 [>] Jeff Howden
     je...@je...
     http://jeffhowden.com/