Re: position: pointer

|  I never said it would only be valid for certain properties and certain 
cases. It would be valid everywhere a <length> is and would likely compute 
to px.

That implies that the browser should reperform the layout everytime the main 
pointer is moved, right? I know it may already have to do it in some cases, 
but those seems rather limited to me.



|  Regarding the element case, the offsets of the element are likely also 
set in CSS, so with calc() the offsets of the mouse would be relatively easy 
to calculate in most cases.

That seems to be a huge "magic constant" generator to me. You may want to 
get the mouse position relatively to the element itself (in border-box & 
content-box flavors), to its last "positioned" ancestror or even to the root 
element (absolute positionning) or relatively to the viewport (fixed 
positionning). That's already a lot of variants to a single input data. I do 
believe that calc() isn't suited for those calculations because you can't 
have functions, and it's impossible to rely on the used value of other 
properties.



|  Of course, it doesn't solve every possible use case, but it solves a 
hella lot more than position: pointer.

What botters me is that it's trying to solve a lot of use cases that are 
better solved by a script. Why do you feel that modifying the center of a 
radial gradient in function of the mouse position is a task better left to 
CSS than JS?

Received on Friday, 12 October 2012 21:03:38 UTC