Bug 20702 - named-character-references.html fakes the represenation of named character entities
named-character-references.html fakes the represenation of named character en...
Status: CLOSED FIXED
Product: HTML WG
Classification: Unclassified
Component: Editor tools
unspecified
PC All
: P3 normal
: ---
Assigned To: Edward O'Connor
HTML WG Bugzilla archive list
http://www.w3.org/html/wg/drafts/html...
:
Depends on:
Blocks: 14430
  Show dependency treegraph
 
Reported: 2013-01-18 02:40 UTC by Leif Halvard Silli
Modified: 2013-05-14 21:46 UTC (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Leif Halvard Silli 2013-01-18 02:40:03 UTC
ISSUE:

(A) In Working Drafts up until bug 1430 was solved, the spec had represented the glyphs by using a numeric character reference.
http://www.w3.org/TR/2012/WD-html5-20120329/named-character-references.html#named-character-references

  Example code, Aacute: <span class="glyph" title="">&#193;</span>

(B) But starting with Working Draft of 25th of October 2012, the spec has started to fake it, by using self reference.
http://www.w3.org/TR/2012/WD-html5-20121025/named-character-references.html#named-character-references

  Example code, Aacute: <span class="glyph" title="">&Aacute;</span>


CONSEQUENCES OF THE BUG:

* The glyph column becomes unreliable - in broken and legacy user agents, unless the parser already has a correct implementation of the named character references, one cannot trust that the character displayed is the inteded character.
* Also, the WHATWG spec doesn't fake this way, and so WHATWG spec is more reliable.

PROPOSAL:

* Either clarify that the glyph column is not normative. 
* Or go back to the old solution where the glyph is 
  referenced as a numeric character reference
* Or adopt the solution in the WHATWG spec, which 
  represents the glyph as normal (unescaped) characters
Comment 1 Edward O'Connor 2013-03-01 21:34:58 UTC
Note that this is only a problem in the multi-page spec; the single-page spec is correct. Moving to "Editor tools" component as the culprit is most probably the spec splitter.
Comment 2 Edward O'Connor 2013-05-14 18:54:33 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: Accepted
Change Description: https://github.com/w3c/html-tools/commit/5f9f4a20b520da183084bb6a0c28cdac869ba0cc
Rationale: Fixed.
Comment 3 Leif Halvard Silli 2013-05-14 21:46:16 UTC
I’m relying you and David’s assessment.