context css-menu within a table

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

context css-menu within a table

Rafal Pietrak
Hello All,

My first shot at implementation of "a certain" context menu, which shows
up in a table when mouse ":hover" over its row (or ".click()" on that
row for mobile devices) is here: (https://jsfiddle.net/fexp/pd6ygatx/7/).

Unfortunately it is rendered differently on chromium, and on
icewheasel(mozilla) and on www-browser (all that on debian-8.1/jessie).

My goal is to have the context menu look like the imeplementation
icewheasle presents, that is "follow the mouse". But:

1. I'm not quite sure which one is actually following the semantics of
CSS specs. Pls advice is icewheasle/mozilla have it right (and thus will
stay and will proliferate to others)
2. and since only one of them can be right, the others are wrong ... so
I'd like to notify respective develoers here (google, mozilla, etc;
which I understand frequent this list) of this bug in their
implementations; although I con't actually know which one is wrong.

Regards,

Rafał Pietrak




Reply | Threaded
Open this post in threaded view
|

Re: context css-menu within a table

Sebastian Zartner-3
On 19 July 2015 at 08:06, Rafal Pietrak <[hidden email]> wrote:

> Hello All,
>
> My first shot at implementation of "a certain" context menu, which shows
> up in a table when mouse ":hover" over its row (or ".click()" on that
> row for mobile devices) is here: (https://jsfiddle.net/fexp/pd6ygatx/7/).
>
> Unfortunately it is rendered differently on chromium, and on
> icewheasel(mozilla) and on www-browser (all that on debian-8.1/jessie).
>
> My goal is to have the context menu look like the imeplementation
> icewheasle presents, that is "follow the mouse". But:
>
> 1. I'm not quite sure which one is actually following the semantics of
> CSS specs. Pls advice is icewheasle/mozilla have it right (and thus will
> stay and will proliferate to others)
> 2. and since only one of them can be right, the others are wrong ... so
> I'd like to notify respective develoers here (google, mozilla, etc;
> which I understand frequent this list) of this bug in their
> implementations; although I con't actually know which one is wrong.

Here's a simplified version of Rafał's example:

https://jsfiddle.net/g9zp6psj/1/

So it looks like Gecko considers relative positioning of table rows
while Blink and Trident don't.

Sebastian

Reply | Threaded
Open this post in threaded view
|

Re: context css-menu within a table

Tab Atkins Jr.
On Thu, Jul 23, 2015 at 6:20 AM, Sebastian Zartner
<[hidden email]> wrote:

> On 19 July 2015 at 08:06, Rafal Pietrak <[hidden email]> wrote:
>> Hello All,
>>
>> My first shot at implementation of "a certain" context menu, which shows
>> up in a table when mouse ":hover" over its row (or ".click()" on that
>> row for mobile devices) is here: (https://jsfiddle.net/fexp/pd6ygatx/7/).
>>
>> Unfortunately it is rendered differently on chromium, and on
>> icewheasel(mozilla) and on www-browser (all that on debian-8.1/jessie).
>>
>> My goal is to have the context menu look like the imeplementation
>> icewheasle presents, that is "follow the mouse". But:
>>
>> 1. I'm not quite sure which one is actually following the semantics of
>> CSS specs. Pls advice is icewheasle/mozilla have it right (and thus will
>> stay and will proliferate to others)
>> 2. and since only one of them can be right, the others are wrong ... so
>> I'd like to notify respective develoers here (google, mozilla, etc;
>> which I understand frequent this list) of this bug in their
>> implementations; although I con't actually know which one is wrong.
>
> Here's a simplified version of Rafał's example:
>
> https://jsfiddle.net/g9zp6psj/1/
>
> So it looks like Gecko considers relative positioning of table rows
> while Blink and Trident don't.

Both behaviors are allowed by CSS 2.1, unfortunately.

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: context css-menu within a table

Gérard Talbot-2
Le 2015-07-23 16:39, Tab Atkins Jr. a écrit :

> On Thu, Jul 23, 2015 at 6:20 AM, Sebastian Zartner
> <[hidden email]> wrote:
>> On 19 July 2015 at 08:06, Rafal Pietrak <[hidden email]> wrote:
>>> Hello All,
>>>
>>> My first shot at implementation of "a certain" context menu, which
>>> shows
>>> up in a table when mouse ":hover" over its row (or ".click()" on that
>>> row for mobile devices) is here:
>>> (https://jsfiddle.net/fexp/pd6ygatx/7/).
>>>
>>> Unfortunately it is rendered differently on chromium, and on
>>> icewheasel(mozilla) and on www-browser (all that on
>>> debian-8.1/jessie).
>>>
>>> My goal is to have the context menu look like the imeplementation
>>> icewheasle presents, that is "follow the mouse". But:
>>>
>>> 1. I'm not quite sure which one is actually following the semantics
>>> of
>>> CSS specs. Pls advice is icewheasle/mozilla have it right (and thus
>>> will
>>> stay and will proliferate to others)
>>> 2. and since only one of them can be right, the others are wrong ...
>>> so
>>> I'd like to notify respective develoers here (google, mozilla, etc;
>>> which I understand frequent this list) of this bug in their
>>> implementations; although I con't actually know which one is wrong.
>>
>> Here's a simplified version of Rafał's example:
>>
>> https://jsfiddle.net/g9zp6psj/1/
>>
>> So it looks like Gecko considers relative positioning of table rows
>> while Blink and Trident don't.
>
> Both behaviors are allowed by CSS 2.1, unfortunately.
>
> ~TJ

