5801 2008-06-25 12:36:23 +0000 Conformance rules for xmlns unintuitively different for HTML and foreign content 2010-10-04 14:47:21 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified All All VERIFIED FIXED NoReply P2 normal --- 1 hsivonen ian mike public-html-admin public-html-wg-issue-tracking zcorpan public-html-bugzilla oldest_to_newest 20850 0 hsivonen 2008-06-25 12:36:23 +0000 Currently, an attribute that in source looks like xmlns is allowed on any foreign content element if its value matches the namespace of the element. For HTML elements, though, the attribute that in source looks like xmlns is allowed only on root or if the parent is not an HTML element. While I understand that the cases have a different nature in DOM terms, this difference in rules is totally arbitrary from an authoring point of view, and the attributes are equally useless and talismanic in all cases. Please allow any HTML element to have an xmlns talisman with the value "http://www.w3.org/1999/xhtml". 20857 1 zcorpan 2008-06-25 13:51:25 +0000 Or it could be changed so that xmlns is only allowed on foreign content elements if their parent is in a different namespace than the element itself. 20866 2 ian 2008-06-25 19:51:11 +0000 Bah. 20874 3 hsivonen 2008-06-26 07:25:46 +0000 (In reply to comment #1) > Or it could be changed so that xmlns is only allowed on foreign content > elements if their parent is in a different namespace than the element itself. If one is writing aesthetically pure text/html from scratch, there's no point in putting any xmlns attribute anywhere. The purpose of allowing xmlns in text/html source is to support copying and pasting XML-serialized SVG and MathML and HTML-compatible XHTML. In the copying source, it is permitted to have redundant xmlns anywhere. Allowing it in some places but not others in the paste target is pretty arbitrary--particularly when allowing it *at all* is about supporting easy pasting. 20880 4 ian 2008-06-26 08:10:12 +0000 Actually the reason xmlns="" is allowed on SVG and MathML fragments is to enable copy/paste from XML source to text/html source, and the reason xmlns="" is allowed in on HTML fragments is to enable the same document to be used in text/html and XML contexts. Being able to copy from XHTML source to text/html has not been a goal. 20884 5 hsivonen 2008-06-26 08:30:49 +0000 (In reply to comment #4) > Actually the reason xmlns="" is allowed on SVG and MathML fragments is to > enable copy/paste from XML source to text/html source, and the reason xmlns="" > is allowed in on HTML fragments is to enable the same document to be used in > text/html and XML contexts. Being able to copy from XHTML source to text/html > has not been a goal. OK, perhaps it isn't a goal, but having different rules is still unintuitive (and adds conformance checker complexity rather pointlessly). Since doing what Simon suggesting for making rules consistent would break the SVG/MathML use case but doing what I suggested wouldn't break the use case for the HTML side, I continue to suggest what I suggested initially. (I think using xmlns attributes *at all* is aesthetically displeasing, but we already have huge aesthetic holes in the conformance definition, such as not requiring a particular source indent style.) 21001 6 ian 2008-06-30 23:48:17 +0000 r1834 32960 7 mjs 2010-03-14 13:14:29 +0000 This bug predates the HTML Working Group Decision Policy. If you are satisfied with the resolution of this bug, 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 This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.