W3C home > Mailing lists > Public > www-svg@w3.org > January 2006

RE: [SVGMobile12] more on data types

From: Jon Ferraiolo <jonf@adobe.com>
Date: Tue, 10 Jan 2006 17:16:01 -0800
Message-ID: <6ECA24BE410D994496A2AE995367C5C8576B75@namail3.corp.adobe.com>
To: "Eric Seidel" <eseidel@apple.com>
Cc: "Maciej Stachowiak" <mjs@apple.com>, "Bjoern Hoehrmann" <derhoermi@gmx.net>, <www-svg@w3.org>
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 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:33 GMT