Easier sIFR implemention with jQuery Plug-in

December 4, 2008 8:27 AM

Easier sIFR implementation with jQuery Plug-in. Web developers or typography aficionados may remember when sIFR was first mentioned and discussed (160 comments) on MeFi: Dec. 29th, 2004. Since then, when it has been mentioned on the Blue, it has mostly been by people who dislike it (or anything remotely related to Flash). Or, as expressed this comment by TKChrist, they have found it overly-complicated to implement. For those of you interested in giving it another look: the jQuery sIFR plug-in. If you do nothing else, check out the three examples using this approach.

(sIFR was mentioned in passing recently but was not mentioned in the discussion). (via WebAppers: "Hunting the Best Open Source Resources for Web Developers")

posted by spock (93 comments total)

WebAppers also points to (the FREE) browsershots.org. Browsershots makes screenshots of your web design in different browsers. It is a free open-source online service created by Johann C. Rocholl. When you submit your web address, it will be added to the job queue. A number of distributed computers will open your website in their browser. Then they will make screenshots and upload them to the central server here.

Amazingly handy. I think I need to add WebAppers to the "check daily" pile.
posted by spock at 8:37 AM on December 4, 2008 [1 favorite]

OK, I did what you demanded and checked out the three examples. When I hit the "sIFR this" button, the text disappeared. Am I free to go now?
posted by Horace Rumpole at 8:41 AM on December 4, 2008 [2 favorites]

Interesting. jQuerys most likely going to become a part of everything I do from now on (I’m working mostly with .net, and they’ve adopted it) so I can see this becoming a part of everything I do if designers push for it. TBH I think it’s probably been best for the world that adding fancy fonts to websites *hasn’t* been easy in the past.
posted by Artw at 8:42 AM on December 4, 2008 [1 favorite]

Kirk is shoving buck knives up his ass, Spock is babbling about sIFR plug-ins. This can mean only one thing.

The shipment of Romulan Ale has come in!
posted by Astro Zombie at 8:43 AM on December 4, 2008 [2 favorites]

I can't cut and paste. That's sort of a deal breaker for text on the internet.
posted by Skorgu at 8:46 AM on December 4, 2008

TBH I think it’s probably been best for the world that adding fancy fonts to websites *hasn’t* been easy in the past.

Totally agree. Verdana Nation!
posted by jbickers at 8:47 AM on December 4, 2008

This is about encoding plain text in Flash?

Oh yes, this will end very, very well. If not in this thread, then IRL.
posted by DU at 8:49 AM on December 4, 2008

Horace Rumpole - What browser are you using? Is JS enabled? TBH if the JS is failing and you're still seeing the text it's actually a good thing, as it demonstates a solid fallback position.

Skorgu - Cut and paste is working fine for me. What browser/OS are you on?
posted by Artw at 8:51 AM on December 4, 2008

What is there to get bent out of shape about? The plain text is still in the document.
posted by specialfriend at 8:53 AM on December 4, 2008

This is about encoding plain text in Flash?

In as non-destructive a way as possible, so the text is replaced after the page is loaded to preserve the original in case of the JS breaking, for accesability purposes and the almighty SEO. Also, generally, only for headings. I bet some dick designer will start demanding entire paragraphs of text with it sooner or later though.
posted by Artw at 8:54 AM on December 4, 2008

I'm sorry, but using a plugin to render type still sucks.

However with time and a bit of luck the CSS 3 server-side web fonts spec should render all of these hacks moot. I've been playing around with its support in the latest build of Safari, and it's very cool.
posted by Bora Horza Gobuchul at 8:55 AM on December 4, 2008 [3 favorites]

What is there to get bent out of shape about?

If it wasn't done well there would be a lot to get bent out of shape about. Not to say there aren't shoddy implementations of this kind of thing out there that cause trouble. It;s certyainly better than, say, having all your headers be .gif files and then not putting in alt text.
posted by Artw at 8:55 AM on December 4, 2008

