meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Archive: 'Tools' Category

Collective Editorial: the Plugin

As I was reading an article with a few scattered apostrophe errors, I wished that I could highlight each one, hit a report button, and know that the author had been notified of the errors so that they could fix them.  No requirement to leave a comment chastising them for bad grammar, replete with lots of textual context so they could find the errors—just a quick “hey, I spotted this error, now you know so you can fix it” notice, sent in private to them.

Then I realized that I wanted that for my own site, to let people tell me when I had gaffes in need of repair.  It’s an almost-wiki, where the crowd can flag errors that need to be corrected without having to edit the source themselves—or have the power to edit it themselves, for that matter, which is an open door for abuse.

I haven’t thought this through in tons of detail, but here’s how it feels in my head:

  • Visitors highlight a typo and click a button to report it.  Or else click a button to start reporting, highlight a word, and click again to submit.  This part is kind of fuzzy in my head, and yes, “click” is not the best term here, but it’s one we all understand.
  • Interesting extra feature: the ability to classify the type of error when reporting.  For example: apostrophe, misspelling, parallelism, pronoun trouble.
  • Other interesting extra feature: the ability to inform users of the ground rules before they report.  For example: “This site uses British punctuation rules, the Oxford comma, and American spelling.”  (Which I do.)
  • The author gets notice whenever an error is reported, or else can opt for a daily digest.
  • Each notice lets the author quickly accept or reject the reported error, much as can be done with edits in MS Word and similar programs, along with a link that will jump the author straight to the reported error so they can see it in context.  If rejected, future reports of that word are disabled.  If accepted, the change is made immediately, without requiring a dive into the CMS.
  • When an error is reported, future visitors to the site will see any already-reported errors in highlight.  This keeps them from reporting the same thing over and over, and also acts as incentive to the author to fix errors quickly.  (The highlight style could be customizable.)
  • Reports can only happen at the word level, not the individual letter level.  So reporting an “it’s” error highlights all of “it’s”, not just the offending apostrophe.  Perhaps also for multiple words, though only up to a certain number, like three.  And yes, I’m keenly aware of the challenges of defining a “word” in an internationally-aware manner, but perhaps in ideographic languages you switch to per-symbol.  (Not an expert here, so take that with a few grinders of salt.)
  • The author can optionally limit the number of reports permitted per hour/day/whatever.  This could be enforced globally or on a per-user basis, though globally is a tad more robust.

That’s how I see it working, after a few minutes’ thought.  It seems pretty achievable as a CMS plugin, actually, though I confess that I don’t have anywhere close to the time and coding chops needed to make it happen right now (or any time soon).  The biggest challenge to me seems like the “edit-on-accept-without-CMS-diving” part, since there are so many CMSes and particularly since static sites are staging a comeback.  Still, I think it would be a fun and worthwhile project for someone out there.  If somebody takes it on, I’d love to follow along and see where it ends up, particularly if they do it for WordPress (which is what the blog hereabouts runs on).

A Precise CSS3 Color Table

In the course of expanding my documentation of color values, I failed to find a table that listed all 147 SVG-and-CSS3-defined keywords along with the equivalent RGB decimal, RGB percent, HSL, hexadecimal, and (when valid) short-hex values.  There were some tables that listed some but not all of those value types, and one that listed all the value types (plus CMYK) along with a few hundred other keywords, but none that listed all of the CSS keywords and value types.  And none that I saw used precise values for the RGB percent and HSL types, preferring instead to round off at the expense of some subtle differences in color.

So I created my own table, which you can now find in the CSS area of meyerweb.  Most of it is dynamically generated, taking a list of keywords and RGB decimal equivalents and then calculating the rest of the values from there.  The presentation is still a work in progress, and may change a little or a lot.  In particular, if I can’t find a better algorithm for determining which rows should have white text instead of black, I’ll probably shift away from the full-row background colors to some other presentation.  (Update: it’s been greatly improved, so I’m sticking with the full-row backgrounds.  For now, anyway.)

My thanks to Tab Atkins for his donation of the RGB-to-HSL routine I adapted as well as help improving the pick-light-or-dark-text algorithm; and to the people who responded positively on Twitter when I mused about the idea there.

