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

I'm not clear why you duplicated the quote, so trimmed the duplicate.

As it stands today, calc() as described in Values says you can do this...

 Some-property: <before-stuff> calc(10% + 5px) <after-stuff>;

... as long as Some-property has a grammar that allows ...

 <before-stuff> <length> <after-stuff>
 <before-stuff> <frequency> <after-stuff>
 <before-stuff> <angle> <after-stuff>
 <before-stuff> <time> <after-stuff>
 <before-stuff> <number> <after-stuff>

... and that it should render the same as the grammar-corresponding length, frequency, angle, time, or number resolved from that calc expression.

Nothing new is introduced with how the property value behaves.  No new layout effect.  No new rendering effect.



As I understand it, your proposal is to change calc() as follows:
(i) remove the requirement:  can only be used in place of one of listed token types
(ii) remove the requirement:  must resolve to same token type as it replaced
(iii) add requirement: Backgrounds gets some new positioning/rendering effect that is not representable without using calc()


Isn't avoiding (3) part of the reason why gradient interpolation was pushed to L4 when cross-fade() moved to L4 at the July F2F?
[Unfortunately... I don't see it fully captured in the minutes
http://lists.w3.org/Archives/Public/www-style/2011Aug/0072.html ]


Am I really the only one on this forum that has a problem with this proposal?   Wow.


My proposal avoids all of i, ii, and iii by formally adopting David's rendering capabilities properly in Backgrounds and then simply adding one more token type to supported list in requirements from i and ii.


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

On Tue, Jan 24, 2012 at 11:30 AM, Brian Manthos <brianman@microsoft.com> wrote:
> Tab:
>> 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
>
> My proposal doesn't say that.  That's one incarnation you *could* specify in the (new) 4th and 5th clauses.
>
> Some simple variations could be...
>        Background-position: complex-anchor(50% + 5px);
>        Background-position: (50% + 5px);
>
>
> Brian:
>> The following approach is significantly better:
>> 1. Backgrounds: Introduce <complex-anchor>
>>       <complex-anchor> = <percentage> [+ | -] <length>
>> 2. Backgrounds: Introduce 4th (and maybe 5th) clause(s) to <bg-position> that show when <complex-anchor>
>> can be used.  Note that it's probably desirable to only > support this in background-position not anywhere else
>> that <position> is now being used.
>> 3. Backgrounds: Define how <complex-anchor> behaves when used within a background-position value
>> 4. Values: Describe how "calc(<complex-anchor>)" resolves to "<complex-anchor>" when found within
>> background-position values
>> Result:  Backgrounds module remains the definitive authority on how background-position behaves and there is no ambiguity.
>
> Tab:
>> "background-position: 50%" and "background-position: calc(50%)"
>> resolve to different values (I think).
>
> If you only did steps 1-3, yes.  If you also do step 4, no.

...

My proposal is, more or less, to do only steps 3 and 4.  The rest
seems unnecessary.

~TJ

Received on Tuesday, 24 January 2012 19:58:45 UTC