- From: Dirk Schulze <dschulze@adobe.com>
- Date: Thu, 23 Jan 2014 13:15:05 +0000
- To: Paul LeBeau <paul.lebeau@gmail.com>
- CC: www-svg <www-svg@w3.org>
On Jan 23, 2014, at 11:28 AM, Paul LeBeau <paul.lebeau@gmail.com> wrote: > Just to play devil's advocate for a moment... There is already a mechanism for using bitmaps for fills and strokes - <pattern>. Since SVG is supposedly a first-class citizen now, why don't the CSS guys just leverage the existing SVG abilities? It is. That doesn’t mean that SVG can’t use some magic that is already part of CSS but not SVG. > Does there really need to be multiple ways to do everything? This gives authors the freedom of choice. I do not see anything particular bad about it. There is nothing that SVG gradients can’t do but CSS gradients can (at the moment). This doesn’t mean that specifying a CSS gradient can’t be simpler in some cases. Repeating images? corssfading images?.. All that can be done with SVG patterns, yes. Why should authors be limited to SVG patterns though? Keep in mind: There is no stronger enemy than the habit of people. Authors familiar with HTML+CSS might have a hard time learning about <pattern> or <linearGradient> but a rectangle might still be in the shorter range. Let them draw the SVG rectangle but use their ways to style it. > > Does complicating the definition of fill and stroke make things all that much simpler? Okay, so animating bitmap strokes will be easier to do with CSS. But do we really want that anyway (*shudder* ;)? The good thing: SVG people don’t need to use it. They can continue using the same simple syntax if they which. fill: url(#gradient) will still work. If you chose to, you can go beyond it. Greetings, Dirk > > Paul > > > > > On 23 January 2014 22:32, Erik Dahlström <ed@opera.com> wrote: > On Wed, 22 Jan 2014 18:05:16 +0100, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > > On Wed, Jan 22, 2014 at 8:36 AM, Dirk Schulze <dschulze@adobe.com> wrote: > On Jan 22, 2014, at 4:34 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > You can wrap a color in image() to transform it into an <image> value. > > I just wanted to point out that: > > background: url(“image.png”) red; > > means something different than: > > fill: url(“image.png”) red; > > In the first example the color is drawn, in the second it is just a fallback. > > This is unfortunate but can not be changed. > > Ah, gotcha. I'd forgotten about that unfortunate aspect of the grammar. > > ~TJ > > It would be interesting to have some stats on how much content would break if we were to change to the interpretation used in the background property. The example "fill: url(image.png) red" is unlikely to be found anywhere since that isn't going to render the image based on SVG 1.1. I'm wondering how much of a need there really is to have the fallback color in the first place, maybe this is something we should revisit? There might be a better alternative. > > Do the most common svg authoring tools typically provide the fallback color for fill/stroke? My guess is that they don't. > > > > -- > Erik Dahlstrom, Web Technology Developer, Opera Software > Co-Chair, W3C SVG Working Group > >
Received on Thursday, 23 January 2014 13:15:37 UTC