Chris Coyier on PostCSS:

We know that specs change. It hap­pens all the time. Seems weird to base a syn­tax on a non-final spec. What hap­pens when the spec changes? Do you change the lan­guage and let exist­ing code break? How is that future-proof? Or sup­port all past for­mats? Mean­ing the lan­guage isn’t really based on future CSS, it’s based on any exper­i­men­tal idea that was considered?

These have been exactly my thoughts since hear­ing about CSS post-processors. How can peo­ple hon­estly believe that the code they’re writ­ing is future-proof? Sass source files cer­tainly are prone to “spec rot”, but the CSS they gen­er­ate isn’t (at least, inso­far as any­thing can be immune to it).

On writ­ing real CSS (again) | CSS-Tricks

One Response · May 28, 2015

My cur­rent devel­op­ment setup revolves mainly around Vim and GNU Screen. I use Screen only to keep ses­sions run­ning between work days or in case I get dis­con­nected, but lately I’ve been tempted to try using dif­fer­ent win­dows inside Screen. In order to make this eas­ier, I wanted one of those sta­tus lines that shows you all your win­dows as “tabs”.

Con­fig­ur­ing this sta­tus line (the “hard­ware sta­tus line” or, as I’ll call it, “hard­sta­tus”) is done with a sin­gle, often long string of char­ac­ters in ~/.screenrc that at first can look entirely baffling:

hardstatus string "%{= KW} %H [%`] %{= Kw}|%{-} %-Lw%{= bW}%n%f %t%{-}%+Lw %=%C%a %Y-%M-%d"

Exactly.

To my dis­may, almost every­thing I can find about hard­sta­tus through Google are just dumps of other people’s strings, with lit­tle to no expla­na­tion about why they do what they do – it’s easy to imag­ine that the peo­ple who post them hardly know why they do what they do, either. GNU’s offi­cial doc­u­men­ta­tion isn’t ter­ri­bly helpful.

After finally deci­pher­ing a lot of what goes on in these strings, I wanted to spell it out to any­body else who might be hunt­ing around for half a clue about this voodoo. There are (more than?) a few things I haven’t cov­ered here, of course – trun­ca­tion and con­di­tion­als, namely – but this should be enough to get you started.

Con­tinue reading →

Hav­ing just stum­bled across an arti­cle advo­cat­ing against AdBlock Plus (via Lea Verou), I decided to revisit my set­tings for rel­a­tively nuisance-free brows­ing in Firefox.

For a long time I’ve done devel­op­ment work and writ­ing for a site that keeps its lights on through adver­tis­ing, so I sym­pa­thize with content-creators’ need for (and frus­tra­tion with) ads. It’s a nec­es­sary evil, and I’ve always found it a bit dis­heart­en­ing to see AdBlock Plus at the top of every “Pop­u­lar Plu­g­ins” list (whether for Chrome, Fire­fox, or Safari). Worse, there seems to be a sense of enti­tle­ment among savvy inter­net users, telling them that they shouldn’t have to endure ads. Com­monly this might be veiled as being “anti-corporate” or some other such vague excuse, but the real rea­sons are usu­ally the same as those behind piracy: it’s just nice not to have to pay for things, whether through eye­balls, band­width, or dollars.

(None of this is to say that I am entirely inno­cent on these points.)

Still, there are some trou­bling com­mon prac­tices among the more insid­i­ous of these JavaScript embeds, and I think there is some jus­ti­fi­ca­tion in cir­cum­vent­ing them. But one doesn’t need to block every adver­tise­ment to severely dimin­ish adver­tis­ers’ abil­ity to, say, keep track of one’s brows­ing habits.

Here are the things you can do to make your brows­ing a lit­tle more pri­vate and safe, while still (mostly) allow­ing the sites you love to pay their bills. These tips will be writ­ten for Fire­fox users (though the equiv­a­lent plu­g­ins are read­ily avail­able in Chrome and Safari), and won’t include things that read­ers of this site will prob­a­bly already know about (e.g., avoid­ing “watch movies free” sites and their ilk, and dis­abling pop-ups).

Con­tinue reading →

I don’t claim to be any kind of Apple pun­dit, but I have some hunches about what their watch will be like if and when they release one.

The two fac­tors I see as being vital are price and simplicity.

Price

The Galaxy Gear starts at $299, which is a lot more, I think, than the aver­age per­son (i.e., non-Android zealots) are will­ing to spend on a watch that they have to charge every night. A suc­cess­ful watch, one that gets into the hands of mil­lions of peo­ple, will have to be closer to the “Apple impulse buy” price of the iPods Nano — at most $249, but I think they could do it for $199. (The Peb­ble E Ink watch is $150.) To reach that price point, an Apple watch will lack, for instance, a cam­era and a speaker, which are included in the Galaxy Gear.

Con­tinue reading →

Despite not agree­ing with all of it, “Just Use Sub­lime Text” (an invec­tive against Vim — or, more accu­rately, against rec­om­mend­ing Vim to any­one who isn’t already indoc­tri­nated by it) by Andrew Ray is an inter­est­ing read. The sec­tion deal­ing with indent­ing in par­tic­u­lar struck a chord with me:

Paste this into an empty buffer:

<div>
<p>
<span>foo</span>
</p>
</div>

