meyerweb.com

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

Archive: 'Guide' Category

Gridded Headings

In my ongoing experiments with both a realignment of meyerweb’s design and CSS Grid, I came up with an interesting heading-and-subheading technique I’d like to share.  It allows two elements to be centered as a block, while letting them text-align with respect to each other, while still line-wrapping if necessary.

Here’s a little demobox.

These Are Grid Headings

A useful technique

Boxes and Alignment

It’s the new hotness

Cool

This is pretty darned easy to implement

Gridded Headings

Wednesday, 19 May 2017

Each heading-subheading pair is composed of two heading elements wrapped in another element.  The wrapping element is the grid container for the headings, each of which become grid items.  This is the markup I used:

<div>
    <h2>These Are Grid Headings</h2>
    <h3>A useful technique</h3>
</div>

If you resize your browser window, or select the “Narrow” option, you should see that the boxes surrounding the headings stays as wide as the wider of the two headings.  It “shrink-wraps” them, visually speaking.  In addition, those boxes stay centered within the grid container.

Furthermore, given the demo’s defaults, the two headings are left-aligned with respect to each other.  You can change this: for example, if you choose to “Center-align headings”, the h2s will center when they’re shorter than the subheadings (the h3s).  On the other hand, if you select “Right-align subheads”, then the subheads will right-align themselves with respect to the headings whenever the subhead is shorter in length.

That was actually a bit misleading: if the headings are centered, they’re centered whether or not they’re shorter than the subhead.  It’s just that, if they’re longer, you can’t see that they’re centered, because left-, center-, and right-aligning them has the same effect.  Ditto for right-aligning the subheads: if they’re longer, they sit in the same place regardless of their text alignment.

The alignments hold even when line-wrapping kicks in.  Try narrowing things down to the point that the text starts wrapping.  If you’re having trouble visualizing the two elements, turn on “Separate backgrounds” to given the heads and subheads visually distinct background colors.

So: a centered box as wide as the longest of the two elements, inside which they can align themselves with respect to each other.  Here’s the CSS that makes this possible:

display: grid;
grid-template-columns:
    minmax(1em,1fr)
    minmax(min-content,max-content)
    minmax(1em,1fr);

That’s pretty much it.  The first and third grid tracks are set to be a minimum of 1em, and a maximum of 1fr.  Given the second track (which I’ll get to in a moment), this means the two tracks will split any free space within the grid container, down to a minimum of 1em.  That’s how the centering of the box work; or, if you turn off “Boxes”, how the unbounded text sticks together in the center of the layout area.

That second track, minmax(min-content,max-content), is what makes all the unusual aspects of this possible.  What that says is: “make this grid track no narrower than the narrowest of the grid items in the track, and no wider than the widest grid item”.  In practice, it’ll most likely be as wide as its widest element.

But if I just said max-content (without having the minmax() and min-content parts) for that track width, the track would always be as wide as the widest element at its widest possible layout, which in this case means without line-wrapping the contents.  That would force particularly long headings to run outside of the track, and possibly out of the grid container altogether.  You can see this by enabling “Remove minmax” and narrowing things until text lines should wrap.

It’s the minmax(min-content,max-content) that avoids this fate, because that means that while the grid track (the column the head and subhead share) can’t get any wider than the widest element it contains, it’s allowed to get narrower.  Thus, if the grid container gets too narrow to fit all the grid items’ maximum widths, the contents of the grid items are able to line-wrap, thus avoiding overspill.  In fact, the grid items can keep getting more narrow until they reach min-content, which is to say, the narrowest the track can get without having content of any grid item stick out of the track.  Then it will stop shrinking.

And finally, if you want to see how the options you’ve selected will look in a Gridless browser, select “Remove grids” and see what happens.  Some combinations may not be palatable without Grid, but remember: you can always use @supports(display: grid) to quarantine any styles that are particularly egregious in older UAs.

So there you have it.  While I’m not certain the Grid drop quotes I wrote about last month will be used in the final version of my styles—I’m still looking to see if they’ll fit with more than 17 years of vaguely ad-hoc markup patterns—it’s pretty close to certain I will use these headings, minus the boxes.  I think they’re a neat effect for blog post titles and dates.

Addendum: As of May 2017, WebKit browsers (e.g. Safari) require vendor prefixes for the min-content and max-content keywords.

