Adding new property to align the panel

57 views
Skip to first unread message

ZER0

unread,
Jan 10, 2013, 8:47:45 PM1/10/13
to mozilla-la...@googlegroups.com
Rocketeers!

We're working on the Bug 732294 ('Panel constructor lacks a way to set
position of panel other than "centered"'), to adding a way to align a
panel when is not anchored to a widget.

Jono already suggested a possible API in the bug:

var panel = require("panel").Panel({
width: 300,
height: 200,
halign: "right",
valign: "top"
});

I was thinking to adding just one property instead:

var panel = require("panel").Panel({
width: 300,
height: 200,
align: "top right"
});

That is working in a similar way than `background-position` (notice that
the only values supported in our case are "top", "right", "bottom",
"left" and "center"):

https://developer.mozilla.org/samples/cssref/background-position/

What do you think? Do you have any preferences, or maybe other
suggestion about this new feature?

If you're willing to try, I have already a prototype there:

<https://github.com/ZER0/addon-sdk/tree/panel-align/732294>


Let us know!


Dave Townsend

unread,
Jan 14, 2013, 2:55:59 PM1/14/13
to mozilla-la...@googlegroups.com, ze...@mozilla.com
This still doesn't seem to let you tell the panel where to appear, looks like you can only align it within the content area. I'd expect to be able to set an x and y co-ordinate to say where it should appear and optionally also add a way to show the arrow pointing to that position.

ZER0

unread,
Jan 15, 2013, 7:14:09 AM1/15/13
to mozilla-la...@googlegroups.com
On 14/01/13 20:55 , Dave Townsend wrote:
> This still doesn't seem to let you tell the panel where to appear,
> looks like you can only align it within the content area.
It's exactly what it does. This is what the bug 732294 is for, and this
is why we can easily implement it, without any UX constraints. There was
another bug related to permit to the developer to explicitly the panel
position, and both me and Myk were against about that – and later on UX
agreed as well.
The bug is 669523, and is mentioned in the bug 732294 too.
> I'd expect to be able to set an x and y co-ordinate to say where it
> should appear and optionally also add a way to show the arrow pointing
> to that position.
It's not the same of bug 669523, but it could be against the UX
guidelines (that, still, we didn't receive yet).
Panels with arrow have a specific set of rules that determined how they
are displayed – and how the arrow is positioned – in order to be
consistent with the UI of Firefox and the user experience.
Surely we can implement those APIs internally without expose them, in
order to "fake" some behavior (e.g. passing DOM node and makes the
panel's arrow point to them), but this is a different issue.

In my opinion we can either:

1. Keep the new `align` property as is (or adding instead
`valign`/`halign`), discuss with UX about set the explicit panel's
position with arrows and see what can be done in a separate bug, and
adding a new property in case.

2. Rename `align` to `position`, discuss with UX about set the explicit
panel's position with arrows and see what can be done in a separate bug,
and if it's acceptable modify the `position` property to accept also
pixel values (as CSS does: `position: "40px 10px"`) or object
(`position: {top: 0, left: 0}`);

3. Don't have an `align` property neither a `position`; discuss with UX
about set the explicit panel's position with arrows and see what can be
done, implement several new property like:

Panel({
with: 300,
height: 200,
top: 0,
left: 0 // same for `right` and `bottom`
arrow: true
});

Notice that in this case the API will be a bit more complex to read,
where if the `arrow` value is omitted (or `false`) the positions are
related to the panel itself, otherwise to the arrow's point.

In any case, if we want to explicitly set the position of a panel, and
not just the alignment, we need to have a talk with UX before proceed,
to be sure we're not break any user experience or guidelines; and all
the values should be related to the content area, not the screen(s):
it's also the behavior we have now: a centered panel is not centered
related to the screen but to the browser's content area.

Dave Townsend

unread,
Jan 15, 2013, 11:27:48 AM1/15/13
to mozilla-la...@googlegroups.com, ze...@mozilla.com
On Tuesday, January 15, 2013 4:14:09 AM UTC-8, ZER0 wrote:
In any case, if we want to explicitly set the position of a panel, and
not just the alignment, we need to have a talk with UX before proceed,
to be sure we're not break any user experience or guidelines; and all
the values should be related to the content area, not the screen(s):
it's also the behavior we have now: a centered panel is not centered
related to the screen but to the browser's content area.

I think we want to be able to explicitly set the position of a panel and I don't know why UX would object to that and not that we centre the panel in the page already (which leaves it open to spoofing).

ZER0

unread,
Jan 15, 2013, 11:39:37 AM1/15/13
to mozilla-la...@googlegroups.com
On 15/01/13 17:27 , Dave Townsend wrote:
> I think we want to be able to explicitly set the position of a panel
> and I don't know why UX would object to that and not that we centre
> the panel in the page already (which leaves it open to spoofing).
The last time I discussed with them about bug 669523 they had specific
guidelines about positioning and displaying an anchored panel, that were
in constrast (= not consistent with current Firefox UI experience) with
the bug mentioned, that's why. The centered panel is not an "anchored" one.

Dave Townsend

unread,
Jan 18, 2013, 1:45:11 PM1/18/13
to mozilla-la...@googlegroups.com, ze...@mozilla.com
On Thursday, January 10, 2013 5:47:45 PM UTC-8, ZER0 wrote:
Rocketeers!

We're working on the Bug 732294 ('Panel constructor lacks a way to set
position of panel other than "centered"'), to adding a way to align a
panel when is not anchored to a widget.

Jono already suggested a possible API in the bug:

    var panel = require("panel").Panel({
      width: 300,
      height: 200,
      halign: "right",
      valign: "top"
    });

I was thinking to adding just one property instead:

    var panel = require("panel").Panel({
      width: 300,
      height: 200,
      align: "top right"
    });

That is working in a similar way than `background-position` (notice that
the only values supported in our case are "top", "right", "bottom",
"left" and "center"):

The API that would make sense to me looks something like this:

var panel = require("panel").Panel({
  width: 300,
  height: 200,
  x: 200,
  y: 400,
  arrow: "top left"
});


I think it's going to be very common to want to set the position when you show the panel so it might also be good to have the show method take the parameters:

panel.show(200, 400, "top left");

The arrow property says where to put an arrow. Without it there is no arrow and the panel has its top-left point at the x,y coordinate. With it the arrow points to the x,y coordinate and the string says where to show the arrow. The first word is which side of the panel the arrow will appear on (top, bottom, left, right). The second word says which side of that edge the arrow should be displayed (top, bottom, left, right but only two are valid depending on what the first words was).

This all maps pretty directly to the XUL panel API so should be relatively straightforward to implement too, assuming UX don't have concerns about this.

ZER0

unread,
Jan 21, 2013, 5:33:40 AM1/21/13
to mozilla-la...@googlegroups.com
On 18/01/13 19:45 , Dave Townsend wrote:

> The API that would make sense to me looks something like this:
>
> var panel = require("panel").Panel({
> width: 300,
> height: 200,
> x: 200,
> y: 400,
> arrow: "top left"
> });

I can see a couple of major issues with this approach:

1. It doesn't cover the scenario of the bug we're fixing (bug 732294);
basically you can't align the panel, just position it (what if I want to
position the panel at the top right corner?).

2. The position of the arrow has specific guidelines how should be
displayed, in according to UX; also depends by the panel's size,
position of the browser and the screen space available, keep a specific
arrow's position could be not possible (see also comments in bug
669523); because the panel will be flipped or moved.

