- From: Chris Lilley <chris@w3.org>
- Date: Fri, 04 Aug 2000 22:14:05 +0200
- To: Leonard Rosenthol <leonardr@lazerware.com>
- CC: Jon Ferraiolo <jferraio@Adobe.COM>, RobertoBe <RobertoBe.software@teseo.com>, www-svg@w3.org
Leonard Rosenthol wrote: > > At 9:15 PM +0200 8/4/00, Chris Lilley wrote: > >The MIME type is missing, as has been noted, from your example. Adding the > >PNG mimetype does not affect display of the image; then again, adding any > >string in there doesn;t seem to affect the displayof the image. > > OK, so the Adobe viewer is smart enough to do auto-detection > of the image type based on the "magic bytes". Well, whether that is smart or not sort of depends. Looking at the specification for the data url scheme, ut clearly says that the MIME type is optional, as is the encoding. But omitting the encoding means ascii, with non-ascii characters represented by %xx URL escapes of the *byte values*, and they don't say what character encoding is being used (same old problem, people are setting on utf-8 for URIs to solve that) so who knows what the byte values are? So, I woulds be happy, personally, so see the base64 declaration be required for all SVG use of data url on images. Omitting the MIME type also has a defined meaning - the resource has the MIME type text/plain;charset="us=ascii". So the issue is exactly the same as the following one <image width="20" height="30" xlink:htef="http://example.net/foo.xyz"> when the server returnes a MIME type of text/plain, what do you do? Some HTML broewsers use a range of undocumented hueristics to fix things up, which propogates the brokenness Some html browsers follow the spec and offer to save to disk (application/octed -stream) or open a text editor (text/plain). > Is it expected that > all SVG conforming viewers do the same, or should they instead punt > on invalid mime-types? What are you thoughts on what to put into the > spec on this subject? Whatever there is needs to be consistent. Generally, with URLs there is resistance to putting the MIME type there - the server might do content negotiation, the resource might change over time, there might be a transcoding proxy in between you and the server, and so forth. These reasons do not apply to the data scheme - the encoding application always knows what the format is and can always write the MIME type and the data will never change. So, my preference would be to follow the spec, require the MIME type in all cases (since text/plain is not an image type and thus never appropriate, for SVG) and require implementatiosn to issue an error if the MIME type is text/plain (by implication of omiossion, or through being physically present), immage/silly, foo.bar, or anything else that is not supported. -- Chris
Received on Friday, 4 August 2000 16:14:41 UTC