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

On Jan 24, 2012, at 1:08 PM, Sylvain Galineau <sylvaing@microsoft.com> wrote:

> 
> [Tab Atkins Jr.:]
>> 
>> On Tue, Jan 24, 2012 at 11:06 AM, Sylvain Galineau
>> <sylvaing@microsoft.com> wrote:
>>> [Tab Atkins Jr.:]
>>>> 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.
>>>> 
>>> And it's all *so* intuitive ! :)
>>> 
>>> Joking aside, am I reading correctly that in some cases the <position>
>>> value type resolves differently than in others? I'll assume that's
>>> both unfortunate and unavoidable and, hopefully, not too surprising in
>>> most cases. A list of those properties categorized by how they resolve
>>> it would be interesting. Seems like fodder for a blog post, at least.
>> 
>> No, <position> resolves the same everywhere.  The problem that it has with
>> calc(), though, only shows itself in some contexts.
>> 
>> Could you please answer the questions I posed, or at least tell me whether
>> the answers I think you'd give (based on your previous emails) are
>> correct?  Brian has made his answers clear.
> 
> I don't disagree with you (not yet, at any rate...) so there is no point in
> pursuing that arguing. Again, it's not about convincing *me* of
> the way you think it should work, it's about convincing me that someone who's 
> never used calc() in background-position before will get it right i.e. what I 
> think of as being intuitive. It seemed much more of a 'this bit is intuitive 
> once you're already familiar with the feature' to me.

That is where it is most important to be intuitive. Trying to "fix" background-position with calc() to be more intuitive than background-position without calc() just makes learning both harder because of the inconsistency. 

> In that respect, I support
> being consistent though I'm worried about changing calc() to make background-position
> consistent having side-effects elsewhere calc() can be used. Might be an unwarranted
> fear but I'd rather not change it again. 

Another option would be to force calc() to resolve to either a percentage or a length based on which unit is mentioned first in the expression. So for instance, if the background is 200px square, and you have this:

background-position: calc(50% + 2px);

then it would resolve to:

background-position: 51%; /* which is 102px */

But if you had this:

background-position: calc(2px + 50%);

then it would resolve to this: 

background-position: 102px;

Hmm. Same end result, but different computed value? How'd that happen? It seems fairly easy to understand this way, even of I don't claim anything about intuitiveness.

Received on Friday, 27 January 2012 04:08:50 UTC