Determining default style properties

Discussion in 'Javascript' started by Guest, Jan 19, 2010.

  1. Guest

    Guest 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>
    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
    but that does not help. Nor does using
    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).

    Guest, Jan 19, 2010
    1. Advertisements

  2. Guest

    Scott Sauyet Guest

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


    specified here:

    and explained better here:

    Internet Explorer has the property


    which is documented here:

    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
    Scott Sauyet, Jan 19, 2010
    1. Advertisements

  3. Guest

    Guest Guest


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

    Guest, Jan 19, 2010
  4. Guest

    David Mark Guest

    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.
    David Mark, Jan 20, 2010
  5. Guest

    Scott Sauyet Guest

    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

    - 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.
    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
    Scott Sauyet, Jan 20, 2010
  6. Guest

    David Mark Guest

    Yes, and among older non-IE browsers. But this is not specific to
    computing styles (just inherent to style in general).
    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).
    There's nothing to decide. See the CSS specs. :)
    Perhaps. It makes for a friendlier interface for beginners used to
    reading CSS, but not JS. I've never bothered with it at all.
    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. ;)
    David Mark, Jan 20, 2010
  7. Guest

    Scott Sauyet Guest

    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
    Scott Sauyet, Jan 20, 2010
  8. Guest

    David Mark Guest

    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.
    The computed style is "none." That's in the specs. ;) IE would
    report "inline" as it doesn't compute styles.
    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)
    David Mark, Jan 20, 2010
  9. Guest

    Scott Sauyet Guest

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

    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
    | 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.

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

    -- Scott
    Scott Sauyet, Jan 20, 2010
  10. Guest

    David Mark Guest

    That's correct. But when you _compute_ the display style, you have to
    take the ancestors into account.
    It is accurate if the computed display style is what you are after.
    What browsers (aside from IE) have you tested that reported "inline"
    for the anchor?
    David Mark, Jan 20, 2010
  11. 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:


    Thomas 'PointedEars' Lahn, Jan 20, 2010
  12. Guest

    Scott Sauyet Guest

    What specs are you referring to? I've never seen this specified.

    Firefox, Chrome, Safari, and Opera.

    Is there something wrong with the following test?

    -- Scott
    Scott Sauyet, Jan 20, 2010
  13. For it is not specified so; David is mistaken here.

    Non sequitur.
    Works as designed.
    Many things are wrong with it, but nothing that would invalidate your

    Thomas 'PointedEars' Lahn, Jan 20, 2010
  14. Guest

    Scott Sauyet Guest

    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.

    Thanks, Thomas.

    -- Scott
    Scott Sauyet, Jan 20, 2010
  15. Guest

    Scott Sauyet Guest

    Fair enough. Looking at it again, I see several issues too. :)

    -- Scott
    Scott Sauyet, Jan 20, 2010
  16. Guest

    David Mark Guest

    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. ;)
    David Mark, Jan 20, 2010
  17. 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:


    However, several features of CSS 2.1 have been implemented already.
    You are welcome.

    Thomas 'PointedEars' Lahn, Jan 20, 2010
  18. Please elaborate.

    Thomas 'PointedEars' Lahn, Jan 22, 2010
    1. Advertisements

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 (here). After that, you can post your question and our members will help you out.