This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The new text for the Working Group Decision on ISSUE-103 srcdoc-xml-escaping says that U+0020 needs to be escaped. <p class="note">Due to restrictions of <span>the XML syntax</span>, - in XML a number of other characters need to be escaped also to - ensure correctness.</p> + in XML the U+003C LESS-THAN SIGN character (<) needs to be + escaped as well. In order to prevent <a + href="http://www.w3.org/TR/REC-xml/#AVNormalize">attribute-value + normalization</a>, XML's whitespace characters — U+0009 + CHARACTER TABULATION (HT), U+000A LINE FEED (LF), U+000D CARRIAGE + RETURN (CR) and U+0020 SPACE — also need to be escaped. <a + href="#refsXML">[XML]</a></p> My reading of the XML spec suggests space does not need to be escaped. http://www.w3.org/TR/REC-xml/#AVNormalize "For a white space character (#x20, #xD, #xA, #x9), append a space character (#x20) to the normalized value." i.e. a literal space and an escaped space results in the same thing. The paragraph "If the attribute type is not CDATA, then the XML processor MUST further process the normalized attribute value by discarding any leading and trailing space (#x20) characters, and by replacing sequences of space (#x20) characters by a single space (#x20) character." does not apply since srcdoc is a CDATA attribute (and none of the allowed doctypes change that for srcdoc even if the UA uses a validating processor).
Hmm, actually HTML5 allows any doctype in XML, so that paragraph *could* apply if the author goes out of his way to change srcdoc to be something other than CDATA, but in that case we could assume that the author knows what he's doing and the note doesn't need to cover that case IMHO.
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: Rejected Change Description: no spec change Rationale: If you disagree with the decision, please use the WG process to handle it. I'm not going to change the text without instruction from the chairs, especially on this issue, where my whole objection to the issue in the first place was that adding this text would mean it would be micromanaged for months afterwards.
> If you disagree with the decision, please use the WG process to handle it. I don't disagree with the decision. I'm following the WG process here. http://lists.w3.org/Archives/Public/public-html/2010Oct/0211.html
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: see diff given below Rationale: Concurred with reporter's comments.
Checked in as WHATWG revision r5777. Check-in comment: this paragraph really shouldn't be in the spec in the first place, but since it's there, let's at least make it mostly correct http://html5.org/tools/web-apps-tracker?from=5776&to=5777
mass-move component to LC1