Why do I get the following message in Visual Studio when I use the <u> element?
"Element 'u' is considered outdated. A
newer construct is recommended"
Has it aged?
The underline tag has been deprecated as of HTML4. The W3C reference can be found here. The reason is that visual styling does not belong in tags, but should be moved to style-sheets.
You can use the text-decoration: underline style instead:
<span style="text-decoration: underline">some underlined text</span>
To remove underline, use text-decoration:none to disable underlining.
It's because the W3C decided to deprecated it.
It's because all layout and design should be done using CSS. In HTML ideally only structure should exist.
<u> only adds a specific font decoration to the text, but no structural information.
Because according to w3c is has been depreciated. Read here
Also any style/formatting should be the responsibility of css but I am sure VS follows the w3c guidelines.
The tag is deprecated along with other text formatting / style elements.
The 'in' thing to do is to use correct markup and apply styling with stylesheets.
As others have said, <u> (and similar elements) have been deprecated in the latest versions of web standards because of a general belief that style and markup should be separated.
And, as others have said, you can make your HTML valid by using a span with inline styling. Really though, that's not any better. Is it valid? Yes. But it buys you nothing else over simply using <u> tags in the first place.
The best semantic solution depends on the context. Why are you trying to insert an underline in text? There are three use cases I can think of: headings, links, and text emphasis. In each case you should be applying css from a stylesheet to the relevant semantic element: <h1-6> for headings, <a> for links, and <em> for emphasized text. If you need variations of each, apply css classes and ids as necessary.
<u> is part of a family of elements that were deprecated. <b> and <i> were replaced with <strong> and <em>, respectively, while requires using css for effect.
The reasoning is that HTML shouldn't decide that something is underlined or bolded, that type of information is supposed to be a part of the style, and thus is a perfect candidate for a stylesheet.
Not just HTML4, <u> is considered obsolete in HTML5 too.
Interestingly, <b> and <i> are kept as conforming. You may try to argue in their mailing list, or just keep using the tag as you like before. Browsers won't pull out its support and you are fine.
I remember the reason behind the decision of pulling <u> out is about its lack of uniform semantic meaning or something like that. At least when you see bold text you know you should read it louder.
there can be meaning that will be lost to some minor extent with CSS reference over the 'u' tag.
One minor but annoying result is the ACCESS key to input controls.
<u>F</u>irst Name <input ... AccessKey="f"..
OR
<span class="ul">F</span>irst Name
The first method, using a tag truly indicates a meaning where a random, user-assigned class name does not. TAGS are fixed - class-name is arbitrary.
As far as standards, it's a distinction without a difference. The decision is arbitrary, subjective and capricious, handed down from the supposed experts and purists.
Formatting with HTML rather than CSS is considered deprecated these days. Anyhow, if you ever have issues with standards compliance rejecting your in-line formatting, follow the following easy search and replace rules:
<b></b> Replace with <span style=font-weight:bold></span>
<u></u> Replace with <span style=text-decoration:underline></span>
<i></i> Replace with <span style=text-font-style:italic></span>
<font face=font,otherfont size=number></font> Replace with <span style=font-family:font,otherfont;font-size:replace-with-keyword></span>
<s></s> aka <strike></strike> Replace with <span style=text-decoration:line-through></span>
Keywords for font-size: xx-small, x-small, small, medium, large, x-large, xx-large
Roughly the same.
If you will just follow through with these easy replacements, you will experience...!
All the joys of standards compliance! (Bragging rights.)
None of the benefits. (This CSS isn't going to get modified from a single <style>.)
All the pain of excessive standardization (Wait, which formatting rule does this </span> tag undo again? Shit.)
More bandwidth consumption! (The price of progress, as soon as someone clues me in on how this helped anything.)
Decreased browser support! (Y'know those folks who still use old browsers or minimalist browsers like LYNX, Links, w3m, OffByOne, etc.? Eh... who cares?)
Oh yeah...
Addendum: More seriously, because these days many standards purists just have a hard-on for pure CSS. Most of the support behind CSS obviating regular markup generates simply from it being modern so you should get with the times. Other support comes from the notion that CSS is inherently more maintainable and completely overlooks unmaintainable messes like what I suggested above.
It's not that I have anything against CSS. The point here is that a lot of people preach the standard excessively and will condone it even when it's used in wildly inappropriate ways. The notion of replacing regular HTML tags with inline formatted CSS as I mentioned is genuinely viewed as progress by far too many advocates of CSS. They seem to view upholding the standard, the pattern, the design rule, as being some kind of inherent good rather than rationally looking at it. Inline formatting has its place, and I think using regular HTML tags for it is fitting and much more readable.
Those adherents are like the folks who tell you gotos are evil and you should never, ever use them. The ones who will look at a regular stack-esque wind and unwind and instead use an indented if statement clusterfuck going ten layers of indentation and repeated code deep. And, they will genuinely view their version as more readable and maintainable even though by any sane standard it clearly isn't. For more on that tangent: http://kerneltrap.org/node/553/2131
Related
First of all, I realize that styling in HTML should be handled by CSS, and I don't want to change that.
I just want a solid tag I can use for underline, a tag that is meant for underlined text, or one that makes sense to use as such. Then I can style it with CSS.
Now where is that tag?
Why is strong, b, em, i etc. perfectly fine (and often auto-styled in browsers), but underlined is the forbidden fruit?
I would hate to write
<span style="blabla: underline">some underlined text</span>
OR <span class="underlined">some text</span>
when I can just use
<u>hello</u>
and style it?
The u element was meant for underlining, ever since HTML 3.2. HTML 4.01 frowns upon it by “deprecating” it, and HTML5 proposes to redefine its meaning in an obscure manner. Yet, in reality, it works in all browsers, and will keep working, and has the exact effect of underlining.
Whether you should underline anything but links on web pages is a different issue. So is the question whether you should think in terms of logical structure rather than visual rendering.
Underlining text is generally a bad idea because it should be exclusively reserved for links. Users just generally expect to be able to clock on underlined text and have something happen.
That said, there is one main exception I can think of:
Price: <del>£12.34</del> <ins>£9.87</ins>!
Most, if not all browsers will render the new price there with an underline, and people will understand it to be an insertion.
I think the whole issue is better approached if we try to understand what the HTML spec writers are trying to accomplish.
On the early days, HTML was basically the only tool to create hypertext documents so it tried to provide all the necessary stuff. As the web grew up it soon become obvious that this all-in-one solution did not scale. Mixing content and presentation didn't provide full control on either. So two steps were taken:
A new language was created to take care of visuals
HTML itself was cleaned up to focus on content definition
The problem with underline is that it doesn't really have any meaning by itself. It will have a meaning if you assign it one in your app context (you can decide, for instance, that underline text will be used for book authors in your on-line library catalogue). So when the guys at W3C created HTML tags for several content types (titles, abbreviations, dates...) they simply didn't consider underlining: it was deliberately outside the language scope. There's no HTML tag for "underline" for the same reason that there's no tag for "red circle" or "uppercase Comic-Sans text".
Of course, in fact there is a <u> tag but underline is only a serving suggestion because the important part is the semantics—like printing <h1> with a large font.
It is not forbidden , but a better practice not to use it ,as underline tag is deprecated in HTML 4 http://www.w3.org/TR/REC-html40/present/graphics.html#edef-U so won't validate.
Underline an element is more a style quetion. So, it's better to give a class like "underline_style" and in the CSS give the correct rules.
The u element you can still use for underlining but because it's more complex than b, i,strong and em you will need CSS to style it in detail. Underline has style and color property which is not the case with other mentioned elements. You have more on this topic here.
I've always used <b> tag to bold something, because that is the way I was taught to do it a long time ago. But now my IDE always informs me that <b> is deprecated and to use css style. Assuming by that they want me to use <div style="font-weight:bold;">Bold Text</div>. How vital is this message that my IDE is giving me? Should I go back and change all my<b> to style?
Below is an example of both situations. Could someone explain the difference's between both and why <b> is deprecated now?
<b>Bold Text</b>
Vs.
<div style="font-weight:bold;">Bold Text</div>
Would <b> be better because if someone has css turned off on the browser, it would still be show correctly?
The correct question is: "What markup best describes my content?"
Let's start with the <b> tag (which is not deprecated):
The b element represents a span of text to be stylistically offset
from the normal prose without conveying any extra importance, such as
key words in a document abstract, product names in a review, or other
spans of text whose typical typographic presentation is boldened.
...
You should not use b and i tags if there is a more descriptive and
relevant tag available. If you do use them, it is usually better to
add class attributes that describe the intended meaning of the markup,
so that you can distinguish one use from another.
...
It may help to think of b or i elements as essentially a span element
with an automatic fallback styling. Just like a span element, these
elements usually benefit from class names if they are to be useful.
http://www.w3.org/International/questions/qa-b-and-i-tags
By comparison, <strong> has a more specific purpose:
The strong element represents a span of text with strong importance.
http://www.w3.org/TR/html-markup/strong.html
For example:
<p><strong>Warning.</strong> Here be dragons.</p>
Here we emphasize the word "warning" to stress its importance.
But not:
<p><strong>Item 1:</strong> Foo, bar, and baz.</p>
"Item 1" isn't meant to be stressed, so <strong> is the wrong tag. Furthermore, it's possible that the whole structure could be better represented.
If the meaning of the text has strong importance, <strong> is appropriate (just like this line).
Perhaps you just want a thicker font for style purposes and the text has no particular meaning. In that case, neither <strong> nor <b> may be appropriate.
<span class="product-name">Hello World</span>
.product-name { font-weight: bold; }
In all cases:
Use the markup which describes the content.
Do not use inline styles (use an external stylesheet).
Do not name styles based on their visual representation (e.g. naming a style "bold" is a poor choice)
Would <b> be better because if someone has css turned off on the
browser, it would still be show correctly?
No. Use the correct markup for the job. It's fairly unusual for someone using the visual representation of your site to willingly disable the stylesheet, but non-visual consumers care primarily about the structure of your document. A "non-visual consumer" could be a search engine parsing your content or a screen reader application.
Additional Reading:
http://www.w3.org/TR/html51/text-level-semantics.html#the-strong-element
http://www.w3.org/TR/html51/text-level-semantics.html#the-b-element
It's not "vital" if the code still works. Though it would conform to current standards which will give the code a longer future.
The difference is that using CSS separates your styling from your content. <b> is a style, nothing more. And it tightly couples that markup to that style. The separation allows you to emphasize the markup in other ways instead of always using a bold font.
Would be better because if someone has css turned off on the browser, it would still be show correctly?
No, because if the user wants to disable styling then your <b> tag undermines that, because it's mixing styling with content.
You should be using <strong> in place of <b>. You could use styles (text-weight: bold in a separate sheet) if a particular group of text was always going to be bold, and you didn't (or couldn't) want to use <strong> for whatever reason. But I would only go that route if you already were applying other styles to that same element.
If you are talking about SEO
Use <strong> should be SEO friendly too... (focus on the keywords)
and it's important !
I find that using <strong></strong> is the better approach than using <b> or inline styles.
I am working on some legacy PHP code that holds a ton of in-line styling, one of our objectives is to leverage CSS so the code will be cleaner. One thing that got me thinking is the use of native html elements VS the use of CSS, such as bold and italics.
For example,
<b>this is foo</b>
Or in css
.bold { font-weight: bold;}
<span class="bold">this is foo</span>
While these two do the same thing, which one do you guys prefer and why?
Always use HTML tags when they can add meaning, structure, or semantics to your content. If you want to write the sentence I <strong>love</strong> cheese (where the word "love" should carry particular emphasis), the <strong> tag is the correct choice. CSS is absolutely not an acceptable solution.
Always use CSS when you are changing the visual appearance of your page. The title heading on your page is a <h1>...</h1> (end of story), but you can make it bold or not, big or not, purple or not using CSS.
A good acid test is to imagine how a screen reader will interpret your page. If you view the page without any stylesheets attached, it should ideally show your content in a linear, minimal fashion, that is in fact quite ugly, but that conveys all the content you wanted to include on the page.
I think you're looking at a false dichotomy, <b> or .bold. Given the choice between these two, I'd probably choose stylised spans over use of the <b> tag, but that's purely to divorce presentation from mark-up.
There is, though, the strong tag, which is more semantic than the use of span.bold, and less purely-presentational than b, although it does, obviously, imply a presentational choice. This is my preferred choice over-all.
Instead of using bold (or span class=bold for that matter), you probably should consider the semantics of what you want. Is the text important? Use strong or em (emphasis). This helps on things like search engine visibility as well.
You should choose the tag based on semantics - afterall, CSS can be used to style them to look like anything.
W3C recommends keeping your HTML as semantic as possible. So you should use <strong>, <em> and other HTML tags instead of various <span>s with classes on them.
As a matter of fact you could have all your HTML code with just <div>s, but that doesn't mean you should do it.
As for <b>, <i> and other tags with no meaning, you should discontinue them.
IMHO, CSS is the way to go.
Reasons :
1 - You should not mix your styling code with your content.
2 - Easier to customize/change your final representation in required, or can represent them differently using different css.
3 - Separation of responsibilities in terms of who maintains what
I prefer using the span because it is infinitely stylable. The bold tag is always bold unless you override it, and then it's useless anyway.
Semantically, you should use html to describe the emphasis used here. The <b> is obsoleted and <strong> should be implemented to describe the text. In addition, the css should reflect the styling for the selector:
strong { font-size: whatever; }
<strong>this is foo</strong>
There are stuff like bold letters that I prefer to still leverage to html, SEO mainly. But if you combine more than one stile i.e. Bold and Italic it would be good to have an style called accent maybe. But trying to keep style out of html would make you happy (Less stuff to maintain) and your users happy (less code to transfer, they would access slim pages).
As we are moving on to HTML5, there are some tags which now hold a very least importance that it did in the past.For example <dl> the defination list, I dont remember the last time used this tag.
And not only this, but there are tags which have a better and more efficient versions or just clear redundancy like <strong> and <b>, <basefont> and <font> etc.
In your Opinion, which are the tags that as a developer you can live out with?, and Which are the tags which can be ignored? because we have a better version.
B and STRONG are not the same thing, and neither are I and EM.
EM means that the text shoud be emphasised. This thus says something about how the text should be interpreted, and this is understood by screen-readers (text-to-speach), etc. It has a logical meaning. I, on the other hand, says nothing about the semantics -- it simply tells the HTML renderer to render the text in italic. Hence, in text, to make an emphasis, use EM. If you for some reason need a bit of text to be in italic without this implying that the text should be emphasised, then you can use I.
The same things applies to STRONG and B.
However, I really dislike FONT, because it says nothing about the semantics. Use Hn for headers, EM for emphasis, CODE for code, etc. If you lack some tag for some context, define a CSS rule like
<p class="footer">...</p>
or
<p>This is <strong class="extraordinaryEmphasis">extremely</strong> important.</p>
It was suggested I make this an answer, so here is an excellent page that discusses which tags and attributes should be avoided in HTML5 pages, and why, though he doesn't include elements like the blink tag.
http://www.html-5.com/avoid/
STRONG and B have distinct semantic meaning now. There was a lot of effort to clean up semantically-ambiguous elements like that. Even HR got some attention.
I use DL all the time, personally. It my workhorse KeyValuePair type. I sometimes find myself wishing it had more rigorous semantics, but then other times I'm thankful for its flexibility in allowing me to define its semantics contextually.
I suppose it depends on your definition of 'useless', which I take to mean 'having no practical use whatsoever'. I don't really know of any element in HTML5 I could say that I'll never use under any circumstances.
P should be abandoned. No Joke. It creates artificial breaks in flowing text that can be better reproduced with a line break. Is there a P tag on a typewriter? What follows is that it becomes a "text container" that we've become dependent on for no good reason. Paragraph is a stylistic flow marker only. At most it should be a singleton tag.
In CSS, I use it simply as a text-area container, a designation which is similar to SPAN except in block form. The P should really be a TEXTSPAN tag that can be parent to multiple spans, but not to itself. We are often forced to store some representation of P in databases, which then are impossible to reconstruct for display. Again, a double line break is much more appealing and universal.
:-)
<code> is useless. Unless maybe you a perl one-liner fan. It should have been a semantic way to create a <pre> block - that would have been useful.
<embed> is useless. It is redundant to <object> and less capable than <object>
<small> is useless. It has no semantic meaning and should be done with CSS.
Those are my opinions of the three most useless tags that made it into the HTML5 spec.
I think that anything that indicates something that should be done in CSS is probably something that should be avoided. This includes
<b>,<strong>
<i>,<em>
<center>
<u>,<strike>
My least favourite has be to <font>, as it has absoutely no meaning, and should, in all instances be replaced with a tag.
Personally, I think it's also good to avoid HTML attributes that should be done with CSS such as "color" and "border".
What is the correct way to make text italic? I have seen the following four approaches:
<i>Italic Text</i>
<em>Italic Text</em>
<span class="italic">Italic Text</span>
<span class="footnote">Italic Text</span>
<i>
This is the "old way". <i> has no semantic meaning and only conveys the presentational effect of making the text italic. As far as I can see, this is clearly wrong because this is non-semantic.
<em>
This uses semantic mark up for purely presentational purposes. It just happens that <em> by default renders text in italic and so it is often used by those who are aware that <i> should be avoided but who are unaware of its semantic meaning. Not all italic text is italic because it is emphasised. Sometimes, it can be the exact opposite, like a side note or a whisper.
<span class="italic">
This uses a CSS class to place presentation. This is often touted as the correct way but again, this seems wrong to me. This doesn't appear to convey any more semantic meaning that <i>. But, its proponents cry, it is much easier to change all your italic text later if you, say, wanted it bold. Yet this is not the case because I would then be left with a class called "italic" that rendered text bold. Furthermore, it is not clear why I would ever want to change all italic text on my website or at least we can think of cases in which this would not be desirable or necessary.
<span class="footnote">
This uses a CSS class for semantics. So far this appears to be the best way but it actually has two problems.
Not all text has sufficient meaning to warrant semantic markup. For example, is italicised text at the bottom of the page really a footnote? Or is it an aside? Or something else entirely. Perhaps it has no special meaning and only needs to be rendered in italics to separate it presentationally from the text preceding it.
Semantic meaning can change when it is not present in sufficient strength. Lets say I went along with "footnote" based upon nothing more than the text being at the bottom of the page. What happens when a few months later I want to add more text at the bottom? It is no longer a footnote. How can we choose a semantic class that is less generic than <em> but avoids these problems?
Summary
It appears that the requirement of semantics seems to be overly burdensome in many instances where the desire to make something italic is not meant to carry semantic meaning.
Furthermore, the desire to separate style from structure has led CSS to be touted as a replacement to <i> when there are occasions when this would actually be less useful. So this leaves me back with the humble <i> tag and wondering whether this train of thought is the reason why it is left in the HTML5 spec?
Are there any good blog posts or articles on this subject as well? Perhaps by those involved in the decision to retain/create the <i> tag?
You should use different methods for different use cases:
If you want to emphasise a phrase, use <em>.
The <i> tag has a new meaning in HTML5, representing "a span of text in an alternate voice or mood". So you should use this tag for things like thoughts/asides or idiomatic phrases. The spec also suggests ship names (but no longer suggests book/song/movie names; use <cite> for that instead).
If the italicised text is part of a larger context, say an introductory paragraph, you should attach the CSS style to the larger element, i.e. p.intro { font-style: italic; }
<i> is not wrong because it is non-semantic. It's wrong (usually) because it's presentational. Separation of concern means that presentional information should be conveyed with CSS.
Naming in general can be tricky to get right, and class names are no exception, but nevertheless it's what you have to do. If you're using italics to make a block stand out from the body text, then maybe a class name of "flow-distinctive" would be in order. Think about reuse: class names are for categorization - where else would you want to do the same thing? That should help you identify a suitable name.
<i> is included in HTML5, but it is given specific semantics. If the reason why you are marking something up as italic meets one of the semantics identified in the spec, it would be appropriate to use <i>. Otherwise not.
I'm no expert but I'd say that if you really want to be semantic, you should use vocabularies (RDFa).
This should result in something like that:
<em property="italic" href="http://url/to/a/definition_of_italic"> Your text </em>
em is used for the presentation (humans will see it in italic) and the property and href attributes are linking to a definition of what italic is (for machines).
You should check if there's a vocabulary for that kind of thing, maybe properties already exist.
More info about RDFa here: http://www.alistapart.com/articles/introduction-to-rdfa/
TLDR
The correct way to make text italic is to ignore the problem until you get to the CSS, then style according to presentational semantics. The first two options you provided could be right depending on the circumstances. The last two are wrong.
Longer Explanation
Don't worry about presentation when writing the markup. Don't think in terms of italics. Think in terms of semantics. If it requires stress emphasis, then it's an em. If it's tangential to the main content, then it's an aside. Maybe it'll be bold, maybe it'll be italic, maybe it'll be fluorescent green. It doesn't matter when you're writing markup.
When you do get to the CSS, you might already have a semantic element that makes sense to put italics for all its occurrences in your site. em is a good example. But maybe you want all aside > ul > li on your site in italics. You have to separate thinking about the markup from thinking about the presentation.
As mentioned by DisgruntledGoat, i is semantic in HTML5. The semantics seem kind of narrow to me, though. Use will probably be rare.
The semantics of em have changed in HTML5 to stress emphasis. strong can be used to show importance as well. strong can be italic rather than bold if that's how you want to style it. Don't let the browser's stylesheet limit you. You can even use a reset stylesheet to help you stop thinking within the defaults. (Though there are some caveats.)
class="italic" is bad. Don't use it. It is not semantic and is not flexible at all. Presentation still has semantics, just a different kind from markup.
class="footnote" is emulating markup semantics and is incorrect as well. Your CSS for the footnote should not be completely unique to your footnote. Your site will look too messy if every part is styled differently. You should have some visual patterns scattered through your pages that you can turn into CSS classes. If your style for your footnotes and your blockquotes are very similar, then you should put the similarities into one class rather than repeat yourself over and over again. You might consider adopting the practices of OOCSS (links below).
Separation of concerns and semantics are big in HTML5. People often don't realize that the markup isn't the only place where semantics is important. There is content semantics (HTML), but there is also presentational semantics (CSS) and behavioral semantics (JavaScript) as well. They all have their own separate semantics that are important to pay attention to for maintainability and staying DRY.
OOCSS Resources
Object Oriented CSS
An Introduction To Object Oriented CSS (OOCSS)
How to Write Object Oriented CSS
Getting started with Object-Orientated CSS (OOCSS)
Object-Oriented CSS: What, How, and Why
Diving into Object Oriented CSS
Perhaps it has no special meaning and only needs to be rendered in italics to separate it presentationally from the text preceding it.
If it has no special meaning, why does it need to be separated presentationally from the text preceding it? This run of text looks a bit weird, because I’ve italicised it for no reason.
I do take your point though. It’s not uncommon for designers to produce designs that vary visually, without varying meaningfully. I’ve seen this most often with boxes: designers will give us designs including boxes with various combinations of colours, corners, gradients and drop-shadows, with no relation between the styles, and the meaning of the content.
Because these are reasonably complex styles (with associated Internet Explorer issues) re-used in different places, we create classes like box-1, box-2, so that we can re-use the styles.
The specific example of making some text italic is too trivial to worry about though. Best leave minutiae like that for the Semantic Nutters to argue about.
HTML italic text displays the text in italic format.
<i>HTML italic text example</i>
The emphasis and strong elements can both be used to increase the importance of certain words or sentences.
<p>This is <em>emphasized </em> text format <em>example</em></p>
The emphasis tag should be used when you want to emphasize a point in your text and not necessarily when you want to italicize that text.
See this guide for more: HTML Text Formatting
The i element is non-semantic, so for the screen readers, Googlebot, etc., it should be some kind of transparent (just like span or div elements). But it's not a good choice for the developer, because it joins the presentation layer with the structure layer - and that's a bad practice.
em element (strong as well) should be always used in a semantic context, not a presentation one. It has to be used whenever some word or sentence is important. Just for an example in the previous sentence, I should use em to put more emphasis on the 'should be always used' part. Browsers provides some default CSS properties for these elements, but you can and you're supposed to override the default values if your design requires this to keep the correct semantic meaning of these elements.
<span class="italic">Italic Text</span> is the most wrong way. First of all, it's inconvenient in use. Secondly, it suggest that the text should be italic. And the structure layer (HTML, XML, etc.) shouldn't ever do it. Presentation should be always kept separated from the structure.
<span class="footnote">Italic Text</span> seems to be the best way for a footnote. It doesn't suggest any presentation and just describes the markup. You can't predict what will happen in the feature. If a footnote will grow up in the feature, you might be forced to change its class name (to keep some logic in your code).
So whenever you've some important text, use em or strong to emphasis it. But remember that these elements are inline elements and shouldn't be used to emphasis large blocks of text.
Use CSS if you care only about how something looks like and always try to avoid any extra markup.
I think the answer is to use <em> when you intend emphasis.
If when reading the text to yourself, you find that you use a slightly different voice to emphasise a point, then it should use <em> because you would want a screen reader to do the same thing.
If it is purely a style thing, such as your designer has decided that all your <h2> headings would look better in italic Garamond, then there is no semantic reason to include it in the HTML and you should just alter the CSS for the appropriate elements.
I can't see any reason to use <i>, unless you specifically need to support some legacy browser with no CSS.
I'd say use <em> to emphasize inline elements. Use a class for block elements like blocks of text. CSS or not, the text still has to be tagged. Whether its for semantics or for visual aid, I'm assuming you'd be using it for something meaningful...
If you're emphasizing text for ANY reason, you could use <em>, or a class that italicizes your text.
It's OK to break the rules sometimes!
OK, the first thing to note is that <i> has been deprecated, and shouldn't be used <i> has not been deprecated, but I still do not recommend using it—see the comments for details. This is because it goes entirely against keeping presentation in the presentation layer, which you've pointed out. Similarly, <span class="italic"> seems to break the mold too.
So now we have two real ways of doing things: <em> and <span class="footnote">. Remember that em stands for emphasis. When you wish to apply emphasis to a word, phrase or sentence, stick it in <em> tags regardless of whether you want italics or not. If you want to change the styling in some other way, use CSS: em { font-weight: bold; font-style: normal; }. Of course, you can also apply a class to the <em> tag: if you decide you want certain emphasised phrases to show up in red, give them a class and add it to the CSS:
Fancy some <em class="special">shiny</em> text?
em { font-weight: bold; font-style: normal; }
em.special { color: red; }
If you're applying italics for some other reason, go with the other method and give the section a class. That way, you can change its styling whenever you want without adjusting the HTML. In your example, footnotes should not be emphasised—in fact, they should be de-emphasised, as the point of a footnote is to show unimportant but interesting or useful information. In this case, you're much better off applying a class to the footnote and making it look like one in the presentation layer—the CSS.
Use <em> if you need some words/characters in italic in content without other styles. It also helps make content semantic.
text-style is better suited for multiple styles and no semantic need.
DO
Give the class attribute a value indicating the nature of the data (i.e. class="footnote" is good)
Create a CSS style sheet for the page
Define a CSS style that is attached to the class that you assign to the element
.footnote {
font-style:italic;
}
DO NOT
Don't use <i> or <em> elements - they're unsupported and ties the data and presentation too close.
Don't give the class a value that indicates the presentation rules (i.e. don't use class="italic").