So is there any difference in this:
<iframe src="iframe.html" width="100" height="100"></iframe>
and this:
<iframe src="iframe.html" style="width: 100px; height: 100px;"></iframe>
Both are supported in HTML5 and I wonder which one is better/reccomended? Any suggestions?
In that case I would suggest to use inline, like for
<iframe src="iframe.html" width="100" height="100"></iframe>
Because if css doesn't load properly or was disabled by user the container size will be the same.
And it will be good for avoiding a block jumping effect.
From the W3C:
"The separation of HTML from CSS makes it easier to maintain sites,
share style sheets across pages, and tailor pages to different
environments. This is referred to as the separation of structure (or:
content) from presentation."
However, there can be exceptions to this. If you have an "original version" of what the page should look like, you can leave the width and height attributes in the markup. You can then use a CSS stylesheet to override the original height and width. This can make sense in the case of an img tag. See the following question: Should image size be defined in the img tag height/width attributes or in CSS?
Like Dryden mentioned its really personal preference. I tend to stick with using class's in my style sheet rather than mixing in with html. Seems much cleaner to me.
However, putting styling at element level would mean that you cannot cache the CSS style rules separately. Usually putting styles in CSS files would allow the caching to be done, thus reducing the amount of load from the server each time you load a page.
Related
This link comes very close to my question, but seems to apply to syntax more than to actual rendered output:
I see that image height and width can be defined in the actual html img tag, in fact the way I read it it should be defined there. However, I am wondering about what matters when it actually comes to how the image is displayed. If I insert the following code
<img src="images/academia_vs_business.png" width="740" height="382" alt="" />
with no css stlying applied to the image, will it be rendered at it's native width and height?
If I do add css styling to that image, as in
img {
width: 400px
}
Will it overrule the width attribute of the html?
If I do not specify the height and width of an image in the html, is the only problem that I am not conveying the actual image size to a non-visual user agent or are there other problems (such as the browser can't allocate space for the imgs during page load).
Isn't specifying size in the html tags redundant if the css is going to change image size anyway?
I guess this all could be summed up as the best practice to place and size images and I would love to hear others techniques.
From the W3C website:
The UA may choose to honor presentational attributes in an HTML source document. If so, these attributes are translated to the corresponding CSS rules with specificity equal to 0, and are treated as if they were inserted at the start of the author style sheet. They may therefore be overridden by subsequent style sheet rules. In a transition phase, this policy will make it easier for stylistic attributes to coexist with style sheets.
See this answer to this question for more details
I know you can do this:
<img style="position: absolute;" src="test.png" alt="Test image" width="50" height="50" />
I don't use this first method, because I know external stylesheets are meant to seperate the CSS from the HTML code. And I like to keep it that way.
<img id="foobar" src="test.png" alt="Test image" width="50" height="50" />
Sometimes I use this method, but when I look at some of the professional HTML coding of big sites like Facebook, Instagram or Twitter I see that they use a lot of container divs, which makes me unsure whether I'm doing it right or not.
<div id="foobar">
<img src="test.png" alt="Test image" width="50" height="50" /> //use 'src' in place of 'sc'
</div>
I found that I mostly use this method for some reason I actually don't really know. But in this case I just add styling to the div and not directly to the img. Or when I do, I directly add styling to the img element by selecting it with #foobar img{ ... } in the CSS.
<div id="foo">
<img id="bar" src="test.png" alt="Test image" width="50" height="50" />
</div>
Usually I do it this way if a container is just necessary to get the job done, where I would have some styling on the img and some on the div#foo element.
I know there probably are more ways, but it's mainly these last two methods I'm not too sure about when to use them. I know there are other HTML elements out there but I just took a div and img for demonstration.
With that being said, I would like to know what are the pros and cons of each and which method should be a good practise?
Many unnecessary tags creates a problem known as "Tag Soup" (ref). This is an issue in hand-written HTML; your goal is to use CSS styling to the maximum potential and obviate the need for excess and meaningless tags.
When creating a document "properly", you ought to start from a document outline perspective. Imagine the page is a report, and it will be read top-to-bottom, and is left-aligned and simple in style. You design this hierarchy with a minimum of markup, making full use of the header, section, article, and footer tags. In the "old days", you would use divs instead.
Next, you apply style to affect the appearance, including the positioning of elements in the document relative to one another. This is where any non-semantic divs can be added, to facilitate positioning and organization within the box model. Again, you still try to keep wrapping or non-semantic tags to a minimum.
Taking all that into account, often, large sites will not be composed of a clean and strictly semantic document outline. Most often, these sites are assembled by code, constructing dynamic bits of content into the overall page. In these scenarios, more non-semantic wrapping tags are often involved as a byproduct of modular, self-contained code generating fragments of HTML. Further, web applications may necessitate wrapping tags to aid in dynamic content redrawing via AJAX or other javascript actions.
Where CSS comes in to play is also a factor in adding non-semantic wrapping tags. Because of CSS specificity (magic!), it is occasionally desired to have some extra "handles" you can use to get really, really specific on a particular tag combination.
The take-away is to write the cleanest, most semantic code you can manage in your project. Beyond being minimal and semantic, there isn't a "proper way", per se.
Further Reading
Semantic HTML - http://en.wikipedia.org/wiki/Semantic_HTML
How Important Is Semantic HTML? - http://www.vanseodesign.com/web-design/semantic-html/
About HTML semantics and front-end architecture - http://nicolasgallagher.com/about-html-semantics-front-end-architecture/
"What are the benefits of using semantic HTML?" - What are the benefits of using semantic HTML?
CSS Specificity: Things You Should Know - http://coding.smashingmagazine.com/2007/07/27/css-specificity-things-you-should-know/
In my opinion there is no absolute answer.It depends on your design.
If you have a lot of similar sections in your site that you want to style the same, you should use the div container (or other elements such as <nav>, <header> etc...).
The advantage of this method is that you can style other elements inside the section without giving each one a class attribute or id, thus, making you code cleaner and easier to maintain.
If you want to style a unique element I thing it's best to use the id attribute and add the CSS to this id.
Remember that id is unique, so, if you have two elements in the same page that will have the same CSS you'll have to duplicate your CSS code and it's never a good idea.
Main Reason for using style sheets is the ability to cache it in websites thus making load time faster once initially loaded. The reason why you see some elements with styling on the html itself maybe because its injected via server side code or by client side script. Where that part of code is literally invisible to FB developers and they would instead be seeing only a few lines of server code, so on their side it might not mean much as to how styling is done whether each element is addressed on style sheet or on html itself.
Another Reason might be when there is too much styling done with many classes on top of each other (nested classes) the final option may be to use it on the html element itself as it takes highest precedence and overrides any styles done by classes or any other form.
Many Reasons to use styles that way but generally its easier for developers to keep clean html/css/script and if possible separation but when things get complicated there comes a time when breaking the normal practice actually makes it easier...
I am curious to know, is it true that it is better to assign a class name to the <img> tag in the html file instead of writing it down directly into css file?
<div class="column">
<img class="custom-style" alt="" />
<img class="custom-style" alt="" />
<img class="custom-style" alt="" />
</div>
instead of
.column img{/*styling for image here*/}
I need to know is there any differences between of these in terms of web performance?
UPDATE:
I'm sorry, supposely the question is multiple <img> tags inside the .column div and all the images are using the same styling.
The short answer is adding a class directly to the element you want to style is indeed the most efficient way to target and style that Element. BUT, in real world scenarios it is so negligible that it is not an issue at all to worry about.
To quote Steve Ouders (CSS optimization expert) http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/:
Based on tests I have the following hypothesis: For most web sites,
the possible performance gains from optimizing CSS selectors will be
small, and are not worth the costs.
Maintainability of code is much more important in real world scenarios.
Since the underlying topic here is front-end performance; the real performance boosters for speedy page rendering are found in:
Make fewer HTTP requests
Use a CDN
Add an Expires header
Gzip components
Put stylesheets at the top
Put scripts at the bottom
Avoid CSS expressions
Make JS and CSS external
Reduce DNS lookups
Minify JS
Avoid redirects
Remove duplicate scripts
Configure ETags
Make AJAX cacheable
Source: http://stevesouders.com/docs/web20expo-20090402.ppt
So just to confirm, the answer is yes, example below is indeed faster but be aware of the bigger picture:
<div class="column">
<img class="custom-style" alt="appropriate alt text" />
</div>
It's just more versatile if you give it a class name as the style you specify will only apply to that class name. But if you exactly know every .column img and want to style that in the same way, there's no reason why you can't use that selector.
The performance difference, if any, is negligible these days.
Assigning a class name and applying a CSS style are two different things.
If you mean <img class="someclass">, and
.someclass {
[cssrule]
}
, then there is no real performance difference between applying the css to the class, or to .column img
Its depend. If you have more than two images in .column but you only need some images to have css applied then its better to add class to image directly instead of doing .column img{/*styling for image here*/}
In performance aspect i thing apply class to image is better because by doing so css will not look for possible child image.
I think the Class on img tag is better when You use the same style in different structure on Your site. You have to decide when you write less line of CSS code and HTML is more readable.
Often times I see something like this:
<body>
<div class="container">
</div>
</body>
Why not just do:
<body class="container">
</body>
You are perfectly free to do any of the following:
add a class or id attribute to the body element;
directly apply CSS to the body element, with or without class or id attributes; or
directly apply CSS to the html element, although without the class or id attributes and with some important caveats.
Any of these are perfectly legitimate uses of CSS and HTML.
Why <div id="container"/>? Through the years, many CSS techniques have employed arbitrary container elements for conceptual simplicity, to avoid certain cross-browser inconsistencies or because they were simply too complex to be achieved otherwise. A couple of more subtle reasons include that in older browsers, one could not apply CSS to the html element directly, and there were (and are) certain unusual or restricted properties for those elements—often for obvious reasons. (They were sometimes described as being "magic" for this reason.)
These all conspired to create a situation where to achieve almost any moderately complex layout, it was inevitably much easier to just start out with a squeaky-clean container element. Though the practice started as a means to an end it soon became just part of the scenery, and now many developers don't think twice about adding that sprinkling of extra markup.
No, there is nothing that says you can't add a class to the body.
Attaching a class to the body is actually quite common in various CMSes and is very handy for theming or styling specific pages.
From looking at your example, if you just want to use the body as a container, why even bother with the class? There should only be one body element, so just call that in your selector.
Walter, it may make sense if you needed to apply a slightly different subset of styling to a page with a custom body tag.
Using a wrapping div is usually for some presentational reason and make not make sense semantically; if you don't need it for your project, don't use it. Sometimes only using the body tag to contain the page is too inflexible for some layouts, and as Jordan says some old browsers cannot apply CSS to the root element.
Background: I need to have an inline element to which I can apply width and height via CSS.
AFAIK, img is the only way to have this behavior, currently.
I would rather not have the image point to a transparent pixel GIF on the server. It may be cached, but browsers queue it nevertheless, slowing down overall page speed. Other clients might not be caching at all.
PS No, floating div is not sufficient, it behaves differently from inline elements.
EDIT Sorry, I should have inserted the term "cross browser" somewhere. It must at least be working for FF≥2, IE≥7 and current Safari.
You could use the "data:" URI scheme to embed an image.
Other replaced elements might also work. Setting display to "inline-block" might also be worth looking into.
Can you set:
display:inline-block;
width:50px;
height:10px;
IIRC, images are an "inline block" element, thus they can be rendered inline in text strings, but still have block-like properties.
I guess it will be valid in the W3C validator sense, because the validator does not check whether the link is a resource or not.
However, valid in the broader sense, I would say it is not. An src attribute is required in the IMG tag, and I would say must point to a valid image resource.
I find outis`s "data: URI" idea the best way.
If that doesn't work, a transparent image is your best bet. It's one call, it's a few bytes at best, and will be cached by most clients.
Using "about:blank" as src will cause IE to display red X-boxes. This line of CSS prevents this (in IE 8+), but it's still all a bit hacky:
img[src="about:blank"] {visibility:hidden}
You can accomplish the same thing with a tag.
<p style="height: 400px; width: 400px; background-color: #ffcccc;"> </p>
Height and width are settable. This should be across the common browsers, however I have not been able to test Safari or Chrome using it.
Use a <span> tag with a in it - totally valid - then set it's width and height in CSS, also apply display: block;
Using an empty <span> tag means it will be ignored by screen readers and it won't show up as a broken image when styles are disabled.
It'll also not use up any more bandwidth.
:-D