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

On Mar 2, 2010, at 6:12 PM, Sylvain Galineau wrote:

> 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.
> [...]
> 
> 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 [...]
> 
> 4. Ideally ?

I can see these points. The way I'd like to see them addressed is the same as what I was arguing for with the slash for background size. Specifically, I'd like to see the following:

• A single slash can be added once ANYWHERE in a bg-layer (or final-bg-layer) of 'background', outside of the shorthand's component values (that is, between or outside those sub-values of the shorthand).

• If 1-2 lengths or percentages together are found anywhere to the RIGHT of a slash in the bg-layer (or final-bg-layer), then it represents 'background-size'. If it is anywhere to the LEFT of the slash in the layer or in a layer with no slash, then it represents 'background-position'. This makes it easy to tell which sub-property it refers to, based on its lateral relationship to (to that easy to spot and discern, full-cap-height, simple-straight-line-that creates-corners-of-white-space-around-it dividing mark,) the slash.

• If either 'padding-box', 'border-box', or 'content-box' is found anywhere to the RIGHT of a slash in the bg-layer (or final-bg-layer), then it represents 'background-clip'. If one of those values is ALSO found anywhere to the LEFT of the slash in the layer, then that one represents 'background-origin'. If one of those values is ONLY found to the LEFT of the slash in the layer or in a layer with no slash, then it represents both 'background-clip' AND 'background-origin'. This makes it easy to tell which sub-property the keywords refer to, based on their lateral relationship to the slash, and also allow the current behavior of setting both properties with one value.

Thus, we would have this change:

Value:	[ <bg-layer> , ]* <final-bg-layer>

Where
	<bg-layer> = <bg-origin> || <bg-image> || <bg-position> || / || <bg-size> || <repeat-style> || <attachment> || <bg-clip> 
and 
	< final-bg-layer> = <bg-origin> || <bg-image> || <bg-position> || / || <bg-size> || <repeat-style> || <attachment> || <bg-clip>  || <'background-color'>

and where ‘<bg-size>’ or '<bg-clip>' can only occur somewhere after ‘/ ’ (and only when '/' is present), and '<bg-position>' or '<bg-origin>' cannot occur before '/'.

I don't really care that this allows a slash at the beginning or end. It only looks funny if you aren't used to it (like anything else does too, before you get used to it), and I don't see any reasonable way to explain to an author why the shorthand should cease to work in those particular configurations but not others. It's simple enough and easy to read, without further restrictions. The author can put the slash wherever it's convenient, or leave it out, but values are only interpreted as ‘<bg-size>’ or '<bg-clip>' if they are to the right of a slash somewhere in that layer. Easy-peasy to learn, remember, read, and write.

On Mar 3, 2010, at 12:03 PM, Sylvain Galineau wrote:

> Pardon my missing the obvious, but I do not understand how and why 
> we can assert content-box clipping is not useful. I have no argument 
> with the need for padding around content. But how does that relate 
> to where I want my background to clip ? If I have padding and I've 
> also set my background image to originate at the top left of the 
> content box, why would I not want even the option of also clipping 
> that background to the content box ? Why is the ability to automatically 
> clip to the origin box an obviously smart default to have for the border 
> and padding boxes but not for the content box ?

The more I think of this, the more I think Sylvain is right on this. We can't anticipate every background-image that might be used, but I could imagine light rules or grids behind lettering that did not extend into the padding area, and almost anything behind non-text that might properly or reasonably be clipped to the content-box. I see no reason to prevent that. It also does also make it easier to learn and remember if the values are the same for both 'background-clip' and 'background-origin'. Is there any good reason to have this restriction against 'background-clip: content-box', other than our lack of imagination over how it will be used? I don't imagine it would be a burden to implement if the other values are already being implemented.