Re: several messages about <i> and many related subjects

Summary: The spec has, over the past few years, evolved to the point where 
most of the comments below now match what it currently says. I have not 
made any new normative changes today in response to these e-mails, but 
some minor editorial changes (e.g. new examples) have been made.

On Sun, 17 Apr 2005, Anne van Kesteren wrote:
> Ian Hickson wrote:
> > Is there any advantage to marking up people's names?
> 
> Not really. As there is no way to distinquish two people sharing the 
> same name. Furthermore, it would only be useful for the few who "love 
> semantics", since names are typically not rendered any different from 
> other paragraph text.

Ok.


> > Maybe we should just let ship names be marked up by <i> (it is, after 
> > all, an instance of use of a term, as it were), and say that <cite> 
> > can be used for any reference to a publication, including those that 
> > aren't really citations ("my favourite book is <cite>...</cite>").
> 
> We need italics for other things as well:
> 
> # Looking over the index entry for "Italics" in my Chicago Manual of
> # Style, I see that italics can be used for emphasis, foreign words,
> # genus and species, key terms, legal cases, letters as letters and
> # words as words, letters in enumeration, math, questions (as
> # quotatives), rhyme schemes, ship names, stage directions, subheads,
> # technical terms, theorems, and titles (of books, journals, movies,
> # musical works, paintings, plays, and poems). Among other things. A
> # lot of these are just typographical conventions in English that do
> # not pertain in all other languages. I think this is exactly what the
> # i tag was invented for.
> <http://annevankesteren.nl/archives/2003/09/b-svg-and-accessibility#comment-206>

The spec is roughly in line with this now, with some cases (titles of 
work, emphasis, maths, headings, and foreign words) having their own more 
appropriate elements.


On Mon, 18 Apr 2005, Henri Sivonen wrote:
> 
> Some print newspapers and magazines bold the first occurrence (per 
> article) of each personal name. (Is it actually useful? Dunno.) However, 
> doing this with a style sheet once each name has been marked up as such 
> would be really hard compared to just using <b> where the editor wants 
> it. UAs are not going to be able to perform morphological analysis for 
> every language under the sun and, therefore, will the unable to figure 
> out that <name lang='fi'>Sivonen</name> and <name 
> lang='fi'>Sivosen</name> are occurrences of the same name but the latter 
> occurrence is in genetive.

The <b> element is officially allowed for this now.


On Mon, 18 Apr 2005, Mikko Rantalainen wrote:
> 
> I think that "bold" isn't really what magazines are looking for in your 
> example case. It's more like some kind of emphasize on first occurrence 
> of person's name. I'd rather use <em>, somebody else might use <strong>. 

I don't think these cases are either stress emphasis or importance, which 
would make <em> and <strong> inappropriate.


> I still think that <b> isn't correct element to use in this case. 
> Newspapers use bold just because it's *the* method to emphasize text in 
> that world. A web browser can do more.

Sure, <b> doesn't have to be bold. It could be styled as small-caps.


> How about <e> for entity? A bit more semantic than <span> but doesn't 
> hint rendering a little bit. Throw a "type" or "class" attribute in and 
> you might have something usable.

I don't think this would really be better than what we have now.


On Mon, 18 Apr 2005, Henri Sivonen wrote:
> 
> When there are established cases where you are supposed to use bold and 
> cases where you are supposed to use italic, is it truly useful to try to 
> enumerate all the semantic roles and come up with gazillions of synonyms 
> for <b> and <i> only in order to adhere to the "no presentationalism" 
> principle even when there aren't compelling use cases for programmatic 
> text analysis that would benefit from fine-grained semantics?

On Sat, 7 May 2005, Henri Sivonen wrote:
> On Apr 16, 2005, at 17:53, Ian Hickson wrote:
> > On Sun, 17 Apr 2005, Lachlan Hunt wrote:
> > > > 
> > > > Actually, <i> in HTML5 is currently defined as having specific 
> > > > semantics:
> > > > 
> > > >    http://whatwg.org/specs/web-apps/current-work/#the-i
> > > 
> > > So does "i" now stand for "instance", instead of "italics"?
> > 
> > At least until someone argues otherwise. :-)
> 
> Everybody knows it originally stands for "italic". Who would you fool by 
> claiming it stood for something else? For browsers, and the element name 
> is just a string. They don't care of English words. The default 
> rendering will have to be italics anyway due to ample legacy content. No 
> matter what to write in the spec, for all practical purposes <i> will 
> mean "italic". I think acknowledging this would be in line with the 
> descriptive approach the WHAT WG specs tend to take when it comes to 
> features that have been already interoperably implemented.

The spec has moved more towards this than at the time of that e-mail, 
though there is still a distinction between <i> and "italics".


