Re: [SVGMobile12] Comments by the CSS WG

Hi Bert,

Thanks for the comments.
These are personal answers, not from the SVG WG.

On 23/05/2005, at 9:36 PM, Bert Bos wrote:

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

Is there any reason why you didn't answer the SVG WG response (other
than for rgba() which I'll respond to below)? If you're simply
resubmitting the comments, that's fine, but the group already
responded.

http://www.w3.org/mid/9d0315d6ba53f1a0c22817fcae161ddd@w3.org

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

Yes, sorry for the delay.

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

In our previous response, we agreed that this is a serious
problem, but described that there isn't an easy solution.
Limiting unitless lengths to attributes isn't backwards or
forwards compatible. Can you suggest any other approaches?

For 'font' maybe we could disallow the 'font' shorthand property
in SVG (we don't have a 'font' attribute equivalent). Would that
remove the ambiguity for CSS processors (but still allows unitless
lengths on 'font-size')?

We don't have 'line-height' in Tiny, but below you suggest it may
be worth adding it in (to replace 'line-increment'). If so, we
can probably live with the CSS unitless meaning (a multiplier).
In other words, we might be able to use the CSS definition
but disallow units for SVG Tiny.

What other properties cause problems?

I hope you can use your CSS expertise to help us solve this
issue.

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

Again, we've already answered this, but I'll include it
again here.

Reading http://www.w3.org/TR/CSS2/selector.html#dynamic-pseudo-classes
[[[
CSS doesn't define which elements may be in the above states, or how
the states are entered and left. Scripting may change whether elements
react to user events or not, and different devices and UAs may have
different ways of pointing to, or activating elements.
]]]

Our understanding is that according your wording our specification of
hover is acceptable (for interoperability we define how the state is
entered and left). We use the W3C Recommendation for event processing
(DOM Events). We've integrated our hover processing with that event
model. Perhaps if there was an extension to the DOM Event model for
the "hover" event we'd consider making a change.


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

Again, please read the response we made the first time
you gave this comment.

In short, we need a solution that works without CSS. We also
changed the feature, to the annoyance of many SVG implementers,
to have less overlap with CSS.

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

The intent was to be compatible with CSS in this regard (which
basically allows an implementation to do the best it can). Your
comments about line-height and line-increment are useful, thanks!

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

Again, please read our existing response.

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

Which part didn't you find convincing? The fact that it's incredibly
difficult to author if they are not separated, or the fact that
anyone would want to do it, or something else?

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

I argue that these are extremely rare cases, while separating
opacity from colour is extremely common. This is the case in
Photoshop, Flash, Illustrator, Corel Draw, The Gimp, Postscript,
PDF and just about every other graphics technology.

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

We've told you many times that they are *not* specified together.

Seeing as you weren't convinced last time, I'll give another
more simple example.

<linearGradient id="g1">
   <stop offset="0" stop-color="red"/>
   <stop offset="0.5" stop-color="rgb(10, 34, 122)"/>
   <stop offset="1" stop-color="#723"/>
</linearGradient>

<rect width="20" height="20" fill="url(#a)"/>

Now make the fill 50% transparent. Can you see how much more
difficult and complicated this is without fill-opacity? Suppose
the fill is a <pattern> - without fill-opacity it is *impossible*
to set the transparency.

Basically, having separate colour and opacity information
is an absolute requirement for SVG. We can't accept your solution
that violates this requirement.

Dean

Received on Monday, 23 May 2005 14:39:50 UTC