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 16:51:15 -0800
Message-ID: <6ECA24BE410D994496A2AE995367C5C8576B56@namail3.corp.adobe.com>
To: "Maciej Stachowiak" <mjs@apple.com>
Cc: "Bjoern Hoehrmann" <derhoermi@gmx.net>, <www-svg@w3.org>

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


-----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  

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).

Received on Wednesday, 11 January 2006 00:50:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:06 UTC