Update 25 May 12: the table now allows sorting (both directions) on the Keyword, RGB Decimal, and HSL columns.  The sorting and styling code uses methods like el.classList.remove() so it may not function well, or at all, in older versions of Internet Explorer.  The numeric sorts also appear to be borked in Opera and Chrome for no reason I can discern, and it’s not like I did anything fancy in the JavaScript—exactly the opposite, I’d wager.  (Speaking of which, I’m sure my JavaScript is an non-stop amateur-hour horrorshow.  I’m okay with that.  If you aren’t, you might want to avert your gaze.)  If there’s a simple fix that doesn’t screw up other browsers, like Safari and Firefox, I’m interested.  If not, then we’ll all just have to live with it.

Update II 25 May 12: thanks to the folks who responded to my question over at StackOverflow as well as on Twitter, the sorting is now stable across browsers.  Bonus: I feel like thanks to everything I’ve learned along the way, the JavaScript in general is getting halfway to decent.  Go me.

As always: share and enjoy!

Transiently Damaged PDF Attachments

I have this very odd problem that seems to be some combination of PDF, Acrobat, Outlook, Thunderbird, and maybe even IMAP and GMail.  I know, right?

The problem is that certain PDFs sent to me by a single individual won’t open at first.  I’ll get one as an email attachment.  I drag the attachment to a folder in my (Snow Leopard) Finder and double-click it to open.  The error dialog I immediately get from Acrobat Professional is:

There was an error opening this document. The file is damaged and could not be repaired.

Preview, on the other hand, tells me:

The file “[redacted]” could not be opened.  It may be damaged or use a file format that Preview doesn’t recognize.

When this happens, I tell the person who sent me the file that The Problem has happened again.  She sends me the exact same file as an attachment.  Literally, she just takes the same file she sent before and drags it onto the new message to send to me again.

And this re-sent file opens without incident.  Every time.  Furthermore, extra re-sends open without incident.  I recently had her send me the same initially damaged file five times, some attached to replies and others to brand-new messages.  All of them opened flawlessly.  The initially damaged file remained damaged.

Furthermore, if I go through the GMail web interface, I can view the initial attached PDF (the one my OS X applications say is damaged) through the GMail UI without trouble.  If I download that attachment to my hard drive, it similarly opens in Acrobat (and Preview) without trouble.

A major indication of damage: that first download is a different size than all the others.  In the most recent instance, the damaged file is 680,302 bytes.  The undamaged files are all 689,188 bytes.  If only I knew why it’s damaged the first time, and not all the others!

So far, I’ve yet to see this happen with PDFs from anyone else, but then I receive very few attached PDFs from people other than this one (our events manager at An Event Apart, who sends and receives PDFs and Office documents like they’re conversational speech—an occupational hazard of her line of work), and it only seems to happen with PDFs of image scans that she’s created.  Other types of PDFs, whether she generated them or not, seem to come through fine; ditto for other file types, like Word documents.  I’d be tempted to blame the scanning software, but again: the exact same file is damaged the first time, and fine on every subsequent re-attachment.

I’ve done some Googling, and found scattered advice on ways clear up corrupted-PDF-attachment problems in Thunderbird.  I’ve followed these pieces of advice, and nothing has helped.  In summary, I have so far:

  1. Set mail.server.default.fetch_by_chunks to false.
  2. Set mail.imap.mime_parts_on_demand to false.
  3. Set mail.server.default.mime_parts_on_demand to false.
  4. Tried the Thunderbird extension OPENATTACHMENTBYEXTENSION.  That failed, and so I immediately uninstalled it because handling files by extension alone is just asking to be pwned, regardless of your operating system or personal level of datanoia.  (I wouldn’t have left it installed had it worked; I just wanted to see if it did work as a data point.)

Here’s what I know about the various systems in play here:

  • I’m using Thunderbird 11.0.1 on OS X 10.6.8.
  • The attachments are always sent via Outlook 2010 on Windows 7.
  • The software used for the scanning is the HP scanning software that was installed with the scanner.  Scans are saved to the hard drive, renamed, and then manually attached to the email.  On resend, the same file is manually attached to the email.
  • My email account is a GMail IMAP account.

So.  Any ideas?

Finding Unicode

