Last Comment Bug 109523 - Implement getComputedStyle for non-computed values
: Implement getComputedStyle for non-computed values
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: DOM: CSS Object Model (show other bugs)
: Trunk
: All All
: P1 normal (vote)
: mozilla0.9.7
Assigned To: Boris Zbarsky [:bz] (still a bit busy)
: Hixie (not reading bugmail)
: Andrew Overholt [:overholt]
Mentors:
: 111133 112093 (view as bug list)
Depends on:
Blocks: 42417
  Show dependency treegraph
 
Reported: 2001-11-10 09:38 PST by Boris Zbarsky [:bz] (still a bit busy)
Modified: 2001-12-06 13:20 PST (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Proposed fix (8.38 KB, patch)
2001-11-23 12:40 PST, Boris Zbarsky [:bz] (still a bit busy)
daniel: review+
attinasi: superreview+
Details | Diff | Splinter Review

Description Boris Zbarsky [:bz] (still a bit busy) 2001-11-10 09:38:10 PST
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 [:bz] (still a bit busy) 2001-11-21 08:12:18 PST
*** Bug 111133 has been marked as a duplicate of this bug. ***
Comment 2 Marcus Fellinger 2001-11-21 09:25:00 PST
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 [:bz] (still a bit busy) 2001-11-23 12:40:08 PST
Created attachment 59001 [details] [diff] [review]
Proposed fix
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2001-11-23 12:40:44 PST
glazou, could you review?
Comment 5 Marcus Fellinger 2001-11-25 12:09:41 PST
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-10 2001-11-25 12:40:57 PST
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 2001-11-26 07:00:03 PST
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 [:bz] (still a bit busy) 2001-11-26 07:36:00 PST
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-10 2001-11-26 09:30:46 PST
...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 2001-11-27 01:41:01 PST
Can one query statically positioned elements for where width/height? 
Comment 11 Boris Zbarsky [:bz] (still a bit busy) 2001-11-27 07:31:30 PST
*** Bug 112093 has been marked as a duplicate of this bug. ***
Comment 12 Boris Zbarsky [:bz] (still a bit busy) 2001-11-27 07:57:27 PST
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) 2001-12-05 02:10:15 PST
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 [:bz] (still a bit busy) 2001-12-05 06:05:39 PST
Oy.  Yes, I do want to break.  :)  Fixed that in my tree.
Comment 15 Marc Attinasi 2001-12-06 10:49:42 PST
Comment on attachment 59001 [details] [diff] [review]
Proposed fix

sr=attinasi
Comment 16 Boris Zbarsky [:bz] (still a bit busy) 2001-12-06 13:20:38 PST
Checked in.

Note You need to log in before you can comment on or make changes to this bug.