Is it more efficient to add a margin to an HTML element or to insert a <br/> somewhere around it?
I wonder how both ways differ in the type of page rendering and, of course, how they differ in speed.
Adding a margin to an element, makes it much more efficient to work with. Just call the class or element, which will automatically add the margin.
A line-break might be forgotten now and then.
As for the speed: No experience in performance, but as you don't have to wait for the css, a line-break might be some nano seconds faster...
But then again, if you are using multiple elements which need some whitespace below adding a margin to it might be better, as your amount of code-lines will reduce (less kB).
It depends on what you want to do. If you are working with an element that is a part of a layout, then you MUST use margins/paddings. You can use <br /> to make a little correction inside the text for example, but my way is to create a CSS class for <p> or other elements like that and simply use it. You can make a classes even for <span> elements to show it in some proper way. This is how I deal with this kind of issues. I think that using a lot of <br /> isn't smart.
And what others say, margin gives you more control.
Related
I am just learning to code and have been looking everywhere for an answer on this one and for some reason cannot find anything.
I noticed that it seems to be common practice to put an image inside of a container or wrapper. For instance, rather just having:
<img src="url"/>
Everyone seems to be in agreement that it needs to be this way:
<div class="container">
<img=src"url"/>
</div>
What is the purpose of wrapping the img inside of a div in this way? It seems to have something to do with "responsive design", but I'm not 100% sure. Is it just so that we have something to size the image relative to, rather than using definite sizing like pixels on the image selector in css? The more I think about it as I write this, the more it seems to be the right answer, but I'm not sure if there's something else I'm missing on this one.
Any insight would be very much appreciated. Thank you.
unfortunately there is no "single" correct answer for this.
There can be many reasons as to why one would wrap any element in another element, it is not specific to <img /> tags :)
In your question I read something like this (converted to real world example):
I see that it is common practice to put a frame around a photo.
Where the "frame" would be the wrapper element, and the photo would be the <img />.
Looking at it this way might make it seem more clear. The photo is the most important part, technically speaking you don't need a frame to show the photo. If you have just a photo, you won't be able to hang it on your wall without damaging it by driving a nail through the top or applying some tape. If you have a frame though, you can make that photo take up any amount of available space within it, you can use the clip to hang it on a wall and if you put multiple photo's in the frame, you can move them all at once since they are in the same frame.
The reason most people put that image in a "container" is because they get some sort of advantage out of it over using an image alone, this could range from aspect-ratio locks to relative positioning. In some cases, a wrapper is required to achieve certain (notably more complex) animations as well.
Websites are built out of "logical" pieces that, together, form a website. The individual pieces are all "frames" that "flow" together to create any page layout you see on every website.
It is merely a structural way of thinking, if the purpose of that image was to be used as a background image for the entire page, a better alternative would be to use CSS background-image property on the <body> tag and not use the image at all. But if the image is meant to be part of a smaller part of your website, it should probably be contained as appropiate.
This answer is in no way a guide to go by, nor a ruleset or anything like that, they are just the thoughts of another developer. There are countless reasons for wrapping an element and this answer doesn't even cover 0.0000001% of those cases. I'm just saying -- there's no specific reason to do or don't here.
I see this being done on websites (ex: http://www.abookapart.com/):
.left {
float: left;
}
<div class="col two left" />
Is the above good practice? I thought it was generally frowned upon to create classes that describe style. If I wanted the above div to float right at a later date I would have to go into the markup and change left to right. No better then adding a style attribute to the element it would seem.
You're right. Most developers avoid class names like "left" or "blue" for that exact reason. Other than the class name, I don't see anything wrong. I would include that float in the "col" class and then just override it with "right" later on if need be.
I've seen it become useful where multiple people are editors for a single website, and you don't give them all full html access.
By setting up classes of styles that they're allowed to use, you can allow them a certain amount of style control without giving them the power to mess everything up.
It's really down to personal/team choice.
I've always preferred this technique as I favor convention over style, I like my concerns separated and I dislike ambiguity.
if I see a div like this:
<div class="clearfix left bordered">
...
</div>
I like the fact that its intent is clearly emphasized and won't make me have to dive into the CSS file to find out what it means.
But based on your example above, if you did go down the more declarative route:
<div class="importantTextDiv">
...
</div>
On the one hand, you have to investigate the CSS file to determine its properties (or run it and inspect the element in your Firebug equivalent) but should you choose to change it, you don't need to make a source change, or change whats emitted from your server side language.
To me, both situations are a pain, but in my experience, changing a div between float:left and float:right is the kind of thing you'd have got finalised before a final deployment anyway.
My answer ? there's no technical reason to prefer one path over another, choose which one feels more comfortable!
Should I use <br /> and in HTML to position elements, or should I just use CSS display:inline with padding/margin for positioning and all styling? what are pros and cons with both?
Use <br> to represent a linebreak inside a block element and use to represent a non-breaking space inside an inline element. Nothing more. For the remnant just use CSS the smart way with help of under each the display, float, padding and/or margin properties.
<br /> has its uses, but if you find yourself using   a lot, I would consider finding better ways to align things. is just ugly and clunky.
If it's tabular data, use a table. Your life will be much happier.
If it's not tabular data, use css, as BalusC suggests.
Ideally you should position everything with css, and only use <br /> (line break) and inside <p>s.
But this isn't an ideal world ;)
<br /> Can really go either way. But if you find yourself using it to adjsut paragraph spacing orsomething like this then you really have to ask yourself "is there a reason why im using breaks instead of applying a class to adjust margins?" on the other rarely if ever makes any kind of sense outside of a paragraph (<p />) and half the time theres not much use for it ther any how as using text-indent is preferable for indenting the first paragraph and much to the chigirn of Editors everywhere im completely opposed to the double space prepending of senetences on the web - as far as im concerned that is a print only thing.
In HTML5 you also have the new
http://html5doctor.com/element-index/#w
the answer is not black and white, it depends on your content, sometimes it should be and in some cases the so the content will be on a single line.
if you want it as block you can use
Using CSS margin and padding will give you greater flexibility to make adjustments later on.
I think the ideal is to use CSS purely for the layout and presentation, and HTML for the content. But let's say, the company wants to change a "Related articles" box from the bottom of the page to the top of the page. In such case, won't using CSS alone be not an ideal solution, but is better to alter the HTML as well? So as things are right now, HTML still takes a role in the page layout and presentation? Thanks.
Things still appear in the same order as they are in the html - it's not as restrictive as that as we can use absolute and relative positions, but those are undesirable - it's better to use to dom flow to handle placement, and that means yes, you should move the node in the html.
As Jason said, CSS is for styling the content, the content itself and its order is defined by the data (html), as order is necessary for the context of information, so it lies firmly in the 'data' part of what we do rather than the 'display'
EDIT:
I should say this: If you want your data to be totally independent of the display, you should consider defining your pages as xml only and using xsl to define the layout. xsl combines with css to completely abstract the display away from the data.
It does on two levels:
Firstly, the order of elements is still important. CSS floats are used a lot for layout but they also require elements to be in a certain order to get things in the right place. For example, lets say you have two buttons:
<input type="button" value="Click Me">
<input type="button" value="No, Click Me!">
These are next to each other. Lets say someone asks you to move the second button to the far right. This is how you do it:
<input type="button" value="No, Click Me!" style="float: right">
<input type="button" value="Click Me">
If you don't do this, the second (floated) button will appear below the other.
The second way HTML is still important is that there are still things that you need HTML tables for that can't be done in pure CSS at all, in a browser-compatible way (meaning IE6 support generally) or easily. This isn't something the pure CSS zealots like to hear but, like it or not, in the real world it's still true.
This is especially true with HTML emails. If you thought browser support for CSS was bad, mail program support is so much worse. Generally speaking you avoid CSS altogether with HTML emails and just pretend like its still 1999.
HTML still defines the hierarchy for elements.
HTML divides your page in logical sections. CSS then applies a certain look/feel/style to those sections.
If you want to change your page layout to include a section inside another one, you have no choice but to modify your HTML because HTML has a role on page layout.
You can actually move blocks around using nothing but CSS. The compromise always boils down to how good your CSS skills are and how much compatibility with older browsers you're after or care about. There are limits to what CSS can do, so yes, HTML definitely still has a role to play.
it is possible to change the "source order" of divs or use css to change positions. But if its more practical to just change the html, then there's no other way round it. At the end of the day, if its more important content then the source should reflect it for semantic reasons.
I've been wondering if I can use <p> </p> (just space in paragraph) instead of <br />
Because I love to keep my code semantic and thought if this is right has been bothering me for a while now. I have seen WYSIWSG editors (TinyMCE) use this, but I still rather ask then do it wrong.
That is not "semantic", an empty paragraph is something that more or less cannot exist, semantically. It contains no information, i.e. no semantic content. All it does is change the visual layout, i.e. the presentation.
You're far better off using styling to change the margins, borders or padding to achieve the effect you're after.
What's wrong with using the margins of the paragraphs for vertical-spacing instead?
<p>Hello World</p>
<p>This is much cleaner than using empty tags with non-breaking spaces.</p>
The right way to do it is with CSS: use the margin-top or margin-bottom.
<p> </p> is pretty horrible... I'd rather see <br> than that (even though it may be less "correct").
<p> </p> is not semantic, so I don't know how that helps you.
You should set the space between the paragraphs with css.
I advocate wrapping items in block-level tags, such as divs and ps. This way I don't need either. If you want to space out elements, you should be using margins. You can be more accurate with margins anyway.
In a situation where you're forced to have a line break, use <br />: it, unlike empty paragraph tags, actually does mean 'line break'. There's almost always a better way to do things though.
It's HTML. You can use whatever it wants as long as you're sure it will render the way you wanted on all the browsers you're gonna use. I don't understand what you mean by "keep my code semantic" so I'm not sure what your issue with <br> is. But if you're talking about formatting and such, turn to CSS.