- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Sun, 27 Mar 2011 13:47:00 +0100
- To: public-fx@w3.org
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