- 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