Determining default style properties

G

Guest

Determining default style properties


I know that one can use JS to determine various properties of the DOM.
E.g., suppose one has:
<p id='qwe' style="color:green">filler</p>
then
something= document.getElementById("qwe").style.color
returns 'green'.

But if one has
<style> .setcolor {color:pink} </style>
<p id='qwe' class='setcolor'>filler</p>
something= document.getElementById("qwe").style.color
gets an empty string rather that the set color of 'pink'.

Similarly, one does not get any information about the browser's default
setting or any other setting given indirectly.

I have tried going up a level with
document.getElementById("qwe").parentNode.style.color
but that does not help. Nor does using
document.getElementById("qwe")getAttribute("style")
do any better in FireFox and in IE it just returns [object]

Surely that information must be there for the browser use it. Is it
accessible in any practical way?

One could, of course, set everything at the topmost level of <body> but
that would override the user's default settings which is most undesirable
(and rude).

TIA
 
S

Scott Sauyet

Determining default style properties

But if one has
  <style>  .setcolor {color:pink}  </style>
  <p id='qwe' class='setcolor'>filler</p>
something= document.getElementById("qwe").style.color
gets an empty string rather that the set color of 'pink'.
Click to expand...

As happens so often in browser scripting, there are competing ways of
doing this. The W3C-defined method is

getComputedStyle

specified here:

http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSSview-getComputedStyle

and explained better here:

https://developer.mozilla.org/en/DOM/window.getComputedStyle

Internet Explorer has the property

currentStyle

which is documented here:

http://msdn.microsoft.com/en-us/library/ms535231(VS.85).aspx

There are plenty of examples (of varying degrees of correctness and
efficiency!) online describing how you might combine these two into
your own function.

-- Scott
 
G

Guest

As happens so often in browser scripting, there are competing ways of
doing this. The W3C-defined method is
getComputedStyle

Internet Explorer has the property
currentStyle
Click to expand...

Scott,

Thank you. Those two expressions and my friend google and your link do
provide the needed answer.

K.
 
D

David Mark

As happens so often in browser scripting, there are competing ways of
doing this. The W3C-defined method is

getComputedStyle

specified here:

http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSSview-getComput...

and explained better here:

https://developer.mozilla.org/en/DOM/window.getComputedStyle

Internet Explorer has the property

currentStyle

which is documented here:

http://msdn.microsoft.com/en-us/library/ms535231(VS.85).aspx

There are plenty of examples (of varying degrees of correctness and
efficiency!) online describing how you might combine these two into
your own function.
Click to expand...

More like there are ten tons of bad examples. Where's one good
article (or example?) It's non-trivial to write a solid
getComputedStyle wrapper, even when limited to dealing with a handful
of styles (and apps should be designed with that in mind).

So if your design dictates a comprehensive cross-browser
getComputedStyle wrapper, change the design as it's a hard way to go.
 
S

Scott Sauyet

More like there are ten tons of bad examples.  Where's one good
article (or example?)  It's non-trivial to write a solid
getComputedStyle wrapper, even when limited to dealing with a handful
of styles (and apps should be designed with that in mind).
Click to expand...

This is true. If anything, it's an understatement.

A few things you will probably have to keep in mind:

- "opacity" is expressed in some places as a decimal, others as a
percentage, and it is handled very differently in IE than in most
other browsers.

- "float" will require special handling (search for "cssFloat" and
"styleFloat").

- inheritable properties may require you to walk up the DOM to
find them defined.

- You have to decide how to handle children of elements with
"display: none" that themselves have some other display value.

- You'll have to deal with the difference in name formats between
JS and CSS: "backgroundColor" vs "background-color".

And that is probably just the tip of the iceberg.
So if your design dictates a comprehensive cross-browser
getComputedStyle wrapper, change the design as it's a hard way to go.
Click to expand...

If on the other hand, you have only a limited number of properties you
need to support, it may not be too bad.

Good luck,

-- Scott
 
D

David Mark

This is true. If anything, it's an understatement.
Agreed.


A few things you will probably have to keep in mind:

- "opacity" is expressed in some places as a decimal, others as a
percentage, and it is handled very differently in IE than in most
other browsers.
Click to expand...

Yes, and among older non-IE browsers. But this is not specific to
computing styles (just inherent to style in general).
- "float" will require special handling (search for "cssFloat" and
"styleFloat").
Yes.


