Re: SVGLength behaviour tightening

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.

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

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.

> >   * when assigning to value or validInSpecifiedUnits that the length is
> >     set to that value in user units;
> 
> 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.
> 
> >   * calling convertToSpecifiedUnits throws an exception.
> 
> Makes sense.
> 
> > 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.

Thanks,

Cameron

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Monday, 31 August 2009 06:04:13 UTC