On Wed, 11 May 2005, fantasai wrote:
>
> Literals
> --------
> 
>   There doesn't seem to be any appropriate markup for literals in HTML.
> 
>   For example:
> 
>      The words 'elude' and 'allude' are frequently mixed up.
> 
>   The formatting for such elements varies freely: I've seen single quotes
>   (which I prefer), double quotes, and italics. It is therefore stylistic,
>   and should be controlled (or controllable) with CSS.

HTML5 says that <i> is appropriate (though not necessory) in such cases.


> Actions
> -------
> 
>   I can't figure out any appropriate markup for things like
> 
>      The pattern, I said, not the text! *runs away*
>                                         ^^^^^^^^^^^
>                                            this.
> 
>   It's not used in formal specs or professional web apps, but,
>   it's frequently used in less formal discussions.

No markup is necessary for this, though <span> or <b> are both 
appropriate per the current text.


> Emphasis (<em>)
> ---------------
> 
>   # The em element represents stress emphasis of its contents.
> 
>   I would render 'stress emphasis' as 'emphatic stress'.

I don't follow why that would be a useful change.


> Highlighting (<m>)
> ------------------
> 
>   Another use for it would be in highlighting important phrases in
>   documents optimized for skimming. (Or buzzwords in marketing hype
>   like at the top of
>     http://fantasai.inkedblade.net/weblog/2003/marketing/about
>   , not that I approve of such language.)

Actually keywords are more <b>'s domain. The conceptual difference between 
<b> and <mark> is that a particular document always has the same <b>s, but 
can, depending on context, have different <mark>s.


>   I'd say the distinction between highlighting and <strong> & <em>
>   is that highlighting does not change the reading of the text when
>   you're reading straight through, it just helps you find the
>   bits you should pay attention to.

Right.


> Small Print (<small>)
> ---------------------
> 
>   # The small element represents small print (part of a document often
>   # describing legal restrictions, such as copyrights or other
>   # disadvantages), or other side comments.
> 
>   Is <small> appropriate for the example at the end of
>     http://fantasai.inkedblade.net/weblog/2003/big-small/
>   ?

In informal contexts, sure.


>   # Note: The small element does not "de-emphasise" or lower the
>   # importance of text emphasised by the em element or marked as
>   # important with the strong element.
> 
>   Does <small> de-emphasize the text at all? This paragraph implies
>   that it does, except within <em> or <strong>, but it is not clear
>   from the definition.

I think it would be hard to argue that making text smaller isn't 
de-emphasising the text. I mean, the whole point of hiding legalese in 
small text is to make the reader not read it.


> Defining Instances (<dfn>)
> --------------------------
> 
>   # The paragraph, definition list group, or section that contains the
>   # dfn element contains the definition for the term given by the
>   # contents of the dfn element.
> 
>   I have very often seen defining instances whose definition is limited
>   to just the sentence in which it appears. The rest of the paragraph
>   is related discussion, of course, but nothing I would pull out into
>   a glossary.

I don't think <dfn> could be used for automated glossary building anyway.


>   Also, this sentence implies that <dfn> should be used with <dl>, but
>   I don't see what you mean by that implication. There are no examples
>   with <dfn> in the <dl> section. If I were to take that idea and run
>   with it, I'd say that if a <dt> contains a <dfn>, then the <dd> is
>   defining the term contained within the <dfn> only; the rest of the
>   <dt> is extra meta-information. E.g.
> 
>    <dt><dfn>term</dfn> (t�rm)</dt>
>    <dd>...</dd>

I've added a glossary example to <dl>.


> Instance of Term (<i>)
> ----------------------
> 
>   # The i element represents an instance of the use of a term, such as
>   # a taxonomic designation, technical term, an idiomatic phrase from
>   # another language, or similar.
> 
>   I think this is a great definition for an element we really need to
>   have in HTML.
> 
>   However, I am not convinced that leaving HTML with no purely
>   presentational tag for italics is a good idea. That leaves nothing
>   for people who do not have the time, opportunity, or patience to
>   learn/semantic/ HTML markup and for simplistic authoring UAs. <b>
>   and <i> are often the first -- or only -- tags people learn, and
>   they are among the few tags understood by most commenting systems.
>   Whatever semantics you declare here for <i> will be flagrantly
>   ignored by all but a minority of authors. How is defining <i>'s
>   semantics this way useful?

<i> is now defined in a way that covers both these use cases.


> Inline Code Fragments (<code>)
> ------------------------------
> 
>   The example should be of an inlined code fragment, not a block-inline
>   tag combination pretending to be a block element.

Added.


