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 24052 - Normal elements must not contain an ambiguous ampersand; and for HTML parser this appear to require a parse error, whereas it appear that browsers render the ambiguous ampersand verbatim (which seems [...]
Summary: Normal elements must not contain an ambiguous ampersand; and for HTML parser ...
Status: RESOLVED NEEDSINFO
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-10 15:36 UTC by contributor
Modified: 2013-12-10 23:13 UTC (History)
2 users (show)

See Also:

Attachments

Description contributor 2013-12-10 15:36:34 UTC 
Specification: http://www.whatwg.org/specs/web-apps/current-work/
Multipage: http://www.whatwg.org/C#elements-0
Complete: http://www.whatwg.org/c#elements-0
Referrer: https://www.google.ca/

Comment:
Normal elements must not contain an ambiguous ampersand; and for HTML parser
this appear to require a parse error, whereas it appear that browsers render
the ambiguous ampersand verbatim (which seems very practical). Is the
specification too strict or are implementations too lax? For myself I would be
happy to see the specification say that an ambiguous ampersand "should" be
rendered verbatim.

Posted from: 64.231.4.194
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36
Comment 1 Ian 'Hixie' Hickson 2013-12-10 23:13:31 UTC 
What is a "parse error" doesn't affect browsers, it's just about what should be reported to the user.

An ambiguous ampersand is required to be rendered verbatim as far as I can tell.

Do you have a concrete example showing the problem?