[css3-background] background-shorthand and its background-clip side-effect

During the recent background shorthand slash syntax discussion [1], Brad said:

	"If I were to choose between allowing a slash to disambiguate or throwing away the capability to include all background properties in the background shorthand...[snip]"

The following relates to "the capability to include all background properties in the background shorthand ".

1. The background shorthand does not include background-clip

The background-clip property is not included in the background shorthand; but it is reset when the latter's background-origin component is set to certain values. Specifically [2]:

	#  If 'background-origin' is present and its value matches a possible value for 'background-clip' then it also sets 'background-clip' to that value.

(Editorial: shouldn't it be 'bg-origin' ?) 

Thus, given this rule:

#test {
	background: border-box url('./foo.png');
	background-clip: padding-box;
}

...if I retrieve #test's background property value through the DOM and set it back as "border-box url('./bar.png')", then background-clip is no longer padding-box but border-box.
The same would happen with a straight round-trip i.e. getting #test's background and setting it back unchanged will effectively overwrite the specified background-clip value. 

Note that this scenario differs from what happens with other shorthands e.g. while round-tripping the border value below through the OM will make the border black :

#test2 {
	border: 1px solid black;
	border-color: blue;
}

...the author can fix his rule to:

#test2 {
	border: 1px solid blue;
}

He does not have that option with background-clip and is thus forced to either update two properties when origin and clip should be different,  or keep background-origin out of the shorthand.

2. background-clip/background-origin: discontinuities between shorthand and longhand

a. If you set the background-origin through the shorthand then the clip box follows the specified origin box, per #1. This does not, however, happen when you use the background-origin property itself. As authors and authoring tools expand and collapse shorthands and expect the same results, being unable to go from shorthand to the equivalent longhand without also explicitly setting background-clip to the value matching background-origin may result in bugs. 

b. The shorthand allows authors and tools to implicitly force the clip box to follow the origin box. They cannot specify this behavior in longhand without manually updating both properties.

c. The shorthand does not affect background-clip when the origin is set to content-box as this is not a valid value for background-clip. Given that clip follows origin in the border-box and padding-box case, the result may also surprise authors.

3. 'Missing' background-clip value

The sole reason for the 'if its value matches a possible value for 'background-clip'...' clause seems to be that the latter does not support content-box. It was removed because we couldn't think of a good use for it [3]. Whether that's a good-enough reason to remove the capability (and require authors to remember that background-clip can't do content-box but background-origin can) is debatable but fwiw, it seems pretty useful for testing. For authoring, being able to fill the padding area with a  partly transparent repeating background pattern while using a separate opaque background image for the content does not seem that weird a scenario. Is it ?

4. Ideally ?

background-clip's initial value would be 'auto', meaning 'The background painting area is set to match the box selected by the background-position'
background-clip would also support content-box as a value.

This would: 
- Preserve origin/clip synching by default but allow us to be hands-off as soon as the author specifies background-clip explicitly;
- Eliminate inconsistencies whereby setting background-origin through the shorthand updates background-clip but setting background-origin does not have the same effect.
- Eliminate the missing value discontinuity.

6. But there is a hitch...

The current initial values for the properties are:

background-origin: padding-box;
background-clip: border-box;

This is necessary for backward compatibility since, by default, backgrounds - color and image - clip to the border box and background-repeat defaults to repeat. 

However, it must be noted that as specified, the CSS3 background-shorthand does break the default relationship as soon as the background-origin component is explicitly set, including to padding-box. 

7. Conclusion

Finding a way to include background-clip in the shorthand would likely simplify the overall origin/clip model as it currently stands and reduce both author confusion and the risk of implementation bugs around shorthand/longhand discontinuities. The shorthand could still force the clipping box to match the origin box when the latter is specified but the former is not, as it currently does. 

Supporting a background-clip 'auto' value to allow authors to match the shorthand's behavior in longhand, as well as supporting content-box clipping, may also help make the property set coherent.
 
At this point, I think I am reasonably comfortable keeping all this in my head. I'm not so sure about demanding the same from all current and future authors. Thoughts ?

S.

[1] http://lists.w3.org/Archives/Public/www-style/2010Feb/0201.html
[2] http://dev.w3.org/csswg/css3-background/#background
[3] http://lists.w3.org/Archives/Public/www-style/2009Jan/0432.html

Received on Wednesday, 3 March 2010 02:13:01 UTC