I've asked this question in another popular forum (here) and was surprised not to have a single response in 2 weeks, maybe because it was tagged as a "jQuery" issue although fundamentally a CSS & cross-browser issue. I am certain a solution will be useful to the SitePoint community and beyond.

I've been using jQuery and IE filters to create a text shadow in IE<=9, to make up for the missing text-shadow property. This can be seen in the top-of-page h2 headings on the site http://area11aa.ie, which uses jQuery on browsers that don't support the text-shadow property (detected by modernizr) to replicate the text inside the h2 element...

The problem: Depending upon the screen width, the simulated drop shadows flow independently of the text behind them. You can always see this in IE8 and IE9 by slowly changing the window width until one of the shadows pops away from its text, like this (screenshot from IE9):

I don't understand how this can happen if the shadow span is absolutely positioned in the containing box of the h2 element. Yet they are able to flow as if they were unattached. I realise this may be a browser bug and therefore would be happy with a workaround supporting IE8 & IE9, as I would be if someone can point out any problems with my application above.

I've heard that CSS Sandpaper text-shadow implements a similar technique. In the next few days I'm about to test to see if it has the same problem... if it does, our next design is totally screwed.

I would therefore love to know if 1) if there is a best-practice way of dealing with this problem, and 2) failing a more general approach, if anyone has tested CSS Sandpaper enough to know if it's free from this vulnerability & could be endorsed as a best-practice solution.

You have offset the duplicated text by 7px to the left and therefore it will wrap 7px later than the text it is associated with. The behaviour is consistent in IE and indeed Firefox if you try this manually. The solution is to offset the offset by adding 7px right padding to the span.

Paul O'B: I've been hoping for an obvious solution like this too, though prior disappointment suggests it's a browser bug: the ugly MS filters vs. the CSS positioning model. I am still on the lookout for such a workaround, and have added your padding line to the CSS on the live site http://area11aa.ie:

h1 span.shadow { ...
left: -7px;
padding-right: 7px;
top: -2px; ... }

The filter elements are still flowing into the empty space as the window increases in size. As far as I can tell the behaviour is exactly as before, which I think favours the idea that it's a positioning bug rather than the size of the padding box.

thanks, ralph.m: my solution above is an implementation of method #2 (it's the link in my original posting). #1 and #4 are the same method, the code looks well supported and usage is clearly documented with reported problems being fixed on Github for a while. The review from Force Flow is also encouraging. Next time around I would definitely give heygrady/textshadow a go. (The remaining two don't look maintained.)

I was worried about using CSS Sandpaper because of the number of JavaScripts and my difficulty understanding how they all worked together or which ones to use.

I'll report as soon as I can on heygrady/textshadow, and in the meantime I am still looking for an explanation of this problem & an elementary workaround. If there is any feedback from the other forum or practical experience I will summarise here.

Paul O'B: I've been hoping for an obvious solution like this too, though prior disappointment suggests it's a browser bug: the ugly MS filters vs. the CSS positioning model. I am still on the lookout for such a workaround, and have added your padding line to the CSS on the live site

It's not a problem with the filters because as I mentioned above Firefox will do exactly the same thing if you give it the same code. The demo I gave above works fine in IE8 so its likely to be the percentage padding and margin you have applied to the h2 that is confusing things again.

I suggest that you sidestep the padding issue and place the appended span into the anchor and then you only have the offset to cater for.

This is a rough version of your code with the span moved and seems to work fine in IE8 right until it gets very small. If you move the span outside the anchor you get the same behaviour as before with the shadow wrapping at different steps.

There may be a typo in one of the offset values... as written, I see a 1px wrapping difference. Fine-tuning the padding-right from 8px to 7px to match the p:a offset makes Paul's solution render perfectly on my PC (FF, Chrome, Opera, IE8).

There may be a typo in one of the offset values... as written, I see a 1px wrapping difference. Fine-tuning the padding-right from 8px to 7px to match the p:a offset makes Paul's solution render perfectly on my PC (FF, Chrome, Opera, IE8).

... I suggest that you sidestep the padding issue and place the appended span into the anchor and then you only have the offset to cater for....

dear Paul: I really appreciate your time in addition to publishing an additional iteration of your demonstration code. This proves that the percentage widths on the containing element aren't the problem, as you suggested earlier if I understood correctly. And it proves that a correct implementation is possible, though my primary question is to find out why the problem is happening on the production site!

I've adjusted the jQuery so it adds the shadow <span> inside the anchor, so the HTML ends up the same as yours above:

The offset is added exactly as in your code (7px). And all relevant parts of the CSS are the same as far as I can tell. So why I am I still seeing this problem on the live site (http://area11aa.ie) in IE9? What have I missed?

Dear Paul: I am truly grateful for your persistence with me. Yes, I'd missed the rule set that establishes a new stacking context for the <a> element. It now works perfectly with that section added, on the live site. Thank you for helping me understand what the issue was, although I still don't know what general design principle would have avoided the problems in the first place.

There are some clues on the design page for [jQuery Textshadow, in the two sections for [URL="http://heygrady.com/blog/2011/03/10/css-text-shadows-in-internet-explorer#glow"]Glow and [URL="http://heygrady.com/blog/2011/03/10/css-text-shadows-in-internet-explorer#blur"]Blur](http://heygrady.com/blog/2011/03/10/css-text-shadows-in-internet-explorer) (the two effects used in this design). Both sections describe adjustments that must be made to element positioning, as well as nested <span> elements each creating a new stacking context.