> Sample Output (<samp>)
> ----------------------
> 
>   # Nested samp and kbd  elements allow for the styling of specific elements
>   # of the sample output using a stylesheet.
>   #
>   # <pre><samp><samp class="prompt">jdoe@mowmow:~$</samp><kbd
>   # >ssh demo.example.com</kbd>
>   # Last login: Tue Apr 12 09:10:17 2005 from mowmow.example.com on pts/1
>   # Linux demo 2.6.10-grsec+gg3+e+fhs6b+nfs+gr0501+++p3+c4a+gr2b-reslog-v6.189
>   # #1 SMP Tue Feb 1 11:22:36 PST 2005 i686 unknown
>   # <samp class="prompt">jdoe@mowmow:~$</samp> <samp
>   # class="cursor">_</samp></samp></pre>
> 
>   This is an interesting example. The outer <samp> can be interpreted as
>   "output of terminal" and the inner one as "output of shell", which seems
>   all well and good.
> 
>   However, what if I wanted to colorize the output of Mozilla's layout
>   regression tests?
> 
>   Running verify test for
> E:\moz_src\mozilla\layout\html\tests\block\rtest.lst.
>   Writing regression data to
>     E:\moz_src\mozilla\layout\html\tests\table\core\verify\standards1.rgd
>   Comparing to regression data from
>     E:\moz_src\mozilla\layout\html\tests\table\core\baseline\standards1.rgd
>   frame bbox mismatch: 0,26437,4824,600 vs. 0,26437,4872,600
>   Node 1:
>     TableOuter(table)(144) 0x10004 0,26437,4824,600, |null
> attr|-16777216|left:
>     0[0x0]tw top: 0[0x0]tw right: 0[0x0]tw bottom: 0[0x0]tw  left: 0[0x0]tw
> top:
>     0[0x0]tw right: 0[0x0]tw bottom: 0[0x0]tw  left: 1[0x1]enum top:
> 1[0x1]enum
>     right: 1[0x1]enum bottom: 1[0x1]enum  left: Null top: Null right: Null
>     bottom: Null  left: Null top: Null right: Null bottom: Null  1[0x1]enum
> 0|1
>     1 [none]|left: Auto top: Auto right: Auto bottom: Auto  Auto  0[0x0]tw
> Null
>     Auto  0[0x0]tw  Null  0 Auto  |0 0 0 Normal  Normal  0[0x0]tw  Normal  |0
> 8
>     1,000000 0 0 0 0 0 0 0 0 0 0 0 [none]|0 0 0 -1 1 |0 0 0 Null
>   Node 2:
>     TableOuter(table)(144) 0x10004 0,26437,4872,600, |null
> attr|-16777216|left:
>     0[0x0]tw top: 0[0x0]tw right: 0[0x0]tw bottom: 0[0x0]tw  left: 0[0x0]tw
> top:
>     0[0x0]tw right: 0[0x0]tw bottom: 0[0x0]tw  left: 1[0x1]enum top:
> 1[0x1]enum
>     right: 1[0x1]enum bottom: 1[0x1]enum  left: Null top: Null right: Null
>     bottom: Null  left: Null top: Null right: Null bottom: Null  1[0x1]enum
> 0|1
>     1 [none]|left: Auto top: Auto right: Auto bottom: Auto  Auto  0[0x0]tw
> Null
>     Auto  0[0x0]tw  Null  0 Auto  |0 0 0 Normal  Normal  0[0x0]tw  Normal  |0
> 8
>     1,000000 0 0 0 0 0 0 0 0 0 0 0 [none]|0 0 0 -1 1 |0 0 0 Null
>   frame bbox mismatch: 0,0,4824,600 vs. 0,0,4872,600
> 
>   (This makes more sense if it's not wrapped. See
>     http://www.mozilla.org/newlayout/doc/regression_tests.html
>    But not much more.)
> 
>   I would want to mark up
>     - the Running veryify test line
>     - the Writing regression data line
>     - the Comparing to line
>     - the filenames in each of those
>     - the frame bbox mismatch label
>     - its vs. value
>     - the node labels
>     - the frame type (TableOuter(table))
>     - each name-value pairing in the output line
> 
>   However, it does not seem to me that marking these with <samp> would be the
>   right thing to do any more than marking up function names, variable names,
>   and keywords in a code sample with <code> would be the right thing to do.
>   Either those are both right, or they're both wrong.
> 
>   Please specify.

Seems like for this level of detail you'd just want to use <span>, since 
you are conveying semantics that aren't describable in HTML.

What would you want the spec to say, exactly?


> User Input (<kbd>)
> ------------------
> 
>   # The kbd element represents user input (typically keyboard input,
>   # although it may also be used to represent other input, such as
>   # voice commands).
> 
>   Can we have some examples for marking up GUI elements? E.g.
> 
>     Don't press the Emergency button.
> 
>     Go to Tools > Options... and select the General tab. Change
>     the Indentation Type radio from Tabs to Spaces, check the
>     Auto-Indent box, and type 4 into the Indent Spaces box.
> 
>   Those should be marked up so that one can use a style sheet to
>     - make "Emergency" look like a button
>     - display "Tools" and "Options" in the menu font
>     - make "General" look like a tab
>     - make "4" look like it's typed inside a text input
>     - and use the appropriate label fonts for "Indentation Type",
>       "Tabs", "Spaces", "Auto-Indent", and "Indent Spaces".
> 
>   # When the kbd element is nested inside another kbd element, it
>   # represents an actual key or other single unit of input as
>   # appropriate for the input mechanism.
> 
>   So "Press the Esc key" would be marked up as
>     <p>Press the <kbd><kbd>Esc</kbd></kbd> key</p>
>   ?

