Re: [SVGMobile12] Comments by the CSS WG

Dean and Bert,
One note about the revised approach the wrapping text in the latest draft 
of SVG-t 1.2. Dean says that we purposely attempted to have less overlap 
with CSS facilities. That is probably only half the story. The rest of the 
story is that we purposely increased the alignment of SVG's wrapping text 
facilities with the single-line text features that were in SVG 1.0 and 1.1. 
In part, you can thank Ian for his fantastic feedback on the SVG language 
and the previous definition of the wrapping text feature in particular 
where he proposed simply adding a 'width' attribute to SVG's existing 
<text> element. The new SVG-t 1.2 text wrapping feature does not use the 
exact syntax that Ian proposed, but it provides pretty much the same 
approach. With the newly-reconstituted text wrapping feature, you just have 
the same single-line text from SVG 1.0 and 1.1 that goes forever along a 
path (which is usually a straight line), except with the extra wrinkle in 
SVG 1.2 that with <textArea> the text will wrap if the text is longer than 
the area is wide. But that's it. No paragraphs, no boxes, no box model.

Getting back to Dean's comment, with this approach an SVG implementer can 
add text wrapping with minor changes to his existing SVG text code. He 
doesn't need to add Gecko or other box model text engine to implement SVG-t 
1.2 text wrapping.

Jon

At 07:39 AM 5/23/2005, Dean Jackson wrote:

>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 20:21:25 UTC