- From: Lea Verou <leaverou@gmail.com>
- Date: Mon, 21 Feb 2011 19:03:58 +0100
- To: www-style@w3.org
- Message-ID: <4D62A90E.40500@gmail.com>
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 discarded. 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 before. 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