- From: Jon Ferraiolo <jonf@adobe.com>
- Date: Tue, 29 Nov 2005 10:05:02 -0800
- To: "Boris Zbarsky" <bzbarsky@mit.edu>, "Chris Lilley" <chris@w3.org>
- Cc: <www-svg@w3.org>
Boris and Chris, We see this issue all over the place with regard to how a Full implementation must deal with Tiny content. This issue is about what happens if a Full implementation encounters content which happens to use CSS units (i.e., outside of 'width' and 'height' on the root 'svg' element). But the same question can be asked about what happens if the content uses filters, masks, clipping, or countless other features which are available in Full but not available in Tiny. My memory is that this issue has been discussed within the SVG WG at length and the conclusion is that it is too complex and too much of an implementation burden for Full implementations to have to turn off features because the content has baseProfile='tiny'. I will point out that the latest draft (soon to be published) has the following to say about 'baseProfile': baseProfile = "profile-name" Describes the minimum SVG language profile that the author believes is necessary to correctly render the content. See rules for baseProfile processing for further instructions. In other words, 'baseProfile' defines the minimum requirements to successfully view the content, but does not say anything about restricting the maximum features that must be allowed by the user agent. The burden is on the content developer. If they want interoperability, only create content that uses features that are in a particular profile and don't use features that go beyond that profile (such as CSS units). Jon -----Original Message----- From: Boris Zbarsky [mailto:bzbarsky@mit.edu] Sent: Tuesday, November 29, 2005 9:48 AM To: Chris Lilley Cc: Jon Ferraiolo; www-svg@w3.org Subject: Re: [SVGMobile12] Comments: Basic Data Types and Color Keywords Chris Lilley wrote: > The intent is that CSS units MUST be supported for width and height on > <svg> and MUST NOT be supported elsewhere. This seems to me to place an undue burden on implementations that DO have support for CSS -- instead of using the same code for both sets of attributes, they are now forced to write separate code to handle the two. Also, since CSS-less implementations still have to handle units for width/height on <svg>, I don't see how their life becomes any easier... In fact, they have to have two separate codepaths instead of just one, which seems unfortunate to me if they're trying to minimize codesize. In short, from my point of view as an implementor I see no benefits to this approach and lots of drawbacks. What am I missing? -Boris
Received on Tuesday, 29 November 2005 18:04:24 UTC