Posts from May 2008

Need Help With Table Row Events

Published 15 years, 9 months past

Here’s a late-week call for assistance in the JavaScript realm, specifically in making IE do what I need and can make happen in other browsers.  I’d call this a LazyWeb request except I’ve been trying to figure out how to do it all [censored] afternoon, and it doesn’t [censored] work no matter how many [censored] semi-related examples I find online that work just [censored] fine, but still don’t [censored] help me [censored] fix this [censored] problem.  [doubly censored]!

I have a table.  (Yes, for data.)  In the table are rows, of course, and each row has a number of cells.  I want to walk through the rows and dynamically add an ‘onclick’ event to every row.  The actual event is slightly different for each row, but in every case, it’s supposed to call a function and pass some parameters (which are the things that change).  Here’s how I’m doing it:

var event = '5'; // in the real code this is passed into the surrounding function
var mapStates = getElementsByClassName('map','tr');
for (x = 0; x < mapStates.length; x++) {
	var el = mapStates[x];
	var id = el.getAttribute('id');
	var val = "goto('" + id + "','" + event + "');";
	el.setAttribute('onclick',val);
}

Okay, so that works fine in Gecko.  It doesn't work at all in IE.  I changed el.setAttribute('onclick',val); to el.onclick = val; per some advice I found online and that completely failed in everything.  Firebug told me "el.onclick is not a function".  Explorer just silently did nothing, like always.

So how am I supposed to make this work in IE, let alone in IE and Gecko-based and WebKit-based and all other modern browsers?

Oh, and do not tell me that framework X or library Q does this so easily, because I'm trying to learn here, not have someone else's code hand-wave the problem away.  Pointing me directly to the actual code block inside a framework or library that makes this sort of thing possible:  that's totally fine.  I may not understand it, but at least there will be JS for me to study and ask questions about.  Ditto for pointing me to online examples of doing the exact same thing, which I tried to find in Google but could not: much appreciated.

Help, please?

Update: many, many commenters helped me see what I was missing and therefore doing wrong---thank you all!  For those wondering what I was wondering, check out the comments.  There are a lot of good examples and quick explanations there.


WordPress Adminimize and Latest Tweet Plugins

Published 15 years, 9 months past

Just because the world hasn’t suffered enough bad PHP coding, I released two WordPress plugins today.  One pares down some of the admin UI, and the other is a Twitter plugin.  Because the world doesn’t have enough of those, either.  You can find links to them on my WordPress Plugins and Hacks (but I repeat myself) page, or if you can go straight to their respective pages, which I’ll link here in just a second.

Okay, second’s up!

MW Adminimize (currently v0.5)

This plugin pares down the page-topping links interface that shows up on every WordPress administration page.  I got tired of seeing my blog name in Big Huge Letters all the time, and I kept forgetting that the “Dashboard” link was hidden up in that black bar.  So I fiddled with some arrays and wrote some CSS, and got something that chews up less screen real estate while also being easier for me to use.  Maybe you’ll feel the same, in which case, enjoy the plugin.

In addition to that, I pared down some of the elements of the “Write Post” page so that they took up a bit less space, and compressed the stuff around the post title’s input field.  Those styles are marginally less stable and may cause weirdness for you.  If so, sorry.  Let me know what goes south and I’ll try to get it fixed in a future version.

Oh, and I also included a CSS rule that makes the background shading of moderated comments more obvious, though not in my usual eye-scarring fashion.  It’s just a little darker and notably redder.  That doesn’t have much of anything to do with minimizing the admin UI, but I thought it was a huge improvement.  I might take it out in a future version if the crowd shouts otherwise.

MW Latest Tweet (currently v1.0)

This one does what you’d probably guess: shows the latest tweet.  Why not just use something like Twitter Tools?  Actually, I tweeted about that.  A further survey of the options available turned up nothing that was quite what I wanted.  So of course I started hacking away.

The basic mechanism is that any time a page that calls this plugin is loaded, it either returns the last-cached tweet or asks Twitter for the latest tweets so it can cache the latest of them.  If Twitter fails to respond (I know, what are the odds?), you still get the cached tweet.  This is similar to SimpleTwitter, from which I took much inspiration, but is more advanced in a number of ways.  Among the options I wanted to have and thus created was having “human time” intervals as an option, and also the ability to filter out @replies (because I personally wanted to display my latest broadcast tweet, not my latest reply).  While I was at it, I decided I’d throw in the ability to define your own XHTML output, so that if the plugin failed there wouldn’t be partial or mangled markup shoved into your pages.  Also, since I cache the whole of the latest tweet, you have all kinds of stuff you can output should you so desire.  It’s all documented on the plugin’s page.

