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: Brian Manthos <brianman@microsoft.com>
Date: Mon, 23 Jan 2012 19:28:50 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>, "L. David Baron" <dbaron@dbaron.org>
CC: www-style list <www-style@w3.org>, fantasai <fantasai@inkedblade.net>
Message-ID: <9710FCC2E88860489239BE0308AC5D170EB1912F@TK5EX14MBXC264.redmond.corp.microsoft.com>
I find this proposed behavior bizarre, personally.  I'm not sure I would fight against it yet (because I need to consider it some more), but on the surface it's very counterintuitive to me.

For the example
	Width: 200px;
	Height: 400px;
	Background-position: calc(100% - 5px) calc(100% - 10px);
	Background-repeat: no-repeat;

As I understand it, the computed value for background-position is something like
	195px 390px
with the upper left of the image at
	(195px, 390px) from the upper-left origin
as the Background specs currently stand.

With the proposal below, a bunch of new confusing stuff pops out in both computed value and rendering.  Good luck with getting authors to have good results when inheriting values under such conditions.
	


-----Original Message-----
From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] 
Sent: Monday, January 23, 2012 11:18 AM
To: L. David Baron
Cc: www-style list; fantasai
Subject: Re: [css3-2d-transforms][css3-images] <position> grammar is duplicated or points to the wrong spec

...
On Mon, Jan 23, 2012 at 9:20 AM, L. David Baron <dbaron@dbaron.org> wrote:
> What's not obtainable using calc()?  Gecko's implementation of
> calc(10% + 5px) for background-position positions the 10% point of
> the image 5px to the left of the 10% point in the container.

Note that this is non-conforming with the current calc() spec, as
calc() will simply return a <length>, which is then interpreted as a
simple offset from the side.

Gecko's behavior is the *right* one, of course.  We just need to spec
that using calc() in a <position> has special behavior.  I've been
nitpicking other new properties to ensure that they don't run into
similar problems.

Fantasai - this makes me think more strongly that we should go ahead
and spec <position> in Values 3.  Thoughts?

~TJ


Received on Monday, 23 January 2012 19:29:33 GMT

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