W3C home > Mailing lists > Public > www-style@w3.org > January 2012

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

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Tue, 24 Jan 2012 18:58:24 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: Brian Manthos <brianman@microsoft.com>, "L. David Baron" <dbaron@dbaron.org>, www-style list <www-style@w3.org>, fantasai <fantasai@inkedblade.net>
Message-ID: <3C4041FF83E1E04A986B6DC50F0178290341B63E@TK5EX14MBXC295.redmond.corp.microsoft.com>

[Tab Atkins Jr.:]
> 
> 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!)

Damn, yes. The actual value that is returned is what matters for this
argument though i.e. 195px given (100% - 5px) in Brian's case.
> 
> 
> > 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.

Yes, the way <position> is resolved is simply the challenge here. So
1) it's not really a calc() issue
2) I can't argue making calc() in <position> inconsistent with their 
non-calc() equivalent. There'd have to be some pretty good use-cases
to allow that.


> 
> 
> >>> 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:59:11 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:48 GMT