For the first point, I will suggest to use one of the alternative API I
already suggested in the previous post:

var panel = require("panel").Panel({
width: 300,
height: 200,
top: 200,
left: 400 // and right and bottom too
});

In that case, if I want to align on the top right, I have just to write:

var panel = require("panel").Panel({
width: 300,
height: 200,
top: 0,
right: 0
});

This is also mimic the CSS syntax for position an absolute element, so
it's good for web developers.

To center a panel, we could set a string with percent:

var panel = require("panel").Panel({
width: 300,
height: 200,
top: "50%",
right: 0
});

Or either implement floating values:

var panel = require("panel").Panel({
width: 300,
height: 200,
top: 0.5,
right: 0
});

But it will be more confusing IMVHO.

For the second point, even if the UX will be fine with that, we still
can't assure that the arrow will be placed where specified.
So or we either don't do that, leaving the panel's arrow displayed in
accordance with Firefox's UI, or we explicitly say that the values set
for the `arrow` property are more "suggested values" rather than "actual
values", and there is no guarantee the arrow will be placed there.

As far as I remember, the UX guidelines says about arrowed panels:

- The arrow should be always placed in the center of the anchor element
(we can't assure that, of course, if we just pass coordinates instead of
anchor element)

- The panel should be always "tend" to the center of the content area.
Not sure if it's the right way to say, but basically if we open an
arrowed panel in top right corner of the browser, the arrow should be
displayed in the top right, with the panel's body that "point" to the
center of the content area. If we open an arrowed panel on the bottom
right, the arrow should be on the bottom right, with the panel's body
that point to the center of the content area, etc.

Personally, I would like for high level API be consistent with Firefox's
UI guidelines and behaviors: one of the big issue so far before Jetpack,
was that the user experience across add-ons was inconsistent; and I can
see Add-on SDK as a good way to mitigate that.

ZER0

unread,
Jan 31, 2013, 5:24:13 PM1/31/13
to mozilla-la...@googlegroups.com
Hi there,

I just added the Panel positioning proposal in the wiki:

<https://github.com/mozilla/addon-sdk/wiki/JEP-Panel-positioning>

You can add your thoughts here or in the etherpad:

<https://etherpad.mozilla.org/panel-positioning>

Looking forward for your feedback!

ZER0

unread,
Feb 3, 2013, 9:27:29 AM2/3/13
to mozilla-la...@googlegroups.com
Rocketeers!

Updated again the wiki:

<https://github.com/mozilla/addon-sdk/wiki/JEP-Panel-positioning>

The main refactoring was about percent values, that are removed, because
it was confusing that percent values are actually used using as origin
point the center of the panel, where for pixel values it was the top
left corner.

Also thanks to Gozala (and FOSDEM, to give to me the opportunity to
block him at a chair :P) for the points he mentioned here:

<https://etherpad.mozilla.org/panel-positioning>

Please, have a look and contribute too with your comments! It will help
to reach a consensus � or sort of � and proceed to delivering this new
feature sooner.
Reply all
Reply to author
Forward
0 new messages