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

[aardvark]

On 20 Jun 2005 at 9:22, Jeff Howden wrote:
[...]
> 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).

looks much better matched with the vertical...

as for the order, remember those tricks we'd do with tables (spans, 
and aligns) to get the last button on screen to still be first in 
source? i've done similar, less offensive, tricks with floats... i've 
floated my first button in source order to the right so it appears 
last, and usually floated the rest over as well... the problem, of 
course, is that i need to define a container else the buttons sprawl 
out to the far edge...

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

i have a customer information screen that is being used in an 
intranet within a framed window... the users have 800x600 displays, 
and the requirement is for no scrolling... everything fits on one 
screen nicely, but if i add any extra space (error boxes, for 
example), then i get a scroll... that's where i can safely use the 
red text and red tick in the field -- we have that control over the 
platform in this case...

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

setting the label to red, in this case, handles selects and 
radios/checks well... hadn't thought about object/embed, but i can't 
think of cases right now where i would be using them... i also 
sometimes change the borders on the radios/checks to red, but i'm 
still on the fence on that one...

also, i try not to use red for anything other than errors... since 
red is generally a warning color in the context of western audiences, 
using to indicate required would be counter to our standards...

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

exactly...

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

see above...

> ;p

ew.

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

yeah, that looks keen...

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

i saw nothing...

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

ok... you've won that battle... i concede that <p> isn't an ideal fit 
here, and that <div> is probably a much better fit...

ultimately, i always try to find an element that imparts some valid 
structural or semantic meaning, and then i try to apply styles to 
what i've got, without having to add any more elements... i think we 
all know that it's hard to get to that ideal anyway...

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

that makes sense...

i like that you've dropped the form into your site style now, too... 
makes it a bit easier to grok in a "real-world" environment...