There are examples at the moment, but I'm not sure it's worth adding more. 
(The examples vaguely cover the kind of things you mention, though not in 
that level of detail.) Let me know if you really think the spec needs 
more.


> Superscripts and Subscripts (<sup> and <sub>)
> ---------------------------------------------
> 
>   # marking up mathematical, but
> 
>   "mathematical" should be replaced with a noun.

Long since fixed.


> Quotes (<q>)
> ------------
> 
>   * You should probably add some notes on presentation, esp. wrt
>     quote mark generation.
> 
>   * You need to explain that <q> should only be used for actual
>     quotations, not as a shortcut for &ldquo; and &rdquo;. (I've
>     seen it abused that way, but I forget where..)

The text requires punctuation now. I'll be mailing the www-style group in 
due course.


>   One nit: Please provide actual titles for the sections (as I have
>   done here) rather than just putting the element name. (But don't
>   leave out the element name either.)

I may change this at some point, but for now I'm sticking with element 
titles only.


On Thu, 12 May 2005, fantasai wrote:
> 
> Figured out what was bothering me about the first sentence.
> 
>   # The strong element represents strong importance for its contents.
> 
> Change "strong importance" to "importance stress". This also puts it in 
> parallel with "emphatic stress".

Not sure I understand why that would be an improvement.


On Thu, 12 May 2005, Maniac wrote:
> > 
> >   There doesn't seem to be any appropriate markup for literals in HTML.
> > 
> >   For example:
> > 
> >      The words 'elude' and 'allude' are frequently mixed up.
> > 
> >   The formatting for such elements varies freely: I've seen single quotes
> >   (which I prefer), double quotes, and italics. It is therefore stylistic,
> >   and should be controlled (or controllable) with CSS.
>
> Not so freely in fact. For example in russian typography these things 
> should be marked up only with quotes (U+00AB and U+00BB). Simple double 
> quotes (") are however more widely used and single quotes (') are also 
> used but mainly in tech-savvy environment. But speaking of italics as a 
> way of marking up literals - this just won't be understood within 
> majority of people. Italics in russian typography is quite rare and may 
> be associated perhaps only with emphasis, not literals.
> 
> That said I agree that it should be controllable with CSS. But since 
> it's not entirely stylistic it shouldn't be controlled only by 
> stylesheet.

Does the current spec cover this to your satisfaction?


On Sat, 23 Jul 2005, fantasai wrote:
>
> <dfn> excludes <dfn>. Would it make sense for it to also exclude <i>? 
> And should <i> exclude <i> and/or <dfn>, too?

Given the current definitions, I don't really think so.


> And shouldn't they both require significant inline content?

That concept is gone now.


On Sun, 24 Jul 2005, R.J.Koppes wrote:
> 
> <dfn><dfn /></dfn>
> - this is not allowed
> 
> <dfn><i /><dfn>
> - this makes sense, the defining term can contain an instance of a
> previously defined term.
> 
> <i><i /></i>
> - this would be an instance of the above
> 
> <i><dfn /></i>
> - maybe this can occur, say you have something like:
> <p>The <dfn><abbr title="For Inspiration and Recognition of Science and
> Technology">FIRST</abbr> LEGO League</dfn> is a tournament, blahblah</p>
> <p>The first word in <i><dfn><abbr title="For Inspiration and Recognition of
> Science and Technology">FIRST</abbr></dfn> LEGO League</i> actually is an
> abbreviation meaning blahblah</p>
> 
> would this be an apropriate example? This is actually similar to case 2, 
> but the other way around.

I don't think <i><dfn/></i> is likely to make much sense (and I'm 
skeptical of the example above) but I don't think we should disallow it.


> Is the order of <dfn> and <i> of importance anyway? should <dfn> always 
> before any instance of it? would an occurence of an instance before the 
> term has been defined actually be an instance? (i think order is of no 
> importance) should there be something about this in the spec?

I'm not sure what we would say that would be of any use.


On Thu, 26 Jan 2006, Alexey Feldgendler wrote:
> 
> The simplest, and actually the one being discussed:
> 
> <em>
>   <p>Paragraph 1</p>
>   <p>Paragraph 2</p>
> </em>
> 
> Why not? These two paragraphs are highlighted with emphasis. What's 
> wrong here, in the semantical sense?

