RE: Differences In SVG and CSS (was: SVGT 1.2: !important is an error)

Hi Ian,
Your previous email which listed all of the parsing differences between
properties as presentation attributes and properties within CSS
stylesheets:
------------
...Case-sensitivity, scientific notation, the infamous lengths without
units, escapes, support for IRIs as opposed to URIs, ...
------------
was a great start on listing the syntax differences. Add in the rgba()
question, where the SVG WG is highly unenthusiastic in general and might
want to keep out of Tiny if not Full. Also, we need to keep in
perspective the fact that all of this excitement is over a relatively
small number of shared properties from CSS that can be used as
presentation attributes in SVG: 
------------
Tiny 1.2's has 7 shared properties: font-family, font-size, font-style,
font-weight, color, display, visibility.
Full 1.1's adds 8 other shared properties, two of which are deprecated
in CSS21: font-size-adjust [dropped with CSS21], font-stretch[dropped
with CSS21], font-variant, direction, unicode-bidi, letter-spacing,
word-spacing, text-decoration
------------
My conclusion is that we should treat SVG's presentation attributes as
SVG things and thus have the SVG spec fully define their syntax (EBNF
where appropriate). Thus, the specification for presentation attributes
should be (from a spec perspective) independent of the specification of
the corresponding properties when used in CSS stylesheets. (Although
obviously we don't want to introduce gratuitous divergence going forward
unless there is a compelling reason.)

There has been talk about CDF and/or browser implementers who will have
a strong interest in sharing code between their HTML+CSS implementations
and their SVG implementations. Sharing code of course is good, but is
best thought of as an implementation decision rather than a
specification decision. In other words, if an implementer wants to
attempt to share the same parsing logic between the CSS definition of
'font-size' and SVG's 'font-size' presentation attribute, they certainly
can pursue that approach, but other implementers might find it is easier
to write different parsing logic for SVG's 'font-size' presentation
attribute or factor out those parts which can be shared.

Jon


-----Original Message-----
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf
Of Ian Hickson
Sent: Thursday, January 12, 2006 3:37 PM
To: Doug Schepers
Cc: www-svg@w3.org
Subject: Re: Differences In SVG and CSS (was: SVGT 1.2: !important is an
error)


On Thu, 12 Jan 2006, Doug Schepers wrote:
>
> Note also, I'm operating under the assumption that there will need to
be 
> a separate parser (or subparser) for presentation attributes and 
> presentation properties, which somewhat reduces the burden of total 
> compatibility.

My e-mail was in reply to Robin's e-mail and was covering the lexical 
space, not the value space. If you grant that there will not be parser 
re-use, then I don't understand what you are asking. The value space is 
not an issue as far as I know. (There might be some ambiguity with
rgba(), 
but that is easily solvable by simply defining it one way or another.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 13 January 2006 00:36:20 UTC