- inheritable properties may require you to walk up the DOM to
find them defined.
Click to expand...

Right, among other calculations (some impossible) that would be
required convert a "cascaded" style to proper computed value. It's
one of those things that is half-assed in the "standard" libraries.
Some make no distinction between them at all (and no comments or
documentation to indicate the shortcomings).
- You have to decide how to handle children of elements with
"display: none" that themselves have some other display value.
Click to expand...

There's nothing to decide. See the CSS specs. :)
- You'll have to deal with the difference in name formats between
JS and CSS: "backgroundColor" vs "background-color".
Click to expand...

Perhaps. It makes for a friendlier interface for beginners used to
reading CSS, but not JS. I've never bothered with it at all.
And that is probably just the tip of the iceberg.
Click to expand...

Pretty much. The computing of styles to compensate for IE's
shortcomings is a major can of worms. That's why it is best to
identify what you need out of a wrapper like this before you design
it. If, for example, left and top will always be in pixels, you know
you can get left and top reliably in cross-browser fashion (for
browsers that support getComputedStyle or IE). Set the inline styles
to pixel-based values and you can support the browsers that predate
getComputedStyle. Context and simplicity are everything with this
stuff, which is why outlandish, complex, half-assed error-prone
nightmare scripts (that must be swapped out in their entirety every
six months) are the opposite of a good idea. Yes, there are a lot of
people out there who have yet to have this epiphany. It's coming. ;)
If on the other hand, you have only a limited number of properties you
need to support, it may not be too bad.
Click to expand...

Exactly.
 
S

Scott Sauyet

[ ... much agreement deleted ... ]
    - You have to decide how to handle children of elements with
"display: none" that themselves have some other display value.
Click to expand...

There's nothing to decide.  See the CSS specs.  :)
Click to expand...

I don't think the CSS specs can determine how getComputedStyle or the
OP's own wrapper should behave.

Each time I've written such a wrapper, I've reported "none" for

<p style="display:none"><a id="myLink">something</a> more</p>
...
var myLink = document.getElementById("myLink");
alert(myGetComputedStyleWrapper(myLink, "display"));

even though the underlying functions might report "inline". This has
been useful behavior for my own applications. That's what I meant by
deciding how to handle it.

-- Scott
 
D

David Mark

[ ... much agreement deleted ... ]
- You have to decide how to handle children of elements with
"display: none" that themselves have some other display value.
Click to expand...
Click to expand...
There's nothing to decide. See the CSS specs. :)
Click to expand...

I don't think the CSS specs can determine how getComputedStyle or the
OP's own wrapper should behave.
Click to expand...

Not the wrapper, but the inheritance rules are clearly defined in the
specs. But you would have to move up to the DOM specs to get the
specific recommendations for getComputedStyle.
Each time I've written such a wrapper, I've reported "none" for

<p style="display:none"><a id="myLink">something</a> more</p>
...
var myLink = document.getElementById("myLink");
alert(myGetComputedStyleWrapper(myLink, "display"));

even though the underlying functions might report "inline".
Click to expand...

The computed style is "none." That's in the specs. ;) IE would
report "inline" as it doesn't compute styles.
This has
been useful behavior for my own applications. That's what I meant by
deciding how to handle it.
Click to expand...

Sure, you could decide to not worry about descendants of elements with
display:none style. That's certainly do-able for most (if not all)
designs.
 
S

Scott Sauyet

The computed style is "none."  That's in the specs.  ;)
Click to expand...

I don't think so. There are slightly mixed signals

http://www.w3.org/TR/1998/REC-CSS2/visuren.html#propdef-display

display { inherited: no }

So children don't inherit "display: none" from their parents. However
the same section says

display: block
==============
| This value causes an element to not appear in the formatting
| structure (i.e., in visual media the element generates no boxes and
| has no effect on layout). Descendant elements do not generate any
| boxes either; the element and its content are removed from the
| formatting structure entirely. This behavior cannot be overridden
by
| setting the 'display' property on the descendants.


And this is why I like to report them as "display: none", it's not
technically accurate, but it's generally more practical.

IE would report "inline" as it doesn't compute styles.
Click to expand...

So does every other browser I've tested. Not that I've gone to great
lengths to test this, mind.

-- Scott
 
D

David Mark

I don't think so. There are slightly mixed signals

http://www.w3.org/TR/1998/REC-CSS2/visuren.html#propdef-display

display { inherited: no }

