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

On Tue, Jan 24, 2012 at 9:03 AM, Sylvain Galineau
<sylvaing@microsoft.com> wrote:
> [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.

getComputedStyle() does *not* return the computed style for width.  It
returns the used value.  (Damn legacy APIs!)


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

'width' doesn't have the consistency problem.  There's no issue with
width.  <position> is the *only* place in CSS where this problem
(percentages treated differently than equivalent lengths) crops up, so
attempting to reason from 'width' isn't very useful.


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

It's important to know what you believe, so I know what I'm arguing
with you about.  You didn't answer whether or not what I stated above
was a correct description of what you believe.  I literally can't
discuss this further with you until I know your answers to the above.

I'll restate the questions more directly.  Given the above example,
what do you believe the following should resolve to?

(1) background-position: 100% 100%;
    (a) background-position: 100px 300px;
    (b) background-position: 200px 400px;
(2) background-position: calc(100%) calc(100%);
    (a) background-position: 100px 300px;
    (b) background-position: 200px 400px;
(3) background-position: calc(100% - 5px) calc(100% - 5px);
    (a) background-position: 95px 295px;
    (b) background-position: 195px 395px;

Given your previous emails, it appears your answers are (1a), (2a),
and (3b).  Is this correct or incorrect?

~TJ

Received on Tuesday, 24 January 2012 18:54:50 UTC