# sIFR Documentation and FAQ
FAQ

Here you'll find answers to the following questions:

- Does sIFR really scale to match the users selected font size?
- Doesn't forcing a proprietary technology such as Flash go against the principal of an 'open world wide web'?
- Isn't the use of Flash a problem for screenreaders?
- What's to stop somebody stealing my paid-for commercial fonts?
- I've set `sWmode` and now Mozilla is acting weird
- I'm replacing a link and it doesn't work
- How do I replace list items?
- I am having problems printing - the sIFR text comes up fine on screen but nothing prints?
- Things are going, uhm, berserk

## Does sIFR really scale to match the users selected font size?

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

## Doesn't forcing a proprietary technology such as Flash go against the principal of an 'open world wide web'?

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!

## Isn't the use of Flash a problem for screenreaders?

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.

## What's to stop somebody stealing my paid-for commercial fonts?

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.

## I've set `sWmode` and now Mozilla is acting weird

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

## I'm replacing a link and it doesn't work

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.

## How do I replace list items?

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.

## I am having problems printing - the sIFR text comes up fine on screen but nothing prints?

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.

## Things are, uhm, going berserk

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