Here you'll find answers to the following questions:
sWmode and now Mozilla is acting weirdsIFR uses what we call 'lazy scaling'. This means that when the page is loaded, the replaced text is generated with respect to the users default font size. To change that size, the Javascript has to be called again, and therefore a page refresh is required. Accessibility wise this is good news because users that require a certain font size, will most likely have it set as their default, and therefore sIFR will respect their choice.
sIFR doesn't force anything. If the site visitor doesn't already use the proprietary technology ie. Flash, then normal X(HTML) headlines are seen and the markup is as pure as the day it was conceived. And if that isn't enough, sIFR itself is open source software!
That's exactly what sIFR is about. It's a behaviour layer, laid over the markup and styling. This way, screenreaders will see the normal heading, as it should. It's the same as with the above question.
There are steps you can take to prevent people from either removing the font from your .swf file or using your bandwidth by linking to your file. See Protecting Commercial Fonts for instructions.
sWmode and now Mozilla is acting weirdUnfortunately there are some bugs in Mozilla with Flash objects which have their wmode property set. These bugs can occur in cases where the CSS float and overflow properties are being used. If you encounter these bugs, the only solution is to refrain from using these CSS properties or from setting the sWmode argument.
sIFR replaces the text and links inside the element you are replacing. Therefore, if you replace a elements, you're actually replacing the content of that a element. So in this example:
<a href="./foo">hello world</a>
you are replacing hello world. If you want a link in your replaced text, you need to wrap the a in another element and replace that instead:
<span><a href="./foo">hello world</a></span>
Now the sIFR element will contain a link to ./foo with hello world as text.
Since sIFR replaces the content of the selector you use, you have to use ul#my-menu>li as a selector, instead of ul#my-menu>li>a. If this gives trouble, you can wrap the anchor in a span and replace the span: ul#my-menu>li>span.
Please note that sIFR is more intented for replacing headlines than it is for replacing list items. Usually an image will do fine for these elements.
This is a peculiar problem, because normally, in the print style
sheet and the print version, the page should be printing up with the
HTML (non-sIFR) text. If, however, nothing appears, then this is most likely due to the fact that you haven't specified your "screen" stylesheet as media=screen.
You should therefore change your style sheet link on every page, for the screen style sheet, from:
<link href="screen.css" rel="stylesheet" type="text/css" />
to:
<link href="screen.css" rel="stylesheet" type="text/css" media="screen" />
Many people already include media="screen" when they're
specifying screen style sheets, but in case you haven't, this may be
the problem why your text isn't showing up in the print version.
Usually, when the sIFR elements look out of place, flicker, or are
way too big, this is caused by nearby floated elements. If the sIFR
element is inside a floated element it may sometimes flicker (for
example when a ticker is moving). Another problem which has been
spotted is that the font size would be way too huge when it was right
after a floated element. In this case you have to add clear: none; to the sIFR element (or, in case this doesn't work, add a new element between the two which gets cleared).