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


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

Received on Tuesday, 24 January 2012 21:08:49 UTC