Conformance, declarative animation about svgwg

[birtles]

Declarative animations includes SVG's animation elements, CSS animations, and CSS transitions. However, there's no requirement to support any of those or script either. I think the sentence makes sense?

[tobireif]

The text

"Conforming Dynamic SVG Viewers"
"Dynamic document content can be achieved via declarative animation or by scripts modifying the SVG DOM."

could be interpreted to include this meaning:

"In a dynamic SVG viewer, the developer has two options for animating SVG elements/properties: they can be animated using declarative animations (eg SVG SMIL / SVG's animation elements) or using script (eg rAF)."

That would mean that both are required.

If there is / will be consensus in the SVG WG that both script animation and declarative animation (incl SVG's animation elements) should be required for dynamic SVG viewers (I think both should be required for eg browsers), then the wording (eg in the SVG2 spec) should be updated to unambiguously state that.

Many developers want/need SVG SMIL / SVG's animation elements.

[DavidDailey]

Absent a requirement that SVG support entails support for both SVG SMIL/SVG's animation elements or using script, I think it is not clear what is intended here. Much content will be broken (including much that Google's bots can't see -- Chinese or behind corporate firewalls), the learning curve increases in difficulty (at least according to experts who have taught this in formal settings), and just as importantly, many things which can now be done only through SVG SMIL will have no way, short of scripting to be implemented: a hugely discriminatory net effect both in terms of socio-cultural and accessibility effects. Allowing browsers to pick-and-choose what they do and don't like about a "standard" makes the document no longer a standard, and W3C no longer a standards organization. It renders W3C impotent and useless. By deprecating SMIL, one is, in effect, deprecating W3C.

[AmeliaBR]

This issue was discussed by the Working Group on the 8 October 2015 teleconference. Apologies: I'd agreed to post an update here, but was distracted before doing so.

Participants on the call agreed that the phrase in question ("Dynamic document content can be achieved via…") should only be interpreted as an example of possible dynamic content, and not as a conformance requirement.

The actual conformance requirements are listed below. There are a number of requirements that apply to both static and dynamic SVG viewers, then three aspects unique to dynamic viewers: users should be able to search for & to select text, and the implementation must conform with ECMAScript & the SVG DOM interfaces defined in the SVG spec.

Nonetheless, it was agreed that the entire section needed some editorial review & the need to do so should be considered an issue in the spec until that happens.

More generally, to clarify what Brian posted, support for particular forms of animation (CSS animation or animation elements) will each be a separate conformance aspect from support for SVG 2. This was the primary purpose of separating the animation elements into their own specification. This way, the debate over animation elements, and the decision by some user agents not to support them, does not compromise progress on other aspects of SVG, or the ability of SVG 2 to reach W3C Recommendation status. As David notes, a standard is not much of a standard if it is inconsistently and incompletely implemented. The W3C now insists on having multiple inter-operable implementations of a proposed standard before it is declared a Recommendation, not after.

There is still strong support for SVG animation elements among (many if not most) Working Group members, but we are working within pragmatic realities.

[tobireif]

Please extend my thanks to the whole SVG WG for discussing this GitHub issue ticket in the telco.

I think that the SVG spec should require support for SMIL animation (because of existing content and because it's great for beginners), but the decision is yours to make.

I understand the need for considering to be pragmatic, but it seems strange that after most popular browsers implemented SVG SMIL animation, one browser vendor's "intent to deprecate" has the effect of making the W3C move it out of SVG (where it might be ignored and forgotten) and to say eg: "given that Blink is not removing the feature, just adding deprecation warnings, then maybe that is the message we should have in the spec as well". Maybe Google's deprecation warning should not sway the W3C.

The W3C now insists on having multiple inter-operable implementations of a proposed standard
before it is declared a Recommendation, not after.

Safari, Opera, Chrome, Firefox, they all implemented SVG SMIL.

Regarding Microsoft:
"We are open to the idea of a JS implementation if it becomes absolutely necessary."
It becomes necessary when the W3C leaves it in the SVG spec and requires its implementation for conformance.

Of the main browsers, the issue is just Microsoft (which would/might implement it, see above)(in Edge I guess) and Chrome (which did implement it). I don't think the W3C should yield to the mere intent of one browser vendor which is based on "complexity [in the code]".

It really is a question of whether the W3C does what it considers best, or whether everyone switches directions based on one vendors's deprecation intent and thus breaks existing content.

Related: If you deprecate animVal/baseVal, please make sure a high performance successor API has been specd and has been implemented widely. But better to keep it (even if the newer API appears) so that existing content (eg JS-animated SVG) doesn't get broken.

[tabatkins]

I understand the need for considering to be pragmatic, but it seems strange that after most popular browsers implemented SVG SMIL animation, one browser vendor's "intent to deprecate" has the effect of making the W3C move it out of SVG

IE never implemented SMIL, and stated on record that they had no plans to do so. Blink deprecating just shifts it across the line towards "never going to be usable interoperably on the web", which means it's not useful to talk about as a requirement, as authors can't depend on it.

Regarding Microsoft:
"We are open to the idea of a JS implementation if it becomes absolutely necessary."
It becomes necessary when the W3C leaves it in the SVG spec and requires its implementation for conformance.

Specs have no enforcement power. Marking something required in a spec is a wish; if implementors agree, great, but if they don't, it's an error in the spec. By "becomes necessary", MS means "due to compat pressure from enough web pages using it and those pages being broken in IE".

[tobireif]

IE never implemented SMIL

That's true for IE and Edge (and I didn't state anything contrary), but all other popular browsers did implement it: Chrome, Firefox, Safari, Opera, and the Android Browser. (Opera Mini omits a lot, generally.)

Microsoft wrote in the thread about Chrome's plans:
"We are open to the idea of a JS implementation if it becomes absolutely necessary."

By "becomes necessary", MS means "due to compat pressure from enough web pages using it and
those pages being broken in IE".

It always is chicken-and-egg - there probably won't be much usage before it's implemented in all popular browsers (including IE and Edge), and implementers can cite low usage as a reason for not implementing it / deprecating it. We produced SVG content before any browser supported it natively, but you can't expect everyone to do that.

But yeah, it seems there isn't much the SVG WG / the W3C can do to make Microsoft implement SVG SMIL (and to make Google keep their pretty nice implementation). But if there are options, I hope you can use them successfully.