Grid-Powered Drop Quotes

I’ve been experimenting with CSS Grid for various layout treatments—not high-level, whole-page layouts, but focused bits of design.  I’d like to share one of them for a few reasons.  Partly it’s because I like what I came up with.  More importantly, though, I think it illustrates a few principles and uses of CSS Grid that might not be immediately intuitively obvious.

First, here’s an interactive demo of the thing I’m going to be talking about.  You can use the checkboxes to alter aspects of the example, whether singly or in combination.  Feel free to fiddle with them before reading the rest of the article, or but you’ll probably want to come back to the demonstration as you read.  There’s also an external version of the demo as a standalone file, if you prefer opening it in a new tab and flipping back and forth.

So that’s how things have been laid out since the middle of 2005, more or less. I fiddled with a flexbox layout at one point as an experiment, but never shipped it, because it felt clumsy to be using a one-dimensional layout tool to manage a two-dimensional layout. I probably should have converted the navigation bar to flexbox, but I got distracted by something else and never returned to the effort.

Besides, Grid was coming. In the run-up to Grid support being released to the public, I was focused on learning and teaching Grid, creating test cases, and using it to build figures for publication.  And then, March 7th, 2017, it shipped to the public in Firefox 52.  I tweeted and posted an article and demo I’d put together the night before, and sat back in wonderment that the day had finally come to pass.  After 20+ years of CSS, finally, a real layout system, a set of properties and values designed from the outset for that purpose.

And then I decided, more or less in that moment, to convert my personal site to use Grid for its main-level layout.  It took me less than five minutes…

Let’s dig in!  The core concept here is a Grid-powered version of the big drop-quote on the left side, there, which is a relatively common treatment for blockquotes.  To make this happen, I’ve applied display: grid to the blockquote element itself, and added the opening quote using generated content, like so:

blockquote {
   display: grid;
   grid-template-columns: -webkit-min-content 1fr;
   grid-template-columns: min-content 1fr;
}
blockquote::before {
   grid-column: 1;
   content: "“";
   font-size: 5em;
   font-weight: bold;
}

There’s more to the actual styles of both rules, but that’s the central thesis: set up a two-column grid, and generate a great big opening quote.

The first thing to note here is that generated content also generates a pseudo-element that can be styled.  You may already realize this, since it’s known we can style generated content separately from the main content of the element.  But given that, if a grid is applied to the element, then any generated content’s pseudo-element, whether ::before or ::after, will become a grid item.  You can then place it in the grid.

I first came across this concept in the comments on my ALA article “Practical CSS Grid”, where Šime proposed using generated elements as a hack to get around the inability to directly style grid cells.  Here, I’m just using one to push a quote over to the side.

Why do this, when we can already use floats or relative/absolute positioning approaches to do the same?  Because it’s not quite the same: with Grid, the column containing the drop-quote responds to any changes to the quotation symbol.  Change the font, change its size, have the preferred font fail and fall back to an unexpected face, or replace the character with an SVG image, and the first column will resize thanks to the min-content track sizing, and the actual main content of the blockquote will adjust its placement to accommodate.  That didn’t happen with earlier techniques.

And yes, there is a vendor prefix in there.  Safari’s 10.1 Grid support came with -webkit- prefixed versions of min-content, max-content, and fit-content.  So I did the old pattern of prefixed first, unprefixed second.  This should be necessary only until the next release; Safari has already dropped the prefixes in its latest Technology Preview builds.  The change apparently just didn’t quite make the cut for 10.1.  It’s sad, but it’s also temporary.

In the meantime, this does mean that if you want to restrict your Grid styles only to implementations that don’t require prefixes, use that in your feature queries:

@supports (grid-template-columns: min-content) {…}

That, as well as a number of close variants like using grid-template-rows or max-content, will keep your Grid styles away from Safari until they update their Grid support in the public release channel.

That’s all nice, but there’s a great deal more to learn!  If you use the “Border” checkbox in the demo, you’ll see a dotted red border around the drop quote’s pseudo-element.  Notice that it matches the height of the opening paragraph, not the entire height of the blockquote.  That’s because the pseudo-element and the first paragraph share a row track.  The following paragraphs are in their own row tracks.

