Posts from June 2018

I keep seeing authors and speakers refer to the ch unit as meaning “character width”.  This leads to claims that you can “make your content column 60 characters wide for maximum readability” or “size images to be a certain number of characters!”

Well… yes and no.  Specifically, yes if you’re using fixed-width fonts.  Otherwise, mostly no.

This is because, despite what the letters ch might imply, ch units are not “character” units.  They are defined as:

Equal to the used advance measure of the “0” (ZERO, U+0030) glyph found in the font used to render it. (The advance measure of a glyph is its advance width or height, whichever is in the inline axis of the element.)

So however wide the “0” character is in a given typeface, that’s the measure of one ch.  In monospace (fixed-width) fonts, where all characters are the same width, 1ch equals one character.  In proportional (variable-width) fonts, any given character could be wider or narrower than the “0” character.

To illustrate this, here are a few example elements which are set to be exactly 20ch wide, and also contain exactly 20 characters.

Courier

Look, 20 characters. abcdefghijklmnopqrst 12345678901234567890 iiiiiiiiiiiiiiiiiiii mmmmmmmmmmmmmmmmmmmm

Helvetica

Look, 20 characters. abcdefghijklmnopqrst 12345678901234567890 iiiiiiiiiiiiiiiiiiii mmmmmmmmmmmmmmmmmmmm

Georgia

Look, 20 characters. abcdefghijklmnopqrst 12345678901234567890 iiiiiiiiiiiiiiiiiiii mmmmmmmmmmmmmmmmmmmm

It’s probably no surprise that in Courier, all the elements are the exact same width as their text contents.  In Helvetica, by contrast, this is mostly not the case except for numbers, which appear to be fixed-width.  In Georgia, by contrast, none of the text contents fit the boxes, not even the numbers.

What I’ve found through random experimentation is that in proportional typefaces, 1ch is usually wider than the average character width, usually by around 20-30%.  But there are at least a few typefaces where the zero symbol is skinny with respect to the other letterforms; in such a case, 1ch is narrower than the average character width.  Trajan Pro is one example I found where the zero was a bit narrower than the average, but I’m sure there are others. Conversely, I’m sure there are typefaces with Big Fat Zeroes, in which case the difference between ch and the average character width could be around 50%.

So in general, if you want an 80-character column width and you’re going to use ch to size it, aim for about 60ch, unless you’re specifically working with a typeface that has a skinny zero.  And if you’re working with multiple typefaces, say one for headlines and another for body copy, be careful about setting ch measures and thinking they’ll be equivalent between the two fonts.  The odds are very, very high they won’t be.

It would be interesting to see the Working Group take up the idea of average character width as a unit of measure — say, 1acw or possibly just 1cw — which actually uses all the letterforms in a typeface to calculate an average value.  That would get a lot closer to “make your columns 60 characters wide!” in a lot more cases than ch does now.

• What is the CSS ‘ch’ Unit? was published on Thursday, June 28th, 2018.
• It was assigned to the CSS and Guide categories.
• There have been eighteen replies.

In another timeline, an early alarm woke Kat and me this morning so we could sneak into Rebecca’s room with her siblings and wish her a happy birthday at the moment she turned ten, 7:24am, June 7th, 2018.

Two digits.  It’s a big milestone, in its way.  Rebecca’s best friend Ruth passed it a few days ago.  Ruth, who she called “Ruthie”.  Who shared all three of her initials, and practically had the same birthday.  Who was the last person to whom Rebecca ever spoke a complete sentence in her full voice, the morning of the day before she died: “Goodbye Ruthie, I love you, MWAH!”

Ruth, who still dreams of Rebecca, happy dreams that make her waking sad.

I have dreams like that too, when I remember them.  I don’t often remember my dreams.  But sometimes, I get to spend a little time with her, free of sorrow, on a nighttime walk or at an amusement park my subconscious constructed out of all the parks we ever took her to.

Kat and Carolyn and Joshua and I went to the grave marker this morning, because Kat works all afternoon into the evening and Joshua has an all-day LEGO and chess camp and Carolyn has friends to see before summer vacation gets crazy.  Because life moves on even when a part of you can’t understand why the sky doesn’t collapse and the world doesn’t crack open and time doesn’t shatter into a million sharded memories.  Classes get taken, grades get graduated, camps get attended, trips get planned, work has to be done.  Each day follows on the one before, pulling you further and further away from the last moments your life was normal.

