Posts from April 2012

I get asked from time to time for my number one tip for new parents.  My answer is always a single word.

“Earplugs.”

Seriously.  Get some earplugs.  They don’t have to be fancy; the squishy yellow foam plugs you can get in a cardboard holder for a dollar work just fine.  If you already have some fancier in-ear jobs for rock concerts or woodworking or whatever, those are good too.

Because as much as you love your new baby, and as much as you will work to keep them calm and happy, there will almost certainly be times when they are hurting or uncomfortable or just generally upset and unable to be soothed.  No matter how much you cuddle and sing and swaddle, they will scream and cry.  Some kids will do this rarely.  Others will do it all the time.  (A friend of ours tells how her eldest child screamed more or less non-stop from the day she was born until the day she walked.)  I don’t honestly know which is harder to handle, but I do know that the screaming worked its way through my eardrums and into my brain to induce a panicked pseudo-flight-or-flight response.  It was cumulatively, enormously stressful.

Earplugs do not shut out the cries completely.  You will not be denying your baby’s distress or placing unwarranted distance between you and your child.  Earplugs simply take the raw, serrated edge off their cry, giving you some mental space to cope with it and be a calmer and therefore better parent.  It lets you hang in there longer, putting off the point where you have to put the baby in the crib and walk away for a few minutes.  (And that’s okay too; the baby won’t die if you take five to regroup.)  That means more direct contact with your baby, and possibly a shorter time to a calm baby due to longer, more continuous periods of parental contact.

So: earplugs.  Probably the highest-ROI parental purchase I ever made.

• Plugging Up was published on Friday, April 27th, 2012.
• It was assigned to the Hacks and Parenting categories.
• There have been eight replies.

Linear gradients in CSS can lead to all kinds of wacky, wacky results — some of them, it sometimes seems, in the syntax itself.

Let me note right up front that some of what I’m talking about here isn’t widely deployed yet, nor for that matter even truly set in stone.  Close, maybe, but there could still be changes.  Even if nothing actually does change, this isn’t a “news you can use RIGHT NOW” article.  Like so much of what I produce, it’s more of a stroll through a small corner of CSS, just to see what we might see.

For all their apparent complexity, linear gradients are pretty simple.  You define a direction along which the gradient progresses, and then list as many color stops as you like.  In doing so, you describe an image with text, sort of like SVG does.  That’s an important point to keep in mind:  a linear (or radial) gradient is an image, just as much as any GIF or PNG.  That means, among other things, that you can mix raster images and gradient images in the background of an element using the multiple background syntax.

But back to gradients.  Here’s a very simple gradient image:

linear-gradient(45deg, red, blue)

The 45deg defines the gradient line, which is the line that defines how the gradient progresses.  The gradient line always passes through the center of the background area, and its specific direction is declared by you, the author.  In this case, it’s been declared to point toward the 45-degree angle.  red and blue are the color stops.  Since the colors don’t have stop distances defined, the distances are assumed to be 0% and 100%, respectively, which means you get a gradient blend from red to blue that progresses along the gradient line.

You can create hard stops, too:

linear-gradient(45deg, green 50%, lightblue 50%)

That gets you the result shown in Figure 1, to which I’ve added (in Photoshop) an arrow showing the direction of the gradient line, as well as the centerpoint of the background area.  Each individual “stripe” in the gradient is perpendicular to the gradient line; that’s why the boundary between the two colors at the 50% point is perpendicular to the gradient line.  This perpendicularness is always the case.

Now, degrees are cool and all (and they’ll be changing from math angles to compass angles in order to harmonize with animations, but that’s a subject for another time), but you can also use directional keywords.  Two different kinds, as it happens.

The first way to use keywords is to just declare a direction, mixing and matching from the terms top, bottom, right, and left.  The funky part is that in this case, you’re declaring the direction the gradient line comes from, not that toward which it’s going; that is, you specify its origin instead of its destination.  So if you want your gradient to progress from the bottom left corner to the top right corner, you actually say bottom left:

linear-gradient(bottom left, green 50%, lightblue 50%)

