This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12178 - Simplify/Remove the semantics of <b> and <i> or the description of it
Summary: Simplify/Remove the semantics of <b> and <i> or the description of it
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-24 23:33 UTC by KangHao Lu
Modified: 2011-08-04 05:05 UTC (History)
6 users (show)

See Also:


Attachments

Description KangHao Lu 2011-02-24 23:33:57 UTC
== Problems ==

The current definition of <b> and <i> uses the term "typical typographic presentation" which makes <b> and <i> look like presentational elements and violates the design principle of HTML5. For example, there is no italics in a typical CJK environment and the word "typical" is ambiguous. Typical in a given set of documents? Typical in part of the world? Also, the paragraph of the description of a phrasing element should be a clean definition of its semantics, and it should avoid mentioning use cases that don't exist globally.

The current definition allows multiple interpretations:

<b>
- Keywords
- Keywords + Text offset
- Text offset - strong
- Text offset
- Text offset that is typically boldened (what does typical mean here?)

<i>
- Alternative voice/sound
- Alternative voice/sound + Text offset 
- Text offset - emphasis
- Text offset that is typically italics

as compared to

<small>
- side comments

It would be nice to know what the original intention was.

== Suggestion 1 ==

Assuming the original intention was <b> = "keywords + text offset" and <i> = "alternative voice/sound + text offset", the 4.6.27 Usage summary should be corrected as such ("keywords and text offset" and "alternative voice and text offset) so that it won't give the author the impression that the pivot use cases are the main use cases.

I suggest we replace

 # The i element represents 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.

with 

 | The i element represents a span of text in an alternate voice or mood, or
 | otherwise offset from the normal prose. The i element should be used as a 
 | last resort.

and a note or second paragraph

 | Note: As browsers are suggested to rendered the i element as italicized text
 | , the use cases include ...

similarly replace

 # 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.

with

 | The b element represents keywords, or otherwise offset from the normal prose.
 | The b element should be used as a last resort.

and a similar note.

I suppose mentioning b/i as last resort elements as early as possible would meet the original intention of making HTML5 a semantic language.

== Suggestion 2 ==

<b> = "keywords" and <i> = "alternative voice/sound". Remove messy and inconsistent fig leaf.

== Suggestion 3 ==

<b> = "text offset" and <i> = "text offset". So, 

 | The i element represents an offset from the normal prose. The i element
 | should be used as a last resort.

and the note.

This is my personal preference.

== Suggestion 4 ==

<b> = <i> = <span> = Representing nothing
Comment 1 Ian 'Hixie' Hickson 2011-05-05 07:14:37 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Partially Accepted
Change Description: see diff given below
Rationale: Yeah, the problem you raise has been bugging me for some time. I hadn't fixed it before because I thought I was the only one. I've tried to fix it now with better terminology.
Comment 2 contributor 2011-05-05 07:15:25 UTC
Checked in as WHATWG revision r6079.
Check-in comment: clarify element definitions
http://html5.org/tools/web-apps-tracker?from=6078&to=6079
Comment 3 Michael[tm] Smith 2011-08-04 05:05:45 UTC
mass-moved component to LC1