[svg-native] What should a browser do when it encounters one of these files

[litherum]

@heycam offered a good question. What is the relationship between SVG Native and the Web platform? What should a browser do when it attempts to open one of these?

The initial draft spec describes how browsers should render the document according to the SVG Native rules, and then goes on to recommend browsers treat SVG Native files the same way as they would treat any other native image file. Systems can have native jpeg image decoders, and they can have native SVG Native image decoders, and they should be treated the same way. This approach requires that such a resource can't exist as a raw <svg> tag in the middle of an HTML document; instead, it needs to be loaded as a remote file in either an <img> element or using CSS (e.g. background-image).

This approach has the benefit that an SVG Native file will look the same whether it's viewed in a browser or in another environment. It avoids the problem where authors will put in nonconforming elements/attributes because it works in their authoring environment. And, it avoids the problem where browsers (historically) refused to disable features for different profiles of SVG, by implementing support using the system renderer.

However, this is a complicated issue, and is probably worth broader discussion, which this issue can track.

[svgeesus]

This is related to the MIME type issue. Browsers provide different handling when the MIME type differs. And as I said in my earlier comments this specification needs to have a MIME appendix.

For browsers, a different MIME type is more robust (for getting the content treated differently) than version or baseProfile attributes (which have been used before, and are typically ignored).

[dirkschulze]

Let's resolve on #664 before getting to this issue first.