[SVGMobile12] Comments by the CSS WG

Hello SVG WG,

Here are the comments from the CSS WG on SVG Tiny 1.2[1]:

   a) We support Björn Höhrmann's message[2].

   b) Our comments from November[3,4] on SVG 1.2 partly still apply to
      Tiny 1.2 as well. See the list below.

   c) Our comments from September[5] on the previous last call were
      apparently never answered. See the list below.



*** Ad b. From our comments on SVG 1.2:


b.1) SIZE

[Does not apply to SVG Tiny 1.2. 400 pages is a lot, too, but it isn't
1000...]


b.2) UNITLESS LENGTHS

(Inherited issue from SVG 1.1)

[It is not clear if SVG UAs may apply a style sheet to an SVG Tiny 
document, see question c.5 below. But assuming they may, the following 
applies.]

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.


b.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.


b.4) UNCLEAR SCOPE

[No longer applies]


b.5) PROPERTIES WITH BOOLEAN VALUES

[Doesn't apply to SVG Tiny 1.2.]


b.6) PROPERTIES WITH DANGEROUSLY GENERIC NAMES

[Doesn't apply to SVG Tiny 1.2]


b.7) OVERLAP WITH CSS

a) We are concerned that section 10.11, Text in an area, 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) [Doesn't apply to SVG Tiny 1.2]

c) [Doesn't apply to SVG Tiny 1.2]

d) [Doesn't apply to SVG Tiny 1.2]

e) [Doesn't apply to SVG Tiny 1.2]


b.8) CONFLICTS WITH CSS

a) The algorithm described in section 10.11, Text in an area, is
different from the CSS line layout algorithm. We feel that having two
different layout algorithms will cause problems for implementors.

For example, it isn't defined what the relation of 'line-height' and
'line-increment' is, although the text claims that 'line-increment' can
be expressed in terms of 'line-height'. In fact, 'line-increment: auto'
appears to be close to, but not exactly the same as 'line-height: 1em'.

b) [Doesn't apply to SVG Tiny 1.2]

c) [Doesn't apply to SVG Tiny 1.2]


b.9) EXTRANEOUS FEATURES

a) [Doesn't apply to SVG Tiny 1.2]

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) [Doesn't apply to SVG Tiny 1.2]


b.10) OTHER ISSUES

a) [Doesn't apply to SVG Tiny 1.2]

b) [Doesn't apply to SVG Tiny 1.2]

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.

The answer of the SVG WG, that animating the opacity independent of the
colour requires separating them, is not convincing. For the same
reason, you might want to separate the V from the hsv value, for
example, or the G from the rgb (to simulate a broken CRT, for example).

Having separate properties for the different aspects of color for every
property that accepts color multiplies the number of properties (costly
to implement, costly to document and costly to learn to use) and
interferes with cascading (things that are always specified together
should be specifiable with a single property).


b.11) CR EXIT CRITERIA

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



*** Ad c. from our comments on the previous draft for Tiny 1.2:


Overall comments
----------------

[It may be that this comment no longer applies. The language for
"baseProfile" and related features seems to have changed.]

Why is there a hardware-specific profile at all? Shouldn't W3C specs
be designed to be device-independent, with fully compliant documents
working on all devices, and advanced features using graceful fallback
where appropriate? (For example, a gradient could fallback to a solid
colour, instead of causing the entire image to be in error and report
a failure.)




Specific comments
-----------------

ABSTRACT

[no longer applies]


STATUS OF THIS DOCUMENT

[no longer applies]


c.3. DATA TYPES

[no longer applies]


c.4. DOCUMENT STRUCTURE

[no longer applies]


c.5. STYLING

[no longer applies]

| SVGT does not support styling with CSS.

Does this mean that a compound document that uses CSS in the XHTML
section and which, with inheritance, sets values on the SVG nodes for
properties such as 'fill', 'stroke', or 'color', will render
differently in SVG Tiny processors than in SVG Full processors?

If so, does that mean SVG Tiny is not a compatible subset of SVG Full?


c.6. COORDINATE SYSTEMS, TRANSFORMATIONS AND UNITS

[no longer applies]


c.8. TEXT

[no longer applies]


c.17. ANIMATION

[no longer applies]


APPENDIX E. SVG TINY CONFORMANCE CRITERIA

[no longer applies]


Process Comments
----------------

What will the CR Exit Criteria be? Will it require two complete SVG
1.2 Tiny implementations? Will a test suite be used? Will tests be
accepted from the community? Will full compliance to the test suite be
required for the implementations to be considered interoperable?



PS. There's a typo in the example solidcolor.svg:
fill="url(#solidCrimson)n" has an "n" too many.


[1] http://www.w3.org/TR/2005/WD-SVGMobile12-20050413
[2] http://lists.w3.org/Archives/Public/www-svg/2005Apr/0255
[3] http://lists.w3.org/Archives/Public/www-svg/2004Nov/0549.html
[4] http://lists.w3.org/Archives/Member/w3c-css-wg/2005JanMar/0173
[5] http://lists.w3.org/Archives/Member/w3c-svg-wg/2004JulSep/1158.html


For the CSS WG,
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 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Monday, 23 May 2005 11:36:43 UTC