Tab,

Allowed maybe, but certainly not recommended/recommendable:

"
The effect of 'position:relative' on table-row-group,
table-header-group, table-footer-group, table-row, table-column-group,
table-column, table-cell, and table-caption elements is undefined.
"
CSS2.1, section 9.3.1 Choosing a positioning scheme: 'position' property
http://www.w3.org/TR/CSS21/visuren.html#choose-position

Earlier versions of CSS2.x were more discouraging or formally
discouraging relative positioning of sub-table elements.

I glance at Rafal Pietrak's code ( https://jsfiddle.net/fexp/pd6ygatx/7/ 
) and I am convinced there are ways to achieve his context menu with
less rules, with less declarations and with less z-index declarations.

Gérard

Reply | Threaded
Open this post in threaded view
|

Re: context css-menu within a table

Rafal Pietrak
In reply to this post by Tab Atkins Jr.


W dniu 23.07.2015 o 22:39, Tab Atkins Jr. pisze:
> On Thu, Jul 23, 2015 at 6:20 AM, Sebastian Zartner
> <[hidden email]> wrote:
>> On 19 July 2015 at 08:06, Rafal Pietrak <[hidden email]> wrote:
>>> Hello All,
[----------------------]

>>> 2. and since only one of them can be right, the others are wrong ... so
>>> I'd like to notify respective develoers here (google, mozilla, etc;
>>> which I understand frequent this list) of this bug in their
>>> implementations; although I con't actually know which one is wrong.
>>
>> Here's a simplified version of Rafał's example:
>>
>> https://jsfiddle.net/g9zp6psj/1/
>>
>> So it looks like Gecko considers relative positioning of table rows
>> while Blink and Trident don't.
>
> Both behaviors are allowed by CSS 2.1, unfortunately.
>

Isn't it calling for specs revision, then?

(I haven't seen the actual wording of the specs, but google returned
pointers to "behavior is undefined" in that conext. What is the point in
leaving it undefined? I mean is "undefinition" serve any purpose there???)

-R




Reply | Threaded
Open this post in threaded view
|

Re: context css-menu within a table

Tab Atkins Jr.
On Thu, Jul 23, 2015 at 10:32 PM, Rafal Pietrak <[hidden email]> wrote:

> W dniu 23.07.2015 o 22:39, Tab Atkins Jr. pisze:
>> On Thu, Jul 23, 2015 at 6:20 AM, Sebastian Zartner
>> <[hidden email]> wrote:
>>> On 19 July 2015 at 08:06, Rafal Pietrak <[hidden email]> wrote:
>>>> Hello All,
> [----------------------]
>>>> 2. and since only one of them can be right, the others are wrong ... so
>>>> I'd like to notify respective develoers here (google, mozilla, etc;
>>>> which I understand frequent this list) of this bug in their
>>>> implementations; although I con't actually know which one is wrong.
>>>
>>> Here's a simplified version of Rafał's example:
>>>
>>> https://jsfiddle.net/g9zp6psj/1/
>>>
>>> So it looks like Gecko considers relative positioning of table rows
>>> while Blink and Trident don't.
>>
>> Both behaviors are allowed by CSS 2.1, unfortunately.
>>
>
> Isn't it calling for specs revision, then?
>
> (I haven't seen the actual wording of the specs, but google returned
> pointers to "behavior is undefined" in that conext. What is the point in
> leaving it undefined? I mean is "undefinition" serve any purpose there???)

A handful of things were left intentionally undefined in CSS 2.1
because browsers differed, and there wasn't a strong expectation that
they would converge their behaviors in a reasonable amount of time.
Rather than hold up finishing 2.1 indefinitely, we undefined those
behaviors, or defined more than one possible behavior that browsers
could use.

In this case, browsers still haven't converged, so ¯\_(ツ)_/¯

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: context css-menu within a table

Rafal Pietrak


W dniu 24.07.2015 o 20:13, Tab Atkins Jr. pisze:
> On Thu, Jul 23, 2015 at 10:32 PM, Rafal Pietrak <[hidden email]> wrote:
>> W dniu 23.07.2015 o 22:39, Tab Atkins Jr. pisze:
>>> On Thu, Jul 23, 2015 at 6:20 AM, Sebastian Zartner
>>> <[hidden email]> wrote:
>>>> On 19 July 2015 at 08:06, Rafal Pietrak <[hidden email]> wrote:
>>>>> Hello All,
[------------------]

>>
>> Isn't it calling for specs revision, then?
>>
>> (I haven't seen the actual wording of the specs, but google returned
>> pointers to "behavior is undefined" in that conext. What is the point in
>> leaving it undefined? I mean is "undefinition" serve any purpose there???)
>
> A handful of things were left intentionally undefined in CSS 2.1
> because browsers differed, and there wasn't a strong expectation that
> they would converge their behaviors in a reasonable amount of time.
> Rather than hold up finishing 2.1 indefinitely, we undefined those
> behaviors, or defined more than one possible behavior that browsers
> could use.
>
> In this case, browsers still haven't converged, so ¯\_(ツ)_/¯
>

Surely that makes sense.

But time pass, people get experience, and may be some parts of that
uncharted territory can get consensus now? That would be a call from
humble programmer having to cope with all those variants :(

Anyway, thank you for explanations.

-R