- From: Dean Jackson <dean@w3.org>
- Date: Tue, 1 Mar 2005 10:20:02 +1100
- To: www-svg@w3.org
[Here is a copy of the response the SVG Working Group sent
to the CSS Working Group. I've posted it here so that there
is a public copy (since the comments were public). The
real response went directly to the CSS private list]
Hello Bert,
Thanks for the comments. This is the official response from
the SVG Working Group.
On 29 Nov 2004, at 09:45, Bert Bos wrote:
> 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...
Thank you. We're changing the way we package our specifications which
should make it easier to review. Also, we describe in detail each
feature, and provide many examples. This makes the specification
larger but better.
> 2) UNITLESS LENGTHS
>
> (Inherited issue from SVG 1.1)
Aside: Any system that uses arbitrary transformations must necessarily
use a unitless coordinate system, and therefore cannot use units
everywhere. Also, we have a lot of legacy content that requires a
unitless coordinate system.
> 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).
We have feedback from a number of implementers who have not found
implementing SVG and CSS in the same cascade a problem.
> Thus we request that unitless lengths be limited to attributes, and
> not allowed in stylesheets.
We agree that this issue in general is a problem. We propose the
following resolution:
- disallow unitless lengths in the 'font' shorthand property.
- we don't (yet) have 'line-height'.
- limiting unitless lengths to attributes breaks backwards
compatibility with existing implementations and a W3C Recommendation
since 2001, and is also inconsistent with a future Compound Document
architecture which unifies XHTML, SVG and CSS.
- we believe the appropriate time to resolve the issue on the conflict
between SVG's unitless lengths and strict CSS2 parsing is when the
issue comes up in the Compound Document Formats Working Group.
> 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.
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.
> 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.
Yes, we'll make appropriate adjustments to our "Introduction" chapter
in case there are clarifications needed in regards to the scope of the
SVG language.
> 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.
We agree.
> 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.
Like CSS, we tended to go for shorter property names rather than the
verbose forms favoured by XSL. This helps readability and makes
authoring content easier.
Regarding the naming being too generic and the potential for future
clashes, the SVG Working Group supports the suggestion that the W3C
establish a process to coordinate the way property names are
assigned. This process should then be used by all Working Groups that
create new properties, such as XSL, CSS and SVG. We don't think that a
Working Group should restrict another Group from choosing a property
name, especially when no use for a name has been found in the past 7
years. We expect most Working Groups will want to choose the most
appropriate names for new properties and don't think that avoiding
generic names is the best solution for content authors. We also think
that a long-term solution for avoiding naming conflicts should be
investigated - such as using namespaces with formatting properties
More details on our position can be found in the following messages:
http://lists.w3.org/Archives/Public/www-svg/2004Nov/0316.html
http://lists.w3.org/Archives/Member/w3c-css-wg/2004OctDec/0226.html
(Member Only)
> 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.
We have the requirement to provide a simple method for automatic line
breaking in an environment without CSS. This continues to be the most
commonly requested feature from the days before SVG 1.0 REC, and is a
standard feature in nearly all graphical authoring tools.
Our next draft of SVG will have an revised method for this feature. It
aligns more closely with the existing SVG 1.0+ text features - only
adding automatic line breaking (with an option to allow the User Agent
to choose the break points). The end result can be easily expressed
using the SVG 1.0+ text elements. We also believe it has less overlap
with CSS layout. As a graphical language, we're replicating standard
graphic features and avoiding many text-layout features.
> 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.
Although we agree there is a superficial similarity between CSS3 Paged
Media and SVG's paging features they are not closely
related. Similarly, SVG's paging features and XSL-FO master pages are
only superficially similar. The term 'page' does not mean the same
thing in all technologies. In SVG, we needed a term which would make
sense for streaming animation (e.g. "scene") as well as one that would
make sense for print streams. We chose "page".
There are many differences between SVG's paging features and CSS3
Paged Media. SVG does not have dynamic page separation at runtime;
Rather, it is part of the document structure. Also, one key aspect of
SVG's paging is the tight integration with SMIL and its timing module
(important when streaming an animation). Another important difference
is the way SVG provides a final-form document that facilitates
resource management (e.g discarding a page's content once it has been
rendered). CSS3 Paged Media does not share these goals.
> c) The 'rendering-color-space' property appears to be redundant with
> CSS3 Color's 'color-profile' property.
No, it is not the same thing at all. Color-profile is for specifying
colors. Rendering-color-space is how to do interpolation and
combination of specified colors.
This is important for gradients, color animations, filters and alpha
blending/compositing.
> 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.
We had a lot of discussion about adopting 'z-index' but unfortunately
it causes a lot of problems with SVG's rendering model (another
example of a generic property name not being as generically useful as
you'd like). I think we all wanted this as a solution, but it would be
something that would cause performance problems.
SVG needed something where the "layer" is put into a completely
separate compositing phase. Also, we wanted the user agent to be able
to leverage the Operating System's underlying windowing technology if
possible.
The 'z-index' property only creates a stacking context within the
nearest containing viewport. It also interferes with the Painter's
model for rendering, which makes it incompatible with SVG.
Therefore, given all the incompatibilities and problems, we think
calling this property 'z-index' would be misleading.
> 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.
The reason we have an 'audio-level' property is that we have taken our
audio features from the SMIL language (in particular <audio> and
<video> elements). In SMIL, the "volume" of these elements is
controlled by the 'volume' property on the container elements. Since
we don't have SMIL containers, we were required to add a property
directly to the element. We renamed it 'audio-level' to align with the
features defined by the Voice Browser Working Group ('voice-level').
Regarding the introduction of sound-related features, we're instead
adding more integration of SMIL into SVG. These features are extremely
common in multimedia animations - a target application for SVG
content.
> 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.
Our revision of this feature allows for the user agent to control
the line layout, and thus is aligned with CSS.
> 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.
It is being used unchanged. The 'text-align' property is taken from
XSL because it is stable (REC from 2001), internationalized and does
not have problematic values such as 'left' and 'right'.
For details: http://www.w3.org/TR/xsl/slice7.html#text-align
> c) The 'page-orientation' properties conflicts with the paged media
> mechanisms of CSS.
We don't agree. Our 'page-orientation' property is a hint for
displaying the content; It doesn't actually effect the
content. However, we do think that our explanation of this property
could be improved and that 'page-orientation' should be an
attribute. Thanks for the feedback that encouraged us to notice this.
By the way, we really think CSS shouldn't have a property named 'size'
for all the reasons that you have given about generic property
naming. Also, it's confusing that CSS has a property named 'size' that
specifies the orientation of a page.
> 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.
We agree that we should remove the ":edited" pseudo-class. Thank you.
> 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.
Having this level of indirection is extremely valuable. It allows the
color to be defined once, named and reused multiple times. It also
allows for animation and styling. This is the reason why many of our
color servers are properties ('stop-color' and
'lighting-color'). Having 'solid-color' as a property is consistent
with the rest of the language. We understand that it creates extra
processing for user agents, but feel that this extra processing is
justified.
As an aside, we were noticing that people were creating this effect by
referencing a gradient with two stops of the same color. This hack
causes twice as much indirection.
> 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.)
This is a request from the technical graphics community who identified
this as a critical missing feature. The differences between
':highlight' and ':target' are due to the behaviour of the SVG
fragment identifier syntax, which allows an optional viewTarget
parameter. ':highlight' is only active when a viewTarget is given,
whereas ':target' is active every time you follow a link. The SVG WG
may consider adding support for ':target' in the future, but
':highlight' is a different feature.
Details on SVG Fragment Identifiers:
http://www.w3.org/TR/SVG11/linking.html#SVGFragmentIdentifiers
> 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.
We've modified the flowed text feature to align it closely with the
standard text features of graphics systems and in the process removed
the need for layout properties. Therefore margin and indent no longer
apply.
> 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).
We agree. We are changing 'focusable' to be an attribute.
> 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.
As we said when you introduced rgba(), we think it is the wrong
solution. We allowed rgba() in SVG 1.2 (and SVG 1.2 Tiny) until we
concluded (again) that it wasn't useful.
Here's a simple example:
- Fill an object with 50% transparent green and stroke it with 100%
opaque blue.
- Animate the green fill to red and back every 10 seconds, forever.
- Fade the fill in and out (ie. animate the fill transparency from 50%
to 0%) every 7 seconds, but only 5 times in total.
Try implementing this example using rgba() without '*-opacity'.
Also, we believe that having opacity always tied to a color value is
short-sighted. It is possible to paint an object with gradients and
patterns, not just colors. It must be possible to control the opacity
of the paint in all situations.
In summary, it is essential that the opacity values of color
properties are separable.
Therefore, we suggest that you consider removing the rgba() color
syntax from CSS3. We believe it will impose some unwanted restrictions
in the long term and have provided technical arguments to this effect
for many years.
> 11) CR EXIT CRITERIA
>
> We suggest that SVG 1.2 use a similar CR Exit Criteria as is being
used
> for CSS 2.1.
Thanks for the suggestion. We'll consider this feedback when we are
discussing our CR exit criteria.
Dean,
for the SVG Working Group
Received on Monday, 28 February 2005 23:20:06 UTC