Opinions on sifr

[Erwin Moller]

Hi,

sIFR = Scalable Inman Flash Replacement.
I use version 3, revision 436.

In my current project our designerguy wanted me to implement sifr.
Sifr is a technic to replace certain fonts with a flash-object that
displays the content in a certain typeface...

Sifr can be found here:
http://www.mikeindustries.com/blog/sifr/

Allthough I really hate to implement thirdparty libs in my projects, our
designerguy insisted, so sifr it is.

The first thing I found was that an unrelated lib (of myself) stopped
working.
Look at the following code snippet from my lib:

if (window.event){
// alert (window.event);
elementName = window.event.srcElement.name;
} else {
elementName = FFref.name;
}

In Firefox (3.0.11) I appearantly had some window.event!
If I uncomment the alert it gives me on FF: 'Object UIEvent'.

If I disable sifr I get 'undefined', as expected.

I can't think of a valid reason for any lib to screw around with the DOM
like that.
To be honest, I don't even know what they did to it, so I looked into
the sourcecode of sifr, but it consists of a heavily compacted two-line
program, without comments of course, which makes it very hard to disect.
Then I visited their forum, which was a mess without a searchoption.

My main problem is not this particular problem because I can evade it by
a few modifications in my lib, but I am afraid this sifr-lib screws up
more. (That is why I seldom use thrid party libs)

So I ask in here before I dive deeper into this package: Does anybody in
here have experience with sifr?

And why should they make window.event available in FF?
Should I start a discussion with the designerguy who fell in love with sifr?


Thanks for your time!

Regards,
(A slightly irritated) Erwin Moller


--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare

 

[Gregor Kofler]

Erwin Moller meinte:

Hi,

sIFR = Scalable Inman Flash Replacement.
I use version 3, revision 436.

In my current project our designerguy wanted me to implement sifr.
Sifr is a technic to replace certain fonts with a flash-object that
displays the content in a certain typeface...

Sifr can be found here:
http://www.mikeindustries.com/blog/sifr/

Allthough I really hate to implement thirdparty libs in my projects, our
designerguy insisted, so sifr it is.

The first thing I found was that an unrelated lib (of myself) stopped
working.
Look at the following code snippet from my lib:

if (window.event){
// alert (window.event);
elementName = window.event.srcElement.name;
} else {
elementName = FFref.name;
}

In Firefox (3.0.11) I appearantly had some window.event!
If I uncomment the alert it gives me on FF: 'Object UIEvent'.

If I disable sifr I get 'undefined', as expected.

I can't think of a valid reason for any lib to screw around with the DOM
like that.
To be honest, I don't even know what they did to it, so I looked into
the sourcecode of sifr, but it consists of a heavily compacted two-line
program, without comments of course, which makes it very hard to disect.
Then I visited their forum, which was a mess without a searchoption.

My main problem is not this particular problem because I can evade it by
a few modifications in my lib, but I am afraid this sifr-lib screws up
more. (That is why I seldom use thrid party libs)

So I ask in here before I dive deeper into this package: Does anybody in
here have experience with sifr?

And why should they make window.event available in FF?
Should I start a discussion with the designerguy who fell in love with
sifr?


Thanks for your time!

Regards,
(A slightly irritated) Erwin Moller

http://www.mikeindustries.com/blog/files/sifr/2.0/sIFR-2.0.7.zip

contains uncompressed code.

Anyway, you are in for a treat:

[hasFlash() is also cool...]

