Help Marking-Up/Styling Event Choices

HTML & CSS
1

I am trying to mock-up a checkout process for registering for an event (e.g. Sports Show) and could use some advice on how to mark-up/style the following…


Location:
------------------
Pierre, SD			___
Sat, Sept 24 (details)
*Only 2 seats left!!

Minneapolis, MN			___
Sat, Oct 1 (details)

Madison, WI			___
Sat, Oct 8 (details)

				*Add-to-Cart*

The underscores are supposed to represent Radio Buttons and *Add-to-Cart would be a Submit Button.

I was thinking of something like this…


<h2>Location:</h2>

<ul>
	<li>Pierre, SD</li>			___
	<li>Sat, Sept 24 (details)</li>
	<li>*Only 2 seats left!!</li>

	<li>Minneapolis, MN</li>			___
	<li>Sat, Oct 1 (details)</li>

	<li>Madison, WI</li>			___
	<li>Sat, Oct 8 (details)</li>
</ul>
				*Add-to-Cart*

IF I use Radio Buttons, I suppose I would like each Radio Button to be on the same line and to the right of the City.

(Have no clue how to mark-up or style that?!)

Suggestions?

Thanks,

Debbie

2

What about this as a starting point

        
        <style type="text/css">
            .ulEvents {
                list-style-type: none;
                width: 300px;
            }
            .liCity {
                margin-top: 30px;
            }
            .liCity input {
                float: right;
            }
        </style>



        <h2>Location:</h2>
        <ul class="ulEvents">
            <li class="liCity">Pierre, SD <input type="radio" name="radCity" value="pier" /></li>
            <li>Sat, Sept 24 (details)</li>
            <li>*Only 2 seats left!!</li>

            <li class="liCity">Minneapolis, MN <input type="radio" name="radCity" value="minn" /></li>
            <li>Sat, Oct 1 (details)</li>

            <li class="liCity">Madison, WI <input type="radio" name="radCity" value="madi" /></li>
            <li>Sat, Oct 8 (details)</li>
        </ul>
3

Yep, that’s what I asked for.

Unfortunately, I don’t think it looks very good… :-/

Maybe it would look better if the Radio Buttons were the first thing you saw, and then each listing was to the right of it and left justified?

Like this…



Location:

___	Pierre, SD
	Sat, Sept 24 (details)
	*Only 2 seats left!!

___	Minneapolis, MN
	Sat, Oct 1 (details)

___	Madison, WI
	Sat, Oct 8 (details)


	*Add-to-Cart*

What do you think?

If you like that layout better, how would I accomplish that? (Tried changing the Float to Left but it didn’t work exactly correctly?!)

Thanks,

Debbie

4

This reverses the radio buttons and text.

        
       <style type="text/css">
            .ulEvents {
                list-style-type: none;
                width: 300px;
            }
            .liCity {
                padding-top: 20px;
            }
            .ulEvents span {
                float: right;
            }
            .ulEvents li {
               clear: both; 
            }
        </style>

        
        <h2>Location:</h2>
        <ul class="ulEvents">
            <li class="liCity"><input type="radio" name="radCity" value="pier" /><span>Pierre, SD</span></li>
            <li><span>Sat, Sept 24 (details)</span></li>
            <li><span>*Only 2 seats left!!</span></li>
            <li class="liCity"><input type="radio" name="radCity" value="minn" /> <span>Minneapolis, MN</span></li>
            <li><span>Sat, Oct 1 (details)</span></li>
            <li class="liCity"><input type="radio" name="radCity" value="madi" /> <span>Madison, WI</span></li>
            <li><span>Sat, Oct 8 (details)</span></li>
        </ul>
5

Hi,

You know what I think about using lists for forms don’t you :slight_smile:

Where’s the label element anyway? The label is very important for accessibility with radio buttons because most browsers allow you to click the label to activate the button. It can be very hard for some users to click the small radio button

I would do it more simply like this and about 15% less code.


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Untitled Document</title>
<style type="text/css">
.location input, .location label {
	display:inline-block;
	vertical-align:middle;
	margin:0 0 15px 5px;
}
.location label { padding:0 0 0 40px; }
</style>
</head>
<body>
<form name="form1" method="post" action="">
		<fieldset class="location">
				<legend>Location:</legend>
				<input type="radio" name="radCity" value="pier" id="pier">
				<label for="pier"> Pierre, SD<br>
						Sat, Sept 24 (details)<br>
						*Only 2 seats left!! </label>
				<br>
				<input type="radio" name="radCity" value="minn" id="minn">
				<label for="minn"> Minneapolis, MN<br>
						Sat, Oct 1 (details) </label>
				<br>
				<input type="radio" name="radCity" value="madi" id="madi">
				<label for="madi"> Madison, WI<br>
						Sat, Oct 8 (details)</label>
				<br>
		</fieldset>
