- From: Jon Ferraiolo <jonf@adobe.com>
- Date: Thu, 12 Jan 2006 16:37:05 -0800
- To: "Ian Hickson" <ian@hixie.ch>, "Doug Schepers" <doug.schepers@vectoreal.com>
- Cc: <www-svg@w3.org>
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