Re: Ignoring trailing semi-colon delimiters

Brian Birtles:

>(2011/12/01 20:38), Dr. Olaf Hoffmann wrote:
>> Well, for begin, according to SMIL, an empty value has to be
>> treated as event value.

>I'm a bit surprised at this but maybe I'm looking at the wrong version 
>of the spec. According to SMIL 3.0 Event-values must include an 
>Event-symbol (Nmtoken) which is non-zero in length.[1] Perhaps I've 
>misunderstood?
>[1] http://www.w3.org/TR/SMIL/smil-timing.html#TimingSyntax-Event-value

Indeed, SMIL 3 seems to be more precise than the version SVG still
refers too:
http://www.w3.org/TR/2001/REC-smil-animation-20010904/#TimingAttrValGrammars

This seems to leave the rules, which events are supported, to the host 
language. This is the section I found related to my last comment.
But the result of this section is only, that an empty value is treated as
an event.

And as I found now:
http://www.w3.org/TR/2001/REC-smil-animation-20010904/#Timing-EventValueSyntax
"Unless explicitly specified by a host language, it is not considered an error 
to specify an event that cannot be raised on the Event-base element (such as 
click for audio or other non-visual elements). Since the event will never be 
raised on the specified element, the event-base value will never be 
resolved."

Because SVG does not explictly note something about such a situation,
only the event base will never be resolved.

Therefore the situation gets complicated here - in SVG it still seems to be ok
to use empty values, but of course it should be better for authors not to use
them for event values, to be compatible with SMIL 3 - and because they
cause problems in some viewers and as best result no event at all, it will
be pretty clever for authors to note only meaningful values not causing 
such problems of course - intentionally I never tried to note such esoteric
values like '' oder 'BigRip'.

>This is generally what Firefox has been doing. However, there seems to 
>be a general view that this behaviour is too strict[2], hence it was 
>softened somewhat in SVG Tiny 1.2[3].
>[2] e.g. see http://lists.w3.org/Archives/Public/www-svg/2010Sep/0114.html
>[3] http://www.w3.org/TR/SVGTiny12/animate.html#KeyTimesAttribute

I think, keyTimes (and keyPoints) for value lists with only value is a 
specific problem, because obviously the general rule is intented for 
more than one value - if there is only one value, there is no way to
apply the rule correctly, because one should note as many keyTimes
as there are values and as well one should not 0 at the beginning and 1
at the end, what is not possible for one value ;o)
Especially the combination of one keyPoints value with one keyTimes 
value could result in several interesting applications. For most (other)
applications it is typically easy for authors to work around the problem.

In general this should be clarified in SMIL, that the general rule does not
apply here, but we know already, that it is typically not completely easy
to fix remaining inconsistencies in SMIL. We managed to fix several.
But currently I think, there are many people not loving SMIL,
reinventing things with low quality solutions compared to the mostly well
thought trough SMIL constructions - we have to understand, that
this is frustrating for the SMIL experts as well - especially because
they once offered help for example to the HTML5 group without any
effect - result can be seen in the HTML5 draft.

>I appreciate your point about the value of being strict and I tend to 
>agree. However, I think it only works if all (or at least most) vendors 
>are equally strict and for this particular situation, that doesn't 
>appear to be the case. Any other vendors care to comment?

Sure, bugs in viewers are always a problem. And if the management
of problematic issues in documents tends to increase the ignorance of authors,
such viewers will become a problem for SVG.
And the situation is already frustrating - Batik/Squiggle reports much
more errors than those really exist in a document, but it takes a
long time, until there is a new version.
Several other viewers have updates every few months, therefore
for them it should be no problem to fix wrong error messages, if something 
went wrong or is changed in a new version, but typically it is prefered to
please authors of wrong documents with intentionally wrong error behaviour.

I think, SVGT1.2 and SVG 1.1.2 turned already several previous errors
into features, what is not bad, if the new behaviour is meaningful, 
however this does not mean, that every stupid notation of authors 
can be turned into meaningful behaviour ;o)



Olaf

Received on Monday, 5 December 2011 10:34:21 UTC