Posts from 2004

Remember my recently posted conversation with Molly?  Boy, am I ever feelin’ that today.  In spades.

Some of you have noticed earlier today that things were presentationally unstable.  Depending on when you dropped by, you would have seen raw document presentation with no author styles at all, or some chunks of the site’s usual styles but not others, or all of the usual styles with a few oddities thrown on top for good measure.  For a few hours, during which I had to attend to something else, the site was fine except that in IE/Win, the main content column was quite a bit wider than usual, and some bits of content were visually exceeding the edges of the design box.  All that was happening because I was turning styles on and off in an attempt to stop freezing Internet Explorer for Windows.

Freezing?  Oh, yes.  As in locking it up so that people had to use the Task Manager to force-quit the process.  There were probably a few reboots out there as well; there were at least a couple here in Casa de Meyer.  Ordinarily, I’d apologize.  Not this time.  If you want an apology, try finding the person or persons responsible for IE’s CSS handling, and demand an apology from them.  I’m not taking the rap for this.

To set the stage, let me back up a couple of days.  As I passed by Kat’s office, she called out, “Hey, how come my browser keeps getting screwed up?”

“Because it’s Explorer,” I said.  “Next question?”

“Ha ha.  Seriously, every time I try to view your ‘ten things to do in Cleveland‘ post, the computer crashes.  I think there’s something wrong with it.”

Grumbling, I wandered over to her computer.  Sure enough, the browser was completely frozen.  She’d already called up the Task Manager and was forcing the browser to quit.  She said it was the third time she’d had to do it.  As I watched, the screen went blank, then drew the desktop color and stopped.  The cursor appeared as an hourglass, and refused to change or even move.

Once the system had gone through a hard reboot, I fired up Netscape 7 and loaded up meyerweb.  I surfed around to various posts.  No problems at all.  I then launched IE and loaded up the home page.  No problem.  I went to the offending post.  Instant freeze.

After a few more invocations of the Fatal Freeze, I wandered out of her office again, muttering about Explorer and Windows and pondering the possibility that her computer had been infected with some kind of virus, malware, or other nastiness.  But then, the next day, I got some e-mail reporting similar problems.  Then Ian Firth managed to get a comment in about the problem on the post “Really Undoing html.css“, even though others were getting the Fatal Freeze on that very post.  And he mentioned that it was happening in both IE and FeedDemon—which meant it was something in IE’s rendering engine, since FeedDemon just wraps itself around the engine.  A similar report cropped up in the FeedDemon forums this morning, where it was mentioned that a similar problem had already been seen in the post “Standards Savings“.  (Not that anybody had actually bothered to tell me, but hey, whatever.)

So I fired up VirtualPC this morning and tested the problem for myself.  And sure enough, I was very quickly the latest resident of Lockup City.  So I started narrowing down the cause.  I’ll spare you all the nasty details (and foul language) of my bug hunt, and cut to the chase: the lockup was happening on entry pages where the post content included an element that used left padding.  Blockquotes and lists were the prime triggers.  There wasn’t an absolute 100% guarantee of trouble, but it was close.  I could avoid the freeze by commenting out a single declaration in my main style sheet:

#main {
  margin: 0 15em 0 0;
  /* padding: 3em 4em 3em 4em; */
  border-right: 1px solid #AAA;
  background: #FFF;
  min-height: 30em;
}

That’s why the content was running rampant earlier today.  I had to leave that line commented out for a few hours.  But I knew that couldn’t be the real cause, because it didn’t cause freezes on the home page, or even on monthly or daily archive pages.  The freeze only happened on an individual entry page where there was a padding-indented element inside the content column.  Thus, the source was most likely to lie in style sheet that’s applied only to post pages.

So I started digging through my entry style sheet until I narrowed the problem down to this line:

.prev-next {margin: 0; padding: 0.25em 1% 0; 
  float: left; width: 98%;}

If I commented it out, and uncommented the padding declaration from before, there were no problems.  So the culprit lay somewhere in the .prev-next rule.  Anyone want to guess at the cause?  Go ahead.

Oh, all right, I’ll tell you.  It was float: left;.  As soon as I removed that declaration, the IE6 freezing problem just melted away.  So if you’ve encountered freezes while trying to view entry pages in the past, you shouldn’t any more.  (If you do, please comment on this entry with the exact browser and OS you’re using.)

