Help - Search - Members - Calendar
Full Version: Difference between inline and style sheets in DOM access.
HTMLHelp Forums > Programming > Client-side Scripting
Scott Hill
If I do a test like:

CODE
<div id="messageBoardStats" onclick="alert(this.id + '\n' + this.style.bottom)">


and when the style is defined inline, then the alert finds the style.bottom. But if (as in this example) the style is defined in a style sheet then the property it is undefined at least to this little test. In both cases I'm using, the page is being rendered properly according to the style. It doesn't matter what the property is or what the browser is, when defined in an external style sheet either using <link> or @import, the properties become invisible to this test.

So, what's up? Why is this?
pandy
I moved this to the scripting forum.

I don't know enough about this to be of any help. I know document.styleSheets['0'].cssRules[0].style.bottom works, but then you have to already know what you are looking for. There must be a more casual way. huh.gif
Christian J
To get the cascaded styles that's set in a style sheet you can use MSIE's proprietary currentStyle (also supported by Opera, it seems):

CODE
<style type="text/css" media="screen">
div {
position: absolute;
bottom: 10px;
}

#foo {bottom: 50px;}
</style>

<div id="foo" onclick="alert(this.currentStyle.bottom)">Foo</div>

(In the above example, the 50px value in #foo overrides the 10px in DIV.)

There's also a function called getStyles() on http://www.quirksmode.org/dom/getstyles.html that seems to work in Safari as well, but Firefox returns a very strange value for "bottom" (-750px or so for me).

If the style sheet is simple you might loop through the rules until you find the matching selector, and hope that the computed style doesn't differ. Here's a modified example from http://www.javascriptkit.com/dhtmltutors/externalcss3.shtml :

CODE
<style type="text/css" media="screen">
body {color: #000;}

#foo {
position: absolute;
bottom: 10px;
}

div {bottom: 50px !important;}
</style>

<script type="text/javascript">
function get_property(selector)
{
    var mysheet=document.styleSheets[0];
    var myrules=mysheet.cssRules? mysheet.cssRules: mysheet.rules;
    for (i=0; i<myrules.length; i++)
    {
        if(myrules[i].selectorText.toLowerCase()==selector)
        {
            alert(myrules[i].style.bottom);
            break;
        }
    }
}
</script>

<div id="foo" onclick="get_property('#'+this.id);">Foo</div>

Note that this only returns what's written in the style sheet for that rule, not the cascaded style applied to the element. For example, in the style sheet above the last DIV rule overrides #foo's rule above it (due to the !important declaration), but the script still alerts #foo's value of 'bottom', not DIV's.
Scott Hill
QUOTE(Christian J @ Feb 1 2009, 10:13 AM) *

To get the cascaded styles that's set in a style sheet you can use MSIE's proprietary currentStyle (also supported by Opera, it seems):

There's also a function called getStyles() on http://www.quirksmode.org/dom/getstyles.html that seems to work in Safari as well, but Firefox returns a very strange value for "bottom" (-750px or so for me).

If the style sheet is simple you might loop through the rules until you find the matching selector, and hope that the computed style doesn't differ. Here's a modified example from http://www.javascriptkit.com/dhtmltutors/externalcss3.shtml :

Note that this only returns what's written in the style sheet for that rule, not the cascaded style applied to the element. For example, in the style sheet above the last DIV rule overrides #foo's rule above it (due to the !important declaration), but the script still alerts #foo's value of 'bottom', not DIV's.


Thanks for your input on this Christian. Good stuff. I see this thread was moved. I'm not sure it should have been. It's really a question about CSS not about scripting. Why is there a difference in an element's properties due to how or where they were set? If a property is set inline or externally, why should that make the property more or less visible to a specific discovery method? It just seems very wrong on some holy-justice-principals level.

Ready for a little Sunday morning venting? I just finished cleaning out all the inline CSS in a client's page and moving it to an external file. A couple of issues just killed me. Expressions WEB was putting Byte Order Marks at the top of the style sheet and messed up Firefox. Then for some reason IE wasn't reading all of the style markup using the @import command but changing to <link> fixed the problem. This is all time I'm going to flush down the drain. IE 7 & 8 is still not rendering an absolute positioned <div> block when Fox, Opera, Safari, Chrome, and even Expressions WEB page-view have no problem. I hate IE. I wish I could send a bill to MS for all the lost time.
Christian J
QUOTE(Scott Hill @ Feb 1 2009, 06:25 PM) *

Why is there a difference in an element's properties due to how or where they were set?

In CSS, it affects the specificity.

QUOTE
If a property is set inline or externally, why should that make the property more or less visible to a specific discovery method? It just seems very wrong on some holy-justice-principals level.

Maybe the JS "style" property applies to HTML's STYLE attribute only, which makes sense from a JS syntax point of view.

QUOTE
Expressions WEB was putting Byte Order Marks at the top of the style sheet

Expressions WEB, isn't that the new FrontPage? tongue.gif FWIW & IIRC, some editors add BOMs when you specify UTF-8 charsets. unsure.gif
Scott Hill
QUOTE(Christian J @ Feb 1 2009, 02:57 PM) *

QUOTE
Expressions WEB was putting Byte Order Marks at the top of the style sheet

Expressions WEB, isn't that the new FrontPage? tongue.gif FWIW & IIRC, some editors add BOMs when you specify UTF-8 charsets. unsure.gif

I thought I might get trashed for mentioning that MS product. It's not so bad. It's funny that the BOM it puts at the begging of the style sheet wrecks havoc with Firefox but not IE.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2010 Invision Power Services, Inc.