var UA = function(){
var sUA = navigator.userAgent.toLowerCase();
var oReturn = {
bIsWebKit : sUA.indexOf("applewebkit") > -1,
bIsSafari : sUA.indexOf("safari") > -1,
bIsKonq: navigator.product != null &&
navigator.product.toLowerCase().indexOf("konqueror") > -1,
bIsOpera : sUA.indexOf("opera") > -1,
bIsXML : document.contentType != null &&
document.contentType.indexOf("xml") > -1,
bHasTransparencySupport : true,
bUseDOM : true,
nFlashVersion : null,
nOperaVersion : null,
nGeckoBuildDate : null,
nWebKitVersion : null
};

oReturn.bIsKHTML = oReturn.bIsWebKit || oReturn.bIsKonq;
oReturn.bIsGecko = !oReturn.bIsWebKit && navigator.product != null &&
navigator.product.toLowerCase() == "gecko";
if(oReturn.bIsGecko && sUA.match(/.*gecko\/(\d{8}).*/)){
oReturn.nGeckoBuildDate = new Number(sUA.match(/.*gecko\/(\d{8}).*/)[1]) };
if(oReturn.bIsOpera && sUA.match(/.*opera(\s|\/)(\d+\.\d+)/)){
oReturn.nOperaVersion = new
Number(sUA.match(/.*opera(\s|\/)(\d+\.\d+)/)[2]) };
oReturn.bIsIE = sUA.indexOf("msie") > -1 && !oReturn.bIsOpera &&
!oReturn.bIsKHTML && !oReturn.bIsGecko;
oReturn.bIsIEMac = oReturn.bIsIE && sUA.match(/.*mac.*/) != null;
if(oReturn.bIsIE || (oReturn.bIsOpera && oReturn.nOperaVersion <
7.6)){ oReturn.bUseDOM = false };
if(oReturn.bIsWebKit && sUA.match(/.*applewebkit\/(\d+).*/)){
oReturn.nWebKitVersion = new
Number(sUA.match(/.*applewebkit\/(\d+).*/)[1]) };
if(window.hasFlash && (!oReturn.bIsIE || oReturn.bIsIEMac)){
var flashDescription = (navigator.plugins["Shockwave Flash 2.0"] ||
navigator.plugins["Shockwave Flash"]).description;
oReturn.nFlashVersion =
parseInt(flashDescription.substr(flashDescription.indexOf(".") - 2, 2), 10);
};
if(sUA.match(/.*(windows|mac).*/) == null ||
oReturn.bIsIEMac || oReturn.bIsKonq ||
(oReturn.bIsOpera && oReturn.nOperaVersion < 7.6) ||
(oReturn.bIsSafari && oReturn.nFlashVersion < 7) ||
(!oReturn.bIsSafari && oReturn.bIsWebKit && oReturn.nWebKitVersion <
312) ||
(oReturn.bIsGecko && oReturn.nGeckoBuildDate < 20020523)){
oReturn.bHasTransparencySupport = false;
};

All in all, very pedestrian 600 lines of code, and a lot of "setAttribute"s
They don't seem to screw around with event objects.

Gregor

 

[Gregor Kofler]

Erwin Moller meinte:

Hi,

sIFR = Scalable Inman Flash Replacement.
I use version 3, revision 436.

Ah I see version 3. My linked version 2 (though from 2008) doesn't work
in FF3...

Still
http://dev.novemberborn.net/sifr3/nightlies/sifr3-r436.zip
contains uncompressed code.

Gregor

 

[Erwin Moller]

Gregor Kofler schreef:

Erwin Moller meinte:

Ah I see version 3. My linked version 2 (though from 2008) doesn't work
in FF3...

Still
http://dev.novemberborn.net/sifr3/nightlies/sifr3-r436.zip
contains uncompressed code.

Gregor

Hi Gregor,

Thanks for finding a readable source version.
I should have found that that myself of course, but was probably too
irritated over sifr to think straight. ;-)

I looked through it and decided to refuse to use it.
Too much code and things going on in there I don't understand or should
study futher.
Bottomline: That thing changed the way my own libs works and makes FF3
have a window.event, which I dislike very much.

Another thing: The author has used code coming from JQuery and I read
enough posts concerning JQuery in here to get extra suspicious.

Now I only have to push my designer into forgetting about sifr. ;-)

Thanks for your help!

Regards,
Erwin Moller



--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare

 

[SAM]

Le 6/23/09 2:26 PM, Erwin Moller a écrit :

