- 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>
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:16 UTC