-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[svg-native] What should the file extension be? #664
Comments
#266 is related (request for a separate MIME type that behaves like other image types re security) MIME types and file extensions don't have to go hand-in-hand, of course. Having a separate file extension would make it easier for server configuration. But it's less useful for compatibility, since existing software wouldn't recognize it as SVG. |
The initial draft was proposing .svn extension, which I find rather confusing since Subversion is still quite popular. If a custom extension is used, I would opt for something like .svgn or .nsvg. |
I strongly suggest keeping When it comes to the MIME type the same may apply but on the server side. It took years to get I have a lot of scepticism about a new MIME type. |
That has a strong downside. Existing servers will serve it as image/svg+xml, which means that browsers will render it differently (in the case of features not supported by SVG Native) compared to an SVG Native renderer. We don't want that (see #665) |
@svgeesus We already agreed that a valid SVG Native documents will always look the same in a SVG Native viewer as in a full SVG renderer. If the document is not valid to the subset the behavior is unspecified anyway. Therefore, I don’t see a benefit of a new MIME type but rather the problem of SVG Native not being supported in many many years! Keep in mind that it doesn’t only take time to get the support into the source code of server software but significantly longer to servers directly. |
I know the difficulty of getting a new mime type etc, but just one comment re this... One of the use cases for this might be things like avatars for websites etc. Currently SVG is not typically allowed in these cases due to the perceived risk of SVG's scripting and interactivity. If there isn't a mime type to put in a file input |
@BigBadaboom that is a good point. What holds you up to still add SVG features to that document? Or the renderer to be a full-SVG-renderer able to process this SVG file? On the other hand, the MIME type maybe a way to enforce an SVG parser/renderer to go to a more strict mode if it would have one. It requires the whole industry to agree to fall back to the strict mode and not simply use the full-SVG parser to be effective though. That said, SVG used in an |
Another question, can we even keep |
Also, should there be an another extension for compressed SVG Native documents? If so, then the possible options could look like this: New extension, new mime type
New extension, old mime type
Old extension, old mime type
|
I would assume those sites wouldn't just trust the user and browser. I imagine they would at least run an SVG Native linter over the upload. |
Realistically no (in theory we could, but most servers map file extensions to MIME types 1:1 so this would be a very bad idea in practice). The use case of getting SVG in places (forum and wordpress image uploads, etc) where it is currently banned (because it has script execution, external references, and interactivity) is a significant one in my opinion. And that argues for a new MIME type. |
The SVG Working Group just discussed The full IRC log of that discussion<AmeliaBR> Topic: SVG Native file extension<AmeliaBR> Github: https://github.com//issues/664 <AmeliaBR> Chris: to me, file extension and MIME type are intrically connected. Most servers map extensions to media type. Different extensions same media type is do-able, but what's the point? <AmeliaBR> ... Given that there are servers that restrict the use of SVG (e.g., image uploads from user) because of security requirements, so a new extension & type is useful. <AmeliaBR> ... The media type is more important. File extension is just a representation of that. <AmeliaBR> Dirk: The downside of a new type/extension is that existing tools would not be able to open by default. <AmeliaBR> ... But, we are designing a format for the future. <AmeliaBR> Myles: Implementations can be divided & some don't currently support all of SVG, anyway. <AmeliaBR> ... Browsers should render it anyway regardless of Mime type, right? <AmeliaBR> Chris: Maybe, but it depends. Browsers do some sniffing, but won't do anything. <AmeliaBR> Dirk: Browsers may not be the main issue, since they're likely to be early adopters. <AmeliaBR> Amelia: It may also depend on what the new type is. If it's still a valid XML type, browsers may be able to handle it anyway. But desktop software is going to look at the extension. <AmeliaBR> ... Might need education for authors: you may need to save as a different extension. Servers may need to respond based on HTTP headers. <AmeliaBR> Sairus: Also worth considering whether we want to create a limited set & then expand it in the future. Would that be a different type? <AmeliaBR> Myles: If we end up creating too many different subsets, I think we then lose any benefit from having a defined subset at all. <AmeliaBR> Sairus: So we really want this to be the defined scope & then stick with that. <AmeliaBR> Dirk: Myles also mentioned the possibility of a distinction internally, e.g., a version attribute. <AmeliaBR> Chris: This is something we've dealt with before, in XML and in SVG. version attribute and profile attribute. And the end result is that it always gets ignored. <AmeliaBR> Myles: Does that mean that you think a stronger enforcement at Mime type level is necessary. <AmeliaBR> Chris: I don't know. Just pointing out the difficulties. Need strong implementer support. <AmeliaBR> Myles: One use case: for the OS, we might want to open a full SVG file in browser, a native SVG file in image preview. So we'd need a different file extension to do that. <AmeliaBR> Dirk: Are we leaning towards a decision here? <AmeliaBR> ... From Adobe's perspective, we'd like a clear distinction. We don't care whether it's internal (attribute) or external (extension / MIME type). <AmeliaBR> Sairus: I think we need to think more carefully about all the use cases. <AmeliaBR> Dirk: Ok, leave the issue open for now. <AmeliaBR> Amelia: It would help to write out, in the issue, the use cases & pros/cons for each. <AmeliaBR> Myles: I'm not sure whether my use case also applies to Windows. <AmeliaBR> Amelia: Yes, file associations to software are keyed on extensions. So you'd need different extensions to associate them with different viewers. <AmeliaBR> Sairus: BTW, I spoke recently with some of the Microsoft team. Trying to get them engaged in this project. <AmeliaBR> Myles: Ok, I'll ping them in the GitHub thread & see if we can get some input. |
If the extension/mimetype is the same as SVG, then this format will be treated as Web content and opened with the browser when you double click on it, but if it's distinct, it can be treated differently. One of the goals of SVG Native is to work outside of the Web content, as a native image format. @MilesMSCohen Do you have any thoughts? |
No renderer may naively trust neither mime nor extension – it has to be either strict (=safe) or trusting. That's the decision to the consumer. Not the producer. So declaring safe via mime or extension isn't a security gain anyway. |
Should the file extension be
.svg
? Or something more specific?The text was updated successfully, but these errors were encountered: