Re: Clean-up SVG2 spec

On May 20, 2014, at 1:05 PM, Jeremie Patonnier <jeremie.patonnier@gmail.com> wrote:

> Hi :)
> 
> 
> 2014-05-20 12:44 GMT+02:00 Tavmjong Bah <tav.w3c@gmail.com>:
> On Tue, 2014-05-20 at 09:03 +0000, Dirk Schulze wrote:
> > I would like us to clean up the SVG spec. We have many sections[1] (even whole chapters[2]) without any normative or even informative content. Usually these sections just reference a responsible CSS specification. I don’t think that we should produce this much noise in the specification itself.
> 
> I guess I have a different vision from Dirk about what a specification
> should be. I believe that one should be able to read a specification and
> be able to see the whole picture of what the specification is about.
> Removing whole sections and chapters make that more difficult. For
> example, I believe that the 'Filters' chapter should not be removed but
> should instead have a one or two paragraph explanation of what filters
> are followed by one or two examples before sending the reader off to the
> CSS Filters specification for the details. Removing this material may
> make writing a specification easier but makes understanding it harder.
> 
> Beyond implementors, this would be very helpful for authors who wish to read the spec (and there are more than we think)

I disagree:

“"
10.12.1.1. Text alignment: the ‘text-align’ property

See the CSS Text Module Level 3 specification for the definition of 'text-align'. [CSSXX]
10.12.1.2. Last line alignment: the ‘text-align-last’ property

See the CSS Text Module Level 3 specification for the definition of 'text-align-last'. [CSSXX]
10.12.2. Line Breaking

10.12.2.1. Breaking Rules for Punctuation: the ‘line-break’ property

See the CSS Text Module Level 3 specification for the definition of 'line-break'. [CSSXX]
“”

isn't any helpful. And this is just one snippet. It goes on over multiple section and subsections. One sentence at the beginning of the document can define that text alignment is defined by CSS Text and reference to the specification. Similar a sentence can describe that graphical effects like masking, filters and blending are covered by other specifications. This increases the readability of the spec a lot. Authors and implementers are not distracted by the noise of irrelevant sections. All these CSS properties apply to SVG anyway regardless if we have these sections or not.

>  
> > We should remove all redundancy. Something that I discovered[4] in the SVG spec lately is a section about CSS Shapes (shape-inside/shape-outside). These sections shouldn’t be handled in SVG at all. If SVG needs some specific behavior, work together with the spec authors of the CSS spec to get this behavior in there. CSS specs are not just for HTML but for markup languages in general — including SVG. CSS Transforms, Filter Effects, Geometry Interfaces, CSS Blending and Compositing, CSS Colors and CSS Masking are examples of specs defining special behavior for SVG as needed.
> 
> I agree we should be working with CSS more closely on this. I do,
> though, think we need to list the properties and give examples of how
> they apply to SVG.

CSS is creating new properties that are going to affect SVG. We do not catch up with adding them to SVG even if we try to. SVG should not be a monolithic document but describe the core of SVG. Just as the HTML spec does for HTML. Special casing every property in SVG itself however is not a solution IMO. It is a huge burden to track all changes on other specs for the editors as well.

We should focus on a clear and self contained core document. We of course need to review CSS specs as they apply to SVG and make sure that these are compatible.

Greetings,
Dirk

> 
> Again, such examples will help authors.
> And if those examples are normative, it means we could use them as implementation test :)
> -- 
> Jeremie
> .............................
> Web : http://jeremie.patonnier.net
> Twitter : @JeremiePat

Received on Tuesday, 20 May 2014 12:50:14 UTC