This brings up two things to consider.  First, all the child elements of the blockquote are now grid items.  That means the drop quote’s pseudo-element, but also all the paragraphs contained by the blockquote.  The same would happen to any child elements.  We could get around that by wrapping all the contents of the blockquote in a div or something like that, but I’d rather not.  So, this grid has four grid items: the pseudo-element, and three paragraphs.

This leads us to the second consideration: without placing the paragraphs into the same column, they’ll auto-flow into whatever grid cells are available.  You can see this by selecting the “Auto placement” option.  The first column will contain the quote and the second paragraph, as narrow as they both can be due to min-content.  The second column will contain the first and third paragraphs.

How I get around this in the working version is to explicitly put all the paragraphs—really, all child elements of the blockquote, which just happen in the case to be paragraphs—into the second column, like this:

blockquote > * {grid-column: 2;}

Okay, but how do they end up stacked vertically?  After all, I didn’t assign each of those child elements to a row, did I?

Wait a minute.  What rows?

If you go back and look at the CSS I showed, there is nothing about rows.  The property grid-template-rows exists, but I didn’t use it.  All I did was define columns.

Each child element goes into a row of its own anyway, because Grid has the ability to automatically create columns or rows when needed.  Suppose you define a three-by-three grid, and then assign a grid item to the fifth column of the fourth row.  What should happen?  The browser should auto-create as many columns and rows as needed.  Any auto-created tracks will have zero width or height if they don’t contain any grid items, unless you size them using grid-auto-columns or grid-auto-rows, but we’re not going there today.  The point is, here I’ve said all of the blockquote’s child elements should go into column 2.  Given that, they’ll auto-fill rows as available and auto-create rows as needed, filling them in once they’re created.

So the blockquote in the demo above has two columns because I explicitly defined them, and three rows because that’s what it needed to create to handle the three child elements.  If I’d added two more paragraphs and an unordered list, the grid would have had two columns and six rows (because six chid elements).

There are a lot of possible extensions to this technique.  A close quote could be created using ::after and placed in the last row of the grid, thanks to the ability to use negative track values to count back from the end of the grid.  Thus:

blockquote::after {
   grid-column: 3;
   grid-row: -1;
   content: "”";
   font-size: 5em;
   font-weight: bold;   
}

That places the close-quote in the third column, so to the right of the quoted text, and in the last row, regardless of how many rows were auto-created.  Of course, there is no third column…or there wasn’t, until assigning something to the third column.  At the point, the browser created it.

The danger there is that the auto-generated column is essentially tacked on to the trailing edge of the grid, without real consideration for what might be in the way—up to and including the edge of the viewport. Rather than auto-generate the column, we could define a third column like so:

grid-template-columns: min-content 1fr min-content;

This sets up a column on each side of the grid, one for each of the big quotes.  The second column, the one that gets all the actual child elements of the blockquote, receives all the space left over after those outer columns are sized, thanks to its 1fr value.

There’s one more drawback here, albeit one that’s easily overcome.  Grid items’ margins do not collapse.  You can see this effect by checking the “Default margins” option in the demo.  That shows what happens if default paragraph margins are allowed to remain.  We end up with two ems of space between the paragraphs, because each has top and bottom margins of 1em.

In the normal flow, margins collapse to the largest of the adjacent margins, which is why we’re used to 1em of space between adjacent paragraphs.  With grid items, what we see instead is the full element box, margins and all, placed inside the grid cell(s) they occupy.  That means any margin will create space between the edge of the grid cell and the border-edge of the element.  The fix here is straightforward: add a style to reduce margins between elements.  For example, something like:

blockquote > * {
   grid-column: 2;
   margin: 0.5em 0;
}

With a half-em margin above and below each element, any two adjacent elements will have the common 1em separation.  The demo actually has less than that because I wanted to use the print convention of paragraphs with the first lines indented, and a minor separation between paragraphs.  So the actual demo styles are more like this:

blockquote > * {
   grid-column: 2;
   margin: 0.125em 0;
   text-indent: 2.5em;
}
blockquote > *:first-child {
   text-indent: 0;
}

So there you have it: a Grid-powered drop quote.  I should note that all this by itself isn’t quite sufficient: if Grid isn’t supported, it will degrade poorly, as you can verify with the “Disable grid” option.

This is where using @supports() to encapsulate the Grid styling comes in handy.  You can put all of the quote-generation styles into the @supports() block, so that downlevel browsers just don’t get the drop quotes; or, you can set up the drop quotes with floats or positioning and then override those with @supports()-protected Grid styles.  Either one works.

