Re: Animating SVG with CSS

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.

~TJ

Received on Thursday, 18 September 2014 17:54:54 UTC