whats the correct way to layout forms using css xhtml strict , so you have 2 text areas on each line, and have control over the space between the lines. I used unordered lists as in my other post but unwanted space occured
Uhm… do you have a picture of what you are trying to do, having trouble visualizing it.
If I’m understanding the question, you SHOULDN’T need ANY extra elements like lists, tables, div, etc to do a form since you have labels and inputs. Your other thread left me with just one question about that list - WHY!!! There is NO reason to be wasting markup on a LIST there.
You can:
<label>My Element:</label>
<input />
<br />
Controlling space between them with line-height.
You can:
<label>
<span>My Element:</span>
<input />
<br />
</label>
setting label to display:block and pad the bottom, while fixing the width and floating the two inner tags.
Though really I’d have to see what it is you are trying to accomplish for a layout on it to come up with the best markup to accomplish it with.
Ok, to break down the HTML
FORM#quickContact - Our primary hook, really given the style we don’t NEED classes or ID’s on any of our sub-elements if we take proper care. We don’t need a div around it, we don’t need a list inside it.
FIELDSET Because you aren’t playing with border or padding on it, we really don’t need to play with the fieldset much.
LEGEND Legend placement can be a royal pain, so most the time you are best off just slapping a span inside it to absolute position it. You can use padding to make room, or an element like a paragraph…
P which you have perfectly good text to slap into a paragraph tag.
LABEL Labels can be used to wrap their inputs, which works to our advantage because all we need to do is float these. I noticed in your image they are in the same order as your code, so all that extra wrapping and floating - completely unnecessary! LABEL will do our job!
LABEL SPAN The span are there for padding or other styling hooks.
LABEL INPUT - Just the input. Remember that LABEL’s for statement should always be required, and point at the ID of the input it is for.
LABEL BR - When CSS is disabled, make sure they all end up on one line apiece. When developing the markup first and foremost you should be thinking that CSS and presentation doesn’t even exist, so what can you do to make it usable without all the eye candy.
DIV - The nested DIV is just a hook to style the submit. I tend to use a DIV instead of a fieldset for these so it’s easy to distinguish from the actual data fields. A submit is not a data field, so why would it be in a ‘set’ of fields.
… and that’s really all there is to the markup.
For the CSS, follow along here:
http://www.cutcodedown.com/for_others/mrcoda/screen.css
First I use a CSS reset - it’s a good idea to use one given that cross browser all those tags don’t tend to start out with the same values. There are larger ones, but they’re a bit saggy around the midsection for my tastes… there are smaller ones, but they can cause problems with form elements (which would be REALLY bad here)… this is a nice middle-ground, I’ve never needed more or had success with less.
body - NEVER set px fonts on body if it can be avoided, since that makes your %/em elsewhere meaningless. Even if you are forced to use PX on the document by image interactions, constrained widths or unpredictable element behaviors, BODY should remain %. The background-color is just there to make the form elements borders clear.
h1 - Just a placeholder.
#quickContact - I dropped the width to 768px so that it’s ACTUALLY 800 friendly (780 is not) - though I couldn’t tell what you were aiming for off that original as your target. The Margin is just to center it, and the position:relative is to prevent the absolute positioned span inside the legend from going off to never-never land. I regrettably am forced to use PX metric fonts because of the MULTIPLE px metric containers and the image interaction… Which of course I load that little phone image as the background here. I also set the text-transform so you don’t have to type it in all upper-case in the markup, which looks kind-of ‘meh’ when CSS isn’t present.
#quickContact fieldset - I set up some simple float wrapping and pad the left side to make certain our floats don’t try to overlap that phone image.
#quickContact legend span - uses absolute positioning to push that legend to where we want it.
#quickContact p - the text-align is obvious, less obvious is that the entire P rides up UNDER the absolute positioned legend, hence the extra padding.
#quickContact label - here’s the neat part about floats - they STACK. So if you have a bunch of them the same size in order, they’ll stack one atop each-other in nice neat columns. I pad the bottom just to push them apart a bit. Because our input and span will be display:inline and/or inline-block, the text-align:right will push them all over to the right edge of the label… Do our math right, and we get that 8px right ‘padding’ without actually stating it. This ‘unstated’ unused ‘padding’ (that isn’t really padding) lets us avoid the ‘perfect width’ IE layout headaches where all of a sudden it will decide they need to be one column. (IE - boo!)
#quickContact label span - Setting these to inline-block means we can declare a width on them in standards compliant browsers (in IE7/earlier you can ALWAYS declare a width even when you shouldn’t be able to). This width pushes the text over to the left thanks to the text-align… (I’d be half tempted to just let them ride up against the inputs on the right, but it’s your layout)
#quickContact label input - Manually declaring a width on these clears up some oddball cross browser issues… Most still won’t actually make them the same size, ESPECIALLY using the markup ‘size’ property - so we undersize these just a hair to account for that. The font size on inputs does NOT inherit from it’s parent so we need to set that to match, and I turn off text-transform (which inherits in some but not all browsers) since the user will likely want to type upper and lower case.
#quickContact div - just some padding to make it pretty and a text-align to position that submit. Wasn’t actually certain where you wanted the submit, so I took a wild guess.
Hope this helps.
your form is exactly what I want, but , I dont want to use html text for the lables, I want graphics, I also want accessability and validation, thats what I’m trying to achieve, why ?, I just want more control over design and know clients will too, if posible. I would like to know why not if so. I’m just trying to offer a bit more in the way of bespoke style I supose.
Thanks for this, I do appreciate it.
I think you just misunderstood - and I didn’t see the image UNDER your content that showed what you were trying to do. That one image (hidden behind the broken form) told me more than the finished page did.
I THINK I’m still guessing wildly, but is THIS:
http://www.cutcodedown.com/for_others/mrcoda/template.html
What you are trying to do? It’s kind of funny, from all that excess markup you had I thought you were trying to do something much more complex than what you actually have. I’m still guessing as to the input sizes and placements… but for the most part that’s what you are after ja?
I threw out the background image since as xhtmlcoder said, that’s a REALLY bad approach to handling things, and just kept the little ‘phone’ and placed it best I could.
Side note - If you are just working on the form/database side, you should be working on the markup WITHOUT the styling. It’s the best approach to get the semantic proper tags around the elements for the document structure FIRST, before you even think about appearance. proper semantic markup, THEN the layout in CSS, THEN the graphics.
I’ll write up a breakdown of the HTML and CSS for you to explain WHY it works, it’s actually pretty simple.
What I assume you are asking is how to replace the ‘label’ text with those 4 textual images (quick_response_BG.gif) which to me doesn’t make a lot of sense - regarding UK Web Accessibility - but it would probably be easier if you used four separate images.
I think that is what you are after?
actually you have helped me, but in future, just leave the “YOU STUPID IDIOT” off the end of your sentences.
just think if we were all as good as you deathshadow, you wouldnt have anyone to look down your nose at, so go easy on us lesser mortals.
look , its not a site crytic I want , its not finished , I just working on the form and database etc. If you know what I’m trying to do you can say what you have just said, but you dont , so disaster it isnt. If you looked at the great pyramid of giza when it was being built you would think that was a disaster too. I did say I was learning. When you know what the end result is going to be , you can comment on weather somethings the way its meant to be or not. Look deathshadow, go and prove your a guru to someone else, your not helping me , your just bigging yourself up. Anyone else can help me please?
Actually, read what I said about gilder-levin - that’s EXACTLY the solution I’m talking about since I apply “CSS sprites” to them. (I don’t consider them true sprites, I prefer the term sliding backgrounds)
I use image replacement and CSS sprites all the time - I just am not sure I’d be using it on form elements or ‘all over the page’. I mean, where do you drawn the line? Next thing you know you’ll be using it for actual flow paragraphs.
As I said, Gilder-levin and CSS sprites addresses all except the last two issues. They don’t auto-scale to the system metric, and it’s a royal PITA to update.
For me that’s enough reason to restrict their use to a handful of headings and menus.
I do have another technique that uses javascript to do a per letter overlapping replacement of the text using images - requires no plugins, SVG, VML or other tricks… but I’m not sure I’d ever try using it on a production website. Was more of an experiment to see if it could even be done.
http://battletech.hopto.org/experimental/dynafont/template.html
Wrote that like three or four years ago. Was planning on using to for headings on one site in particular, but that project has been on the back-burner for the better part of two years since that would be for a volunteer project, not a paying one. Was actually going to use a simpler version since the font desired was mono-space mono-caps, so it doesn’t need the complex kerning functionality.
Ok, here it is with image-replacement.
http://www.cutcodedown.com/for_others/mrcoda/imageReplacement/template.html
It uses this image, cutting out some unnecessary white-space to try and keep the filesizes under control.
Using this one image means less handshakes than the method most people would use - which would have all of those as separate files. It’s harder to update, but is a lot less strain on the server and loads faster.
The major changes to the markup is the addition of classes to some of the parent wrapping elements so we can slide that background image around, and an empty BOLD tag for use as the image. Normally I would use a span, but we’ve already used those inside the form - so we need another tag if we don’t want to end up adding even MORE classes. Thankfully empty elements are ignored so there is zero impact on semantics or SEO from their presence.
In the CSS all of the immediate parents wrapping the bold tags need positioning. On the legend, it’s already absolute positioned so it doesn’t need anything extra, but on the P and the LABELS they all need position:relative added. Thankfully the ones that would need haslayout to fix positioning bugs already have it thanks to the various widths and heights declared.
All the image sandbags share the same absolute positioning, height and background-image, so we can set those together. Likewise the legend and label ones share position values, so those too can be put together. We then set the widths on those two, and then the positioning and width on the one for the paragraph. Finally we just need to set the background-position off each parent class to slide that image around to show just the parts we want.
It’s a very powerful technique, and is fine for small uses on things like headers from time to time - I am NOT certain I would even TRY using this technique this much on a page.
It’s one of those “just because you CAN do something, doesn’t mean it’s a good idea” moments.
totally correct code does mean less flare in style and more standard looking pages though doesnt it ?
Digressing a bit now.
look , for a start you use sprites, so theres only one image, as I have on the rollovers at the top of my homepage, and then theres only one handshake, the text is in the 1x1 <span> and doesnt use hidden text and is clearly marked as image replacement text which google is OK with, and the text reader reads the text inside the span. I think were both learning here Death.
Ok, semantically they aren’t two separate fieldsets (your example in the other thread had them as such) NOR are they lists… You just have some labels and inputs. They’d be ONE fieldset, but I’d use two SPAN to break them up for floating.
Looking at your other example, I’d approach the markup for that something like this:
<form method="post" id="quickContact" action="basicvalidation.php" onsubmit="return checkForm();">
<fieldset>
<legend>Your Contact Info</legend>
<span>
<label for="name">Name:</label>
<input type="text"
name="name"
id="name"
size="15"
maxlength="30"
/><br />
<label for="company">Company:</label>
<input type="text"
name="company"
id="company"
size="15"
maxlength="50"
/><br />
</span><span>
<label for="phone">Phone:</label>
<input type="text"
name="phone"
id="phone"
size="15"
maxlength="30"
/><br />
<label for="email">E-Mail:</label>
<input type="text"
name="email"
id="email"
size="15"
maxlength="50"
/><br />
</span>
</fieldset>
<div>
<input type="image" src="images/quick_response_send.gif" value="send" alt="send" />
</div>
</form>
You’ll notice I didn’t put the submit in a fieldset. To me a fieldset contains FIELDS - stuff the user fills out, so the input that submits the form doesn’t belong there. It’s also an easy way to provide a hook to style it with CSS if wanted without inheriting the properties of it’s parent elements.
Oh, and the non-breaking spaces are there because IE CORRECTLY collapses the bottom, while modern browsers do not…
For the CSS, I’d probably be doing something like:
#quickContact fieldset {
overflow:hidden; /* wrap floats standards browsers */
height:1%; /* trip haslayout, wrap floats IE */
}
#quickContact span {
float:left;
white-space:nowrap;
}
#quickContact label {
display:-moz-inline-block;
display:-moz-inline-box;
display:inline-block;
width:10em; /* you'll have to play with this value */
}
the inline-block behavior (or for IE the element already being inline-level) lets you set a even width, so you don’t need to play with floats on your labels/inputs. The nowrap on the spans will prevent the labels/inputs from riding down, while the floats puts the two span next to each-other. I used span instead of DIV
-
so that div’s block behavior doesn’t interfere when CSS isn’t present.
-
so that the div I use for hidden and submit inputs doesn’t need a class on it.
Note, the line-break before the close of each span MAY inject unwanted whitespace when CSS is applied. If so, apply a negative margin to the bottom each span equal to the current line-height, should clear that right up.
The reason for it being one fieldset is it’s all one type of data ‘contact info’ as the legend I added says. It’s only if it’s an entirely different type of information “reason for contact”, “payment info”, “shipping address” that it would warrant being a separate fieldset semantically.
Also, get used to using label and legend - that’s how you build a semantic proper accessible form. You do no/should not be throwing in lists, tables, or anything else.
(See the nimrods abusing definition lists for an example of COMPLETELY wasted code… Hunting season is open on them.)
– edit –
Oh, and styling fieldsets directly can be a bit unpredictable - much like legend. Common practice is to wrap an extra DIV around the fieldset with the class “fieldsetWrapper” to style instead. You WANT the fieldset accessibility on things that don’t see the CSS, but you cannot trust it for styling cross-browser. Legend is similarly afflicted so you’ll often see a span inside the legend (using the legend as it’s CSS hook) and then absolute positioning it in relation to the fieldset and/or div.fieldsetWrapper.
It’s a pain in the ass, but it’s the only solution that gives you predictable cross-browser styling AND semantics/accessibility.
WORSE, I’m a backwoods New England Yankee.
deathshadow, one minute I like you , one minute I think your an arsey mare, your not my misses are you? Thanks mate, your a bit of a star , you are.
In general you will find most developers will take you to task for the mere NOTION of doing this on labels, fieldsets, etc… They’ll tell you to suck it up and deal with the default fonts. It’s why xhtmlcoder reacted as such, and why I had similar misgivings.
For the most part I agree with this, but there are ways around the shortcomings… The best technique being “gilder-levin image replacement” - I write up a demo for you that does that on the labels, paragraph and legend.
But first let’s review the problems with using images:
-
Images instead of text means search engines have nothing to look at - it’s bad SEO.
-
Screen readers aren’t going to present it properly either.
-
It’s a waste of bandwidth. Blowing a 1 to 3k of images for single digit BYTES of text isn’t all that great an idea.
-
multiple images means more handshakes, slowing the page load and unnecessarily increasing server load thanks to the extra file requests.
-
The text does NOT automatically enlarge for large font/120dpi users, win7 144dpi ‘ten foot’ media center users, or shrink for the handful of handhelds that obey screen but force 72dpi. (and yes, they are out there). That’s bad accessibility. There’s a REASON the WCAG says to use %/em for all user content. It’s also part of why fixed width layouts are a miserable /FAIL/ as well, but that’s a subject for another time.
-
It’s a HELL of a lot harder to update later on.
Now of those, only the last two cannot be ‘fixed’ by using gilder-levin style replacement… but since I resorted to PX metric fonts ANYWAYS which also don’t obey the rules for #5, what’s the big difference?
Gimme a while, I’ll toss together a version that uses a gilder-levin_esque method to put those images over the text.
Another approach would be using something like sIFR to let you force-load the font or one of the new SVG approaches - but those too can be really bloated.
Ok, I can’t even tell what that’s supposed to look like - though I’m pretty sure structurally the “valid XHTML” should NOT be the h1, that 90% of what you have applied as images on that page shouldn’t be images or should be applied on a per element basis using image replacement…
I mean you’ve got multiple H1’s that don’t even appear to be the starts of sections, lists on non-list elements, spans on what SHOULD be heading tags, nothing resembling actual content, a horde of div’s for god only knows what… hordes of DIV and span around elements that I cannot fathom the reasoning behind…
You are leaving me with more questions about just what it is you are even trying to do - as that is a DISASTER that I can’t even figure out what elements are what… Though your use of spans, lists and h1’s seems to have you similarly flummoxed.
Though I CAN see at least one major oopsy that is probably screwing you in IE. You have the XML prolog at the start of the document. That throws IE into quirks-mode, doctype or no. CERTAINLY not helping your issues.
Now if I could just make sense of what you are even trying to do.
what if a client wants what I want , with graphics for the form text, instead of html, how would you do that?