Fortunately, we do have that capability, so it’s fairly easy to progressively enhance your designs with little touches like this one, even if you’re not ready for a full-on Grid plunge.  I’m looking forward to deploying this pattern here on meyerweb, as part of a site design overhaul I’ve been working on for the past couple of weeks.  That’s right: I’m working on my first redesign in a dozen years.  If that doesn’t give you some sense of the power of Grid, well, I just don’t know what will.


There is a followup to this article that explains and corrects an oversight in this article.

Not On This Day

Suppose you use Facebook (statistically, odds are at least 1 in 5 that you do).  Further, suppose you have a period of your life, or even more than one, that you’d rather not be mined by Facebook’s “On This Day” feature.  Here’s how to set a blackout for any period(s) of time.

  1. Go to facebook.com/onthisday in a web browser while logged into Facebook.  Said browser can be either desktop or mobile.
  2. In a desktop web browser, click the “Preferences” button in the upper right quadrant of the page, to the right edge of the On This Day masthead.  In a mobile web browser, tap the gear icon in the upper right, then tap “Preferences”.
  3. Select the “Dates” line (on desktop, you have to click the “Edit” link on the right).
  4. Now select the “Select Dates” link that looks like a section heading, but is actually a point of interaction.
  5. Select start and end dates, in that order (see below).  On desktop you can type into the boxes or use the popup calendars; on mobile, you get date wheels.
  6. Select “Done” (desktop) or “Add” (mobile).
  7. If you want to add more date ranges to filter out, go back to the “Select Dates” step again and work forward.
  8. Once you’re done, select “Save”.
  9. To finish setting preferences, select “Done”.

…and that’s it, he said dryly.

Should you want to effectively disable On This Day, you can set up a date range of January 1, 1900 to December 31, 2099.  I couldn’t go past 2099 in my testing—according to the error message, anything from 2100 on is an “invalid date”.  I also discovered that setting a start date will always reset the end date to the new start date, so make sure to set your start date first and your end date second.

You might have seen that you can also filter out specific people.  The process there is similar, except you type names to find accounts to filter out instead of using date pickers.

So that’s it.  The preferences aren’t easy to find, but they are there.  I’d be a lot happier if Facebook let you pick a given date and applied it to all years—thus allowing you to block out the birthday of an ex-spouse, or the wedding anniversary of a now-defunct marriage, for example.  I’d be happier still if they surfaced these preferences more readily; say, prompting you with a date-exclusion option whenever you tell them you don’t want to see a given memory in your timeline.  I don’t mind writing how-to guides to help other people, but I do sometimes mind that their existence feels necessary, if you follow me there.


A note for the future: this guide was accurate as of the date of publication.  If you’re reading it some time later, especially if it’s been several months or years, bear in mind that things may have changed in the meantime.  In that case, please feel free to leave a comment indicating there’s been a change, so I can update the guide.  Thanks!

Gradient Flags

With the news today of the Supreme Court’s decision in Obergefell v. Hodges, and my recent completion of the part of CSS:The Definitive Guide that deals with gradients, I thought I’d create a couple of flags using linear gradients.

First, I’ll define the basic box of the flags.  The dimensions are the same as those specified for the U.S. flag, 1:1.9.  I added a couple of box shadows for visual constrast with the background.

div {height: 10em; width: 19em; margin: 3em;
    box-shadow: 0 0 0.5em rgba(0,0,0,0.25),
        0.4em 0.6em 0.5em rgba(0,0,0,0.25);}

Okay, with that set, first up is what’s often called the pride flag, which is to say the “rainbow flag”.  There’s an interesting history to the design of the flag, but I’m going to stick with “the six-color version popular since 1973”, as Wikipedia puts it.

For such a flag, we just need color stripes with hard stops between them.  That means putting the color stops right up against each other, like so:

div#rainbow {
    background: linear-gradient(180deg,
        red 0%, red 16.7%, 
        orange 16.7%, orange 33.3%,
        yellow 33.3%, yellow 50%, 
        green 50%, green 66.7%, 
        blue 66.7%, blue 83.3%, 
        purple 83.3%, purple 100%);
}

