Re: Ignoring trailing semi-colon delimiters

 Cameron McCormack:
>I think we have to be practical here.  If the strictness of the spec has 
>not resulted in the intended author behaviour (as is the case here with 
>the frog document) and the browsers that are currently "lax" aren't 
>willing to change to be strict, then we should just specify the lax 
>behaviour.  There is no loss in expressivity in Brian's proposal.

I think, the only practical variant for authors is, never to note 
something like values="a; ;b; ; c; ; ; ;d", values="a; b; c;" 
or values="a;b;;"  for practical reasons - 
we found already out, that the behaviour 
for such notations is different in different viewers, therefore
not reliable. And because already published versions 
of viewers will not change anymore, whatever is written
somewhere, such notation will not become reliable.

Currently authors basically have to know, if they try for
example to animate URIs, that they should not use
empty values, because in some viewers this can cause
problems - even if allowed, practically they have to work
around known bugs of viewers (bug in this situation is
not completely correct, because I think before SVGT1.2
the situation of empty URIs values was not explained, 
therefore it cannot be considered a bug, if older viewers
interprete it differently) - and because SVG 1.1.2 has no
version indication, it is not predictable for a SVG 1.1 
document, which behaviour is intended by the author
anyway.

Practically, if something like values="a; b; c;" or values="a;b;;"
is mentioned to result in some defined behaviour, authors
mainly have to know, that they should never use this,
because it results in different behaviour in already published
viewers. And theoretically they should not use it, because
it is a meaningless notation in cases, where no empty values
are allowed. 

And if there are already correct implementations for empty values 
for URIs, the current proposal concerning values="a;b;;" 
will result in another timing of the animation and therefore practically 
the behaviour of currently correct implementation and future correct
implementation would be quite different with the result, that even if 
authors just care about correct behaviour and not for bugs, such 
notation would be not reliable and therefore nothing to use at all.

The strictness of the recommendations (SMIL and SVG) has
at least the advantage, that authors can read, how to do it
right and meaningful - or in such a way, that compatibility problems 
are typically avoided. The remaining problem for authors is
therefore basically only, that not all viewers accept empty
values at all. But the proposal does not even try to solve
this problem (and maybe there is no other solution as
simply to fix the bugs in viewers).
If the SVG2 notation becomes incompatible with SMIL and
previous SVG recommendations, implementors have to
implement anyway two or three variants, for SVG 1.1.1,
SVGT1.2 + SVG 1.1.2 and for SVG2 to do it right.

The effect for such SMIL lists is different from CSS declarations 
with trailing semicolon - maybe the often seen trailing semicolon
in CSS files is the source of the trouble?
CSS itself has no trailing semicolon as well:
'A declaration block starts with a left curly brace ({) and ends with the 
matching right curly brace (}). In between there must be a list of zero or 
more semicolon-separated (;) declarations.'
http://www.w3.org/TR/CSS21/syndata.html#rule-sets

For CSS the trailing semicolon can be interpreted as a notation of an
unknown property, that has to be ignored - therefore it has no consequences.
For SVG and SMIL it has consequences, therefore these are two quite
different and incompatible approaches for different purposes.

If we look on radish, cherries and strawberries, all are mainly red, but
taste quite different and the pit(s) are either missing, inside or outside.
Just with the argument of the same colour there is no
need to align the taste or the pit position just for practically not relevant
compatibility ideas.
The same applies for CSS lists and SMIL lists.
 

To resume: 
a) The proposal does not define a meaningful feature for authors
b) The proposal does not solve the problem of bugs in viewers with
     allowed empty values (what is no surprise)
c) It introduces a backwards incompatible change
d) Behaviour of current viewers is different
e) It is completely incompatible with SMIL
f) If authors note typical things, they do not have to care about this
     anyway - to avoid problems the best is to forget about this rule and
     the complication it introduces
g) For the exception of attributes or properties with possible empty values
    authors already now have to care about viewer bugs,
    no advantage occurs, because with yet another variant the chance,
    that empty values will become ever usable, will be even lower.


Olaf

Received on Thursday, 8 December 2011 12:53:19 UTC