- From: Lea Verou <lea@w3.org>
- Date: Fri, 12 Oct 2012 23:44:31 +0300
- To: François REMY <fremycompany_pub@yahoo.fr>
- Cc: "Jussi Kalliokoski" <jussi.kalliokoski@gmail.com>, <www-style@w3.org>
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. 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 (unless the element is nested deeply, in which case it's still possible, but harder). Also, this is only a problem with static/relative positions, not with fixed or absolute (unless the parent is positioned). Of course, it doesn't solve every possible use case, but it solves a hella lot more than position: pointer. On Oct 12, 2012, at 23:35, François REMY wrote: > Creating a unit which would only be valid for certain properties and in certain cases doesn't seem a very good idea to me. It would be impossible to get a radial gradient's center to follow the mouse on an element even if we had a 'mouse' unit because that unit would have to be relative to the element itself (and if the position of the element depends itself on the mouse position, we get an unresolvable problem). For those kinds of problems, I believe scripting will stay the best solution because it can always extend to something more complex or taking more parameters in account; while CSS doesn't. But I can be wrong, and this is just a point of view. > > "Position: pointer" solves the most important use case (mouse-following tooltips / cursor additions). >
Received on Friday, 12 October 2012 20:44:40 UTC