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">
Related
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 had a very hard time trying to word what I wish to know how to do, nor could I locate any post or website from Google that had my answer probably due to not being able to word this correctly, but I will explain in fullest detail.
<br />
<hr />
<br />
Break, horizontal, break is my way of separating parts of the post from another. How can I group the three into one simple tag that can replace the three, thus saving me time and hassle .
It would be also helpful to know if there are ways to define tag groupings with more than just empty tags like a tag identified by the string title1 would be a tag containing all the format, text, and all sub-elements of the template that was coded somewhere else.
If this question has already been posted then I am sorry. Thanks!
You don't need the <br> tags because <hr> is a block level element and automatically creates a line break. If you're doing that to get some vertical space above and below thw <hr> why not just use CSS to give the <hr> some margin?
hr
{
margin-bottom: 20px;
margin-top: 20px;
}
Neither <br> nor the proposed alternative <hr> are particularly well-suited here.
You need to learn about CSS. All you need to do is apply appropriate styles (i.e. a margin) to the elements that wrap your posts.
<div class="post">
<h1>Post #1</h1>
<p>something</p>
</div>
<div class="post">
<h1>Post #2</h1>
<p>something else</p>
</div>
div.post {
margin-bottom: 3em;
}
If you are using HTML5 then use <article> instead of <div class="post"> to denote individual posts.
As for grouping tags, this is currently not possible in plain HTML, you need to apply some preprocessing for that. The usual solution is to use a content management system which creates the final HTML based on your content and an HTML template.
Whilst this specific problem can be solved with a little bit of CSS, it sounds like you need a layout or templating engine of some sort in the long run. I'm a rubyist by trade so my go-to solution for doing this is Jekyll.
What Jekyll does is generate static html files from layouts and content that you write. You can abstract a lot of the repetitive layout markup into separate files and then just reference them when you need them.
The following guide is a good place to get started: http://net.tutsplus.com/tutorials/other/building-static-sites-with-jekyll/
If you're already working with another framework then do some reading around it first to see if there's something there you can use. If you're just writing straight-up HTML/CSS though, then definitely give Jekyll a try.
I've tried to search for a subject on this, but I haven't found any, so I thought I'd go ahead.
My question is when it is correct, if anytime, to just put your style directly in your HTML file, instead of using a .css file.
I mean, I get that it is very useful to use your .css file when you have alot of things that needs to be repeated, or is used on several pages.
But in my case, I have one page where I'm about to style something, that I'm pretty sure only will be on that page. This being the width, height, and small stuff for a div.
To show you what I mean, here's the code:
<div style="margin:0px auto; width:600px;">
<div style="float:left">
<p class="InputFieldsText">Brugernavn</p>
<div class="InputFields"><input name="Text1" type="text" class="Medium" placeholder="Din e-mail adresse" /></div>
<p class="InputFieldsUnderText">Glemt dit brugernavn?</p>
<p class="InputFieldsText">Password</p>
<div class="InputFields"><input name="Text1" type="password" class="Medium" /></div>
<p class="InputFieldsUnderText">Glemt dit password?</p>
<input onclick="window.location='user_page.html'" class="LargeIndent" name="Submit1" type="button" value="Log ind" />
</div>
<div style="float:left; width:172px; text-align:center">
<img alt="" height="128" src="images/lock.png" width="128">
</div>
</div>
So, as you can see, in some divs I styled it directly, instead of coming up with a name for my class and put on there.
I know it isn't wrong to do, since it will come out the same if I used it in my .css file and called a class, but is there a "guideline" or something that this and this is not recommended etc. etc.
Hope you understood my question. Really not that big of a deal, I've just always wondered :)
Regards
The answer is pretty simple, IMO: never. :)
You should always use a style sheet, because it allows you to quickly and easily change the entire appearance and layout of your site. If you embed the style information in the HTML directly, you have to work a lot harder if something needs to change; with a style sheet, you simply change the CSS file in a single location, and the change becomes global everywhere that style sheet is used.
It's best not to mix presentation with content. To simplify your CSS there is nothing wrong with using smarter selectors and IDs for elements for which you know there will always be one and only one. You don't have to define classes for every little thing.
In my opinion, inline styles make markup so cluttered, especially with large style declarations which cause line wrapping.
A small block of style inside the HTML page (instead of an external file) might be acceptable in some cases as it reduces the number of requests sent to the server. Server-side processing can be used to accomplish this by reading a separate stylesheet file and injecting the style directly into the page. With this approach, there is a trade-off between page size and the number of HTTP requests.
During development of a page I bung eveything into the same file.
just being lazy - have the stylesheet in the head part.
Then when in production seperate the HTML from the CSS. actually I do that during development when they share common features - a cut and paste job is required.
Never have your style information inline
When working with hierarchical template systems, I sometimes find it convenient to place style definitions in a stylesheet in that template, which ends up being part of the page. If these need to be reused, they can be migrated to a separate stylesheet.
Well, first things first. Styling takes some order of precedence :
inline styling
CSS in HEAD
imported CSS files
That is, if a specific element has some attributes defined in the .css file, then you can definitely override them by using inline CSS (<div style='...'></div>), for example.
Apart from that, I suppose it's merely a matter of taste and of how 'cluttered' (vs 'compartmentalized') you want your code to end up. Don't forget that CSS's main purpose is to separate : LOOK from STRUCTURE.
My GENERAL STRATEGY is :
Use CSS files, for better organization is bigger sites, that may be used an re-used in various files (portability)
Use CSS in HEAD in some "quite" big, but not too big chunks of CSS code, that are page-specific.
Use inline CSS for local modifications only (in REALLY small pages, or for existing specifications that I want to alter on location)...
CONCLUSION :
Anyway, as your main issue is about inline CSS, here's my 2 cents : inline CSS makes the code easily unreadable (at least for my taste), so why do it unless necessary?
You should always use a external .css files, because external style sheets enable you to change the appearance and layout of all the pages in a Web site, just by editing one single file!
If you will use inline css rather than external css in HTML pages that will take of much time to edit the changes so should use the external css files for smoother process.
I am struggling with how to write the correct CSS for positioning some data entry forms. I'm not sure what the "proper" way to do it is.
An example of what I am trying to create a layout for:
Last Name Middle Initial First Name DOB
||||||||||||| |||||| |||||||||||||||| ||||||||||
City State Zip
|||||||| |||| |||||||||
Basically I have my labels and the ||| are representing my form elements (text boxes, dropdowns etc). I don't know the proper way to create classes for these elements without just creating one time use classes that specify a specific width that is only for these elements.
Also, how do I get all of these elements aligned properly and multiple items per line? Do I need to float each element?
Would I do something like:
<div class="last-name">
<div class="label">
<label>Last Name</label>
</div>
<div class="field">
<input type="text" />
</div>
</div>
<div class="middle-initial">
<div class="label">
<label>Middle INitial</label>
</div>
<div class="field">
<input type="text" />
</div>
</div>
...
<div class="clear"></div>
last-name and middle-initial etc would all be classes that would be used once and floated to the left. I'm not sure if this is a good way to go about it or not? Is there a better way to do this kind of positioning with CSS so I can avoid using tables?
I would choose to mark up this particular layout using fieldsets:
<form>
<fieldset class="personal">
<label>
<span>Last Name</span>
<input type="text" ... />
</label>
<label>
<span>Middle Initial</span>
<input type="text" ... />
</label>
...
</fieldset>
<fieldset class="address">
<label>
<span>City</span>
<input type="text" ... />
</label>
</fieldset>
</form>
I'd float all the labels, make the spans or inputs use display:block, and most everything should fall into place.
IMO, this is tabular data.
I don't think it's necessarily a shame to use a <table> for this.
Related discussion: Proper definition for "tabular data" in HTML
It's not a bad thing to use table layout when the data you're laying out is a table! That's what you have here, imo: a table. So save yourself some grief and treat it that way. We've been so beat up by CSS purists and semantic-web lunatics that I suggest the pendulum has swung too far: now we tie ourselves in knots over-CSSifying our layouts. Or at least I do. I spend way too much time trying to avoid table layout.
The outcome is that a lot of my pages have to do browser checking. And the extra time (hey! the 80-20 rule again!) to deal with browser quirks is way more than it should be. I'd have saved a lot of time, and had more robust pages, if I'd just thought a little bit instead of going for the never-any-tables, always-pure-CSS solution every time. Table handling is solid like a rock in every browser with no problems and no frustrations.
Just my experience.
Here is my version without tables: http://jsfiddle.net/dy4bv/5/ (increase a little HTML part to fit all fields)
Maybe it will be helpful.
You could always use display:table and display:table-cell.
So using your example code above, you would do something like this
div.last-name, div.middle-initial{
display:table-cell;
padding:1em;
}
Example: http://jsfiddle.net/5LBgp/
EDIT
A bit more context to add to the answers from #Pekka and #Pete Wilson:
I foresee two big problems with styling this as a table
if you ever want to change the styling, you will need to hack away at the HTML, probably even redo it completely. Your code will be more future friendly if you use divs.
screen readers and such will likely make a mess of it, not understanding that the table is not really a table.
I am not a web developer, but i've had a crack.
http://jsfiddle.net/dy4bv/28/
This is based on #Samich's design, but instead of using a pile of divs with magic clearing divs interspersed, i've split the rows up into items in a ul. I use labels for the warm fuzzy semantic feeling. The styling is done by making the label-and-field divs inline-block, so they flow from left to right, but the labels and fields themselves block, so they stack vertically (this is a very crude idea, i know). As #zzzzBov pointed out, you can then use the field IDs to hang widths off.
No, that is not tabular data. Here's a test if you're ever wondering if something is tabular data: What are the table headers?
As for the layout, whenever I get something that I have trouble laying out, I back up and ask if the design is the problem and in this case I think the answer to that question is: yes.
Is that a user friendly design? no. It's difficult to scan and will be slow for users to identify errors if there are submit errors.
Luke Wroblewski has some great information on his blog and in his book Web Form Design: Filling in the Blanks about how to design human friendly forms.
Just to unload these 2 pennies...
The first column is "PropertyDescription" and the second column is "PropertyValue", while each row is a "Property" items -- voilà, a table!
Still prefer CSS, but this can certainly be classified as tabular data.
Is it sometimes bad to use <BR/> tags?
I ask because some of the first advice my development team gave me was this: Don't use <BR/> ; instead, use styles. But why? Are there negative outcomes when using <BR/> tags?
The main reason for not using <br> is that it's not semantic. If you want two items in different visual blocks, you probably want them in different logical blocks.
In most cases this means just using different elements, for example <p>Stuff</p><p>Other stuff</p>, and then using CSS to space the blocks out properly.
There are cases where <br> is semantically valid, i.e. cases where the line break is part of the data you're sending. This is really only limited to 2 use cases - poetry and mailing addresses.
I think your development team is refering to <br /> in place of margin spacing. To make empty space between elements, use padding / margin styling via CSS.
Bad use of <br />:
<div>
Content
</div>
<br />
<br />
<br />
<br />
<div>
More content...
</div>
Good use of <br />:
<style>
div {
margin-top:10px;
}
</style>
<div>
Content<br />
Line break
</div>
<div>
More content...
</div>
Generally, <br/> is an indication of poor semantic HTML. The most common case is using <br/> to declare paragraph separations, which there are much better ways to do it semantically. See Bed and BReakfast.
There are occasions where it is the proper tag to use, but it is abused often enough that people adopt a "do not use" mentality as to force better semantic thinking.
What was meant by your team was probably not to use <br>s to split between paragraphs.
For example :
<p>I am a paragraph</p>
<p>I am a second paragraph</p>
is the better way to do that, because you can then easily adjust the spaces between paragraphs through CSS.
Other than that, I can not think of anything speaking against line breaks as such.
Same concept applies to why we don't use tables for layout - use tables for tables and CSS for layout.
Use <br/> for break lines in a block of text and CSS if you want to affect the layout.
Specifying the layout directly makes it difficult adapting the site for different page sizes or fonts for example.
If you do this: <BR/> <BR/>
You will get diffrent layout on different browsers.
Deeper:
If you use <BR/> just for line breaks - ok.
If you use <BR/> as a line spacer - not ok.
I will generally always set appropriate margins and padding on elements using CSS - it's a lot less messy than loads of <br />s all over the place apart from being more semantically correct.
Probably the only time I would use a <br /> in preference to the margins and padding set by CSS, even if it's not strictly technically correct, is if it was an isolated incident where slightly more space was needed. If I'd got quite a large stylesheet and it didn't seem worth setting up an additional style just for that one occurence, I may use a <br /> as a one-off.
Like most things, <br />s aren't a bad thing providing they're used correctly.
I try to write my markup in a way that it's easily readable with CSS disabled. If you're just using BRs to add spacing, it's better to use margins and padding.
<br /> should be used for line breaks only, and not to apply style to a page. For example, if you need extra space between paragraphs, give them a class and apply the extra padding to the paragraphs. Don't spread out your paragraphs with <br /><br ><br />
They are to be used to represent newlines. Nothing more. Not to fill up space like as at the average geocities site. There is however only one case wherein they may be useful for other purposes than putting a newline: to clear the floats.
<br style="clear: both;">
Don't use three or more consecutive <br>s, that's a signal you're using them for stylistic purposes and no, you shouldn't.
Some would say a single <br> is enough and instead of two you should use <p></p>, but there are situations (e.g. screenplays) in which you want to introduce a longer pause without implying a change of topic or a new period starting, like a paragraph usually does.
They're fine, if used appropriately. For instance, you shouldn't use them in lieu of <p> tags or to create spacing between elements. You're probably doing something wrong if you ever have two in a row.
Here's an example how <br> can negatively affect styling (run snippet for visuals)
(note the misaligned button and odd space on the right):
button {
width: 70px;
height: 70px;
}
#arrows {
border: solid thin red;
display: inline-block;
}
#arrows span:first-of-type {
text-align: center;
display: block;
}
#moveUp {
margin: 0;
}
/* In the current case instead of <br> use display */
/*
#arrows span:last-of-type {
display: block;
}
*/
<div id="arrows">
<span>
<button id="moveUp" value="üles">↑</button>
</span>
<button id="moveLeft" value="vasakule">←</button>
<button id="moveDown" value="alla">↓</button>
<button id="moveRight" value="paremale">→</button>
<br> <!-- note the shifted button and odd space on right -->
<span>or move with keyboard arrows</span>
</div>
In HTML (up to HTML 4): use <br>
In HTML 5: <br> is preferred, but <br/> and <br /> is also acceptable
In XHTML: <br /> is preferred. Can also use <br/> or <br></br>
So use of <br> tag is perfectly valid HTML. But use of <br> is not recommended?
Main reason why not to use <br> is because it's not semantic tag & has no content inside. Its use can be avoided like,
<p>some<br>text<p>
can be marked up without <br> as
<p>some</p>
<p>text<p>
If you are using <br> other purpose like top-spacing etc. that can be achieved via CSS margin property.