Re: Some practical issues integrating the SVG transform attribute with CSS transform properties

Robert O'Callahan:
> 2011/3/27 Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
>
> > But similar things apply for some features of the current CSS2.1 draft
> > compared to CSS2.0 (used by SVG 1.1) - and of course there are even more
> > version-dependent features in HTML ;o)
>
> CSS and HTML do not respect version switches. I.e. there is no way for a
> document to say "I am CSS 2.0 and HTML3" and get the behavior specified by
> CSS 2.0 and HTML3 instead of whatever the latest specs say. When CSS or
> HTML specs change, we change the behavior for *all* documents.
>

The meaning of an already existing document cannot change with any 
change of a recommendation in the future. This is a general problem of
formats with more than one recommendation and no option to indicate
formally, which recommendation applies. In doubt then the creation date
of the document is relevant. Typically the author will have used the
recommendation, that was the current recommendation at the creation
date. For example my CSS documents are all CSS 2.0 (I have never
written a CSS1.0 document and CSS2.1 is still a draft).
Of course, if there is no option either to indicate the creation date
formally (possible in XML formats with RDF(a)), this results in the
problem, that if the creation date does not exist and there is more
than one definition of a feature, the behaviour for the document using
this feature is undefined. There is no method to say, which interpretation
is right. Cautions authors should not use such a dubious feature at all and
tutorials should recommend not to use such a dubious feature.

All recommended versions of (X)HTML have a version indication, including
the newest recommendation XHTML+RDFa.
That the HTML5 draft still has no version indication may lead several people
to the impression, that it is not helpful to write documents with a defined 
meaning, what could be pretty important for a text markup language,
more than for a style sheet language. But of course, vector graphics will
often have similar needs to have a defined meaning, if they are not
purly decorative, therefore a version indication is important as well ...  


> (There is a "quirks mode" switch but it doesn't map onto spec versions and
> we are not adding to it.)

This is only about bugs in viewers, 'quirks mode' has nothing to do with
a defined meaning of a document - the opposite is true, it results in an
intentional  wrong interpretation of defined documents (if is deviates
from the recommended behaviour ;o)

>
> SVG transformations are often used in current SVG documents, therefore
>
> > either
>
> future recommendations are compatible with current SVG recommendations,
>
> > or version-dependent and profile-dependent viewer behaviour is necessary
> > for a huge amount of documents.
>
> Future recommendations need to be compatible with current recommendations,
> or at least we need to be confident that any changes will break only an
> insignificant amount of Web content. 

As long as the existing web content has a version indication, nothing can 
break. In worst case only the interpretation with new viewers can be wrong
and stupid, but this does not change the intended interpretation of the 
document.

But of course, concerning these SVG transformations, as long as there
are no version inconsistencies introduced, the versioning does not matter
here. Therefore it is obviously a good idea, not to introduce inconsistencies
in future versions ;o)

Typical viewers (not only for SVG) are full of bugs. 
Looking into my test suite, it is quite simple to write a huge amount of
simple documents, which are interpreted wrong in different ways for 
different reasons in different viewers - and this includes interesting
applications - or those could have been interesting without the bugs.
Therefore we can assume, that a typical viewer interpretes web content
wrong. Users of software have to know this. And of course there is a lot
of work to fix such bugs to reduce the problem (For example in the
last days I tested Gecko2.0/Firefox4beta and found out several bugs/gaps
relevant for my art gallery. If they are not fixed, I will of course inform
the visitors not to use this viewer for the SVG content containing animation,
pattern and filters - because it displays it wrong or breaks the content as
you might say).
If different recommendations deviate, of course the risk of a wrong 
interpretation of a document is even larger, therefore it is even more
important to avoid such inconsistencies.
Else we get more and more content with warnings about specific viewers
breaking the web content (as we already had in the days of netscape
and MSIE) - this is how the web works, if things deviate - and I don't like
this option.

> This is the way the rest of the Web 
> works, 

After many years as author of 'normal' documents for the
general audience and author of tests, doubts are increasing,
that it works at all, if the interpretation of recommendations
is so bad as it was in the past and today :-(
There are a lot of efforts of authors to publish something
anyway, instead of concentrating on the content, they have
to work around bugs and inconsistencies - maybe this is
how it works today, but is basically a waste of time for authors,
therefore not desirable for the future.

But of course, if there is no defined meaning of anything,
interpretations cannot be wrong. But then authors should
better use other formats, if they have something to express
instead of only bubbling around.


> and SVG should be consistent with that. 
>

Many/most formats have a version indication to ensure
a defined meaning of documents. Maybe for the rest
a defined meaning is not relevant?

Recommendations for SVG and (X)HTML etc should ensure,
that documents have a defined meaning, because they
are intented for the purpose to write meaningful documents.

If there are never inconsistencies between old and new
versions, there is indeed no need for a version indication,
in such a case the version indication is nevertheless useful
to find an appropriate recommendation to interprete the
document. For old viewers this is an option as well to
be able to warn, that there might be an interpretation problem,
if the version used for the documents is newer that the versions
known by the viewer. For example the adobe plugin does this,
if the document has a related doctype. Unfortunately it does not
look on the version attribute, therefore it runs in trouble, where 
it really matters, for SVG tiny 1.2 documents ;o) Version indication
could have been more clever here ...

As it appears currently for SVG, (X)HTML and CSS, version
inconsistencies are unfortunately not completely avoided or
maybe could not have been avoided. Therefore a version indication
is important to allow deviations in newer recommendations, mainly
to replace problematic issues. To replace already good defined
behaviour just with other behaviour is an abuse of versioning and
should be avoided in general. There are examples for such attempts
for example in the CSS2.1 draft as well, this indicates, that CSS 
needs a version indication maybe more than SVG, that has 
currently only less problematic issues. In general real recommendation
history and present shows, that inconsistencies in the future cannot
be avoided in the present, therefore to be careful, a version indication
is always useful, to keep historical documents defined, whatever 
happens with the next recommendation.

And of course, proper version indication helps authors to
update their documents to new versions, if they like the new
definition more than the old. With a proper version indication,
they can identify the meaning of the old document and can 
investigate how to realise it with the new version of the format,
if this is interpreted better with the majority of viewers.

'The web' consists of many complex problems and a huge
amout of imperfection.
Different people may have different methods to solve the problems
or to work around it. More information helps, less inconsistencies
in recommendation versions helps even more.

Olaf

Received on Sunday, 27 March 2011 12:47:36 UTC