But bottom left does not equal 45deg, unless the background area is exactly square.  If the area is not square, then the gradient line goes from one corner to another, with the boundary lines perpendicular to that, as shown in Figure 2.  Again, I added a gradient line and centerpoint in Photoshop for clarity.

Of course, this means that if the background area resizes in either direction, then the angle of the gradient line will also change.  Make the element taller or more narrow, and the line will rotate counter-clockwise (UK: anti-clockwise); go shorter or wider and it will rotate clockwise (UK: clockwise).  This might well be exactly what you want.  It’s certainly different than an degree angle value, which will never rotate due to changes in the background’s size.

The second way to use keywords looks similar, but has quite different results.  You use the same top/bottom/left/right terms, but in addition you prepend the to keyword, like so:

linear-gradient(to top right, green 50%, lightblue 50%)

In this case, it’s clear that you’re declaring the gradient line’s destination and not its origin; after all, you’re saying to top right.  However, when you do it this way, you are not specifying the top right corner of the background area.  You’re specifying a general topward-and-rightward direction.  You can see the result of the previous sample in Figure 3; once more, Photoshop was used to add the gradient line.

Notice the hard-stop boundary line.  It’s actually stretching from top left to bottom right (neither of which is top right).  That’s because with the to keyword in front, you’re triggering what’s been referred to as “magic corners” behavior.  When you do this, no matter how the background area is (re)sized, that boundary line will always stretch from top left to bottom right.  Those are the magic corners.  The gradient line thus doesn’t point into the top right corner, unless the background area is perfectly square — it points into the top right quadrant (quarter) of the background area.  Apparently the term “magic quadrants” was not considered better than “magic corners”.

The effect of changing the background area’s size is the same as before; decreasing the height or increasing the width of the background area will deflect the gradient line clockwise, and the opposite change to either axis will produce the opposite deflection.  The only difference is the starting condition.

Beyond all this, if you want to use keywords that always point toward a corner, as in Figure 2 except specifying the destination instead of the origin, that doesn’t appear to be an option.  Similarly, neither can you declare an origin quadrant.  Having the gradient line always traverse from corner to corner means declaring the origin of the gradient line (Figure 2).  If you want the “magic corners” effect where the 50% color-stop line points from corner to corner, with the gradient line’s destination flexible, then you declare a destination quadrant (Figure 3).

As for actual support:  as of this writing, only Firefox and Opera support “magic corners”.  All current browsers — in Explorer’s case, that means IE10 — support angles and non-magic keywords, which means Opera and Firefox support both keyword behaviors.  Nobody has yet switched from math angles to compass angles.  (I used 45deg very intentionally, as it’s the same direction in either system.)

That’s the state of things with linear gradients right now.  I’m interested to know what you think of the various keyword patterns and behaviors — I know I had some initial trouble grasping them, and having rather different effects for the two patterns seems like it will be confusing.  What say you?

• Linear Gradient Keywords was published on Thursday, April 26th, 2012.
• It was assigned to the CSS and Standards categories.
• There have been ten replies.

I recently stumbled over a subtle interaction between cookie policies and localStorage in Firefox.  Herewith, I document it for anyone who might run into the same problem (all four of you) as well as for you JS developers who are using, or thinking about using, locally stored data.  Also, there’s a Bugzilla report, so either it’ll get fixed and then this won’t be a problem or else it will get resolved WONTFIX and I’ll have to figure out what to do next.

The basic problem is, every newfangled “try code out for yourself” site I hit is just failing in Firefox 11 and 12.  Dabblet, for example, just returns a big blank page with the toolbar across the top, and none of the top-right buttons work except for the Help (“?”) button.  And I write all that in the present tense because the problem still exists as I write this.

What’s happening is that any attempt to access localStorage, whether writing or reading, returns a security error.  Here’s an anonymized example from Firefox’s error console:

Error: uncaught exception: [Exception... "Security error"  code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)"  location: "http://example.com/code.js Line: 666"]

When you go to line 666, you discover it refers to localStorage.  Usually it’s a write attempt, but reading gets you the same error.

But here’s the thing: it only does this if your browser preferences are set so that, when it comes to accepting cookies, the “Keep until:” option is set to “ask me every time”.  If you change that to either of the other two options, then localStorage can be written and read without incident.  No security errors.  Switch it back to “ask me every time”, and the security errors come back.

