Re: Animating SVG with CSS

Hello world ;-)

Tab Atkins Jr. wrote:
> On Thu, Sep 18, 2014 at 7:05 AM, Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de> wrote:
>> Erik Dahlström:
>>> I'm puzzled as to why you think that the CSS Animations draft doesn't
>>> apply.
>>>
>>> The CSS Transitions spec clearly states that all animatable SVG properties
>>> are supported when they have compatible types[1].
>> Well, at least
>> http://www.w3.org/TR/2011/REC-SVG11-20110816/styling.html
>> notes, which poperties are shared between CSS and SVG 1
>> and which apply to SVG 1 exclusively.
>> If meanwhile CSS has some of them adopted with the same
>> name, they are still not shared yet (this can be a task for SVG 2
>> - maybe with the result to skip such restriction sections).
>> This already restricts the questionable properties to a small list.
> 
> They are still CSS properties, they're just restricted to only having
> meaning on SVG elements.
> 
>> SVG 1 refers only to CSS 2, no current draft. CSS 2 does not contain
>> animation features, therefore it is nothing with a defined meaning for
>> SVG 1 documents.
>> SVG 1 clearly predates such drafts, implicating no defined relation.
> 
> The use of such dated references is a spec bug; in reality, SVG uses
> the latest CSS that is supported by the UA.
> 
>> There is of course nothing, that prevents authors from noting anything
>> in stylesheets (even what is not mentioned in any draft or recommendation),
>> implementors may provide for test purposes experimental implementations
>> of drafted or other features as well with CSS vendor-prefix notation.
>> The behaviour might be somehow related to some specific draft version,
>> but there is no need for such an alignment.
>> But for a draft I think it should not work without prefix, therefore it is
>> not applicable at all as drafted (this means without prefix).
>>
>> Maybe you are only confused by the implications, which occur, because
>> typically implementations do not care about format versions, resulting
>> quite often in confused presentations, if different versions of formats
>> require different behaviour - finally the defined meaning of documents
>> it determined by the format version an author has used to create a document,
>> not by the interpretation of any viewer. This is the major feature/progress,
>> markup languages provided for authors of information.
>> This meaning cannot be changed later in newer format versions or viewer
>> interpretations.
>> (Backwards incompatible) changes in an SVG 2 draft for example do never
>> apply to SVG 1 documents; HTML5 changes do not apply for HTML4 or XHTML 1.x
>> documents. To create documents with a defined meaning following HTML5 rules,
>> authors have to add meta information about the relevant HTML5 draft for
>> example with RDF(a) or  DCMI elements or terms, because such a (X)HTML
>> version indication is not available in HTML5.  If a markup document exposes
>> no such relations, it has no defined meaning. In such a case it is quite
>> useless to discuss what applies or what does not apply.
> 
> Fortunately, none of what you just said is true, and browsers don't
> actually have to ship implementations of every version of every spec
> they've ever supported (plus combinatorial amounts of glue code for
> when the specs interact in different ways).  UAs use the latest
> versions of whatever specs they implement, and web languages almost
> never carry version indicators; the big ones (HTML, SVG, CSS, JS)
> certainly don't.
> 
> There is a certain theoretical purity to what you're saying, but it
> has not and will not ever be true on the web.

And that is the great "feature" what might easily break existing 
content: If an attribute (let's take "x" as an example, and let's even 
add a second one, "y") happens to become a presentation attribute (in 
order to make it work with CSS animations or whatever), which it is was 
definitely not in SVG 1.1, a simple CSS rule of
* { x: 47; y: 11; }
which did not do any harm, so far (since unknown CSS properties _must_ 
_be_ _ignored_ by browsers, according to _any_ _CSS_ _spec_ in my 
knowledge), makes all my SVG objects using individual x and y attributes 
appear at the very same place (47,11). One might address this issue by 
changing the precedence of CSS rules over presentation attributes vice 
versa, but such a change might break other existing content :-(

That's why I am sure that with this version-less web-language handling, 
many more problems will arise (or exist already) than what will be "solved".

Juergen Roethig

Received on Thursday, 18 September 2014 19:32:55 UTC