CSS WG comments on SVG 1.2

Hello SVG WG,

Here the promised comments from the CSS WG.



1) SIZE

The SVG 1.2 spec is more than 1000 pages. That's maybe too much. At 
least it is hard to do a thorough review and we think this list of 
issues is not complete...


2) UNITLESS LENGTHS

(Inherited issue from SVG 1.1)

Lengths must have units in CSS; without units some properties in CSS
are ambiguous (e.g. 'font', 'line-height'). Unitless lengths are in
fact not catered for by the CSS core syntax; implementations are
unable to implement both SVG and CSS in the same cascade (as required
by multi-namespace documents).

Thus we request that unitless lengths be limited to attributes, and
not allowed in stylesheets.


3) HOVER PROCESSING

(Inherited issue from SVG 1.1)

SVG 1.1 suggests that canceling a mouse event can affect which
elements match the :hover pseudo-class. This is incorrect, the :hover
pseudo-class must be unaffected by DOM events processing.


4) UNCLEAR SCOPE

It is unclear what the scope of SVG 1.2 is, which makes it hard to
comment on other aspects of the specification.

We request that a scope section be added and a new last call draft
submitted, so that the draft can be more adequately reviewed.


5) PROPERTIES WITH BOOLEAN VALUES

Several properties in SVG 1.2 (including 'clip-to-self', 'knock-out',
'background-fill', 'overlay-host', 'cache', 'static', 'snap',
'focusable', and 'tooltip') accept boolean values ('true'/'false',
'enable'/'disable'). To ensure that new values can be added to
properties in the future, CSS avoids boolean values and instead used
keywords that are self-descriptive. We request that the value names be
changed to be clearer.


6) PROPERTIES WITH DANGEROUSLY GENERIC NAMES

Several properties in SVG 1.2 (including 'enable-background',
'overlay', 'cache', 'static', 'snap', 'focusable', 'tooltip') have
names that are likely to clash with future CSS extensions. Since the
SVG-introduced properties apply only to specific SVG cases, whereas
the CSS properties are generic, we request that the SVG property names
be made more specific to avoid future clashes.


7) OVERLAP WITH CSS

a) We are concerned that section 4, Flowing text and graphics, overlaps
directly with CSS. We feel that instead of adding line layout to SVG,
it would be wiser to add a way to specify a fill shape to CSS.

b) Section 5, Multiple pages, seems to overlap with CSS3 Paged Media. We
feel that instead of adding a new paginated layout algorithm, SVG
should integrate with the CSS paginated layout mechanisms.

c) The 'rendering-color-space' property appears to be redundant with 
CSS3 Color's 'color-profile' property.

d) The 'overlay' property appears to be similar in intent to CSS's
'z-index' property. It would be good to use 'z-index' (in a compatible
way of course) so that implementations do not have to cascade both
properties simultaneously, using one for one namespace and the other
for the rest.

e) The 'audio-level' property overlaps with properties in the CSS3 Voice
and CSS3 Audio drafts. We feel that it is inappropriate for the
Graphics activity to be introducing sound-related features.


8) CONFLICTS WITH CSS
a) The algorithm described in section 4, Flowing text and graphics, is
different from the CSS line layout algorithm. We feel that having two
different layout algorithms will cause problems for implementors.

b) The 'text-align' property in SVG 1.2 is different than in CSS. This
makes it impossible for the property to be used in a mixed-namespace
environment. We request that the property be used unchanged.

c) The 'page-orientation' properties conflicts with the paged media
mechanisms of CSS.


9) EXTRANEOUS FEATURES

a) We feel that the ':edited' pseudo-class is unnecessary given that it
maps directly to a simpler, existing selector. Adding pseudo-classes
should be considered expensive, and adding pseudo-classes without
defining how they work in non-SVG contexts should be avoided.

b) The 'solid-color' property seems to introduce too many levels of
indirection. Given that the introduction of this property requires
that its value be computed (or computable) for every element in the
DOM, its limited usefulness doesn't seem to outweigh its cost. In
particular, note that an element's fill colour can now take the following
stops to be determined: cascade for 'fill' property, look up paint
server, cascade for 'solid-color', cascade for 'color'. This seems
excessive.

c) SVG 1.2 claims to introduce the ':highlight' pseudo-class. We request
that this property be removed from SVG until such time that the SVG
group has explained the purpose of this pseudo-class and the CSS group
has had the opportunity to examine it in more detail. In particular it
is unclear how this pseudo-class differs from the ':target'
pseudo-class. (In case there are any other new pseudo-classes that
were missed during this review, the same applies to them.)


10) OTHER ISSUES

a) It is unclear how the margin and indent properties apply to the flowed
text feature. Both properties are mentioned in passing but the model
is never fully explained. In particular, it appears to be different to
the CSS model in important ways, although exactly how different is
unclear due to the ambiguity of the description.

b) Whether an element is focusable or not should not be controlled by a
property, since the cascade can depend on this information (due to the
':focus' pseudo-class).

c) Given the introduction of rgba() in CSS3 Color, we recommend the
deprecation of the '*-opacity' properties in SVG and the adoption of
CSS3 rgba() colour syntax instead.


11) CR EXIT CRITERIA

We suggest that SVG 1.2 use a similar CR Exit Criteria as is being used
for CSS 2.1.



Bert
-- 
   Bert Bos                                ( W 3 C ) http://www.w3.org/
   http://www.w3.org/people/bos                               W3C/ERCIM
   bert@w3.org                             2004 Rt des Lucioles / BP 93
   +33 (0)4 93 65 76 92            06902 Sophia Antipolis Cedex, France

Received on Sunday, 28 November 2004 22:46:14 UTC