W3C home > Mailing lists > Public > www-svg@w3.org > May 2014

Re: Clean-up SVG2 spec

From: Nikos Andronikos <nikos.andronikos@cisra.canon.com.au>
Date: Fri, 23 May 2014 14:16:38 +1000
Message-ID: <537ECBA6.1070108@cisra.canon.com.au>
To: <www-svg@w3.org>
Having considered this a little after last night's telcon, here are my

I sympathise with both points of view, but I'm leaning more towards
Dirk's as a general philosophy.
Having said that, I do agree that having to jump around between many
specs does make understanding more difficult.

If I were reading the SVG 2 spec, I think the following would be useful...
Each chapter in SVG has a section that includes:
- List of all referenced specifications
- a glossary of all external definitions used (e.g. stacking context),
with links to that definition in the external spec
- possibly a table of the properties that apply and that have been
reviewed by the SVG WG.
- or alternatively a table of any properties that don't apply or don't
make sense for SVG
- a section for each property that has special behaviour in SVG or needs
some extra normative text for SVG
- a link to an external document that includes examples of how the two
specs interact. webplatform.org might be the best host for this sort of
document. SVG editors should be responsible for updating this as part of
any relevant actions.

But what happens in future if a new CSS module is released that could
apply to SVG?
Say, CSS Photo Effects that allows an author to make everything sepia toned.
Do we have to edit the SVG spec to note specifically that it applies?

I agree with Rik that the spec should focus on the needs of implementers
first. They only have one reference after all, authors (hopefully) have

The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
Received on Friday, 23 May 2014 04:17:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:53 UTC