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


[Tab Atkins Jr.:]
> 
> On Tue, Jan 24, 2012 at 12:29 AM, Sylvain Galineau
> <sylvaing@microsoft.com> wrote:
> > [Tab Atkins Jr.:]
> >> On Mon, Jan 23, 2012 at 9:34 PM, Sylvain Galineau
> >> <sylvaing@microsoft.com>
> >> wrote:
> >> > I am referring to the pattern in Brian’s email. I think many folks
> >> > will
> >> expect an expression like calc(100% -5px) to resolve at compute time
> >> in background-position, just like it would when in width.
> >>
> >> Did you mean something else?  Percentages do *not* resolve at
> >> compute-time in either background-position or width.  They can't -
> >> they rely on layout info.
> >
> > That's simply not always true. If your containing block has a fixed
> > width then width:50% will compute to half that width. (So will
> calc(50%), by your own definition).
> 
> Yes, of course.  You can't *always* do that, though, so the value as a
> whole is defined to resolve at used-value time.  Look, here's the Computed
> Value line from CSS 2.1:
> 
> Computed value:   the percentage or 'auto' as specified or the absolute
> length
> 
> Percentages are "as specified" in the computed value.  They're not
> resolved into a length.  So a calc() expression containing a percentage
> must *also* remain as specified at computed-value time.

Thank you, Captain Obvious! No, really, even I know that...:)

Again, I am referring to Brian's example which uses a fixed width 
and height. In that case, getComputedStyle() on a width:50% child 
will resolve to a 100px length across browsers. Likewise, 
width:calc(50% + 5px) can also be computed. Same for top, right, 
bottom, left... Thus Brian's expectation of what the exact same expression 
would compute to in the background-position case is imo consistent i.e. 
195px is the response I would most expect to hear from a random population
asked what the horizontal offset would be in this case. 

If that same expression, applied in the same horizontal dimension, yields 
something like 95px instead then I'm reasonably confident 'intuitive' is 
not going to be the first word that comes to mind. 

> 
> 
> > I also don’t know anyone who has any use for writing calc(50%) instead
> > of 50% so it may not be so obvious to people that the two are meant to
> > be equivalent. (Though I agree they should be)
> 
> It appears you are being inconsistent.  Let me quote the example we're
> talking about again, from Brian's earlier message:
> 
> Brian said:
> > For the example
> >       Width: 200px;
> >       Height: 400px;
> >       Background-position: calc(100% - 5px) calc(100% - 10px);
> >       Background-repeat: no-repeat;
> 
> For the rest of this email, let us assume that the background-image is
> 100px by 100px.
> 
> Now, first, let's assume that it instead had (1)"background-position:
> 100% 100%".  This would resolve at used-value time to
> "background-position: 100px 300px", placing the image snug in the lower
> right.  This is intuitive and expected, as it's been the behavior since
> 2.1.
> 
> In your quote directly above, you said that you expect "X%" and "calc(X%)"
> to be equivalent in behavior.  I assume this means that if the above
> example instead had (2)"background-position: calc(100%) calc(100%);", you
> would expect it to resolve the same as the last paragraph, to "background-
> position: 100px 300px;".  Is this correct?
> If not, please clarify your statements.
> 
> You also stated that you expect most authors to come to the same
> conclusions as Brian in this example.  Brian stated that
> (3)"background-position: calc(100% - 5px) calc(100% - 5px);" should
> resolve to "background-position: 295px 395px;", 95px away from what
> (1) resolves to.

See above.

> 
> David, on the other hand, asserts that (3) should resolve to
> "background-position: 95px 295px;", so that the resolved values are 5px
> less than what (1) resolves to.
> 
> Based on your statements so far, you believe that (2) should resolve the
> same as (1), but that adding "- 5px" to (2)'s value should *shift it by 95
> pixels in the opposite direction*.  What part of (3) causes the sudden
> jump?

We're not discussing what I believe. We're debating your claim that this is
the intuitive behavior. I'm arguing it may not be so obvious outside the folks
on this mailing list who think of this for a living. That is *very* different 
from arguing it's the wrong result.

Note that this may be the consequence of a general, existing trait of 
<position> resolution I've missed for some time. That doesn't really change 
my assessment that someone new to background-position is reasonably likely to be 
surprised in this case. This is an area where annotated examples will be worth
their weight in gold.

Received on Tuesday, 24 January 2012 17:04:35 UTC