We stood or sat or huddled around the flecked slate blue granite slab under the gray clouds of morning, emotions flaring and fading, subsumed by a profound sorrow without many tears.  We’re too used to it, now.  The sobs of previous years have given way to a steeled mourning.  Sometimes there is resentment at the stupid blind unfairness of the holes shot through all our hearts, the hole in our lives, and all the things she and we never got to experience.

Her playgroup friends still talk of her with their parents.  Rebecca was a good friend, she was funny, she was fun, she was so nice.  In their way, still trying to come to grips with what happened to her.  To them.

They don’t mention her to us.  Children, trying to protect the grown-ups.

Which makes sense, since they know, now, that sometimes grown-ups can’t protect the children.  Sometimes the killer gets into the house and there is nothing you can do to cast it out.

Sometimes there is nothing anyone can do, except hold the victim’s hand as her life ebbs away, and wish your desperate pleas to take her place had been heard.  That there was something to hear, anything to hear, and accept a frantic parent’s bargain of life for life.

Ten years ago today, Rebecca came into this world.  Four years ago today, she left it.

I can’t remember if I ever told her I would never forget her, or if I was too afraid of frightening her.

I clearly remember when and where she told me, sobbing, knowing she would die, that she would never forget me.

I can still recall the terrified strength in her arms, locked around my neck.

I hope I told her then.

Today she should have been ten.

• Decimated was published on Thursday, June 7th, 2018.
• It was assigned to the Personal and Rebecca categories.
• There have been fourteen replies.

A few years back, I wrote a short post on specificity, element proximity, and the negation pseudo-class.  Everything in it is still accurate and relevant, but I have some updates to share.

First off, I’d like to clarify something that some people may have found confusing.  In that post, I said:

But it turns out that the negation pseudo-class isn’t counted as a pseudo-class.

That might leave some people with the idea that the entire negation portion of the selector is ignored for the purposes of specificity, especially if you don’t speak spec.

So consider the following:

div:not(.one) p

In order from left to right, that’s an element selector (div), a negation pesudo-class (:not) a class selector (.one), and another element selection (p).  Two element selectors and one class selector are counted towards the specificity, yielding a total of 0,0,1,2.  That’s the same specificity as div.one p, though the two selectors select very different things.

In Ye Olden Days, that was easy enough to work out, because :not() could only ever contain a simple selector.  Things are looking to get more complicated, however — :not() is set to accept grouped selectors.  So we will at some point be able to say:

div:not(.one, .two, #navbar) p

So any p element that is not descended from a div that has a class containing either one or two (or both), or that has an id of navbar, will be selected.

But how do we calculate the specificity of that whole selector?  Just add up all the pieces?  No.  The Working Group recently decided that the specificity contributed from inside a :not() will be equal to the single selector with the highest specificity.  So given div:not(.one, .two, #navbar) p, the #navbar will contribute 0,1,0,0 to the overall specificity of the selector, yielding a total of 0,1,0,2.  The specificities of .one and .two are ignored.

This same approach will be taken with the :has() and :matches() pseudo-classes.  Thus we get the following:

:matches(nav, header, footer#pageend) a[href] {color: silver;}  /* 0,1,1,2 */
article:has(a.external, a img)  /* 0,0,1,2 */
input:not([type="radio"], [type="checkbox"])  /* 0,0,1,1 */

In the first instance, the bits that are added together are footer#pageend and a[href], so that’s one ID, one attribute, and two elements.  In the second, it’s article and a.external for one class and two elements.  And last, we add up input and either of the [type=""] attribute selectors, since their specificities are equal, which means we add up one attribute and one element.

There is still, so far as I’m aware, no concept of DOM-tree proximity in CSS.  I would still continue to wager that will remain true, though I’d put a fair bit less money down now than I would have six years ago.

• Specificity in :not(), :has(), and :matches() was published on Tuesday, June 5th, 2018.
• It was assigned to the CSS category.
• There have been six replies.