Hi,

sIFR = Scalable Inman Flash Replacement.
I use version 3, revision 436.

In my current project our designerguy wanted me to implement sifr.
Sifr is a technic to replace certain fonts with a flash-object that
displays the content in a certain typeface...

Sifr can be found here:
http://www.mikeindustries.com/blog/sifr/

I can't understand that Flash can be used in a web project
and more again if its use needs JS
Most of the time it is impossible to transmit an url of what we've seen
to somebody else :-(

What is this "designerguy" ?

sifr seems only a kind of help about fonts
"to insert rich typography into web pages without sacrificing accessibility"

But what is "accessibilty" (in Flash) ?
Who codes *accessible* pages in Flash ?

Anyway I see nothing special with my FlashBlocker with this demo :
<http://www.mikeindustries.com/blog/files/sifr/2.0/>
even when I set the site as acceptable.

 

[Erwin Moller]

SAM schreef:

Le 6/23/09 2:26 PM, Erwin Moller a écrit :

I can't understand that Flash can be used in a web project
and more again if its use needs JS

Welcome to sifr then. ;-)

Most of the time it is impossible to transmit an url of what we've seen
to somebody else :-(

??? I cannot follow.

What is this "designerguy" ?

A guy that designs the look and feel of the pages I program.

sifr seems only a kind of help about fonts
"to insert rich typography into web pages without sacrificing
accessibility"

But what is "accessibilty" (in Flash) ?
Who codes *accessible* pages in Flash ?

I think they mean that the pages will still behave normally if sifr
doesn't work.
It works like this:
1) You tell via css to use sifr for example for each <h1>
2) If sifr can load if will show the text between every h1 as a flash
applet, using kinky typography.
If sifr cannot load (= no flash or no JavaScript) it will fall back to
normal h1.

That is what I understood of sifr so far.

Anyway I see nothing special with my FlashBlocker with this demo :
<http://www.mikeindustries.com/blog/files/sifr/2.0/>
even when I set the site as acceptable.

I use flashblock too.
At least it falls back to normal rendering.

Regards,
Erwin Moller

PS: The 'designerguy' agreed to ditch sifr.



--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare

 

[SAM]

Le 6/23/09 10:41 PM, Erwin Moller a écrit :

SAM schreef:

Welcome to sifr then. ;-)


??? I cannot follow.

Say a site all in Flash with navigation by buttons in Flash,
I see something interesting somewhere there,
how can I give the url of the interesting page to somebody else ?
(there is no specific url for that page, no?)

Or the merchant site has a catalog in Flash and we have same problem.
(sometimes a flash link points to a pdf file, this one at least can be
referenced, but not every designerguy go so far, z'nt'it)

I meant what kind of man can be this guy ?!

A guy that designs the look and feel of the pages I program.

Ha! the loooook ... :-/
it becomes tiring to see
(all those decorations will kill the advantage of DSL)

I think they mean that the pages will still behave normally if sifr
doesn't work.

Yes, probably.
But that adds no accessibility,
that just tries to do not break what is still accessible.

It works like this: (...)
That is what I understood of sifr so far.

I did too.

I use flashblock too.
At least it falls back to normal rendering.

at least, yes.
(except the 12ko of JS downloaded for nothing)

PS: The 'designerguy' agreed to ditch sifr.

For now, for now ;-)

 

[David Mark]

Hi,

sIFR = Scalable Inman Flash Replacement.
I use version 3, revision 436.

Complete bullshit. Always has been. I don't mean the idea (which is
bad enough), but the code.

In my current project our designerguy wanted me to implement sifr.

Tell that idiot that he isn't qualified to pick scripts.

Sifr is a technic to replace certain fonts with a flash-object that
displays the content in a certain typeface...

Sifr can be found here:http://www.mikeindustries.com/blog/sifr/

Mike Industries? LOL.

Allthough I really hate to implement thirdparty libs in my projects, our
designerguy insisted, so sifr it is.

Again, what does this "designerguy" know about browsers scripting (or
even this particular script.) Like those who plop jQuery on pages
because they like the fade demos, they figure this is the only way to
get a certain effect. These clowns are easy to weed out of an
organization. Present evidence that their favorite script(s) are
unwieldy junk written by neophytes and wait for them to respond like
you insulted their favorite cartoon hero. Any sane organization will
toss them out on the street.

The first thing I found was that an unrelated lib (of myself) stopped
working.

Yes, that happens a lot.

Look at the following code snippet from my lib:

if (window.event){
   // alert (window.event);
   elementName = window.event.srcElement.name;} else {

   elementName = FFref.name;

}

To be fair, that's pretty bad.

In Firefox (3.0.11) I appearantly had some window.event!

Because some other script is emulating IE's quirks. Those are ill-
advised for what (I hope) are obvious reasons at this point.

If I uncomment the alert it gives me on FF: 'Object UIEvent'.

Oh joy. Some obtrusive blob of script has "smoothed over" the browser
differences.

If I disable sifr I get 'undefined', as expected.

That's the one.

I can't think of a valid reason for any lib to screw around with the DOM
like that.

Me either, but I can think of one guy who writes nothing but BS like
that. If scripts are out there, somebody will use (or attempt to use)
them.

To be honest, I don't even know what they did to it, so I looked into
the sourcecode of sifr, but it consists of a heavily compacted two-line
program, without comments of course, which makes it very hard to disect.
Then I visited their forum, which was a mess without a searchoption.

And likely staffed by people who start every sentence with "wow." As
in, "Wow, I can't believe you don't like it!!!!!"

My main problem is not this particular problem because I can evade it by
a few modifications in my lib, but I am afraid this sifr-lib screws up
more. (That is why I seldom use thrid party libs)

Your lib needs some work as well. But yes, dump the "Sifr" script.
You can't even pronounce the name.

So I ask in here before I dive deeper into this package: Does anybody in
here have experience with sifr?

I've seen it. Forget it. Looking at the source is a waste of time.

And why should they make window.event available in FF?

Because they are ignorant and probably saw some other ignoramus do the
same thing.

Should I start a discussion with the designerguy who fell in love with sifr?

I'd start a discussion with a higher decision-maker. Barring that,
tell him to stifle himself when the talk turns to scripts. He's
causing you to waste time on dubious code (and you need to work on
your own code.)

 

[Erwin Moller]

SAM schreef:

Le 6/23/09 10:41 PM, Erwin Moller a écrit :

Hi Sam,

Say a site all in Flash with navigation by buttons in Flash,
I see something interesting somewhere there,
how can I give the url of the interesting page to somebody else ?
(there is no specific url for that page, no?)

I see what you mean now.
And you are correct: sending an url is difficult and just points to the
flashmovie.
That is one of the reasons why full flash sites are bad IMHO.

Or the merchant site has a catalog in Flash and we have same problem.
(sometimes a flash link points to a pdf file, this one at least can be
referenced, but not every designerguy go so far, z'nt'it)


I meant what kind of man can be this guy ?!

Oh, like that. ;-)
He is actually really OK.
He is just waaaaay too eager to use new technology while I, on the other
hand, am quite conservative.
I don't even assume JavaScript is enabled.
IMHO: It is perfectly possible to create pleasing sites without Flash or
JavaScript.

Ha! the loooook ... :-/
it becomes tiring to see
(all those decorations will kill the advantage of DSL)

LOL.
Like loading the whole JQuery-lib on each request to replace a text on a
page. ;-)

Yes, probably.
But that adds no accessibility,
that just tries to do not break what is still accessible.


I did too.


at least, yes.
(except the 12ko of JS downloaded for nothing)


For now, for now ;-)

Brr, I hope your predictions are wrong.
All this fuzz for a 'better' font....

Regards,
Erwin Moller

--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare

 

[Richard Cornford]

SAM schreef:


