Thoughts From Eric Archive

Gatekeeper 1.5 rc5

Published 19 years, 6 months past

It only took most of a year for this to happen, but WP-Gatekeeper 1.5 RC5 is now available.  The only change is that it will now auto-add the challenge to any standard WordPress 1.5 install from the moment you activate the plugin.  Before now, this auto-insertion wasn’t working on any WordPress install that had gzipping turned on, as many do.  A heap of thanks to Jeremy Dunck, who first identified the problem; and Andy Skelton, who showed me how to solve it.

For those who joined the party in the long silence since RC4, Gatekeeper is a WordPress plugin that lets you manage a series of challenge/response pairs.  The default challenge is “What color is an orange?” (correct response: “orange”), though you should definitely disable that one and add your own.  This helps stymie spambots, though of course it is easily defeated by a manual spammer—and they do exist—and it can do nothing to stop trackback spam.  I actually stopped using Gatekeeper on meyerweb when I installed Akismet, which may be good enough for most people.  For those who can’t or won’t run Akismet, though, Gatekeeper is a decent alternative.

Gatekeeper is technically a CAPTCHA, but it is a fully accessible CAPTCHA, as it uses no images.  It’s also highly configurable, allowing you to add as many challenges as you like and then rotating between them randomly.  I know of a few sites that are quite happy with Gatekeeper, and recently caught wind of a Django implementation of the same concept.

So it’s there and ready for use by those who are interested.  If I haven’t heard about any bugs within the next month or so, I’ll strip off the RC designation and go with 1.5 final.  And about time, too.

Note to WordPress 2.0.x users: I have no idea if WP-Gatekeeper 1.5 will work in WP2.  It may.  Then again, it may not.  I’d be interested to know either way.


S5 1.2a2

Published 19 years, 6 months past

The alpha 2 release of S5 1.2 is now available (177KB ZIP file; also available for previewing in the testbed).  There isn’t any major change here, but I did add some notable enhancements to the notes window.  These are:

  • On any slide with incrementals, an indicator of incremental progress will appear in square brackets next to the overall slide show progress on the title line.  It’s a little crude, I admit, but it serves the purpose well enough.
  • Clicking on the title of either the Elapsed Time or Remaining Time counters will “minimize” them.  Click a minimized title to maximize the box.  The actual minimum and maximum effects are purely CSS-driven, hooked onto a collapsed class name.  I’m still pondering the best way to handle this feature, so the class name may change, as for that matter may the mechanism by which one can min/max the boxes.  Suggestions are welcome.
  • Keypresses and clicks are passed from the note window back to the slide show.  In other words, the slide show fully is fully operable from either the slide show window or the notes window.  The only difference is that the notes window doesn’t have the navigation links and popup navigation menu (said difference to disappear in a future release).

That’s it.  In the process, though, I uncovered a bug that shows up in Safari 1.3.1 and 2.0, where it’s ignoring the show-first feature for incrementals.  I’m going to assume that the problem lies in the getIncrementals() function, though of course I could be wrong.  If anyone can spot the error and provide a fix, I’d be grateful.

Update 2 Mar 06: in addition to the Safari problem, I’ve discovered that IE/Win doesn’t seem to share event information between windows.  Thus, if you try to run the slide show from the notes window, errors get thrown.  I managed to fix this in clicker() by adding a test for notes-window events, but trap() has a very different structure and I’m not sure how to fix it.  Thus the testbed in IE/Win currently lets you advance the slide show from the notes window by clicking the mouse button, but keyboard navigation throws an error.  If anyone can tell me how to get around this, even with a pointer to a good article on passing events from one window to another, I’d be very grateful.


A Grand Lady

Published 19 years, 6 months past

Not long after noon this past Tuesday, my grandmother Constance died at the age of 98.  She was my father’s mother, the last of my grandparents to die.  At this point, if I were to start with me and trace the tree diagrams of my mother’s and father’s families all the way back to their root elements, my only living ancestor is my father.

It is always sad when a loved one dies, but it’s what she wanted, and I respect that decision without reservation.  Her health and physical abilities had deteriorated greatly, and she was tired in a way that I cannot hope to comprehend.  She had seen her children grow up and have their own children, and then become grandparents of their own.  Her life had been long, her joys and sorrows beyond counting.  She was ready to call an end.  In many ways, she had been ever since losing her husband a little over three years ago.

Tomorrow we go to join the gathering family.  I think Grammy would have wanted nothing else but that: the family together, forming a great circle of strength and love in which each of us can shelter.


Comment Spam Quips

Published 19 years, 6 months past

In keeping with Molly‘s recent conversations with comment spam, I present to you a back-handed compliment (or is it?) that I found in my moderation queue:

A great site where one can enjoy the thought of a great mind long departed. Cheers for the good work!

Wow.  Harsh.


Botheration

Published 19 years, 6 months past
If you’re bothered by the fact that you weren’t bothered by a thought you just had, isn’t the thought just bothering you by proxy?

Unfortunately Eric

Published 19 years, 7 months past

Thanks to The Wolf‘s pointer to The Other Wolf‘s post, I now bring you “Unfortunately Eric”.

