W3C home > Mailing lists > Public > www-svg@w3.org > July 2008

Re: Applying SVG properties to non-SVG content

From: David Hyatt <hyatt@apple.com>
Date: Sat, 12 Jul 2008 16:16:20 -0700
To: robert@ocallahan.org
Cc: Bert Bos <bert@w3.org>, "www-style@w3.org" <www-style@w3.org>, www-svg <www-svg@w3.org>
Message-id: <22570BC7-3CE5-4200-9DBC-0BA8E022C327@apple.com>

On Jul 11, 2008, at 1:41 PM, Robert O'Callahan wrote:

> There's also a strategic issue within the standards community. It  
> seems the "path of least resistance" to adding a single feature to a  
> standard like CSS (or SVG) is to just go ahead and extend CSS (or  
> SVG) with a new spec for that feature, rather than creating a  
> dependence on another standard that has that feature.

On the other hand if using the other standard would be clumsier than  
simply extending the original standard (as is the case with - for  
example - CSS-based gradients vs. being forced to link to an external  
SVG file just to do a gradient that is cleanly separated from your  
HTML presentationally), then I think that should be taken into  
consideration.  When integrating SVG and CSS we need to look for  
integration points that really unleash SVG's power into HTML (via  
CSS).  I think your proposal does this, so that's great.

However I would not want to see this work used as an argument for  
preventing CSS from extending at all into territory that overlaps with  
SVG, since in many cases i think the CSS properties could integrate  
*back* into SVG (e.g., CSS transforms).

If the alternative would be extremely clumsy to specify in CSS, then I  
think integration with SVG is good.  However using SVG just to do  
syntactically simple effects (like transformations or gradients) is  
overkill.  (This doesn't mean we shouldn't support it as part of a  
more general mechanism, but we should not be afraid to invent  
"syntactic sugar" to make life more convenient for authors.

There is room for overlap is basically all I'm saying. :)
Received on Saturday, 12 July 2008 23:17:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:19 UTC