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