- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 29 Apr 2019 20:56:55 +0000
- To: public-svg-issues@w3.org
The SVG Working Group just discussed `SVG Native file extension`. <details><summary>The full IRC log of that discussion</summary> <AmeliaBR> Topic: SVG Native file extension<br> <AmeliaBR> Github: https://github.com/w3c/svgwg/issues/664<br> <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?<br> <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.<br> <AmeliaBR> ... The media type is more important. File extension is just a representation of that.<br> <AmeliaBR> Dirk: The downside of a new type/extension is that existing tools would not be able to open by default.<br> <AmeliaBR> ... But, we are designing a format for the future.<br> <AmeliaBR> Myles: Implementations can be divided & some don't currently support all of SVG, anyway.<br> <AmeliaBR> ... Browsers should render it anyway regardless of Mime type, right?<br> <AmeliaBR> Chris: Maybe, but it depends. Browsers do some sniffing, but won't do anything.<br> <AmeliaBR> Dirk: Browsers may not be the main issue, since they're likely to be early adopters.<br> <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.<br> <AmeliaBR> ... Might need education for authors: you may need to save as a different extension. Servers may need to respond based on HTTP headers.<br> <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?<br> <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.<br> <AmeliaBR> Sairus: So we really want this to be the defined scope & then stick with that.<br> <AmeliaBR> Dirk: Myles also mentioned the possibility of a distinction internally, e.g., a version attribute.<br> <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.<br> <AmeliaBR> Myles: Does that mean that you think a stronger enforcement at Mime type level is necessary.<br> <AmeliaBR> Chris: I don't know. Just pointing out the difficulties. Need strong implementer support.<br> <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.<br> <AmeliaBR> Dirk: Are we leaning towards a decision here?<br> <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).<br> <AmeliaBR> Sairus: I think we need to think more carefully about all the use cases.<br> <AmeliaBR> Dirk: Ok, leave the issue open for now.<br> <AmeliaBR> Amelia: It would help to write out, in the issue, the use cases & pros/cons for each.<br> <AmeliaBR> Myles: I'm not sure whether my use case also applies to Windows.<br> <AmeliaBR> Amelia: Yes, file associations to software are keyed on extensions. So you'd need different extensions to associate them with different viewers.<br> <AmeliaBR> Sairus: BTW, I spoke recently with some of the Microsoft team. Trying to get them engaged in this project.<br> <AmeliaBR> Myles: Ok, I'll ping them in the GitHub thread & see if we can get some input.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/svgwg/issues/664#issuecomment-487740943 using your GitHub account
Received on Monday, 29 April 2019 20:56:56 UTC