This is not a widget, because I’ve never written one and didn’t have time to learn (due to all the time I was burning just trying to write the plugin).  You have to edit your template/web page PHP in order to call it.  That’s just the kind of DIY guy I fly.  Er, I am.

Also, I’m a wee tiny bit proud of how I styled the labels on the plugin’s Settings page.  I’ll probably write that up in a separate post.

That’s about it.  If anything goes wrong or is unclear, please do let me know in the comments.  Share and enjoy!


Characteristic Confusion

Published 15 years, 9 months past

In the course of building my line-height: normal test page, I settled on defaulting to an unusual but still pervasive font family: Webdings.  The idea was that if you picked a font family in the dropdown and you didn’t have it installed, you’d fall back to Webdings and it would be really obvious that it had happened.

(A screenshot of the symbols expected from Webdings: an ear, a circle with a line through the middle, and a spider.)

Except in Firefox 3b5, there were no dings, web or otherwise.  Instead, some serif-family font (probably my default serif, Times) was being used to display the text “Oy!”.

It’s a beta, I thought with a mental shrug, and moved on.  When I made mention of it in my post on the subject, I did so mainly so I didn’t get sixteen people commenting “No Webdings in Firefox 3 betas!” when I already knew that.

So I didn’t get any of those comments.  Instead, Smokey Ardisson posted that what Firefox 3 was doing with my text was correct.  Even though the declared fallback font was Webdings, I shouldn’t expect to see it being used, because Firefox was doing the proper Unicode thing and finding me a font that had the character glyphs I’d requested.

Wow.  Ignoring a font-family declaration is kosher?  Really?

Well, yes.  It’s been happening ever since the CSS font rules were first implemented.  In fact, it’s the basis of the whole list-of-alternatives syntax for font-family.  You might’ve thought that CSS says browsers should look to see if a requested family is available and then if not look at the next one on the list, and then goes to render text.  And it does, but it says they should do that on a per-character basis.

That is, if you ask for a character and the primary font face doesn’t have it, the browser goes to the next family in your list looking for a substitute.  It keeps doing that until it finds the character you wanted, either in your list of preferred families or else in the browser’s default fonts.  And if the browser just can’t find the needed symbol anywhere at all, you get an empty box or a question mark or some other symbol that means “FAIL” in font-rendering terms.

A commonly-cited case for this is specifying a CJKV character in a page and then trying to display it on a computer that doesn’t have non-Romance language fonts installed.  The same would hold true for any page with any characters that the installed fonts can’t support.  But think about it: if you browse to a page written in, say, Arabic, and your user style sheet says that all elements’ text should be rendered in New Century Schoolbook, what will happen?  If you have fonts that support Arabic text, you’re going to see Arabic, not New Century Schoolbook.  If you don’t, then you’re going to see a whole lot of “I can’t render that” symbols.  (Though I don’t know what font those symbols will be in.  Maybe New Century Schoolbook?  Man, I miss that font.)

So: when I built my test, I typed “Oy!” for the example text, and then wrote styles to use Webdings to display that text.  Here’s how I represented that, mentally: the same as if I’d opened up a text editor like, oh, MS Word 5.1a; typed “Oy!”; selected that text; and then dropped down the “Font” menu and picked “Webdings”.

But here’s how Firefox 3 dealt with it: I asked for the character glpyhs “O”, “y”, and “!”; I asked for a specific font family to display that text; the requested font family doesn’t contain those glyphs or anything like them; the CSS font substitution rules kicked in and the browser picked those glyphs out of the best alternative.  (In this case, the browser’s default fonts.)

In other words, Firefox 3 will not show me the ear-Death Star-spider combo unless I put those exact symbols into my document source, or at least Unicode references that call for those symbols.  Because that’s what happens in a Unicode world: you get the glyphs you requested, even if you thought you were requesting something else.

The problem, of course, is that we don’t live in a Unicode world—not yet.  If we did, I wouldn’t keep seeing line noise on every web page where someone wrote their post in Word with smart quotes turned on and then just did a straight copy-and-paste into their CMS.  (Here we have a screenshot of text where a bullet symbol has been mangled into an a-rhone and an American cents sign, thus visually turning 'Wall-E' into 'Wallace'.)  Ged knows I would love to be in a Unicode world, or indeed any world where such character-incompatibility idiocy was a thing of the past.  The fact that we still have those problems in 2008 almost smacks of willful malignance on the part of somebody.