A little while back, I was reading some text when I realized the hyphens didn’t look quite right.  A little too wide, I thought.  Not em-dash wide, but still…wide.  Wide-ish?  But when I copied some of the text into a BBEdit window, they looked just like the hyphens I typed into the document.

Of course, I know Unicode is filled with all manner of symbols and that the appearance of those symbols can vary from one font face to another.  So I changed the font face, made the size really huge, and behold: they were indeed different characters.  At this point, I was really curious about what I’d found.  What exactly was it?  How would I find out?

For the record, here’s the character in question:

Googling “−” and “− Unicode” got me nothing useful.  I knew I could try the Character Viewer in OS X, and eventually I did, but I was wondering if there was a better (read: lazier) solution.  I asked the Twittersphere for advice, and while I don’t know if these solutions are any lazier, here are the best of the suggestions I received.

  • Unicode Lookup, a site that lets you input or paste in any character and get a report on what it is and how one might call it in various encodings.
  • Richard Ishida’s UniView Lite, which does much the same as Unicode Lookup with the caveat that once you’ve input your character, you have to hit the “Chars” button, not the “Search” button.  The latter is apparently how you search Unicode character names for a word or other string, like “dash” or “quot”.
  • UnicodeChecker (OS X), a nice utility that includes a character list pane as well as the ability to type or paste a character into an input and instantly get its gritty details.

Any of those will tell you that the − in question is MINUS SIGN, codepoint 8722 (decimal) / 2212 (UTF-16 hex) / U+2212 (Unicode hex) / et cetera, et cetera.  Did you know it was designated in Unicode 1.1?  Now you do, thanks to UnicodeChecker and this post.  You’re welcome.

Update 2 Mar 12:  Philippe Wittenberg points out in the comments that you can add a UnicodeChecker service.  With that enabled, all you have to do is highlight a character, summon the contextual menu (right-click, for most of us), and have it shown in UnicodeChecker.  Now that’s the kind of laziness I was trying to attain!

Seeing the matrix()

Over the weekend, Aaron Gustafson and I created a tool for anyone who wants to resolve a series of CSS transforms into a matrix() value representing the same end state.  Behold: The Matrix Resolutions.  (You knew that was coming, right?)  It should work fine in various browsers, though due to the gratuitous use of keyframe animations on the html element’s multiple background images it looks best in WebKit browsers.

The way it works is you input a series of transform functions, such as translateX(22px) rotate(33deg) scale(1.13).  The end-state and its matrix() equivalent should update whenever you hit the space bar or the return key, or else explicitly elect to take the red pill.  If you want to wipe out what you’ve input and go back to a state of blissful ignorance, take the blue pill.

There is one thing to note: the matrix() value you get from the tool is equivalent to the end-state placement of all the transforms you input.  That value most likely does not create an equivalent animation, particularly if you do any rotation.  For example, animating translateX(75px) rotate(1590deg) translateY(-75px) will not appear the same as animating matrix(-0.866025, 0.5, -0.5, -0.866025, 112.5, 64.9519).  The two values will get the element to the same destination, but via very different paths.  If you’re just transforming, not animating, then that’s irrelevant.  If you are, then you may want to stick to the transforms.

This tool grew out of the first Retreats 4 Geeks (which was AWESOME) just outside of Gatlinburg, TN.  After some side conversations betwen me and Aaron during the CSS training program, we hacked this together in a few hours on Saturday night.  Hey, who knows how to party?  Aaron of course wrote the JavaScript.  Early on we came up with the punny name, and of course once we did that the visual design was pretty well chosen for us.  A free TTF webfont (for the page title), a few background images, and a whole bunch of RGBa colors later we had arrived.  Creating the visual appearance was a lot of fun, I have to say.  CSS geeks, please feel free to view source and enjoy.  No need to say “whoa”—it’s actually not that complicated.

So anyway, there you go.  If you want to see the matrix(), remember: we can only show you the door. You’re the one that has to walk through it.

Reset v2.0

Earlier today, I updated the CSS Tools: Reset CSS page to list the final version of Reset v2.0, as well as updated the reset.css file in that directory to be v2.0.  (I wonder how many hotlinkers that will surprise.)  In other words, it’s been shipped.  Any subsequent changes will trigger version number changes.

