Re: [SVGMobile12] more on data types

Quoting thomas.deweese@kodak.com:
>> On Jan 11, 2006, at 14:53, thomas.deweese@kodak.com wrote:
>> >    I personally can't believe the WG has made this change.  It
>> > means that no compliant renderer can inform users that they
>> > have made a mistake because of course they haven't they have
>> > simply indicated to the UA to ignore the value of the attribute.
>>
>> It isn't the job of a renderer to inform users of errors in the
>> content. That's the job of compliance verifying tools.
>
>   Well except as I point out above the WG has defined it such that
> there isn't a error, it's just an attribute that needs to be ignored.
> So I'm not sure what your compliance tool is going to do.

 From the RelaxNG snippets and the specification prose it should be 
clear that it
is not conforming SVG Tiny 1.2 content. That the attribute should be ignored
when it contains a certain value is only forward compatible error handling. So
that the language can be extended in a way that is backwards compatible with
existing deployment.


>> Switch does have its uses, but wrapping everything in a conditional
>> is hardly better than testing navigator make and version in scripts
>> as used to be done in HTML.
>
>   Actually I would consider it much closer to feature testing
> (especially with the 'requireFeatures' test attribute), and feature
> testing appears to be widely considered to be the 'best' way to
> handle this issue.  One major problem is that currently svg doesn't
> provide very detailed feature strings.

Given the many comments on this topic that are in favor of the newly suggested
approach and the results from forward compatible error handling in other WGs
(CSS for example) I don't think that feature testing is "widely considered to
be the 'best' way".


>   I would expect similar behavior from 'incomplete' implementations.
> But I really see no reason why an implementation that knows the complete
> element list for SVG 1.2, see's the version="1.2" and still should be
> forced to allow 'unknown' elements in the SVG namespace - other than
> to allow for vendors to stick proprietary extensions into the SVG
> namespace.

It does not allow them. It just treats them as prescribed in the 
specification.
That does not mean that UAs are allowed to make extensions in the SVG
namespace... Not sure where you get that from.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>

Received on Thursday, 12 January 2006 15:58:42 UTC