:set ft=html and then gg=G. Let me know what you get. In all seri­ous­ness, never, ever tell me what you get.

As I said in a tweet, what I got didn’t offend me too much. But many peo­ple would argue that the <span> tag should be indented inside the <p> tag. I’d prob­a­bly do this myself, actu­ally — and there have been aspects of Vim’s indent­ing that irk me. So I set about find­ing a solution.

Con­tinue reading →

First of all, it’s terrific.

I was sur­prised to find that the front­light can never be turned com­pletely off while the Kin­dle is awake.

Also regard­ing the front­light, I’m pleas­antly sur­prised that, when it’s set at a mod­est level in a dimly-lit room, it has the appear­ance of not being lit at all, but merely of being more “white” than it is and as a result reflect­ing more ambi­ent light, almost mag­i­cally so. I didn’t expect to want to leave the light on all the time, but for this rea­son, I do.

When set too high, or when in a too-dark room, there is an appear­ance of uneven­ness with the light­ing, but it’s not ter­ri­bly distracting.

What is a bit dis­tract­ing is how sur­real it can look when some­thing (like your thumb or head) is cast­ing a shadow on the sur­face in cer­tain light­ing; the area around the shadow looks mostly illu­mi­nated by the ambi­ent light, and the area under the shadow has an odd blue glow to it, since the frontlight’s effect is more appar­ent there.

Hav­ing fonts other than Cae­cilia is nice, although I can’t imag­ine any­body want­ing to read for any length of time in Futura or Hel­vetica. Baskerville is of course clas­sic for type­set­ting books, but because of its del­i­cate let­ter­forms and small x-height doesn’t really suit the (rel­a­tively) low-contrast and (rel­a­tively) low-resolution Kin­dle. There doesn’t seem to be an ideal “small” font size for Baskerville, at least not for my eyes. For these rea­sons I’ve so far stuck with Palatino, a font that I don’t really like very much, but which is less “artificial”-feeling than Cae­cilia, anyway.

The new UI ele­ments (and the font in which they’re set, some Futura-like geo­met­ric I can’t iden­tify) are really attrac­tive. You can tell a lot of time was spent here and it gives the device a lot more per­son­al­ity and finish.

As expected, I’m frus­trated by the lack of a hard­ware page-turn but­ton, par­tic­u­larly while read­ing in bed, where (with the face of the Kin­dle pointed slightly down­ward) my thumb becomes a cru­cial sup­port point, and is there­fore not free to tap the screen to turn pages. In other inter­ac­tions I’m also forced to use two hands quite a bit.

It was worth the upgrade even if only for the front­light, and despite its small and few draw­backs, the over­all improve­ment (over the Kin­dle 3, I should men­tion) make it a no-brainer.

One day while watch­ing Arrested Devel­op­ment, I noticed some­thing: The theme song is strik­ingly sim­i­lar to the Pac-Man theme.

I had to slow the Pac-Man theme down a bit to match these up, but otherwise:

Arrested Devel­op­ment / Pac-Man


Update: More at CelineThe­Fe­line

I began notic­ing recently that some­times when try­ing to send a file to the trash, I was told that it couldn’t be moved there and that I’d have to delete it entirely to get rid of it. I didn’t really think any­thing of this at first, until I began to sus­pect that it was only hap­pen­ing with files in my /home directory.

My /home direc­tory is on its own par­ti­tion on a stan­dard hard disk. The rest of the file sys­tem is on another par­ti­tion on an SSD. In order to fully reap the speed ben­e­fits of an SSD, I sym­bol­i­cally linked as many non-personal direc­to­ries as I could from /home to /var/jay on the SSD. These included ~/.local, ~/.cache, ~/.gconf, ~/.mozilla, etc.

I didn’t really know much about the way Linux/GNOME han­dles Trash. Files deleted from a third inter­nal hard disk or from USB sticks would be moved to /.Trash-1000 on that device, while appear­ing in “Trash” in Nau­tilus. Files from a user’s home direc­tory, how­ever, don’t go to /home/.Trash-1000, or even /.Trash-1000 — instead, they go to ~/.local/share/Trash. Because in my setup this direc­tory was on the SSD rather than the hard disk with the /home par­ti­tion, GNOME refused to move it there, since that would require copy­ing from one disk to another, which GNOME’s devel­op­ers (smartly, I think) believe would be alarm­ingly time-consuming for some­one who’s just try­ing to delete some files — they shouldn’t expect to see a copy dia­log grind­ing away.

In order to try to fix this, I made ~/.local/share/Trash into a sym­bolic link itself, back to the /home par­ti­tion at ~/Trash. After this change, things were get­ting trashed prop­erly — at least, I wasn’t asked to delete them entirely — but they weren’t show­ing up in Nautilus’s Trash view. I don’t know how Nau­tilus makes itself aware of all the trash fold­ers spread across dif­fer­ent devices, but for what­ever rea­son it wasn’t pick­ing up on this one, even after sev­eral reboot cycles.

Finally I gave up and moved ~/.local back onto the same par­ti­tion as /home, and now everything’s back to nor­mal. But I’d still like to know if it’s pos­si­ble to keep ~/.local on a sep­a­rate disk while retain­ing GNOME’s and Nautilus’s ordi­nary trash behavior.