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: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 24 Jan 2012 11:24:56 -0800
Message-ID: <CAAWBYDAAn5NsaYC3-y4ZeSL98B6BnVqxBt_zuoi3ZL_pVuaYDA@mail.gmail.com>
To: Brian Manthos <brianman@microsoft.com>
Cc: Sylvain Galineau <sylvaing@microsoft.com>, "L. David Baron" <dbaron@dbaron.org>, www-style list <www-style@w3.org>, fantasai <fantasai@inkedblade.net>
On Tue, Jan 24, 2012 at 11:03 AM, Brian Manthos <brianman@microsoft.com> wrote:
> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
>> On Tue, Jan 24, 2012 at 10:56 AM, Brian Manthos <brianman@microsoft.com> wrote:
>>> Tab:
>>>> <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.
>>> Incorrect.
>>> The background-position property is the only place.
>>> The <position> token isn't the problem.
>> Nope, 'object-position' has the same problem.
>> Most other places that use <position> don't show the problem because,
>> as you pointed out previously, the "subject" being positioned is 0x0
>> anyway, so percentages go back to acting the same as lengths.
> Ah, object-position isn't on my radar yet.
> I would argue that it was a mistake infecting object-position with the same virus that background-position has.

I think that background-position's behavior is useful and intuitive,
so I disagree here.

On Tue, Jan 24, 2012 at 11:03 AM, Brian Manthos <brianman@microsoft.com> wrote:
> Tab:
>>> The fact that "background-position: 10%;" and "background-position: calc(10%);"
>>> can result in differ renderings is perhaps unfortunate, but required by the specs as I read them.
>> Yes, it's currently required by the specs.  I've stated this several times.
> You might be saying that.  My interpretation of David's comments is that he was saying otherwise.

Yes, David's interpretation of the current calc() spec is wrong.

> Tab:
>> This is why I'm proposing to *change* the specs here, to match
>> what Gecko currently does.
> Ok, well I think you're both wrong.  It's the wrong direction for CSS to fundamentally change (in this case add functionality to) the behavior of one property by doing parlor tricks with calc in a different module.
> See my commentary regarding <complex-anchor> for a better way to achieve what you want.

Your proposal for <complex-anchor> appears to roughly the same as what
I'm suggesting, except that it additionally allows a bare
"background-position: 50% + 5px;", and it still makes
"background-position: 50%" and "background-position: calc(50%)"
resolve to different values (I think).  The former doesn't seem
necessary, and the latter is still unacceptable to me.

Received on Tuesday, 24 January 2012 19:26:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:10 UTC