STR: SwishMAX Text Replacement
STR: SwishMAX Text Replacement is similar to sIFR in that it uses Flash movies to replace text in an HTML document. STR does not, however, use Macromedia Flash to create the movies.
- Previous post: Validating an entire site
- Next post: Manipulating Definition Lists
Information, sponsorship, and externals
About the author
Roger Johansson is a Swedish web professional specialising in web standards, accessibility, and usability. More about me and this site.
Latest articles
- Validation statistics from Nikita the Spider Comments off
- An analysis of the sites crawled by the bulk validation tool Nikita the Spider during March 2008.
- Authentic Jobs API and Affiliates program Comments off
- The Authentic Jobs job listing service now has a public API and an affiliate program.
- What does Acid3 mean to you and me? Comments off
- Opera and Apple have announced that their web browsers pass the Acid3 Browser Test, but how will that help web designers and developers?
- Designing Web Navigation (Book review) Comments off
- Learn the fundamentals of navigation design and design better navigation systems for large and small sites as well as for web based applications.
- DOMAssistant bundle for TextMate Comments off
- To save keystrokes and speed up development I have created a DOMAssistant bundle for TextMate.
- First impressions of Internet Explorer 8 Beta 1 Comments off
- My impressions after trying out Internet Explorer 8 Beta 1 for a couple of days.
Comments
I scanned the article, but couldn't really find what differences existed between STR and sIFR, aside from using SwishMAX. Which beggs the question, why not use SwishMAX to export a Flash movie compatible with the sIFR ones?
Hi Mark, first of all, compliments for the wonderful job on sIFR.
STR is really basic and could not be compared to sIFR, since it's not scalable nor it's possible to get "auto-height" multilines (but just setting it with manually with Swish). It has something more than the original IFR, as is the possibility to get hover effect while replacing links. But it has two main advantages on them both: the replacement should be more accessible, since the swf movie cover the plain replaced text, maintaining accessibility to screen readers or crappy browsers. Links are accessible too, since they're preserved in the DOM tree. The technique of the replacement used is very similar to Gilder and Levin's cover up span, and should grant legibility even in the case Flash player is available, but blocked. And besides SwishMax is very more affordable than Flash.
SwishMax has a script language called SwishScript, wich is I believe at almost 90% equal to ActionScript.. so perhaps (but not sure about it) it's possible to get a working SwishMax source to produce fully compatible swf to sIFR. But I didn't tried, since I'm quite new to SwishMax or Flash. And, to be honest, I neither did think about it, since I enjoy to came with solutions by myself :-)
Best Regards. And thanks to Roger for everything.
Alessandro, ah, I see. Thanks for your reply. sIFR does still display the text though, and the links are still preserved in the DOM ;-)
Yeah, I looked over the article and the code for STR and it really offers no accessibility or otherwise advantages over sIFR at all (besides not requiring Flash to export the movies) and it has clear disadvantages:
You need to manually tell each instance how many lines of text to display (which is the single most important reason why sIFR was even developed).
It doesn't degrade gracefully with FlashBlock.
It hasn't been tested in the multitude of browser/OS/Flash combinations out there. Believe me, testing in hundreds of different setups required hundreds of code tweaks.
You must hardcode the height and width of each Flash movie.
Browser text seems to flash in before the Flash text overlays it.
Anyway, I don't mean to denigrate any of the work done here. Great job Alessandro for continuing to push the envelope. I'm just trying to correct the statement that STR offers advantages over sIFR.
Hi Mark and Mike, first of all thanks you both for the interest about STR. Mike, as I said STR could not be compared with sIFR. And, to continue the list you started:
The CSS selectors are a very small subset of those supported by sIFR.
It uses innerhtml and object/embed injection depending on the browser.
Text is not scalable.
And I could continue.. I wrote an article in italian about sIFR (when it was RC4) from the user's point of view, and in particular on how get it running, even because a part of the audience of site I write for it's not well informed about latest webdev english trends, techniques and articles. In doing so, however I did not dig into sIFR javascript code, since I wanted to develop a replacement technique from the ground up wich used SwishMax. When I said STR "should be" more accessible than sIFR, I was refering to the replacement technique. It should be more accessible the same way cover-up span is more accessible with images turned off respect the other image replacing techniques. I don't know much about FlashBlock and its implementation... But it did this small test with this home-made-flash-blocker with user style sheets, defining this simple rule:
object,embed{display: none}
While in STR the plain text is showed, in sIFR no headers are showed. I believe also that the scenario flash enabled but blocked is quite rare thought.
Finally, I could only guess how much hard coding work and tests are behind sIFR to produce such a great technique. This certainly could be thousands times more than the work on STR. Perhaps my english is not so good, and I really didn't meant to say that STR is better than sIFR in any point. In fact, I used a conditional verb. It's just a (cheaper) and really basic alternative.
Best regards, and keep up the good work.
I may be a tad biased :) however here goes... what Alessandro has done is provide SWF text replacement to a whole new group of users. They are usually young, besotted with flash and can't afford to spend more than $99 on good Flash authoring software. This tutorial might just expose them, for the first time, to elements of Web Standards and it's leading edge developers. It's realy not a "mine's bigger than your's" situation. STR is a great spin off from the acclaimed sIFR and understands it's limitations.
Oh, absolutely, I just didn't quite get why Alessandro didn't build upon the sIFR code, that's all! :)
Sorry, comments are closed for this post.