[thelist] CSS-Only Forms That Don't Suck

[Jeff Howden]

Aardy,

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> From: aardvark
> 
> > I tend to add a pointer cursor to the labels to let
> > users know that they can click on them.
> 
> ben, i've found through testing with clients as users
> (which is anecdotal and unscientific at best), the hand
> cursor tends to confuse them -- they think it's a link
> and are afraid to click it (and lose their place), or
> in a few cases, they click it and expect a pop-up with
> help to appear... these expectations have probably been
> set by a combination of poor page design in the past
> (which has burned said users when they lose the form
> and all the info they have entered) or win32 (or other
> OS) applications that sometimes have help associated 
> with field labels...
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

Interestingly, my experience has been the same.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> jeff, i am mad at you... you've done something i've just
> recently started working on myself (having done simpler
> forms in the past, i wanted to make one general form
> layout that would work with all my types of forms)...
> 
> jerk...
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

That's ok.  You'll get over it.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> you have a nice vertical line down the center of the
> form which is defined by the input fields' left edges...
> this sets a linear flow which holds until the submit
> button... i feel strongly that the submit button is lost
> on the right and needs to line its left edge up to the 
> vertical you've created... especially since it's hidden
> under your note box otherwise, and i had to search for
> it each time...
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

I've experimented with various setups for the submit buttons.  Based on your
feedback, I've tried yet another combination.  I think I've come up with
something that I'll stick with now.  The only major obstacle I'd like to
tackle with submit buttons is having a generic method of defining multiple
submit buttons and not being forced to have the left-most one be the first
in the source order (and therefore being the default when the user presses
the enter key).

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> i like how you've done the error fields... however,
> there are cases where i can't afford to have the extra
> height inserted by those boxen... [...]
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

Hmmmm, pray tell when you imagine that happening?

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> [...] as such, i have an error class that turns my
> labels red, and inserts a little red "tick" in the
> upper left corner of the field (except <select>s,
> which always make me grumpy)... I know you've seen
> this jeff, since i borrowed the tick idea from
> you... [...]
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

Additionally, radio buttons and checkboxes can't be marked with the red tick
either.  Perhaps there's some way it could be used in conjunction with the
<label> element instead.  That would allow support for all elements,
combination of elements, and custom elements created through scripting,
things included via the <object>/<embed> elements, etc.  Unlike you though,
I prefer to use the red tick to mark whether or not the field is required,
not to indicate an error.

Regardless of which method you end up settling on, you realize the
importance of maintaining consistency in your error reporting.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> [...] granted, for users without CSS, this approach
> fails... but for apps for targetted audiences, it works
> well for me...
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

... except where your forms user radio buttons, checkboxes, and/or <select>
elements.

;p

I've added the red tick to the top left corner of all error displays, and
interestingly, it draws a lot more attention to the fields with errors.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> your big red error bar at the top (surprisingly) doesn't
> stand out for me... i actually didn't see until just
> now... i think you need to set it off by increasing its
> left/right margins so it floats more in the middle,
> instead of spanning the entire width...
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

Done and agreed.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> tabindices... i've actually stopped using them in linear
> forms like this... because the order of the fields, when
> linearized, matches the tab flow i'd insert, i leave
> them out and just let the browser handle tabbing...
> this reduces conflicts when i really do need to insert 
> them with complex forms, or when my form gets inserted
> into a page that already has them defined in a number
> space that overlaps my own...
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

Actually, I'm in the same camp as you on that topic.  I only included them
in this example form to keep the pro-tabindex crowd quiet.  Sssshhhh, don't
tell them though.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> semantics... i've noticed you're using <div>s as your
> generic container... obviously, when containing
> block-level elements, you're kinda stuck... but i feel
> that most of the other <div>s could be replaced with
> <p>s, which at least have a semantic meaning and
> aren't just generic... granted, you know my aversion
> to <div>s and <span>s, so this shouldn't surprise
> you...
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

Smaller doses, less often.

;p

Seriously though, there isn't a single, semantic paragraph that isn't
properly wrapped with <p> elements.  According to the spec, I'm using a
<div> in exactly the prescribed manner; "These elements define content to be
inline (SPAN) or block-level (DIV) but impose no other presentational idioms
on the content.  Thus, authors may use these elements in conjunction with
style sheets, the lang attribute, etc., to tailor HTML to their own needs
and tastes." [0]  In my opinion, using <p> elements to contain one or more
<label> elements, one or more <input>, <select>, <textarea>, or other custom
elements, and, optionally, an explanatory note contained within a <small>
element is dubious at best and realistically more like grasping at straws.
According to the spec, "The P element represents a paragraph." [1]  The
document than goes on to describe aspects of the <p> element that relate to
its usage involving text.  Further, a paragraph is most loosely defined as:

  "A distinct division of written or printed matter that
   begins on a new, usually indented line, consists of
   one or more sentences, and typically deals with a
   single thought or topic or quotes one speaker's
   continuous words."

Personally, I find it a stretch that this could, in any way, be applied to
elements of a form and their supporting elements.

For semantic accuracy perhaps the only appropriate change would be to use a
<p> element for the error at the top and the errors within each <div>
element.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> it might interest you (or not) to know that one of my
> early implentations along these lines had me stuffing
> my labels and form elements into <dl>s (<label> into
> <dt>, <input> into <dd>)... it actually worked out quite
> well, especially when linearized and with no CSS, but
> its semantic purity is still kinda questionable...
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

Yes, I have also tried that, but abandoned it when I started taking my meds
again.  Using definition lists is over-engineering the solution, imo.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> ok... that's all i've got for now...
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

Thank you.  This is the best feedback I've receive so far.

[0]
http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#h-7.5.4
[1] http://www.w3.org/TR/1999/REC-html401-19991224/struct/text.html#h-9.3.1

 [>] Jeff Howden
     jeff at jeffhowden.com
     http://jeffhowden.com/