Furthermore, in most (but not all) of the text editors I have available and tested, I can type “Oy!” with the font set to Webdings and get the ear, Death Star, and spider symbols.  So mentally, it’s very hard to separate those glyphs from the keyboard characters I type, which makes it very hard to just accept that what Firefox 3 is doing is correct.  Instinctively, it feels flat-out wrong.  I can trace the process intellectually, sure, but that doesn’t mean it has to make sense to me.  I expect a lot of people are going to have similar reactions.

Having gone through all that, it’s worth asking: which is less correct?  Text editors for letting me turn “Oy!” into the ear-Death Star-spider combo, or Firefox for its rigid glyph substitution?  I’m guessing that the answer depends entirely on which side of the Unicode fence you happen to stand.  For those of us who didn’t know there was a fence, there’s a bit of a feeling of a slip-and-fall right smack onto it, and that’s going to hurt no matter who you are.


Tour de Frantic

Published 15 years, 9 months past

I am, as ever, woefully behind on posting.  (Then again, maybe it’s not just me: Greg Hoy recently tweeted that it’s happening all over.)  I still want to follow up on line-height: normal and also on a closely related topic that emerged in the comments.  And I will.  Eventually.

Right now, though, I want to mention a few pieces of news from the conference world.  After that, it’s back to steeling myself to upgrade WordPress while stomping out the problems I have with my current install and also, I hope, finally getting it set up to do version-controlled upgrading henceforth.

Right.  The news.

  • The early bird deadline for An Event Apart Boston 2008 is next Monday, so don’t wait much longer to register if you’re a fan of discounts.  If not, that’s cool too.  Maybe you like to pay more.  We’re not here to judge.

  • If you’re on the opposite coast, there’s also An Event Apart San Francisco 2008, whose detailed schedule was announced this morning.  It will be two days jam packed with greatness from Heather Champ, Kelly Goto, Jeremy Keith, Luke Wroblewski, Dan Cederholm, Tantek Çelik, Jeffrey Veen, Derek Featherstone, Liz Danzico, Jason Santa Maria, Jeffrey Zeldman, and your humble servant.  You’ve still got some time to register with the early bird discount, but I wouldn’t put it off forever, because there’s no way to know when the last seat will be sold.

    (And if you aren’t subscribed to our mailing list, then you’re already behind the times:  subscribers got word of the detailed San Francisco schedule yesterday, ahead of everyone else.  Because they’re on the ins, as the kids are known to say.  Don’t let them have all the fun.  Sign up today!)

  • At the beginning of June, I’ll be giving a keynote plus a bonus session to be named later at the Spring <br/> Conference in Athens, Ohio.  For years they’ve been trying to get me to come down there, and every year I had some insurmountable scheduling conflict.  It almost happened again this year, but they were really fantastic and actually worked the schedule to accommodate me, for which I can’t thank them enough.  Come on down and take a <br/> with us!

  • Come mid-July, I’ll be in sunny Philadelphia for the Higher Education Web Symposium co-teaching a full-day workshop on “CSS Tips & Techniques” with the incomparable Stephanie Sullivan.

  • And in the realm of the not-absolutely-guaranteed-and-therefore-underspecified:  come late September, it looks like I’ll be back in Destin, Florida; and I just might be making my way to Japan in early November.

Plus of course there’s An Event Apart Chicago 2008 in October, but you already knew about that.  The detailed schedule will be published in mid-July, and with that lineup of speakers, I’m already shivering with anticipation.

Okay, that’s all I have for the moment.  Hopefully that upgrade/fix/control thing will go less bumpily than I fear, and I can get another post out before all those shows have passed into memory.


line-height: abnormal

Published 15 years, 10 months past

When I first wrote Cascading Style Sheets: The Definitive Guide, the part that caused me the most difficulty and headaches was the line layout material.  Several times I was sure I had it all figured out and accurately described, only to find out I was wrong.  For two weeks I corresponded with Ian Hickson and David Baron, arguing for my understanding of things and having them show me, in merciless detail, how I was wrong.  I doubt that I will ever stop owing them for their dedication to getting me through the wilderness of my own misunderstandings.

Later on, I produced a terse description of line layout which went through a protracted vetting process with the CSS Working Group and the members of www-style.  At the time it was published, there was no more detailed and accurate description of line layout available.  Even at that, corrections trickled in over the years, which made me think of it as my own tiny little The Art of Computer Programming.  Only without the small monetary reward for finding errors.