I'm not sure what it would mean to place stress emphasis on multiple 
paragraphs! I could see the argument with <strong>, e.g. for a big 
warning, but even then this is rare enough that I don't think it's a big 
deal to have to say:

   <p><strong>Paragraph 1</strong></p>
   <p><strong>Paragraph 2</strong></p>


> The classification of elements into "block" and "inline" is purely 
> presentational (in fact, even the words "block" and "inline" themselves 
> are bound to the graphical representation of a document and lose their 
> meaning for voice rendering, where there are no "lines").

"Block" and "inline" as terms are gone now. There's just "Flow content", 
some of which is "phrasing content", some of which is "embedded content".


> I think the rule of not putting block elements inside inline elements 
> shouldn't be applied to elements themselves. It should rather be applied 
> to the computed values of "display" property after evalutaion of CSS: 
> "In a graphically rendered document, elements with display: block 
> shouldn't be directly nested inside elements with display: inline". 
> Breaking this rule would leave it undefined how to calculate the 
> positions and dimensions of the elements. On the other hand, for voice 
> rendering there is no difference between display: block and display: 
> inline (the only value that makes a difference is display: none), so 
> there's no need to inforce the correct inline/block nesting.

CSS is a whole different layer, I'd rather not mix it into the HTML 
conformance issue.


On Thu, 26 Jan 2006, Alexey Feldgendler wrote:
>
> This confirms the point that the classification of elements into 
> block-level and inline-level is just a convention not backed by a 
> semantic requirement. Well, it establishes a rule about the valid and 
> invalid element nesting, which does help error recovery. But as we are 
> discussing the very error recovery at this time, maybe we should review 
> this rule if it helps build a saner DOM for some pathological but widely 
> used markup?

I think the way the rules are phrased now makes this somewhat moot. Some 
elements accept any flow content (including phrasing content), others 
accept only phrasing content.


On Mon, 8 May 2006, Henri Sivonen wrote:
>
> Moreover, the content models of <i> and <b> should probably allow 
> struct-inline as well.

That concept is gone now too.


On Thu, 3 Aug 2006, Jonathan Worent wrote:
>
> I have just recently become interested in the work WHATWG is doing. I 
> apologize if something like this has already been suggested.
> 
> I'd like to suggest adding a level attribute to both em and strong tags. 
> This attribute would be used to set the level of emphasis/importance, 
> rather than by nesting. The level attribute would take a negative 
> integer, to indicate, de-emphasis/less importance, a positive integer, 
> to indicate increasing emphasis/importance, or a "0", to indicate the 
> default. If the default is desired the level attribute could be left 
> off, unless it is nested within an element that has changed the level 
> (though I can't think of any examples where this would be good 
> practice). There would need to be a reasonable limit for the number of 
> levels, both positively and negatively
> 
>     Examples:
>         <em level="2">I am getting <em level="3">very</em> angry.</em>
>         
>         I don't spend every waking moment on the computer, <strong 
>         level="-1">although my wife thinks otherwise</strong>.
> 
>         <strong level="1">This is a bad example of where the <strong 
>         level="0">default level</strong> has to be explicit 
>         stated.</strong>
> 
> I think a level attribute is better than nesting because it allows for 
> reducing the emphasis/importance below normal. Nesting can only increase 
> this.

I don't understand the use case. Why wouldn't you just say:

   <em>I am getting <em>very</em> angry.</em>

   I don't spend every waking moment on the computer, <small>although my 
   wife thinks otherwise</small>.

   <strong>This is a bad example of where the</strong> default level 
   <strong>has to be explicit stated.</strong>


> A use-case where de-emphasis would be needed is in marking up a 
> transcript. (WCAG requires this for accessibility) De-emphasis could be 
> used to indicate that the speaker whispered.

<small> handles this case now. Typically though you don't need markup for 
this kind of side-comment, just use parentheses.


> A use-case where indicating less importance would be needed would be 
> digression. This is different than aside IMHO.

I'm not sure why you would mark a digression up.


> I understand that this is not backwards compatible. But, IMHO, neither 
> is nesting elements. Future browsers already will have to change to 
> understand that nesting em or strong increases emphasis/importance. They 
> could also be changed to understand the level attribute.

I don't think the backwards-compatibility problem of nesting <em> or 
<strong>, if one considers there to be any such problems at all, are 
anywhere near as serious as those introduced by a new attribute.


> If this cannot be done then I would suggest as an alternative: Add 2 new 
> elements. One for indicating de-emphasis, One of indicating less 
> importance. I leave the naming of them to you.

Less importance can be done just by ending the <strong> element. Side 
notes can be marked with <small>. I don't think there is a concept of 
"less than normal stress emphasis" that really makes sense to mark up.


On Thu, 8 Feb 2007, David Latapie wrote:
> 
> For now, we have an unbalanced system [for emphasis]:
> 
> - not symmetrical: +1, +2, nothing for minus

Just close the elements.


> - incremental: one value basically does the same as the previous one, 
> just stronger. This is the only I case I can think of where such a 
> thing happens in the specs

