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

On 03/02/2010 06:12 PM, Sylvain Galineau wrote:
>
>  # 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' ?)

Fixed.

> 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.

Only if you change the background declaration's position in the cascade.
If you write it back at the same point, nothing changes. If you write
it out into the 'style' attribute, then, yes, it will reset all background
properties -- either to the given value, if specified, or to the initial
value if not.

> 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.

Leaving background-origin out of the shorthand would reset both
background-origin and background-clip to their initial values.

The scenario is similar to

#test3 {
   border: 1px solid black;
   border-bottom-color: green;
}

I can't set the bottom border color differently in the 'border'
shorthand. And if I set style="border: 1px solid" the color on
all four sides will get reset to 'currentColor'.

> 2. background-clip/background-origin: discontinuities between shorthand and longhand
...
> 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 ?

I'm a little skeptical that the content box were actually a useful clipping rect
for that type of design. You usually (almost always?) want at least some amount
of padding around the contents, even if it's not the full amount of padding,
because the content box is a very tight fit around the logical contents and does
not account for e.g. kerning glyphs.

Try viewing, e.g.
   <!DOCTYPE html>
   <title>Demonstration of content-box clipping</title>
   <p style="background: orange; font-size: 4em; font-style: italic; float: left;
             font-family: serif">Just some italic serif</p>
 
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Ctitle%3EDemonstration%20of%20content-box%20clipping%3C%2Ftitle%3E%0A%3Cp%20style%3D%22background%3A%20orange%3B%20font-size%3A%204em%3B%20font-style%3A%20italic%3B%20float%3A%20left%3B%20font-family%3A%20serif%22%3EJust%20some%20italic%20serif%3C%2Fp%3E

> 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.

The idea of background-origin's shorthand setting 'background-clip' was mostly
to make it easier to specify. Conceptually, I think of the shorthand as setting
background-clip and background origin at the same time, like "margin: 1em 2em 1.5em"
sets the left and right sides to 1em at the same time.

> - 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.

How I wish the spec didn't do this. :/

> 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.

Yeah, because how often does someone want the background clipping to be
border-box when the image is aligned to the padding box? If you're
bothering to think about it, I'd say you almost always want them to match.

> 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 ?

I think that *except* for the content-box case, it's very rare for someone to
want the background-clip and background-origin to be set to different boxes
(despite this being the default behavior). This is why the shorthand sets both
at the same time.

For background-clip: content-box, I think the authoring use cases are mostly
theoretical. And having the shorthand content-box value for background-origin
set the background-clip to content-box would therefore make that shorthand
value mostly useless. This is why we removed it and had the shorthand reset
background-clip to its initial value instead of setting "background-clip:
content-box". The shorthand mismatch here is more likely to be useful: I can
imagine cases for aligning to the content box corners, likely with an outward
position offset--which would require a border or padding box clip to render,
not a content-box clip.

If setting 'background-clip' and 'background-origin' to different values in the
shorthand is important, then we can expand the shorthand to be able to set both
independently. But I still think 'border-box' and 'padding-box' alone should set
both 'background-clip' and 'background-origin'. Otherwise most people will be
constantly repeating themselves.

Anyway, those are my thoughts.

~fantasai

Received on Wednesday, 3 March 2010 03:48:57 UTC