- From: Jon Ferraiolo <jonf@adobe.com>
- Date: Tue, 10 Jan 2006 17:16:01 -0800
- To: "Eric Seidel" <eseidel@apple.com>
- Cc: "Maciej Stachowiak" <mjs@apple.com>, "Bjoern Hoehrmann" <derhoermi@gmx.net>, <www-svg@w3.org>
- Message-ID: <6ECA24BE410D994496A2AE995367C5C8576B75@namail3.corp.adobe.com>
Eric, I agree with your analysis, particularly with respect to the transform attribute. (And if other implementers agree with Maciej, for other attributes as well.) The SVG WG should have a test for the 'tranform' attribute for incorrect entries such as the example you provide. It is too much to ask for tests for every possible incorrect formulation of every attribute, but the example you give below represents a case which is more likely due to accidental error, such as misspelling 'translate'. Jon ________________________________ From: Eric Seidel [mailto:eseidel@apple.com] Sent: Tuesday, January 10, 2006 5:05 PM To: Jon Ferraiolo Cc: Maciej Stachowiak; Bjoern Hoehrmann; www-svg@w3.org Subject: Re: [SVGMobile12] more on data types My understanding is that invalid attribute values are "unknown" and thus are ignored completely. C.2 Unsupported elements, attributes, properties, attribute values and property values Conforming SVG User Agents must ignore unknown attributes, attribute values, styling properties, styling property values, and descendant elements as follows: Am I reading this correctly? Thus things like transform="scale(2) foobar(2) translate(2,3)" should be ignored completely. (This has been brought up before and is an area where FireFox and Safari currently disagree.) -eric On Jan 10, 2006, at 4:51 PM, Jon Ferraiolo wrote: Maciej, This is great feedback. If other implementers share your opinion, then your approach is OK with me. One thing to keep in mind is that the Tiny implementers might be resistant to the extra code and processing. As I have said, my opinion is that I am not all that concerned with lack of interoperability with incorrect content. SVG is a different beast than HTML. There is much less hand-coding by non-technical people and no SGML legacy. But if we can get implementers to enforce strictness, I agree that is the best approach. Jon -----Original Message----- From: Maciej Stachowiak [mailto:mjs@apple.com] Sent: Tuesday, January 10, 2006 4:42 PM To: Jon Ferraiolo Cc: Bjoern Hoehrmann; www-svg@w3.org Subject: Re: [SVGMobile12] more on data types On Jan 10, 2006, at 4:08 PM, Jon Ferraiolo wrote: Bjoern, The statement unfair and inaccurate to say " The Working Group rejected the idea" when in our response (http://lists.w3.org/ Archives/Public/www-svg/2005Apr/0156 ) to your "Microsyntaces" email we basically agreed with 3 of your 4 points, and we have now in the latest Last Call draft put in changes which at least partially addresses your fourth point via fixes to some of syntax definitions for SVG's properties, such as including the definition of color inline within the SVG spec. Regarding the lack of interoperability for the following content: height="100 user units or so" I am over on the Jim Ley side of the argument about error handling. Don't put the burden on each implementation to have to validate each attribute value and don't slow down processing to perform this validation. Validating attribute values while parsing is not a huge burden. This is already done for CSS, and for HTML presentational attributes. I can say with some confidence that it adds very little to the overall parsing cost, having spent a lot of time optimizing WebKit page load speed. Interoperability is more important here -- we have a demonstration that UA behavior varies. The spec clearly should specify what happens with malformed attributes (which may already be true in the 1.2 tiny spec for all I know, perhaps the document is "in error" and so should give a fatal error display). Regards, Maciej
Received on Wednesday, 11 January 2006 01:15:17 UTC