I'm not sure what you mean here.


> - limited levels: why two levels? why not three, six, twelve? I agree 
> more than four is quite useless, but we shall not limit ourselves there. 
> Let's take CSS as an example:

There's no limit with nesting.


> strong is really just a supercharged em, semantic-wise.

Not in HTML5. :-) <strong> and <em> have very different meanings; one for 
importance, one for stress emphasis.


On Thu, 8 Feb 2007, Nicholas Shanks wrote:
>
> So there have been a number of complaints that the only way to 
> de-emphasize something is via <small>. I am one such complaining voice. 
> There have been several suggested solutions proposed too. I would like 
> to give my opinions on a few of those:
> 
> <em level="-1"> or similar attribute
> 
> My concern here is whether this is supposed to be an absolute or 
> relative value. Would <em level="3"><em level="-1">this</em></em> result 
> in an emphasis level of 2 (relative) or −1 (absolute). What would 
> level="+3" mean?
> 
> <de-em>, <de-emph>, <subdue> or other new element
> 
> I think a new element would be better, but the English language seems to 
> lack an antonym for "emphasis".
> http://thesaurus.reference.com/browse/emphasis
> http://www.synonym.com/antonym/emphasis
> Short of proposing a new word (“antiphasis" ?) and deriving an element 
> from that I'm not sure there's anything that would be suitable.
> 
> Antiphasizing: the act of coughing over or mumbling something you say 
> when you don't want others to hear it. ;-)
> 
> 
> Repurposing an existing element
> 
> I don't think there's anything that would be suitable. Using <small> 
> would give the wrong impression to HTML authors.
> 
> 
> Does anyone else have better ideas?

I don't understand the problem. Why does <small> not solve it? What is the 
problem exactly?


On Thu, 8 Feb 2007, Benjamin Hawkes-Lewis wrote:
> 
> This is somewhat tangential to the Great Emphasis Debate, but I just 
> wanted to suggest that, in this new medium of ours, the relationship 
> between main text and note is arguably not so much one of de-emphasis as 
> of hypertext.

Notes are covered by the <aside> element.


On Fri, 9 Feb 2007, Mikko Rantalainen wrote:
> 
> I believe that <aside> and <small> are different from de-emphasis (that 
> would be <dem> IMHO). However, the <dem> element wouldn't be that often 
> used and it would be vital for it to be easily implemented. A new 
> element with specified semantics and a simple default CSS style would be 
> a nice choice. An example *implementation* could be a single CSS rule:
> 
>  dem { opacity: 0.8 }
> 
> How hard it would be to implement the behavior David described above? 
> Take any existing UA as a base.

Would would this element mean?


> And why do I think that <aside> and <small> are different from <dem>? 
> Because I think <aside> (or a footnote) is something you can safely 
> ignore and is usually orthogonal to the rest of the content. <small> is 
> something you usually skip but you must be aware of the content (e.g. a 
> copyright or license boilerplate) - the key here is that the content is 
> often repeated but if you have read it *once*, then you may skip it 
> later. The <dem> would be something that you may skip without reading it 
> once but which is not orthogonal to the rest of the content and as such 
> shouldn't be considered equal to <aside>.
> 
> Example:
>  <p>One should <em>never execute <code>rm -rf /</code>
>  in a UNIX shell <dem>because doing so would remove
>  everything in the system</dem></em>.</p>
> 
> Here I think that the explanation is also something that should be 
> emphasized. However, the reader can safely ignore the explanation. I 
> think that <dem> shouldn't be considered to be equal strength to <em> 
> but something less. Logically it could be -0.5 emphasis.

Why not:

   <p>One should <strong>never execute <code>rm -rf /</code> in a UNIX 
   shell</strong> (because doing so would remove everything in the 
   system).</p>

...? That seems cleaner and just as clear.


On Fri, 9 Feb 2007, David Latapie wrote:
> 
> So, if I understanf you correctly, <small> is short for "important 
> legalse-like SMALL-print" and not just "SMALL-text">, right?

The spec defines it as "small print (part of a document often describing 
legal restrictions, such as copyrights or other disadvantages), or other 
side comments".


On Fri, 9 Feb 2007, David Walbert wrote:
> 
> Logically, if <small> represents "small print" legalese, I agree that it 
> is not de-emphasized. (That kind of small print is often small precisely 
> because it IS important, and the authors would probably rather you not 
> read it!)
> 
> However, looking at the three examples in the spec, I would question the 
> value of the <small> element.
> 
> ___
> 
> First example: the footer contains contact information and a copyright.
> 
> <footer>
>  <address>
>   For more details, contact
>   <a href="mailto:js@example.com">John Smith</a>.
>  </address>
>  <p><small>� copyright 2038 Example Corp.</small></p>
> </footer>
> 
> Here, <small> is a copyright notice. In HTML 5 I'd use <p 
> class="license"> and style it appropriately, since "license" is now a 
> restricted semantic class.

