W3C home > Mailing lists > Public > public-html-admin@w3.org > January 2013

[Bug 20702] New: Spec has started to fake the represenation of named character entities

From: <bugzilla@jessica.w3.org>
Date: Fri, 18 Jan 2013 02:40:03 +0000
To: public-html-admin@w3.org
Message-ID: <bug-20702-2495@http.www.w3.org/Bugs/Public/>

            Bug ID: 20702
           Summary: Spec has started to fake the represenation of named
                    character entities
    Classification: Unclassified
           Product: HTML WG
           Version: unspecified
          Hardware: PC
               URL: http://www.w3.org/html/wg/drafts/html/master/embedded-
                OS: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: HTML5 spec
          Assignee: dave.null@w3.org
          Reporter: xn--mlform-iua@xn--mlform-iua.no
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-admin@w3.org,


(A) In Working Drafts up until bug 1430 was solved, the spec had represented
the glyphs by using a numeric character reference.

  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.

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


* 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
* Also, the WHATWG spec doesn't fake this way, and so WHATWG spec is more


* 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

You are receiving this mail because:
You are on the CC list for the bug.
Received on Friday, 18 January 2013 02:40:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:57:21 UTC