So children don't inherit "display: none" from their parents.
Click to expand...

That's correct. But when you _compute_ the display style, you have to
take the ancestors into account.
However
the same section says

display: block
==============
| This value causes an element to not appear in the formatting
| structure (i.e., in visual media the element generates no boxes and
| has no effect on layout). Descendant elements do not generate any
| boxes either; the element and its content are removed from the
| formatting structure entirely. This behavior cannot be overridden
by
| setting the 'display' property on the descendants.

And this is why I like to report them as "display: none", it's not
technically accurate, but it's generally more practical.
Click to expand...

It is accurate if the computed display style is what you are after.
So does every other browser I've tested. Not that I've gone to great
lengths to test this, mind.
Click to expand...

What browsers (aside from IE) have you tested that reported "inline"
for the anchor?
 
T

Thomas 'PointedEars' Lahn

The cited section does not contain that line.
That's correct. But when you _compute_ the display style, you have to
take the ancestors into account.
Click to expand...

No. That is only the case if the property is inherited. `display' is a
property that is not inherited. You mistake the computed value for
something else.
It is accurate if the computed display style is what you are after.
Click to expand...

No. The computed value of the `display' property of those child elements
is "block" or whatever the default property value for the corresponding
element is, not taking into account stylesheets that apply to that element.

ISTM that Scott wants to compute what the CSS 2(.1) Specification calls the
"actual value" instead:

<http://www.w3.org/TR/CSS21/cascade.html#computed-value>


PointedEars
 
T

Thomas 'PointedEars' Lahn

D

David Mark

The cited section does not contain that line.



No. That is only the case if the property is inherited. `display' is a
property that is not inherited. You mistake the computed value for
something else.



No. The computed value of the `display' property of those child elements
is "block" or whatever the default property value for the corresponding
element is, not taking into account stylesheets that apply to that element.

ISTM that Scott wants to compute what the CSS 2(.1) Specification calls the
"actual value" instead:

<http://www.w3.org/TR/CSS21/cascade.html#computed-value>
Click to expand...

Yes, I had that one screwed up. Unsurprisingly, I was thinking of
some extraneous code that I shouid remove from My Library (been doing
a bit of that lately). In this case, the computed value from the
specs is what is returned by getComputedStyle (and it is not "none"),
so I should not be compensating in the cascaded style (IE) branch.
JFTR though, sometimes the expected result for getComputedStyle does
not match what the specs call "computed".

So the descendant is not displayed, regardless of display style, which
might make it seem convenient to return 'none' for a get style
wrapper. But if you consider the question during design, you don't
need to worry about computing the display style of descendants (just
check the ancestor). For example, imagine if you got a "none" result
for an sncestor of an element with display:none, what would that mean
to the caller? Setting its style to something other than "none" will
have no effect. Empirically the ancestor is not displayed. Logically
it is displayed and the proof is that if you display the ancestor, the
descendant follows suit. If the descendant were not displayed,
displaying the ancestor would not change that. I'm sure it is clear
that designing around such questions is preferable to dealing with
them at run time. ;)
 
T

Thomas 'PointedEars' Lahn

Scott said:
Yes, although I don't know if that's what the OP would want or not.

CSS2.1, now why in the world was I looking at 2.0? :) I knew there
was some information on this.
Click to expand...

Although CSS 2.1 is still only a Candidate Recommendation as of today, for
references as if still in the status of a Working Draft, the CSS 2 Errata
document says that it should be considered the errata for CSS 2 where both
versions define the same feature but differently:

<http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata.html>

However, several features of CSS 2.1 have been implemented already.
Thanks, Thomas.
Click to expand...

You are welcome.


PointedEars
 
T

Thomas 'PointedEars' Lahn

David said:
JFTR though, sometimes the expected result for getComputedStyle does
not match what the specs call "computed".
Click to expand...

Please elaborate.


PointedEars
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Help with code 0
Help with my responsive home page 2
Using JS to verify registration info? 1
CreateChildControls() always has default values for properties 1
Tree list with checkboxes that can capture values of checked items and corresponding text areas 0
Sencha Touch--Support 2 browsers in just 228K! 64
Help with a default page 2
AJAX/DOM - Works in FF but not IE? 13

Members online

No members online now.
Total: 34 (members: 0, guests: 34)
Robots: 197

Forum statistics

Threads
473,756
Messages
2,569,535
Members
45,008
Latest member
obedient dusk

Latest Threads

Top