Unfortunately we removed class="license". Part of the reasoning was that 
<small> handled this case enough. :-)


> In this second example, the small element is used for a side comment.
> 
> <p>Example Corp today announced record profits for the second quarter 
> <small>(Full Disclosure: Foo News is a subsidiary of Example 
> Corp)</small>, leading to speculation about a third quarter merger with 
> Demo Group.</p>
> 
> This side comment is already de-emphasized, because it is in parentheses 
> -- the standard print convention (in English, at least) for 
> de-emphasizing text within the flow of other text. Since there is 
> already a typographical marker of de-emphasis, the <small> tag would 
> have added value only to a machine (if it would even then), and if I 
> wanted text to appear in parentheses I wouldn't also wrap it in a tag -- 
> just as I'd use either quotation marks or the <q> tag, but not both. In 
> this case the parentheses and <small> tag are not technically redundant, 
> but they're awfully close.

I agree, that's why I don't think we need an element for de-emphasis.

In the example above, though, you'd want both elements because people 
often style that particular side note by making the text smaller.


> In this last example, the small element is marked as being important 
> small print.
> 
> <p><strong><small>Continued use of this service will result in a 
> kiss.</small></strong></p>
> 
> Since there's no context given, I can't comment. But if it's emphasized 
> I'm not sure why anyone would want it to appear as "small print." That 
> would, visually, de-emphasize it.

It's important, but it's small print. They are not mutually exclusive 
states.


> I would also ask whether a semantic element for "small print" legal text 
> has real practical value. In each of these examples, it is obvious from 
> the text or context that what's enclosed in the <small> tag is legal 
> text or some kind of disclaimer. Would there ever be a need for legal 
> text to be findable by machine? If so, wouldn't the text of a license 
> agreement have to be all in <small> text, and would anyone ever actually 
> do that? Does the "Full discloser" count as legal text for a machine's 
> purposes?

It's not about finding legal text, it's about marking the text as a "small 
print" sidenote. It's almost equivalent (when used in a paragraph) to an 
inline <aside>.


> And finally, I haven't used <small> since maybe 1998 -- in part because 
> once I started learning about web standards I quit using anything that 
> sounded purely presentational. Even if <small> has semantics, it sounds 
> from the name like it is purely presentational. I expect I'm not alone 
> in making that (incorrect) assumption. (Most people don't actually read 
> the entire specification.)
> 
> I admit I don't know how <small> is used in the wild -- can anyone 
> enlighten me? If the examples in the spec are typical, I'd suggest that 
> some kind of microformat for legal text might be more appropriate than a 
> "small print" element.

If the examples in the spec are typical, it seems that just "paving the 
cowpath" as people say would be best way forward. :-)


On Fri, 9 Feb 2007, David Walbert wrote:
> 
> In looking for a print analog the only common cases I can think of for 
> de-emphasized text are notes (footnotes, endnotes, etc.) and 
> parenthetical text. HTML 5 already has elements for asides & notes. As 
> for parentheses, if the typical web author wants to insert parenthetical 
> text and is writing in a language that uses parentheses, he/she will use 
> parentheses. They're obvious, they're available from the keyboard. If 
> one marked a piece of text as parenthetical using an HTML element, one 
> would quite likely want it to be styled inside parentheses, and we all 
> know how inconsistent CSS-generated content is. Few authors use the <q> 
> tag, for the same reasons.

On Fri, 9 Feb 2007, Michel Fortin wrote:
>
> As another general comment on this discussion, I will say that I agree 
> with David Walbert's observations that it is impossible to to 
> "de-emphasize" something. However, I believe that what some means here 
> by de-emphasising something is that they want to *emphasize the 
> unimportance* of what they're saying. To me, "de-emphasis" is just 
> another kind of emphasis where you state that the reader doesn't really 
> need to know that thing but the author want to say it anyway.
> 
> Like David, I think the best rendering for "de-emphasis" would be to use 
> parenthesis, notes, or asides depending on the exact nature of the 
> content. Frankly, I don't think we need to introduce any new element for 
> the general case of emphasizing the pointlessness of something. If an 
> element is introduced however, maybe <pointless> would be a better name, 
> less abstract and harder to misuse than anything derived from 
> "de-emphasis".

I agree with the above comments.


[At this point I trimmed many posts that just went around in circles 
repeating the points given above.]


On Fri, 9 Feb 2007, Michel Fortin wrote:
> 
> Can I suggest a <whisper> element then (or something similar)? I'm still 
> not convinced that it is needed or that it can have a good default 
> rendering, but it'd certainly be more to-the-point than the abstract 
> concept of "de-emphasis" which can be stretched to dozens of unrelated 
> use-cases.

I'm not convinced that it is needed either.