The first red 0% isn’t really necessary, nor is the last purple 100%, but I left them in for the sake of consistency.  You could remove them both in order to make the CSS a little smaller, and still get the same result.  I decided to go from red to purple, as the spectrum is usually described, which meant having the gradient ray point from top to bottom.  Thus 180deg, although to bottom would be completely equal in this case.

Now for the US flag.  In this case, things get a little more interesting.  I’ll note right up front that I’m not going to put in any stars, in order to keep this simple and gradient-focused, and yet it’s still interesting.  We could use a repeating linear gradient, like so:

repeating-linear-gradient(180deg,
    #B22234, #B22234 0.77em, white 0.77em, white 1.54em)

That would then cause each red-white pair of stripes to repeat vertically forever.  Because the specified stripes are manually calculated to be 1/13th of the height of the overall flag (10em), they’ll just fit like they should.

The problem there is that if the overall flag size ever changes, like if the height and weight are converted to pixels, the stripes will get out of sync with the dimensions of the flag.  Fortunately, we don’t have to rely on ems here; we can use percentages.  Thus:

repeating-linear-gradient(180deg,
    #B22234, #B22234 7.7%, white 7.7%, white 15.4%)

Ta-da!  The stripes are the right sizes, and scale with any changes to the height and width of the flag, and repeat as required.

That’s all well and good, but we still need the blue canton (as it’s called).  Since the canton will be on top of the stripes, it actually needs to come first in the comma-separated value list for background-image.  That gives us:

background-image:
    linear-gradient(0deg, #3C3B6E, #3C3B6E),
    repeating-linear-gradient(180deg,
        #B22234, #B22234 7.7%, white 7.7%, white 15.4%);

Wait.  A blue-to-blue gradient?  Well, yes.  I want a consistent blue field, and one way to create that is a gradient that doesn’t actually grade.  It’s a quick way to create a solid-color image that can be sized and positioned however we like.

So, now we size and position the canton.  According to the official design specifications for the flag, the canton is the height of seven stripes, or 53.85% the height of the overall flag, and 40% the width of the flag.  That means a background-size of 40% 53.85%.  The stripes we then have to size at 100% 100%, in order to make sure they cover the entire background area of the flag.  Finally, we position the canton in the top left; the stripes we can position anywhere along the top. so we’ll leave them top left as well.

The final result:

div#usa {
    background-image:
        linear-gradient(0deg, #3C3B6E, #3C3B6E),
        repeating-linear-gradient(180deg,
            #B22234, #B22234 7.7%, white 7.7%, white 15.4%);
    background-size: 40% 53.85%, 100% 100%;
    background-repeat: no-repeat;
    background-position: top left;
}

And if you, like Bryan Fischer, believe that morally speaking “6/26 is our 9/11”, you can move the canton from top left to bottom left in order to invert the flag, which is permitted “as a signal of dire distress in instances of extreme danger to life or property”.

(Of course, it’s a lot easier to do that with background positioning since I didn’t include the stars.  If the stars were there, then we’d have left the canton’s position alone and done a rotateX() transform instead.)

So, there you go: two gradient flags.  You can see both (along with the “distress” variant) on this test page.  If you’ve any desire to use any or all of them, go ahead.  No copyright, trademark, patent, etc., etc. is asserted, implied, etc., etc.  I just wanted to have a little fun with gradients, and thought I’d share.

Touchy About Faucets

As part of last year’s renovation, we redid our kitchen, which means a new sink and faucet.  We traded up from an overmount single-bowl sink to an undermount double-bowl sink, both aspects of which we’d long wanted.

There was one thing we had to fight a bit to get, though, which was a garbage disposal for each sink bowl.  The plumber didn’t want to do it on ground of it adding weight to the sink.  Our response was, in effect: “We’ll have the sink remounted in ten years if necessary, but put in two disposals.”  So he did, and we’re really glad.

The replacement faucet, however, does not make us nearly as glad.  We decided to get a touch-activated faucet, settling on a Delta Addison single-handle faucet.  The touch activation was because many are the times we want to wash off hands that have just handled raw meat, and being able to touch-on the faucet with a forearm seemed like a great idea—and it is!  The problem is that nearly the entire faucet body, including the temperature/flow adjustment handle, is touch-sensitive.  The exception is the pull-out head, which is inert.

Thus, if you reach past the faucet and brush it by mistake, the water starts flowing.  This is true even if you bump the base of the faucet, which is annoying when you’re trying to wipe down the countertop around the faucet.  Even worse, changing the temperature or flow rate means using the touch-sensitive handle.  There’s evidently logic built into the faucet that’s meant to prevent the water from cutting off if you adjust the handle, but it only works about half the time.  So sometimes you make an adjustment and the flow cuts off, and sometimes it doesn’t.

Frankly, the inconsistency is more maddening than the unwanted cutoffs.  For example, I’ve developed an expectation that the flow will cut off after I use the handle.  So I’ll adjust and then immediately tap the faucet again so it cuts off and then comes back on tap.  Except if it didn’t cut off, then my tap cuts it off before I can stop the impulse and then I have to tap again.

Of course, any touch-sensitive faucet is a total luxury, and fortunately it’s easy to disable the touch feature—all we have to do is pull the batteries from the battery pack and it becomes a regular faucet.  The drawback there is that there are definitely times when you want to be able to turn on the water flow without smearing whatever’s all over your hands on the faucet.  (And with three kids, one of which is an infant, there are some things you definitely want to avoid smearing.)

The really incredible part is that these problems would be completely solved if only the neck of the faucet were touch-sensitive.  If the base, which is a separate part from the neck, and the adjustment handle were inert, easily 90% of our frustration would just vanish.  We could start the water flow by touching the neck and not worry about weirdness with the adjustment handle or when brushing the base.

If you’re thinking of installing a touch-sensitive faucet, I can’t recommend this one, unless of course a future version of it fixes the problems plaguing this one.  And I have no idea if there’s a better touch faucet on the market; for all I know, they’re all like this.  Definitely do your homework, and if at all possible play with a functioning model before taking the plunge.  The touch feature doesn’t add a ton to the price of the base faucet, but it’s enough to be annoying when you’re seriously considering disabling it.

From Filaments to Semiconductors

Thanks to last summer’s home renovation project, the new kitchen is lit by six interior flood bulbs.  We were using the diffuse incandescent bulbs our contractors put in, which were nice and warm and soft.  And also, being essentially freebies, not long for this world.  We recently had three burn out within two weeks.

We decided to take the opportunity to switch from incandescents to something far more energy-efficient.  Having used a number of CFLs around the house, I knew I wanted no part of that scene.  The subtle flicker they generate isn’t subtle enough for me, and I hate the wan quality of the light.  I’m not really thrilled with the warm-up time, either.

So we went with LEDs.  This wasn’t as straightforward as I might have liked, but we’ve now switched and are really happy to have done so.  I’d like to share the most important thing we learned in hopes of helping others through the transition.

It’s this:  if you’re going from “warm” incandescents straight to LED, find bulbs that have a color temperature of 2700K.  The first test bulb we bought was 3000K, and the difference was enormous.  By comparison to the incandescents, it was a harsh white.  In a Modernist design setting, like say at the Guggenheim, 3000K is probably a good choice.  In our wood-and-grain center-hall Colonial home, it was all wrong.

So I ran up to Home Depot and picked up a couple of EcoSmart BR30 diffuse floodlight bulbs, which are 2700K.  I put in one as a test, and when we flipped on the lights, I couldn’t see a difference in the light given off by the LED and incandescent bulbs.  The LED gave off a little bit more light than the incandescents around it (more on that in a minute) but the quality of light was essentially the same.  I put in the other test bulb with the same results.  Now we have all six cans fitted with the EcoSmarts, and the kitchen is just as warm as it was before.

One slightly noticeable difference is that there are more lumens bouncing around the kitchen than before, because we had 65W incandescents and the LEDs are equivalent to 75W (they actually consume 14W).  There weren’t any 65W equivalents in the floods, at least when I went looking, so I picked the 75W equivalents.  The new bulbs put out 800 lumens each, whereas the old ones likely shed 650-700 lumens each.  I do notice the difference, but it’s not so extra-bright that it’s bothersome.  That said, if I track down some bright white 2700Ks in the 650-700 lumen range, I may swap out half the kitchen bulbs in a staggered pattern to see how it feels.  Whichever ones I don’t use in the kitchen, I can always reuse in the cans in our basement.

The really noticeable difference is that when you flip the wall switch, it takes half a second for the bulbs to actually light up.  It’s a bit unusual when you switch straight from incandescent, but it’s no worse than the “on time” for most CFLs, and there’s no slow warm-up time for LEDs like you get with CFLs.  Once they’re on, they’re on.  And they don’t hum or flicker they way CFLs are prone to doing.

In closing, I just want to reiterate that color temperature is absolutely crucial, and if you’re coming over from incandescents, you want to be at 2700K.  Beyond that, match up the wattage as best you can, grit your teeth through the purchase price, and bask in the knowledge that your electricity bills will be lower, plus you shouldn’t have to replace the bulb any time in the next decade or even two.  That last part alone nearly makes LEDs worth the up-front cost.

If you have experiences or tips to share with regards to LED bulbs, by all means leave a comment!

Fixing Font Display in Thunderbird 3.1

If you upgraded Thunderbird and discovered that the fonts used to display messages suddenly changed, and worse still, you were unable to get all messages to obey your font display settings, then this post is most likely for you.

Here’s what happened to me: I upgraded to Thunderbird 3.1, and suddenly all my messages were in a font I didn’t recognize or appreciate.  I insist on seeing only the plain text version (technically, the text/plain part) of all my e-mail; and what’s more, that it be displayed in a monospace font.  Courier 13, in my case.

So I made sure “View > Message Body As” was still set to “Plain Text”, which it was.  Then I went into the preferences and messed around for a bit.  Eventually I set every font setting I could in “Preferences… > Display > Formatting > Advanced…” to be Courier and have a size of 13, and also to make sure that “Allow messages to use other fonts” was not checked.  All this was done, and Thunderbird relaunched to make sure the preferences stuck.  They did, and most of my mail was displayed as I intended.  And yet a number of messages, such as those generated by Basecamp, were still displaying in this new, thoroughly unwanted font.

A screenshot showing that all the relevant preferences have been set over top of a mail message which clearly violates the preference settings by displaying the message in a different font and font size.

At first I thought it was happening with any HTML mail, but after viewing source on a bunch of messages (using command-U, same as in any Gecko browser) that didn’t seem to be true.  I Googled about and came across a post on Daniel Glazman’s blog which decried the problem in terms very similar to those I’d have used.  Unfortunately, all the comments on the post told me was that the interloping font is Menlo, that this was a deliberate decision by the Thunderbird team, and that they didn’t seem to understand why anyone might be annoyed as hell to have their font settings changed out from under them with no apparent recourse.  What they didn’t tell me was how to fix the problem.

Eventually, I tweeted a complaint—you know, the way you do—and Bryan Watson got me pointed in the right direction.  Something just told me that if I dug around in the hidden preferences, I’d find what I needed.  So I went to “Preferences… > Advanced > Config Editor…” and searched for “Menlo”.  I got three hits, and it suddenly became clear what was happening:  Menlo was being used for Unicode-based mail.  Further, it would seem, the GUI options in “Preferences… > Display > Formatting” don’t affect the settings for Unicode mail.  For whatever reason.

A screenshot of about:config (a.k.a. the Config Editor) showing the results of a search for the term

So I ran a new search in the Config Editor, this time for “unicode”.  That got me several results, but it also got me what I needed: the settings for both the font face and the font size used to display monospace and “fixed” type in Unicode mail.

Accordingly, I changed three lines in the Config Editor—the ones in the screenshot which are boldfaced and have a “user set” value for the “Status” column—and with that, my mail was displayed the way I wanted it, which is to say the way it had been displayed for years, which is to say the way it would have continued to have been displayed if Thunderbird hadn’t silently changed the settings on me and then refused to honor my reasserted preferences.

The 'about:config' window showing the results of a search for the term 'unicode'.  The three preferences changed are 'font.name-list.monospace.x-unicode', 'font.name.monospace.x-unicode', and 'font.size.fixed.x-unicode'.  There are thirteen other preferences listed along with the three changed, for a total of sixteen.

If you’ve encountered a similar problem, now you can do what I did and hopefully avoid some of the annoyance I experienced in trying to get my mail client to behave properly.

[Update 8 Jul 10: Mook wrote in to point out where this setting is buried in the preferences UI, for those who might want to set it without diving into the Config Editor.  Thanks, Mook!]

I’m also really rather annoyed that Thunderbird can’t seem to remember that I don’t ever want to see the Message Pane, but that’s a reported bug and I only hope that they fix it sooner rather than later.

Translations

December 2017
SMTWTFS
November  
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Archives

Feeds

Extras