Re: SVGLength behaviour tightening

On Mon, 31 Aug 2009 08:03:32 +0200, Cameron McCormack <cam@mcc.id.au>  
wrote:

> Cameron McCormack:
>> > I’d like to define the behaviour of SVGLength (and similarly for
>> > SVGAngle) when the attribute contains an invalid string such that:
>> >
>> >   * unitType is SVG_LENGTHTYPE_UNKNOWN, value is NaN,
>> >     valueInSpecifiedUnits is NaN and valueAsString is "";
>
> Jonathan Watt:
>> I think valueAsString should probably be the string "NaN", since that  
>> should
>> give the author a higher chance of noticing what they've done wrong when
>> debugging (e.g. scanning the property values on an element in the  
>> debugger), and
>> it's what NaN converts to when converted to a string in ECMAScript.
>
> I think that’s reasonable.

Sounds fine.

>> Saying that unitType will be SVG_LENGTHTYPE_UNKNOWN probably has  
>> knock-on
>> implications. Right now unitType can never be that value, so I don't  
>> think the
>> spec really addresses in all the places that it would have to, what the  
>> renderer
>> should do when it finds any of the various SVGLength attributes in that  
>> state.
>
> I don’t think the spec says anything about rendering in terms of the SVG
> DOM interfaces as opposed to DOM Core attributes.
>
> I’ve always thought that it was implied that SVG_LENGTHTYPE_UNKNOWN is
> used whenever the length is invalid, and that while you can’t explicitly
> set it to that unit through newValueSpecifiedUnits(), the attribute
> could be of that value.  But yes it was never said explicitly.

I think making the invalid values be SVG_LENGTHTYPE_UNKNOWN is logical,  
otherwise I see no real use for that enum.

> Do you think we shouldn’t make this change without changing various
> other parts of the spec to handle SVG_LENGTHTYPE_UNKNOWN values
> explicitly?  One place that comes to mind is an SVGLengthList that is
> modified to hold such an invalid length.

I suppose a question then is, does that make the whole list invalid or  
just the individual list-value?

>> >   * when assigning to value or validInSpecifiedUnits that the length  
>> is
>> >     set to that value in user units;

That is fine I think, though it's possible that valueInSpecifiedUnits  
should throw instead.

>> I think I'd rather this threw. The user then has a chance of having  
>> their
>> attention being drawn to the bug in their code earlier where it's  
>> easier to
>> locate, rather than finding that their SVG doesn't display as they  
>> expect and
>> having to figure out exactly which bit of the SVG or the scripts it  
>> embeds went
>> wrong.
>
> OK, that’s fair.
>
>> >   * assigning to valueAsString or calling newValueSpecifiedUnits works
>> >     normally; and
>>
>> Makes sense.

Yep.

>> >   * calling convertToSpecifiedUnits throws an exception.
>>
>> Makes sense.

Sounds good.

>> > Also I’d like to make it clear that assigning to value will keep
>> > unitType as whatever it was before, and not just change it to
>> > SVG_LENGTHTYPE_NUMBER.
>>
>> It does? Without looking, I thought setting 'value' set the value in  
>> user units
>> (changed unitType), and that to maintain the units you have to set
>> valueInSpecifiedUnits.
>
> I actually had that impression too until I saw that Firefox, Batik and
> WebKit (but not Opera) all preserve the unitType and compute the
> valueInSpecifiedUnits accordingly.  The current wording doesn’t mention
> that unitType will change, either.

IMHO it makes more sense to change the unit (to SVG_LENGTHTYPE_NUMBER)  
when assigning to value, there is valueInSpecifiedUnits for the cases  
where you want to keep the unit as specified.

Cheers
/Erik

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Monday, 31 August 2009 06:50:08 UTC