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

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

In your opinion.  How do you know that's what me or other authors are asking for?  As should be clear from this thread, I don't think most authors are asking for that at all.

As you state below, percentages are treated differently than length in background-position (for better or worse).  You're then making the leap that percentages should be primary and non-percentages should be secondary.  That's quite a leap, and I think it's probably often an incorrect leap w/r/t author intent.  IMO, author intent for calc is NOT to exploit some undocumented behavior of calc to produce an unusual position; rather, I think the intent is just to leverage calc to produce the desired offset for the upper-left of the image in a way that reacts to the size of the box.


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

No, it's not.  Neither easy to understand nor what I'd expect.


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

Right, so background-position is a complicated beast and for historical reasons we can't "fix it".

So the solution is to make it more complicated by inserting some voodoo in the Values spec buried in the rules for Calc()?  That seems incredibly wrong-headed to me.


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

Completely disagree.  If you want to add new functionality to background-position, then add it to background-position.  THEN make changes to Calc to align with it.


The following approach is significantly better:
1. Backgrounds: Introduce <complex-anchor>
 <complex-anchor> = <percentage> [+ | -] <length>
2. Backgrounds: Introduce 4th (and maybe 5th) clause(s) to <bg-position> that show when <complex-anchor> can be used.  Note that it's probably desirable to only support this in background-position not anywhere else that <position> is now being used.
3. Backgrounds: Define how <complex-anchor> behaves when used within a background-position value
4. Values: Describe how "calc(<complex-anchor>)" resolves to "<complex-anchor>" when found within background-position values

Result:  Backgrounds module remains the definitive authority on how background-position behaves and there is no ambiguity.


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

Calc doing this produces a background-position value format that is incompatible with the Backgrounds module, and thus broken.

Received on Tuesday, 24 January 2012 16:47:53 UTC