The point here is that line layout is very difficult to truly understand—even given everything I just said, I’m still not convinced that I do—and that there are often surprises lurking for anyone who goes looking into the far corners of how it happens.  As I’ve said before, my knowledge of what goes into the layout of lines of text imparts a sense of astonishment that any page can be successfully displayed in less than the projected age of the universe.

Why bring all this up?  Because I went and poked line-height: normal with a stick, and found it to be both squamous and rugose.  As with all driven to such madness, I now seek, grinning wildly, to infect others.

Here’s the punchline: the effects of declaring line-height: normal not only vary from browser to browser, which I had expected—in fact, quantifying those differences was the whole point—but they also vary from one font face to another, and can also vary within a given face.

I did not expect that.  At least, not consciously.

My work, let me show it to you: a JavaScript-driven test file where you can pick from a list of fonts and see what happens at a variety of sizes.  (Yes, the JS is completely obtrusive; and yes, the JS is the square of amateur hour.  Let’s move on, please.  I’m perfectly happy to replace what’s there with unobtrusive and sharper JS, as long as the basic point of the page, which is testing line-height: normal, is not compromised.  Again, moving on.)

When you first go to the test, you should (I hope) see a bunch of rulered boxes containing text using the very common font face Webdings, set at a bunch of different font sizes.  The table shows you how tall the simple line boxes are at each size, and therefore the numeric equivalent for line-height: normal at those sizes.  So if a line box is using font-size: 50px and the line box is 55 pixels tall, the numeric equivalent for line-height: normal is 1.1 (55 divided by 50).

On my PowerBook, Webdings always yields a 1:1 ratio between the font-size and line box height.  The ten-pixel font size yields a ten-pixel-tall line box, and so on.

This is actually a little surprising by itself.  The CSS 2.1 specification says:

normal
Tells user agents to set the used value to a “reasonable” value based on the font of the element. The value has the same meaning as <number>. We recommend a used value for ‘normal’ between 1.0 to 1.2. The computed value is ‘normal’.

This is basically what CSS has said since its first days (see the equivalent text in CSS1 or in CSS2 for confirmation) and there’s always been a widespread assumption that, since 1.0 is probably too crowded, something around 1.2 is much more likely.

So finding a value of 1 was a surprise.  It was an even bigger surprise to me that this held true in Camino 1.5.2, Firefox 2.0.0.14, and Safari 2.0.4, all on OS X.  Firefox 3b5 didn’t render Webdings at all, so I don’t know if it would do the same.  I actually suspect not, for reasons best left for another time (and, possibly, a final release of Firefox 3).

Various browsers doing the same thing in an under-specified area of the spec?  That can’t be right.  It’s pretty much an article of faith that given the chance to do anything differently, browsers will.  The sailing was so unexpectedly smooth that I immediately assumed was that a storm lurked just over the horizon.

Well, I was right.  All I had to do was start picking other font faces.

To start, I picked the next font on the list, Times New Roman, and the equivalent values for normal immediately changed.  In other words, the numeric equivalents for Times New Roman are different than those for Webdings.  The browsers weren’t maintaining a specific value for normal, but were altering it on a per-face basis.

Now, this is legal, given the way normal is under-specified.  There’s room to allow for this behavior.  It’s actually, once you think about it, a fairly good thing from a visual point of view: the best default line height for Times New Roman is probably not the best default line height for Courier New.  So while I was initially surprised, I got over it quickly.  The seemingly obvious conclusion was that browsers were actually respecting the fonts’ built-in metrics.  This was reinforced when I found that the results were exactly the same from browser to browser.

Then I looked more closely at the numbers, and confusion set back in.  For Times New Roman, I was getting values of 1.1, 1.12, 1.16, 1.15, 1.149, and 1.1499.  If you were to round all of those numbers to two decimal points, you’d get 1.10, 1.12, 1.16, 1.15, 1.15, 1.15.  If you round them all to one decimal place, you’d get 1.1, 1.1, 1.2, 1.2, 1.1, 1.1.  They’re inconsistent.

But wait, I thought, I’m trying to compare numbers I derived by dividing pixels by pixels.  Let’s turn it around.  If I multiply the most precise measurement I’ve gotten by the various font sizes, I get… carry the two… 11.499, 28.7475, 57.495, 114.99, 1149.9, 11499.  As compared to the actual values I got, which were 11, 28, 58, 115, 1149, and 11499.

Which means the results were inappropriately rounded up in some cases and down in others.  28.7475 became 28 and 1149.9 became 1149, whereas 57.495 became 58.  Even though 11.499 became 11 and 114.99 became 115.

