W3C home > Mailing lists > Public > www-style@w3.org > February 2011

[css4-background] Change the way the # of background layers is calculated

From: Lea Verou <leaverou@gmail.com>
Date: Mon, 21 Feb 2011 19:03:58 +0100
Message-ID: <4D62A90E.40500@gmail.com>
To: www-style@w3.org
I've recently came across many cases where I had to use the same image 
twice with different background positions or sizes, mostly when making 
patterns like e.g. checkerboard or polka dot. Especially given that in 
my case the tiles were actually CSS gradients, it felt really redundant 
to have to declare it twice and have to make twice as many edits to 
change a color.

So, I researched what the rationale was behind making only the 
background-image property able to set the number of background layers. I 
found the relevant issue in the tracker [1] which links to the 
discussion and the related Minutes & Resolutions. After also asking 
Elika about this, it seems that the reasoning was the old way was too 
confusing for authors in cases like:

     background: url(a.png) top left, url(b.png) bottom right;
     background-image: url(a.png);

which most authors would expect to produce just one background layer 
instead of 2 copies of a.png.

I understand the reasoning for that particular example being confusing 
to authors. However, I think one can find confusing examples on both 
sides. The whole concept of background-image having a different effect 
to the number of bg layers than the rest of the background properties is 
a bit confusing. For example, when I came across this problem, I 
happened to be at the same office with 2 quite well known CSS experts in 
the industry, so I asked them if they can think of a way to just declare 
the image once. The spontaneous first thought of both was that declaring 
2 background positions would produce the effect I wanted. So, it might 
actually be more confusing to some authors that the extra values are 

Besides, Webkit still calculates the number of background layers the 
"old" way, even on the latest nightly, so it would be safe to assume 
that the issue is still pending? Presto and Gecko comply with the spec 
and I didn't test what IE9 does.

On the other hand, a big disadvantage of my suggestion is that the only 
way to *reduce* the number of background layers is to redeclare *all* 
background properties, which is quite inconvenient. Also, Backgrounds & 
Borders 3 is in CR, so it's probably too late to change that.

There has to be a better approach than both the "old" and the "new" way, 
since both have significant disadvantages.
A quick idea I had is that a new property like background-layers could 
be introduced in B&B 4 that controls which property sets the number of 
layers, or even sets it explicitly. Something like:

Name: background-layers
Value: background-image | background-repeat | background-attachment | 
background-position | background-clip | background-origin | 
background-size | <number> | max | min
Initial: background-image
Applies to: all elements
Inherited: no
Percentages: N/A
Media: visual
Computed value: for min/max the property name that specifies the 
least/most layers, otherwise as specified
(or maybe the actual layer count in all cases, not sure what would be 
more useful)

Webkit's implementation would be equal to them having background-layers: 
max; in the UA stylesheet.

I haven't given this much thought, so I apologize if it's a bad idea. 
However, I should note that it doesn't break existing compliant 
implementations and even provides the non-compliant ones a good excuse, 
it satisfies all sides and actually allows things that weren't possible 

Also, even if it's not a good idea, I hope it might inspire someone for 
a better solution.

Sorry for the long email and thanks for reading.

          [1]: http://www.w3.org/Style/CSS/Tracker/issues/74


Lea Verou
Web designer & developer, specializing in front-end development
leaverou.me <http://leaverou.me> . Twitter <http://twitter.com/LeaVerou> 
. LinkedIn <http://gr.linkedin.com/in/leaverou>
Received on Monday, 21 February 2011 18:04:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:56 UTC