- 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