Best practice for inline form elements?

[dresden_phoenix]

So we use CSS to style elements and keep semantic separate from aesthetics. and CSS is great and getting better at allowing almost any layout option regardless of the mark up so it's hard for me to find excuses to use mark up for .. well .. layout.


The question is this say you sad quiz in the form (pun) of a form ( or anything like this the example is fictional). so each question is a fieldset with the question text. That simple enough and each answer option is a... hmmm? Well a radio button and a label seem like a good idea; it cuts down codeand is totally semantic. One could even place the input inside the label tag.

<fieldset>
<legend>So this could be the question here. It could be long or short or it could just be a header for multiple questions coded as follows.<legend>
<label><input type='radio' name='answer'>an answer option and its  corresponding button. I dont even need an ID if its wrppped this way and it seems perfectly semantic and streamlined</label>
<label><input type='radio' name='answer'>another answer</label>
<label><input type='radio' name='answer'>another answer</label>
<label><input type='radio' name='answer'>another answer</label>
<label><input type='radio' name='answer'>another answer</label>
</fieldset>

Again with a little CSS one can layout this in to to a nice looking easily readable AND ACCESSIBLE FORM. But what if CSS is OFF? Then you have a long line of text punctuated by radio buttons. That is perfectly accessible, but a pain to read and use. We can solve this by placing BRs between each label or wrapping each label in a block level tag. But in each case we are adding extra mark up and purely for presentational reasons. Damned if I do damned if I don't.

So I was wondering what the forum expert consider the right approach to this kind of conundrum?

[RyanReese]

I'd do the <br> approach, purely because if CSS is off, then at least I have a fallback. So what if it's extra markup? We add markup all the time for text/image replacement techniques where we use a <span> normally.

It may bloat the HTML with "unneeded" code, although it would essentially cover the CSS off option.

[kohoutek]

Like Ryan, I'd use BR. What good does it do to have less markup at the cost of readability? The BR tag is for breaks and a perfectly valid way of separating form elements.

[dresden_phoenix]

So both of you would chose BRs over wrapping?

[kohoutek]

I would, yes.

[RyanReese]

So both of you would chose BRs over wrapping?

Yes. Such a simple fix for CSS being off is definitely worth it.

[TehYoyo]

Interesting - can you style a BR to not display if CSS is on?

br {display:none;}
label {etc.etc.etc.}

Then, you could still use CSS and keep it separate but also have it work w/ CSS off.

Eh?
~TehYoyo

[RyanReese]

That defeats the purpose of having it there though. If you're going to have it, why bother removing it just so you can accomplish the same effect another way? You're just creating work for yourself .

[TehYoyo]

That defeats the purpose of having it there though. If you're going to have it, why bother removing it just so you can accomplish the same effect another way? You're just creating work for yourself .

Because it's a fallback for if CSS is turned off. When CSS doesn't load, it'll still be on a line break.

~TehYoyo

[TheRaptor]

Because it's a fallback for if CSS is turned off. When CSS doesn't load, it'll still be on a line break.

~TehYoyo

Yes but the point is, why not skip the CSS and leave it to <br/> to do the line breaks?

[RyanReese]

Because it's a fallback for if CSS is turned off. When CSS doesn't load, it'll still be on a line break.

~TehYoyo

You missed my point. Raptor tried explaining. If you have <br> there and leave it like that (no effort at all) and just keep everything the same (because it shows how you want it to), why would you add extra work to display:none the BR and get the same effect the <br> gave you, with an alternative way with CSS, when you COULD just leave everything alone!

Don't over complicate things .

[TehYoyo]

Oh. I thought that we wanted to use CSS instead of a BR.

~TehYoyo

[RyanReese]

Oh. I thought that we wanted to use CSS instead of a BR.

~TehYoyo

The OP asked what we would do if we had the two options. Both kohoutek and myself picked the <br> flat out and no CSS added, since it does the same job and is less code to deal with. Perhaps you wanted to do the CSS approach instead, which is fine. I don't judge that much .

[TehYoyo]

D_P also talked about keeping the aesthetics apart from the semantics. I was just looking for a way to do just that while still having a fallback if CSS wasn't working or was turned off.