</form>
</body>
</html>
6

It’s usually considered good practice to have radio/checkboxes to the left of left-aligned text labels, because it makes it easier for people to align one with the other. If the buttons are way off to the right of the label then there could be a big gap between the text and the clicky bit, especially if the length of the labels varies a lot, and that makes it harder for people to click on the right ones.

Of course, you can get round that by right-aligning the text, but that tends to look messy…

7

“more simply” is a relative term and is subjective and I don’t see a 15% reduction in the code.

But in any case, like I said, it was a starting point given the op has not posted what other content is on the page. I wouldn’t necessarily use a fieldset if there is only 1 set of radio buttons on the page.

Whether someone uses a list or not boils down to a personal choice depending on how much flexibility and ease of maintenance you want. For example, the city name and event details might be required now or in the future to have different fonts, colours etc.

Everything else being equal, imo it can successfully be argued that the data the op is displaying is table data and so a table could also be used imo although I wouldn’t use a table in this case.

8

Ha ha. Yeah, I think we’ve tangled before on this issue… :lol:

Where’s the label element anyway? The label is very important for accessibility with radio buttons because most browsers allow you to click the label to activate the button.

I agree completely with this statement.

It can be very hard for some users to click the small radio button

So, what is a better design for what I want to do? (I’ve never understood why you can’t size Checkboxes and Radio Buttons?!)