The original point of the float statement was to get the unordered list to wrap around the floated list items within it, since floated elements wrap around floated descendants (for more details, see my article “Containing Floats“).  Since that was apparently a recipe for disaster, I modified the rule to read:

.prev-next {margin: 0; padding: 0.25em 1% 0; 
  width: 98%; height: 1em;}

It isn’t exactly the same as what I was doing before, but the result is close enough for now.

What else might I have done?  Well, in all honesty, I thought seriously about leaving things status quo and letting IE users go hang.  I don’t cater to potential crash bugs in NN4, for example; why should I make an exception for another browser?  But as I always knew I would, I grumbled a bit and then made an accommodation for IE.  I may one day restore the float for more modern browsers and use some sort of hack to hide it from IE/Win, but for now I’ll leave things be.

What’s odd to me is that the styles involved in triggering this problem have been in place literally for months.  If this was a problem, it should have arisen before now.  Yet the first I heard of this freeze bug was two days ago, and then all of a sudden I was hearing about it from multiple sources.  If I’d been updating my CSS, that would be understandable, but I wasn’t.  So what happened?  Did the installed Explorer population just get spontaneously and collectively buggier over the weekend, or what?  Is there a subtle worm running around adding bugs to IE’s rendering engine?  I’m really at a loss here.

As to why that particular combination of styles would cause IE to freeze up, I’m completely at a loss.  Not a clue in the world.

While I was mucking around in the CSS anyway, I decided to see if I could fix the rendering error in IE/Win that made the sidebar hang out over the vertical separator.  I did, so far as I can tell.  The problem there was the “Exploration” box and the styles I’d applied to it.  Apparently, if you set a form element to width: 95%; margin-left 5%; and then set a text input within that form to width: 100%;, it all adds up to something like 120%, or something.  So I did a little bit of a hack to hide the input element’s width value from IE/Win.  The input box won’t be as wide for IE/Win users, but as far as I’m concerned that’s an acceptable loss.

I hope your morning was substantially less frustrating than mine.

• When Browsers Attack! was published on Thursday, September 16th, 2004.
• It was assigned to the Browsers and CSS categories.
• There have been fifty-four replies.

Heard several times in 2002 and 2003: “Hey, Eric, how come you don’t use a blogging package for your site instead of that goofy XML/XSLT thing you cooked up?  It would make your archive URLs easier to remember, you could let people search, and comments would be possible.”

Oh, I don’t know… maybe because once I pour everything into a system, I’m subject to its quirks and whims, whereas if I roll my own system, it’s subject to my quirks and whims—and is thus tuned to my personal expectations, built to account for what I might choose to do even if I don’t realize it?

Despite this totally sensible attitude, I eventually did migrate to a system (WordPress).  That decision just bit me, thanks to its handling of markup in a post title.  Had the markup just been stripped out, that would be one thing—annoying, but totally understandable.  But to only sort-of strip it in the post slug and drop the markup raw into the title element, thus breaking any hope of validation?  Instead of, oh, I don’t know, maybe stripping the markup from both the title element and the post slug, but otherwise leaving it alone, so that the post title could remain marked up in the document itself?

<sigh type="frustrated" />

For the record, this is not evidence that WordPress sucks.  All packages suck in some way, and each one sucks in unique ways.  Eventually, you’re going to trip over something undesirable.  Today it was my turn to take that trip.

Now the post slug of emreallyem-undoing-htmlcss is enshrined forever, because you don’t change permalinks if you can possibly avoid it.  I can avoid it here by gritting my teeth, sucking it up, and wishing I had the programming moxie (not to mention spare time) to implement my own full-featured system.

• When Blog Software Attacks! was published on Wednesday, September 15th, 2004.
• It was assigned to the WordPress category.
• There has been one reply.

There’s an aspect of document presentation most of us don’t consider: the browser defaults.  If you take an HTML or XHTML document—for the purposes of this exercise, assume it contains no presentational markup—and load it up in a Web browser with no CSS applied, there will still be some presentational effects.  A level-one heading, for example, is usually boldfaced and a good deal larger than other text, thus leading to the old stereotype of headings being “big and ugly”; the pre element typically honors whitespace and uses a monospace font; a paragraph is separated from other elements by a “blank line”; and so on.  From a CSS point of view, all this happens because the browser has built-in styles.

