Considering the following paragraph:
So in the first set, we start to mix those 3 codes:
- AA
- BB
- CC
with those codes:
- Aa
- Ab
- Ac
to get the perfect result we're looking for.
Is this paragraph semantically incorrect?
If not, what's the html5 way of writing it?
If I use ul, then it splits the paragraph in three parts, which is semantically inexact (isn't it?).
I can use br or span, but then I have to do all the formatting myself.
Are those the two only ways we have?
If so, why not having an enum element, like this:
<p>
So in the first set, we start to mix those 3 codes:
<enum>
<ei>AA</ei>
<ei>BB</ei>
<ei>CC</ei>
</enum>
with those codes:
<enum>
<ei>Aa</ei>
<ei>Ab</ei>
<ei>Ac</ei>
</enum>
to get the perfect result we're looking for.
</p>
Would that make any sense?
I would like to propose that to the W3C, do you think that's a good idea?
If not, why?
I think using description list is the best way for the above particular example like;
<dl>
<dt>So in the first set, we start to mix those 3 codes:</dt>
<dd>AA</dd>
<dd>BB</dd>
<dd>CC</dd>
<dt>with those codes:</dt>
<dd>Aa</dd>
<dd>Ab</dd>
<dd>Ac</dd>
</dl>
I finally found an answer that satisfies me: https://github.com/whatwg/html/issues/4685.
Basically, breaking the "p" element is not a big deal, as the p element is an html paragraph, which is different from an english paragraph.
So, the html way of doing a list inside a paragraph, is simply to break the p before the list, and create another one after, like this (for instance):
<p>The list should be</p>
<ul>
<li>responsive</li>
<li>short</li>
<li>precise</li>
<li>easy to use</li>
</ul>
<p>to do all the things I want</p>
Is it allowed to use definition list tag like this
<dl class="feature-list">
<dt>Stackoverflow</dt>
<dd>Is a nice place place to find some answers</dd>
<dt>Stackoverflow</dt>
<dd>Has a cool team</dd>
<dt>Stackoverflow</dt>
<dd>Welcomes your contribution</dd>
<dt>Stackoverflow</dt>
<dd>is simply amasing</dd>
</dl>
The idea is to have a product feature list, while every feature starts with the product name. But product name is the same for every feature. If that is not an allowed usage, what will be the most suitable layout for such a case?
Up to HTML 4.01, the dl element has been defined as a definition list, though with notes that make it questionable whether this was really meant. In HTML5 CR, the dl element is a description list, representing “an association list consisting of zero or more name-value groups”. So there is not much of semantics here, just an abstract structure. So more or less anything that matches the syntax can be said to be conforming, and the syntax has always permitted markup as in the question.
A list where each “value” (dt element) has the same content looks odd, but there is nothing formally wrong with it. Associating different “values” with the same “name”, even when the “name” is repeated, can be seen as a legitimate use of an association list.
Besides, there is no evidence of browsers or search engines assigning any particular structural meaning to dl, i.e. the real effect of using it is the default rendering you get with it. Thus, if such rendering is OK, and a suitable basis for the more detailed rendering you are aiming at, dl is suitable.
According to HTML5Doctor's article on the dl element: "<dl> can be used to mark-up a glossary of terms, although you must remember to use <dfn> to indicate that the word is defined [in the same document]." Note: the bracketed language is my own. The article gives this markup to explain:
<dl>
<dt><dfn>RSS</dfn></dt>
<dd>An XML format for aggregating information from websites whose
content is frequently updated.</dd>
</dl>
Note that the term "RSS" is enclosed in both dt and dfn tags.
My question is this: why must we remember to use dfn? That isn't explained convincingly. I'm looking for definitive explanation of dfn usage as well as some concrete examples.
Note: I looked at The dfn tag documentation by the W3C but that didn't answer my question.
Additional Background and References
Interestingly (or not), according to the HTML5Doctor article the dl element was renamed to 'description list' in HTML5. Formerly it the 'definition list'. From the W3C Working Draft on the Description List:
The dl element represents a description list, which consists of zero or more term-description (name-value) groupings; each grouping associates one or more terms/names (the contents of dt elements) with one or more descriptions/values (the contents of dd elements).
Interestingly (or not), according to the HTML5Doctor article the dl element was renamed to 'description list' in HTML5.
That sums it up; now that dl is no longer exclusively applicable to definition lists, but to any kind of lists which contain terms and their corresponding descriptions, the dfn tag is recommended use to indicate that the content of the dt is in fact a definition term; that is, a term whose description is in fact its definition (something once necessarily true in previous specifications but no longer in HTML5).
Confusing, I know, but that's the basic idea: use dfn in a dt if the content of the dt is something that's being defined by its dd.
As I just learned, a good time to use dt without dfn is for metadata. Here is an example that was right under my nose in the same definition list writeup:
<dl> is also appropriate for marking up content metadata, such as information about our article on how to use HTML5 in your client work right now."
Here is the markup:
<dl>
<dt>Authors:</dt>
<dd>Remy Sharp</dd>
<dd>Rich Clark</dd>
<dt>Editor:</dt>
<dd>Brandan Lennox</dd>
<dt>Category:</dt>
<dd>Comment</dd>
</dl>
(One small criticism of this example: the ":" is marked up as being part of the term, but really, it is used as a delimiter.)
Nobody covered this, from the original blog to this post. The reason is this:
<dl>
<dt><dfn>RSS</dfn> flibbit </dt>
<dd>An XML format for ...</dd>
</dl>
You can add non-definition-target verbiage to the <dt>, so CSS marks it up as defined-term side, not definiton-data side.
That couples with the rule the <dfn> must appear once per <dl> (else someone scanning for it could be confused).
I've read this and I GENERALLY use spans or strongs to describe "text-labels". Is this true for best practices? It seems is also a semantic way but why is it limited to just form elements?
What if I wanted to display information as this:
Name: FOo Bar
Age: 27
Weight: 151 kg
etc?
name, age, and weight can all be described as labels, but since the items they're describing aren't input tags, it isn't semantically correct(for html and w3c at least). I usually use
<span class="label"> or <span class="description"> or <span class="person-detail"> etc
but generally there should also be a tag for labels that don't pertain to input fields. As this might be a bit subjective I don't mind this turning into a community wiki or something
You should use a definition list (dl with dt and dd):
<dl>
<dt>Name</dt>
<dd>FOo Bar</dd>
<dt>Age</dt>
<dd>27</dd>
<dt>Weight</dt>
<dd>151 kg</dd>
</dl>
The spec states that it could be used for
terms and definitions, metadata topics and values, questions and answers, or any other groups of name-value data.
I think a table (with th) could be used, too. But I would only use it when I want to compare several people, not just listing the data of one person.
I'd avoid using a label tag unless it's in combination with a functional HTML form (with editable fields); otherwise, using it may be semantically confusing.
A span tag has no semantic meaning, regardless of the id or class added to it, and regardless of the context in which it's used. You don't gain anything semantically by using a span (though it does no harm).
A strong tag has a generic meaning (this content has extra importance) that doesn't vary based on the context in which it's used. It's sometimes useful when there's nothing else more appropriate.
In this particular case, a definition list (as suggested by #unor) seems like the way to go. If advanced styling is required, put each name-value pair into a separate definition list (which may be awkward semantically, but it allows greater flexibility with styling the content).
I guess if you wanted to be 100% semantically correct you'd have to use labels in conjunction with disabled or readonly text boxes that have been styled to look a bit different.
Semantically speaking, is there an appropriate place in today's websites (late 2008+) where using the bold <b> and italic <i> tags are more useful than the more widely used <strong> and <em> tags?
While in general I would stay away from non-semantic tags like b and i, strong and em are not direct replacements for b and i.
I would use b or i when it's only presentation you're going for, and what you're marking up has no semantic meaning. For example, a logo like stackoverflow could be marked up with stack<b>overflow</b>. The "overflow" portion has no semantic meaning over "stack", yet stack<span class="overflow-logo">overflow</span> doesn't offer anything either.
Hope this helps.
Not sure how to comment (edit: need moar karma!), but this is in reply to Erik's comment.
Please read the HTML5 working draft. It gives a good explanation on when to use b.
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.
"overflow" does not have emphasis over "stack" in the logo, therefore wrapping "overflow" with em is semantically incorrect.
Never. They are removed in XHTML 2.0 as they are presentational tags. CSS should be used to bold/italicise content.
edit: If you're looking for a purely presentational tag, that's what the SPAN tag with a class and a little CSS is for.
According to the HTML 5 spec, <b> and <i> should be used when appropriate.
On the i:
[A] span of text in an alternate voice or mood, or otherwise offset from the normal prose, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, a ship name, or some other prose whose typical typographic presentation is italicized.
On the b:
[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.
Generally speaking, "when appropriate" is deemed to be as a last resort, when all other semantic options have been exhausted. "Presentational" though they may be, it would certainly be a disservice to their semantic cousins <em> and <strong> to consider them always italic or bolded, respectively.
On http://www.webmasterworld.com/forum21/7095-1-15.htm there's a good comment:
"If page readers really read every
<strong> tag in a strong voice, or
really emphasize every <em> section on
a page, then the poor user gets a page
shouting at her or him on a regular
basis.
I think this issue is really a
no-brainer. If I am setting a bold or
italic font for purposes of typography
only, then I use <b> and <i>. If
there's a word or phrase that I want
to emphasize as I would in speaking,
then - and only then - do I use
<strong> or <em>."
For markup generated by a WYSIWYG editor.
The <b> and <i> tags don't have semantic meaning, whereas <strong> and <em> do. If a reader read the block of text aloud it would react to the <strong> and <em> tags, whereas the <i> and <b> tags would be ignored, and treated and purely visual elements. I tend to regard <i> and <b> as deprecated.
Whenever you want to do things incorrectly ... just kidding.
The real answer is never, these tags have been deprecated by the W3C
Neither <b> nor <i> are semantic tags, so purists would say they should not be used. Where I've seen their use justified are in things like putting online content in print where text was bolded or italicized as a matter of convention, but not as a manner of strengthening or emphasizing content.
The easy example is if you're putting online a magazine article that references a book by its title: you may want to put the book title in italics, but the italics are not for emphasis, so the <em> tag would be inappropriate. You could use <i> here, but the semantic thing to do would be to use something like <span class="booktitle"> and then use CSS to make booktitles italics. You are referencing a title, not putting emphasis, and you wouldn't want a screen reader to put verbal emphasis on the title.
My personal opinion is to not use either <b> or <i> today, but using <strong> or <em> as their substitutes when you aren't really looking to do anything besides bold or italicize the text is equally incorrect.
I think when you're trying to make your markup meaningful, these are rarely useful.
There are, however, new tags that produce some of the same results, but which provide even more semantic value. I like to use the <cite> tag when I'm referring to the name of a book, for example, as it still gets italicised, but the HTML now carries meaning about why.
There are a variety of other semantic tags that can also affect formatting listed here:
http://www.w3.org/TR/xhtml2/mod-text.html
I've been using <b> for years to indicate key words on my web site. I wrote a small utility that crawls the site looking for <b> tags and adds them to an index. I use <strong> when I want to bold a word without adding it to the index. I have used this convention for years -- too late to quit now.
It could be argued that there is still a use for the <i> tag: when expressing the scientific name (aka the Latin name) of a species. The scientific name of a species is, by convention, usually presented in italics. Example. It is semantically incorrect to use <em> in this situation because one is not trying to emphasise the name but rather merely distinguish it visually. It may be more appropriate to use something like <span class="sci-name">, but when one considers that most scientific names are composed of words of the italic languages, mainly Latin, the <i> tag becomes a rather sematically rich and convenient solution.
There are technical rules, but here are my two rules of thumb:
1) If you are writing something where, if spoken, you would emphasize a word, < strong > and < em > are appropriate. (E.g., "You have got to be sh*tting me, Pyle!")
2) If you are emphasizing a word for a technical reason, but would not emphasize the word in spoken conversation, < b > and < i > are appropriate. (E.g., "He boarded the RMS Titanic and sailed away, never to be seen again.")
Don't leave out other tags like < cite >, though!
Officially, <i /> and <b /> are "presentational" and shouldn't be used. While many developers think that <em /> and <strong /> are presentational, they are not. They are generally italicized and bolded resopectively, but the CSS can (and should, when appropriate) change how the emphasis and strongness could be displayed.
Similar things could be done with css on a <span /> tag, and many consider that the preferred method, but it isn't substantiatable with the specification.
Some years have passed …
In HTML5 (W3C Recommendation), none of these four elements are deprecated/obsolete.
The (non-normative!) usage summary lists their purposes:
strong: importance
b: keywords
em: stress emphasis
i: alternative voice
Of course, if you want to use them, always refer to their normative definitions (which you can find by clicking on the element names) and verify that they are appropriate for your case.
Examples
The b element could be used for keywords in a text, where the other three elements would not be appropriate: such keywords are not stressed (em), nor are they offset (i), and there is also no need for distinguishing them from boilerplate etc. (strong).
The i element could be used for scientific names in Latin, where strong and em are not appropriate. While b seems to be appropriate, too, its definition explicitly excludes the cases handled by i.
There can of course be cases where you’d use several of these elements. For example, a scientific name could also be a keyword in a document (<b><i>…</i></b>).
When writing websites for mobile devices. They don't always support the 'latest and greatest' standards, are depreciated but not deleted from all modern browsers, and simply take up less space and bandwidth (though in theory the streams are compressed by either the websites or the wireless browser, it can't be counted on).
-Adam