Just to cover all the bases regarding my configuration:

1. Firefox is not in Private Browsing mode.
2. dom.storage.default_quota is 5120.
3. dom.storage.enabled is true.

Also:  yes, I have my cookie policy set that way on purpose.  It might not work for you, but it definitely works for me.  “Just change your cookie policy” is the new “use a different browser” (which is the new “get a better OS”) and it ain’t gonna fly here.

To my way of thinking, this behavior doesn’t conform to step one of 4.3 The localStorage attribute, which states:

The user agent may throw a SecurityError exception instead of returning a Storage object if the request violates a policy decision (e.g. if the user agent is configured to not allow the page to persist data).

I haven’t configured anything to not persist data — quite the opposite — and my policy decision is not to refuse cookies, it’s to ask me about expiration times so I can decide how I want a given cookie handled.  It seems to me that, given my current preferences, Firefox ought to ask me if I want to accept local storage of data whenever a script tries to write to localStorage.  If that’s somehow impossible, then there should at least be a global preference for how I want to handle localStorage actions.

Of course, that’s all true only if localStorage data has expiration times.  If it doesn’t, then I’ve already said I’ll accept cookies, even from third-party sites.  I just want a say on their expiration times (or, if I choose, to deny the cookie through the dialog box; it’s an option).  I’m not entirely clear on this, so if someone can point to hard information on whether localStorage does or doesn’t time out, that would be fantastic.  I did see:

User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user.

…from the same section, which to me sounds like localStorage doesn’t have expiration times, but maybe there’s another bit I haven’t seen that casts a new light on things.  As always, tender application of the Clue-by-Four of Enlightenment is welcome.

Okay, so the point of all this: if you’re getting localStorage failures in Firefox, check your cookies expiration policy.  If that’s the problem, then at least you know how to fix it — or, as in my case, why you’ll continue to have localStorage problems for the next little while.  Furthermore, if you’re writing JS that interacts with localStorage or a similar local-data technology, please make sure you’re looking for security exceptions and other errors, and planning appropriate fallbacks.

• Firefox Failing localStorage Due to Cookie Policy was published on Wednesday, April 25th, 2012.
• It was assigned to the Browsers, Standards, and Web categories.
• There have been eleven replies.

This picture completely cracks me up every time I look at it:

So guess what?  It’s caption contest time!  Give us your best caption(s) in the comments, and see if you have what it takes to boost the inherent hilarity.  Knock us out!

(Photo credit: Drew Angerer/The New York Times.)

• Boy Howdy! was published on Wednesday, April 18th, 2012.
• It was assigned to the Humor category.
• There have been thirty-nine replies.

A couple of weeks back I wrote about customizing your markup, but I got an important bit wrong and while I’ve corrected the post, I wanted to clear up the error in detail.

I said that you wrap portions of your document (or the whole thing) in an element element and use the customized element inside.  This is incorrect, and actually a very bad idea.  In fact, you define your customized elements using an element element and then use the customized elements later in the document.  Something like this:

<element extends="h1" name="x-superh1">
</element>

<h1 is="superh1">UltraMegaPower!!!</h1>
<h1>Regular Old Power</h1>

The line break inside the element element isn’t required — I just threw it in for clarity.

The element element can optionally contain template markup, but I honestly don’t understand that part of it yet.  I get the general idea, but I haven’t crawled through the specifics long enough to have really internalized all the fiddly bits.  And as we all know by know, the fiddly bits are where understanding lives and dies.  (Also where the Devil hangs out, or so I’ve been told.)

I still firmly believe that all this papers over a much bigger problem, which is the arbitrary barrier to devising and using actual custom elements (as opposed to customized existing elements).  HTML5 already allows you to make up your own bits of language: you can make up any attribute you want as long as your preface the name with data-.  Okay, so that’s a little bit clumsy naming-wise, but the capability is there.  You don’t have to register your attributes, or declare them in a list, or any of that other stuff.  You just make up data-timing or data-proglang or data-sttngcharacter on the spot and off you go.

