Re: It's time for contextual positioning

as per our missunderstanding of "off the list" intentions: It was not my 
intention to talk off the list. funny total missunderstanding :)

Then: I'm sending this as a "replay" as I'm not quite sure if the list 
will retain thread if mail for forwarded instead. so my replay below is 
actually quoted.


W dniu 17.06.2014 23:08, Rafał Pietrak pisze:
> Sory for the delay - I was offline for some time; yet, I'd like to dig 
> this bit little  further.
>
> (I've notice you've taken this reply off the list, so let's continue 
> this way).
>
> W dniu 13.06.2014 18:21, Tab Atkins Jr. pisze:
>> On Fri, Jun 13, 2014 at 2:28 AM, Rafał Pietrak <rafal@ztk-rp.eu> wrote:
>>> W dniu 12.06.2014 22:43, Tab Atkins Jr. pisze:
> [-------------------]
>>>> to import the position of another element and using it directly loses
>>>> this.
>>> I'm not exactly sure if I get it.
>> Sorry, this wasn't "your" use-case, it was Simon's, at the beginning
>> of the thread.
>
> I sort of assumed that. But still, wasn't able to figure out the case 
> anyway. Yet, your comments below do explain it sufficiently.
>
> So, to the point:
>
> [-----------------]
>> I mean what the thread-starter wanted, which is a context menu - if
>> possible, they put their top-left corner where you clicked, expanding
>> to the right and down, but if there's not enough room, they'll expand
>> up or to the left instead.  Tooltips do something similar.
>>
>> Note, though, that neither of these are addressed by "position
>> something near this element", because both of those cases actually
>> position near the *mouse cursor* at whatever time they started showing
>> (upon right-clicking for context menus, upon a delayed hover for
>> tooltips).
>>
>>> Yet, in either case, I cannot figure out what exactly is lost here. 
>>> In both
>>> cases dereferrence of other (fixed, or currently hovered above) element
>>> position attribute is the thing that will position the "said tooltip".
>>> right?
>> Your suggestion would not allow tooltips or context menus to choose
>> which direction to expand in based on whether or not they'd overflow
>> the screen.
>>
>
> Yes.
>
> But I don't think it should.
>
> This use case is "positioning relative to position where right-click 
> happened", but not in ordynary case, only in case when it wouldn't fit 
> inside current viewport clipping if rendered "here" ... and have to be 
> repositioned. This isn't anything like currently available 
> floats-flexes-etc "repositioning" in css. So, I was wrong: this isn't 
> just the case of "take a position of another element".
>
> Now I think, that this use case which could be spoken out as: "here is 
> a list of other elements, avid covering them in such order/preference".
>
> In consequence, my conclusion here would be:
> 1. position referring to other element position is usefull and would 
> be welcome, but only usefull in case when repositioning is not necesary.
> 2. if referring to position of "other element" is possible, then 
> referring to other attributes of other elements should be possible, 
> too. and will be wellcomed even more.
> 3. I may be wrong here, but I don't see an "avoid coverage" attribute 
> in CSS, yet the context-menu "use case" would benefit from such 
> tremendously. And from the eyars of CSS availability to web-designers 
> community, I'd say, that this could be yet another enabler for 
> currently unexpected usage.
>
> One thing is to "display:block" a context menu, the other is to 
> "reposition it", when it doesn't fit. IMHO those two should be made in 
> CSS explicitly distinct, and the better if the later is only hinted to 
> the brawser (as opposed to "pixel-perfect" specifying by page designer).
>
> -R

Received on Wednesday, 18 June 2014 07:45:12 UTC