- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 18 Mar 2010 11:26:48 +0100
- To: Maciej Stachowiak <mjs@apple.com>
- CC: Shelley Powers <shelley.just@gmail.com>, HTMLWG WG <public-html@w3.org>
On 17.03.2010 02:31, Maciej Stachowiak wrote: > > On Mar 13, 2010, at 6:14 AM, Shelley Powers wrote: > >> Please remove me as a volunteer for writing a change proposal for >> Issue 103. I believe that what I write for the change proposal for >> Issue 101 will preclude any need for this change proposal. > > I have removed you as volunteer: > http://dev.w3.org/html5/status/issue-status.html#ISSUE-103 > > If anyone else wants to volunteer to write a proposal for this issue, > please speak up. > ... I'm attaching a change proposal below. Note that removing @srcdoc (see ISSUE-100) would address this issue as well; but let's keep separate things separate. Best regards, Julian -- snip -- SUMMARY Specification is needlessly vague about XML escaping requirements when discussing iframe/@srcdoc. RATIONALE Spec should properly balance considerations for text/html and application/xhtml+xml. If the requirements are spelled out for the former the same should be done for the latter. DETAILS Spec currently says: "Note: In the HTML syntax, authors need only remember to use U+0022 QUOTATION MARK characters (") to wrap the attribute contents and then to escape all U+0022 QUOTATION MARK (") and U+0026 AMPERSAND (&) characters, and to specify the sandbox attribute, to ensure safe embedding of content. Note: Due to restrictions of the XML syntax, in XML a number of other characters need to be escaped also to ensure correctness." Replace the last sentence by: "Note: Due to restrictions of the XML syntax, in XML the U+003C LESS-THAN SIGN (<) needs be escaped as well." IMPACT 1. Positive Effects More clarity about the XML syntax; equal treatment of both formats. 2. Negative Effects Repeats information that already is defined somewhere else, but this applies to the paragraph about HTML as well. 3. Conformance Classes Changes None. 4. Risks The statement might not be totally accurate, in which case we can use the regular review and bug fixing process to get it right. That being said I believe it is accurate, as it's not about encoding characters in XML in general, but just about *additional* requirements for attribute values. REFERENCES None.
Received on Thursday, 18 March 2010 10:27:25 UTC