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

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.  Why is that the "right" answer?  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.


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.

Received on Tuesday, 24 January 2012 15:57:15 UTC