There is one small change I made between 2.0b2 and 2.0 final, which is the replacement of the “THIS IS BETA” warning text with an explicit lack of license.  The reset CSS has been in the public domain ever since I first published it, and the Reset CSS page explicitly said it was, but the file itself never said one way or the other.  Now it does.

Thanks to everyone who contributed their thoughts and perspectives on the new reset.  Here’s to progress!

Reset Revisited

It was close to four years ago now that I first floated (ha!), publicly refined, and then published at its own home what’s become known as the “Eric Meyer Reset”.  At the time, I expected it would be of interest to a small portion of the standards community, provoke some thought among fellow craftspeople, and get used occasionally when it seemed handy.  Instead, it’s ended up almost everywhere.

(This occasionally backfires on me when people use it in the CSS of e-mail campaigns, it’s exposed by older mail clients, and people then mail me to demand that I unsubscribe them from the mailing list.  But that’s not the worst backfire—I’ll get to that in just a minute.)

Four years is long enough for a revisit, I’d say.  I spent a little time working on and thinking about it over the holidays.  Here’s where I ended up.

/* http://meyerweb.com/eric/tools/css/reset/ 
   v2.0b1 | 201101 
   NOTE: WORK IN PROGRESS
   USE WITH CAUTION AND TEST WITH ABANDON */

html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, figcaption, figure, 
footer, header, hgroup, menu, nav, section, summary,
time, mark, audio, video {
	margin: 0;
	padding: 0;
	border: 0;
	outline: 0;
	font-size: 100%;
	font: inherit;
	vertical-align: baseline;
}
/* HTML5 display-role reset for older browsers */
article, aside, details, figcaption, figure, 
footer, header, hgroup, menu, nav, section {
	display: block;
}
body {
	line-height: 1;
}
ol, ul {
	list-style: none;
}
blockquote, q {
	quotes: none;
}
blockquote:before, blockquote:after,
q:before, q:after {
	content: '';
	content: none;
}

/* remember to define visible focus styles! 
:focus {
	outline: ?????;
} */

/* remember to highlight inserts somehow! */
ins {
	text-decoration: none;
}
del {
	text-decoration: line-through;
}

table {
	border-collapse: collapse;
	border-spacing: 0;
}

Some of you may be thinking: “Hey, it’s the HTML5 Doctor reset!”  Actually, no, though I did use their work as a check on my own.  I felt like that one went a bit far, to be honest.  What I have above is simply the reset I had before with the following changes:

  • Removed font from the selector of the first rule.  It’s been long enough now, I think.  We can let that one go.
  • Removed background: transparent from the declaration block of the first rule.  I don’t think it really served any purpose in the long run, given the way browsers style by default and the CSS-defined default for background-color (which background encompasses, of course).  Its removal will also stop causing table-appearance glitches in old versions of IE, if that’s of interest.
  • Added font: inherit to the declaration block of the first rule.  There are still older versions of IE that don’t understand inherit, but support is now widespread enough that I feel this can go in.  I left font-size: 100% as a sop to older browsers, and override it with the next declaration in those browsers that understand.
  • Added HTML5 elements to the selector of the first rule.  While this is probably unnecessary right now, those elements being about as styled as a common div, it’s in the spirit of the thing to list them.
  • A separate rule to make blocks of those HTML5 elements that generally default to blocks.  This is more backward-looking, as the comment suggests, and it’s a prime excision candidate for anyone adapting these styles to their own use.  However, if you’ve ever known the pain of HTML5 markup shattering layouts in, say, older versions of Firefox, this rule has a place.
  • Removed the “cellspacing” comment near the end.  It used to be the case that lots of browsers needed the support, but that’s a lot less true today.
  • And then the big one, trying to correct the biggest backfire of the whole enterprise: I commented out and subtly altered the commentary on the :focus rule without removing it entirely.

On that last point, defining an invisible focus was the biggest blunder of the original reset.  In hindsight, it’s really a obvious unforced error, but when I published the reset I literally had no conception that it would be just copied (or, worse, hotlinked) blindly in a thousand sites and frameworks.  As the new advocacy site outlinenone.com points out, I did say right in the style sheet that one should define a focus style.  I put in a value of 0 in the same spirit I zeroed out paragraph margins and set the body element’s line-height to 1: by taking everything to a “plain baseline”, the thoughtful craftsperson would be reminded to define the focus style that made most sense for their site’s design.

