Re: Clean-up SVG2 spec

On May 21, 2014, at 1:00 PM, Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de> wrote:

> Hello,
> 
> currently SVG 1.1 explicitly defines, which CSS properties apply to SVG 1.1 
> documents (implicating as well, which do not apply, what helps authors to use
> the same style sheet for (X)HTML documents and SVG documents and mixed
> documents SVG+XHTML).
> And it explicitly defines, if such CSS properties have values, that do not 
> apply in the same way to SVG content and what to do, if they are noted 
> anyway.
> Even more, in SVG it is possible to use most applicable properties as 
> presentation attributes (not available in CSS at all).

Right, there have been presentation attributes which are not defined by CSS and belong to SVG core. I do not argue that this should stay in SVG. I never said that we remove everything that is slightly related to CSS. There is just no need to keep redundancy that will always be outdated. CSS is evolving all the time and to keep SVG up-to-date and back port all these changes is illusory. Relying on well defined CSS sub modules makes sense. Of course it is the task of the SVG WG to review these submodules and make sure that intersections with SVG do not cause interoperability. If they do, SVG should not try to fix it, but the responsible CSS sub module should be fixed instead.

> 
> Therefore there is an obvious need to mention all this in SVG 2 as well.

I agree.

> 
> Additionally one has to take care, that for CSS properties not applicable
> for SVG 1.1 or with a different definition (for example in CSS 2.1 or a CSS 3 
> modul different to CSS 2.0, applicable now), that there do not appear 
> backwards incompatibilities due to changes in CSS, therefore one can
> expect that the SVG 2 draft contains text to describe different behaviour
> to avoid backwards  incompatibilities introduced by changes in CSS
> (what might be of some use for CSS alone).

I agree with you. To a certain amount there are differences. In general we can divide CSS into two main categories:

1) Layout and the related box model which does not apply to SVG elements.
There are intentions of some WG members to bring layout to SVG as well. At this point SVG has a simple positioning based system.

2) Graphics and decorations.
This absolutely applies to SVG. Examples are CSS Transforms, Filter Effects, Web Animations, CSS Masking, Geometry Interfaces, CSS Compositing and Blending, CSS Colors, CSS Text decoration and partly CSS Inline as well as CSS3 Text.

We need to make sure that specs in the second category apply to SVG. These specs should deal with differences between markup languages as much as possible. And of course the world is not black and white either. Some parts always have to be specified in SVG itself.

> 
> Obviously one can reduce definition text for unproblematic issues, 
> but to remove everything without care, results in a loss of those information
> already available about specific behaviour in SVG.

That is not what I suggested. Yes, everything should be reviewed to avoid incompatibilities. CSS Text Decoration is one example where a WG member (Tav) found issues with the integration into SVG. Instead of “hacking” exceptions into SVG, we must work together with CSS to resolve these issues. Tav started a discussion on www-svg and www-style about his findings. I am sure that we can find a general solution that serves HTML and SVG and hopefully other markup languages as well.

> 
> For readers of the draft/recommendation it is obviously a big help to
> get at least a complete lost and some none normative description of all
> applicable properties without the need to download any CSS recommendations 
> or drafts as well and in case of offline-reading searching definitions 
> manually, because links do not work anymore.
> Indeed, if the SVG 2 recommendation is splitted into hundreds of different
> recommendations, this results in the problem, that one can forget about
> offline-reading.

Many parts haven’t been specified in SVG 1.1 either and SVG just referenced other specifications. One never get the whole picture without looking beyond one’s own nose.

> 
> And if there is more than just 'one' SVG 2 it is even more problematic
> for authors to predict, at which time one really can use SVG 2, because
> it can be assumed to be completely specified and defined at this time
> (for many authors it would be even more relevant to know, at which time
> a recommendation is really implemented as specified, but we already learned
> from HTML, SVG, CSS, that this does not happen in practice anyway ;o)

I suspect that you mean sub modules with “more then ‘one’ SVG 2”. I do not think that we are actively splitting SVG core into further sub modules. The SVG WG just agreed that SVG matches the behavior of CSS as specified by the CSS WG as close as possible. Again, it is the task of the SVG WG to review CSS specs and make sure that these specs do not cause interoperability issues with SVG.

Greetings,
Dirk

> 
> Olaf
> 
> 
> 
>

Received on Wednesday, 21 May 2014 20:47:20 UTC