Tantek recently wrote about his creation of a file called undohtml.css, whose sole purpose is to strip away some of the default browser styles applied to common elements.  By resetting all headings to the same size, for example, he avoids the inconsistencies of heading sizes across browsers and brings everything to a common baseline.  If a different size is desired, the author has to do it manually.  (He should probably zero out the margins on headings as well, as those too tend to be inconsistent across browsers.)  He also zeroes out their margins, using a separate rule that I overlooked when I first posted.  Apologies to Tantek for my initial claim that he didn’t take that step.

Of course, Tantek isn’t really removing all the default styles, but (so far) just those that have given him the most trouble.  When it comes to Gecko-based browsers like Firefox and Mozilla, however, you can completely eliminate all built-in styles.  These browsers use a series of style sheets to control the presentation of documents, forms, MathML markup, and so on.  In OS X, you can find most of these style sheets by showing the package contents of the browser’s application file and navigating to Contents > MacOS > res.  On just about any other OS, it’s even easier; just search your hard drive for html.css and open the directory that contains that file.

If you look in html.css, you’ll find all of the styles that make what we think of as “unstyled” documents act the way they do.  Consider, for example:

area, base, basefont, head, meta, script, style, title,
noembed, noscript, param {
   display: none;
}

That rule is why the head element and all its contents don’t appear in your browser (as well as all those other “invisible” elements).  From a CSS standpoint, there’s nothing special about those elements as compared to others like div or ul.  The fact that they’re traditionally “invisible” is irrelevant—but with that one rule, the tradition is preserved.  You can always override the rule, of course; try style {display: block;} on a test document that contains an embedded style sheet and load it up in Firefox/Mozilla.  It isn’t magic.  It’s just a change from the usual way that documents are presented.  (See this test document for an example.)

There’s also:

/* nested lists have no top/bottom margins */
ul ul,   ul ol,   ul dir,   ul menu,   ul dl,
ol ul,   ol ol,   ol dir,   ol menu,   ol dl,
dir ul,  dir ol,  dir dir,  dir menu,  dir dl,
menu ul, menu ol, menu dir, menu menu, menu dl,
dl ul,   dl ol,   dl dir,   dl menu,   dl dl {
  margin-top: 0;
  margin-bottom: 0;
}

So in order to remove the top and bottom margins from nested lists, which is a traditional behavior of HTML browsers, that rule needs to be in the default style sheet.  Remove it, and nested lists would have top and bottom margins thanks to another rule in the style sheet:

ul, menu, dir {
  display: block;
  list-style-type: disc;
  margin: 1em 0;
  -moz-padding-start: 40px;
  -moz-counter-reset: -html-counter 0;
}

That rule not only sets the usual margins and such, but also includes some Mozilla-proprietary properties that help lists act in accordance with our expectations.  There are certain aspects of traditional presentation that aren’t (yet) fully describable using CSS, so the Mozilla folks have had to add properties.  In accordance with CSS2.1, section 4.1.2, these proprietary extensions are marked with a vendor prefix; here, it’s -moz-.  So any property or value you see starting with that string is a proprietary extension.  (For the record, I have no objection to extensions so long as they’re clearly marked as such; it’s the “silent” extensions that bug me.)

There is more to the presentation story than just html.css.  In the same directory, you can find quirk.css, which is applied instead of html.css when the browser is in “quirks” mode.  Another style sheet, viewsource.css, affects the presentation of any view source window.  All the nifty color-coding happens as a result of that style sheet, which is applied to automatically-generated markup that underlies the actual source you see.

So how do you completely strip out the default styles for an (X)HTML document?  Quit the browser application and rename the file html.css to something like html222.css.  Do the same for quirk.css.  Now re-launch the browser and find out just how much you’ve been taking for granted.  Feel free to browse around the Web and see what happens on various sites, but you’ll have to type blind, because the address bar won’t show any text.  You can still drag HTML documents on your hard drive into the window and see what happens.  If a document has any CSS applied to it, then the browser will use it.  It just won’t have any of the default styles available, so you’ll be applying your styles on top of nothing, instead of the usual foundation of expected presentation.

So what exactly is the point of all this?  As it turns out, I believe there are four:

1. By studying html.css, beginning CSS users can compare the rules to the “unstyled” presentation of documents, and thus get a much better idea of how CSS works.
2. By removing the default styles, you can come to a much greater realization of how much presentation is taken for granted, and how much there is to be dealt with when creating a new design.
3. On a related note, note that the absolute bare minimum presentation of a document is to render all elements with inline boxes, and to show every scrap of content available.  Even something as basic as making a paragraph generate a block box is a style effect.
4. It helps us to realize that what we often think of as the “special handling” of HTML is anything but: in Firefox/Mozilla, HTML documents are just a case of some markup that happens to have some pre-defined CSS applied to it.  Granted, the proprietary extensions needed to keep things in line with expectations are a case of special handling, and those tell us one of two things:
   • CSS still has a long way to go before it can be called a full-fledged layout tool, since it can’t fully recreate traditional HTML layout.
   • Old-school HTML layout was so totally wack, it’s no surprise that it’s hard to describe even with a tool like CSS at your disposal.
   I’ll leave it to the reader to decide which of those two they prefer.  Or, heck, choose both.  It isn’t as though they’re mutually exclusive.

Have fun fiddling with or completely removing the built-in styles!  Just remember: modifications like those described are made at your own risk, I’m not responsible if you do this and your hard drive vaporizes, no warranty is expressed or implied, not a flying toy, blah blah blah.

• Really Undoing html.css was published on Wednesday, September 15th, 2004.
• It was assigned to the Browsers and CSS categories.
• There have been sixty-six replies.

Excerpt from an IM session this afternoon:

Eric Meyer: Browsers– can’t live with ’em, can’t kill their developers.

Molly Holzschlag: well one could …

Eric Meyer: Okay, but not legally.

Molly Holzschlag: justifiable homicide?

Eric Meyer: Juries are notoriously unsympathetic to technical explanations.

Molly Holzschlag: you have a point

• Scenes From An iChat Window was published on Tuesday, September 14th, 2004.
• It was assigned to the Browsers and Humor categories.
• There have been four replies.

I quick-linked 10 Things to Do in Cleveland Before You Die, but the more I looked at the list, the less happy it made me.  So I’ve decided to compile my own list.  Note that this list doesn’t include restaurants.  As much as I love to eat, I just don’t think that a single meal is worthy of a “things to do before you’re dead” list, no matter how amazing the meal.  I might compile a separate “Ten Places to Eat In Cleveland” list, but that’s a subject for another day.

1. Hear the Cleveland Orchestra.

   Not on CD, you goof—anyone can do that.  Hear them perform live and in person at least once in your life.  Odds are you’ll want to make it more than once, given that they’re one of the best orchestras in the world.  Bonus points for seeing them at Blossom Music Center, followed by a fireworks display.

2. Tour the cultural institutions of University Circle.

   That includes the Cleveland Museum of Art; the Cleveland Museum of Natural History, which includes the Shafran Planetarium; the Western Reserve Historical Society, which includes the Crawford Auto-Aviation Museum; and the Cleveland Botanical Gardens, all within a quarter-mile radius.  Included in that grouping is Severance Hall, home of the Cleveland Orchestra.  This one’s kind of a cheat, since if I mentioned them all separately that would make this a “Top 15 Things To Do” list, which for some reason doesn’t sound as interesting.

3. Spend a day at the Cleveland Metroparks.

   Known as the “Emerald Necklace”, the extensive park system (20,000 acres in 14 reservations) not only girds the city but also runs throughout the greater metropolitan area.  There are hiking trails, picnic areas, educational events, and a whole lot more, including the Cleveland Metroparks Zoo.

4. Tour the Rock and Roll Hall of Fame.

   The real joy is in the smaller cases, where you can find original lyrics sheets to landmark songs complete with scratched-out ideas and arrows marking rearrangements, bills for hotel-room damage, and other tidbits.  The architecture of the building is fascinating as well.

5. Visit the West Side Market.

   Besides the dozens of fruit and vegetable stalls in the outside promenade, the interior market space is filled with local butchers, bakers, and other amazing treats.  Come early on Saturday morning for the best selection.

6. Spend Labor Day weekend downtown.

   That’s where and when you’ll find the Taste of Cleveland, a great way to sample various cuisines, while the aerial displays of the Cleveland National Air Show, based not half a mile away, soar overhead.  (Assuming the FAA relaxes its restrictions on such flights near sporting events, that is.)  If you stick around until nightfall, you’ll have a perfect excuse to go party in the Flats, too.