Oh, like that. ;-)
He is actually really OK.
He is just waaaaay too eager to use new technology while I, on
the other hand, am quite conservative.

<snip>

Flash is not exactly new (even if, because everyone insists on writing
for the latest version, it is constantly trying to download some new
version), And I doubt that using to replace browser text is that new
an idea, just an idea that has to reoccur many times before someone
fails to conclude that it is a bad idea.

One of the first things I tried with the sifr demo was changing the
font size on the page. Of course they have pinned down the font sizes
in IE, but you cannot do that in Firefox (to name but one), and when
the font size changes the size of the replaced text does not (though
the areas it is sitting in does). That alone is a big minus on the
accessibility side.

It is also characteristic of many of these types of ideas, where some
work is done to replace some feature/facility/behaviour of web
browsers with something that would supposedly be "better", but the
early efforts fail to address the full set of features/facilities/
behaviours (such as failing to respond to font re-sizing, or
considering user activity such as window re-sizing) presumably because
the authors were initially unaware of these aspects of their task and/
or their importance. And then, if these missing features are added (if
they can be added, as that is not necessarily possible) the result is
so bloated by (and slowed down by), client-side code that it will not
look nearly as appealing as did at first.

When attempting to replace any aspect of normal browser behaviour
there is usually quite an uphill struggle just to get back to what the
browser was giving you before you started. It is not an activity to be
taken lightly.

An eagerness to use (or at least know about) the latest technology is
entirely understandable, but does it come along with a sound
understanding of the medium. Hypertext documents are a very particular
medium, where the 'page' does re-size, re-flow, and the text-sizes can
be changed by the reader. A decent designer for that medium could be
expected to have a mindset where the way documents flowed and scaled
would be of significance, making an interest in a technology that was
unsatisfying in that regard unexpected.

Perhaps your designer's perceptions are too tied to paper as a medium?
In which case there are other things to be addressed before trying to
choose new technologies.

Richard.

 

[Erwin Moller]

David Mark schreef:

To be fair, that's pretty bad.

Hi David,

Thanks for your response.
(We decided to not go with sifr.)

But I am always eager for a free lesson in JavaScript/DOM. ;-)
Could you tell me what is bad/wrong with the above codesnippet?
This is the complete function:

function getSelectHelper(FFref){
var elementName = "";
if (window.event){
elementName = window.event.srcElement.name;
} else {
elementName = FFref.name;
}
return selectHelperAllInstancesLookup[elementName];
}

It is an old piece of code, and while looking through it again I found a
few mistakes, so it is probably time to rewrite the thing anyway.
Feel free to shoot me.

Regards,
Erwin Moller

--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare

 

[Gregor Kofler]

Erwin Moller meinte:

[snip]

If - and only if this "if" is completely unavoidable - you need graphics
text, one could use some server side technology (e.g. PHP with some
graphics lib), to filter headlines, turn them into graphics and alter
the markup accordingly.

Anyway, we are talking about a solution to a non-existent problem again.
IMO it always looks crap, when headlines have some wildly different font
than the rest of the page.

Gregor

 

[Erwin Moller]

Gregor Kofler schreef:

Erwin Moller meinte:

[snip]

If - and only if this "if" is completely unavoidable - you need graphics
text, one could use some server side technology (e.g. PHP with some
graphics lib), to filter headlines, turn them into graphics and alter
the markup accordingly.

Hi Gregor,

Yes, I did that a few times:
<img src="getImg.php?text=whatever">
And generate the image on the fly with GD.

But I used that only when it actually adds some value (eg when the text
is used someway in the image), not for typeface only.

Anyway, we are talking about a solution to a non-existent problem again.
IMO it always looks crap, when headlines have some wildly different font
than the rest of the page.

I agree.
But sometimes you end up in a project where the decisions are made
elsewhere. Luckily I am my own boss, so I can always say 'bye bye' if
cashflow allows. ;-)

Regards,
Erwin Moller

Gregor

--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare

 

[David Mark]

