- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Wed, 18 Dec 2013 11:37:08 +0100
- To: www-svg@w3.org
Brian Birtles: ... >Yes, please see my previous reply to Alex where I described such a case. I could not identify any specific functionality here (maybe due to the script problem - script interpretation is disabled in my user-agent by default for unkown resources ;o) >> If yes and this matters for content, it might be a good idea >> to provide a mechanism as well to have such a feature for >> content as well, not just for decoration. >I'm afraid I don't understand this comment. CSS properties are about decoration or styling only, this means is makes no difference for the understanding of the content, if you remove all styling information. If it matters for content, one needs for example the attribute or another mechanism - similar applies for scripted parts of documents - if it really matters, this needs to be done declaratively and scripting is the wrong way. For SVG most features matter for understanding the content, therefore the applications for styling or scripting are alternative views of the content, currently not often done by authors. For example with viewBox typically it matters for understanding, which fraction of the document one can see, however if the document contains different alternative views in different areas, this may matter as well for styling. Therefore if something can be done only with the property for styling, one has to think about the question, if this could matter for content as well. A typical example is the current problem, that one cannot animate classes of elements, but one can style classes of elements. Therefore one should consider to introduce a feature in SVG 2 to allow the animation of classes of elements as well, because this is a helpful use case and such an animation is often relevant for the interpretation of the content, if present. About new values for viewBox: With non numerical values like 'none' introduced already in SVG tiny 1.2 and 'auto' one has to take into account, that this means more complex implementations for animation - or at least more rules to explain what to do. If one follows strictly SMIL rules, such possible values mean, that there can be only discrete animation. But we have already specific rules for fill and stroke, resulting typically in bugs in implementations due to the complexity to get it right to determine the interpolation method. But this is required, because often one wants to have continuous animation. Still one should add some non normative information as a help for implementors, how to get the interpolation method (discrete versus linear/spline/paced) for such complex attributes, for example: 'Analyse the values list. If it contains a non interpolable value, chose calcMode discrete, else use the specified calcMode, respectively the default linear, if not specified.' There has to be additional information about additivity for fill and stroke, that is not applicable for viewBox, because it is not additive anyway. About width/height: >That's an interesting idea. If we introduce a new top-level <graphics> >element I would be interested in simply removing width/height from its >definition for similar reasons. width and height of the root svg element are quite important for several use cases, for example for maps with a defined scale, for representing images of objects in original size or simply if the document contains raster images and one does not want, that those are scaled up resulting in a presentation of bad quality. Tab Atkins Jr.: >Correct that CSS separates words with dashes, because CSS is ASCII >case-insensitive for language-defined things. We traditionally write >it all lowercase, but you can do whatever casing you want. >I don't think English has a preference between "viewbox" and "view >box". It would likely be just fine for CSS to have a property named >"viewbox" (which SVG-comfortable authors could write as "viewBox" if >they chose). This sounds like a note for such properties would be sufficient/helpful like: "Note, that the related SVG attribute is 'viewBox', but because property names are case-insensitive, one can use other representations of the property like 'viewbox' as well." Olaf
Received on Wednesday, 18 December 2013 10:37:50 UTC