I believe at the top of this thread - or maybe it was another - I was going to have an “Add-to-Cart” button next to each Date/Location. This would be similar to what a lot of E-commerce sites do, and seemed like a good approach since once they click one “Add-to-Cart” button they’d be whisked away to the next screen (i.e. Step #2: Register or Log-In) and so they couldn’t add multiple Event Dates/Locations.

I can see the benefits of each approach.

How would you handle this, Paul?

(Since my client doesn’t want people registering for Events that might not happen or that are too far in the future, there probably will only be 3-4 Event choices at any one time, is my guess.)

Thanks,

Debbie

9

I would use a table – shot me.

edit: maybe not, looking at it it kinda sucks though I do dig my lists.

10

There is a down side to using labels, although I usually include them but not because of accessibility, but for convenience of all users.

The down side is that elderly or anyone whose awareness is not quite what it used to be, through no fault of their own, do accidentally click the mouse button while moving the mouse around on a page and so they do some times make selections they would not normally make without even realising it by clicking on labels.

Just something to keep in mind :slight_smile:

11

You cannot typically easily resize check boxes and radio buttons because they basically only have the function of either ‘on’ or ‘off’ true/false and they’re basically controlled by the OS you use and have limited styling options.

12

No you are right its actually about 20% if you just take the form data itself as you should also have added fieldset and legend tags to your example.:slight_smile: (595 characters for your method and 472 characters for my method excluding fieldset)

I find that lists just confuse things in forms when all you want is a line break and this is the perfect and valid time to use breaks. Indeed with css off my version is less confusing than yours with all the bullets showing up.

The consensus of expert opinion is that forms are not tabular data or simple lists although I think a fair case can be made for both so I’m not saying they are completely wrong. What I am saying is that my version is simpler, less code, easier to read and does the job perfectly even with automatic vertical alignment unlike the floated method. I just do not see a need to do it any other way. (In html5 they advocate using p tags to wrap form controls but a lot of purists are aghast at that solution).

Of course it does boil down to personal preference and a few extra characters is neither here nor there when you are happy with your chosen method and make it do what you want :slight_smile:

But in any case, like I said, it was a starting point given the op has not posted what other content is on the page.

Yes, I didn’t mean to sound off-hand and your example was basically good.:slight_smile:

I wouldn’t necessarily use a fieldset if there is only 1 set of radio buttons on the page.

Yes its debatable whether if there is only one set of items whether you need the fieldset but the fact remains that it is invalid to have form controls inside a form that are not inside a block element so if you have to add a block element then it may as well be a fieldset and associated legend and the benefits to accessibility that go with it.

The benefit of labels are well known and documented although there may be the odd case of a mis-click the benefits far outweigh the problems in every area and each visible form control (apart from buttons as they are self labelling) should have an associated label otherwise screenreaders will be very confused or have a hard time working out what the control is for.

I think you should associate the label with the form control so that it gives the user the ability to click the label (in most browsers).

I believe at the top of this thread - or maybe it was another - I was going to have an “Add-to-Cart” button next to each Date/Location. This would be similar to what a lot of E-commerce sites do, and seemed like a good approach since once they click one “Add-to-Cart” button they’d be whisked away to the next screen (i.e. Step #2: Register or Log-In) and so they couldn’t add multiple Event Dates/Locations.

I can see the benefits of each approach.

How would you handle this, Paul?

If you are using radio boxes then (usually) you only have one choice to make anyway so one button would seem enough.

If you have mutiple choices then you may want to use an add to cart button next to it and no radio or check boxes. However if you want to make sure the user looks down the whole list then you may want to use checkboxes with just one add to cart at the bottom. Most ecommerce site list the products and then have an add to cart button next to it. (It’s probably a discussion more suited to general usability rather than CSS though.)

To be honest the simpler you can make the process the better. I still get confused when buying things online as there seems to be no logic in the process.

13

That type of comparison when the op hasn’t specified what, if any, additional styling might be required is meaningless because if the op wants to have different styles (font, colours etc) on each row or add additional spacing between the rows then you would need to add extra code (and hence characters) to your code.

But the issue of whether you use lists or not is moot because any additional download time, if any, would not be noticeable at all.

Like I said, I usually use labels but not always.

14

That may be true but I always work with the minimum to start with. Why add code until necessary but I take your point:)

Irrespective of the above the list method you proposed is a little flawed because even accepting that lists are ok in forms then these are certainly not separate list items.


 <li><span>Sat, Sept 24 (details)</span></li>
 <li><span>*Only 2 seats left!!</span></li>

They are items referring to each input and as such you should only have had 3 list items in your structure (although I know you were working form Debbies code so I’m probably being a bit picky here).

Although in my example you could argue that only the town name should be the label and the other two lines are just information. There are many ways to skin a cat but I find the inline-block method for forms are consistently providing better layout possibilities than floats.

However don’t get me wrong, I know some people prefer lists or tables to layout forms and if that’s what they want to do and find works for them then I’m fine by that. It’s just that I wouldn’t do it that way as I see no need.

15

Point for Paul on that one! (Good point!!)

If you are using radio boxes then (usually) you only have one choice to make anyway so one button would seem enough.

But it seems pretty standard for e-commerce sites to have “Add-to-Cart” buttons next to each product displayed in a list.

If there were 5 Events and each had its own button, I think it is pretty intuitive that you can only select one - assuming the page doesn’t reload upon itself - and one could argue that each button is more prominent and readable than those tiny Radio Buttons - which I don’t mind - but which can confuse many users…

Just my thoughts…

Debbie

16

Paul,

For argument’s sake, let’s say I ditch the radio buttons and want a page that looks like this…


Event		Cost	Attendees	Total
Flower Show	$20	___		____	[b]Select[/b]
Mankato, MN
Sept 24, 2011

Flower Show	$20	___		____	[b]Select[/b]
Willmar, MN
Oct 1, 2011

Banjo Jamboree	$50	___		____	[b]Select[/b]
Brainerd, MN
Oct 8, 2011

How would you go about doing the HTML/CSS for a more complex layout like that?! :-/

You basically have 4 columns: Event, Cost, Attendees (drop-down box) and Total (calculated field).

And I suppose you could argue the “Select” buttons make a 5th column?!

I’m pretty certain this is the layout I want to use, as it helps me eliminate a screen and get all of the purchasing info on one page.

I suppose you could through that data in an HTML Table, but I am thinking there is a better, non-table approach?!

What do the CSS gods think?!

Thanks,

Debbie

P.S. Even if I go for Radio Buttons over the “Select” buttons next to each Event, the rest of the layout above would still look the same, and I’m not sure of how to tackle it in a “graceful” way… :blush:

17

They could just as easily be seen as a list of event properties. It just depends how one chooses to view them and so again boils down to personal choice as to whether you use a list or not. :slight_smile:

18

I am a little confused. Do you want to learn how to do it or do you want Paul or someone else to just do it for free for you?

There is plenty of example code options already in this thread that should enable you to markup and style the relatively straight forward layout you have above :slight_smile:

Why not post your attempt at marking up and styling the above layout first :wink:

19

At that point you have tabular data – obvious rows and columns with headings – probably one of the few times I’d advocate a form around a table… with a thead filled with TH scope=“col” for that top row, inside TBODY each TR would probably be TH scope=“row”, TD, TD, TD… I’d consider moving the secondary lines to their own TR/TD, possibly with rowspan=“2” on all the actual data column TD’s since structurally the event should be the heading… that or put heading tags inside the TD though honestly, if you need headings it’s no longer table data (just as if you need headings it’s no longer a list item).

20

Yes I’m with Jason on this now that you’ve aligned it like that :slight_smile: A table would be sensible.

I’m not always against using tables or lists in forms when the section required is a list or is tabular data. I just don’t like them being used as a blanket solution when there is no need :slight_smile: