sIFR: anti-aliased text in any font
December 29, 2004 11:36 AM Subscribe
Forget Verdana, here’s sIFR: anti-aliased text in your browser in any font you like.
The next big thing? Just a kludge? Heard about it already?
The next big thing? Just a kludge? Heard about it already?
Funny; I thought I already knew all I needed to know about this technique, but I hadn't checked in since the Werner/Cameron innovation. This new development is quite welcome.
posted by eustacescrubb at 11:47 AM on December 29, 2004
posted by eustacescrubb at 11:47 AM on December 29, 2004
Beautiful tool, but as smackfu mentions, it breaks usual copy-pastability. That's the downfall of flash sites, especially ones that rely on word-of-mouth for publicity. Word of mouth spreads faster when your text can be paste-bombed into blogs, IMs, and e-mails.
posted by NickDouglas at 11:52 AM on December 29, 2004
posted by NickDouglas at 11:52 AM on December 29, 2004
This is what it looks like. Try resizing your browser window and then hit reload to see sIFR adapt.
posted by Termite at 11:52 AM on December 29, 2004
posted by Termite at 11:52 AM on December 29, 2004
good idea (now i know why flashblock gives me "empty" movies on the ESPN website). but i do agree with the author that this sort of thing shouldn't be necessary.
if i can't have my flying car, can i at least have some class and fanciness for my web? we've got the technology but it hasn't been implemented. jakob neilsen be damned, usability is a good idea and all, but clean and interesting design shouldn't need to be this hard.
posted by caution live frogs at 11:56 AM on December 29, 2004
if i can't have my flying car, can i at least have some class and fanciness for my web? we've got the technology but it hasn't been implemented. jakob neilsen be damned, usability is a good idea and all, but clean and interesting design shouldn't need to be this hard.
posted by caution live frogs at 11:56 AM on December 29, 2004
It's a neat solution but it breaks more things than it solves. I can think of only a few instances I would want to use this.
posted by camworld at 11:57 AM on December 29, 2004
posted by camworld at 11:57 AM on December 29, 2004
Actually, you can copy and paste with this technique. No right-clicking though. Still, great use of Flash. It certainly beats using GIFs/PNGs for headline type.
posted by gwint at 12:01 PM on December 29, 2004
posted by gwint at 12:01 PM on December 29, 2004
I've always found it brilliant, but then, Shaun Inman and Mike Davidson are a brilliant men.
What I've found to be more exciting than the Flash technique itself is the way members of the design community have taken it and modified and improved it to create something that I'm fairly certain is more than just a passing trend. That evolution over the past year has been fascinating to experience. And, in the next year, I'm hoping that many of it's current bugs and issues will be solved.
This has been a hot topic in the design community for some time now with just about everyone weighing in on it's pros and cons and you give MetaFilter one link? ;)
Here's Shea's commentary and some facts and tips on how to use it.
posted by erisfree at 12:01 PM on December 29, 2004
What I've found to be more exciting than the Flash technique itself is the way members of the design community have taken it and modified and improved it to create something that I'm fairly certain is more than just a passing trend. That evolution over the past year has been fascinating to experience. And, in the next year, I'm hoping that many of it's current bugs and issues will be solved.
This has been a hot topic in the design community for some time now with just about everyone weighing in on it's pros and cons and you give MetaFilter one link? ;)
Here's Shea's commentary and some facts and tips on how to use it.
posted by erisfree at 12:01 PM on December 29, 2004
Fine and dandy for titling, but not for the entire text.
Aside from the many concerns my clients profess against Flash, money being one of them, processor speed at anything other than a gamer's box is considerably low, thus when one has many apps and browser windows open, things would slow to a crawl if there were a ton of embedded flashii on the pages. Been there, done that, not worth the trouble.
Progress is progress, yes, but until a complete solution is found, one that does not need a plugin, we'll still be making our titles out of gifs.
If Macromedia were halfway smart, they be developing a browser, instead of all the other BS they do.
posted by jsavimbi at 12:02 PM on December 29, 2004
Aside from the many concerns my clients profess against Flash, money being one of them, processor speed at anything other than a gamer's box is considerably low, thus when one has many apps and browser windows open, things would slow to a crawl if there were a ton of embedded flashii on the pages. Been there, done that, not worth the trouble.
Progress is progress, yes, but until a complete solution is found, one that does not need a plugin, we'll still be making our titles out of gifs.
If Macromedia were halfway smart, they be developing a browser, instead of all the other BS they do.
posted by jsavimbi at 12:02 PM on December 29, 2004
Jakob Nielsen is irrelevant to clean and interesting design. People who focus on demonizing him for paying attention to the details that interest him -- who insist on making it a personality issue -- fail to understand the real barriers to what they want.
As for sIFR, I love the results, but AFAIAC, any "standard" that relies on a proprietary format is a non-starter. At some point, I'll probably use it for someone who's paying me to use it and insists on this level of anal-retentiveness, but I doubt I'll ever use it for myself.
posted by lodurr at 12:04 PM on December 29, 2004
As for sIFR, I love the results, but AFAIAC, any "standard" that relies on a proprietary format is a non-starter. At some point, I'll probably use it for someone who's paying me to use it and insists on this level of anal-retentiveness, but I doubt I'll ever use it for myself.
posted by lodurr at 12:04 PM on December 29, 2004
more importantly, does it render the blink tag properly?
posted by evilgenius at 12:04 PM on December 29, 2004
posted by evilgenius at 12:04 PM on December 29, 2004
Wow, what a nightmare. Is there no concept of time in Flash? Are all delays accomplished by no-op loop? (Even if this is true, surely an animation can find out how much time has actually passed and skip frames accordingly, right?) I spent about three or four minutes waiting for the demo to do something and then gave up on it. It had got as far as saying "This text looks like garbage". I couldn't agree more.
Needless to say, any site that makes me wait several minutes for a pokey Flash animation isn't going to sell me on the idea of using Flash for basic text rendering.
posted by dreish at 12:06 PM on December 29, 2004
Needless to say, any site that makes me wait several minutes for a pokey Flash animation isn't going to sell me on the idea of using Flash for basic text rendering.
posted by dreish at 12:06 PM on December 29, 2004
You might also be interested in the previous discussion about sIFR on Whitespace. Always good design discussions there.
posted by erisfree at 12:06 PM on December 29, 2004
posted by erisfree at 12:06 PM on December 29, 2004
jsavimbi, I'm not sure that Macromedia aren't a bit more than halfway smart. Why should they expend time and energy developing a browser, when people keep using their "technology" to produce solutions like sIFR?
sIFR generates profits for Macromedia. Browser development would be a huge cost center.
Put another way: Macromedia benefits from the failure to fully implement decent web based layout. I'm not suggesting that they try to inhibit the processes -- I sincerely don't think they do -- but it's clear that the need for things like sIFR enhances sales of Flash.
FWIW, I've been telling people for a couple of years now that Macromedia are the way of the future -- if not the next Microsoft, then close to it. If they can't sell you a server, they can sell you an IDE that will work with yours. They are turning themselves into the IBM of the content delivery and management stream.
posted by lodurr at 12:09 PM on December 29, 2004
sIFR generates profits for Macromedia. Browser development would be a huge cost center.
Put another way: Macromedia benefits from the failure to fully implement decent web based layout. I'm not suggesting that they try to inhibit the processes -- I sincerely don't think they do -- but it's clear that the need for things like sIFR enhances sales of Flash.
FWIW, I've been telling people for a couple of years now that Macromedia are the way of the future -- if not the next Microsoft, then close to it. If they can't sell you a server, they can sell you an IDE that will work with yours. They are turning themselves into the IBM of the content delivery and management stream.
posted by lodurr at 12:09 PM on December 29, 2004
There’s an improved version 2.0 out. The headlines on the example page are clickable and you can right-click and copy them, but not together with the small text. (For me the example page works in IE but not in Firefox).
posted by Termite at 12:14 PM on December 29, 2004
posted by Termite at 12:14 PM on December 29, 2004
I loathe Flash for exactly the same reason web designers love it - it sacrifices usability for prettiness. I don't think web designers should get to use any font they damn well please. I surf the net for content, i.e., words and pictures. The fonts they come in shouldn't affect the content - in fact, they should pretty much be dictated on the client-side. But I'm not an artist.
lodurr is right in saying that Macromedia benefits from poor web standards and browser design.
On a side note, I use Proxomitron with JD5000's filter set that replaces all Flash animation with a toggle switch. That's not the only thing it does, of course ;)
posted by aerify at 12:24 PM on December 29, 2004
lodurr is right in saying that Macromedia benefits from poor web standards and browser design.
On a side note, I use Proxomitron with JD5000's filter set that replaces all Flash animation with a toggle switch. That's not the only thing it does, of course ;)
posted by aerify at 12:24 PM on December 29, 2004
Wait a minute. Didn't Netscape 4 have the feature of being able to embed fonts in webpages? I distinctly remember that, even though it appears to have fallen by the wayside.
posted by neckro23 at 12:25 PM on December 29, 2004
posted by neckro23 at 12:25 PM on December 29, 2004
No problem, Termite, it's just a topic I'm familiar with.
posted by erisfree at 12:36 PM on December 29, 2004
posted by erisfree at 12:36 PM on December 29, 2004
sIFR looks absurd when Flashblock is installed. A bunch of Play buttons where headlines should be, and me scratching my head wondering why there are so many ads on a page.
(For the record I'm not anti-Flash but Flash bogs down my Firefox on OS X so I deny by default and then show the stuff I'm interested in.)
posted by revgeorge at 12:42 PM on December 29, 2004
(For the record I'm not anti-Flash but Flash bogs down my Firefox on OS X so I deny by default and then show the stuff I'm interested in.)
posted by revgeorge at 12:42 PM on December 29, 2004
Wow, that's a lot of ADBLOCK buttons.
But, like any tricky new web technology, there is an appropriate time and place to use it... I'm definitely going to play around with this.
posted by hartsell at 12:44 PM on December 29, 2004
But, like any tricky new web technology, there is an appropriate time and place to use it... I'm definitely going to play around with this.
posted by hartsell at 12:44 PM on December 29, 2004
Ick. Let's take the most open, widely-supported, indexable and flexible aspect of the web and lock it into a proprietary, clunky, nasty, closed plug-in. My thesaurus does not have enough words for "stupid".
posted by gimonca at 12:51 PM on December 29, 2004
posted by gimonca at 12:51 PM on December 29, 2004
While yes, Flash is proprietary, has anyone viewed the source of the sIFR example pages? Now *that* is a beautiful (and deliciously standards-compliant) thing...at the very least, it's a huge improvement over the many image replacement techniques that the standards-approved crowd of Zeldman et al have been using for the past six months or more.
Plus it gracefully degrades to displaying regular CSS-styled text if either javascript or Flash aren't present. I'm finding it hard to dislike sIFR, if used in moderation and with some sense...
posted by flaneur at 12:56 PM on December 29, 2004
Plus it gracefully degrades to displaying regular CSS-styled text if either javascript or Flash aren't present. I'm finding it hard to dislike sIFR, if used in moderation and with some sense...
posted by flaneur at 12:56 PM on December 29, 2004
Netscape and IE had ways of embedding fonts but both companies dropped those non-compatible features long ago.
posted by infowar at 12:57 PM on December 29, 2004
posted by infowar at 12:57 PM on December 29, 2004
"I don't think web designers should get to use any font they damn well please"
I've read some dumb shit on Mefi but this one is a standout. And what about all those annoying 256 colors, do we really need all them?
The technology that has spawned sIFR will no doubt find usefullness in other areas of the web. I believe it's called progress Aerify. Yeah, at this point a waste of time for most users but everything has to start somewhere.
posted by j.p. Hung at 1:24 PM on December 29, 2004
I've read some dumb shit on Mefi but this one is a standout. And what about all those annoying 256 colors, do we really need all them?
The technology that has spawned sIFR will no doubt find usefullness in other areas of the web. I believe it's called progress Aerify. Yeah, at this point a waste of time for most users but everything has to start somewhere.
posted by j.p. Hung at 1:24 PM on December 29, 2004
You people would bitch if you were hung with a new rope.
posted by majcher at 1:26 PM on December 29, 2004
posted by majcher at 1:26 PM on December 29, 2004
Didn't Netscape 4 have the feature of being able to embed fonts in webpages?
Microsoft tried to get this passed by the w3, but they, being the Microsoft-fearing bastards they are, refused to make it a standardized process. Still, you can embed fonts in HTML, but it only works with Internet Explorer 4+. Here are detailed instructions in how to do this.
My thesaurus does not have enough words for "stupid".
Completely agreed.
posted by Civil_Disobedient at 1:33 PM on December 29, 2004
Microsoft tried to get this passed by the w3, but they, being the Microsoft-fearing bastards they are, refused to make it a standardized process. Still, you can embed fonts in HTML, but it only works with Internet Explorer 4+. Here are detailed instructions in how to do this.
My thesaurus does not have enough words for "stupid".
Completely agreed.
posted by Civil_Disobedient at 1:33 PM on December 29, 2004
"I don't think web designers should get to use any font they damn well please"
I've read some dumb shit on Mefi but this one is a standout.
Oh, please, give me a break. You know damn well that we'd be living in design hell if "web designers" could use any damn font they pleased at any damn resolution they pleased.
Repeat after me, children: THE WEB IS NOT PRINT. THE WEB IS ABOUT CONTENT.
When content is indivisible from presentation, that is usually, IMNSHO, a failure of design. There are occasional exceptions; but for all the successful marriages of presentation and idea that litter the design rags, there are hundreds and hundreds of failures.
Odinsdream: I actually set my default sans-serif to Comic Sans precisely so I can tell when someone isn't properly binding fonts to the page elements. It's a pet peeve of mine.
posted by lodurr at 1:54 PM on December 29, 2004
I've read some dumb shit on Mefi but this one is a standout.
Oh, please, give me a break. You know damn well that we'd be living in design hell if "web designers" could use any damn font they pleased at any damn resolution they pleased.
Repeat after me, children: THE WEB IS NOT PRINT. THE WEB IS ABOUT CONTENT.
When content is indivisible from presentation, that is usually, IMNSHO, a failure of design. There are occasional exceptions; but for all the successful marriages of presentation and idea that litter the design rags, there are hundreds and hundreds of failures.
Odinsdream: I actually set my default sans-serif to Comic Sans precisely so I can tell when someone isn't properly binding fonts to the page elements. It's a pet peeve of mine.
posted by lodurr at 1:54 PM on December 29, 2004
...I actually set my default sans-serif to Comic Sans precisely so I can tell when someone isn't properly binding fonts to the page elements. It's a pet peeve of mine.
You are a far braver man than I.
posted by flaneur at 2:18 PM on December 29, 2004
You are a far braver man than I.
posted by flaneur at 2:18 PM on December 29, 2004
As it is implemented in the above links, I think this technique is a bad idea. Although the code is clean, using JavaScript to rewrite portions of the page with Flash is still terrible for accessibility, because it ignores user-defined fonts and stylesheets. If odinsdream configures his browser to display everything in Verdana, and my parents want to see everything in 24pt bold, we as web designers should let them.
However, I think this could still be useful when the text in question is not content. (Sorry lodurr.)
posted by hartsell at 2:30 PM on December 29, 2004
However, I think this could still be useful when the text in question is not content. (Sorry lodurr.)
posted by hartsell at 2:30 PM on December 29, 2004
Repeat after me, children: THE WEB IS NOT PRINT. THE WEB IS ABOUT CONTENT
This implies that print is not about content?
posted by romanb at 2:32 PM on December 29, 2004
This implies that print is not about content?
posted by romanb at 2:32 PM on December 29, 2004
"Content" needs to be clarified. The net is made for shuffling bytes around. Those are the content. All the other stuff are poorly-thought-out ad-hoc protocols and formats stacked in an ever-higher tower. sIFR is a program written in Flash, embedded with ActiveX into an HTML document which is rewritten with Javascript. We're talking four or five layers above the application layer (web browser.)
Pick out the robust, well-defined protocols in the above. Funny things will go wrong in the others. The hacker in me thinks this is very neat, but the web surfer in me wants to weep at the thought of using this Rube Goldberg machine to read 1k of text.
(ob: Flash and Javascript have improved about 300% in the last 3 years, so I'm not really complaining. When the Metaverse arrives, we'll all have beautiful type.)
posted by sonofsamiam at 2:57 PM on December 29, 2004
Pick out the robust, well-defined protocols in the above. Funny things will go wrong in the others. The hacker in me thinks this is very neat, but the web surfer in me wants to weep at the thought of using this Rube Goldberg machine to read 1k of text.
(ob: Flash and Javascript have improved about 300% in the last 3 years, so I'm not really complaining. When the Metaverse arrives, we'll all have beautiful type.)
posted by sonofsamiam at 2:57 PM on December 29, 2004
Flash has its purposes, but it is a poor substitute for a browser's native abilities. For instance, can I scale the Flash-fonts? In Firefox, this is trivial (CTRL + mouse wheel). And how about speed? If you've ever used the lame scroll-panels in Flash on a slow computer, you'll quickly appreciate built-in OS widgets.
posted by Civil_Disobedient at 3:12 PM on December 29, 2004
posted by Civil_Disobedient at 3:12 PM on December 29, 2004
You people would bitch if you were hung with a new rope.
Indeed. People seem to be turning a small, useful tool into a fight for the Web's soul. The main purpose of sIFR, from my understanding, is to give the designer just a little more control over typography. Make those headers look perfect. Give the page a little more style. Have some fonts match your corporate identity while still retaining the ability to scale and copy. sIFR does those things very well.
If you truly believe graphic design has no place on the web, use lynx and shut the hell up.
posted by gwint at 3:48 PM on December 29, 2004
Indeed. People seem to be turning a small, useful tool into a fight for the Web's soul. The main purpose of sIFR, from my understanding, is to give the designer just a little more control over typography. Make those headers look perfect. Give the page a little more style. Have some fonts match your corporate identity while still retaining the ability to scale and copy. sIFR does those things very well.
If you truly believe graphic design has no place on the web, use lynx and shut the hell up.
posted by gwint at 3:48 PM on December 29, 2004
I think someone's still upset that they only had the 8 color box of crayons when all the other kids had 64.
You're web may be only about content but my web is about many other things, including "experience".
...but mostly porn and mp3s
posted by Mick at 3:56 PM on December 29, 2004
You're web may be only about content but my web is about many other things, including "experience".
...but mostly porn and mp3s
posted by Mick at 3:56 PM on December 29, 2004
Flash and Javascript have improved about 300% in the last 3 years
300% of an infinitesimal amount is.....a very slightly larger, but infinitesimal amount.
Make those headers look perfect. Give the page a little more style. Have some fonts match your corporate identity while still retaining the ability to scale and copy.
Higher production costs and more brittle, breakable pages with virtually no added value. Bad business decision. Good for "graphic designers" who bill by the hour; bad for everyone else.
posted by gimonca at 4:05 PM on December 29, 2004
300% of an infinitesimal amount is.....a very slightly larger, but infinitesimal amount.
Make those headers look perfect. Give the page a little more style. Have some fonts match your corporate identity while still retaining the ability to scale and copy.
Higher production costs and more brittle, breakable pages with virtually no added value. Bad business decision. Good for "graphic designers" who bill by the hour; bad for everyone else.
posted by gimonca at 4:05 PM on December 29, 2004
Repeat after me, children: THE WEB IS NOT PRINT. THE WEB IS ABOUT CONTENT.
No more than print is about content. Both can be about more than content without sacrificing the content.
If someone wants to make what you deem to be an ugly website, why shouldn't they be free to do so?
posted by rushmc at 4:12 PM on December 29, 2004
No more than print is about content. Both can be about more than content without sacrificing the content.
If someone wants to make what you deem to be an ugly website, why shouldn't they be free to do so?
posted by rushmc at 4:12 PM on December 29, 2004
I like this idea and I think I'll try it on a site soon, but I actually think I'd prefer generated gif / png files with proper alt / title tags (and within the right semantic markup, of course), if you can get the php font dealie to behave. A flash file with an embedded font is probably bigger or equal to a gif or png of a single title, so I'm not sure there's a huge bandwidth savings, especially when the javascript's considered too. But then, like I said, I might give this a shot.
posted by condour75 at 4:38 PM on December 29, 2004
posted by condour75 at 4:38 PM on December 29, 2004
Huh? What's the innovation here? Replace some text on the page with a fucking SWF file? Woo.... hoo? I don't see the value of this. if you want things to look nice in the browser, use a browser that makes things look nice!
posted by majick at 4:38 PM on December 29, 2004
posted by majick at 4:38 PM on December 29, 2004
This is turning into a typical sIFR comments page, with people who don't understand the technology wading in with their "Flash is bad", and "proprietary, clunky, nasty, closed plug-in" opinions.
For the record, I am the author of the How and when to use sIFR article referenced by Eris above. If you can't see why sIFR is important - then go and read it.
I am resisting the temptation to repeat everything I have written at UsableType, but...
Many designers will never need to implement a solution like sIFR. Many designers have never developed sites where hundreds of dynamically created pages are added daily and a corporate typeface is required. Those that have, will instantly see the advantages of sIFR over dynamically generating images or any other current methods.
As for "higher production costs", why do you think IFR was developed in the first place? To reduce costs of course: by reducing server load and bandwidth.
posted by andyhume at 4:39 PM on December 29, 2004
For the record, I am the author of the How and when to use sIFR article referenced by Eris above. If you can't see why sIFR is important - then go and read it.
I am resisting the temptation to repeat everything I have written at UsableType, but...
Many designers will never need to implement a solution like sIFR. Many designers have never developed sites where hundreds of dynamically created pages are added daily and a corporate typeface is required. Those that have, will instantly see the advantages of sIFR over dynamically generating images or any other current methods.
As for "higher production costs", why do you think IFR was developed in the first place? To reduce costs of course: by reducing server load and bandwidth.
posted by andyhume at 4:39 PM on December 29, 2004
"weep at the thought of using this Rube Goldberg machine to read 1k of text."
Not 1k of text. It's for magically replacing headlines (which apparently don't render well in some browsers) with SWF. So, you're reading, what, 30 bytes of text?
posted by majick at 4:42 PM on December 29, 2004
Not 1k of text. It's for magically replacing headlines (which apparently don't render well in some browsers) with SWF. So, you're reading, what, 30 bytes of text?
posted by majick at 4:42 PM on December 29, 2004
One sentence above should of course read:
"...and a corporate typeface is required for titles or headings."
I'm not advocating using this for body text!!
posted by andyhume at 4:42 PM on December 29, 2004
"...and a corporate typeface is required for titles or headings."
I'm not advocating using this for body text!!
posted by andyhume at 4:42 PM on December 29, 2004
hehe, point "Mike".
Incidentally, it looks like Metafilter has picked up on sIFR today and is sending over a ton of traffic to the original sIFR article. Reading the Metafilter comment thread is a bit humorous. It never ceases to amaze me how some people will see the word “Flash” and cry about imaginary accessibility issues, imaginary proprietary file format issues, and other imaginary “sky is falling” issues. Look at the code people. Study it. Analyze it. Understand it before you jump to conclusions. And above all else, understand that the entire web as we know it is a hack. I’d respond on the Metafilter thread myself but I don’t feel like paying $5 to join.posted by wah at 4:44 PM on December 29, 2004
Well, thanks for that, andy! I'm not trying to pick a fight here, but at what point does
I don't think the issue is with people who "don't understand the technology" -- I could implement this myself having now read a general description -- but with people who don't think Your Corporate (oo! so important!) Decision About Your Fancypants Font merits anything so drastic as slapping people around with Flash.
posted by majick at 4:49 PM on December 29, 2004
"The scenario: A large sports news website decides to style all their headlines in a unique corporate typeface."translate to "it is a good idea to shove semi-optional binary data at the user" rather than "we don't get the web, we don't get the web, we do not understand the purpose of the web"?
I don't think the issue is with people who "don't understand the technology" -- I could implement this myself having now read a general description -- but with people who don't think Your Corporate (oo! so important!) Decision About Your Fancypants Font merits anything so drastic as slapping people around with Flash.
posted by majick at 4:49 PM on December 29, 2004
A web developer (to a certain extent) is required to deliver what the client needs. What would you do in that situation? Sit them down and tell them, "you don't get the web, you don't get the web, you don't understand the purpose of the web"?
Can we have a rational discussion, rather than a "sky is falling" one? What's wrong with sIFR, majick?
And it's "semi-optional binary data" doesn't count, OK?
posted by andyhume at 5:01 PM on December 29, 2004
Can we have a rational discussion, rather than a "sky is falling" one? What's wrong with sIFR, majick?
And it's "semi-optional binary data" doesn't count, OK?
posted by andyhume at 5:01 PM on December 29, 2004
Oh, and it seems to add about 10k to page weight. If I were to put this on my Large Corporate Image-Conscious Marketing-Driven employer's Highly Visible Web Site, I would be risking getting canned just for spending the 10k in APW even if we offloaded the heavy stuff to Akamai.
"What would you do in that situation? Sit them down and tell them, [the nanny-nanny boo boo rant]"
Yeah. That's what I'm getting paid for. If my current employer wants Shut-Up-And-Implement service, they can farm the project out to the team in India . They're inexpensive and have been doing a pretty good job. If they want a serious discussion about doing the Right Thing, they ask me.
There seem to be two different web development models. One is purely client driven, the client delivers a spec, the developer turns it around, gets paid. For something like this, I suppose replacing headlines with 10k of JavaScript and Flash might sell some contracts and probably leave some customers pretty pleased.
In the other model, the client (my employer, for example) wants an optimal solution and wants someone who can tell them "you're crazy, that's a waste of time, money, and architectural robustness".
I try to contstrain myself to the latter category as I find the work more satisfying and suited to my curmudgeonliness.
So what's wrong with sIFR? The fundamental assumption that it's actually a good idea to put more Flash on the page for what are, essentially, static elements. It's not. Seriously. Rendering is the browser's job.
I realize that sIFR has left all the right escape hatches in place for both technical and curmudgeon-compatibility. They're clever, fiendishly clever. Except that I shouldn't have to dodge yet another binary that's going to kick off yet another Flash thread that's going to hang yet another browser window just because you want your headline font.
The utility of this thing is limited, at an unknown cost to robustness. It's not a tradeoff I would make.
posted by majick at 5:21 PM on December 29, 2004
"What would you do in that situation? Sit them down and tell them, [the nanny-nanny boo boo rant]"
Yeah. That's what I'm getting paid for. If my current employer wants Shut-Up-And-Implement service, they can farm the project out to the team in India . They're inexpensive and have been doing a pretty good job. If they want a serious discussion about doing the Right Thing, they ask me.
There seem to be two different web development models. One is purely client driven, the client delivers a spec, the developer turns it around, gets paid. For something like this, I suppose replacing headlines with 10k of JavaScript and Flash might sell some contracts and probably leave some customers pretty pleased.
In the other model, the client (my employer, for example) wants an optimal solution and wants someone who can tell them "you're crazy, that's a waste of time, money, and architectural robustness".
I try to contstrain myself to the latter category as I find the work more satisfying and suited to my curmudgeonliness.
So what's wrong with sIFR? The fundamental assumption that it's actually a good idea to put more Flash on the page for what are, essentially, static elements. It's not. Seriously. Rendering is the browser's job.
I realize that sIFR has left all the right escape hatches in place for both technical and curmudgeon-compatibility. They're clever, fiendishly clever. Except that I shouldn't have to dodge yet another binary that's going to kick off yet another Flash thread that's going to hang yet another browser window just because you want your headline font.
The utility of this thing is limited, at an unknown cost to robustness. It's not a tradeoff I would make.
posted by majick at 5:21 PM on December 29, 2004
I love the comments from people who comment before they know what the hell they are even talking about. sIFR is brilliant. It's not Flash, it's a font exported as a .swf file that can then be dynamically rendered as anything (headlines are the most obvious). It is a way of embedding fonts that is extremely lightweight. SWF is not Flash.
Here is an hour long Breeze presentation on sIFR from Macromedia and a good article on Why sIFR Matters.
posted by spock at 5:23 PM on December 29, 2004
Here is an hour long Breeze presentation on sIFR from Macromedia and a good article on Why sIFR Matters.
posted by spock at 5:23 PM on December 29, 2004
I stumbled on this, like, yesterday. How serendipitous.
I don't think I'll use it except maybe to play around with a bit, but I like things that are fiendishly clever, which, as makick says, this is.
posted by stavrosthewonderchicken at 5:36 PM on December 29, 2004
I don't think I'll use it except maybe to play around with a bit, but I like things that are fiendishly clever, which, as makick says, this is.
posted by stavrosthewonderchicken at 5:36 PM on December 29, 2004
10k to page weight once. The .js and .swf files need only be downloaded once to be used on thousands of headlines.
However...
You are right about two current web development models. I guess it comes down to your fundamental feelings about the web and the way it should be going.
Generating Flash headlines is one massive hack, of course it is. But no more so than any of the dozens of techniques that makes the web look like it is today. Tables for layout? Image replacement? etc... None of it is good.
But I still haven't heard one good reason against using sIFR in the right situation apart from that it goes against an idealistic philosophy.
posted by andyhume at 5:39 PM on December 29, 2004
However...
You are right about two current web development models. I guess it comes down to your fundamental feelings about the web and the way it should be going.
Generating Flash headlines is one massive hack, of course it is. But no more so than any of the dozens of techniques that makes the web look like it is today. Tables for layout? Image replacement? etc... None of it is good.
But I still haven't heard one good reason against using sIFR in the right situation apart from that it goes against an idealistic philosophy.
posted by andyhume at 5:39 PM on December 29, 2004
As far as weight is concerned it is far lighter than your previous option of using gifs or jpegs for typographical headlines ... the sifr.js file (which does all the work) is a 12K file (and is cached after the first load, right?). The individual font files are only 8K - 16K each (and if you are smart you are probably only using ONE of them, not SIX as in the example page). The added code on the page is next to nothing. The bandwidth savings can be HUGE for a high traffic site.
posted by spock at 5:39 PM on December 29, 2004
posted by spock at 5:39 PM on December 29, 2004
The release candidate 3 has dropped the sifr.js to 8.8K.
Micheal Davidson has some comments for ignorant metafilter commenters on the RC3 page:
"Reading the Metafilter comment thread is a bit humorous, however. It never ceases to amaze me how some people will see the word “Flash” and cry about imaginary accessibility issues, imaginary proprietary file format issues, and other imaginary “sky is falling” issues. Look at the code people. Study it. Analyze it. Understand it before you jump to conclusions. And above all else, understand that the entire web as we know it is a hack. I’d respond on the Metafilter thread myself but I don’t feel like paying $5 to join."
posted by spock at 5:44 PM on December 29, 2004
Micheal Davidson has some comments for ignorant metafilter commenters on the RC3 page:
"Reading the Metafilter comment thread is a bit humorous, however. It never ceases to amaze me how some people will see the word “Flash” and cry about imaginary accessibility issues, imaginary proprietary file format issues, and other imaginary “sky is falling” issues. Look at the code people. Study it. Analyze it. Understand it before you jump to conclusions. And above all else, understand that the entire web as we know it is a hack. I’d respond on the Metafilter thread myself but I don’t feel like paying $5 to join."
posted by spock at 5:44 PM on December 29, 2004
hrm, am I missing something? on the example page, and several sites that have implemented it, I have no problems in Firefox 1.0F on winxp copy/pasting this stuff. I can take whole paragraphs and get the headlines in there too...either right-click to copy (full contextual menu) or good ol' ctrl-c. I can highlight a part of a sIFR headline and right-click or ctrl-c again (tho in this example I get a slimmed down contextual menu...just cut/copy/paste/delete and select all, which only selects the headline).
versions from the 1914 translation by H. Rackham.
The Quick Brown Fox Jumps Over the Lazy Dog
The standard chunk of Lorem Ipsum used
While the highlighting is a touch unclear (parts of the sIFR headline will be highlighted, others not) the whole text comes through (see above, formatting added for emphasis with empty lines removed).
I think this is an awesome use of flash...it adds a whole new dimension for developers and is quite discreet...that is, if you dont have flash/js, you dont see it (how much easier can it be?) just the old style page. Kudos to Mr. Davidson et all for the innovation...I'll be playing around with this all weekend.
posted by gren at 6:06 PM on December 29, 2004
versions from the 1914 translation by H. Rackham.
The Quick Brown Fox Jumps Over the Lazy Dog
The standard chunk of Lorem Ipsum used
While the highlighting is a touch unclear (parts of the sIFR headline will be highlighted, others not) the whole text comes through (see above, formatting added for emphasis with empty lines removed).
I think this is an awesome use of flash...it adds a whole new dimension for developers and is quite discreet...that is, if you dont have flash/js, you dont see it (how much easier can it be?) just the old style page. Kudos to Mr. Davidson et all for the innovation...I'll be playing around with this all weekend.
posted by gren at 6:06 PM on December 29, 2004
"10k to page weight once."
As someone who has come up against millions of page views of what are inarguably fairly complex web pages, I'm extremely confident in saying that trusting the browser cache is an extremely bad idea. This is a good first approximation, but that's all it is. In reality, I'd change "once" to a rough factor of "one and a third times," modulo how much AOL cached traffic you expect.
"SWF is not Flash."
This is disingenuous. The thrust of the argument is that "Flash" is a suite of authoring software, and SWF is a file format. That's great, except the only widely distributed interpreter of SWF data is something called the "Macromedia Flash Player," and SWF content has been commonly called "Flash" for quite a long time. In the end, a thread is going to run some (in my experience, especially shoddy) Macromedia code if you throw SWF at the browser.
"other imaginary 'sky is falling' issues."
At no point am I claiming the sky is falling. I'm claiming that the sort of thinking that leads people to want to ram their fonts down the browser's throat -- even with fiendishly clever browser tricks -- is wrongheaded. If you want falling sky rants, I'll rail about how this is one more tiny step towards turning the web over to Big Corporate Content. But I'll spare everyone, since in then end that's all speculation on my part.
"And above all else, understand that the entire web as we know it is a hack."
I'm not sure I can dignify this with an appropriate response, other than to call it incorrect. sIFR is a (fiendishly clever) hack. The entire web as brochureware designers know it is a hack. The rest of us see it as a relatively mature, extremely well specified, open platform.
Now, I'd go so far as to say that most of the major browsers are hacks, but that's mostly to support the bad things brochureware designers are doing and some early markup language ambiguity. The web is not your browser.
posted by majick at 6:29 PM on December 29, 2004
As someone who has come up against millions of page views of what are inarguably fairly complex web pages, I'm extremely confident in saying that trusting the browser cache is an extremely bad idea. This is a good first approximation, but that's all it is. In reality, I'd change "once" to a rough factor of "one and a third times," modulo how much AOL cached traffic you expect.
"SWF is not Flash."
This is disingenuous. The thrust of the argument is that "Flash" is a suite of authoring software, and SWF is a file format. That's great, except the only widely distributed interpreter of SWF data is something called the "Macromedia Flash Player," and SWF content has been commonly called "Flash" for quite a long time. In the end, a thread is going to run some (in my experience, especially shoddy) Macromedia code if you throw SWF at the browser.
"other imaginary 'sky is falling' issues."
At no point am I claiming the sky is falling. I'm claiming that the sort of thinking that leads people to want to ram their fonts down the browser's throat -- even with fiendishly clever browser tricks -- is wrongheaded. If you want falling sky rants, I'll rail about how this is one more tiny step towards turning the web over to Big Corporate Content. But I'll spare everyone, since in then end that's all speculation on my part.
"And above all else, understand that the entire web as we know it is a hack."
I'm not sure I can dignify this with an appropriate response, other than to call it incorrect. sIFR is a (fiendishly clever) hack. The entire web as brochureware designers know it is a hack. The rest of us see it as a relatively mature, extremely well specified, open platform.
Now, I'd go so far as to say that most of the major browsers are hacks, but that's mostly to support the bad things brochureware designers are doing and some early markup language ambiguity. The web is not your browser.
posted by majick at 6:29 PM on December 29, 2004
Micheal Davidson has failed to address my point, but of course he would, because my point still stands.
Can you dynamically resize the text of the embedded SWF? Because just about every browser on the planet has this ability.
Get it through your fucking head: this isn't just about your c00l l33t font, oh great d3sign3r king. It's also about a little thing called accessibility. Many people have to use larger font sizes because they have difficulty seeing. How does the embedded SWF option scale when the rest of the text on the screen increases in size?
posted by Civil_Disobedient at 6:36 PM on December 29, 2004
Can you dynamically resize the text of the embedded SWF? Because just about every browser on the planet has this ability.
Get it through your fucking head: this isn't just about your c00l l33t font, oh great d3sign3r king. It's also about a little thing called accessibility. Many people have to use larger font sizes because they have difficulty seeing. How does the embedded SWF option scale when the rest of the text on the screen increases in size?
posted by Civil_Disobedient at 6:36 PM on December 29, 2004
Civil_Disobedient, this is from the "How and When to Use sIFR" article that has now been posted twice in this thread:
* sIFR does not require any changes to the (X)HTML code, all the work is done by Javascript, Flash and CSS.
* If the user does not have Flash installed or Javascript enabled then the (X)HTML text is displayed and styled by CSS.
* sIFR is scalable, and when rendered will adjust to the users font size settings.
* sIFR is compatible with all screen readers. No problems or issues have ever been reported.
* sIFR text is selectable with the mouse, although visual confirmation of the selection may be absent when selected with body text.
* sIFR does not affect search engine placement or ranking, nor does it hide textual content from search engines or users.
posted by erisfree at 6:47 PM on December 29, 2004
* sIFR does not require any changes to the (X)HTML code, all the work is done by Javascript, Flash and CSS.
* If the user does not have Flash installed or Javascript enabled then the (X)HTML text is displayed and styled by CSS.
* sIFR is scalable, and when rendered will adjust to the users font size settings.
* sIFR is compatible with all screen readers. No problems or issues have ever been reported.
* sIFR text is selectable with the mouse, although visual confirmation of the selection may be absent when selected with body text.
* sIFR does not affect search engine placement or ranking, nor does it hide textual content from search engines or users.
posted by erisfree at 6:47 PM on December 29, 2004
Funny, it didn't adjust for me.
posted by Civil_Disobedient at 6:50 PM on December 29, 2004
posted by Civil_Disobedient at 6:50 PM on December 29, 2004
When the page is loaded the text scales to the users font settings. If the settings are changed then the javscript needs to be called again, the font size redefined and sent to Flash: so a refresh is required.
posted by andyhume at 7:02 PM on December 29, 2004
posted by andyhume at 7:02 PM on December 29, 2004
I heard about sIFR couple of weeks ago and while impressed, wasn't too impressed. Then I read Mike Davidson's Introducing sIFR, played the demo movie and drooled like a design fanboy. It's cool. It's not a total fix, but it's a great tool.
And that, I think, is the problem.
Like the initial introduction of tables, people are going to use sIFR for all sorts of things it wasn't intended to do and 5 years from now we're going to have to redo pages for when the css equivalent of rich type finally hits the web. sIFR is fine tool for limited uses, but how many designers are just going to use for those few uses?
sIFR is a Band-Aid. It's one of those colorful, Walt Disney bandaids that you thought was kooool as a kid, but it's still a band aid.
When is the web going to be fixed so we don't have to hack it in order to get rich type? And for those who question "does the web need rich type", I'll be first to say, No, it doesn't need it. But it can look really good with it, so lets do it.
Still, as a primarily print designer, I can't help but wonder why the open source nature of the web hasn't produced the web equivalent of Postscript (the page description language which made desktop publishing and fonts BIG TIME). It seems like the wheel is being reinvented which frustrates the hell outta me as a print designer: these problems have been solved, can't we learn from those solutions and adapt them to this need medium?
It should be noted that web growth shows no sign of stopping despite the lack of rich text controls. Food for thought, eh?
Yeah, this is an idealistic philosophy, but I always liked the idea behind The Dao of Web Design. sIFR is good, but perhaps we should look deeper to solve this "problem".
posted by Brandon Blatcher at 7:08 PM on December 29, 2004
And that, I think, is the problem.
Like the initial introduction of tables, people are going to use sIFR for all sorts of things it wasn't intended to do and 5 years from now we're going to have to redo pages for when the css equivalent of rich type finally hits the web. sIFR is fine tool for limited uses, but how many designers are just going to use for those few uses?
sIFR is a Band-Aid. It's one of those colorful, Walt Disney bandaids that you thought was kooool as a kid, but it's still a band aid.
When is the web going to be fixed so we don't have to hack it in order to get rich type? And for those who question "does the web need rich type", I'll be first to say, No, it doesn't need it. But it can look really good with it, so lets do it.
Still, as a primarily print designer, I can't help but wonder why the open source nature of the web hasn't produced the web equivalent of Postscript (the page description language which made desktop publishing and fonts BIG TIME). It seems like the wheel is being reinvented which frustrates the hell outta me as a print designer: these problems have been solved, can't we learn from those solutions and adapt them to this need medium?
It should be noted that web growth shows no sign of stopping despite the lack of rich text controls. Food for thought, eh?
Yeah, this is an idealistic philosophy, but I always liked the idea behind The Dao of Web Design. sIFR is good, but perhaps we should look deeper to solve this "problem".
posted by Brandon Blatcher at 7:08 PM on December 29, 2004
I'm gonna leave now (I think I've got my $5 worth in) so perhaps I won't have the final say on this here but...
To anyone still reading this thread who is new to sIFR, it is something you must look in to despite the difference of opinion here. It may be for you and it may not be - but don't rule it out.
It's not a question of ASCII vs. Binary or anything else these purist engineers will spout about what the web should be. It is about progress towards making the web the best it can be. If we wait for the W3C to dish out new specs, and the browser makers to implement them, we will be stuck in the current web for for the next 10 years.
The views of majick (despite their good intentions) come across as arrogant. It's a proclomation that something is evil because he himself doesn't use it... simple as that. Why go so far as to say that it's bad for everyone? If it was, clearly no one would be even interested in it.
Oh, and Brandon who's just popped in:
I think you are absolutely right about this being a stop gap technology. As I've said before, it's a hack. However, it's not a hack that is gonna do us any harm in the future. sIFR places presentation on top of a structurally and semantically built document; it will be no problem removing it once a true solution comes our way.
posted by andyhume at 7:39 PM on December 29, 2004
To anyone still reading this thread who is new to sIFR, it is something you must look in to despite the difference of opinion here. It may be for you and it may not be - but don't rule it out.
It's not a question of ASCII vs. Binary or anything else these purist engineers will spout about what the web should be. It is about progress towards making the web the best it can be. If we wait for the W3C to dish out new specs, and the browser makers to implement them, we will be stuck in the current web for for the next 10 years.
The views of majick (despite their good intentions) come across as arrogant. It's a proclomation that something is evil because he himself doesn't use it... simple as that. Why go so far as to say that it's bad for everyone? If it was, clearly no one would be even interested in it.
Oh, and Brandon who's just popped in:
I think you are absolutely right about this being a stop gap technology. As I've said before, it's a hack. However, it's not a hack that is gonna do us any harm in the future. sIFR places presentation on top of a structurally and semantically built document; it will be no problem removing it once a true solution comes our way.
posted by andyhume at 7:39 PM on December 29, 2004
Arrogant is chuffing 10k down the pipe to make your 25 character headline especially fancy if the end user has the right version of the right proprietary software.
I had hoped to keep this from sinking further into the quagmire of a slugfest; hopefully I've managed to convey the (apparently now unhip) notion that one of the best things about the web is that I, and I alone, control how it looks. For me. sIFR, in most cases, takes a little bit of that away.
Never let it be said I don't appreciate the cleverness. I just can't see the value of running the end user through a known-rickety code path for the sake of a headline font. Certainly not in a production application. What clever hacks people want to put on their home page is purely a matter of individual choice.
In any case, thanks, Andy, for popping in and informing us, and above all, keeping a level head in the face of arrogant trolls.
posted by majick at 8:08 PM on December 29, 2004
I had hoped to keep this from sinking further into the quagmire of a slugfest; hopefully I've managed to convey the (apparently now unhip) notion that one of the best things about the web is that I, and I alone, control how it looks. For me. sIFR, in most cases, takes a little bit of that away.
Never let it be said I don't appreciate the cleverness. I just can't see the value of running the end user through a known-rickety code path for the sake of a headline font. Certainly not in a production application. What clever hacks people want to put on their home page is purely a matter of individual choice.
In any case, thanks, Andy, for popping in and informing us, and above all, keeping a level head in the face of arrogant trolls.
posted by majick at 8:08 PM on December 29, 2004
sIFR does not affect search engine placement or ranking
Funny, I did a Google search on Pedro Martinez, and the only ESPN hits that turned up in the first 6-7 pages of results are two that don't use sIFR. There's Pedro's banner, in a homely old non-anti-aliased SPAN that, mirabile dictu, seems to have been indexed much better.
It's a proclomation that something is evil because he himself doesn't use it
Pot, kettle, black.
posted by gimonca at 8:17 PM on December 29, 2004
Funny, I did a Google search on Pedro Martinez, and the only ESPN hits that turned up in the first 6-7 pages of results are two that don't use sIFR. There's Pedro's banner, in a homely old non-anti-aliased SPAN that, mirabile dictu, seems to have been indexed much better.
It's a proclomation that something is evil because he himself doesn't use it
Pot, kettle, black.
posted by gimonca at 8:17 PM on December 29, 2004
sIFR is compatible with all screen readers. No problems or issues have ever been reported.
Starts up ZoomText, hits *dictate*.. beep.. nothing.
of course, tihs isn't a formal "report", so I'm sure this little bullet point will stlil be there despite the fact that it isn't true.
posted by Space Coyote at 8:22 PM on December 29, 2004
Starts up ZoomText, hits *dictate*.. beep.. nothing.
of course, tihs isn't a formal "report", so I'm sure this little bullet point will stlil be there despite the fact that it isn't true.
posted by Space Coyote at 8:22 PM on December 29, 2004
I'm looking at ESPN's actual site...
This page has a headline in Flash. Firefox 0.9.1 on WinXP, increase or decrease text size affects most text on the page, does not change the size of the Flash headline at all.
posted by gimonca at 8:53 PM on December 29, 2004
This page has a headline in Flash. Firefox 0.9.1 on WinXP, increase or decrease text size affects most text on the page, does not change the size of the Flash headline at all.
posted by gimonca at 8:53 PM on December 29, 2004
Without criticizing this font thingy, javascript, Flash in general, or anyone on either side of this argument, here's my take: I have much greater respect for web developers who create beautiful sites within the onerous limitations of clean, usable, cross-browser design. Sure, you can do all kinds of "fiendishly clever" things with Flash and javascript and anything else that limits your potential audience, and sometimes you just have to. But it's not something you should be proud of, roughly the same way filming a stage play shouldn't make a movie director proud of his mastery of the cinema.
This, incidentally, is why our host Mr. Owie is so highly regarded.
posted by rusty at 10:20 PM on December 29, 2004
This, incidentally, is why our host Mr. Owie is so highly regarded.
posted by rusty at 10:20 PM on December 29, 2004
God, another attack of "the enemy of good is perfect" metafilter crowd. You know what. Don't fucking tell me how to design my webpages. I kinda think this thing is cool. I might not put any content in it, but if I wanted a title to look shnazy and anti-aliased, I might use it. If your one of the infinitesimal curmudgeons who worked hard to uninstall flash then you'll see the alternate browser rendered text.
If you've setup some contraption to filter all flash files and show goatsx anuses to stick it to all the ad-supported sites because information I worked on all fucking night "wants to be free, man" then fuck you.
If you don't visit sites because they don't validate XHTML and uses tables (gasp!) for layout, fuck you.
If you shit upon other peoples work that they do for free to help out their fellow fucking man, who have tried hard to address both usability and the real fucking world where 99.999% of people could give two craps about the "semantic web" and sometimes judge a site on whether it looks, you know, professional, then....
Well, I've gone and lost my train of thought, but I think the point of it was, fuck you, you luddite holier than thou self appointed police of right and wrong on the web.
So, besides all that, there are some good points here, namely, that in the real world of web tools and tricks, there are no absolutes, and getting religious about things is stupid. There are best practices, and admittedly, those I just railed against iterated many of them. But best practices are guidelines and breaking them is not felony, and if you know what your doing, and your smart, breaking them can be just the right thing to do.
posted by PissOnYourParade at 11:17 PM on December 29, 2004
If you've setup some contraption to filter all flash files and show goatsx anuses to stick it to all the ad-supported sites because information I worked on all fucking night "wants to be free, man" then fuck you.
If you don't visit sites because they don't validate XHTML and uses tables (gasp!) for layout, fuck you.
If you shit upon other peoples work that they do for free to help out their fellow fucking man, who have tried hard to address both usability and the real fucking world where 99.999% of people could give two craps about the "semantic web" and sometimes judge a site on whether it looks, you know, professional, then....
Well, I've gone and lost my train of thought, but I think the point of it was, fuck you, you luddite holier than thou self appointed police of right and wrong on the web.
So, besides all that, there are some good points here, namely, that in the real world of web tools and tricks, there are no absolutes, and getting religious about things is stupid. There are best practices, and admittedly, those I just railed against iterated many of them. But best practices are guidelines and breaking them is not felony, and if you know what your doing, and your smart, breaking them can be just the right thing to do.
posted by PissOnYourParade at 11:17 PM on December 29, 2004
If you want your or your client's page headlines to be replaced with plugin placeholders asking me to approve a plugin in that location, by all means, use this technology. If you want to piss off people who want to dynamically resize text and select it without jumping through hoops, you can use it too.
I know the poor choice of fonts and lack of font download is a problem on many platforms, but this is too much of a hack to be useful. Though the hack itself is impressive, yeah.
posted by azazello at 11:38 PM on December 29, 2004
I know the poor choice of fonts and lack of font download is a problem on many platforms, but this is too much of a hack to be useful. Though the hack itself is impressive, yeah.
posted by azazello at 11:38 PM on December 29, 2004
Whoa, piss, a little hostile there, huh?
Tell you what, you can design your webpages the way you want, and I'll view other webpages the way I want, OK? And when I stumble upon the train wreck that your page will be in my browser, I will just close that window.
posted by azazello at 11:44 PM on December 29, 2004
Tell you what, you can design your webpages the way you want, and I'll view other webpages the way I want, OK? And when I stumble upon the train wreck that your page will be in my browser, I will just close that window.
posted by azazello at 11:44 PM on December 29, 2004
JP Hong: I've read some dumb shit on Mefi but this one is a standout. And what about all those annoying 256 colors, do we really need all them?
Heh. You really think the designers should have total control of what you see in your browser? The reason why we have to use plugins like adblock, pop-up blockers, HTTP proxy filters like Proxomitron, etc. is because users want to view sites the way THEY want to see it, not some designer's conception of what "looks good". Fonts are a prime example. Imagine what the web would look like if web designers didn't have to stick to web-safe fonts or could impose any font they wanted on the user. God, that would be horrible.
The color limitation was a technological one, that was surpassed with better graphics cards and monitors. New fonts, on the other hand, do not add to an objectively better experience. I don't mind a variety of fonts, but forcing it onto the user via some ugly Flash hack is not my idea of progress.
I use Proxo to substitute my own CSS file for Metafilter because I don't like the blue background. I like high-contrast colors and if you're going to use white fonts I demand a black background. Likewise I use Proxo to set a minimum size font, since on my high-res screen small fonts are a bitch to read. I also disable all background images by default. White is good enough for me. I realize that I am in the minority of hard-core anal web surfers but most people would do what I do if they knew how to do it.
lodurr: Oh, please, give me a break. You know damn well that we'd be living in design hell if "web designers" could use any damn font they pleased at any damn resolution they pleased.
Repeat after me, children: THE WEB IS NOT PRINT. THE WEB IS ABOUT CONTENT.
Hear, hear.
posted by aerify at 11:46 PM on December 29, 2004
Heh. You really think the designers should have total control of what you see in your browser? The reason why we have to use plugins like adblock, pop-up blockers, HTTP proxy filters like Proxomitron, etc. is because users want to view sites the way THEY want to see it, not some designer's conception of what "looks good". Fonts are a prime example. Imagine what the web would look like if web designers didn't have to stick to web-safe fonts or could impose any font they wanted on the user. God, that would be horrible.
The color limitation was a technological one, that was surpassed with better graphics cards and monitors. New fonts, on the other hand, do not add to an objectively better experience. I don't mind a variety of fonts, but forcing it onto the user via some ugly Flash hack is not my idea of progress.
I use Proxo to substitute my own CSS file for Metafilter because I don't like the blue background. I like high-contrast colors and if you're going to use white fonts I demand a black background. Likewise I use Proxo to set a minimum size font, since on my high-res screen small fonts are a bitch to read. I also disable all background images by default. White is good enough for me. I realize that I am in the minority of hard-core anal web surfers but most people would do what I do if they knew how to do it.
lodurr: Oh, please, give me a break. You know damn well that we'd be living in design hell if "web designers" could use any damn font they pleased at any damn resolution they pleased.
Repeat after me, children: THE WEB IS NOT PRINT. THE WEB IS ABOUT CONTENT.
Hear, hear.
posted by aerify at 11:46 PM on December 29, 2004
Repeat after me, children; THE WEB IS NOT PRINT, THE WEB IS NOT CONTENT, THE WEB IS NOT HTML, THE WEB IS NOT PNG, THE WEB IS NOT LINUX, THE WEB IS NOT COOL FLASH GAMES, THE WEB IS NOT PICTURES OF CHILDREN URINATING ON RUM-BREATH SANTA CLAUS. THE WEB IS NOT A PLACE TO PUT PICTURES OF YOUR BABIES FIRST DIRTY DIAPER. THE WEB IS NOT OPEN SOURCE.
wait... what is the web, it seems to me to be the intersection of primarily http line protocol and ways to deliver data (content, games, anti-aliased fonts, e-commerce solutions) to clients designed to receive and parse it (primarily browsers, but also fat clients backed by web-services, neato DHTML app look-a-likes, streaming pornography video, etc)
At the present, for me professionally, the web is a condiut for a product that involves taking a legacy banking function space and making it available (and better, hopefully) by making it hosted and browser based.
Just as a single example, we have a requirement that a page displayed to a user look as closely as possible to a standard Bill Of Lading. Not just for printing, the way people work means that the look and feel during data entry is just as important as print performance. Want to try that using just your 'Best Practices' without breaking some rules. Good fucking look.
For you:
THE WEB IS NOT PRINT. THE WEB IS ABOUT CONTENT.
For me:
MY WEB IS WHAT MAKES THE GREATEST NUMBER OF USERS MORE PRODUCTIVE, WISER, MORE COMFORTABLE AND ADDS VALUE TO THEIR PROCESS.
I don't think that either of these are wong, but I get the distinct impress that you think my web is wrong and yours is right. And thats the part where my IQ drops 20 points and I find myself typing fuck every five or six words.
In other words, stop telling me what my web is and I'll stop telling you what your web is. I'm not doing anything to hurt you. If your not a user of my web, or if you don't like my web, don't use the product, I promise I won't come with a gun and force you to.
If the compromises I make are really onerous to the majority of my users, well then, the market will decide and I'll be back here begging for the full frontal nude tour of CSS Zen Garden. Luckly for me, all the whining and bitching seems to be exclusively on metafilter, where the intersection between my paying customers seems quite small.
Wikipedia is not the end all, be all of what the 'web' should be.
Man, you guys are going to be batshit when things like Lazlo and Flex
become popular (and they are, whether you like it or not)
posted by PissOnYourParade at 12:57 AM on December 30, 2004
wait... what is the web, it seems to me to be the intersection of primarily http line protocol and ways to deliver data (content, games, anti-aliased fonts, e-commerce solutions) to clients designed to receive and parse it (primarily browsers, but also fat clients backed by web-services, neato DHTML app look-a-likes, streaming pornography video, etc)
At the present, for me professionally, the web is a condiut for a product that involves taking a legacy banking function space and making it available (and better, hopefully) by making it hosted and browser based.
Just as a single example, we have a requirement that a page displayed to a user look as closely as possible to a standard Bill Of Lading. Not just for printing, the way people work means that the look and feel during data entry is just as important as print performance. Want to try that using just your 'Best Practices' without breaking some rules. Good fucking look.
For you:
THE WEB IS NOT PRINT. THE WEB IS ABOUT CONTENT.
For me:
MY WEB IS WHAT MAKES THE GREATEST NUMBER OF USERS MORE PRODUCTIVE, WISER, MORE COMFORTABLE AND ADDS VALUE TO THEIR PROCESS.
I don't think that either of these are wong, but I get the distinct impress that you think my web is wrong and yours is right. And thats the part where my IQ drops 20 points and I find myself typing fuck every five or six words.
In other words, stop telling me what my web is and I'll stop telling you what your web is. I'm not doing anything to hurt you. If your not a user of my web, or if you don't like my web, don't use the product, I promise I won't come with a gun and force you to.
If the compromises I make are really onerous to the majority of my users, well then, the market will decide and I'll be back here begging for the full frontal nude tour of CSS Zen Garden. Luckly for me, all the whining and bitching seems to be exclusively on metafilter, where the intersection between my paying customers seems quite small.
Wikipedia is not the end all, be all of what the 'web' should be.
Man, you guys are going to be batshit when things like Lazlo and Flex
become popular (and they are, whether you like it or not)
posted by PissOnYourParade at 12:57 AM on December 30, 2004
Has anyone even looked at the embedded font links I provided above? The ones that only work in IE? Because THAT is a seamless solution.
I know it's not *cool* to admire Microsoft and their proprietary shit, but this is one case where they got it right, and everyone in their antitrust zeal is overlooking a truly perfect technical implementation.
posted by Civil_Disobedient at 1:22 AM on December 30, 2004
I know it's not *cool* to admire Microsoft and their proprietary shit, but this is one case where they got it right, and everyone in their antitrust zeal is overlooking a truly perfect technical implementation.
posted by Civil_Disobedient at 1:22 AM on December 30, 2004
If you are having issues with sIFR not doing what it claims to do, a good course of action would be to email Mike with your browser details and the problem you are having. Bickering about its shortcomings on Metafilter isn't the best way to improve the technology.
posted by erisfree at 3:57 AM on December 30, 2004
posted by erisfree at 3:57 AM on December 30, 2004
After rereading this thread again, I've come to this conclusion:
sIFR is a start. It's not perfect, but it has improved since it was created and looks to continue to improve. So lets see where it goes.
Being able to change headlines is nice, but hardly earthshattering. Let me know when I have the same or near control as QuarkXpress did ten years ago.
posted by Brandon Blatcher at 4:33 AM on December 30, 2004
sIFR is a start. It's not perfect, but it has improved since it was created and looks to continue to improve. So lets see where it goes.
Being able to change headlines is nice, but hardly earthshattering. Let me know when I have the same or near control as QuarkXpress did ten years ago.
posted by Brandon Blatcher at 4:33 AM on December 30, 2004
I haven't looked at the example of ESPN that "doesn't work", but before anyone rushes off to report it please check that it is actually sIFR being used.
If it doesn't scale it is not sIFR. Make sure if you are testing sIFR you are using the latest demo page
posted by andyhume at 4:50 AM on December 30, 2004
If it doesn't scale it is not sIFR. Make sure if you are testing sIFR you are using the latest demo page
posted by andyhume at 4:50 AM on December 30, 2004
Oh no, I'd never want to look at a real-world example. Let's stick to carefully controlled demo environments where we think it maybe works.
posted by gimonca at 5:30 AM on December 30, 2004
posted by gimonca at 5:30 AM on December 30, 2004
Laszlo technology is an open source XML-native platform for building rich client applications that deliver a breakthrough online user experience.
That Laszlo sales page is definitely buzzword-compliant...but everything I right-click on is still Flash. Nothing new here--the "new" stuff in the Behr paints site is awfully similar to something I saw done in Java years ago. And Flex is just another Macromedia tentacle.
It's not open-source, it's all proprietary and Flash-based. Or to put it another way: it's not the sex, it's the lying.
posted by gimonca at 5:48 AM on December 30, 2004
That Laszlo sales page is definitely buzzword-compliant...but everything I right-click on is still Flash. Nothing new here--the "new" stuff in the Behr paints site is awfully similar to something I saw done in Java years ago. And Flex is just another Macromedia tentacle.
It's not open-source, it's all proprietary and Flash-based. Or to put it another way: it's not the sex, it's the lying.
posted by gimonca at 5:48 AM on December 30, 2004
You know, brining rich text to the web sounds like a perfec t Open Source project, hint, hint, for the developer reading.
posted by Brandon Blatcher at 6:01 AM on December 30, 2004
posted by Brandon Blatcher at 6:01 AM on December 30, 2004
... but I get the distinct impress that you think my web is wrong and yours is right.
And I get the distinct impression that you're taking things too literally.
posted by lodurr at 6:45 AM on December 30, 2004
And I get the distinct impression that you're taking things too literally.
posted by lodurr at 6:45 AM on December 30, 2004
OK, to recap. Here's the good stuff about sIFR:
sIFR is a neat, elegant solution to an anal-retentive design problem; it's a really clever and elegant hack; it's a fantastic example of how to stretch the DOM without breaking it (because, really, sIFR is absolutely not a hack in that sense -- it uses the DOM exactly as the DOM was designed to be used). But it's not a solution. It's still a hack -- a band aid.
Where sIFR will get really interesting is when people start using the techniques behind it to do other things.
posted by lodurr at 7:00 AM on December 30, 2004
- It degrades gracefully, and is thus friendly for screen readers, search spiders, and syndication.
- It works as designed the great majority of the time.
- It looks great.
- It adds about 10K, processing overhead and another HTTP turnaround to the total page impact (page weight + system overhead + net latency).
- It uses proprietary software to render the text.
- It requires about $500 worth of proprietary software to create the text.
sIFR is a neat, elegant solution to an anal-retentive design problem; it's a really clever and elegant hack; it's a fantastic example of how to stretch the DOM without breaking it (because, really, sIFR is absolutely not a hack in that sense -- it uses the DOM exactly as the DOM was designed to be used). But it's not a solution. It's still a hack -- a band aid.
Where sIFR will get really interesting is when people start using the techniques behind it to do other things.
posted by lodurr at 7:00 AM on December 30, 2004
BTW, piss's "Laszlo" and "Flex" are examples of my last point. And the fact that piss thinks we'll be pissed by them illustrates quite well how much he misses the point of most people's objections to the idea of using a technique like sIFR for trivial applications like page headlines.
posted by lodurr at 7:04 AM on December 30, 2004
posted by lodurr at 7:04 AM on December 30, 2004
Repeat after me, children: THE WEB IS NOT PRINT. THE WEB IS ABOUT CONTENT.
Except for MetaFilter, which is mostly about discontent. :o)
I expected a yawn or two at most when I posted this. I’m not strongly for or against sIFR but it’s been interesting to follow the discussion. I’m going to keep looking to see what sIFR or something similar develops into.
On his site, Mike Davidson wrote: ”I’d respond on the Metafilter thread myself but I don’t feel like paying $5 to join.”
I e-mailed Mike Davidson and offered to post any comments he’d like to make here and he politely declined.
posted by Termite at 7:17 AM on December 30, 2004
Except for MetaFilter, which is mostly about discontent. :o)
I expected a yawn or two at most when I posted this. I’m not strongly for or against sIFR but it’s been interesting to follow the discussion. I’m going to keep looking to see what sIFR or something similar develops into.
On his site, Mike Davidson wrote: ”I’d respond on the Metafilter thread myself but I don’t feel like paying $5 to join.”
I e-mailed Mike Davidson and offered to post any comments he’d like to make here and he politely declined.
posted by Termite at 7:17 AM on December 30, 2004
Civil_Disobedient: MSFT's embedded font technology is indeed nice. I wonder why most web-designers won't balk at using IE-only Javascript, but will use flash or gfx for type?
posted by sonofsamiam at 7:24 AM on December 30, 2004
posted by sonofsamiam at 7:24 AM on December 30, 2004
Regarding the MS "solution", quoting quasimondo:
I looked extensively at WEFT and here are the three major problems with it:
1. It only works on IE/PC.
2. Microsoft clearly isn't supporting it anymore.
3. It only looks good on XP with ClearType turned on. I don't know about you but I can't stand ClearType. Unlike OS X's anti-aliasing, I find it actually makes normal body copy look worse.
WEFT would be fabulous if it worked better and in other browsers, but it appears dead-in-the-water at this point.
posted by spock at 7:47 AM on December 30, 2004
I looked extensively at WEFT and here are the three major problems with it:
1. It only works on IE/PC.
2. Microsoft clearly isn't supporting it anymore.
3. It only looks good on XP with ClearType turned on. I don't know about you but I can't stand ClearType. Unlike OS X's anti-aliasing, I find it actually makes normal body copy look worse.
WEFT would be fabulous if it worked better and in other browsers, but it appears dead-in-the-water at this point.
posted by spock at 7:47 AM on December 30, 2004
It adds about 10K, processing overhead and another HTTP turnaround to the total page impact (page weight + system overhead + net latency).
* It uses proprietary software to render the text.
* It requires about $500 worth of proprietary software to create the text.
It also REMOVES the need for however many K of images you are currently using to display a title or headline in a particular font. For virtually every site that uses it, sIFR is going to result in a net weight LOSS. I don't even understand the "another http turnaround". To load an external javascript? It is the same as loading another 10K image. Again, if you no longer have to use that typographically keen gif or jpeg you've just reduced your number of http calls.
"It uses proprietary software to render the text?"
Proprietary software that is free and nearly ubitquitous. Look, I'm a huge proponent of Open Source software, but getting things bundled so they are there when the customer takes the computer out of the box is not their strong suit. If we only want Linux people to be able to see your hack after they install the right combination of plug-ins or utilities, be my guest and write one. If you aren't a Linux guy, then your attitude is indefensible (unless you want in uninstall all proprietary software from you machine, including the operating system, immediately.)
Finally, it requires NOTHING to create the text, which is why you can download and run the sIFR demo even if you don't have flash. (It includes a couple of fonts in .swf format).
If you have Flash, you can create your own font files, but you can also grab ones that other people have made (just like you can grab images that other people have made). I expect there to be loads of places to do this soon. I don't expect that the type people will be too happy about this, but I don't see what they can do about it was made the .swf file from a font that you legally have on your system. If they are going to get upset about that then they should get upset about PDFs which are also documents created and distributed with their fonts.
From the production side, sIFR is for web designers. Odds are they already have Flash. From a consumer side, you only need the flash plug-in and that is only if you care to SEE the sIFR effect. If you don't have it (or have javascript turned off) you will see the plain text you would have otherwise seen.
Choose to use sIFR or don't. But don't expect to mandate that everybody make the same decision that you came to.
posted by spock at 8:11 AM on December 30, 2004
* It uses proprietary software to render the text.
* It requires about $500 worth of proprietary software to create the text.
It also REMOVES the need for however many K of images you are currently using to display a title or headline in a particular font. For virtually every site that uses it, sIFR is going to result in a net weight LOSS. I don't even understand the "another http turnaround". To load an external javascript? It is the same as loading another 10K image. Again, if you no longer have to use that typographically keen gif or jpeg you've just reduced your number of http calls.
"It uses proprietary software to render the text?"
Proprietary software that is free and nearly ubitquitous. Look, I'm a huge proponent of Open Source software, but getting things bundled so they are there when the customer takes the computer out of the box is not their strong suit. If we only want Linux people to be able to see your hack after they install the right combination of plug-ins or utilities, be my guest and write one. If you aren't a Linux guy, then your attitude is indefensible (unless you want in uninstall all proprietary software from you machine, including the operating system, immediately.)
Finally, it requires NOTHING to create the text, which is why you can download and run the sIFR demo even if you don't have flash. (It includes a couple of fonts in .swf format).
If you have Flash, you can create your own font files, but you can also grab ones that other people have made (just like you can grab images that other people have made). I expect there to be loads of places to do this soon. I don't expect that the type people will be too happy about this, but I don't see what they can do about it was made the .swf file from a font that you legally have on your system. If they are going to get upset about that then they should get upset about PDFs which are also documents created and distributed with their fonts.
From the production side, sIFR is for web designers. Odds are they already have Flash. From a consumer side, you only need the flash plug-in and that is only if you care to SEE the sIFR effect. If you don't have it (or have javascript turned off) you will see the plain text you would have otherwise seen.
Choose to use sIFR or don't. But don't expect to mandate that everybody make the same decision that you came to.
posted by spock at 8:11 AM on December 30, 2004
odinsdream: I went to your personal site and could not believe when I was assaulted by that patterned graphic at the top of your screen. Perhaps it would have been better if I could have changed the colors or increased the line thickness of the pattern but there was no way to do this! What do you expect me to do, turn off images just so I never have to see that single graphic? May I remind you that the web is not designed for designers but for the user!
posted by gwint at 8:41 AM on December 30, 2004
posted by gwint at 8:41 AM on December 30, 2004
Is it just me, or does the headline on the ESPN page to which gimonca links look a little too fuzzy? Is it the years of browsing sites without anti-aliased fonts that have made me accustomed to the horror that is non-anti-aliased text?
As near I can tell it's a nifty hack, but if it matters so much to the pointy haired types just specify the font and install it on their machines for them.
I of course am expecting to see people using this to replace their h1 header graphics, not their h2 and h3 headlines.
posted by codger at 8:41 AM on December 30, 2004
As near I can tell it's a nifty hack, but if it matters so much to the pointy haired types just specify the font and install it on their machines for them.
I of course am expecting to see people using this to replace their h1 header graphics, not their h2 and h3 headlines.
posted by codger at 8:41 AM on December 30, 2004
I get a little irritated with the "Inman" thing. Couldn't we just call it DOM Flash Replacement? I've been doing almost exactly the same thing for about a year now without naming it after myself.
posted by 4easypayments at 8:45 AM on December 30, 2004
posted by 4easypayments at 8:45 AM on December 30, 2004
I wonder why most web-designers won't balk at using IE-only Javascript, but will use flash or gfx for type?
Because they're STUPID.
Regarding the MS "solution", quoting quasimondo:
Hey, here's a little advice. OPEN IT UP AND CHECK IT OUT FOR YOURSELF. Jesus, does someone else have to do all the thinking for you. Check it out. For yourself. Here's the link again in case you missed it. You don't even need to install Internet Explorer. If you're using Windows, you can cut and paste the address into the file explorer.
See, if you actually looked at it yourself, you'd notice that it looks great without needing ClearType. I don't use ClearType, either, because I'm not on an LCD panel. Yet it looks perfect. PERFECT. I wonder why your savior would mislead you?
As for it working only in IE -- well, heck, the Flash method only works for people who have Flash installed. And aren't actively BLOCKING it. That's a lotta' meatballs.
And "Microsoft clearly isn't supporting it anymore"? That's funny, because I didn't install jack shit, and yet it works fine for me. So I would contest that it's supported quite well, actually. The reason you're not hearing about it anymore is because all the "cool kids" are dropping the ball in favor of hacks that will never be as elegant.
WEFT would be fabulous if it worked better and in other browsers, but it appears dead-in-the-water at this point.
So why not push for it? Why not try and get Mozilla The Great to support implementing it? It's obviously a great idea, there's already a working implementation that makes for a great proof-of-concept. What's stopping them? Blind, seething hatred of all that is Microsoft. That's what.
posted by Civil_Disobedient at 8:47 AM on December 30, 2004
Because they're STUPID.
Regarding the MS "solution", quoting quasimondo:
Hey, here's a little advice. OPEN IT UP AND CHECK IT OUT FOR YOURSELF. Jesus, does someone else have to do all the thinking for you. Check it out. For yourself. Here's the link again in case you missed it. You don't even need to install Internet Explorer. If you're using Windows, you can cut and paste the address into the file explorer.
See, if you actually looked at it yourself, you'd notice that it looks great without needing ClearType. I don't use ClearType, either, because I'm not on an LCD panel. Yet it looks perfect. PERFECT. I wonder why your savior would mislead you?
As for it working only in IE -- well, heck, the Flash method only works for people who have Flash installed. And aren't actively BLOCKING it. That's a lotta' meatballs.
And "Microsoft clearly isn't supporting it anymore"? That's funny, because I didn't install jack shit, and yet it works fine for me. So I would contest that it's supported quite well, actually. The reason you're not hearing about it anymore is because all the "cool kids" are dropping the ball in favor of hacks that will never be as elegant.
WEFT would be fabulous if it worked better and in other browsers, but it appears dead-in-the-water at this point.
So why not push for it? Why not try and get Mozilla The Great to support implementing it? It's obviously a great idea, there's already a working implementation that makes for a great proof-of-concept. What's stopping them? Blind, seething hatred of all that is Microsoft. That's what.
posted by Civil_Disobedient at 8:47 AM on December 30, 2004
Shaun Inman's site is excellent at using all of the CPU on my Powerbook under Safari.
One should always strive for a web page to use all CPU resources since displaying text is not a hard operation - making it harder is always desirable. Always.
posted by MrFancypants at 8:55 AM on December 30, 2004
One should always strive for a web page to use all CPU resources since displaying text is not a hard operation - making it harder is always desirable. Always.
posted by MrFancypants at 8:55 AM on December 30, 2004
What about those users that have Specifically Asked that all of their text content be delivered in a particular font, or at a particular size, as the majority of browsers enable them to do?
Look sIFR is a tool. sIFR doesn't "respect" anything. Don't anthropomorphize sIFR. It hates it when you do that.
That being said, any tool can be used for good or evil. sIFR is best used for replacing headlines. Is there a way that that the user can specifically choose what font/size h1-h6 tags are displayed (as separate from other text?) I'm just askin'. Cause that is the smart way to use sIFR (imho). The user's preferences are respected, except for those tags that you choose to replace (like h1 or h2, for instance).
Again, since sIFR is great at replacing that gif or jpeg that you were displaying your title or headline in 30 point insert-font-name-here, it is an improvement over that approach. The user couldn't dictate the size of the text in that gif or jpeg either. And sIFR scales. How is this bad?
I think a page looks tremendously better with just a touch of typographical originality on the page. It is subtle, but that is what typography is. I only want to use sIFR in specific places on pages I design. As a guy who loves typography, I think sIFR is one of the coolest, most important things that I have seen for the web in a looooong time.
Web designers make choices every day. Bad choices make viewers go away or not stick around to see the page load. Web designers (in general) stop using bad tools and making bad choices. It's a free market system. Let's run sIFR up the flagpole awhile and see if user's salute it.
posted by spock at 8:57 AM on December 30, 2004
Look sIFR is a tool. sIFR doesn't "respect" anything. Don't anthropomorphize sIFR. It hates it when you do that.
That being said, any tool can be used for good or evil. sIFR is best used for replacing headlines. Is there a way that that the user can specifically choose what font/size h1-h6 tags are displayed (as separate from other text?) I'm just askin'. Cause that is the smart way to use sIFR (imho). The user's preferences are respected, except for those tags that you choose to replace (like h1 or h2, for instance).
Again, since sIFR is great at replacing that gif or jpeg that you were displaying your title or headline in 30 point insert-font-name-here, it is an improvement over that approach. The user couldn't dictate the size of the text in that gif or jpeg either. And sIFR scales. How is this bad?
I think a page looks tremendously better with just a touch of typographical originality on the page. It is subtle, but that is what typography is. I only want to use sIFR in specific places on pages I design. As a guy who loves typography, I think sIFR is one of the coolest, most important things that I have seen for the web in a looooong time.
Web designers make choices every day. Bad choices make viewers go away or not stick around to see the page load. Web designers (in general) stop using bad tools and making bad choices. It's a free market system. Let's run sIFR up the flagpole awhile and see if user's salute it.
posted by spock at 8:57 AM on December 30, 2004
Civil_Disobedient: Bill Gates, is that you?
: )
Microsoft apologetics: There is nothing worse than a bully with a persecution complex.
posted by spock at 9:04 AM on December 30, 2004
: )
Microsoft apologetics: There is nothing worse than a bully with a persecution complex.
posted by spock at 9:04 AM on December 30, 2004
For those that really care, sIFR was preceded by IFR. There have been multiple versions of sIFR and it is getting better each time. If you see a site that you think is using sIFR, check out the sifr.js file and see if it is using the latest version. Whatever is bothering you may have been corrected in the latest version and you shouldn't make hasty judgments based on somebody's implementation of a deprecated version. (Upgrading is normally as easy as simply replacing the sifr.js file with the new one, I believe.)
MrFancyPants: interesting. I'm curious: Have you checked if the same thing happens using other browsers? How long is the processor at 100%. What processor are you talking about, a G3 or G4?
As with anything related to page rendering, the faster processor will do a faster job of it and any delay (etc.) will be magnified for the user with the older equipment. This is a concern, though not necessarily a fatal one (imo). I'd like more info on what you are experiencing.
posted by spock at 9:23 AM on December 30, 2004
MrFancyPants: interesting. I'm curious: Have you checked if the same thing happens using other browsers? How long is the processor at 100%. What processor are you talking about, a G3 or G4?
As with anything related to page rendering, the faster processor will do a faster job of it and any delay (etc.) will be magnified for the user with the older equipment. This is a concern, though not necessarily a fatal one (imo). I'd like more info on what you are experiencing.
posted by spock at 9:23 AM on December 30, 2004
odinsdream: My (sarcastic) point was that a user can't change elements of an image-- as in, I like your tessellating pattern but it looks terrible unless the line thickness is doubled (not really, I'm just saying as an example) Some people feel the same way about fonts and other design elements as you did about that image. The only option a user has is to view it exactly as it is or turn it off. Same with sIFR.
posted by gwint at 9:36 AM on December 30, 2004
posted by gwint at 9:36 AM on December 30, 2004
More data:
Tested the demo sIFR page in Jaws 4.51 -- Jaws won't read any of the sIFR headlines. All this talk of "accessibility" is just hot air. You might as well have .gifs with blank or missing alt attributes, you'll get the same result.
posted by gimonca at 9:43 AM on December 30, 2004
Tested the demo sIFR page in Jaws 4.51 -- Jaws won't read any of the sIFR headlines. All this talk of "accessibility" is just hot air. You might as well have .gifs with blank or missing alt attributes, you'll get the same result.
posted by gimonca at 9:43 AM on December 30, 2004
Bill Gates, is that you?
We have your position and troops are on their way. You have no chance to survive make your time.
posted by Civil_Disobedient at 10:09 AM on December 30, 2004
We have your position and troops are on their way. You have no chance to survive make your time.
posted by Civil_Disobedient at 10:09 AM on December 30, 2004
spock: This is a G4 1.25Ghz Powerbook running OS X v10.3.7. Under Safari v1.2.4 it runs the processor to 100% - although everything is still usable, more than about 20 seconds there and the fans kick in (and it uses more battery power of course).
Under FireFox 1.0 it "only" uses 69%, but goes to 75% or higher if I try to scroll on that page.
Probably of significance (mostly in how browsers handle the content over that of anything interesting about the page) - in Safari the load is there when I have that page visible. But if I move another window to cover Safari so that I can no longer see the page, the load drops back to normal (fluctuating over various amounts but peaking at 9%). If I have that page open in FireFox, regardless of what window and/or tab has focus, and even if FireFox is totally hidden from view, the processor still hits 69-75% usage.
Safari has a few issues with pages that use a lot of JavaScript - I haven't bothered to look into his page any further than that, but it is probably something rather significant if it also is causing FireFox to exhibit similar behavior.
It doesn't prevent the system from being usable, it just causes it to heat up more and drain the battery faster. I only happened to notice it since I have a CPU monitor up at all time and tend to want to see what applications (either written by me or not) are using more resources on my machine.
posted by MrFancypants at 10:48 AM on December 30, 2004
Under FireFox 1.0 it "only" uses 69%, but goes to 75% or higher if I try to scroll on that page.
Probably of significance (mostly in how browsers handle the content over that of anything interesting about the page) - in Safari the load is there when I have that page visible. But if I move another window to cover Safari so that I can no longer see the page, the load drops back to normal (fluctuating over various amounts but peaking at 9%). If I have that page open in FireFox, regardless of what window and/or tab has focus, and even if FireFox is totally hidden from view, the processor still hits 69-75% usage.
Safari has a few issues with pages that use a lot of JavaScript - I haven't bothered to look into his page any further than that, but it is probably something rather significant if it also is causing FireFox to exhibit similar behavior.
It doesn't prevent the system from being usable, it just causes it to heat up more and drain the battery faster. I only happened to notice it since I have a CPU monitor up at all time and tend to want to see what applications (either written by me or not) are using more resources on my machine.
posted by MrFancypants at 10:48 AM on December 30, 2004
spock: also note that this isn't a bursting of CPU usage, but a constant maxing out which sustains for as long as you are on the page (and it is visible in Safari, or just as long as it is loaded in any browser window in FireFox, visible or not).
posted by MrFancypants at 10:52 AM on December 30, 2004
posted by MrFancypants at 10:52 AM on December 30, 2004
Spock: It also REMOVES the need for however many K of images you are currently using to display a title or headline in a particular font.
Um.... Huh?
I guess I don't get this. Because it seems to me that the clearest and simplest alternative is to make the headline PLAIN TEXT, not an image. So, unless you assume that the only solution for displaying headlines is graphics, then your position is indefensible.
In fact, sIFR at base DOES SOMETHING THAT DOES NOT NEED TO BE DONE for the vast, vast, vast majority of cases. It doesn't neet to be cone on ESPN.com. It doesn't need to be done on any commercial site. Not if by "need" we mean that we're helping the reader in any way to understand the content of the site.
Why it does in fact "need" to be done on ESPN is because someone defined it as necessary, which has absolutely nothing to do with whether any user actually needs to see it that way. Whether the reason for defining it that was was "branding" or anal-retentive design is more or less irrelevant: It's a decision that someone made, divorced from any really objective evaluation of cost:benefit.
Now, if your cost:benefit calculations at your own site determine that you need to display some text in exactly a specific font for the subset of web users who have Flash installed
Proprietary software that is free and nearly ubitquitous. Look, I'm a huge proponent of Open Source software, but getting things bundled so they are there when the customer takes the computer out of the box is not their strong suit. If we only want Linux people to be able to see your hack after they install the right combination of plug-ins or utilities, be my guest and write one. If you aren't a Linux guy, then your attitude is indefensible (unless you want in uninstall all proprietary software from you machine, including the operating system, immediately.)
Finally, it requires NOTHING to create the text, which is why you can download and run the sIFR demo even if you don't have flash. (It includes a couple of fonts in .swf format).
Wow, so much here to respond to....
First, if the point is that you need to have a specific font show up in your headlines, you're not likely to find the SWF fonts you need at the sIFR site. If you can, great: You just saved yourself the $500 you'd need to spend to buy Flash so you can compile the font as SWF. (And we're both ignoring the font-licensing issues here, but I'm happy to do that since everyone else seems willing...)
Second, F/OSS is a red herring. F/OSS is not the same as open standards. "Proprietary" is not synonymous with "commercial"; "Open standards" are not synonymous with "non-commercial". Moz/Firefox, Opera, Safari and even IE work primarily via open standards. Flash does not.
For the record, I'm not "a linux guy". I'm writng this on a Win2K system that I could boot to Linux if I wanted to (at which point I would probably be able to see sIFR headlines just fine, thank you, using Mandrake's default Konqueror configuration). And in any case, I really just don't get your point, I guess: Why does it matter if I'm a "Linux guy" or "Mac guy" or "Windows guy"? I don't see you making a coherent argument for why that should matter.
posted by lodurr at 11:17 AM on December 30, 2004
Um.... Huh?
I guess I don't get this. Because it seems to me that the clearest and simplest alternative is to make the headline PLAIN TEXT, not an image. So, unless you assume that the only solution for displaying headlines is graphics, then your position is indefensible.
In fact, sIFR at base DOES SOMETHING THAT DOES NOT NEED TO BE DONE for the vast, vast, vast majority of cases. It doesn't neet to be cone on ESPN.com. It doesn't need to be done on any commercial site. Not if by "need" we mean that we're helping the reader in any way to understand the content of the site.
Why it does in fact "need" to be done on ESPN is because someone defined it as necessary, which has absolutely nothing to do with whether any user actually needs to see it that way. Whether the reason for defining it that was was "branding" or anal-retentive design is more or less irrelevant: It's a decision that someone made, divorced from any really objective evaluation of cost:benefit.
Now, if your cost:benefit calculations at your own site determine that you need to display some text in exactly a specific font for the subset of web users who have Flash installed
Proprietary software that is free and nearly ubitquitous. Look, I'm a huge proponent of Open Source software, but getting things bundled so they are there when the customer takes the computer out of the box is not their strong suit. If we only want Linux people to be able to see your hack after they install the right combination of plug-ins or utilities, be my guest and write one. If you aren't a Linux guy, then your attitude is indefensible (unless you want in uninstall all proprietary software from you machine, including the operating system, immediately.)
Finally, it requires NOTHING to create the text, which is why you can download and run the sIFR demo even if you don't have flash. (It includes a couple of fonts in .swf format).
Wow, so much here to respond to....
First, if the point is that you need to have a specific font show up in your headlines, you're not likely to find the SWF fonts you need at the sIFR site. If you can, great: You just saved yourself the $500 you'd need to spend to buy Flash so you can compile the font as SWF. (And we're both ignoring the font-licensing issues here, but I'm happy to do that since everyone else seems willing...)
Second, F/OSS is a red herring. F/OSS is not the same as open standards. "Proprietary" is not synonymous with "commercial"; "Open standards" are not synonymous with "non-commercial". Moz/Firefox, Opera, Safari and even IE work primarily via open standards. Flash does not.
For the record, I'm not "a linux guy". I'm writng this on a Win2K system that I could boot to Linux if I wanted to (at which point I would probably be able to see sIFR headlines just fine, thank you, using Mandrake's default Konqueror configuration). And in any case, I really just don't get your point, I guess: Why does it matter if I'm a "Linux guy" or "Mac guy" or "Windows guy"? I don't see you making a coherent argument for why that should matter.
posted by lodurr at 11:17 AM on December 30, 2004
Here's a sentiment that I see a lot in this thread, and in general, as expressed by Spock: "Bad choices make viewers go away or not stick around to see the page load."
Well.... No. Actually. No.
I can understand the source of the sentiment. We all like to think of the web as a technical meritocracy. It's not. It's an ecosystem. We like to think of evolution as something that produces best results, as we'd like to understand them. It doesn't. It produces optimal results, in the terms of the relevant ecosystem.
Bad choices degrade the user's experience, but maybe not enough to make them leave. If the content trumps the impact of degraded experience, then they'll stay.
Bad choices affect the implementation cost, but maybe not enough to get noticed, or maybe in a way that's hidden by the organizational structure or business process. So maybe no one notices that simple template changes now have to be routed through an irrelevant department, or have to be sent back to the design department to fix breakages.
Bad choices, in fact, only cause those choices to be noticed if the results of the bad choices have sufficient impact.
posted by lodurr at 11:38 AM on December 30, 2004
Well.... No. Actually. No.
I can understand the source of the sentiment. We all like to think of the web as a technical meritocracy. It's not. It's an ecosystem. We like to think of evolution as something that produces best results, as we'd like to understand them. It doesn't. It produces optimal results, in the terms of the relevant ecosystem.
Bad choices degrade the user's experience, but maybe not enough to make them leave. If the content trumps the impact of degraded experience, then they'll stay.
Bad choices affect the implementation cost, but maybe not enough to get noticed, or maybe in a way that's hidden by the organizational structure or business process. So maybe no one notices that simple template changes now have to be routed through an irrelevant department, or have to be sent back to the design department to fix breakages.
Bad choices, in fact, only cause those choices to be noticed if the results of the bad choices have sufficient impact.
posted by lodurr at 11:38 AM on December 30, 2004
I heart majick. S/He gets the web.
posted by five fresh fish at 11:47 AM on December 30, 2004
posted by five fresh fish at 11:47 AM on December 30, 2004
It's not a question of ASCII vs. Binary or anything else these purist engineers will spout about what the web should be.
Now there are people on the sIFR page complaining that they can't do something as basic as an ñ. Obviously no character set issues were even considered.
posted by gimonca at 12:01 PM on December 30, 2004
Now there are people on the sIFR page complaining that they can't do something as basic as an ñ. Obviously no character set issues were even considered.
posted by gimonca at 12:01 PM on December 30, 2004
I'm torn by this thread. On the one hand, sIFR is a really profound example of the kind of power you can wield via the DOM, and I admire the out of the box thinking that went into creating it.
OTOH, I don't think it needed to be done. Especially not on commercial sites, and especially not on sites that are already heavy with plugins and clutter.
I also think it's unfair to rag on them for not supporting extended character sets -- hell, some typefaces just don't support those characters. I also know that these guys try hard to make it work, as a point of pride.
But at base, I have to think that using sIFR as a production tool in and of itself is a bit like commuting in a street rod.
On Prev: I'll get behind odinsdream's summary, FWIW.
posted by lodurr at 12:36 PM on December 30, 2004
OTOH, I don't think it needed to be done. Especially not on commercial sites, and especially not on sites that are already heavy with plugins and clutter.
I also think it's unfair to rag on them for not supporting extended character sets -- hell, some typefaces just don't support those characters. I also know that these guys try hard to make it work, as a point of pride.
But at base, I have to think that using sIFR as a production tool in and of itself is a bit like commuting in a street rod.
On Prev: I'll get behind odinsdream's summary, FWIW.
posted by lodurr at 12:36 PM on December 30, 2004
Bad choices degrade the user's experience, but maybe not enough to make them leave.
Definately no. Case in point: my SO just had to reboot her computer (old, Windows 98) because she tried viewing Salon, with it's craptacular Flash ads. The system came to a standstill. Completely halted. I honestly doubt she's going to be visiting it again any time soon.
posted by Civil_Disobedient at 1:04 PM on December 30, 2004
Definately no. Case in point: my SO just had to reboot her computer (old, Windows 98) because she tried viewing Salon, with it's craptacular Flash ads. The system came to a standstill. Completely halted. I honestly doubt she's going to be visiting it again any time soon.
posted by Civil_Disobedient at 1:04 PM on December 30, 2004
For her, yes. So it refutes your absolutist comment, "Well.... No. Actually. No." In some cases, actually, yes. Definately yes.
posted by Civil_Disobedient at 1:58 PM on December 30, 2004
posted by Civil_Disobedient at 1:58 PM on December 30, 2004
For the Character Set issue: I'm just wrong, apparently they are supported.
Then why did three different people post to the sIFR site that they aren't working? They're not talking about some obscure scripts--the posters are trying to do Spanish, Portuguese, and (guessing from the name of the third) Italian. Those ought to be pretty much universal, seeing as they're all covered by ISO 8859-1. If they don't work, something is going horribly wrong somewhere, something that in a normal environment would never happen.
For Screen Readers not being able to read sIFR:
I'm just wrong, apparently they can.
Again, totally contradicted by the sIFR site itself. From a poster to that site:
Sigh. This means that this trick will not be accible for most blind users, as they tend to use a regular browser with a screen reader that reads the rendered page, not the source code (while Flash is installed by default and JavaScript must be enabled for most sites to work).
I've confirmed this live. My copy of Jaws skips past "The Quick Brown Fox Jumps Over the Lazy Dog" every time. The only way to avoid the problem is not to use the hack to begin with.
posted by gimonca at 4:01 PM on December 30, 2004
Then why did three different people post to the sIFR site that they aren't working? They're not talking about some obscure scripts--the posters are trying to do Spanish, Portuguese, and (guessing from the name of the third) Italian. Those ought to be pretty much universal, seeing as they're all covered by ISO 8859-1. If they don't work, something is going horribly wrong somewhere, something that in a normal environment would never happen.
For Screen Readers not being able to read sIFR:
I'm just wrong, apparently they can.
Again, totally contradicted by the sIFR site itself. From a poster to that site:
Sigh. This means that this trick will not be accible for most blind users, as they tend to use a regular browser with a screen reader that reads the rendered page, not the source code (while Flash is installed by default and JavaScript must be enabled for most sites to work).
I've confirmed this live. My copy of Jaws skips past "The Quick Brown Fox Jumps Over the Lazy Dog" every time. The only way to avoid the problem is not to use the hack to begin with.
posted by gimonca at 4:01 PM on December 30, 2004
So it refutes your absolutist comment
If I had made an absolutist comment -- which I did not -- it would have refuted it. Here's what was said.
Spock: "Bad choices make viewers go away or not stick around to see the page load."
Me: "Well.... No. Actually. No."
Spock makes an absolutist comment ('If the page is bad people will leave'); I negate it ('No, actually, it's not true that if the page is bad people will leave'). That does not imply, in any way, that I'm sayign people always stick around. In fact, the context of my comment makes it clear I was arguing more or less the opposite. But since you seem to need it spelled out for you, I'll do that:
SOMETIMES WHEN THINGS ARE BAD ON A PAGE, PEOPLE LEAVE AND NEVER COME BACK. SOMETIMES THINGS AREN'T BAD ENOUGH THAT THEY DO STILL COME BACK.
There, is that clearer?
posted by lodurr at 8:28 PM on December 30, 2004
If I had made an absolutist comment -- which I did not -- it would have refuted it. Here's what was said.
Spock: "Bad choices make viewers go away or not stick around to see the page load."
Me: "Well.... No. Actually. No."
Spock makes an absolutist comment ('If the page is bad people will leave'); I negate it ('No, actually, it's not true that if the page is bad people will leave'). That does not imply, in any way, that I'm sayign people always stick around. In fact, the context of my comment makes it clear I was arguing more or less the opposite. But since you seem to need it spelled out for you, I'll do that:
SOMETIMES WHEN THINGS ARE BAD ON A PAGE, PEOPLE LEAVE AND NEVER COME BACK. SOMETIMES THINGS AREN'T BAD ENOUGH THAT THEY DO STILL COME BACK.
There, is that clearer?
posted by lodurr at 8:28 PM on December 30, 2004
My visually impaired focus group is all Jaws/Windows users, so that's what I test with.
Are you sure abcnews.go.com is using the current version?
posted by gimonca at 9:27 PM on December 30, 2004
Are you sure abcnews.go.com is using the current version?
posted by gimonca at 9:27 PM on December 30, 2004
An interesting point of view, from Roger Johansson's web-design predictions for '05:
Typography-starved web designers go crazy with their new toy, sIFR, and use it for everything. The resulting slow-loading sites look like flyers from the desktop revolution in the late eighties because of their use of at least ten different fonts. Only this time, the text is anti-aliased. As more people install ad blockers, site owners will get complaints about missing headings and text. By the end of the year, sIFR gets mentioned in the same sentence as <marquee>, <blink>, and Java applets.
posted by ubernostrum at 1:56 AM on December 31, 2004
Typography-starved web designers go crazy with their new toy, sIFR, and use it for everything. The resulting slow-loading sites look like flyers from the desktop revolution in the late eighties because of their use of at least ten different fonts. Only this time, the text is anti-aliased. As more people install ad blockers, site owners will get complaints about missing headings and text. By the end of the year, sIFR gets mentioned in the same sentence as <marquee>, <blink>, and Java applets.
posted by ubernostrum at 1:56 AM on December 31, 2004
The advantage to the IE font embedding method is that you might actually push other browsers in a direction to support it.
Ignoring the font licensing issues of pushing an embedded font the MS way, you clearly haven't been paying attention to how Microsoft works. They create things to give their browser what they think is a competative advantage. They don't want to share, and even when they do select something that is a standard (think java or kerberos, for example) they attempt to tweak it so their product will be the only one that can take advantage of the tweak and everyone will think that the standards-compliant products are the ones that are broken.
Considering that Microsoft has created the single worst web browser on the planet (any way you slice it), I would not look twice at a Microsoft browser "innovation".
posted by spock at 8:42 AM on December 31, 2004
Ignoring the font licensing issues of pushing an embedded font the MS way, you clearly haven't been paying attention to how Microsoft works. They create things to give their browser what they think is a competative advantage. They don't want to share, and even when they do select something that is a standard (think java or kerberos, for example) they attempt to tweak it so their product will be the only one that can take advantage of the tweak and everyone will think that the standards-compliant products are the ones that are broken.
Considering that Microsoft has created the single worst web browser on the planet (any way you slice it), I would not look twice at a Microsoft browser "innovation".
posted by spock at 8:42 AM on December 31, 2004
you clearly haven't been paying attention to how Microsoft works
See, I get bashed for being a MS lover, and then I read reasoning like this.
It works. I know it must burn you to the core, but it works, and it works better. Who cares about MS's hijinks when you just want to read a web page? Why can't open source enthusiasts simply steal the idea back? What's stopping them from even trying to implement it?
Oh, and true-type fonts are encoded with a protection bit (which, I might add, the MS embed function recognizes) to prevent unauthorized distribution. So the licensing issues are moot.
posted by Civil_Disobedient at 10:52 AM on December 31, 2004
See, I get bashed for being a MS lover, and then I read reasoning like this.
It works. I know it must burn you to the core, but it works, and it works better. Who cares about MS's hijinks when you just want to read a web page? Why can't open source enthusiasts simply steal the idea back? What's stopping them from even trying to implement it?
Oh, and true-type fonts are encoded with a protection bit (which, I might add, the MS embed function recognizes) to prevent unauthorized distribution. So the licensing issues are moot.
posted by Civil_Disobedient at 10:52 AM on December 31, 2004
Mike had some final comments he wanted to share.
----------------------------
Thank you to all who have taken the time to comment on this thread.
Thank you even further to those who have taken the time to actually
understand sIFR and *then* comment on this thread. I've resisted
commenting because to me this is beginning to resemble a mini SlashDot
feud where the people who talk the loudest and the most often tend to
drown out the voices of reason.
In the non-internet world, informed people spread opinions in books, in
newspapers, in journals, at conferences and other avenues of noble
repute. Uninformed people spread opinions with megaphones on
streetcorners, leaflets, sandwich boards, chain-letters, and other
avenues of ill repute. It is usually easy to tell the informed from
the uninformed based on solely on the delivery of their message.
On the internet, however -- and particularly in unmoderated discussions
like this one -- an informed opinion can appear the same as an
uninformed opinion, unless you know otherwise. It disappoints me to
see people like "gimonca" and "Civil_Disobedient" (among others)
spreading such misinformation on Metafilter and hoping others take it
as the truth. It is not the truth and it only hurts the value of these
discussions to treat it as such. Let's go over some of the more
aggregious comments:
1. Gimonca does a Google search for "Pedro Martinez" and clumsily
assumes that since the first ESPN pages to come up are ones without
Flash headlines, that sIFR must be causing page rank problems. First,
ESPN doesn't even use sIFR. We could just stop right there and point
out the ridiculousness of the argument. But let's go further. Had
Gimonca even attempted to understand sIFR (or search engines for that
matter), he'd know that sIFR doesn't even touch your HTML code and
hence has no effect on indexability. That is the whole point of it for
crying out loud! But since Gimonca likes to just spew nonsense, he
spews it... and we shake our heads.
2. Space Coyote and Gimonca both attempt to test sIFR on screenreaders
and post messages to claiming to prove it's not an accessible
technique. As it turns out, both were looking at an early beta version
sIFR from several months ago. Had either taken the time to actually
read any of my articles on the subject (each which contains a link to
the newest article and example at the very top of the entry), they'd
know how many improvements have occurred from 1.0b to 2.0RC3. But you
know what? I don't even expect them to do this. Instead, how about a
post like "I went to the example at this page and couldn't get it to
work" instead of "Haha, you are WRONG. It doesn't work". It's this
uninformed cynicism which makes people look like fools.
3. Gimonca says "Now there are people on the sIFR page complaining
that they can't do something as basic as an ñ. Obviously no character
set issues were even considered." So because 2 or 3 people out of
about 800 commenters didn't read the instructions about how to support
extended character sets that means that "obviously no character set
issues were even considered"? Again, the folly of this logic makes me
wonder how this person is even able to operate a mouse. sIFR *does
indeed* fully support any and all character sets... you just need to
choose which to enable (in order to keep filesize of the .swf down...
this is by design).
4. Dreish mentioned something about waiting three or four minutes for
an "animation" and ended with some nonsense about no-op loops in Flash.
I can't say I even understand any of this comment.
5. Sorry to keep picking on Gimonca here but I feel like he's provided
at least 50% of the nonsense in this entire thread. His next comment
is "Let's take the most open, widely-supported, indexable and flexible
aspect of the web and lock it into a proprietary, clunky, nasty, closed
plug-in." Who's locking anybody into anything? sIFR can be applied
sitewide in 5-10 minutes. It can be removed sitewide in about 10
seconds. That's part of the beauty of it... it pops right in and it
snaps right out. This crazy idea that sIFR is about building entire
sites around Flash is just insane. Your site stays untouched. And if
someone doesn't have Flash, they don't even notice it's there.
6. Civil_Disobedient brought up Microsoft's WEFT technology claiming
it's the way to go. I cover WEFT in my sIFR article. I love the idea
and I wish it worked better. It just doesn't though and that's part of
why Microsoft dropped support for it. First of all, it looks terrible
without ClearType turned on (over half of PCs have it turned off or
just don't even support it at all). Second of all, it only works in
PC/IE. And third of all, it has other display quirks which make it
less than ideal. And given the bleeding-heart, open-source slant of
this discussion, I'm surprised anyone is even mentioning WEFT.
7. Majick and a couple of others went on to complain about an added
10k-20k of page weight and even said they'd risk getting canned over
this extra page weight. Wow. If your employer is going to can you for
adding two 10k files, both of which only load once and are cached
thereafter, you must have a pretty uptight boss. Do you have any idea
how insignificant a one-time load of 20k is? Give me a break... that's
just ridiculous and you know it. I pay $15 a month on Dreamhost to
host my site and I get 192 GB of throughput. I'd need 9.6 million hits
to those files in that time to use up my $15. And that's a $15 plan!
Any site getting 9.6 million hits a month is on a lot cheaper GB per
dollar plan than that. If you want to argue that an extra one-time
load of 20k for a dial-up user is a bit of a downer, ok, fine... I'll
buy that. But let's not act like a 8.9k file and an 11k file are going
to even be noticed in the bandwidth bill. And by the way, lets also
not just compare this to plain text. Let's compare it to image
replacement. You're actually *saving* quite a bit of bandwidth over
image replacement.
8. Civil_Disobedient claims that text is not zoomable. I understand
that part of being a civil disobedient is not doing things that
civilized people do (like "read"), but again, how about we study up on
the technique before making such claims? sIFR uses what I call "lazy
scaling". It scales as the page is rendered, based on the size of the
box it is replacing. Most people who have problems seeing small text
surf the web with text zoom always turned on. They don't adjust font
sizes for every page they hit. Sure, occasionally you may hit a page
which needs adjusting, but for the most part, vision-impaired people
*always* need a bump-up. For this situation, sIFR's zooming works just
fine. Additionally, smart use of sIFR means using it mainly for
headlines... in other words, things which are very big to begin with.
9. Rusty said: "I have much greater respect for web developers who
create beautiful sites within the onerous limitations of clean, usable,
cross-browser design." Thanks, that's exactly what sIFR does.
10. Aerify goes on to explain to us "children" that "THE WEB IS NOT
PRINT. THE WEB IS ABOUT CONTENT." So print is not about content?
Okay, what is it about then? Why do you read a newspaper? The fact
is, *every* medium is about content and I don't understand what this
truism has to do with what we're talking about. Aerify is part of the
.00000000001% of the population that strips away all color, design,
typography, etc from every site he can using a custom CSS file so does
that mean the rest of the world wants to view web content in the same
bland, lifeless backdrop that he does? I don't think so. If you want
to strip away bad design, fine. But not all design is bad, and market
forces will eventually push people away from poorly designed sites and
towards well-designed sites.
11. Odinsdream brought up a point about users wanting to control their
own fonts. I don't disagree at all about this, but I just think
display type and body copy play by different rules. On my own site,
mikeindustries.com, I not only allow you to pick from a list you want
your body copy rendered in but I let you type in the name of any font
on your system if you'd like. You see, body copy needs to be read for
5, 10, 20 minutes at a time... or longer, so it is of UTMOST importance
that the user be able to control every single aspect of it. For a
headline on a page, however, we're talking about less than a second of
reading time. For this reason, it plays by different rules and has a
bit more leeway.
12. Mrfancypants explains how Shaun Inman's site pegs his CPU.
Shaun's site doesn't use sIFR. Additionally, it replaces quite a few
blocks of text (upwards of 100 sometimes) with Flash. This use of
Flash replacement may be a bit overzealous and I'm sure once Shaun
stops being insanely busy creating other great things for the world
like Shortstat, he will address this. Do not pin it on sIFR though.
13. Civil_Disobedient goes off on how Salon.com crashes his
significant other's Win 98 machine. Sorry, that's not my problem, nor
is it caused by sIFR (which Salon.com obviously doesn't use).
And so there you have it. Let's cut the nonsense. I usually don't
respond to this sort of discussion but I just couldn't stand to watch
this flow of misinformation to continue feeding on itself. To the
people who have maintained the sanity on this thread, I thank you. To
the 4 or 5 others who continue to pollute the pipes with your own
biases and misgivings, thanks for wasting the last hour of my life.
I'll close with what I believe to be the salient points about sIFR:
1. sIFR provides an easy cross-platform, cross-browser way to display
rich typography to approximately 95% of the world. The other 4.9% will
see CSS-styled HTML text. And the remaining .1% may unfortunately run
across the ad-blocking issues that have been discussed here. I do take
the ad-blocking issues seriously and I feel there is a very easy way
these companies can release much smarter ad-blockers. Perhaps I'll
have a chat with some of them. So for for the small handful of sIFR
haters on this thread, if you want to hang your entire argument on a
Flash-blocking issue, go ahead... once a measurable portion of the
population is affected, perhaps we'll have a better solution.
2. sIFR does not touch your code and thus has no effect on indexability
of your site, the accessibility of your site to screenreaders, nor the
long-term architecture of it. It can be implemented in about 10
minutes and removed in about 10 seconds. It is not a permanent
solution, but just an extremely elegant and useful hack.
3. sIFR is best used in a judicious manner... 1-4 headlines per page
maybe. It is not meant for body copy but for display type.
4. sIFR is not for everybody and if you don't wish to use it, then
don't. That doesn't mean you should require that nobody else in the
world use it. Your web site is yours and yours alone. The market will
decide whether or not you are making good design decisions with it.
5. The javascript which powers sIFR is some of the best object-oriented
javascript you'll ever see. Mark Wubben has spent an inordinant amount
of time on the JS-side of the technique, so for you code geeks out
there who think sIFR is a "Flashy designer thing" take a look at the
javascript source code. It's quite beautiful.
6. Finally, if this thread has taught you anything, I hope it's that
when evaluating anything new, it is most important to know the facts.
The internet makes it very easy for people like Gimonca,
Civil_Disobedient, and others to come across as experts based solely on
the volume and voracity of their posts. As we see from the unraveling
of the nonsense, nothing could be further from the truth.
Cheers, and I hope everyone has a great new year. Continue pushing the
limits of this great medium we work on. The only way for it to achieve
its true potential is through the extending of boundaries. Those who
say sIFR is not an end-all-be-all solution are correct... but it gives
us one important thing today which we'd otherwise have to wait years
for: rich, accessible typography. And that's a good enough for me.
Cheers,
Mike
posted by erisfree at 11:53 AM on December 31, 2004
----------------------------
Thank you to all who have taken the time to comment on this thread.
Thank you even further to those who have taken the time to actually
understand sIFR and *then* comment on this thread. I've resisted
commenting because to me this is beginning to resemble a mini SlashDot
feud where the people who talk the loudest and the most often tend to
drown out the voices of reason.
In the non-internet world, informed people spread opinions in books, in
newspapers, in journals, at conferences and other avenues of noble
repute. Uninformed people spread opinions with megaphones on
streetcorners, leaflets, sandwich boards, chain-letters, and other
avenues of ill repute. It is usually easy to tell the informed from
the uninformed based on solely on the delivery of their message.
On the internet, however -- and particularly in unmoderated discussions
like this one -- an informed opinion can appear the same as an
uninformed opinion, unless you know otherwise. It disappoints me to
see people like "gimonca" and "Civil_Disobedient" (among others)
spreading such misinformation on Metafilter and hoping others take it
as the truth. It is not the truth and it only hurts the value of these
discussions to treat it as such. Let's go over some of the more
aggregious comments:
1. Gimonca does a Google search for "Pedro Martinez" and clumsily
assumes that since the first ESPN pages to come up are ones without
Flash headlines, that sIFR must be causing page rank problems. First,
ESPN doesn't even use sIFR. We could just stop right there and point
out the ridiculousness of the argument. But let's go further. Had
Gimonca even attempted to understand sIFR (or search engines for that
matter), he'd know that sIFR doesn't even touch your HTML code and
hence has no effect on indexability. That is the whole point of it for
crying out loud! But since Gimonca likes to just spew nonsense, he
spews it... and we shake our heads.
2. Space Coyote and Gimonca both attempt to test sIFR on screenreaders
and post messages to claiming to prove it's not an accessible
technique. As it turns out, both were looking at an early beta version
sIFR from several months ago. Had either taken the time to actually
read any of my articles on the subject (each which contains a link to
the newest article and example at the very top of the entry), they'd
know how many improvements have occurred from 1.0b to 2.0RC3. But you
know what? I don't even expect them to do this. Instead, how about a
post like "I went to the example at this page and couldn't get it to
work" instead of "Haha, you are WRONG. It doesn't work". It's this
uninformed cynicism which makes people look like fools.
3. Gimonca says "Now there are people on the sIFR page complaining
that they can't do something as basic as an ñ. Obviously no character
set issues were even considered." So because 2 or 3 people out of
about 800 commenters didn't read the instructions about how to support
extended character sets that means that "obviously no character set
issues were even considered"? Again, the folly of this logic makes me
wonder how this person is even able to operate a mouse. sIFR *does
indeed* fully support any and all character sets... you just need to
choose which to enable (in order to keep filesize of the .swf down...
this is by design).
4. Dreish mentioned something about waiting three or four minutes for
an "animation" and ended with some nonsense about no-op loops in Flash.
I can't say I even understand any of this comment.
5. Sorry to keep picking on Gimonca here but I feel like he's provided
at least 50% of the nonsense in this entire thread. His next comment
is "Let's take the most open, widely-supported, indexable and flexible
aspect of the web and lock it into a proprietary, clunky, nasty, closed
plug-in." Who's locking anybody into anything? sIFR can be applied
sitewide in 5-10 minutes. It can be removed sitewide in about 10
seconds. That's part of the beauty of it... it pops right in and it
snaps right out. This crazy idea that sIFR is about building entire
sites around Flash is just insane. Your site stays untouched. And if
someone doesn't have Flash, they don't even notice it's there.
6. Civil_Disobedient brought up Microsoft's WEFT technology claiming
it's the way to go. I cover WEFT in my sIFR article. I love the idea
and I wish it worked better. It just doesn't though and that's part of
why Microsoft dropped support for it. First of all, it looks terrible
without ClearType turned on (over half of PCs have it turned off or
just don't even support it at all). Second of all, it only works in
PC/IE. And third of all, it has other display quirks which make it
less than ideal. And given the bleeding-heart, open-source slant of
this discussion, I'm surprised anyone is even mentioning WEFT.
7. Majick and a couple of others went on to complain about an added
10k-20k of page weight and even said they'd risk getting canned over
this extra page weight. Wow. If your employer is going to can you for
adding two 10k files, both of which only load once and are cached
thereafter, you must have a pretty uptight boss. Do you have any idea
how insignificant a one-time load of 20k is? Give me a break... that's
just ridiculous and you know it. I pay $15 a month on Dreamhost to
host my site and I get 192 GB of throughput. I'd need 9.6 million hits
to those files in that time to use up my $15. And that's a $15 plan!
Any site getting 9.6 million hits a month is on a lot cheaper GB per
dollar plan than that. If you want to argue that an extra one-time
load of 20k for a dial-up user is a bit of a downer, ok, fine... I'll
buy that. But let's not act like a 8.9k file and an 11k file are going
to even be noticed in the bandwidth bill. And by the way, lets also
not just compare this to plain text. Let's compare it to image
replacement. You're actually *saving* quite a bit of bandwidth over
image replacement.
8. Civil_Disobedient claims that text is not zoomable. I understand
that part of being a civil disobedient is not doing things that
civilized people do (like "read"), but again, how about we study up on
the technique before making such claims? sIFR uses what I call "lazy
scaling". It scales as the page is rendered, based on the size of the
box it is replacing. Most people who have problems seeing small text
surf the web with text zoom always turned on. They don't adjust font
sizes for every page they hit. Sure, occasionally you may hit a page
which needs adjusting, but for the most part, vision-impaired people
*always* need a bump-up. For this situation, sIFR's zooming works just
fine. Additionally, smart use of sIFR means using it mainly for
headlines... in other words, things which are very big to begin with.
9. Rusty said: "I have much greater respect for web developers who
create beautiful sites within the onerous limitations of clean, usable,
cross-browser design." Thanks, that's exactly what sIFR does.
10. Aerify goes on to explain to us "children" that "THE WEB IS NOT
PRINT. THE WEB IS ABOUT CONTENT." So print is not about content?
Okay, what is it about then? Why do you read a newspaper? The fact
is, *every* medium is about content and I don't understand what this
truism has to do with what we're talking about. Aerify is part of the
.00000000001% of the population that strips away all color, design,
typography, etc from every site he can using a custom CSS file so does
that mean the rest of the world wants to view web content in the same
bland, lifeless backdrop that he does? I don't think so. If you want
to strip away bad design, fine. But not all design is bad, and market
forces will eventually push people away from poorly designed sites and
towards well-designed sites.
11. Odinsdream brought up a point about users wanting to control their
own fonts. I don't disagree at all about this, but I just think
display type and body copy play by different rules. On my own site,
mikeindustries.com, I not only allow you to pick from a list you want
your body copy rendered in but I let you type in the name of any font
on your system if you'd like. You see, body copy needs to be read for
5, 10, 20 minutes at a time... or longer, so it is of UTMOST importance
that the user be able to control every single aspect of it. For a
headline on a page, however, we're talking about less than a second of
reading time. For this reason, it plays by different rules and has a
bit more leeway.
12. Mrfancypants explains how Shaun Inman's site pegs his CPU.
Shaun's site doesn't use sIFR. Additionally, it replaces quite a few
blocks of text (upwards of 100 sometimes) with Flash. This use of
Flash replacement may be a bit overzealous and I'm sure once Shaun
stops being insanely busy creating other great things for the world
like Shortstat, he will address this. Do not pin it on sIFR though.
13. Civil_Disobedient goes off on how Salon.com crashes his
significant other's Win 98 machine. Sorry, that's not my problem, nor
is it caused by sIFR (which Salon.com obviously doesn't use).
And so there you have it. Let's cut the nonsense. I usually don't
respond to this sort of discussion but I just couldn't stand to watch
this flow of misinformation to continue feeding on itself. To the
people who have maintained the sanity on this thread, I thank you. To
the 4 or 5 others who continue to pollute the pipes with your own
biases and misgivings, thanks for wasting the last hour of my life.
I'll close with what I believe to be the salient points about sIFR:
1. sIFR provides an easy cross-platform, cross-browser way to display
rich typography to approximately 95% of the world. The other 4.9% will
see CSS-styled HTML text. And the remaining .1% may unfortunately run
across the ad-blocking issues that have been discussed here. I do take
the ad-blocking issues seriously and I feel there is a very easy way
these companies can release much smarter ad-blockers. Perhaps I'll
have a chat with some of them. So for for the small handful of sIFR
haters on this thread, if you want to hang your entire argument on a
Flash-blocking issue, go ahead... once a measurable portion of the
population is affected, perhaps we'll have a better solution.
2. sIFR does not touch your code and thus has no effect on indexability
of your site, the accessibility of your site to screenreaders, nor the
long-term architecture of it. It can be implemented in about 10
minutes and removed in about 10 seconds. It is not a permanent
solution, but just an extremely elegant and useful hack.
3. sIFR is best used in a judicious manner... 1-4 headlines per page
maybe. It is not meant for body copy but for display type.
4. sIFR is not for everybody and if you don't wish to use it, then
don't. That doesn't mean you should require that nobody else in the
world use it. Your web site is yours and yours alone. The market will
decide whether or not you are making good design decisions with it.
5. The javascript which powers sIFR is some of the best object-oriented
javascript you'll ever see. Mark Wubben has spent an inordinant amount
of time on the JS-side of the technique, so for you code geeks out
there who think sIFR is a "Flashy designer thing" take a look at the
javascript source code. It's quite beautiful.
6. Finally, if this thread has taught you anything, I hope it's that
when evaluating anything new, it is most important to know the facts.
The internet makes it very easy for people like Gimonca,
Civil_Disobedient, and others to come across as experts based solely on
the volume and voracity of their posts. As we see from the unraveling
of the nonsense, nothing could be further from the truth.
Cheers, and I hope everyone has a great new year. Continue pushing the
limits of this great medium we work on. The only way for it to achieve
its true potential is through the extending of boundaries. Those who
say sIFR is not an end-all-be-all solution are correct... but it gives
us one important thing today which we'd otherwise have to wait years
for: rich, accessible typography. And that's a good enough for me.
Cheers,
Mike
posted by erisfree at 11:53 AM on December 31, 2004
Thank you even further to those who have taken the time to actually understand sIFR and *then* comment on this thread.
Translation: Thank you even further to those who have taken the time to actually understand sIFR and come to the same conclusions I do and *then* comment on this thread.
I'm afraid that "rich, accessible typography" is pretty much the last thing I want from the web. I want content, I want it presented in the two faces that I have chosen for their great readability on my system, and I want my typeface and typesize preferences to be respected.
posted by five fresh fish at 12:21 PM on December 31, 2004
Translation: Thank you even further to those who have taken the time to actually understand sIFR and come to the same conclusions I do and *then* comment on this thread.
I'm afraid that "rich, accessible typography" is pretty much the last thing I want from the web. I want content, I want it presented in the two faces that I have chosen for their great readability on my system, and I want my typeface and typesize preferences to be respected.
posted by five fresh fish at 12:21 PM on December 31, 2004
I appreciate erisfree posting Mike's comments, and further appreciate Mike taking the time out to clarify his position against the scathing, bitter comments of people like Civil_Disobedient. But the casual grouping of those who disagree with you as "uninformed" loud-mouths, better suited to "megaphones on streetcorners, leaflets, sandwich boards, chain-letters, and other avenues of ill repute," is not appreciated. Believe it or not, some of us are IT professionals, and have been doing this since the beginning. We've implemented our own various hacks to get things to work. We appreciate a good hack when we see it. But we know it for what it is: a hack.
Mike, your implementation is clever. I've seen lots of clever attempts to "fix" the web -- Dan Steinman's DOM-hack to create cross-browser DHTML compatibility comes to mind -- but these are band-aids.
posted by Civil_Disobedient at 1:16 PM on December 31, 2004
Mike, your implementation is clever. I've seen lots of clever attempts to "fix" the web -- Dan Steinman's DOM-hack to create cross-browser DHTML compatibility comes to mind -- but these are band-aids.
Civil_Disobedient brought up Microsoft's WEFT technology claiming it's the way to go. I cover WEFT in my sIFR article. I love the idea and I wish it worked better. It just doesn't though and that's part of why Microsoft dropped support for it.Embedded font technology is the way to go, not necessarily Microsoft's proprietary implementation. And hell, WEFT is almost a decade old, man. I'm frankly surprised it still works, but there you go.
First of all, it looks terrible without ClearType turned on (over half of PCs have it turned off or just don't even support it at all).As I said before, false. It looks fine on my CRT (Windows XP, ClearType off).
Second of all, it only works in PC/IE.So? That's like General Motors telling Preston Tucker, "Why should we install seat belts? So far you're the only one doing it." How does this even factor into the argument? If you've got a problem with the technology, by all means have at it. But saying, "Nobody else does it" is pretty piss-poor rationale to dismiss it outright.
And third of all, it has other display quirks which make it less than ideal.What display quirks are you talking about that are independent of the operating system? If you send the fonts over to the user, and their OS or browser mangles the fonts, that's not a problem with the base technology.
And given the bleeding-heart, open-source slant of this discussion, I'm surprised anyone is even mentioning WEFT.Give me a fucking break.
Civil_Disobedient claims that text is not zoomable. I understand that part of being a civil disobedient is not doing things that civilized people do (like "read") [...] Most people who have problems seeing small text surf the web with text zoom always turned on. They don't adjust font sizes for every page they hit.Mike, do you get paid to be a prick, because really, you're quite good at it. One of the problems with designers being given free-reign with fonts is that they make webpages with teensy-tiny text completely arbitrarily. I understand your "best usage strategy" dictates that it only be used for headlines. But you'll have to forgive me if I'm not more than a little skeptical that everyone will follow your (very lengthy) guidelines.
posted by Civil_Disobedient at 1:16 PM on December 31, 2004
Re: screen readers. The problem which was posted to his own blog back in September applies to both his carefully-controlled demos and to the real-world implementations various people here have dug up. I'm sure he knows it's a problem which is built right into the concept itself and is simply unsolvable.
Re: character sets. Nobody should ever have a problem entering an ñ or é. If they do, that's a sign of a serious problem with the model being used, that that could even happen in this day and age. Incidents like that are a step backwards 25 years in time--unforgivable.
you just need to choose which to enable (in order to keep filesize of the .swf down...this is by design). --a huge step backwards. I could understand not embedding a Hangul font that wasn't being used, but characters in Latin-1? That hasn't been an issue in normal environments in recent memory.
Re: google rankings. Snarks aside, there's no way to tell for sure one way or the other without having insider info from Google. Text in a headline that would occur in a search is likely to occur in body text as well. It's very amusing that searches for popular sports figures seem to pull up the non-Flash-replacement player stats pages right away, but that regular articles with Flash-replacement are buried several pages of results deep. One possibility is that this is the result of paid placement, or hand-picking by Google staff, and has nothing to do with good or bad code, but that's just speculation. It's also possible that an H1 within a NOSCRIPT is ranked lower than a real H1, but again, just speculation. (But it was very amusing to see fan blogs, the Modesto Bee, baseball card sites, personal pages about somebody's uncle who was also named "Pedro Martinez", before I ever got to the pages with Flash-replacement. Count that as a snark.)
The real issue with these and the various other issues that have been brought up is that they all involve breaking the most basic best practice of the web: Don't introduce unnecessary complications. There was no reason to start out down this inadvisable path to begin with, but extra possible points of failure were introduced at multiple points along the way, upgrade and compatibility issues were introduced where none existed before, problems which had long been solved had to be solved again (and not all were). And to what benefit? None.
The second lesson here is that one can't use "open source, standards-compliant and accessible" as though it were a "New, Improved Taste" blurb on a box of cereal.
posted by gimonca at 2:46 PM on December 31, 2004
Re: character sets. Nobody should ever have a problem entering an ñ or é. If they do, that's a sign of a serious problem with the model being used, that that could even happen in this day and age. Incidents like that are a step backwards 25 years in time--unforgivable.
you just need to choose which to enable (in order to keep filesize of the .swf down...this is by design). --a huge step backwards. I could understand not embedding a Hangul font that wasn't being used, but characters in Latin-1? That hasn't been an issue in normal environments in recent memory.
Re: google rankings. Snarks aside, there's no way to tell for sure one way or the other without having insider info from Google. Text in a headline that would occur in a search is likely to occur in body text as well. It's very amusing that searches for popular sports figures seem to pull up the non-Flash-replacement player stats pages right away, but that regular articles with Flash-replacement are buried several pages of results deep. One possibility is that this is the result of paid placement, or hand-picking by Google staff, and has nothing to do with good or bad code, but that's just speculation. It's also possible that an H1 within a NOSCRIPT is ranked lower than a real H1, but again, just speculation. (But it was very amusing to see fan blogs, the Modesto Bee, baseball card sites, personal pages about somebody's uncle who was also named "Pedro Martinez", before I ever got to the pages with Flash-replacement. Count that as a snark.)
The real issue with these and the various other issues that have been brought up is that they all involve breaking the most basic best practice of the web: Don't introduce unnecessary complications. There was no reason to start out down this inadvisable path to begin with, but extra possible points of failure were introduced at multiple points along the way, upgrade and compatibility issues were introduced where none existed before, problems which had long been solved had to be solved again (and not all were). And to what benefit? None.
The second lesson here is that one can't use "open source, standards-compliant and accessible" as though it were a "New, Improved Taste" blurb on a box of cereal.
posted by gimonca at 2:46 PM on December 31, 2004
With all the talk about Microsoft's font embedding technology, I'm surprised no one has mentioned Bitstream's. (Yeah, it probably doesn't work in your browser. It works in Netscape 4, but even Netscape dropped support for it when no one else jumped on the bandwagon.) Honestly, I never understood why it didn't catch on. I used it for a long time on one of my sites, but eventually no one was using any browsers that supported it, so I gave up.
If Mozilla/FireFox/etc. would include that technology I would be very, very happy.
posted by litlnemo at 3:26 PM on December 31, 2004
If Mozilla/FireFox/etc. would include that technology I would be very, very happy.
posted by litlnemo at 3:26 PM on December 31, 2004
erisfree: thanks for posting Mike's comments. I'm glad he spoke up for his "child" on the record here and outed the gross inaccuracies and those who were complaining about pages that didn't even use sIFR (or used an early version).
Those of you pushing WEFT, I'd really like to see some URLs to some of the beautiful sites you designed using the technology. I'd like to take a look at them when I go back to work on Monday and have access to one of those craptacular Windows machines running IE.
posted by spock at 6:35 PM on December 31, 2004
Those of you pushing WEFT, I'd really like to see some URLs to some of the beautiful sites you designed using the technology. I'd like to take a look at them when I go back to work on Monday and have access to one of those craptacular Windows machines running IE.
posted by spock at 6:35 PM on December 31, 2004
Right now we have no evidence that any version of sIFR, or any Flash-replacement hack, works in Jaws. The "you didn't use the latest version" shell game doesn't apply--examining the code suggests that it has never, and will never, work. It's inherent in the very model of what is being done.
Asked a search engine consultant friend of mine this evening over cocktails--his opinion was that sIFR's code would have a small negative effect on search engine rankings, that text in an H1 buried in NOSCRIPT would not be indexed and ranked as well as that in a simple Hn tag. (But, as I've pointed out, we can't know for sure without internal access to what the various indexing criteria are.)
Within the last day or so (yes, that's the current version), problems with Latin-2 and Cyrillic are being posted. Again: unnecessary complications. Maybe "everyone should just speak English"--would that solve the problem?
posted by gimonca at 11:34 PM on December 31, 2004
Asked a search engine consultant friend of mine this evening over cocktails--his opinion was that sIFR's code would have a small negative effect on search engine rankings, that text in an H1 buried in NOSCRIPT would not be indexed and ranked as well as that in a simple Hn tag. (But, as I've pointed out, we can't know for sure without internal access to what the various indexing criteria are.)
Within the last day or so (yes, that's the current version), problems with Latin-2 and Cyrillic are being posted. Again: unnecessary complications. Maybe "everyone should just speak English"--would that solve the problem?
posted by gimonca at 11:34 PM on December 31, 2004
(Note that, yes, the latest version of sIFR doesn't use NOSCRIPT--but it's not in production anywhere. Examine the code actually in use in sites that use Flash-replacement for examples. Oh, and that page crashes at least one install I have of Firefox 0.9.1 on XP.)
posted by gimonca at 11:45 PM on December 31, 2004
posted by gimonca at 11:45 PM on December 31, 2004
Here you go, spock (just off the top of my Googling). http://www.sindhicomputing.com/
posted by Civil_Disobedient at 8:21 AM on January 1, 2005
posted by Civil_Disobedient at 8:21 AM on January 1, 2005
Well, I'm done after this comment, so feel free to have the last inaccurate shrill words fellas. I can't speak with authority on the subject, since I don't use Jaws, but a little googling shows that any problem may again not be sIFRs fault:
From: http://www.mikeindustries.com/blog/archive/2004/09/sifr2-kick-the-tires:
This is such a huge move forward for the web. Seriously. I'm ecstatic.
By the way, for those of you who are interested, I tested this with JAWS screenreader, and I can tetatively say that it works. JAWS is a little strange about the order in which it reads the elements of the page, but if you tell it to read everything from the top of the page on down, it works beautifully.
and...
Alright! Thanks to Justin Cone, we have our first confirmed report that sIFR is JAWS-friendly.
By the way Justin, I think the issue you mentioned about order of screenreading is more related to the source-ordering of my floats, rather than the use of this method. I believe JAWS goes by source-order. Feel free to correct me if I'm wrong.
... so I wouldn't be surprised if once again you are blaming sIFR for some other problem in the page code. This has pretty much been the pattern here. You guys object to something, blame it on sIFR, then have to be told that the page doesn't even use sIFR. Or you pop off with something, realize it doesn't apply (or no longer applies, as with the NOSCRIPT comment above) so you try to correct yourself before somebody else does.
If you felt that you had a serious concern and really wanted an answer, you wouldn't be posting about it here. But posting about it here makes you less accountable. Say it positively enough and maybe you'll sound like you know what you are talking about.
Clearly the sIFR developers are concerned about accessibility and are working to make it better. I would expect more documentation to be available when the final release comes out that assists those wishing to put it to good use. Diagnosing particular product's foibles is part of the process.
posted by spock at 10:41 AM on January 1, 2005
From: http://www.mikeindustries.com/blog/archive/2004/09/sifr2-kick-the-tires:
This is such a huge move forward for the web. Seriously. I'm ecstatic.
By the way, for those of you who are interested, I tested this with JAWS screenreader, and I can tetatively say that it works. JAWS is a little strange about the order in which it reads the elements of the page, but if you tell it to read everything from the top of the page on down, it works beautifully.
and...
Alright! Thanks to Justin Cone, we have our first confirmed report that sIFR is JAWS-friendly.
By the way Justin, I think the issue you mentioned about order of screenreading is more related to the source-ordering of my floats, rather than the use of this method. I believe JAWS goes by source-order. Feel free to correct me if I'm wrong.
... so I wouldn't be surprised if once again you are blaming sIFR for some other problem in the page code. This has pretty much been the pattern here. You guys object to something, blame it on sIFR, then have to be told that the page doesn't even use sIFR. Or you pop off with something, realize it doesn't apply (or no longer applies, as with the NOSCRIPT comment above) so you try to correct yourself before somebody else does.
If you felt that you had a serious concern and really wanted an answer, you wouldn't be posting about it here. But posting about it here makes you less accountable. Say it positively enough and maybe you'll sound like you know what you are talking about.
Clearly the sIFR developers are concerned about accessibility and are working to make it better. I would expect more documentation to be available when the final release comes out that assists those wishing to put it to good use. Diagnosing particular product's foibles is part of the process.
posted by spock at 10:41 AM on January 1, 2005
That's from last September. Why not the most current version?
That page did not work for me in Jaws.
posted by gimonca at 10:50 AM on January 1, 2005
That page did not work for me in Jaws.
posted by gimonca at 10:50 AM on January 1, 2005
(And yes, we're talking about "The Gothic Times" page.)
posted by gimonca at 11:02 AM on January 1, 2005
posted by gimonca at 11:02 AM on January 1, 2005
Spock, aren't you missing odinsdream's point by saying that JAWS incompatability is "not sIFR's fault"?
As my old high school english teacher used to say: "I don't care if it's not your fault. It's your problem."
posted by lodurr at 12:01 PM on January 1, 2005
As my old high school english teacher used to say: "I don't care if it's not your fault. It's your problem."
posted by lodurr at 12:01 PM on January 1, 2005
... and finally, my parting shot: It's amazing and revealing to me that there's been such passionate defense of sIFR in this thread, because aside from a few individuals, the worst of the criticism has amounted to "this is a bandaid and really shouldn't be used on a production sites."
For a real professional webmonkey, that should be a pretty non-controversial assertion. If it's necessary to expend much energy defending some technique against that kind of argument, there's a really good probability that the technique actually shouldn't be used on a production site.
Now, I've been working on or managing corporate websites and web apps since 1997. I would use sIFR if someone with sufficient impact on my performance appraisal wrote upon the wall that I had to (which could reflect a failure of communication on my part, I hasten to add), but otherwise, it's clearly not something that's justifiable via business case. The cost:benefit just isn't there for a production site or web app. Personal and portfolio sites are a whole 'nother smoke.
posted by lodurr at 12:12 PM on January 1, 2005
For a real professional webmonkey, that should be a pretty non-controversial assertion. If it's necessary to expend much energy defending some technique against that kind of argument, there's a really good probability that the technique actually shouldn't be used on a production site.
Now, I've been working on or managing corporate websites and web apps since 1997. I would use sIFR if someone with sufficient impact on my performance appraisal wrote upon the wall that I had to (which could reflect a failure of communication on my part, I hasten to add), but otherwise, it's clearly not something that's justifiable via business case. The cost:benefit just isn't there for a production site or web app. Personal and portfolio sites are a whole 'nother smoke.
posted by lodurr at 12:12 PM on January 1, 2005
One of the reasons that I subscribe to blog and news sites' RSS feeds (whenever they are offered) is so that I don't have to put up with the design decisions someone else thought were good ideas. I'm just saying.
posted by moonbiter at 1:32 PM on January 1, 2005
posted by moonbiter at 1:32 PM on January 1, 2005
There are many negative opinions here about sIFR, and most of them are missing the point.
Some have got even more out of hand and ended up with Civil_Disobediant describing the main developer of sIFR as "being paid to be a pr**k", and asking to us to "give me a f**king break". In the same post he asks us to consider that he is a "web professional". I don't envy anyone that has a professional relationship with you. Not to mention a professional disagreement.
sIFR has it drawbacks and everyone is aware of them. It won't stop its usage increasing over the next year. My guess is that when the first examples of image replacment were unveiled on the web, similar rather crazy and personally insulting comments could be read here - from the likes of majick and Civil_Disobediant.
You might as well be pissing in the pacific guys.
I'm not going to make any more comments about sIFR as it has been done to death here. But feel free to use your "megaphones and sandwich boards" to continue your fight against the inevitable. However, I think everyone would rather if you put the personal insults to one side.
posted by andyhume at 7:30 AM on January 2, 2005
Some have got even more out of hand and ended up with Civil_Disobediant describing the main developer of sIFR as "being paid to be a pr**k", and asking to us to "give me a f**king break". In the same post he asks us to consider that he is a "web professional". I don't envy anyone that has a professional relationship with you. Not to mention a professional disagreement.
sIFR has it drawbacks and everyone is aware of them. It won't stop its usage increasing over the next year. My guess is that when the first examples of image replacment were unveiled on the web, similar rather crazy and personally insulting comments could be read here - from the likes of majick and Civil_Disobediant.
You might as well be pissing in the pacific guys.
I'm not going to make any more comments about sIFR as it has been done to death here. But feel free to use your "megaphones and sandwich boards" to continue your fight against the inevitable. However, I think everyone would rather if you put the personal insults to one side.
posted by andyhume at 7:30 AM on January 2, 2005
I'm going to type a ç here, just because I can. Good luck getting anyone to use a non-compliant product in Canadian or EU environments.
posted by gimonca at 7:49 AM on January 2, 2005
posted by gimonca at 7:49 AM on January 2, 2005
You might as well be pissing in the pacific guys.
That's right. Fuck us, eh! You're gonna do what you're gonna do, and damn anyone who disagrees!
Read what odinsdream just said. Really carefully. Word-for-word. Without trying to spin what he is saying.
Not a single end-user is crying out for headlines to be fancier. Anti-aliased headlines add nothing of value to the web. It is unnecessary.
posted by five fresh fish at 9:32 AM on January 2, 2005
That's right. Fuck us, eh! You're gonna do what you're gonna do, and damn anyone who disagrees!
Read what odinsdream just said. Really carefully. Word-for-word. Without trying to spin what he is saying.
Not a single end-user is crying out for headlines to be fancier. Anti-aliased headlines add nothing of value to the web. It is unnecessary.
posted by five fresh fish at 9:32 AM on January 2, 2005
"You're gonna do what you're gonna do, and damn anyone who disagrees!"
I, nor Mike, Mark, or Shaun or anyone else is making a decision on behalf of web developers. All they have done is provide an option, which so far has developed considerable interest within the community. The method is spreading widely all the time, as people learn what makes sIFR the breakthrough concept that it is - despite the potential drawbacks!
The point I was making is that the web is always going to evolve as developers see fit, and certainly not by sentimental, purist, and frankly old-school ideas of how content should be delivered.
As I said earlier: There was the same controversy about image replacement and look what happened!
posted by andyhume at 10:15 AM on January 2, 2005
I, nor Mike, Mark, or Shaun or anyone else is making a decision on behalf of web developers. All they have done is provide an option, which so far has developed considerable interest within the community. The method is spreading widely all the time, as people learn what makes sIFR the breakthrough concept that it is - despite the potential drawbacks!
The point I was making is that the web is always going to evolve as developers see fit, and certainly not by sentimental, purist, and frankly old-school ideas of how content should be delivered.
As I said earlier: There was the same controversy about image replacement and look what happened!
posted by andyhume at 10:15 AM on January 2, 2005
The sIFR team provided an option, true.
As did Netscape when it introduced the BLINK tag.
As did Microsoft when it pushed Passport on us all.
The two points I'm making are
This option provides no end-user benefits.
The sIFR supporters are telling us that they're going to shove this new trick up our asses.
Fine, whatever. I can assure you that if the sIFR hack causes me any trouble, I will simply cease to visit the offending website.
I question whether the risk of pissing people off is really worth taking, just for the designer-geek thrill of forcing fancy fonts into headlines.
You guys choose, and we end-users will choose. One way or the other, it'll sink or swim.
posted by five fresh fish at 12:03 PM on January 2, 2005
As did Netscape when it introduced the BLINK tag.
As did Microsoft when it pushed Passport on us all.
The two points I'm making are
Fine, whatever. I can assure you that if the sIFR hack causes me any trouble, I will simply cease to visit the offending website.
I question whether the risk of pissing people off is really worth taking, just for the designer-geek thrill of forcing fancy fonts into headlines.
You guys choose, and we end-users will choose. One way or the other, it'll sink or swim.
posted by five fresh fish at 12:03 PM on January 2, 2005
What popular sites actually use(d) dynamic image replacement? 'Cause I've never noticed it.
posted by mote at 3:16 PM on January 2, 2005
posted by mote at 3:16 PM on January 2, 2005
Some have got even more out of hand and ended up with Civil_Disobediant describing the main developer of sIFR as "being paid to be a pr**k"
Did you choose to ignore the quote that spurned that comment? Or was the text size too small for your browser? In case you missed it:
"Civil_Disobedient claims that text is not zoomable. I understand that part of being a civil disobedient is not doing things that civilized people do (like "read")"
I don't envy anyone that has a professional relationship with those who deliberately leave out information to bolster their non-sequitors.
posted by Civil_Disobedient at 6:21 PM on January 2, 2005
Did you choose to ignore the quote that spurned that comment? Or was the text size too small for your browser? In case you missed it:
"Civil_Disobedient claims that text is not zoomable. I understand that part of being a civil disobedient is not doing things that civilized people do (like "read")"
I don't envy anyone that has a professional relationship with those who deliberately leave out information to bolster their non-sequitors.
posted by Civil_Disobedient at 6:21 PM on January 2, 2005
What popular sites actually use(d) dynamic image replacement? 'Cause I've never noticed it.
Whenever examples have been cited, we've always gotten the "oh, that isn't the latest version" line.
posted by gimonca at 7:04 AM on January 3, 2005
Whenever examples have been cited, we've always gotten the "oh, that isn't the latest version" line.
posted by gimonca at 7:04 AM on January 3, 2005
Saavy users who find this annoying (and/or an impediment) will route around this. Expect to see a plugin for Firefox disabling sIFR at some point in the future if use of the latter becomes popular. Sadly, less saavy users will be left to the whims of designers both good and bad ...
Remember, sIFR doesn't kill people: bad designers kill people (or something like that).
posted by moonbiter at 8:11 AM on January 3, 2005
Remember, sIFR doesn't kill people: bad designers kill people (or something like that).
posted by moonbiter at 8:11 AM on January 3, 2005
Yes, that's a good point: dynamic image replacement could include libraries that generate a .gif on the fly.
posted by gimonca at 11:15 AM on January 3, 2005
posted by gimonca at 11:15 AM on January 3, 2005
I've never run across anything besides designers' personal pages or someone's blog that actually uses dynamic text/image replacement, but if anyone has seen it used professionally, I'd like to know.Here is an example of professional use; I just put this live yesterday. The primary navigation, the secondary navigation, and this particular page's main content are all done using image replacement. (View the source and you'll see what I mean...there's not a single img tag in the HTML!) No, it's not "dynamic," but it's a technique that is currently being used quite a bit, imo. (And it's the exact case that sIFR improves on.)
Now, this is an extreme example; I was hired to preserve their existing site design / layout while transitioning the code from table-based HTML to XHTML/CSS. Given that that was my mandate, image replacement made a lot of sense, since I could keep their current images but make the code a lot more friendly for Google / screen readers. Obviously there are long-term maintainability problems, but this was a baby step in the right direction.
And yeah, I tried to suggest that they turn that big image into regular text. No dice. At least it's the only page like that, thank god...
posted by flaneur at 9:00 PM on January 4, 2005
Browsing with graphics off, flaneur, I see nothing on that page. No text and, of course, no graphics.
Turning graphics back on gives me the menu graphics across the top but none of the main content graphics and still no text.
Opera, latest version, fyi.
Hitting reload does, of course, fix things.
posted by five fresh fish at 9:56 PM on January 4, 2005
Turning graphics back on gives me the menu graphics across the top but none of the main content graphics and still no text.
Opera, latest version, fyi.
Hitting reload does, of course, fix things.
posted by five fresh fish at 9:56 PM on January 4, 2005
five fresh fish: Yep, you've hit upon the biggest weakness of that method. In this particular case, I'd argue that a) that's the only page on the site that contains 'no' text and b) this particular client wasn't worried about the no-graphics audience segment (for better or worse).
Now, the interesting thing is that what this technique DOES let you do is create a second stylesheet that is essentially what you wanted -- text-only. Later this year I'm going to do exactly that, so that the site can be viewed on mobile devices in a mostly text-based format. It's a shame Opera reacts the way it does, since all the text is THERE...it's just that Opera's graphics hiding doesn't make the CSS wake up and go "oh, I'd better show this text now." Sadly. Thanks for the feedback though.
posted by flaneur at 11:06 PM on January 4, 2005
Now, the interesting thing is that what this technique DOES let you do is create a second stylesheet that is essentially what you wanted -- text-only. Later this year I'm going to do exactly that, so that the site can be viewed on mobile devices in a mostly text-based format. It's a shame Opera reacts the way it does, since all the text is THERE...it's just that Opera's graphics hiding doesn't make the CSS wake up and go "oh, I'd better show this text now." Sadly. Thanks for the feedback though.
posted by flaneur at 11:06 PM on January 4, 2005
it's just that Opera's graphics hiding doesn't make the CSS wake up and go "oh, I'd better show this text now."
I've communication with the developers. If you can explain what you mean more clearly, I'll pass the idea along.
I don't think it's reasonable to expect Opera to second-guess your CSS when graphics are disabled, but it might be reasonable to expect Opera to re-layout the page and/or re-run the Javascript when graphics are turned back on.
Unless, of course, re-running the JS would normally cause tons of problems on webpages that don't do silly things like replace text with graphics.
posted by five fresh fish at 10:19 AM on January 5, 2005
I've communication with the developers. If you can explain what you mean more clearly, I'll pass the idea along.
I don't think it's reasonable to expect Opera to second-guess your CSS when graphics are disabled, but it might be reasonable to expect Opera to re-layout the page and/or re-run the Javascript when graphics are turned back on.
Unless, of course, re-running the JS would normally cause tons of problems on webpages that don't do silly things like replace text with graphics.
posted by five fresh fish at 10:19 AM on January 5, 2005
Wow... that's all I have to say. What a bunch of knee-jerk reactions to something you didn't even take the 30 seconds to understand.
posted by karlshea at 11:28 PM on January 10, 2005
posted by karlshea at 11:28 PM on January 10, 2005
« Older Chuteless Jumps | (Hypothetical) Lovin, Touchin, Squeezin Newer »
This thread has been archived and is closed to new comments
posted by smackfu at 11:46 AM on December 29, 2004