290664 - implement -moz-box-orient: inherit-opposite

Status: NEW

(Core :: XUL, enhancement)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

In the case of some UI elements that can be used in either a horizontal or
vertical fashion, it would be useful to be able to specify that the orient of a
<box> should be inherited as the opposite of its parent.  We can already do
-moz-box-orient: inherit through normal CSS inheritance; how hard would it be to
add a -moz-box-orient specific inherit-opposite, that flips horizontal to
vertical and vice versa?

Comment 1

[Boris Zbarsky [:bzbarsky]]

Implementing that shouldn't be too hard, actually...

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

dbaron is suggesting "opposite" as the keyword instead of "inherit-opposite"; I
have no strong feelings either way, anyone else have any comments?

Comment 3

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: xul-box-opposite.patch

So here's a first patch for this.  As I found out though, we don't so much map
XUL attributes into style or vice versa like we do for HTML; this means that
switching the orient via setAttribute("orient", ....) doesn't so much allow
'opposite' to work (the computed style is never updated).

Also, switching -moz-box-orient via style doesn't have any effect on the box
itself.

This makes this patch less than useful. :)

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: xul-box-opposite-1.patch

Ok, with dbaron's help, this seems to work.

It's only really useful for specifying -xul-box-orient via CSS, and specifying
it via an attribute will cause strange things to happen -- but that's not
unlike what happens when you mix the two now anyway.

Comment 5

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

I have a question: where is NS_STYLE_BOX_ORIENT_OPPOSITE supposed to be defined?
 I can't find it, and neither can my compiler.

Comment 6

[Boris Zbarsky [:bzbarsky]]

I won't be able to get to this for a bit... (a week?)

Comment 7

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Whoops, diff too deep in the tree.  I'll put a new patch up shortly.

bz: no hurry, whenever you get a chance to poke at it.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 181589 [details] [diff] [review]
xul-box-opposite-1.patch

This seems to be missing some nsStyleConsts.h changes, no?

>Index: nsRuleNode.cpp
>   if (parentContext && 
>-      aRuleDetail != eRuleFullReset &&
>-      aRuleDetail != eRulePartialReset &&


I'm not so happy about this change, actually...  And we need similar changes
elsewhere, or a better system of handling this, unfortunately.	For example,
"color: currentColor" needs similar treatment.	I _think_ that's it, but I
didn't do a thorough audit.  What sort of performance testing has been done
with this patch?

>+    if (xul->mBoxOrient == NS_STYLE_BOX_ORIENT_OPPOSITE) {
>+      inherited = PR_TRUE;
>+      if (parentXUL->mBoxOrient == NS_STYLE_BOX_ORIENT_VERTICAL)
>+        xul->mBoxOrient = NS_STYLE_BOX_ORIENT_HORIZONTAL;
>+      else
>+        xul->mBoxOrient = NS_STYLE_BOX_ORIENT_VERTICAL;

So "opposite" is equivalent to "vertical" on the root.	Is that documented
somewhere?  I guess that's the opposite of the default direction, so it makes
_some_ sense....

Comment 9

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 181589 [details] [diff] [review]
xul-box-opposite-1.patch

Per comment 8

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

> I'm not so happy about this change, actually...  And we need similar changes
> elsewhere, or a better system of handling this, unfortunately.	For example,
> "color: currentColor" needs similar treatment.

Bug 332333 has another way of fixing color:currentcolor.

Comment 11

[Giorgio]

very nice improvement, i hope to see this soon in a nightly version :)