7. Hit one of the amusement parks.

   Technically these aren’t in Cleveland itself, but they’re close enough to warrant inclusion.  About forty minutes southeast of downtown is Geauga Lake (formerly Six Flags Worlds of Adventure), a combination amusement park and water park.  Just over an hour west of downtown, you’ll find Cedar Point, one of the nation’s premiere amusements parks and the roller coaster capital of the world.

8. Go sailing on Lake Erie.

   Whether you take out a two-man boat or take a dinner cruise on the Good Time III, it’s worth seeing the city from the water.  Even better, if you’re captain of your own boat, you can sail to one of the islands or head west along the shoreline to Cedar Point.

9. See a game.

   With three major-league teams (the Indians, Browns, and Cavaliers) playing downtown, if you’re a sports fan, you’ll find a game to watch.  There are a number of other teams in town as well, including the Barons (hockey) and the Force (soccer).

10. Drop by Lakeview Cemetery.

    Do it while you’re still alive, okay?  You’ll not only get great views of the city, but also see artistic, beautiful monuments to James A. Garfield, John D. Rockefeller, Eliot Ness, and others.  The Wade Chapel, situated on the shores of a pond, features an interior designed by Louis Comfort Tiffany and full of the famous glasswork bearing his name.  Who knows?  Maybe you’ll find a place to rest after you’re dead.

I have to be honest and admit that I haven’t even done everything on my own list.  However, I suspect that as our kids grow up, we’ll do all of those things more than once.

• Ten Things To Do In Cleveland Before You’re Dead was published on Tuesday, September 14th, 2004.
• It was assigned to the Cleveland category.
• There have been fifty-six replies.

A couple of nights ago, Kat and I watched most of Toy Story 2 before going to bed.  In subsequent nights, we watched the rest of the movie, and also the original Toy Story, but that’s not important right now.  It was interesting to compare the technical differences between the two, from rendering to animation, but that’s also not important right now.

A few minutes before 5:00am on the morning after we’d watched most of TS2, we were awakened by a cry from Carolyn.  She settled back down within a minute, and as we lay there dropping back off to sleep ourselves, we very clearly heard, coming from somewhere in the house, a quick series of three beeps.

My first thought was the carbon monoxide detector, but it wasn’t loud enough or the right tone pattern (the CO detector just wails in one long earsplitting tone).  My second thought was a fire detector running low on batteries, but again, wrong tone pattern.  The interval between these two thoughts was probably a couple of minutes, because it was very early in the morning and I was stumbling around the house trying to figure out what had produced the sound.

After a tour of the first floor and a quick peek into Carolyn’s room, I went back to bed.  It took a while, since I’d shifted into sentry mode, but I eventually fell back asleep.  We haven’t heard any mysterious beeps since then.

It’s hard to shake the suspicion that our electronic gadgets have started talking to each other at night.  I’m not sure what they’d talk about; how much would a VCR really have to say to a cell phone?  Maybe they discuss difficult philosophcal questions and further illuminate the nature of existence.  Maybe our technosphere has gotten sophisticated enough that a collective awareness has emerged.  If that’s true, then it’s little wonder we wouldn’t have heard about it.  What interest would a global intelligence have in talking to any of us?

Then again, maybe a short-circuit or other unexpected condition triggered some beeps, and that was that.

• Things That Go Beep In The Night was published on Monday, September 13th, 2004.
• It was assigned to the Humor and Tech categories.
• There have been twenty-seven replies.

Yesterday morning, I saw via somebody’s feed (most likely either Matt or Simon) that Rakesh Pai has published a piece called “The Economics of XHTML”, in which he explores and summarizes many points in favor of moving to XHTML.  As he says, XHTML and semantic HTML are basically the same thing, so when you read the article you should prepend the words “old-style” to the term HTML and “semantic HTML or” to the term XHTML.  Thus, the following paragraph from his article:

HTML files are rather complex. They have so much irrelevant information, it becomes difficult to manage them. XHTML on the other hand, if well planned, will be much easier to manage in the long run due to sheer simplicity of the files.

…should be read (emphasis indicates my modifications):

Old-style HTML files are rather complex. They have so much irrelevant information, it becomes difficult to manage them. Semantic HTML or XHTML on the other hand, if well planned, will be much easier to manage in the long run due to sheer simplicity of the files.

I admit I’m reading a bit into the text, but I think my reading is supported by Rakesh’s statement about the basic equivalence of semantic HTML and XHTML.