Bora Horza Gobuchul - When the big three (which, let's face it, webkit is currently the most minor member of and most devs still think of as a big two) support it I'll totally go for it. Till then it's use a plug in that works acorss the big three or don't do it at all.
posted by Artw at 9:00 AM on December 4, 2008

We tried sIFR when we redesigned our site, and because it loads a flash movie for each character our site almost tanked. sIFR adds so much weight to a page that it's only really good for technology demos. That all being said it's a neat, well thought out hack.
posted by Jeff_Larson at 9:00 AM on December 4, 2008

Artw: FF 3.0.4-1/Linux(Arch). And nevermind, it fills the app clipboard not the X clipboard. Mildly better I suppose but it would drive me nuts if it were commonly used.
posted by Skorgu at 9:08 AM on December 4, 2008

Surely this is redundant when firefox 3.1 is released?

As FF3.1 supports @font-face. Webkit already supports @font-face, so we're fine for Safari 3+ and Chrome. I think Opera has support for it - or at least it did in v9.5. And Internet Explorer, even v6 has some support of @font-face. Although for IE you have to encode the fonts as *.eot files using WEFT.

WEFT is a bit rubbish; it looks like something from Windows 3.1 and only lets you embed fonts you have installed in your "c:\windows\fonts" directory rather than any old fonts on your machine. Which is frustrating when it comes to testing - as you'll have the fonts installed and so they'll display anyways. You'll either need to uninstall or have a test machine...


(ok sure you can say "yeah but ie5.5/firefox2/firefox3/random unknown never heard of browser doesnt support it. Big deal. Give them loads of Arial, Verdana and Georgia)
posted by 13twelve at 9:10 AM on December 4, 2008

Needless to say it doesn't work too well if you've got Flashblock. If there weren't so much terrible, gratuitous Flash out there, Flashblock wouldn't be necessary. It's easy enough to click to enable a Flash embed if it's what you actually came to see but the rest of the time I want that noise off, and it renders this thing useless. Also, how's this behave on the ultralight underpowered portables that are becoming fashionable now?
posted by George_Spiggott at 9:14 AM on December 4, 2008

Wouldn't it be awesome if HTML just let you specify a proper font directly? Oh, yeah, it sort of does, only it's never worked right and you have copyright problems.
posted by Nelson at 9:15 AM on December 4, 2008

I'd take CSS actually being useful for vertical positioning over that.
posted by Artw at 9:17 AM on December 4, 2008 [2 favorites]

George_Spiggott - out of curiosity, are you getting the plain text, or just a blank and an error? If people with flashblock get plaintext then TBH I can live with that.
posted by Artw at 9:18 AM on December 4, 2008

Besides, it's less burdensome on the client to just automatically render the text as an image on the server side, either during the article creation or the first time it's request, and with a proper server-side caching or storage model the performance hit would be nonexistent unless your headings were ridiculously dynamic. And the ALT text should make the SEO types happy,

Artw, the Flashblock graphic indicator appears for a moment, then vanishes.
posted by George_Spiggott at 9:22 AM on December 4, 2008

I feel like. This is just making a bad idea easier. sIFR is neat-o and a cute trick, but it adds a ton of weight, causes semantic nightmares and disables copy-paste, which is, as far as I'm concerned, breaking the internet.

At worst this gives everyone free reign to turn the internet into a giant MySpace. At best it allows sloppy developers and kids in Web Dev 101 to wow their friends and crush their servers. This is better as a case study than an application, me thinks.
posted by GilloD at 9:29 AM on December 4, 2008 [1 favorite]

George_Spiggott, surely text-indent: -9999em; ftw ?
posted by 13twelve at 9:29 AM on December 4, 2008

Doesn't work on iPhones, of course.

But, then, not many people have those...
posted by LordSludge at 9:29 AM on December 4, 2008

...automatically render the text as an image on the server side... ...ALT text...

Fuck that. That's just .gif headers again, with added complexity.
posted by Artw at 9:29 AM on December 4, 2008

This looks like an excellent solution to a problem I wish I didn't have but have all the time anyway. Designer hands you a comp where a bunch of sidebar headers (and frequently even links) are in some random font. You say "Can't we have these headers in text?" and the client says "No branding blah blah blah identity blah it has to be this crappy font." And then you say "If they ever want to change these links (and they will) someone's going to have to generate new images." and they say "Whatever just do it." And then you say "And the images will have to work against this gradient background you have under them too..." and they say "Shut up and build it." And you sigh and build yourself another maintainability tarpit because otherwise you'll never get paid.

So (naysayers): given the reality of the above, is this not a much better solution? I think so.
posted by rusty at 9:30 AM on December 4, 2008 [1 favorite]

Wouldn't it be awesome if HTML just let you specify a proper font directly? Oh, yeah, it sort of does, only it's never worked right and you have copyright problems.

Fonts can't be copyrighted. The data in the actual font files can be copyrighted, but the font shapes are not protectable. Just imagine what a mess it would be if they were.
posted by delmoi at 9:35 AM on December 4, 2008

So (naysayers): given the reality of the above, is this not a much better solution? I think so.

Why not just build the images server side and serve them as png files?
posted by delmoi at 9:36 AM on December 4, 2008

I don't see how .gif headers are inferior to this. No client-side JS or plugin burden, a reasonably bandwidth-efficient format for something that's essentially two colors plus antialiasing, and it can be automated on the server side so the publisher doesn't have to think about it. Perhaps the only down side is that the implementation details for generating and caching it would be different for different publishing systems, whereas with this you just embed in HTML.

On preview: delmoi, read moar.
posted by George_Spiggott at 9:38 AM on December 4, 2008

Because not everyone wants to maintain and host bit of code that generates .png from arbitary text, because there are height and width issues that sIFR deals with which are more complex than it may at first appear, because if you don't do some kind of sIFR like text replacement it's basically the same as crappy .gif headings with alt text, and because this theoretically should be more lightweight. Basically.
posted by Artw at 9:40 AM on December 4, 2008

delmoi: Why not just build the images server side and serve them as png files?

Possible, but (a) you have to create the server-side thingy that does that, which is not always easy -- or at least not always as easy as just making your graphics guy do it, and (b) I'd say at least half the time the text is on top of some complicated background where the text has to include a matching background itself or it looks like shit. Transparency doesn't always do it. So automating that has to take into account where on the bg the thing is... it turns into kind of a mare's nest, and again we tend to just dump it on the graphics guy.

That said, I have no idea how sifr/flash handles backgrounds and transparency either, so that might be an issue.
posted by rusty at 9:44 AM on December 4, 2008

delmoi--

Fonts are programs -- full on, turing complete, programs.

I'm serious. There's an absurd amount of complexity that goes into determining how a font scales, and how to determine kerning. We take it for granted up until the moment we see fonts that were captured from images, with none of the logic intact. It ain't pretty.
posted by effugas at 9:48 AM on December 4, 2008 [1 favorite]

Never been a fan of how SIFR headlines fill in after the page load is done, and before that they are white boxes. If your browser decides to be slow loading Flash (low-memory or something), it's pretty ugly looking.
posted by smackfu at 9:48 AM on December 4, 2008

I realize that reading comprehension has gone to hell-in-a-handbasket in this country, but seriously: Some people see the word "plug-in" and you think we're talking about BROWSER plug-ins. For your information, we are not. If you don't want to grok the information, fine. But commenters' ignorance is the only thing on display when they make ignorant comments. Sorta like when people see the term "Flash" or "swf" and give themselves a black eye with their knee jerk reaction.
posted by spock at 9:49 AM on December 4, 2008

There probably are going to be times when the .png/.gif solution IS the better solution, but TBH I’m think they’re going to be far outnumbered by the situations when really you should stop messing around with fonts and just use plain text.
posted by Artw at 9:49 AM on December 4, 2008

@font-face will require you to download the specified font (if you don't have it) in order to see it. Tell me how this is good? This was tried back in the late 90's with so much success that few even remember it today.
posted by spock at 9:52 AM on December 4, 2008

Flash = fans spinning up on my Mac, because Adobe only have one Mac in their development shop, and it doesn't work right.

So I need a screaming Mac to read some text? Fuck that. And Fuck Flash.
posted by bonaldi at 9:52 AM on December 4, 2008 [1 favorite]

I can copy the sIFR text. What's with all the complaints that this breaks copy/paste?
posted by niles at 9:53 AM on December 4, 2008

Flash = fans spinning up on my Mac, because Adobe only have one Mac in their development shop, and it doesn't work right.

I think you maybe underestimating the degree of interest the makers of Photoshop have in the mac market.

(TBH if your mac chokes on flash that much your’re best off turning it off entirely and getting the text only version, though TBH any site that uses this will probably feature something else that;s going to break your machine anyway. )
posted by Artw at 9:58 AM on December 4, 2008

Spock, the two commenters (me and Bora) who have used the word plug-in the client-side sense were referring to the Flash plug-in; no ignorance involved. I've developed extensively in Flash since 1999, I have nothing against it. I'm against inappropriate use of anything, even technologies that I like, and unfortunately Flash is used all over the web to run 5 simulataneous ad animations, some of which float across your screen, others of which have the cheek to include audio. Some of us pretty much have to take matters into our own hands and throttle Flash even if we'd rather not.
posted by George_Spiggott at 10:00 AM on December 4, 2008

I do not love, nor use, sIFR. however, there is a lot of bad information in this thread.

sIFR creates one flash movie per called instance (block of text it is called on), not per character.

Cut and paste still works just fine, which is one of the main advantages of this over image-based headlines.

The semantic structure of the page is not affected.
posted by Nothing at 10:05 AM on December 4, 2008

I think you maybe underestimating the degree of interest the makers of Photoshop have in the mac market.

No, I'm really not. Look at the performance difference in After Effects between Windows and Mac. Flash is even worse. Hulu takes 7% of a Windows CPU, and 70% of a Mac one. The Mac installer boondoggle speaks for itself, too.

This was a company that cared about the Mac -- it depended on it, in fact. That's history, as it's now managed by morons, marketers and layoff-merchants.

(TBH if your mac chokes on flash that much your’re best off turning it off entirely and getting the text only version, though TBH any site that uses this will probably feature something else that;s going to break your machine anyway. )

Well, yes, precisely. Flash is pretty much blocked everywhere on my Mac apart from YouTube and iPlayer, and I never miss it. So seeing people using such a hateful hunk of code for what is actually a laudable purpose is depressing.
posted by bonaldi at 10:13 AM on December 4, 2008

I can imagine the conversation…

Client: We want you to use fancy flash fonts!
Me: OK, I’d sooner not, theres a way we can do that which will fall back to text for people without flash, people without JS and for screenreaders and search engines. It’ll work on all major browser/OS combinations.
Client: Great! Any downsides?
Me: Hmm… if people are using an adblocker to block your flash adverts it won’t show up.
Client: Well fuck them.
posted by Artw at 10:15 AM on December 4, 2008 [1 favorite]

Me: Hmm… if people are using an adblocker to block your flash adverts it won’t show up.
Client: Well fuck them.
Client: I don't understand what that means. But figure out a way to make it work for them, too.
posted by junesix at 10:28 AM on December 4, 2008 [3 favorites]

Isn't the worst thing that can happen be that you see the unstyled/non-Flash™ text? Or are there some cases where you see nothing (no heading).

This whole conversation should be prefaced with the impracticality of using this technique for body text. I'd recommend using it only for heads/subheads.
posted by spock at 10:41 AM on December 4, 2008 [1 favorite]

Cripes, the Mac OS X version of After Effects is absolutely smoked again, and the results are slightly worse than last time in places. Either Adobe isn't tuning After Effects on the Mac at all, or tuning the buhjeezus out of the Windows versions.

Theres a possibilty there they haven't really addressed...
posted by Artw at 10:45 AM on December 4, 2008

As I understand it, if you've got flash disabled, you should see the non-styled system text. That's a win-win.

And as others have stated, the genius of sIFR is that it's still live - you can highlight and copy it. That's worth a lot more than having it turn out a graphic.
posted by cusack at 11:06 AM on December 4, 2008

That article about flash on the Mac actually seems to indictae they're making efforts there to improve it, with some success in Flash 10.
posted by Artw at 11:14 AM on December 4, 2008

Yes, it's gone from abysmally appalling to merely hideously appalling. Could that be anything to do with their desperation to get it on the iPhone and Jobs's comments about what a performance dog it is, d'ye think? If this is the best they can do when it's part of a key business strategy, that's shite.
posted by bonaldi at 11:24 AM on December 4, 2008

Possibly this is a result of technical difficulties with getting the code to run on the Mac platform, rather than them not giving a shit or being out to give you a bad day?

FWIW I’ve not noticed any huge differences when mac-testing anything I’ve worked on that’s had a flash component, and also most of the flash developers I know work on macs, so it can’t be *that* horrible, surely?
posted by Artw at 11:31 AM on December 4, 2008

Possibly this is a result of technical difficulties with getting the code to run on the Mac platform, rather than them not giving a shit or being out to give you a bad day?

You've gotta wonder. They don't get an easy ride, certainly: apple fucks them about with framework changes something rotten, but Adobe is equally quick to complain vocally when a problem isn't their fault, and there's been nothing like regarding Flash.

so it can’t be *that* horrible, surely?
Oh, it can. It really can. It's bearable on a very powerful Mac, or one that has constant fans, but quieter and slower machines like MacBooks and the lesser iMacs really highlight the woe of the thing. If you see a Mac limping or hear it howling, chances are there's a browser window open somewhere running a Flash anim.

Look at the tests on Flash 10. 70% of a hefty cpu to play a shitty tiny video? That shouldn't bring down a machine, and there's not much more to it than that.
posted by bonaldi at 11:38 AM on December 4, 2008

The nature of video seems to be that it grabs as much CPU as it can. Seems to be that way on windows, anyway.
posted by Artw at 11:40 AM on December 4, 2008

Holy crap. This is just when I needed it. We had a client that fell in love with our typographical treatments but then their Developer put the kibosh oh using Flash due to issues with the CMS system and standards concerns. So we went pure web-standards. I wanted then to try sIFR but it has, in the past, been such bog of complications I hated to even mention it as an option.

But this will work. Thanks Spock.
posted by tkchrist at 11:58 AM on December 4, 2008

Me: OK, I’d sooner not, theres a way we can do that which will fall back to text for people without flash, people without JS and for screenreaders and search engines. It’ll work on all major browser/OS combinations.
Client: Great! Any downsides? I don't understand what "JS", "screenreader" or "search engine" means. Have it done by 7am.
posted by signal at 12:13 PM on December 4, 2008

I'd take CSS actually being useful for vertical positioning over that.

Soon, grasshopper. Soon.
posted by dw at 12:13 PM on December 4, 2008

No, I'm really not. Look at the performance difference in After Effects between Windows and Mac. Flash is even worse. Hulu takes 7% of a Windows CPU, and 70% of a Mac one.

Hmm, suddenly buying a Dell instead of a Mac is starting to look even smarter.
posted by signal at 12:14 PM on December 4, 2008

That will be really useful... in 4 years time when enough people are using browser that support it that I can actually use it.
posted by Artw at 12:16 PM on December 4, 2008

I'm so in-between on sIFR. I would love better typographical treatments. But I'm still so meh about Flash. And I still worry about making the sIFR stuff obviously accessible, even though it basically is now. But it's jQuery, which I'm really coming to love for being dead-simple (especially compared to other JS visual libraries).

I think I've just worked in higher ed too long and have oversaturated myself with higher ed's Flash anathema. Maybe it's time to actually spend some time working with Flash.

Wait, this is the Dark Side, isn't it?
posted by dw at 12:19 PM on December 4, 2008

Hmm, suddenly buying a Dell instead of a Mac is starting to look even smarter.

Suddenly buying a Dell? Was it out of the back of a van?
posted by heeeraldo at 12:59 PM on December 4, 2008

Soon, grasshopper. Soon.

The table element in HTML is a semantic structure: it describes what data is.

The semantics of the tag are present in the mind of the human reader or the disposition of the mechanical reader.

I'm familiar with no reason in this world or hell we couldn't have all adopted <table class="layout"> years ago, other than the fact that a lot of people drank the kool aid.

I did it too, and I'm glad I forced myself to learn css positioning as a layout tool, but it turns out I'm probably only into light bdsm.
posted by weston at 2:35 PM on December 4, 2008 [1 favorite]

If you do nothing else, check out the three examples using this approach.

Numerous spacing problems in Firefox 3.04. sIFR fails again.
posted by Blazecock Pileon at 2:44 PM on December 4, 2008

Which is to say that it fails quite ungracefully with a lack of Flash support. Graceful failure is the hallmark of good web design and why sIFR, itself, is not very useful.
posted by Blazecock Pileon at 2:46 PM on December 4, 2008

It does seem a bit like saying “well, you can do all that stuff you did with tables, but use DIVs instead and use a style that makes them pretend they’re tables”.

Also I suspect you’re still shit out of luck if you want to do height=100% without some kind of hack.
posted by Artw at 2:46 PM on December 4, 2008

Blazecock Pileon - Graceful failure *should* be what's good about sIFR. Any idea what's causing it to fail? Are you using any kind of ad block? That's seeming like the achilles heel so far.
posted by Artw at 2:49 PM on December 4, 2008

I've looked at using this: typeface.neocracy.org to accomplish similar design aethetics.
posted by keame at 4:04 PM on December 4, 2008

Actually, copy-and-paste has never worked transparently with sIFR, in that you can't select a page's text including both HTML and sIFR text and copy it.
posted by nicwolff at 4:26 PM on December 4, 2008

On Safari on MacOS, it breaks find, copy/paste, app services (email text, lookup in wikipedia, text to speech, etc). It tries to emulate copy/paste, but does so poorly (wrong highlighting colors, no heterogeneous selections, etc). Also, it overrides the right-click menu, which is fucked up. It probably also screws up when using non-default key bindings, but I can't be bothered to check.
posted by ryanrs at 4:37 PM on December 4, 2008

Also breaks increase/decrease text size.
posted by ryanrs at 4:40 PM on December 4, 2008

Doesn't seem to respond to the Zoom in IE7 either. I was thinking it would at least work when you visit the page in a zoom setting > 100%, even if it doesn't work on the fly, but no, the text remains at 100% while the flash area increases.
posted by Artw at 4:50 PM on December 4, 2008

I could accept these failings if this hack actually did something useful like play video or present an interactive game. But rendering text? Complete FAIL. And not just failure in execution, but failure in concept.
posted by ryanrs at 5:01 PM on December 4, 2008

See above about the designers and the clients and the horrif .gif headers you'd get otherwise.
posted by Artw at 5:02 PM on December 4, 2008

More godawful misuses of Flash. Listen: just because you can doesn't mean you should. Clear?
posted by mr. strange at 5:24 PM on December 4, 2008 [1 favorite]

Eh, fuck 'em. Ignorant clients and submissive designers, both. Perhaps someday they'll come to understand their site's insignificance, and maybe adjust their attitude. Nobody visits a site because of the 'branding'.
posted by ryanrs at 5:39 PM on December 4, 2008

I'm familiar with no reason in this world or hell we couldn't have all adopted years ago, other than the fact that a lot of people drank the kool aid.

Because it's a table tag, and the moment you use a table for data in the middle of a table for layout, you're going to send that mechanical reader down that Magrittian rabbit hole. And then you'd have to create a <table_for_data> which would have been even more kludgy than the awfully named div and span.

Semantics are good. Semantics are right. Semantics work. They are also a pain in the ass.
posted by dw at 6:55 PM on December 4, 2008

Semantics work.

But let me just ask, playing devils advocate for a moment, what do they actually DO?
Speaking only of thing that actually happen, of course, rather than things that theoretically should happen.
posted by Artw at 7:52 PM on December 4, 2008

But let me just ask, playing devils advocate for a moment, what do they actually DO?

They make it easier for machines to read a web page, whether it's a screen reader or a spammer's scraping tool.

In theory, it should also improve Googlebot's ability to understand the page and thus improve ranking. But I'm not sure that's true. I've never seen an SEO consultant recommend semantics, but that could be because SEOers barely understand the web.
posted by dw at 8:41 PM on December 4, 2008

Proper semantic coding makes greasemonkey scripting much easier. This greatly improves my web browsing experience.
posted by ryanrs at 9:43 PM on December 4, 2008

But does Google as it is ACTUALLY care whether you put your headings in H1 and H2s or if you just use DIV for everything?
posted by Artw at 11:09 PM on December 4, 2008

Because it's a table tag, and the moment you use a table for data in the middle of a table for layout, you're going to send that mechanical reader down that Magrittian rabbit hole.

That horse is already not only out of the barn, it's left the state and galloped through several time zones. The bridge has been crossed, dotted, underlined, and burnt. I could come up with more mixed metaphors, but suffice it to say, that a mechanical reader which counts on the semantics of the table tag being limited solely to tabular data is going to be confused by the bulk of existing web documents for years to come.

And then you'd have to create a <table_for_data> which would have been even more kludgy than the awfully named div and span

I'm not sure you *need* any distinguishing markup. I'd bet real money that a semi-sophisticated mechanical reader that depends on a few heuristics could actually distinguish between semantic tables and layout tables 90% of the time. I'd speculate an actually sophisticated one could keep out of rabbit holes 99.99% of the time.

If you want distinguishing markup to save mechanical readers some sniffing (a worthy goal), you don't need a different tag. The snippet I gave above ( <table class="layout|data"> ) works just fine without having to hack anything onto the standards. It's not doing anything microformats don't do by pushing some of the semantics into the class system.

Plus I'm not really convinced that <tabledata>, hackish as it would be, is objectively worse than shoehorning grid layout onto div, span, and any other container that can/will be conscripted.

Semantics are good.

I agree.

Semantics are right. Semantics work.

This seems to me to drift into kool-aid territory.

I think I get the value of semantics, I really do, and there is real also value in doing layout with CSS where it's somewhere between convenient and painful but possible. However, the purity campaign surrounding the table tag has problems to match its benefits. It actually pushes the advent of the semantic web back to the extent that it insists on waiting for a web where tables aren't used for markup, and time invested in all kinds of gymnastics just to get layouts that table markup achieved in 1997 is time that is not invested in something else.
posted by weston at 11:45 PM on December 4, 2008

But does Google as it is ACTUALLY care whether you put your headings in H1 and H2s or if you just use DIV for everything?

It's hard to say, mainly because the Google algorithm remains a black box. You get some SEO people who say yes, some who say no. They all agree that standards mean squat when it comes to SEO, but that's about whether a document validates, not whether it's semantic.

Does Google actually care? We don't know, and we'll probably never know.

That horse is already not only out of the barn, it's left the state and galloped through several time zones. The bridge has been crossed, dotted, underlined, and burnt. I could come up with more mixed metaphors, but suffice it to say, that a mechanical reader which counts on the semantics of the table tag being limited solely to tabular data is going to be confused by the bulk of existing web documents for years to come.

That's why they don't count on it being like that. But screenreaders work a heck of a lot better when you're not using tables for layout.

Honestly. The table/div war is over. What's left is a bunch of mandarins wringing their hands over HTML5 and XHTML 2.0 and CSS 3, which remain stuck far from finality because the movement fell apart under the weight of a lot of egos. Yes, 75% of what's out there is still tables, and it'll remain so, even as institutional sites continue to redesign using divs. Yes, Hixie and Lie will flail their arms and tilt at their windmills. But the war itself is over. We're just waiting for IE7 to get pushed from ther market by IE8 so the syncretism of display: table-cell can serve as the peace treaty between the two camps.

I'd bet real money that a semi-sophisticated mechanical reader that depends on a few heuristics could actually distinguish between semantic tables and layout tables 90% of the time.

JAWS can't. It just announces "table." And anyway, why try to make a table serve dual purposes? What you going to do, modify every old site to do this? Wouldn't it just be easier to start over again on the design at this point if you're going to crack open old code?

The snippet I gave above (<table class="layout|data">) works just fine without having to hack anything onto the standards. It's not doing anything microformats don't do by pushing some of the semantics into the class system.

No, you're using microformats wrong. Microformats are there to give semantics to things that do not have pre-existing semantic markup in HTML so that the data can be identified semantically, e.g. telephone numbers. Tables have been explicitly for tabular data since HTML 4. You're trying to force a meaning into a tag that does not carry that meaning -- same problem hCalendar has with using abbr to mash RFC 2445 formatted, machine-readable dates into calendar parts.

This seems to me to drift into kool-aid territory.

Or, you know, I could be riffing on a movie quote.

However, the purity campaign surrounding the table tag has problems to match its benefits. It actually pushes the advent of the semantic web back to the extent that it insists on waiting for a web where tables aren't used for markup, and time invested in all kinds of gymnastics just to get layouts that table markup achieved in 1997 is time that is not invested in something else.

You know, I'd have sympathy for someone saying that in 2003, but I have no sympathy for it now. It's been 5 1/2 years since ESPN went to a tableless layout. We have thousands and thousands of pages of best practices. We have reams of tips and tricks. We have tens of thousands of examples. The number of hacks that need to be used have dwindled as the problem browsers go away. There are better things in the pipeline between full support of the layout CSS attribute and the layout-based tags in HTML5, but right now it can be done, it is being done, and the excuses are starting to wear thin.

It's too hard to learn? Well, tough. Learn it or give it to someone else who knows. But this is how we do things now. Every HTML standard since 3.2 has stated that layout tables are bad juju. Every good designer I know avoids layout tables and only uses them when they truly are the best option. At the end of 2008, there's no excuse for any web designer to start clean-sheet using tables for layout.
posted by dw at 1:26 AM on December 5, 2008 [2 favorites]

>> a semi-sophisticated mechanical reader [..] could

> JAWS can't.

It's my understanding you're both right.
posted by ryanrs at 1:48 AM on December 5, 2008 [1 favorite]

We're just waiting for IE7 to get pushed from ther market by IE8

You know that IE6 is still at least 20%, right? When, roughly, are you expecting IE7 to get pushed out? And exactly how good are you trusting IE8 to be?

JAWS can't. It just announces "table."

If JAWS just announces table, then it doesn't meet the threshold for semi-sophisticated handling of the table tag that I'm talking about.

And anyway, why try to make a table serve dual purposes?

Because:
* it did serve them for a long time, effectively still does for a large portion of the web
* offering people an easy way to explictly signify intent for tables might be a more tractable way to make more of the web machine-readable than attempting to evangelize every last person and piece of software producing markup
* tables still do certain layout tasks more conveniently than CSS positioning techniques do

What you going to do, modify every old site to do this?

The burden of that question falls fall more heavily on the standards purists holding out a labor-intensive solution as the Only Right Way than on someone recommending a combination of a lightweight solution, a proposal for enhancing the capabilities of mechanical readers, and, where reasonable, modern standards.

No, you're using microformats wrong.

Microformats provide information about the semantics of a tag (and potentially, its contents) to a mechanical reader via class attributes. This is also what my hypothetical markup does. Suggesting specific semantic communications should be verboten is an interesting concept, but also more than a bit troublesome.

You're trying to force a meaning into a tag that does not carry that meaning

The table tag very clearly does carry that meaning to quite a few human readers. Some of whom might be more likely to classify the disposition of their tables before either investing time or money in completely re-working their markup.

Anyway, my suggestions aren't a way to entirely replace CSS positioning as a layout tool. They are potential ways to make do on sites that standards evangelists haven't converted. Or for sophisticated coders who are very standards-aware but may have found a layout task that is more suited for tables to signal to semantics-aware software that something is a layout table.

We have thousands and thousands of pages of best practices. We have reams of tips and tricks. We have tens of thousands of examples.

And despite all those resources, even if you're a person who's coded literally hundreds and hundreds of those "best practices" pages and learned reams of those tips and tricks over a period of five years, you can still frequently find yourself spending hours chasing down solutions to rendering bugs.

One might be perfectly capable of taking arbitrary design and turning it into valid semantic markup and CSS sans-tables for layout. Making the commitment to do so is still a tradeoff with costs. Those costs are frequently low enough and come with enough benefits that it's worthwhile. But in some cases, for some design or project constraints, those costs aren't acceptable, no matter what ESPN invested in it.
posted by weston at 5:00 AM on December 5, 2008 [1 favorite]

TBH I think it’s probably been best for the world that adding fancy fonts to websites *hasn’t* been easy in the past.

I favorited this SO HARD.
posted by rokusan at 5:02 AM on December 5, 2008

The more I think about it the more unhappy I am about display: table-cell as a solution. How on earth is <table> <tr> <td> hello </td> </tr> </table> worse than <div class=table> < div class=tr> < div class=td> hello </div> </div> </div>? You could maybe strip off one level of tagging but you’re still left with a simulated TR and TD structure.
posted by Artw at 9:27 AM on December 5, 2008

If anyone's looking for dynamic replacement of text with automatically generated images instead of Flash files -- which I personally think is a better solution -- see this article, "Dynamic Text Replacement", at A List Apart.

I don't think it's unreasonable to want text on the web to show up in the font you want -- the right font can communicate a wealth of emotional and aesthetic information. Not everything is plaintext; there's a reason fonts exist. You don't wonder why all magazines aren't printed entirely in Times New Roman, do you?
posted by webmutant at 9:43 AM on December 5, 2008

seconding the mention of http://typeface.neocracy.org/ -- it looks like an interesting potential contender to sIFR.
posted by verb at 11:43 AM on December 5, 2008

How does that work exactly? Is it basically the WEFT method mentioned above?
posted by Artw at 11:55 AM on December 5, 2008

Every time I see something like this, it just convinces me that rather than adding more and more junk into HTML, we should just scrap it and serve PostScript over HTTP instead.

I'm half-serious: there are existing renderers for virtually every platform you could want, and many have been heavily optimized over the years for hardware that's (by today's standards) very minimal. The hardware specs on some of those ultra-mobile laptops aren't that much different, and in most cases are better, than a lot of hardware RIP engines from a few years ago. There are also good free/open-source implementations, and it's old enough (at least the first version or so) that there are probably not any submarine patents lurking, either.

PostScript already has all the font-embedding issues worked out, and it's a full-on Turing complete programming language, so you don't need an add-on scripting language like JavaScript.

About the only thing it doesn't have -- at least that I know, but I could be wrong -- is links, and they're pretty trivial to add.

It's pretty clear that's where HTML is going, eventually: people want all sorts of fancy typography and pixel-level control over the page elements, but at the same time it doesn't make sense to send whole-screen bitmaps to the client. That's nearly the exact same problem that people had, when they started dealing with high-quality laser printers almost three decades ago.
posted by Kadin2048 at 7:09 PM on December 5, 2008

That's called "downloading a PDF" - it's not terribly popular.

Still- you can embed flash movies!
posted by Artw at 7:29 PM on December 5, 2008

Semantic and validating HTML doesn't mean anything to blind screenreader users in my experience. Meaningful link text, H1-H6, alt attributes and not requiring Javascript are important. The code you use to position things on the page they can't see? Doesn't matter. I'm with Artw and fellows on this one.

But hey, one blind user once pointed out to me that the very best page design uses frames. One frame has the navigation bar, one frame has the content: simple and easy to use for screenreader users. Try arguing that one to accessibility gurus. (Except me, of course!)
posted by alasdair at 1:47 AM on December 6, 2008 [1 favorite]

How on earth is <table><tr><td>hello</td></tr></table> worse than <div class=table><div class=tr><div class=td>hello</div></div></div>?

Ah, but the enclosing TR and TABLE elements will be automatically created, so all you need is <div class="td">hello</div> to get the whole effect.
posted by nicwolff at 9:53 PM on December 8, 2008

The example code appeared to replicate at least a TR TD structure, and a container level above that (though that one was probably nor necessary).
posted by Artw at 10:14 PM on December 8, 2008

No extra container is necessary at all - see my simple demo here (with Safari or Firefox).
posted by nicwolff at 11:37 PM on December 8, 2008