Reference to SVG

[murata2makoto]

Our normative reference to SVG is:

[SVG]
SVG. W3C. URL: https://www.w3.org/TR/SVG/

But this URL references SVG 2, which is just a CR.

Meanwhile, Relationship to SVG:

This specification does not reference a specific version of [SVG], but instead uses an undated reference that will always point to the latest recommendation.

Does 3.2 now reference SVG 1.1 or SVG2?

[dauwhe]

That's a really good question.

[mattgarrish]

Interesting, I thought that URL wasn't supposed to be updated until SVG2 was a REC, with tr/SVG2 serving as the latest link for that document until then. The wayback machine shows it was still pointing at 1.1 when we closed off 3.1. @iherman do you have a take on whether this was a premature change?

But we do clarify the references are intended to point to the latest REC, so in this case SVG 1.1 should still be considered the official reference.

[murata2makoto]

But we do clarify the references are intended to point to the latest REC, so in this case SVG 1.1 should still be considered the official reference.

Agreed.

[iherman]

@mattgarrish @murata2makoto : I have asked the higher powers at W3C. Hope to get an answer soon.

That being said: I wonder whether we should not, somehow, have two URL-s in these documents. One should point to the latest Rec-s (hopefully we will get those), but also pointers to the latest stable versions of those. Indeed, for developers, implementers, etc, it might be good to have those at hand, because that is where things will evolve. In particular, although the current standard is indeed not SVG2, it is clear that this will be soon, that browser implementations actually do SVG2 already, etc, so if I was an implementer I would certainly prefer to use SVG2 rather than 1.1.

[mattgarrish]

but also pointers to the latest stable versions of those

I'm just not sure how we do this, if I understand correctly, short of having to periodically update the specs solely to tend to the changes (e.g., I'm assuming we'd have a link to tr/HTML54 as it's developed, and then tr/HTML55, etc.).

Maybe notes in the relationship sections to https://www.w3.org/TR/?tag=html and https://www.w3.org/TR/?tag=graphics would do?

[iherman]

@mattgarrish I think those references give us way too much information...

I wonder whether we should not be more flexible, in fact. There is no process obligation for EPUB to refer to recommendations/standards only. The question is whether the /TR/SVG (and /TR/html) references are considered by the relevant Working Group to point to the latest stable version that both implementers and users should use. AFAIK the answer to this question is 'yes'. To use the SVG1.1 vs. SVG2 example, if I look at the changes' section clearly new content should use the slightly changed angle values, for example.

(I have not received a definitive answer to my question within the W3C team, though)

[mattgarrish]

There is no process obligation for EPUB to refer to recommendations/standards only.

No, but it's been practice to only refer to recommendations except in certain extraordinary cases, like CSS modules that couldn't be waited on. I'm personally fine adapting with the Web as it evolves, as I expect epubcheck will be allowing new features as they are incorporated into the schemas instead of when a REC is published, anyway.

But it's something the CG should determine, as we would need to reword those reference from the "latest recommendations" to the "latest stable releases" or some such.

[dauwhe]

I also think we're in a different situation with SVG than with HTML or CSS. The latter two are under active development by the browsers. SVG is... more problematic. The SVG 2 working group almost died. I have no idea how we discover how much of SVG2 has browser support. Even caniuse.com reports on only SVG 1.1 now.

I'm also concerned that there's a lot of use in EPUB of SVG graphics exported from tools like Adobe Illustrator. Would these tools evolve the same way browsers might?

[mattgarrish]

I have no idea how we discover how much of SVG2 has browser support.

The awkward thing is that validator.nu seems to be supporting parts of SVG 2 based on their utility, so strict 1.1 conformance is also problematic. This must mean that there is some SVG2 feature support in browsers, too.

Instead of changing the reference, we may want to add some verbiage that explains that our intention is to also follow this approach.

[murata2makoto]

In my understanding, what validator.nu supports as HTML is neither strictly WHATWG nor strictly W3C. I guess that the same approach has been taken for SVG.

I do not think that EPUB 3.2 should say much about epubcheck or underlying validator.nu. I think that EPUB 3.2 should reference SVG 1.1 without saying anything more.

[mattgarrish]

I think that EPUB 3.2 should reference SVG 1.1 without saying anything more.

This approach just seeds confusion, though. I'd rather we just adapt the relationship section so it reads more like:

This specification does not reference a specific version of [SVG], but instead uses an undated reference. Whenever there is any ambiguity in this reference, the latest recommended specification is the authoritative reference.

Authors and Reading System developers will have to keep track of changes to the SVG standard, and ensure that their processes and systems are kept up to date. New features are often supported before a specification reaches recommendation, and use of such features is not forbidden as soon as they are implemented. This approach ensures that EPUB will always keep pace with changes to the SVG standard.

As SVG evolves, it is also possible that features that were valid in previous versions could become obsolete or be removed. It is anticipated that the W3C will make any such changes carefully to ensure minimal disruption for Authors, but in the case of a backwards-incompatible revision the use of an undated reference could be revisited.

This will keep us officially on 1.1 for now, while also acknowledging that we're not being strict about it. We don't have to talk about specific validators.

[murata2makoto]

@mattgarrish

In some standardization organization, it is said that "Less is more". As I see it, your second paragraphs add nothing to the first para. Your third para may be useful as a note.

[dauwhe]

Closed via #1231

[dauwhe]

Postscript: I talked to AmeliaBR, who says the CR of SVG2 is actually much closer to the reality of browsers than the REC of SVG 1.1.