W3C home > Mailing lists > Public > www-svg@w3.org > February 2015

Re: making comma-wsp optional between points list coordinates

From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
Date: Fri, 6 Feb 2015 17:19:28 -0700
Message-ID: <CAFDDJ7x7PadHzqpt2F6809rRfmgrH-JczVUMt7CdVy+AifmOqg@mail.gmail.com>
To: Juergen Roethig <roethig@dhbw-karlsruhe.de>
Cc: www-svg <www-svg@w3.org>
I have to say that I agree with Juergen in the general case, when he writes

consistency with other cases is always a good argument for a change. But in
> this case, I would have proposed to have a consistency to a notation which
> is _readable_, and _intuitively_ _understandable_ by _humans_ instead of
> allowing notations like "1.5.3-1,.2-.7e1.2.3" in any case

I definitely don't like the idea of encouraging people to smoosh all their
numbers together.  For one thing, it makes writing regular expressions to
parse values from scripts a serious pain.

(P.S. On that particular jumble of numbers, I was wrong -- the specs
clearly say that an exponent must be an integer.  But it does prove
Juergen's point!)

However, I do like the idea of inter-consistency between polygon and path.
As Cameron notes, many implementations already support the condensed form
-- probably because they are using the same path parsing code to handle
polygons and polylines.

I suggest something like the following language:

Authors and authoring agents SHOULD use a comma or whitespace or both to
separate values in a <list-of-numbers> or <number-optional-number>
datatype.  User agents MAY ignore errors from missing separators where the
value can still be parsed as distinct numbers according to the grammar in
the [Basic Data Types section].

(In other words, formalize the current situation.)

OR replace the "MAY" by "SHOULD" in the second sentence (i.e., encourage
*all* browsers, etc., to adopt the permissive behavior).

However, there's also a counter argument:  This approach will sometimes
cause very-difficult-to-debug errors if the author (or their script) has
put together a string of numbers that can be correctly parsed as numbers --
just not the numbers the author intended.

For example, my -.7e1.2 error.  If separation is always required between
subsequent numbers, drawing of the shape would stop right at that erroneous
coordinate, and I can easily track down the problem.  If separation is not
required, that gets parsed as two numbers (-0.7e1 and 0.2), and drawing
continues, but now all my coordinate pairs are jumbled up, creating a total
mess until it reaches the end of the list of points and there's an extra
number left at the end.  But the entire shape would be a mess and it would
be hard to figure out what was going wrong.

Received on Saturday, 7 February 2015 00:19:56 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:39 UTC