This was consistent across all the browsers I was testing.  So again, I was suspecting the fonts themselves.

And then I switched from Times New Roman to just plain old Times, and the storm was full upon me.  I’ll give you the results in a table.

Derived normal equivalents for Times in OS X browsers
font-size Camino 1.5.2 Firefox 2.0.0.14 Safari 2.0.4
10 1 1.2 1.3
25 1 1 1.16
50 1 1 1.18
100 1 1 1.15
1000 1 1 1.15
10000 1 1 1.15

Much the same happened when comparing Courier New with plain old Courier: full consistency on Courier New between browsers, albeit with the same strange (non-)rounding effects as seen with Times New Roman; but inconsistency between browsers on plain Courier—with Camino yielding a flat 1 down the line, Firefox going from 1.2 to 1, and Safari having a range of values above the others’ values.

Squamous!  Not to mention rugose!

Now it’s time for the stunning conclusion that derives from all this information, which is: not here.  Sorry.  So far all I have are observations.  I may turn all this into a summary page which shows the results for all the font faces across multiple browsers and platforms, but first I’ll need to get those numbers.

I do have a few speculations, though:

  1. Firefox’s inconsistency within font faces (see Times and Courier, above) may come from face substitution.  That’s when a browser doesn’t have a given character in a given face, so it looks for a substitute in another face.  If Firefox thinks it doesn’t have 10-pixel Times, it might substitute 10-pixel something else serif-ish, and that face has different line height characteristics than Times.  I don’t know what that other face might be, since it’s not Times New Roman or Georgia, but this is one possibility.  It is not the minimum font size setting in the preferences, as I’ve triple-checked to make sure I have that set to “None”.

  2. Another possibility for Firefox’s line height weirdness is a shift from subpixel font rendering to pixelly font rendering.  10-pixel text in Firefox is distinctly pixelly compared to the other browsers I tested, while sizes above there are nice and smooth.  Why this would drive up the line height by two pixels (20%), though, is not clear to me.

  3. Much of what I’ve observed will likely be laid to rest at the doorsteps of the font faces themselves.  I’d like to know how it is that the rounding behaviors are so (mathematically) messed up within faces, though.  Perhaps ideal line heights are described as an equation rather than a simple ratio?

Again, this was all done in OS X; I’ll be very interested to find out what happens on Windows, Linux, and other operating systems.  Side note for the Mac Opera fans warming up their flamethrowers: I’ve left Opera 9.27 for OS X out of this because it seems to cap font sizes at a size well below 1000, although this limit varied from one face to another.  Webdings and Courier capped at 507 pixels, whereas Courier capped at 574 pixels and Comic Sans MS stopped at 707 pixels.  I have no explanation, though doubtless someone will, but the upshot is that direct comparisons between Opera and the other browsers are impossible.  For sizes up to 100 pixels, the results were exactly consistent with Camino, if that means anything.

The one tentative conclusion I did reach is this: line-height: normal is a jumbled terrain of inconsistent behaviors, and it’s best avoided in any sort of precision layout work.  I’d already had that feeling, but at least now there’s some evidence to back up the feeling.

In any case, I doubt this is the last I’ll have to say on this particular topic.

Update 7 May 08: I’ve updated the test page with a fix from Ben Lowery so that it works in IE.  Thanks, Ben!  Now all I need is to add a way to type in any arbitrary font-family’s name, and we’ll have something everyone can use.  (Or else a way to use JavaScript to suck up the names of all the fonts installed on a machine and put them into the dropdown.  That would be cool, too.)


The Really Perfect Ringtone

Published 15 years, 10 months past

When I saw a couple of people link to “the perfect iPhone ringtone” last week, I had that sinking feeling that comes from being beaten to the punch.  I knew I should have stayed up an extra hour that one night and just gotten it done!

But wait, hold it, never mind, cancel the panic parade: it was not, in fact, the perfect ringtone.  Crisis averted!  Still, the sinking feeling lingered, reminding me of what could have been, so last night I sat down and got it done.  Now I bring to you the absolutely most perfect ringtone ever.

Feel free to preview it using that link, if you really feel that’s necessary, but frankly you should just charge ahead and download the .m4r AAC for instant ringtoniness.  If for some reason you’d rather have the audio source and do your own ringtone conversions, you can get the same file as a .m4a AAC or a comfy old .mp3.  And for all you completists, there’s a .zip archive of all three formats.

Go.  Ring.  Enjoy.


Browse the Archive