Unfortunately, Eric mentions it, but doesn’t really discuss aa major concern of many…
You mean your misspelling of the word “a”?  I didn’t want to harp on it.
Unfortunately Eric Doesn’t Look Old Enough to Remember MS C 7.0…
Sure I am.  I just don’t want to remember it.
Unfortunately, Eric and Felecia are now against Lisa and the Wildlife preserve.
They started it!
She and Eric had been living with Dan in Hawaii for a while, but unfortunately, Eric had to go back home for a family emergency before we got there.
And that’s how she and Dan ended up together, whereas I ended up on the streets.  Crazy times…
Unfortunately Eric takes several wrong turns on the twisty, identical, unlabeled streets leading to Dog Boys (entirely due to a lack of preparation)…
In my defense, I was totally prepared for Cat Boys.
Unfortunately Eric has not released those precious gems of 415 golden songs, nor the EMB II album, as Eric left the group for other projects…
They weren’t very danceable anyway.
Unfortunately, Eric didn’t receive the letter until after the dance.
Story of my life.
Unfortunately, Eric had a couple of problems.
Your count seems a bit low.
Unfortunately, Eric had an appetite for destruction – which he never had the opportunity to quench…
Eric SMASH!
unfortunately eric is not only drop dead f*cking gorgeous he…
Oh, stop.
Unfortunately, Eric did not live long enough to witness the legend he created.
Aw crap.  Did I drop dead again?

It’ll be interesting to see how long it takes for this post to throw Google’s results out of whack.  (Answer: three days.)


Unitless line-heights

Published 19 years, 7 months past

I’d like to share something that will be old news to readers of CSS: The Definitive Guide and all of my other books, but nonetheless needs to be said out loud, in public, for everyone to hear.

The property line-height can accept unitless number values.  You can also give line-height united values, though generally you shouldn’t.  But unitless numbers are just fine for this property.

So what’s the difference?  When you define a united value, like 1em, you’re setting things up to pass along the computed result to any descendants.  For example, suppose the following CSS is applied to a document containing the following markup fragment:

ul {font-size: 15px; line-height: 1em;}
li {font-size: 10px;}
small {font-size: 80%;}

<ul>
  <li>I'm a list item with <small>small text</small>.</li>
</ul>

The ul element has its line-height computed to be 15px because for line-height, em-based values are calculated using the computed font-size of the element itself.  I declared the font-size directly, so we know its computed size in pixels.

(Yes, yes, I know, pixel-sized text is evil and wrong, but it makes explaining how all this works a lot simpler.)

So that computed value of 15px is what’s passed on to the descendent elements.  The li and small elements will inherit a line-height value of 15px.  End of story.  They don’t change it based on their own font sizes; in fact, they don’t change it at all.  They just take that 15px and use it, exactly the same as if I’d said:

ul {font-size: 15px; line-height: 1em;}
li {font-size: 10px; line-height: 15px;}
small {font-size: 80%; line-height: 15px;}

Okay, now suppose I take the em off that line-height value, so that the styles now read:

ul {font-size: 15px; line-height: 1;}
li {font-size: 10px;}
small {font-size: 80%;}

Now what’s passed on is that raw number, which is used by descendent elements as a scaling factor—a multiplier, if you will–and not the computed result.

Thus every element that inherits that value of 1 will take that value and multiply it with their computed font-sizes.  The list item, with its declared font-size: 10px, will have a computed line-height of 10px.  Then it will pass that 1 on to the small element, which will multiply it with its computed font-size.  That’s 8 pixels; therefore, its line-height will also be 8 pixels.

The end result is exactly the same as if I’d written:

ul {font-size: 15px; line-height: 1;}
li {font-size: 10px; line-height: 10px;}
small {font-size: 80%; line-height: 8px;}

That’s a pretty major difference.  This is why it’s always strongly recommended that you use unitless numbers if you’re going to set a line-height on something like the html or body elements, or indeed on any element that is going to have descendant elements.

The fact that the CSS validator has a bug that causes it to generate parse errors on unitless number values for line-height (see report #2307) rather confuses things; we get an occasional jeering e-mail over at A List Apart as a result, since running CSS validation on the site gets an error due to my use of line-height: 1;.  Jeffrey points the correspondents to that bug report, and usually we never hear anything back.

And if anyone reading this feels motivated to fix the validator, please do.  As it says in the bug report, all they really need is a patch for review.  I might do it myself when I have some free time.  That’ll be in, oh, 2009 or so.

Again: the property line-height can accept unitless number values, and they’re a better choice than united values in 99 out of 100 cases anyway.  Okay?  Thank you.

[Addendum 26 Aug 06: Roger Johansson points out a bug in older Gecko browsers relating to unitless line-heights.]


AEA Atlanta Heats Up

Published 19 years, 7 months past

Registration for AEA Atlanta has been open a week now and one-fifth of the seats are already claimed, so you might want to step up the pressure on your boss.  The early bird deadline won’t be here for another three and a half weeks, but seat availability may not last that long.  (As I’ve mentioned before, it didn’t in Philadelphia.)

Even better, the value of any one of those seats just went up.  How so?  We’ve just announced that we’ll have two (count ’em!) guest speakers joining us: Jason Santa Maria, who delivered one of the highest rated presentations in Philadelphia; and Atlanta native Todd Dominey of Dominey Design, Turner Entertainment, and What Do I Know.

What will they talk about?  You’ll have to come to Atlanta to find out.  Personally, I can’t wait.


Browse the Archive

Earlier Entries

Later Entries