Good news is Microsoft is ending expressions in Internet Explorer as announced on Thursday earlier this week. Indeed a very nice move towards the standard-compliant browser.

I’m wondering however if it isn’t required to use javascript hacking if the idea behind the inherit is to remind a person to style the elements rather than depend on inherit as a default directive;

I’m trying to talk myself out of using any more hacks to make IE behave. Designers are already stuck using Transparent PNG hacks and other HTC (HTML Component) just to get IE to play nice.

This is a really good post Eric, thanks for the education and perspective.

~ Jared Ritchey

but It’s very slowwwwwwwwwing the page :(. It’s seems IE is calling js expression on any user action.

It should certainly be one of the generic families (serif, sans-serif, cursive, fantasy or monospace). serif and sans-serif seem the obvious choices.

you should check this, because during page loading things are different and html does have parentNode too.

That doesn’t overrule my point: it would be more sensible to just not use that expression for the html element.

Apart from performance, what’s wrong with:
  * {
    font-style: expression(this.parentNode.currentStyle.fontStyle);
  }
  html {
    font-style: normal;
  }
?

Are you sure that running your solution through profiler versus mine, your is not perhaps ten times slower?

Using expression is expensive in the first place; I don’t think calling a function adds relevant overhead.

To hell with using JavaScript for CSS. I suggest a separate reset IE style sheet within a conditional comment for all IE browsers.. simple and stupid.

html,body,div,span,
applet,object,iframe,
h1,h2,h3,h4,h5,h6,p,blockquote,pre,
a,abbr,acronym,address,big,cite,code,
del,dfn,em,font,img,ins,kbd,q,s,samp,
small,strike,strong,sub,sup,tt,var,
fieldset,form,label,legend,
caption{font-style:normal;font-weight:normal;font-family:monospace}


Anyone see any pitfalls in my logic, please blast away.

I am viewing the reset style sheet as more of a design tool that can be removed, or portions of it, prior to moving the content to the production server. I have been assuming that its use and development has and is directed primarily for projection and screen media. [Have not yet evaluated its impact upon print media or creating a separate massive print reset, nor the same for handheld devices.]

The use of script dynamic properties within a temporary reset file that serves as a visual aide to the developer/designer to insure that elements have been assigned values for font styling seems to make some sense. Keeping it simple and stupid seems to make some sense. Testing the hell out of any script, using a NASA philosophy, prior to deployment makes even more sense.

Spending ten bucks to solve a nickel problem doesn’t make sense.

I am leery as hell about the use of client-side JavaScript for a lot of reasons.

But then as stated, I could be just confused.

Jonathon is on the right track. To get true inheritance you should walk up the DOM tree like this:

<style type=”text/css">
p {font-family: wingdings;}
p.inherit {font-family: expression(inherit(this,"fontFamily","times"));}
</style>

<script type="text/javascript">
function inherit(element, property, defaultValue) {
  function process(element) {
    if (!element) return defaultValue;
    return element.currentStyle[property] || process(element.parentElement);
  };
  return process(element.parentElement) || defaultValue;
};
</script>

In the case of font-family, do you need to specify anything? As far as I know, the default value of font-family is inherit (or at least, the functionality is the same).

Nearly every element uses the same font-family as its parent, unless you explicitly overrule it. The only exceptions are elements like <code>, which have a default monospace font.

So doing nothing might be the best way of solving the font-family problem. Alternatively, as Sebastian said, use document.documentElement.currentStyle.fontFamily throughout the document.

I was having issues with IE 6 and 7 only when the script was referenced via conditional commented style sheets. Changing the single quotes to double quotes, as you did, resolved the IE errors.

One thing to note about the expression() value is that it executes JavaScript. When JavaScript is turned off the expression() is never calculated. However, because it is JavaScript, the default could be a variable. Unfortunately if the variable doesn’t exist (unless it is an object property) it will cause an error. So something like -

font-family: expression(
this.parentNode.currentStyle ?
this.parentNode.currentStyle.fontFamily :
xFamily );

wouldn’t be a good idea, but you could do something similar to

font-family: expression(
this.parentNode.currentStyle ?
this.parentNode.currentStyle.fontFamily :
top.xFamily );

if top.xFamily doesn’t exist it simply treats it as a null or empty value & displays whatever IE’s default is.

When using expression() just be aware of some of the things others have discovered – 456 Berea Street – IE expressions ignore CSS media types