Implement getComputedStyle for non-computed values

RESOLVED FIXED in mozilla0.9.7



DOM: CSS Object Model
16 years ago
16 years ago


(Reporter: bz, Assigned: bz)


(Blocks: 1 bug)


Firefox Tracking Flags

(Not tracked)



(1 attachment)



16 years ago
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...
Blocks: 42417


16 years ago
Priority: -- → P3
Target Milestone: --- → mozilla0.9.8

Comment 1

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

Comment 2

16 years ago
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 ,
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

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

16 years ago
Created attachment 59001 [details] [diff] [review]
Proposed fix

Comment 4

16 years ago
glazou, could you review?
Keywords: patch, review
Priority: P3 → P1
Target Milestone: mozilla0.9.8 → mozilla0.9.7

Comment 5

16 years ago
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:
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

16 years ago
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

16 years ago
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.
...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

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

Comment 11

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

Comment 12

16 years ago
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>

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 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.
Attachment #59001 - Flags: review+

Comment 14

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

Comment 15

16 years ago
Comment on attachment 59001 [details] [diff] [review]
Proposed fix

Attachment #59001 - Flags: superreview+

Comment 16

16 years ago
Checked in.
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.