~TehYoyo

[dresden_phoenix]

Yes. taht was my original concerned. Though , after reading how this thread has progress I think therer e comes a time when you can be TOO hard core for your own good. Along with the separation of style and content... accessibility is an issue. Face it, when CSS IS OFF:

NAME: __________
EMAIL:__________
AGE: __________
TITLE: __________

is far more accessible than:

NAME: __________EMAIL:__________AGE: __________TITLE: __________


my old fallback , btw.. would have been to WRAP a block level element such as a DIV around each element. But reconsidering what has been said I think I will star to implement BRs ( in MOST cases.. you can never say ALL in web design) because of the following reasoning:

1) accomplishes line breaks when CSS is off
2) does not ACTUALLY alter the semantics ( using any block element but a DIV would)
3) Eliminates/simplifies the need for CSS styling for dropping each element to its own line
4) it's "reversible"... if you want to still stile each element as if the BR wasn't there BR { display:none ; } applied

Yeah Am still entertaining arguments to the contrary.. but so bar the BR seems to be in the lead.

[deathshadow60]

I'd also use BR, but that's because I prefer label and input to be siblings to each-other. That way I can set the label to inline-block, fix it's width, and then I don't have to mess with floats to get them to all line-up properly.

[dresden_phoenix]

And.. that NAILS it. BRs FTW..

[Stomme poes]

Be careful wrapping inputs in labels. Some AT and some browsers seem to sometimes have bugs when doing this, even though it's perfectly legal HTML. In accessibility circles the wrapping with label isn't recommended because of this. AT tends to lag browsers in terms of software updates.

[dresden_phoenix]

Stommey...
does that still hold true even if you STILL USE the "for" attribute on label tags that wrap controls?

[Stomme poes]

Yes.

Jim Thatcher of IBM has consistently recommended keeping the label and input tags separate. Window-Eyes had a bug where the input didn't seem to exist. Some versions of OSX seemed to not allow Safari users to click on the inputs... but this was a very intermittant and so hard to find the cause. There may be other AT with issues as well. It was also asked in the a11y community about "anything wrong with the redundancy of for-id *and* wrapping" and the replies were "if you do that be prepared to do way more testing, so don't."

That said, I've still done it on occasion but I try not to. I also use BR to stop inline labels and inline inputs from running into each other. One of Jakob Nielsen's big usability no-no's was when you have an inline row of radio buttons or check boxes where it's difficult to see which input belongs to which label. You would think wrapping the input in the label would help this, and I've done that too (and used background colours and outlines and extra margins on the label to help with this) but nowadays I tend to either margin the hell out of the labels or sometimes use an inline wrapper (like a span) for styling, and if no-CSS is an issue then br's with "display: none" as mentioned above do the trick nicely.

[deathshadow60]

and if no-CSS is an issue then br's with "display: none" as mentioned above do the trick nicely.

It also helps to not use that type of thinking... CSS off shouldn't be something you consider as an 'issue' at all, it should be the first thing you wrote the markup for. What does it do without style applied just using semantic tags and attributes?

If you're not thinking about that FIRST, you aren't writing HTML properly.

[Stomme poes]

What does it do without style applied just using semantic tags and attributes?

It runs everything all together and you lose usability. Actually so are most forms controls. Association, especially for those not brilliant in visio-spatial areas, becomes insanely difficult for no reason. A forced break uses newlines to group label-input pairs for no-CSS. With CSS you can use margins and other things, and remove the newlines.

http://stommepoes.nl/Forms/form1.png
http://stommepoes.nl/Forms/form2.png

Here's an example where proximity is assumed http://dubroy.com/blog/usability-mis...radio-buttons/ although it is recommended that with radios and checks, the input comes before the label, unlike all other form controls.
I can't find the Nielsen screenshot, of a row of radio buttons where the order is correct but the list is a bit long and there is no proximity to obviously show a radio belongs to a particular label.

You may be correct in that we maybe should not be thinking of CSS-off, but when my connection gets butt-slow I think about it a lot. Maybe most other people don't. I never, ever want to RELY on CSS to know how to work a form. I want it obvious at all times. But that may be because I'm stupid and easily confused by retarded forms.