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

> From: fantasai [mailto:fantasai.lists@inkedblade.net]


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


My comment was strictly limited to dynamic style attribute updates since they're
a very common pattern.


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


It's true that you cannot but I think this only proves that my choice of 
border was inadequate as the latter has components that are top-right-bottom-left 
shorthands themselves. This is not an  issue for background origin/clip and thus
does not justify requiring authors and script to keep track of more property states 
than necessary.


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


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 ?


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

So we're really, really clear that I don't get it:) : I do not understand 
why overhang scenarios make content-box clipping useless in scenarios where 
overhang is not an issue. My content box may not even contain text. It might
be an array of thumbnail images with margin between them. 


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


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


Sigh. You and me both...


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

I agree. I agree so strongly I think it should be true for content-box too !

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

And I'm cool with that. In fact, I'd like authors to be able to specify
this in longhand as well using background-clip:auto; 


 
> For background-clip: content-box, I think the authoring use cases are
> mostly
> theoretical. 

Right. I get you think that. And by now you get that I don't get it :)


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

Sorry: which shorthand value is made 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.

So you're implicitly saying authors *expect* this mismatch. I'll accept
that for the sake of argument. Yet this does still make this shorthand 
more complicated to expand/collapse than others, for either tools or humans. 
One has to remember that background-origin needsa matching background-clip value 
in longhand, except for content-box. It'll be easy to get it wrong, I think. 

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

I'm quite happy with origin controlling clip when the latter is not specified. But I'd 
Still like authors to be able to specify it independently when needed in either shorthand 
and longhand. I think that makes the feature more coherent and consistent with existing shorthands.

Received on Wednesday, 3 March 2010 20:04:07 UTC