I doubt anyone will be restricting this to small items People will
always abuse things; there's not much you can do about it (only block it
or "fix" it yourself)

I can't see using Canvas/VML for text.

Yep. That's the main problem with Cufon, as well as other
accessibility-related failures. I think they are working on support for
text selection.

Can't see that working reliably.

There's also a simple support for assistive devices
(i.e. original text is being hidden in such way that it is pronounced by
screen readers, but is not visible once canvas element is initialized).

Positioning it off-screen? That will break when CSS is disabled
(though not a big issue with this scheme.) In general, if a document
doesn't make sense when CSS is disabled (and scripting enabled), you
are hindering users of screen readers.

 

[David Mark]

I'm pretty sure there's a public demo available.





Yeah, that looks like a can of worms.





Indeed. I suppose both - regular text and the one generated with canvas
will be positioned right on top of each other. This will look confusing
of course, but it should be possible to offset original text *only* when
  CSS is available (i.e. detect CSS support via scripting).


Doesn't make sense visually? I don't see how it would hinder screen
readers. Could you give an example?

Think about it. If it takes something that blind users cannot
perceive (e.g. visual styling) to make sense of a document, they are
stuck with a representation that does not make sense. Browse around
the Web for a bit with CSS disabled (with or without scripting
enabled.) Text-only browsers (or simulators) are also useful for
learning about these issues.

Markup alone can demonstrate similar issues. Take Google's "My
Account" page. Turn off images and the menu reads:

AdsenseAdsense AnalyticsAnalytics GmailGmail, etc.

Now imagine an "unobtrusive" script that rearranges content assuming
that it will be able to hide and show elements. If the user can't
perceive these changes (for whatever reason), they can't make sense of
the interface and will likely give up on reading the document's
content. It's called progressive destruction.

For years I've heard "gurus" touting the accessibility of progressive
enhancement, but most only know scripted or not scripted. In reality,
the issue is not black and white. It's similar to (and often spouted
in the same breath) as claims that scripts like jQuery work in "all
browsers." Daffy delusions or deliberate deceptions, it's all
bullshit (but good enough for Google!)

 

[David Mark]

I'm pretty sure there's a public demo available.





Yeah, that looks like a can of worms.





Indeed. I suppose both - regular text and the one generated with canvas
will be positioned right on top of each other. This will look confusing
of course, but it should be possible to offset original text *only* when
  CSS is available (i.e. detect CSS support via scripting).


Doesn't make sense visually? I don't see how it would hinder screen
readers. Could you give an example?

I should also add that screen readers are a mixed bag (and sometimes
the term is used to describe aural browsers, which are another
story.) AFAIK, there are no real standards for these things, so the
developers do whatever they think is valid. Are they best used
without scripting and/or style? It's hard to generalize, but I'll bet
blind people have tried about everything to make sense of the
nonsensical Web.

Some good rules are:

- Test without scripting
- Test without style
- Test without scripting or style
- Test with text browsers and/or images disabled
- Test handheld and projector renderings (Opera is good for those)
- Related to the previous, be wary of media="screen" as it excludes
handheld, projector, tv, etc.
- Test print preview (and/or print the document.)
- Test at least one screen reader (Opera Voice is handy and supports a
handful of aural rules.)

Do all of this at the *design* stage or you will likely be in for some
nasty surprises down the road. And after all that, if it fits your
belief system, a few words of prayer can't hurt.

 

[Ahrjay]

Yep. That's the main problem with Cufon, as well as other
accessibility-related failures. I think they are working on support for
text selection. There's also a simple support for assistive devices
(i.e. original text is being hidden in such way that it is pronounced by
screen readers, but is not visible once canvas element is initialized).

Text selection actually already works on canvas supporting browsers
it's just that there is no visual feedback to the user that they are
selecting the text.

 

[David Mark]

Text selection actually already works on canvas supporting browsers
it's just that there is no visual feedback to the user that they are
selecting the text.

That's not working in the sense that it is usable.