On Thu, 8 Feb 2007, �istein E. Andersen wrote:
> 
> Perhaps the most logical solution would be to keep only <em> as a 
> general emphasis element and allow i/b/u and possibly others to be used 
> at the author's discretion, but with the same semantics as <em>.
>
> The semasiologists amongst you are unlikely to approve of such a 
> flagrant lack of inherent meaning, but insisting on too fine-grained 
> distinctions, influenced by more or less arbitrary conventions in modern 
> Western typography, is not helpful either.

I think the current spec strikes a balance between those two extremes that 
is more useful than either extreme.


On Mon, 23 Apr 2007, Philip Taylor (Webmaster) wrote:
> 
> > a[n] HTML5 which, for instance, contain <i> with a revised purpose 
> > over what authors has used it for in the last decade.
> 
> Oh.  Groan.  However, it's reasonably clear the authors are writing 
> about proposed usages with at least some of which they are unfamiliar, 
> since the first example of its use is <p>The <i>felis silvestris 
> catus</i> is cute.</p> (note the lower-case "f" of "Felis").

Thanks, fixed.


On Fri, 2 Nov 2007, Matthew Paul Thomas wrote:
> 
> Yes, the current definition makes much more sense, though it buries the 
> point a bit. I think it would be more obvious to begin something like 
> "The i element represents a span of text where the typical typographical 
> presentation is italics, and no other element is more appropriate. (For 
> example, citations should instead use the cite element..."

The burying is somewhat intentional.


> > (I strongly feel that there is a difference between <div> used for 
> > grouping thematically related blocks, and <p> used for separating 
> > thematically related inline content, e.g. parts of a form. ...
> 
> Launchpad.net presents (for people registered) many forms where a text 
> field has not just a label, but also an explanatory caption of one or 
> two (or in one case five) sentences. These captions are unambiguously 
> paragraphs <p>, inside form rows <div>, inside forms <form>. If we 
> wanted to "separat[e] thematically related ... parts of a form" we 
> wouldn't use <p>; we'd use <fieldset>, because that's *exactly* what 
> <fieldset> is for.

This issue is mostly moot now given the new definitions.


On Fri, 1 Feb 2008, Richard Ishida wrote:
> 
> These are personal thoughts, unless the i18n WG decides to endorse them 
> later.
> 
> I like how the HTML5 spec defines <em> and <strong>, and to a point I 
> like the (distinct) explanations of <i> and <b>. But they are still 
> presented as somewhat vague presentational devices in that they can 
> cover a range of semantics:
> 
> <i> is suggested for things “such as a taxonomic designation, a 
> technical term, an idiomatic phrase from another language, a thought, a 
> ship name, or some other prose” and the examples suggest Latin names 
> for flora and fauna and dream sequences;
> 
> <b> is suggested for “key words in a document abstract, product names 
> in a review, or other spans of text” and the examples include special 
> eye-catchers and lede sentences.
> 
> And then follows the phrase “whose typical typographic presentation is 
> boldened/italicized”.
> 
> However...
> 
> In a blog post I wrote yesterday[1] I try to make the points that
> 
>    1. during localisation, people may want to separate the 
> presentational styling for the suggested uses where more than one 
> appears in a localised version of a document (ie. not all italicised or 
> boldened)
>
>    2. such things may not be typically boldened/italicised in other 
> scripts, ie. that may not be the best default in Chinese/Japanese
> 
> (See the blog post for details and examples: 
> http://rishida.net/blog/?p=134.)
> 
> Therefore…
> 
> The spec says that “The i/b element should be used as a last resort 
> when no other element is more appropriate.”, but I think it implies 
> that once you have exhausted the elements offered by HTML5, you have run 
> out of options. You haven’t. You could use class names to label 
> things.
> 
> So I would suggest an alternative wording along the lines of “The i/b 
> element should only be used as a last resort when no other element is 
> available and you want the text to be visually distinct when the text is 
> separated from its style sheet or you are in situation where you cannot 
> use a style sheet. This should only be used as a fallback device, 
> however. It is much better to use an i/b element with a class name that 
> describes the intent of the text, and associate that where possible with 
> a rule in a style sheet.”
> 
> For example, I would prefer the spec to change its examples slightly 
> like this:
> 
> <p>The <i class="taxonomy">felis silvestris catus</i> is cute.</p>
> <p>The term <i class="term">prose content</i> is defined above.</p>
> <p>There is a certain <i class="foriegn" lang="fr">je ne sais quoi</i> in the air.</p>
> 
> If one document contained all these examples, I would now be free to 
> restyle them individually and separately as I wish, without having to 
> trawl through the HTML to make the changes.
> 
> PS: I'd still secretly like to replace <i> and <b> with elements that 
> have non-presentation-related names, since I think it would help authors 
> think in a less presentation-oriented way, but I don't think I'd win 
> that battle.

I've added a class to the first example and added an encouragement to use 
classes for <i>.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'