This is not possible for elements.  You can’t even make up a prefixed element name, whether it’s data-kern or x-kern or even xkern (to avoid the limitation that hyphens aren’t allowed in element names).  You just can’t devise your own elements.  The best you can do is use the element element to sprinkle some semantic dust bunnies on top of elements that already exist.

Of course, all this “you can’t” and “not possible” applies to the specification.  Browsers will let you feed them any old element name and style it, script it, whatever.  Some say that’s more than enough.  If the browser lets you do it, why let the specification hold you back?  And of course, that’s how most people will approach the situation.

To someone like me, though, who spent years (literal years) explaining to web folk the world over that just because Internet Explorer for Windows let you write width: 12 px, actually writing it was still a bad idea — well, those habits die hard.  Just doing stuff because the browser let you do it is not always a good idea.  In fact, more often than not it’s a bad idea.

None of that really matters, as I say, because people are going to inject their own elements into their markup.  They’ll do it because it’s easier than thinking about the proper element to use, or they’ll do it because no appropriate element yet exists, or for some other reason.  That’s why the HTML5 specification ought to include the ability to do it, so that we have a paved path and defined best practices.  The capability is useful, as the data- attribute feature demonstrates.  If there’s a good, solid technical reason why extending that customization from attributes to elements is not desirable, I’d really like to know what it is.

• Element Customization was published on Tuesday, April 10th, 2012.
• It was assigned to the (X)HTML and HTML5 categories.
• There have been nine replies.

I’ve been messing around with native calculated values in CSS, and there’s something a bit surprising buried in the value format.  To quote the CSS3 Values and Units specification:

Note that the grammar requires spaces around binary ‘+’ and ‘-’ operators. The ‘*’ and ‘/’ operators do not require spaces.

In other words, two out of four calculation operators require whitespace around them, and for the other two it doesn’t matter.  Nothing like consistency, eh?

This is why you see examples like this:

width: calc(100%/3 - 2*1em - 2*1px);

That’s actually the minimum number of characters you need to write that particular expression, so far as I can tell.  Given the grammar requirements, you could legitimately rewrite that example like so:

width: calc(100% / 3 - 2 * 1em - 2 * 1px);

…but not like so:

width: calc(100%/3-2*1em-2*1px);

The removal of the spaces around the ‘-’ operators means the whole value is invalid, and will be discarded outright by browsers.

We can of course say that this last example is kind of unreadable and so it’s better to have the spaces in there, but the part that trips me up is the general inconsistency in whitespace requirements.  There are apparently very good reasons, or at least very historical reasons, why the spaces around ‘+’ and ‘-’ are necessary.  In which case, I personally would have required spaces around all the operators, just to keep things consistent.  But maybe that’s just me.

Regardless, this is something to keep in mind as we move forward into an era of wider browser support for calc().

Oh, and by the way, the specification also says:

The ‘calc()’ expression represents the result of the mathematical calculation it contains, using standard operator precedence rules.

Unfortunately, the specification doesn’t seem to actually define these “standard operator precedence rules”.  This makes for some interesting ambiguities because, as with most standards, there are so many to choose from.  For example, 3em / 2 * 3 could be “three em divided by two, with the result multiplied by three” (thus 4.5em) or “three em divided by six” (thus 0.5em), depending on whether you privilege multipliers over dividers or vice versa.

I’ve looked around the Values and Units specification but haven’t found any text defining the actual rules of precedence, so I’m going to assume US rules (which would yield 4.5em) unless proven otherwise.  Initial testing seems to bear this out, but not every browser line supports these sorts of expressions yet, so there’s still plenty of time for them to introduce inconsistencies.  If you want to be clear about how you want your operators to be resolved, use parentheses: they trump all.  If you want to be sure 3em / 2 * 3 resolves to 4.5em, then write it (3em / 2) * 3, or (3em/2)*3 if you care to use inconsistent whitespacing.

• Whitespace in CSS Calculations was published on Tuesday, April 10th, 2012.
• It was assigned to the CSS and Standards categories.
• There have been eighteen replies.

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?

• Transiently Damaged PDF Attachments was published on Thursday, April 5th, 2012.
• It was assigned to the Questions and Tools categories.
• There have been twenty-one replies.