W3C home > Mailing lists > Public > www-style@w3.org > October 2009

Re: [css3-background] Preparing for Last Call

From: Bert Bos <bert@w3.org>
Date: Thu, 8 Oct 2009 17:27:33 +0200
To: "www-style@w3.org" <www-style@w3.org>
Message-Id: <200910081727.33971.bert@w3.org>
On Thursday 08 October 2009, Andrew Fedoniouk wrote:
> Bert Bos wrote:
> > On Wednesday 07 October 2009, Brad Kemper wrote:
> >> On Oct 6, 2009, at 10:49 AM, Bert Bos <bert@w3.org> wrote:
>
> ...
>
> > Of course, as the support for SVG improves and spreads to more CSS
> > implementations, many of the images won't even be PNG, but will be
> > replaced by SVG images and scaling won't be a problem anymore.
>
> If you would have SVG why do you need that strange (from SVG point of
> view) way of defining things like background brush named
> background-image and another [stroke] brush for some reason named as
> border-image?
>
> In CSS you just need something like background-repeat: fill | expand
> and single image that will be that SVG image defining your
> background/border layer.
>
> I mean that you will need either one: SVG or that multi-image
> paradise. For some reasons I do not see how SVG will play with e.g.
> border-image thing. So, Bert, could you elaborate on what you expect
> from scaling of SVG files on border-image and background-image?

SVG cannot replace multiple backgrounds. SVG is scalable, but you can 
only scale the whole image. You cannot say, e.g., that you want a shape 
on the left that is 1em wide and another on the right that takes up the 
rest of the space. For that you need two separate SVG images(*) and 
information external to SVG, such as our 'border-image-slice' property.

I certainly don't want CSS to do things that SVG already does, because 
that would be both confusing and wasteful of resources. But SVG cannot 
do everything. And there is also a balance to be found between on the 
one hand dependence on SVG, complexity of CSS and optimal use of 
resources, and on the other hand convenience. E.g., Tab's recent 
suggestion of auto-shrinking menu entries is perfectly possible with 
SVG, but maybe in the balance it turns out to be easier with CSS. In 
such a case some redundancy is acceptable.

In the case of SVG for the border image, consider that you draw the SVG 
nine times at scales that are appropriate for the nine border parts, 
but each time you clip out a different part of the result. Those nine 
clipped images are the nine border image parts. In other words, each of 
the nine images is scaled individually and the quality is optimal. It 
is certainly not the case that you render the SVG once into a bitmap 
and then slice and scale the bitmap. That would look ugly and remove 
all the advantage of having a scalable format.

In summary, SVG doesn't offer any new functionality compared to PNG (or 
at least not anything that is significant for backgrounds or borders), 
but it is desirable because in many cases it offers better image 
quality and smaller files.


(*) The different SVG images can also be stored in a single SVG file, if 
you want.



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
Received on Thursday, 8 October 2009 15:28:05 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:21 GMT