275042 - XML Parser to assume xmlns for SVG documents

Status: VERIFIED INVALID

(Core :: SVG, enhancement)

Description

[Peter L Jones]

This is a requests for the XML parser to assume (or supply) the SVG xmlns
attribute for

1) documents served as image/svg+xml
2) valid XML documents containing
<!DOCTYPE svg PUBLIC "-//W3C/DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
(or any other valid SVG document type) AND the root element of the document is
<svg> (or the element stated in the DOCTYPE directive).

Current behaviour limits the content that the SVG render gets to see as the
parser rejects the document as "having no stylesheet".

Whilst requiring the xmlns attribute on the tag defining the SVG document is
standards-conformant, the SVG documentation appears to promote the use of
image/xml+svg as a valid way of informing a browser that the content is SVG
markup.  (See section 2.3 of the W3C SVG1.1 TR.)  Hence much available SVG
content on the net does not include the xmlns attribute.

This change will improve the desirability of Firefox, as it will render more SVG
content without the need for third-party plugins.

Comment 1

[Henri Sivonen (:hsivonen)]

I am strongly opposed to this. Suggesting INVALID/WONTFIX.

1) External entities on the Web are an extremely bad idea, because it follows
from the XML spec that you can't count on them being supported by all UAs.
2) Doctype sniffing with XML is a bad idea. See
http://iki.fi/hsivonen/doctype.html#xml
3) Defaulting the xmlns attribute in the DTD is an extremely bad idea due to #1.
4) The sane XML compound document architecture is based on namespaces--not MIME
types.
5) Solutions that involve hacking the XML parser are very, very wrong. (OK, in
this case you'd actually hack the content sink but anyway.)

Please file a bug against Adobe if they ignore the namespace layer.

Comment 2

[Hixie (not reading bugmail)]

This is indeed invalid.

Comment 3

[Peter L Jones]

I wonder how many users Firefox would have if the same attitude - i.e. bugger
usability, follow the standards blindly - were followed with HTML.

The point of this bug is to get Firefox onto more people's disks because it
works - not because it rejects badly-formed XML.  Most *users* don't give a
monkey's about how well-formed the XML is, they just want to view content.

Sad response.  Very, very sad.  Almost enough to make me try writing a patch - I
think I'll probably badger a Community Edition hacker first, though.

Comment 4

[Anne (:annevk)]

(In reply to comment #3)
> The point of this bug is to get Firefox onto more people's disks because it
> works - not because it rejects badly-formed XML.  Most *users* don't give a
> monkey's about how well-formed the XML is, they just want to view content.

This bug is about SVG which isn't enabled by default. Besides, Mozilla has this
policy for XHTML as well and nobody complains.

HTML is a completely different thing. Although Mozilla does advocate valid HTML
by having a quirks, almost standards and standards compliant rendering mode it
would be stupid if we didn't have a compatible parser for all the incorrect HTML
usage on the web. (Besides, the HTML specification doesn't mention what should
happen with invalid HTML so from that light Mozilla is doing the right thing.)

The same argument does not apply to XML, since the error handling of XML is
decribed in the specification.

Comment 5

[Peter L Jones]

> This bug is about SVG which isn't enabled by default.
I may have misunderstood but I thought Firefox post-1.0 will have SVG enabled by
default?  If it's being "sold" on having SVG as a feature at 1.1 and beyond,
user expectation is going to be that when a site says it's displaying SVG, they
won't need a plugin to see it.

The point being, it will _look bad_ for Firefox if, having claimed to support
SVG, it still needs a plugin to view 95% of the SVG on the net.

If SVG isn't going to be enabled in Firefox by default, I'm not going to worry
about it.

Comment 6

[Henri Sivonen (:hsivonen)]

At this point SVG is only used by early adopters. There's a good chance that
they fix their docs. Early adopters who aren't prepared to deal with that kind
of thing should not be early adopters and do more harm than good to emerging specs.

> The point being, it will _look bad_ for Firefox if, having claimed to support
> SVG, it still needs a plugin to view 95% of the SVG on the net.

Breaking XML for the future is worse. 

The situation with SVG is radically different from the vast HTML soup legacy.

Comment 7

[Peter L Jones]

But the browser isn't breaking anything.

It's a reader.  It not creating content.  The tools that create content *must*
be strict.  It would be a serious bug if they were creating SVG content without
the xmlns attribute.

However, it is not necessary - nor, in my opinion even vaguely desirable - for
the browser to act as some for of Audit Tool that barfs when it hits malformed
content.  It should try *HARD* to get the content to the user.  If, by adding
the xmlns attribute, the content is still invalid, the SVG renderer won't
display correctly.  But at least it's tried.

To junk content that could be displayed correctly due to a failure in the
*content creator* is punishing the *content consumer*.  Wrong-headed and illogical.

Comment 8

[Henri Sivonen (:hsivonen)]

> But the browser isn't breaking anything.

Accepting bogosities breaks things because others are under pressure to
implement the same bogosities. This bug report is itself an example of an
attempt at applying such pressure.

> It would be a serious bug if they were creating SVG content without
> the xmlns attribute.

If the xmlns attribute was unnecessary, omitting it could not be a serious bug.

> To junk content that could be displayed correctly due to a failure in the
> *content creator* is punishing the *content consumer*.  Wrong-headed and 
> illogical.

It's not pretty, but that's the way the feedback loop works on the Web. The
content creator wants his/her content to reach an audience. To punish a content
creator, you need to prevent the content from reaching the audience.

Comment 9

[Hixie (not reading bugmail)]

Just to clarify -- when HTML says something should happen, we do follow it. When
HTML leaves things undefined, _that_ is when we do as you say, and attempt to
just be compatible with legacy content (and even then, we limit the extent to
which we do so by having a defined Quirks mode for this kind of thing).

In this regard, we are handling HTML and SVG in exactly the same way -- when the
spec is explicit, as it is in this case, we do what the spec says.