- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 24 Jan 2012 07:44:40 -0800
- To: fantasai <fantasai.lists@inkedblade.net>
- Cc: www-style@w3.org
On Mon, Jan 23, 2012 at 11:33 PM, fantasai <fantasai.lists@inkedblade.net> wrote: > On 01/23/2012 11:17 AM, Tab Atkins Jr. wrote: >> >> >> 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. > > > How is it non-conforming? Where does calc() say it computes to a <length>? "A math expression has a resolved type, which is one of ‘<length>’, ‘<frequency>’, ‘<angle>’, ‘<time>’, or ‘<number>’. [...] If percentages are accepted in the context in which the expression is placed, a PERCENTAGE token has the type of the value that percentages are relative to; otherwise, a math expression containing percentages is invalid." >> 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. > > We should put this in as an example, to make sure nobody else gets it > wrong. I've also created a wiki page for it at <http://wiki.csswg.org/spec/calc-and-percentages>. ~TJ
Received on Tuesday, 24 January 2012 15:45:33 UTC