- From: Tavmjong Bah <tav.w3c@gmail.com>
- Date: Tue, 20 May 2014 12:44:07 +0200
- To: Dirk Schulze <dschulze@adobe.com>
- Cc: SVG public list <www-svg@w3.org>
On Tue, 2014-05-20 at 09:03 +0000, Dirk Schulze wrote: > Hi, > > 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. > I agree that we should mention all specs SVG is relying on. We should have a section describing all normative referenced specs and the interaction with these specs. However, this should be similar to the “Module Interactions” sections in CSS specs[3]. This section would be very large and separating the details from the relevant SVG sections would not lead to a clearer specification. > 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. > Everything that is covered by a kind of stable CSS spec (CR and up) should be removed from SVG2 entirely and *definitely* don’t redefine the property but extend it if it should be a requirement for SVG that can’t wait for CSS. Mention the interaction in a “Module Interactions” section and add more details to the Changes section. If something like shape-inside is not in a stable CSS spec, it is probably not ready for SVG anyway and we shouldn’t try to do our own thing in SVG. We did this mistake in the past. CSS and SVG are much more integrated and the WGs have common meetings nowadays. I don't think there is any intent to redefine things from CSS. There are often subtle differences in how things applied to SVG differ from how they are applied to HTML. Again, it helps to have examples of use in the SVG specification. Tav > [1] https://svgwg.org/svg2-draft/text.html#Alignment > [2] https://svgwg.org/svg2-draft/filters.html > [3] http://dev.w3.org/fxtf/css-masking-1/#placement > [4] https://svgwg.org/svg2-draft/text.html#TextShapeOutside
Received on Tuesday, 20 May 2014 10:44:38 UTC