Should i give my time to change terms and abbreviations to <acronym> and <abbr>? Is it worth to use? What are pros to use both tags? Is it useful for SEO and screen reader?
See W3C specs.
An acronym is a kind of abbreviation but not vice versa.
E.g. <acronym lang="en" title="Radio Detection And Ranging">Radar</acronym> or <abbr lang="en" title="Abbreviation">abbr.</abbr>.
There is likely to be no or infinitesimally small SEO benefit from using these tags unless the abbreviation is not well known or something you made up or there is some ambiguity. For example, in an article about LILO the Linux Loader, you may want to specify <acronym title="Linux Loader">LILO</acronym> to avoid confusion with Last In, Last Out.
Any accessibility benefit would exist only for those acronyms and abbreviations that are not well known by the target audience. For instance, it makes very little to no sense to have <abbr lang="en" title="Mister">Mr.</abbr> (WCAG checkpoint 4.2 disagrees with me on this. Note also that I did not provide an expansion of WCAG in my post).
On the other hand, if you use are not using IMF to refer to the International Monetary Fund, it might make sense to use <acronym lang="en" title="Impossible Mission Force">IMF</acronym>.
Now, what happens if you also want to use IMF to mean International Monetary Fund in the same document?
The article The Accessibility Hat Trick: Getting Abbreviations Right might also be useful.
Interesting nuggets:
The assertion that abbr is structural is misguided, as the point of the tag is the content of its title attribute.
...
In [XHTML] version 2, the acronym element has been deprecated, so we're now using the abbr element for all shortened forms.
The first time you use an acronym or an abbreviation in a part of your site, you should mark it with abbr. Here's an example:
I visit <abbr title="Stack Overflow">SO</abbr>, and so should you.
This is useful for a number of reasons:
Screen readers can read the unabbreviated term
A user hovering the cursor over that term can see the unabbreviated term
This can be coupled with CSS styling to hint that the term is an abbreviation (some browsers do this automatically)
Search engines are more likely to understand the context of the term
Should you use abbr?
I would recommend using abbr for long-lived documents, such as help pages. Here, clarity is important, and it's worth the extra few minutes peppering your content with abbr tags.
For periodicals like blog posts, you can probably skip abbr. Chances are that if you use an obscure abbreviation, you'll explain it in-text anyway. There's no sense grinding your creative process to a halt by typing HTML tags.
Avoid acronym
If you are going to use acronym or abbr at all though, you may consider using only abbr. Acronyms are a type of abbreviation, and the acronym tag is being dropped in HTML 5.
Before asking "what is the benefit", normally the question you need to answer first is "what is the alternative?"
CSS tooltips?
JavaScript tooltips?
Spelling out the entire word every time?
Putting the abbreviation in parentheses just once?
The first two put you at risk of the various CSS and JS browser incompatibilities. And the third is going to be pretty irritating for both you and your readers when you have the phrase "National Technology Transfer and Advancement Act" repeated 500 times on the page.
And the last of those... well, it's pretty much the same as using the <ACRONYM> or <ABBR> tag, except using the tags lets the browser decide how to render it (usually with a nice tooltip).
SEO and accessibility... maybe there's some benefit, but I think you should use these tags because they are the right tags, just like <p> is the right tag for a paragraph and <em> is the right tag for emphasized text. Say what you mean!
<acronym> and <abbr> are actually quite useful, precisely for the reasons you mentioned yourself: accessibility and SEO. And it's not that much work, either, because it suffices to mark up only the first occurrence of an acronym or abbreviation on any given page, not all occurrences. In fact, that's precisely what W3C recommends in its accessibility guidelines:
Specify the expansion of each abbreviation or acronym in a document where it first occurs.
Reading the comments on Sinan's answer I think I understand what the question is getting at...
I'd say it completely depends on the circumstances of your text. Using <abbr> tags on everything is pure madness, but you can use it to enhance understanding.
Traditionally, a text that uses abbreviations explains the abbreviation when it's first used. Long names or words can be shortened for the remainder of an article, like so:
The Agency for Awesomeness (AfA) announced [...] An AfA representative said ...
Alternatively, if something is already widely known by its acronym, it is usually briefly clarified the first time it is used like so:
The IMF (International Monetary Fund) has ...
The problem with the web is that you may have a long text split over several pages, and a user can jump to any page without having to read the previous pages. For stylistic purposes you may not want to repeat the definition of every used abbreviation and acronym on every new page. On the other hand, you also don't want to force the user to read your text from the very beginning. This is where the <abbr> and <acronym> tags come in handy. They allow you to (re-)define something without having to break up the flow of the text.
I would add another reason: Style.
One would give more letter-spacing inside an abbr to improve its readability. In the same way, in order to not break the balance of the text, sometimes is preferable to use small caps instead of normal caps.
Related
I read the difference between <b> and <strong>, <i> and <em> and some other sources, but am still not sure which element to choose when I write instructions like the following:
Go to the page > right-click Download > Save link as. What are right elements for Download and Save link as? Or should I simply use CSS to style them? Then should I use font-weight: bold or font-style: italic? I guess I should use <strong> because they are key words in my sentence, but I'm not sure. Here's a real-world example: Download a file.
In linguistics, italics are often used when we are using a word of the language to talk about the language, not to represent a meaning, as is often the case in ordinary speech. With this in mind, I think that you should mark with italics all the words in your instructions that are not part of the explanation but refer to words that the user will see on the screen. With this in mind I recommend that you add those marks in the HTML, that is, using <em> instead of a CSS class and properties since this practice is more accessible to accessibility tools.
Important part of semantics is context. If your whole article for example can be replaced with this single line, you probably should use strong. And if your article is not about downloading files and this line doesn't have so much strong importance, but you still want to draw reader's attention, you probably should use b.
According to MDN:
strong indicates that its contents have strong importance, seriousness, or urgency.
b is used to draw the reader's attention to the element's contents, which are not otherwise granted special importance.
Source: docs/Web/HTML/Element/strong and docs/Web/HTML/Element/b
In my opinion you should find out usage cases, read formal definition of the element from web docs (for example MDN) or web specs and find out which fits you better. You should keep in mind that everyone's case is different. There is no 100% percent correct answer or algorithm which you could use to determine if you need to use strong, b, em, i or something else. What is the topic of the site and the context of the article? In which part of the article is this line placed? So.. basically what am I trying to tell you is that you better know which semantic meaning this text have.
Edit: And SO question you referenced is a bit outdated (answer was written in 2008 which is the year when HTML5 was not so widely used). So it's better to reference web docs or web specs as I mentioned above.
As I understand it, formatting is expected to be done with CSS, not tags like <b> and <i>. However, these tags are still in widespread use, along with tags like <em> and <strong>. I understand that these tags have semantic value, but what is the current expectation (standard) regarding their use, especially in HTML5?
Not a duplicate in my eyes. The question is specific about their semantic values in HTML5.
There are now two set of HTML5 standards - The living standard by
whatwg, and the the w3c standard. They are not necessary the same. Fortunately, for this question they are.
As of 2014 Apr, both specify that <i> means "alternate voice or mood", and <b> means "conveying extra importance". So they can be safely used to represent these semantic meanings. Please note that the semantic meanings are not exactly the same with <em> or <strong>, despite that all browsers I know apply the same default styles.
When client/users says "Please bold these words" you rarely (if ever) ask them whether they mean "extra importance" or "seriousness/urgency" or actually "stress emphasis", and for good reasons. Since almost everyone use them the same way, using them for quick styling for a few words and not worring about standard is ok and saves everyone's time. It's when you apply them en masse (e.g. for every menu item, for every navigation link, etc) that it should be frowned upon.
It seems like there is a sort of unwritten standard people follow to not use b and i tags anymore, at least not as they have been in the past. To a lesser extent the same seems true for em and strong. Honestly, between something like the <strong> tag and CSS, I think it's personal preference.
I don't know of any real standard here. All the tags in question have use.
Supposedly screen readers may also be able to provide more information with strong and em tags, which perhaps gives them more credibility. Though in practice I'm not sure how often that's actually the case.
Interesting aside: Viewing the source of this page, you can see that the <b> tag is being used right here on SO.
I know some languages emphasise words differently to English, e.g. via changing word endings rather than stressing words with inflection of the voice.
If you are localising a site, would you trust that <strong> and <em> tags (and their placement) will have the same meaning in other languages — would you maintain this emphasis, check with your translator or leave them out?
What I'm wondering is how this translates (excuse the pun) into the semantics of the web? — Strong and em tags carry semantic meaning that is used within SEO, screen-readers etc. So should they be left in place so this isn't lost, or dropped to better conform with the target language?
Mark-up is there to convey meaning a whole, and so long as the meaning is conveyed, you have succeeded in your mark-up. So in a language where stress emphasis is conveyed in the text, using tags to signal the emphasis is redundant and optional.
Inline level markup, much more so than block level markup, may need to be radically different in different languages. In a good translation, the text should be marked up from scratch in each language.
For individual words, I would leave the markup tags in the translation strings for the reasons outlined in comments above. If emphasising blocks of text, whole sentences, numerals, etc, I'd put it in the template if possible as it's not really something that would need to be be messed with by the translation.
A good idea might be to flag in the template the you have done this using comments. You will also need some reliable process for getting all the translation files changed if you decide to alter the emphasis ever (which you inevitably will). This is a pain, so I tend to avoid adding emphasis to individual words wherever possible :)
Interesting question! The only thing I can add is that strong and em tags are only useful for SEO if the search engines connect those tags with the content on your site.
I'd recommend using these tags only if there's an actual reason (for emphasis, say) rather than hoping to gain SEO benefit from bolding or italicizing keywords.
For screen readers, it comes down to what language you are talking about. JAWS for example, you can download voice files. If it isn't listed, then they have to have to choose another language or find alternative means. The key thing is for you to set the lang attribute correctly.
I'm currently marking up some user alerts as follows
<em>You are in danger of exceeding your <strong>40GB</strong> download limit</em>
I've found other answers suggesting that, although valid html, this is not semantically valid. But is it really not OK to nest em/strong tags in all instances? The above example seems to me to be a perfectly reasonable use - to specifically emphasise a subsection of something that's already emphasised. But can screen readers interpret this as it's meant to be interpreted, or woudl it tend to confuse them?
It's permissible to use <strong> within an <em>, in terms of HTML. However, within the specific semantics of your question, it wouldn't be the best option.
Someone answered advocating using <b> with a great explanation of why it's appropriate and a link to the specs to back it up.
The b element represents a span of text to which attention is being
drawn for utilitarian purposes without conveying any extra importance
and with no implication of an alternate voice or mood, such as key
words in a document abstract, product names in a review, actionable
words in interactive text-driven software, or an article lede.
But then they deleted the answer for some reason. If they want to repost their answer I'll happily upvote it and mark as the answer.
Also, for the case where you really do want to put stronger emphasis on a subsection of an alreday emphasised passage #Alohci's comment above points out that in html5 nesting <em> tags is permissible
Unfortunately, the semantics of <em> and <strong> have changed in
HTML5 from HTML4, and this may affect the answer to your question. If
you are interested in HTML5, I recommend that, in particular, you read
the new definition of <em> here :
http://dev.w3.org/html5/spec/the-em-element.html
Yes, it's fine in the case you posted, because the 'strong' part is not wrapping the whole of the text. It picks out a specific part of the text.
The problem with something like:
<em><strong>something</strong></em>
is that it, effectively, it's used to make something bold and italic. In semantics, <strong> overrides <em>, making the latter irrelevant. However, in your example, the whole thing has <em>, and only part of it has <strong> as well.
Another way of explaining it is to try reading it out loud. Can you give something both empahsis and strength? Would you be able to tell the difference between saying something with emphasis and saying it with strongly with emphasis? No. However, you can say something with emphasis, and in the middle of that, say something even more strongly.
The issue is almost purely theoretical, and the only practical aspect is this: are you working in a community where other authors have certain ideas about the “semantics” of the tags? In that case, it is this community’s ideas that matter, rather than the varying formulations in different HTML5 drafts.
That is, apart from adherence to some agreed coding style, it does not matter the least. In practice, all that matters is that the default rendering is italic or slanted for em, bold for strong, and by nesting them you get bold italic. Just as you would get by using i and b the same way.
Screen readers generally ignore these types of markup. It would just be too disturbing to raise the voice or change from female to male voice for individual words, with any normally used reading speed. But if screen readers react to this markup somehow, they can do that in different ways, and they will hardly try to make any fine-grained differences.
The sample style sheet with aural features in the CSS 2.1 spec is just sketchy and at most suggestive, but it may be of some relevance to note that it uses the same pitch and but higher stress and richness for strong (and b) than for em (and i) and that it has no rules where nesting would matter. That is, according to it, strong would be rendered the same independently of whether it is inside em or not.
What you're doing is fine. You can nest tags, as long as they are correctly nested.
This is valid:
<em>You are in danger of exceeding your <strong>40GB</strong> download limit</em>
This is not:
<em>You are in danger of exceeding your <strong>40GB</em></strong> download limit
As for semantics, you're telling the browser that some of your text should be both strong and emphasized. What this will means visually depends on the browser implementation. Emphasized is usually rendered in italics, which strong will be bold.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am taking a peek at Dive Into HTML5. It seems nice and interesting, but I am puzzled.
In the 1990s, at the time when Netscape was the browser and HTML was HTML2 or HTML3, there were a lot of tags: address, cite, code... Most of them are unused as of today, probably even obsolete.
HTML5 introduces tags to express "semantic meaning" to the tag itself. This is all fun and games, but I see something very strange in this approach. Technically, the semantics can be very open ended. HTML5 has tags for article, time, navigation bars, footer. Why shouldn't it contain tags for post icon, author's place, name and surname, or whatever else you want to assign specific semantics to (I'm confident <rant> and <nsfw> would be very important tags): ? I thought XML was the strategy to assign semantics to stuff. Nothing forbids you to put an XML chunk under a XHTML div element, and assign a stylesheet to it so to style it properly, or to delegate to the proper viewer the handling of that namespace (for example, when handling RSS or SVG).
In conclusion, I don't understand the reason behind this extensions focused towards semantics, when it's clear that semantic is a very broad topic, which is guaranteed to require a potentially infinite amount of semantic tags. Since I am pretty sure there are clever people at W3C, I think I'm wrong, but I'd like to know why.
Why are tags for article, time, navigation bars, footer useful?
Because they facilitate parsing for text processing tools like Google.
It's nothing about semantics (at least in 'broad' meaning). Instead they just say: here is the body of page (most important text part) and there is the navigation bar full of links. With such an approach you can easily extract just what you need.
I too hate the way that W3C is going with their specs. There are many things that I don't like, and this "semantics" fad is one of them. (Others include taking forever to complete their specs and leaving too many important details for the browsers to implement as they choose)
Most of all I don't like it because it makes my work as a web developer more difficult. I often have to make a choice whether to make the webpage "semantically correct" or "visually/aesthetically pleasing". The latter wins of course, because that is what the users want, but as a result validations start failing and the whole thing gets quite non-semantic (tables for layout and other things).
Another issue at which I frown is that they have officialy declared that the "class" attribute is for semantics, but then they used it for visual presentation selectors in CSS.
Bottom line - DON'T MIX SEMANTICS AND VISUAL REPRESENTATION. If you use some mechanism for describing semantics (like tag names, attribute values, or what not else), then don't use it for funcional/visual purposes and vice versa.
If I would design HTML, I would simply add an attribute "semantic" which could (like the "class" attribute) be added to any tag. Then there would be a number of predefined values like all those headers/footers/articles/quotes/etc.
Tags would define functionality. Basically you could reduce HTML tags to just a handful, like "div", "table/tr/td", "a", "img", "form", "input" and "select". I probably missed a few but this is the bulk. Visual styling would be accomplished through CSS.
This way the three areas - semantics, visual representation, and functionality - would be completely independent and wouldn't clash in real life solutions.
Of course, I don't think W3C is interested in practical solutions...
There is already a lot of semantics in HTML markup in the forms of classes and IDs, of which there is a (near) infinite amount of possibilities of, And everyone has their own way of handling these semantics. One of the goals of HTML5 is to try to bring some structure to this. you will still be able to extend the semantics of tags with classes and ids. It will also most likely make things easier for search engines.
Look at it from the angle of trying to make statements either about the page, or about objects referenced from the page. If you see a <footer> tag, all you can say is "stuff in here is a footer" and pass it by. As such, adding custom tags is not as generic a solution as adding attributes and allowing people to use their own choice of URIs to specify predicates and optionally values - RDFa wins hands-down because you can express any triple-statement you like from RDF in a page, one way or another.
I just want to address one part of your question. You say:
In the nineties, at the time when
Netscape was the browser and html was
HTML2 or HTML3, there were a lot of
tags: address, cite, code... Most of
them are unused as of today, probably
even obsolete.
There are a great deal of tags to choose from in html, but the lack of usage does not imply that they are obsolete. In particular the header tags <h1>, etc, and <ul>, <ol> are used to join items into lists in a way I consider semantic. Many people may not use tags semantically, but the effort to create microformats is an ongoing continuation of the idea you consider an artifact of the 1990s. Efforts to make the semantic web be a winner keeps going, despite full-text search and link analysis (in the form of Google) being the winner as far as how to find and understand the web.
It would be great to see an updated version of Google's Web Stats which show "html as she is spoke." But you are right that many tags are underused.
Whether html5 will be successful is an open and interesting question, but the tags you describe as obsolete didn't go anywhere, they were there in HTML 4.01 and xhtml. HTML5 seems to be an effort to solidify what is useful in tags. In the end if html5 gets support in browsers and makes the job of web developers easier, it will succeed. xhtml2 failed because it roundly failed to gain adoption in browsers and did nothing to make the job of web page makers easier. The forces working on html5 seem keenly aware of the failure of xhtml2, and I think are avoiding having html5 suffer a similar fate.
"Why shouldn't it contain tags for post icon, author's place, name and surname, or whatever else you want to assign specific semantics to (I'm confident and would be very important tags): ?"
You use <dialog> to describe conversations or comments. Rant and NSFW are subjective terms therefore it makes sense not to use them.
From what I understand a bunch of experienced web developers did research and looked for what most websites have in common in html. They noticed that most websitse have id="header", id="footer", id="section" and id="nav" tags so they decided that we need HTML tags to replace those id's. So in other words, don't expect them to give you a HUGE amount of HTML vocabulary. Just keep it simple as possible as you can while addressing the MOST common needed HTML tags.
NAV tag is VERY important for providing accessibility as well. You want them to know where the navigation is rather than to force them to find whether links are for navigation or not.
I disagree with adding extra tags. If detailed vocabulary were actually import then there could be a different tag name for every word in the dictionary. Additional tags names are not helpful as they may communicate additional meaning to humans, but do nothing to facilitate machine parsing of the language. This is why I don't like the "semantic" tags for HTML5 as I believe this to be slippery slope to providing a vocabulary too complex while only providing a weak solution to a problem not fully addressed.
In my opinion markup language structure data as much as describe it in a tree diagram form. Through parsing of the structure and proper use of semantic conventions, such as RDFa, context can be leveraged to provide specific meaning to otherwise generic tag names. In such as case excessive vocabulary need not exist and structurally redundant tag names, such as footer and aside, could be eliminated. The final objective is to make content faster and more accurate to interpret by both humans and machines simultaneously while using as little code as possible to achieve that result. How that solution is lesser important, except to HTML5.
I thought XML was the strategy to assign semantics to stuff.
As far as I know, no it wasn’t. XML allows new languages to be defined which are all parsed in the same way, because they all use the XML syntax.
It doesn’t, of itself, provide any way to add meaning (“semantic” just means “meaningful”) to those languages. And until computers get artificial intelligence, they don’t actually understand meaning, so meaning is just what is agreed between human beings. HTML is the most commonly-used language with agreed meaning of its tags.
As HTML is so common, it’s helpful to add a few meaningful tags to it that are quite general in their application. The new HTML5 tags are aimed at that. The HTML5 spec’s authors could indeed carry on down this route, creating tags for every specific bit of meaning possible, but as they’re not robots, they probably won’t.
<section> is useful, and general enough to be meaningfully applicable in lots of documents. <author-last-name> isn’t. Distinguishing between the two is a judgment call, which is why humans, and not computers, write the spec.
For custom semantics that are too specific to be added to HTML as tags, HTML5 defines microdata.
I've been reading Andy Clark's book Transcending CSS (page 33).
...,it is now widely accepted that presentational names such as header, left, or red that describe an element's look or position are poor choices.
After reading these lines I asked myself: hey, aren't there elements in HTML5 spec such as header, footer?? Why is footer more semantic ? Andy in his book advocates to use site-info for the ID of the footer div and this makes more sense IMHO. Footer is a presentational name (describes the element's position).
In a word, AJAX. The new tags are meant to support what real-world developers are doing by replacing some of the <div class="sidebar-wrap"><div class="styling-hook"><div><ul class="nav"> type of divitis many websites suffer from. The only <div> left in the HTML5 is the styling hook.
The semantics that get promoted to tags from classes are those that developers have freely adopted en-masse as best practices, given an extended xhtml/css adoption period. Check out the WHATWG developer's edition of the spec's sections pagehere. The document itself is a pleasure, but I won't spoil it if you haven't seen it yet.
One of the less obvious reasons for some decisions made by the W3C is the importance of Webkit. If you look, you can see that they were better than some at taking the current work of the HTML5 Working Group and implementing ideas. They have historically been way out ahead in compliance (see here). The W3C placed a high priority on their (i.e. Android, iPhone, the Googlebot, Chrome, Safari, Dreamweaver, etc.,). Google, framework users, Wordpress/Moveable Type/Joomla! type users and others wanted self contained building blocks, so this is the style we get.
Facebook is modular. Responsive design's grids are modular. Wordpress is modular. Ajax works best with modular page structures. Widgets are modules. Plug-ins are modules. It would seem that we should be trying to figure out stuff like how to apply these tags to make it easier to hook the appropriate elements and activate them in our document/application/info-network hybrid Web 2.0.
In closing, HTML5 is meant to be written as xml (again, see the spec) in order to ensure that tools and machines making ajax requests for a portion of a document will get a well-formed useful response. How awesome in combination with things like media queries for devices like feed readers, braille printers, annotators, etc.,. I see a (near)future where anything with good semantic content is it's own newsfeed automagically! This only happens if developers adopt and write compliant documents.