Hi Cameron and Thomas,
Cameron McCormack wrote:
Yes, exactly the _SVG_ Document Factory. If you look at the
official DTD for SVG 1.0 & 1.1 it says that any 'svg' element
(no prefix) automatically gets 'xmlns=".../svg"'. In other words
on can easily view the SVG standard as saying that any 'svg' element
with no prefix is automatically in the SVG namespace.
But I think what determines if a document is an SVG document is whether
the document element is { "http://www.w3.org/2000/svg";, "svg" }. That a
DTD could enforce this is a side issue. Is it really allowable
behaviour for a UA to apply a DTD to a document even though there is no
DOCTYPE?
Also, it seems that this FIXED namespace declaration is turned off in
the SVG 1.1 DTD (with an IGNORE).
How about you only set the namespace for documents that have an SVG 1.0
doctype and a root 'svg' tag?
Or, should this content display some sort of warning (possibly
like the little yellow bar that appears in Firefox when popups are
blocked or if an appropraite plugin is not available)?
I think the more warnings there are out there the better. For Firefox we
can't (won't be allowed to by the powers that be) display one in the UI
since the browser is aimed squarely at end users. Currently we always
require namespaces to be declared explicitly so we seem to be the
strictest implementation out there. If we changed this in some way I'd
certainly want a warning in the JavaScript (now more a general content
author) Console.
So my leaning would be towards leaving the behavior as is for
version 1.0 & 1.1 documents and either out right failing or
producing a warning for 1.2 documents.
Regardless of whether it's acceptable for the DTD to be applied even if
it's not explicitly referenced with a DOCTYPE, since it looks like SVG
1.2 won't have a DTD produced for it I suppose this would allow this
"stricter" behaviour, either way.
I think setting the namespace for new 1.2 content would be bad. I think
a 1.0 doctype should be required before doing this. Perhaps a 1.1
doctype too if you want to break with the standards for compatibility
with existing content.
Regards,
Jonathan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
