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

On Mon, Jan 23, 2012 at 12:00 PM, Brian Manthos <brianman@microsoft.com> wrote:
> Tab:
>> Both.  David is correct that the computed value of bg-position
>> maintains percentages without converting them to lengths.  It is also
>
> I wasn't suggesting that it they do.  I was suggesting that calc's resolve to a single "value (+ unit)" when computed.  Perhaps I'm wrong on that?

You are wrong.  calc() resolves as soon as it can, which can be
anywhere from parse time to used-value time.  If percentages are
calculated based on layout information, a calc() expression using
percentages obviously can't be resolved until used-value time.

>> true that, given the current state of the calc() spec,
>> "background-position: 75%;" and "background-position: calc(75%);"
>> produce two very different positions.
>
> We agree on this point.  But I don’t think the proposed solution makes it better.  I think it makes the problem worse.

Nah, the (implicit) proposed solution patches calc() to work in the
intuitive way for <position>, so <percentage>s and <length>s are
tracked separately in calc() and then applied as two steps.


> The root issue, IMO, is the difference between these two DIVs:
>
> <html>
> <meta http-equiv="X-UA-Compatible" content="IE=10" />
> <style>
>        Div { width: 200px; height: 400px; background-image: url(http://www.w3.org/Icons/w3c_home); background-color: gray; background-repeat: no-repeat; }
>        div:nth-child(1) { background-position: 25% 25%; }
>        div:nth-child(2) { background-position: 50px 100px; }
> </style>
> <div>
> </div>
> <div>
> </div>
> </html>
>
> This is, arguably, a fundamental issue with how background-position is treated rather than the <position> grammar itself.

Yes, that's the issue.  However, that behavior is intuitive and
useful.  It just doesn't work well with the current definition of
calc().

~TJ

Received on Monday, 23 January 2012 21:00:07 UTC