W3C home > Mailing lists > Public > public-svg-wg@w3.org > July to September 2008

Re: Patch for Acid3 test 77 (SVGTextContentElement errata)

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 14 Jul 2008 15:04:47 -0700
Cc: Ian Hickson <ian@hixie.ch>, "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Message-Id: <A04CE976-4352-4664-9AD1-34363E2CFB5B@apple.com>
To: Erik Dahlström <ed@opera.com>


On Jul 14, 2008, at 12:28 AM, Erik Dahlström wrote:

>
> On Sat, 12 Jul 2008 04:01:36 +0200, Ian Hickson <ian@hixie.ch> wrote:
>
>> On Fri, Jul 11, 2008 at 4:17 PM, Ian Hickson <ian@hixie.ch> wrote:
>>>>
>>>> It's likely that there will be a publication of the SVG 1.1  
>>>> errata soon.
>>>> Once that happens, it would be great if the attached patch could  
>>>> be included
>>>> in the acid3 test.
>>>
>>> I updated Acid3.
>>
>> Actually I've reverted the change, because the test was still correct
>> given the SVG errata. The WebKit team pointed out to me that the new
>> errata is wrong. You've made (2,2) not through an exception and (3,0)
>> throw an exception, even though the former is undefined and the  
>> second
>> should be 0.
>
> Assuming the example is a 3 character string, the reasoning behind  
> the change for getSubStringLength(2,2) being equal to  
> getSubStringLength(2,1) is that that's how selectSubString(2,2)  
> works, the second argument value is clamped to the number of  
> available characters.
>
> It's possible that (3,0) shouldn't throw though, to be somewhat more  
> similar to the old definition. That would make it different to  
> selectSubString though, but I can see that with that particular  
> indata you'd want to know in selectSubString that nothing was  
> selected, and for getSubStringLength to return 0 for this case is  
> more convenient.
>
> The webkit team is represented on the SVG WG (by Apple), and it  
> would have been great if the comments would have been heard there  
> when this errata was discussed.

If you'd like specific errata reviewed on behalf of Apple or the  
WebKit project in the future, please let me know. But we probably  
won't be able to give detailed immediate review of every erratum  
without being specifically asked.

As for the substance of the change, it seems very strange to me that  
whether the method throws depends on which range endpoint is out of  
bounds. It would make more sense to either always clamp to the text  
node's available range (returning 0 if you end up outside the range  
entirely), or always throw when either endpoint is out of bounds, but  
the current mix makes for a strange programming model.

Regards,
Maciej
Received on Monday, 14 July 2008 22:05:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:09 UTC