On Aug 24, 2009, at 01:05, Micah Dubinko wrote:

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.

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"')

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.

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.

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.

OK. Your proposal specifically suggested changes to what specific DOM methods return, though.

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.

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.)

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.

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.

-- Henri Sivonen hsiv...@iki.fi http://hsivonen.iki.fi/

_______________________________________________________________________

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