I have this little piece of code and I often run into this problem knowing it's bad practice and I seek to find a better way to optimize this code.
<p>Register a house here.
<input type="submit" value="Login" onclick="formhash(this.form, this.form.password);" class="login"></p>
As you can see, I have wrapped the whole text in a <p> tag which is obviously bad practice but I need the two things to stand next to each other, and putting them on the same paragraph is surely the easiest way, but what ways would be best practice?
I have considered using a table for this, but using tables for things that are not meant to be a part of a table seems like bad practice too, lot's of code and it might be confusing.
Any advice? Thanks in advance.
Not sure why you'd think a <p> is bad practice. But:
You can always use elements like <div> and <section> if it suits you better.
Use <label> elements to associate labels for inputs. If done properly, you can have a nice effect when clicking on the label to focus on the corresponding input.
Easy rule to remember: An inline(-block) element can always be placed in a block element
The correct and most semantic way to do this would likely be:
<form>
<label>Your Label Here</label>
<input type="text" />
</form>
However, there really isn't anything wrong with how you're doing it. If it works, it works. Cleanliness is for other people or for yourself if you have to revisit the code a long time from now.
Hopefully this helps you have cleaner code!
Just wrap it in a span or div if you don't want to use a paragraph:
<div>Register a house here.
<input type="submit" value="Login" onclick="formhash(this.form, this.form.password);" class="login">
</div>
The input would also best be in a - this can be outside of the or
It seems to work the same
I need to layout a page, but I can't figure out how to do it without tables. I know it must be possible, but I can't think of a solution that isn't table-based that isn't incredibly rigid with fixed widths for everything.
Mockup: http://i.imgur.com/jSSDhIh.png
No matter what I do, it looks like I'm going to have commit a major sin. For example, the top set - it looks like I'm going to have either to:
Create a table (the root of all evil, apparently)
Hardcode widths and heights specifically for these elements. (either #id or style= or single-use classes, all three are also considered evil)
Is that the case? Is there a realistic way I can avoid those scenarios? Googling for answers just gets me a bunch of useless "TABLES ARE EVIL SO ARE CSS TABLES ALSO DON'T USE ID SELECTORS OR STYLE ATTRIBUTES EVERYTHING MUST BE A REUSABLE CLASS" with no actual useful information.
EDIT: I've already done this with CSS tables (display: table) and had it thrown back as unacceptable. I think it's fine because it works and it still looks good, but it's not my call.
Tables aren't evil. This stackexchange page alone has many tables on it. Some people want to use divs to create rows and spans using a grid. I suggest using tables where they seem appropriate. If you're really bent on avoiding it, consider grabbing something like bootstrap for twitter.
http://twitter.github.com/bootstrap/scaffolding.html#gridSystem
There you can use their scaffolding to arrange items the way you want without tables.
heres a link on HTML Tables – when and how to use tables in HTML
this might help you understand when to use tables.
on your mock theres no reason not to use tables. like wordpress backend uses tables for forms but in tabular form.
but if you really want to layout this on divs i rather suggest using css grid frameworks.
I personally use zurb foundation. heres the link
I'd recommend using Bootstrap, it gives you plenty of options for styling forms. (However it may interfere with the rest of your CSS.)
Here's how a two column form would work:
<link rel="stylesheet" href="http://twitter.github.com/bootstrap/assets/css/bootstrap.css">
<div class="row">
<!-- right column -->
<div class="span6">
<label>Subject <input type="text"></label>
<label>Category <select></select></label>
<label><input type="radio"> Permanent Change</label>
<label><input type="radio"> Temporary Change</label>
</div>
<!-- right column -->
<div class="span6">
<label>Requested Approval Date <input type="text"></label>
Effective Dates <input type="text"> to <input type="text">
</div>
</div>
Obviously the styling leaves a lot to be desired, but check out http://twitter.github.com/bootstrap/base-css.html#forms to see how much you can do. You'll want to look into <form class="form-horizontal">. Be forewarned that the CSS is picky, you'll need a lot of <div class="control-group">'s.
I have always struggled designing css forms, I can never get the input and label side by side. Do you have any words of wisdom that may help me.
I usually use a 10px margin on the bottom but cannot get them aligned
My Common form:
Name:
Email:
Phone:
Message:
text area
I know I'm going to get backlash for this from people who think that the only possible way to do things is with pure CSS, divs, spans, etc. However, your form is tabular. You have a column of titles, and a column of input fields. In this case, because of the tabular layout, a valid solution could be tables.....GASP!
Tables are not valid for page layout...let me repeat that again, tables are not valid for layout. However, you've got an element of a page, you're not doing a full page layout. You can easily use <th> elements to style the labels for the inputs, which is quick and simple. Overall, the table (tabular) solution would be less verbose than many of the CSS layouts given, which from a pure HTML standpoint is a win. It will continue to work and layout properly even when the server gets backed up and can't load the external CSS document. To all those who believe that tables are never ok, let me remind you that this solution will validate with W3 100% of the time provided your table is properly structured. And it's far more cross browser compatible, with no box-model issues in the "crabby" legacy browers. Certainly continue to progressively enhance with CSS as is best practice.
Theory and practice, especially in the web world, are two entirely different things. In theory, all of us should be producing 100% HTML5/CSS3/Semantic/SEO Optimized...blah blah blah. In practice, theory only goes as far as the first customer complaint. Progressive enhancement is key to survival. When a webform breaks in a big corporate setting, money is lost and people get fired. For that reason, the International Bank I recently did work for had requirements that demanded all its webforms were tabular (assembled with tables) It's hard to argue with a portfolio of sites whose users generate the company hundreds of millions of $$$ annually.
<style>
ul.anyclassname{
padding:0;
}
ul.anyclassname li{
list-style-type:none;
clear:left;
}
ul.anyclassname li label{
width:300px;
float:left;
}
.inputs{
float:left;
}
</style>
<form>
<ul class="anyclassname">
<li>
<label>Name:</label>
<div div class="inputs"><input type="text"></div>
</li>
<li>
<label>Email:</label>
<div div class="inputs"><input type="text"></div>
</li>
<li>
<label>Phone:</label>
<div div class="inputs"><input type="text"></div>
</li>
</ul>
</form>
I usually do this:
<div>
<label for="txtname">Name:</label>
<input type="text" id="txtname" name="txtname"/>
</div>
<div>
<label for="txtEmail">Email:</label>
<input type="text" id="txtEmail" name="txtEmail"/>
</div>
<div>
<label for="txtPhone">Phone:</label>
<input type="text" id="txtPhone" name="txtPhone"/>
</div>
etc...
Then with my CSS:
label { width: 100px; display: inline-block; }
Something along those lines. Nothing fancy, but they are side-by-side and with the surrounding div you get a block level element to give you a line return after each pair.
I wrote a complete form in this answer: how can we make forms like this with css & html? . It has the html markups and the css classes you need to start.
The code is also in a fiddle here: http://jsfiddle.net/vSqR3/64/ (Now with the nice addition of the for attribute, thanks Kyle!)
You will find in that link not only how to put one markup next to the other, but how to set sizes and borders for each.
I strongly suggest you to play on the jsfiddle.net website. You'll be able to modify and test immediately all your changes.
One part of web development (from a front-end perspective) is laying out forms. There is never a standard set, and I've seen people continuing to use <tables> to keep styling consistent. Say you were to lay out this form:
At first glance it seems that a table would make laying out this form easy. Another options is to use <fieldset>'s, with perhaps a list inside them. Float the fieldsets to the left, give them equal widths.
My question is what is the most standard way of laying out forms? There seem to be several techniques, but many of them don't work cross browser.
How would you do it? And why?
I must say, the most common way to do this would be to use tables. Unfortunately, there are problems with table based form layouts (big surprise). One big thing is that tables will bleed over their containers (if overflow is not hidden) and they don't squash their contents like CSS can do. On top of that, rendering tables is more expensive (takes up more CPU cycles). Overall, I think that, compared to pure CSS solutions, table based form layouts are rigid and inflexible, and as a designer, I cringe (and you should, too!) at using tables for layout purposes to begin with.
A method that I am beginning to like (and that is growing more popular) is a pure, CSS2 method for laying out forms. I will not credit myself for coming up with the idea, but it is really straight forward. All you have to do is this:
THE HTML:
<form action="process.php" method="post">
<label for="username">Username:</label>
<input type="text" name="username" id="username" />
<br />
<label for="password">Password:</label>
<input type="password" name="password" id="password" />
</form>
THE CSS:
label, input {
width:200px;
display:block;
float:left;
margin-bottom:10px;
}
label {
width:125px;
text-align:right;
padding-right:10px;
margin-top:2px;
}
br {
clear:left;
}
As you can see, the CSS code is really minimal and the results are really awesome. The pros of this method is that it uses less code (faster to download), it is cleaner without all the messy table tags littering your HTML document (maintainability), and I believe web browsers will render the CSS method faster.
Update 1: I also found a CSS method using unordered lists.
Update 2: #musicinmyhead reminded me about using fieldset and legend tags in CSS form layouts. I coded us a quick and dirty little demo here.
Note: I originally learned of this pure CSS form layout from: http://www.cssdrive.com/index.php/examples/exampleitem/tableless_forms/
Research shows that labels above fields and fields all in one column are the easiest to fill out. Lukew has a lot of form's data/research/info:
http://www.lukew.com/ff/entry.asp?504
As a bonus, that's usually the easiest way to build the presentation layer as well. Plus, it's usually much more mobile-friendly out-of-the-box.
All that said, tables can be valid. In many ways, a form is a partially filled out spreadsheet (if you want to think in terms of tabular data).
I typically wrap the LABEL/FIELD pair in a div and position the label and field as needed depending on the layout desired.
The practice of using tables as layout made sense prior to CSS, but tables are actually intended to present data and nothing else. The simplest way to layout a form is label above field in a single column, but it is possible to create the same grid-like layout that tables provide using the <div> element and some CSS.
For that, the CSS might look like this:
.layout-grid{
display: table;
}
.layout-row{
display: table-row;
}
.layout-cell{
display: table-cell;
}
and the HTML might look like this:
<form action="foo.php" method="post">
<div class="layout-grid">
<div class="layout-row">
<div class="layout-cell">
<label for="foo">Foo:</label>
</div>
<div class="layout-cell">
<input id="foo" name="foo" />
</div>
</div>
<div class="layout-row">
<div class="layout-cell">
<label for="foo">Foo:</label>
</div>
<div class="layout-cell">
<input id="foo" name="foo" />
</div>
</div>
<div class="layout-row">
<div class="layout-cell">
</div>
<div class="layout-cell">
<button type="submit">Go!</button>
</div>
</div>
</div>
</form>
Personally? A table. At work? CSS. I go with whatever is required. There's the whole debate about the fact that a form is not in and of itself tabular data (like that of a form), which is true, and there is CSS that can create a cell-like structure.
If you're short on time and comfortable with only tables? Tables. Next up is the CSS/cell structure, but most will (probably rightly) say CSS all the way. It's not too difficult, and if you want to mix and match the whole thing, say adding an extra, fourth question at the bottom at the first three, it will make the change just a tad quicker. Not much, but a tad.
I continuously find places where I need to use the <br /> tag because CSS can't do what I need. Isn't the <br /> considered part of the "design" and not part of document structure? What is the acceptable usage for it? Should the same rules also apply to the <hr />?
Here is an example of where I feel forced to use the <br /> tag:
I want to display this:
<address>1234 south east Main St. Somewhere, Id 54555</address>
like this:
1234 south east main st.
Somewhere, Id 54555
There is nothing wrong with using <br /> or <hr />. Neither of them are deprecated tags, even in the new HTML 5 draft spec (relevant spec info). In fact, it's hard to state correct usage of the <br /> tag better than the W3C itself:
The following example is correct usage of the br element:
<p>P. Sherman<br>
42 Wallaby Way<br>
Sydney</p>
br elements must not be used for separating thematic groups in a paragraph.
The following examples are non-conforming, as they abuse the br element:
<p><a ...>34 comments.</a><br>
<a ...>Add a comment.<a></p>
<p>Name: <input name="name"><br>
Address: <input name="address"></p>
Here are alternatives to the above, which are correct:
<p><a ...>34 comments.</a></p>
<p><a ...>Add a comment.<a></p>
<p>Name: <input name="name"></p>
<p>Address: <input name="address"></p>
<hr /> can very well be part of the content as well, and not just a display element. Use good judgement when it comes to what is content and what is not, and you'll know when to use these elements. They're both valid, useful elements in the current W3C specs. But with great power comes great responsibility, so use them correctly.
Edit 1:
Another thought I had after I first hit "post" - there's been a lot of anti-<table> sentiment among web developers in recent years, and with good reason. People were abusing the <table> tag, using it for site layout and formatting. That's not what it's for, so you shouldn't use it that way. But does that mean you should never use the <table> tag? What if you actually have an honest-to-goodness table in your code, for example, if you were writing a science article and you wanted to include the periodic table of the elements? In that case, the use of <table> is totally justified, it becomes semantic markup instead of formatting. It's the same situation with <br />. When it's part of your content (ie, text that should break at those points in order to be correct English), use it! When you're just doing it for formatting reasons, it's best to try another way.
Just so long as you don't use <br/> to form paragraphs, you're probably alright in my book ;) I hate seeing:
<p>
...lengthy first paragraph...
<br/>
<br/>
...lengthy second paragraph...
<br/>
<br/>
...lengthy third paragraph...
</p>
As for an address, I would do it like this:
<address class="address">
<span class="street">1100 N. Wullabee Lane</span><br/>
<span class="city">Pensacola</span>, <span class="state">Florida</span>
<span class="zip">32503</span>
</address>
But that's likely because I love jQuery and would like access to any of those parts at any given moment :)
<hr /> and <br />, much like everything else, can be abused to do design when they shouldn't be. <hr /> is meant to be used to visually divide sections of text, but in a localized sense. <br /> is meant to do the same thing, but without the horizontal line.
It would be a design flaw to use <hr /> across a site as a design, but in this post, for instance, it would be correct to use both <br /> and <hr />, since this section of text would still have to be a section of text, even if the site layout changed.
<hr/> and <br/> are presentational elements that have no semantic value to the document, so from a purist perspective yes, they ought to be avoided.
Think about HTML not as a presentational tool but rather as a document that needs to be self-describing. <hr/> and <br/> add no semantic value - rather they represent a very specific presentation in the browser.
That all being said, be pragmatic in your approach. Try to avoid them at all cost but if you find yourself coding up the walls and across the ceiling to avoid them then its better to just go ahead and use them. Semantics are important but fringe cases like this are not where they matter the most.
I believe absolutely avoiding usage of a commonly accepted solution (even it is outdated) is the same thing as designing a table with <div> tags instead of <table> tags, just so you can use <div>.
When designing your website, you probably won't require the use of <br /> tags, but I can still imagine them being useful where user input is needed, for example.
I don't see anything wrong with using <br /> but have not come across many situation where I required using them. In most cases, there probably are more elegant (and prettier) solutions than using <br /> tags if this is what you need for vertically seperating content.
I put in a <hr style="display:none"> between sections. For example, between columns in a multi-column layout. In browsers with no support for CSS the separation will still be clear.
No. Why? They're useful constructs.
Adding this addendum (with accompanying HR), in case my brief answer is construed as lacking appropriate consideration. ;)
It can be, and often is, an incredible waste of time -- time someone else is usually paying for -- trying to come up with cross-browser CSS-limited solutions to UI problems that BR and HR tags, and their likes, can solve in two seconds flat. Why some UI folks waste so much time trying to come up with "pure" ways of getting around using tried-and-true HTML constructs like line breaks and horizontal rules is a complete mystery to me; both tags, among many others, are totally legitimate and are indeed there for you to use. "Pure," in that sense, is nonsense.
One designer I worked with simply could not bring himself to do it; he'd waste hours, sometimes days, trying to "code" around it, and still come up with something that didn't work in Opera. I found that totally baffling. Dude, add BR, done. Totally legal, works like a charm, and everyone's happy.
I'm all for abstracting presentation, don't get me wrong; we're all out do to the best work we can. But be sensible. If you've spent five hours trying to figure out some way to achieve, in script, something that BR gives you right now, and the gods won't rain fire down on you for doing it, then do it, and move on. Chances are if it's that problematic, there might be something wrong with your solution, anyway.
Interesting question. I have always used <br/> as a carriage return (and hence as part of content, really). Not sure if that is the right way of going about it, but its served me well.
<hr/> on the other hand...
I'd not say at all costs but if you want to be purist, these tags have nothing to do with structure and everything to layout but HTML is supposed to separate content from presentation. <hr /> can be done through CSS and <br/> through proper use of otehr tags like <p>.
If you do not want to be a purist, use them :)
I think you should seldom need the BR tag in your templates. But at times it can be called for in the content, user generated and system generated. Like if you want to keep a piece of text in the paragraph but need a newline before it.
What are the occasions where you feel you are forced to use BR tags?
<br> is the HTML way of expressing a line break, as there is no other way of doing it.
Physical line breaks in the source code are rightfully ignored (more correctly: treated as a single white space), so you need a markup way to express them.
Not every line break is the beginning of a new paragraph, and packing text into <div>s (for example) just to avoid <br>s seems overly paranoid to me. Why do they bother you?
BR is fine, since a hard line-break could be part of the content, for example in code blocks (even though you'd probably use the PRE-element for that) or lyrics.
HR on the other hand is purely presentational: a horizontal rule, a horizontal line. Use border-top/bottom for neighbouring elements instead.
I personally feel that, in the interest of true separation of content and style, both <br /> and <hr /> should be avoided.
As far as doing away with <br /> tags in my own markup, I use <div> in conjunction with the css margin property to handle anything that needs a line break, and a <span> for anything that would be inline, but of a different "content class" (obviously distinguishing them with the class attribute).
To replace an <hr /> tag with css, I simply create a <div> with the border-top-style css property set to solid and the other three sides set to none. The margin and the padding properties of said <div> then handle the actual placement/positioning of the horizontal line.
Like I said, I'm no expert, my web design experience is mostly a side effect of my work with JSP pages (I am a Java programmer), but I came upon this question during some research and wanted to put my two cents in...
You can use <br> but don't use <hr>.
<BR> — LINE BREAK— This is display information. Still in
common use, but use with restraint.
<HR> — HORIZONTAL RULE— Display info with no semantic value –
never use it. “Horizontal”, by definition, is a visual attribute.
Source: Proper Use Guide for HTML Tags
That's bad usage if you're going Strict.
<br/> and <hr/> are not part of the content. For instance the <hr/> is commonly used to separate blocks of text. But isn't possible to that with border-bottom? And <br/> is seen in many cases as a way to limit text to a certain form, which couldn't be accomplished with css?
Of course you aren't going Strict don't worry to much.
HR has some hacky uses right now in preventing mobile browsers' font inflation algorithms from kicking in.
Also if you have lots of small content separated by HRs, the Googlebot will currently see it as 'N separate entries', which might be useful to you.
BRs should really only be used as a line break within a paragraph, which is a pretty rare typographical usage (except perhaps within a table cell), and I'm not aware of any hacky reason to use them.
Here is an excerpt from a course that helps you learn html.
<form>
<p>Choose your pizza toppings:</p>
<label for="cheese">Extra cheese</label>
<input id="cheese" name="topping" type="checkbox" value="cheese">
<br>
<label for="pepperoni">Pepperoni</label>
<input id="pepperoni" name="topping" type="checkbox" value="pepperoni">
<br>
<label for="anchovy">Anchovy</label>
<input id="anchovy" name="topping" type="checkbox" value="anchovy">