SIFR3 - An Alternative

SIFR is an awesome concept. I hate sacrificing the visual quality of my web sites in favor of accessibility and search engine compatibility, and so when I learned about SIFR I immediately fell in love with the idea. Its not great that we have to resort to these kinds of things to achieve our web design goals, but if it works well, then why not?

As I started using SIFR 2, I became more aware of its limitations. SIFR doesn't allow for dynamic text re-flow (which is vital to liquid layouts). Also, if you modify the text size of your page using View > Text Size (or equivalent), SIFR doesn't resize the text for you. These are not deal breakers, since SIFR is still better than using images. But these limitations are nonetheless a "stone in my shoe", as it were. People (my clients and end users alike) don't care if you're using Flash to display the headers, as long as they don't notice it. But as soon as they try to change font sizes and it doesn't work, they begin to become dissatisfied with the work.

Also, I found SIFR 2 difficult to configure. It was quite a chore to get it to work in my layouts, and the process of updating a special SIFR stylesheet was not intuitive. Also, I had to explain to the other developers why we had to include this whacky css file in the first place.

As SIFR 3 did not seem to be on the horizon, I began developing my own version. My goal was to create a SWF header replacement solution that supported dynamic text reflow, on-the-fly text resizing, and did not require special stylesheets. Ideally, it would get all same style information as the headers it would replace, and be a truly seamless integration. Also, it would be compatible with Flash Player 6 and higher, take advantage of Flash 8 font technology where available, and be compatible with as wide a range of browsers as possible.

I borrowed some ideas from the SIFR 2 libraries (standing on the shoulders of giants), and discarded others. Things like browser detection and cross-platform compatibility were abstracted into other parts of my overall JS framework. And I tested, tested, and tested some more.

And in the end, I was successful. I met every objective I set out to achieve. So now I'm considering releasing the source code into the public domain. I've seen the feature list for SIFR 3, which is currently in Alpha, and I've seen the Alpha page too, and I'm not sure whether SIFR 3 will support text reflow as my library does. Also not sure whether it will allow you to set the size of the text using your browser. So, I think there's a possibility my library will be useful to some people.

I don't consider my work to be competing with SIFR at all. I have no intention of matching SIFR feature-for-feature, since I'd rather just use SIFR than do all that development and testing myself. But I do think my work is pretty good, and I'd like to see it help someone other than me. So, in the near future I'll be scrubbing the code, writing a little documentation, and posting a demo page where you can see it in action.

Let me know if you think you would find a SIFR alternative useful, and I'll work to deliver a high-quality product.

<DL> within <CITE> in Mozilla

Another arcane css issue... Sometimes I like to use a definition list within a cite element to display the name and title of a person I am quoting, like this:

<blockquote>I am not a crook.</blockquote>
<cite>
<dl>
<dt>Richard Nixon</dt>
<dd>President, USA</dt>
</dd></dl>
</cite>

To me, this makes semantic sense. The cite tag is used to show that the information within it is the citation for what's in the blockquote, and the definition "President, USA" defines the term "Richard Nixon". The advantage to all this markup is that now I have style hooks to work with.

The problem is that in Mozilla browsers, if you make "cite" a block element, it will not contain the definition list within it. In fact, it doesn't seem to matter what you put in it. If, for example, you want to give the cite a border, the child element will appear outside the border.

Adding a span tag around the child element fixes the problem:

<blockquote>I am not a crook.</blockquote>
<cite>
<span>
<dl>
<dt>Richard Nixon</dt>
<dd>President, USA</dt>
</dd></dl>
</span>
</cite>

This is cruft, and I hate it. But it's the best fix I've found so far. Anyone else got a solution?

Select Blocks (Not Rows) of Text

I always forget how to do this, so I figured I'd post it here.

To select a block of text in some applications, hold ALT + SHIFT while dragging. Try it, you'll like it!

I'm not sure what programs this works in, although it seems to work in most Microsoft apps.

Sadly, this trick doesn't seem to work in Dreamweaver or Flash.

Playing with Flex 2 Beta 3

Had to download and install Flex 2 Beta 3 as soon as I heard about it. I like the new welcome screen, although I doubt I'll look at it any more than the last one. I thought it was interesting that they actually performed usability testing on this, and discovered that most people skipped it. That's what people DO with welcome screens, after all: skip them, and never return.

I quickly migrated some of my test projects over to the new beta, and compiled them. After a bit of fiddling, and referencing this page heavily, I was able to get them to work.

Some thoughts regarding the changes:

1) The StringBuilder class is gone, the reason given being that the performance gain it achieved was not enough to justify having two string manipulation classes. Now, I'm all for having a clean API. But I think I'd rather have the (mildly confusing) choice between two similar classes if it means I can have even slightly better performance.

2) Trace is back out of flash.utils, so now you can call it without importing the package. I think I liked it better in flash.utils. The point of putting it there in the first place was (I think) to put control in the hands of the developer. If I don't need it, why load it? Again, convenience be damned if it makes for even SLIGHTLY poorer performance. Plus, it just seemed at home in flash.utils, rather than floating about the ether as a global method.

Anyway, that's my first quick look at things. I will no doubt be posting more on the subject as I delve more deeply.

Best Flash Blog Ever?

In my book, the title might go to this man, who is an engineer at Macrome... er... Adobe and works on the Flash Player. Every time he posts, I learn something new about the internals of the Player, or how decisions are made on the Player team.

Today's post on frame rates was typical Tinic quality. I had always wondered about why frame rates can be so imprecise, and now I know... in detail.

Also, he always seems to convey a healthy irreverence for the Player as a piece of software. He's not afraid to point out flaws or room for improvement. Now, if we can just get him to post more frequently!!