Overall, it’s a very good summary of the business reasons to shift to standards-oriented design.  It bothers me not at all that he left out a discussion of CSS in the article, since the focus was purely on the benefits to be gained from improving your markup.  It’s often useful to concentrate on small pieces in detail, so that by the time you’ve looked at the various pieces you have a much better understanding of the overall picture.  I would like to talk about an under-recognized aspect of his first point, which was (again, emphasis indicates an insertion on my part):

Semantic HTML or XHTML will give a definite reduction in amount of space used on the server, which translates to money saved. Large sites will also benefit from the bandwidth savings, though this might be insignificant for smaller sites.

It’s true that smaller sites probably won’t save a lot of money on bandwidth.  This is especially true given that many small businesses pay a flat rate each month so long as their bandwidth is below a certain level.  So sites in that range will likely not see significant reductions in expenses.

What they will see, though, is a faster site.  Okay, actually, that’s what their users will see, but that’s the entire point.  Suppose I said I could sell you a product that would make your Web site twice as fast as it is today.  How much would that be worth?  Maybe not much for a fandom site, but even for a small business trying to sell its products online and disitinguish itself from competitors, a 2x speed booster would probably be worth buying.

The thing is that you don’t have to make a purchase to get this boost (unless you decide to hire a consultant like me to help you migrate to standards-oriented design).  There’s no product to buy.  Along with all the other benefits Rakesh describes—accessibility, ease of maintenance, and so on—a faster Web site is part of the standards package.

How so?  Far and away, the #1 factor in request-to-render time is the raw number of bytes you’re shipping to the user.  If you’re sending a dialup user a 60KB page, then even assuming an uninterrupted, uncongested connection it will take about 15 seconds for the page to render, measured from the time the user requests it.  If you send a 30KB page, it will take half that time.

I’m not just saying that because it sounds true: while I was at Netscape, Bob Clary and I did experiments on the effects of standards-oriented design on request-to-render time.  We saw basically no speed improvement from using standards-oriented design beyond the reduction in page weight—but that was a substantial effect.  Thus, the actual markup you use is basically irrelevant in this arena.  The whole page could be one graphic scan of your brochure, or it could be a press release.  Either way, the more bytes you send over the wire, the slower the site will seem.  True, there are other considerations, like server load, network congestion, and so on.  All of those factors will be eased, and speed improved, if there are fewer bytes per page request.  It’s honestly that simple.

As I’ve been telling clients, this is what makes standards a big economic win: standards-oriented designs are nearly always much smaller than old-style designs.  Usually they’re half the size of old-school pages, although that reduction can vary; Microsoft’s home page size dropped by about two-thirds in terms of the markup weight alone.  With Microsoft’s traffic, they stand to save a boatload of money on that reduction.  They also have a site that’s faster, that feels less bloated, that leaves more of a positive impression on the user.  That’s an important consideration for any company, regardless of its size.  It’s a consideration that’s harder to quantify than reduced costs, of course, but not one that can be ignored.  As Richard Rutter shared, when Multimap went to a standards-oriented design, they didn’t see as much of a drop in bandwidth consumption as they’d expected, although there was a reduction.  What they saw was a dramatic upswing in page views, which meant increased revenue for the firm; in other words, they were able to serve more customers and increase revenue while using less bandwidth than before.

That’s what they call increased efficiency, and it’s a competitive advantage in any arena.

• Standards Savings was published on Monday, September 13th, 2004.
• It was assigned to the Standards category.
• There have been six replies.

Over dinner this evening, I wondered why it is that bank ATMs always have to ask me what language I prefer.  Why not just encode my language preference on the card’s magnetic strip, so that when I insert the card into the machine it immediately knows what language to use?

It was, of course, too obvious an idea for me to have had it first: Why Not? has a post proposing the same idea just over a year ago.  The followup comments pretty much covered all the related ideas that came up as well.

So while it turns out I don’t get points for having the idea first, the question still remains: why don’t ATM cards (and the ATMs themselves) offer this capability?

Update: I forgot to enable comments, so a few people have e-mailed me to say that Bank of America ATMs do in fact let you set your language preferences, along with several other options.  Apparently these settings only carry to other BoA ATMs, so I suspect it’s data being stored in their database instead of being written onto the card itself.  It would be nicer if the card could carry that information and have it recognized by all ATMs, but I suppose we get these things one step at a time.

• Automated Language Setting was published on Thursday, September 9th, 2004.
• It was assigned to the General and Tech categories.
• There has been one reply.