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

[Teemu A. <te...@di...>]

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.

>><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
>>   * A "date selection" widget, consisting of three
>>     <select> dropdown lists (year, month, day). I'd
>>     like to replace this one with a proper calendar
>>     widget, sometime.
>><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

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.

>>     +--------+      +--------+
>>     |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.

>><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
>>   * If you still have too little to do, then
>>     "View"-versions of the widgets would be nice.
>>     Especially for list-type, tabular and hierarchical
>>     data.
>><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
>
> 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).

> 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.

> 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.

>>     - 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).

>><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
>>   * It would be nice if all CSS measurements were in
>>     em's and not px'en, so that page scaling works
>>     better (increasing the text size in your browser).
>><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
>
> I'm personally not a big fan of ems as they do funny things cross-browser.

With fonts I guess percents work best cross-browser. Plone.org has
very good CSS implementations, see how they use ems and percents.

Regards,

Teemu Arina

Dicole http://www.dicole.org
FLOSS in education blog: http://flosse.dicole.org

"Discover, collaborate, learn."