109523 - Implement getComputedStyle for non-computed values

Status: RESOLVED FIXED

(Core :: DOM: CSS Object Model, defect, P1)

Description

[Boris Zbarsky [:bzbarsky]]

This bug covers deciding on and implementing getComputedStyle() for values taht
are not computed.  Examples:

width/height for inline elements (currently NS_ERROR_NOT_IMPLEMENTED)
left/top/right/bottom for statically positioned elements (NOT_IMPLEMENTED)
All of these and z-index for elements which have display:none (hence no frames
and thus no computed size/position/z-index properties). (currently returns 0)

Ian? David?  Any of these that you _do_ agree on? :)  If so, I'll start working
on those...

Comment 1

[Boris Zbarsky [:bzbarsky]]

*** Bug 111133 has been marked as a duplicate of this bug. ***

Comment 2

[Marcus Fellinger]

Well, since Bug #111133 got duped do this one :-)

What I would like to do is create a menubar, with a series of submenus. 
There's an example of this at http://www.brainjar.com/dhtml/menubar/demo.html ,
but it uses the non-standard offsetLeft and offsetParent-properties. I would
like to do the same, but without using anything not in the DOM 1/2 or CSS
1/2-specification.

The size of each menuitem will depend on a variety of influences, some not under
the control of the page-author (user stylesheets, installed fonts, screen
resolution), so I either the position or size of each item have to be determined
at runtime.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: Proposed fix

Comment 4

[Boris Zbarsky [:bzbarsky]]

glazou, could you review?

Comment 5

[Marcus Fellinger]

I applied to patch provided by Boris to my tree. Now using getPropertyValue
doesn't cause an exception anymore. However, getPropertyValue("left") always
returns 0px, no matter where the element actually resides on the page. This
makes it essentially useless for statically positioned elements, and is no
better than the previous situation.

I've updated my test page to demonstrate this effect.

It is available at: http://www.felliweb.de/tests/getPropertyValue.html

Comment 6

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

That's the correct behavior.  getComputedStyle isn't much more useful than
getCascadedStyle.  If you want to know where something is on the page, you need
another API.

Comment 7

[Marcus Fellinger]

Well, I've seen the offsetXXX-attributes used to get this information. But these
are not in the specification. Is there no they, a JS programm can get
information about the actual layout of the page without using proprietary APIs?

Comment 8

[Boris Zbarsky [:bzbarsky]]

That's correct.  Unless an element is absolutely (or arguably fixed) positioned,
the W3C DOM api does not provide a way to find where it's located on the page.

Comment 9

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

...and even then, you have to do a bit of calculation to get the right position
for absolutely positioned elements that are the descendants of other absolutely
positioned elements.

Comment 10

[Marcus Fellinger]

Can one query statically positioned elements for where width/height? 

Comment 11

[Boris Zbarsky [:bzbarsky]]

*** Bug 112093 has been marked as a duplicate of this bug. ***

Comment 12

[Boris Zbarsky [:bzbarsky]]

For some, yes.  You can query block or inline-block or table-cell elements for
width/height.  You can also query replaced inline elements (eg images).

For non-replaced statically positioned inline elements, width/height once again
make no sense.  What is the "width" of the span in the following case:

<span>some text<br>
a</span>

if the first line is indented, so the shape of the span is:

   ************
**

For these elements my patch just returns the specified value of width/height

Comment 13

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Comment on attachment 59001 [details] [diff] [review]
Proposed fix

>Index: content/html/style/src/nsComputedDOMStyle.cpp
> ...
>+        case eStyleUnit_Auto:
>+          val->SetString(NS_LITERAL_STRING("auto"));
>+        case eStyleUnit_Inherit:
>+          val->SetString(NS_LITERAL_STRING("inherit"));
>+        default:

Don't you want to break after the string assignments ?

>+        case eStyleUnit_Auto:
>+          val->SetString(NS_LITERAL_STRING("auto"));
>+        case eStyleUnit_Inherit:
>+          val->SetString(NS_LITERAL_STRING("inherit"));
>+        default:

Same thing here.

Patch looks fine otherwise.
r=glazman providing the fact the changes above are made.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Oy.  Yes, I do want to break.  :)  Fixed that in my tree.

Comment 15

[Marc Attinasi]

Comment on attachment 59001 [details] [diff] [review]
Proposed fix

sr=attinasi

Comment 16

[Boris Zbarsky [:bzbarsky]]

Checked in.