|65 earlier messages|
|Simon St.Laurent||Aug 6, 2009 1:06 pm|
|Michael Ludwig||Aug 6, 2009 1:13 pm|
|Michael Ludwig||Aug 6, 2009 1:16 pm|
|Michael Ludwig||Aug 6, 2009 1:39 pm|
|Liam Quin||Aug 6, 2009 2:43 pm|
|Michael Ludwig||Aug 6, 2009 3:11 pm|
|Michael Kay||Aug 6, 2009 3:32 pm|
|rjel...@allette.com.au||Aug 6, 2009 8:21 pm|
|rjel...@allette.com.au||Aug 6, 2009 8:32 pm|
|Michael Kay||Aug 7, 2009 1:10 am|
|michael odling-smee||Aug 7, 2009 1:28 am|
|Michael Kay||Aug 7, 2009 1:33 am|
|michael odling-smee||Aug 7, 2009 2:24 am|
|Michael Ludwig||Aug 7, 2009 3:00 am|
|Dave Pawson||Aug 7, 2009 8:50 am|
|Liam Quin||Aug 7, 2009 9:08 am|
|Micah Dubinko||Aug 7, 2009 5:03 pm|
|Micah Dubinko||Aug 7, 2009 5:05 pm|
|Robert Koberg||Aug 7, 2009 5:08 pm|
|Dave Pawson||Aug 12, 2009 12:34 am|
|Dave Pawson||Aug 13, 2009 12:35 am|
|Henri Sivonen||Aug 13, 2009 11:47 am|
|Micah Dubinko||Aug 23, 2009 3:05 pm|
|David Carver||Aug 23, 2009 4:21 pm|
|Henri Sivonen||Aug 24, 2009 4:03 am|
|Subject:||Re: [xml-dev] Pragmatic namespaces|
|From:||Henri Sivonen (hsiv...@iki.fi)|
|Date:||Aug 24, 2009 4:03:08 am|
On Aug 24, 2009, at 01:05, Micah Dubinko wrote:
On Aug 13, 2009, at 11:47 AM, Henri Sivonen wrote:
Example: <head> <title>Document title</title> <com.example.project> <com.example.id>123521123</com.example.id> </com.example.project> </head>
In this example document.getElementsByTagName("id") would return the innermost element. So would document.getElementsByTagNameNS("com.example", "id")
I think here your proposal goes into the weeds.
The #1 flaw with Namespaces & DOM Level 2 is that the identifiers that are fundamental to the operation of software were different from the identifiers in plain XML 1.0 or DOM Level 1. Your proposal repeats this mistake by making the platform behave radically differently if you have a JS program running on a browser that doesn't implement your proposal and if you have the same JS program running on a browser that implements your proposal.
It's already the case that older browsers will interpret things differently. Old browsers won't treat <svg> as something in the SVG namespace, but newer ones will.
I thought the point of "extensions" was that they are mainly hooks for scripts. As such, they could work on existing browsers, too, if they were a mere naming convention. In contrast, SVG requires quite distinctive native 2D rendering support that can't be achieved with mere scripting and styling macros on top of the HTML4+CSS functionality.
As for unilateralist browser-sensitive extensions like <blink> and <marquee>, it would probably have been better to make them less attractive than the elements minted through a peer review. Thus, it would have been better to make them <com.netscape.blink> and <com.microsoft.marquee> without a mechanism to hide the prefixes.
Since there are (presumably) far fewer HTML documents with multiple dots in element names than with <svg> elements, one could argue that this doesn't cause significant backwards compatibility problems either.
Actually, SVG-in-text/html parsing takes special steps to deal with legacy content that contains SVG bit due to cargo cult copying and pasting. Specifically, the parser breaks out of SVG at the slightest hint of cargo cult copying and pasting: http://www.whatwg.org/specs/web-apps/current-work/#parsing-main-inforeign (The cases that say: 'A start tag whose tag name is one of: "b", "big", "blockquote", "body", "br", "center", "code", "dd", "div", "dl", "dt", "em", "embed", "h1", "h2", "h3", "h4", "h5", "h6", "head", "hr", "i", "img", "li", "listing", "menu", "meta", "nobr", "ol", "p", "pre", "ruby", "s", "small", "span", "strong", "strike", "sub", "sup", "table", "tt", "u", "ul", "var" A start tag whose tag name is "font", if the token has any attributes named "color", "face", or "size"')
By its very nature, recent HTML standardization work has been about getting browsers to change how their parsers operate. I can flip a switch in my Firefox and enable HTML5 mode, which has slight differences in how my browser would otherwise work.
Except for the SVG and MathML stuff, the changed behaviors (compared to the old HTML parser in Gecko) fall mainly into one of two buckets: 1) Changes from old Gecko behavior to align with IE or WebKit behavior 2) Changes from old behavior of any browser in order to make the parser never read back from the DOM in order to allow the DOM and the HTML parser to live in different threads
The SVG and MathML changes are sometimes generalized to mean that browsers are now doing HTML extensions or namespaces. That's not what's happening. The SVG and MathML support is about taking the browser-native functionality investment that has already been made but that has been tied to XML parsing and enabling it in the text/html world.
It is incorrect to extrapolate that it's now OK to use Namespaces in text/html for purposes other than salvaging investments in functionality previously implemented but tied to XML.
The other issue that came up in discussions is what the proper scope of a proposal like this should be. Does it affect only the HTML syntax rules, or could something be dreamt up that would supplant/ replace xmlns in XML documents as well? That's a wide open issue still.
I think it's a problem in terms of the DOM Consistency design principle if the same syntax doesn't produce the same DOM on both sides of the fence. The simplest way to make progress is to stick to things that don't require any changes to the XML 1.0 4th ed. + Namespaces 1.0 layers on the XML side and that don't trigger any Namespaces layer processing (i.e. don't use the colon).
Using reverse DNS identifiers as a naming convention without affecting how the DOM/Infoset is constructed meets these requirements.
In your example, the local name of the innermost element MUST be "com.example.id" for compatibility with existing behavior.
Based on your following comment, it's not clear if you mean existing behavior of parsers or of the DOM API...
Parsers and DOM Level 2 are rather heavily coupled. I meant in terms of the DOM API, in terms of the Infoset, in terms of the XPath data model, in terms of Selectors and in terms of the browser-internal APIs.
Changing what document.getElementsByTagName() returns here is not something that's open for discussion. (As in, the probability of a browser vendor shipping with the API behavior change is virtually zero.)
Right, I wouldn't expect any DOM functions to change w.r.t. returning already-parsed DOM information.
OK. Your proposal specifically suggested changes to what specific DOM methods return, though.
The namespace of the innermost element as reported by the DOM isn't
really open for discussion, either. In an HTML5-compliant UA it is
"http://www.w3.org/1999/xhtml ", because this unifies the DOM with the XHTML5 side, where the namespace is constrained by the XHTML legacy to be "http://www.w3.org/1999/xhtml ". In legacy UAs, the namespace is null.
There are already special cases for SVG, MathML, etc., and already differences with legacy browsers. Is one more class of special cases beyond consideration? If so, why?
SVG and MathML are the only vocabularies that have already been implemented in multiple browsers and that need bringing into the text/ html world. New things can simply be added to the http://www.w3.org/1999/xhtml namespace. That's what was done with <video>, for example.
I think it is a bug that the organization of the W3C into Working Groups leaks to Web authors in the form of multiple namespaces. (Consider Conway's Law.) Changing the namespace of SVG and MathML or withdrawing Namespaces from the XML stack would be too late at this point, so the namespaces for SVG and MathML need to be grandfathered in, but there's no reason to keep minting more namespaces.
Requirement: widely-known namespaces must be parse to an equivalent DOM as xmlns
Think of this: it's entirely possible that the arrival of a distributed extensibility mechanism in HTML (not just XHTML) might forever change some respects of how HTML gets written, and how XML vocabularies are defined.
For example, say Tim's proposal mentioned earlier takes off. Then 1) many more HTML documents will be around using one-off <x.y.z> element names, and 2) future XML vocabularies might use element names like <foo.bar.baz> (possibly without namespaces) so that they could be readily used in HTML.
This is possible. (The XML vocabularies that wish to use dotted names
and be mixed readily into text/html should probably use the
http://www.w3.org/1999/xhtml namespace, though.)
But even if this happens, there still exists *some* list of older namespaces/vocabularies that people will want to use in HTML. I don't have a strong opinion of what that list might be, so I put together some typical examples in the initial proposal in an attempt to smooth over the inevitable transition process.
I think it's pretty simple to form the list of privileged namespaces: Take the set of namespaces supported by at least two browsers out of IE, Firefox, Safari and Opera in subtrees of application/xhtml+xml documents.
<html using.math="math">... <p> E.g. <math><msqrt><mi>π</mi></msqrt></math> </p> ...</html>
This already works in HTML5 without even having to use the using.math stuff. I invite you to try it in a trunk nightly build of Firefox after you've set the preference html5.enable to true in about:config.
What if these namespace assignments could happen in a less magical fashion?
Why shouldn't SVG and MathML work just as easily as HTML? What benefit is there for Web authors for having to use incantations like xmlns or using.math when it has now been shown by implementation this stuff can work without such incantations? I think the HTML5 way of incorporating SVG and MathML is less magic in the sense that there are no spells for the author to cast.
XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-...@lists.xml.org subscribe: xml-...@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php