Instead, focus outlines were obliterated wholesale as lots and lots of people, not all of them craftsmen, just copied the reset and built on top of it without thinking about it.  I can’t find it in my heart to fault them: most construction workers don’t think about how beams and rivets or even riveters are made.  They just bolt ‘em together and make a building.

Perhaps some of the pain would have been eased if I had said in the comment, as I do now, “remember to define visible focus styles”.  But I doubt it.

So in this revision, I’ve altered the rule and commentary to raise its visibility, but more importantly I’ve commented out the whole rule.  This time, copiers and hotlinkers won’t destroy focusing.  Some may still uncomment it and change the value back to 0, of course, but that could happen anyway.  With luck, this change will help educate.

As was the case in 2007, comments and suggestions are most welcome, and may well result in changes that make it into the final version.  Also, my thanks to the HTML5 Doctor crew for publishing their variant, which I used as a sanity check; and Michael Tuck, whose research into the history of resets got me looking back and interested in moving things forward.

Addendum 3 Jan 11:  as the previous paragraph says, and the version number (2.0b1) heavily implies, this is not a final version.  It may well change, either due to errors on my part (one of which has already come to light) or changes of mind due to discussions in the comments.  You can take this version and use it if you want, but I don’t particularly recommend it because—again—changes are likely.

Translations

A Textile Filter for BBEdit?

A few days back I tweeted a request for a Textile filter for BBEdit, which is one of those things people have asked for over the years but has never actually appeared.  There’s been a Markdown filter since forever, but since I find myself on Basecamp a lot for business reasons and Basecamp uses Textile I’d really prefer to stick to one syntax instead of constantly confusing myself by switching between two similar syntaxes.

(And I prefer to use BBEdit because I like it a lot, know it well, and have no compelling reason to switch.  Please take any thoughts of text-editor snobbery or flamewars elsewhere.)

In response, the mighty Arlen Walker told me how to install Xcode, the Text::Textile module, and a short Perl script to drop into  ~/Library/Application Support/BBEdit/Unix Support/Unix Filters.  I did that, and it all worked, but I was unhappy with the <span class="caps"> that default Textile litters all over.  I tried to disable it, failed, tweeted for help, and was contacted by the incredible Brad Choate (who wrote the Text::Textile module!).

The upshot of all this is that Brad not only told me how to disable the spans, but how to convert Textile to a standalone BBEdit filter that, so far as I can tell, shouldn’t require installation of either Xcode or Text::Textile.  I’m pretty sure about this, but since I’ve already installed Text::Textile I can’t be entirely certain.  Who wants to test it out?

All you have to do is download TextileSA_pl.zip, unzip it, and drop the Perl script into ~/Library/Application Support/BBEdit/Unix Support/Unix Filters.  Once you do that, it should immediately become available in BBEdit, even if BBEdit is already running.  (At least that’s what happens in BBEdit 9.x.)  Here’s a test file to Texile-ize if you’re so inclined:

h1. Testing the BBEdit Textile filter

This is _awesome_!  "Arlen":http://theodicius.net/ and "Brad":http://bradchoate.com/ are the *bomb*.

There’s a bug at the moment that means double-quote marks don’t get smart-encoded, but Brad’s aware of it and plans to fix it.  Also, this does a straight Textile run with nothing disabled, so it will in fact still litter <span class="caps"> around any sequence of uppercase letters (like those in, say, “BBEdit”).  If you can’t stand that even during testing, open up TextileSA.pl and insert the following after line 2312:

my $css_flags = $textile->css();
$css_flags->{'class_caps'} = '';
$textile->css($css_flags);

If you don’t mind (or even like) those spans, then of course you can slip that part.

The “SA” in TextileSA.pl stands for “StandAlone”, by the way.  I’ll drop that once I’m sure this actually works and pass it along to the BBEdit gang.

July 2014
SMTWTFS
June  
 12345
6789101112
13141516171819
20212223242526
2728293031  

Archives

Feeds

Extras