Re: [css3-2d-transforms][css3-images] <position> grammar is duplicated or points to the wrong spec

On Tue, Jan 24, 2012 at 7:55 AM, Brian Manthos <brianman@microsoft.com> wrote:
> The introduction of computed-value-of-calc into the discussion (by me, I think) branched off into a deeper discussion of that entanglement.  That's not a bad thing, but I want to try to clarify another point I didn't explain earlier.
>
> L. David Baron <dbaron@dbaron.org>:
>> What's not obtainable using calc()?  Gecko's implementation of
>> calc(10% + 5px) for background-position positions the 10% point of
>> the image 5px to the left of the 10% point in the container.
>
> div {
>        background-image: url(Some200by400image.png);
>        width: 500;
>        height: 1000;
>        background-repeat: no-repeat;
> }
>
> Example A:
> background-position: 10% 10%;
>
> Example B:
> background-position: 5px 5px;
>
> Example C:
> background-position: calc(10% + 5px) calc(10% + 5px);
>
> Example D:
> background-position: horizontal(10% + 5px) vertical(10% + 5px);
>
>
> A. "the point 10% across and 10% down [of] the image is to be placed at the point 10% across and 10% down in the area"
> 1. (20, 40) in the image should be placed at (50, 100) of the div's box
> 2. (0, 0) in the image should be placed at (30, 60) of the div's box
>
> B. "Positive values represent an offset inward from the edge of the background positioning area."
> 1. (0, 0) in the image should be placed at (5, 5) of the div's box
>
> C. I think David is saying this should be rendered the same as case D if that could be expressed directly.  Please correct me if I'm misunderstanding.
>
> D. I think David is suggesting that we apply A1, A2, and then offset it by 5px.

Yes, that's what David is suggesting.


>  Why is that the "right" answer?

It's the right answer because you're asking for it to be positioned at
"10%, plus 5px", and it gives you the element positioned at 10% then
shifted to the right 5px.

This gives an example like the following an easy-to-understand result:

.foo {
  background-image: url(one.jpg), url(two.jpg);
  background-position: 10% 10%, calc(10% + 5px) calc(10% + 5px);
}

The second image is positioned 5px more to the right/bottom than the
first image (the first image is at (30,60), the second is at (35,65)).
 That's exactly what you'd expect from such an expression.  Your
interpretation, on the other hand, positions the second image at
(55,105).


>  Further, that represents a new kind of positioning treatment that is not directly supported without calc.  Is this intended that calc adds new positioning / rendering requirements to other features?  This was/is news to me and why I called it bizarre.  My understanding was that calc adds to CSS a way to provide algorithmic means to fill a length/angle/etc. field rather than expressing it directly -- NOT a way of adding new positioning/layout algorithms to properties.

'background-position' is the one and only context in CSS 2.1 (and, as
far as I know, <position> in general is the only context in all of
CSS) where percentages are treated different than an equivalent
length.  Unfortunately, we can't change that behavior, so instead we
should bend calc() into doing the "appropriate" thing here.  This is a
one-time context-switch for the value, not a change to how calc()
works in general.


> If my assessment of D is correct, then I think the evolution of calc() as proposed is extremely confusing and detrimental for CSS as a whole.  The complexity of such an endeavor from an engineering perspective would be at least as expensive as introducing a new document mode.

This seems incorrect.  In this context you track <percentage> as its
own unit, and at the end calc() returns both a <percentage> and a
<length>, which is interpreted as performing the normal behavior for
<percentage>s and then shifting by <length>.

I'm not sure whether it's easier in your plumbing to always track
<percentage> separately or to special-case it based on context, but
either way, I don't believe it's very hard.  I'll ask our engineer
implementing calc() about it, though - luckily he's in town this week,
so I don't have to wait until people wake up in Sydney.

~TJ

Received on Tuesday, 24 January 2012 16:25:29 UTC