#chrome posts — Ben Crowder

A short followup to what I wrote last year about Press, my abandoned typesetting engine project: I’m...

Ben Crowder — Mon, 14 Nov 2022 12:00:00 GMT

A short followup to what I wrote last year about Press, my abandoned typesetting engine project: I’m now fully convinced that the web platform is where I want to do typesetting. It’s open, programmatic, and capable. Source files are plain text, easy to version control, and fairly future-proof. And even though it’s not WYSIWYG — at least not the way I’m using it — it’s much more comfortable for me as a working environment.

For non-book work (charts, some kinds of documents), I’ve found that browsers already support everything I need (like @page). That’s how I’ve done all my recent genealogy design work, and it’s how I’ll do any language charts I make going forward. And for things like books where browser support isn’t quite there yet, Paged.js works well (and will presumably be phased out once browser support gets better).

Not to mention how nice it is for both print and digital workflows (EPUB, web) to all use the same technologies. I also love that the web is cross-platform. Something I ran into when I was making charts with PlotDevice (which is Mac-only) was that people on Windows couldn’t modify the charts even when I gave them the source. That’s not a problem with the web.

I’ve even started using the web platform for less webby things like making wallpaper for my phone:

Here’s the HTML (the 375×812px size is the CSS resolution of my iPhone 12 Mini — RIP — and also keep in mind that this was for a one-off never to see the light of day, so I took the liberty of cutting a few corners):




  
  


  
    

    
  

  Come unto me, all ye that labour and are heavy laden, and I will give you rest.

  Matthew 11:28

The CSS (with the font purchased from FontShop):

* {
  box-sizing: border-box;
  font-family: Clifford Pro;
}

html {
  height: 100%;
}

body {
  color: #777;
  font-size: 1.6rem;
  margin: 0;
  text-align: center;
}

.background {
  background: radial-gradient(circle at 50% 90%, #222, #111);
  bottom: 0;
  left: 0;
  position: absolute;
  right: 0;
  top: 0;
  z-index: -1;
}

.background svg#darknoise {
  bottom: 0;
  filter: saturate(0);
  left: 0;
  mix-blend-mode: multiply;
  opacity: 0.9;
  position: absolute;
  right: 0;
  top: 0;
}

.background svg#lightnoise {
  bottom: 0;
  filter: saturate(0);
  left: 0;
  mix-blend-mode: soft-light;
  opacity: 0.4;
  position: absolute;
  right: 0;
  top: 0;
}

.quote {
  line-height: 1.4;
  margin: 25rem 1.5rem 0;
}

.reference {
  color: hsl(0 40% 32%);
  font-size: 1.3rem;
  font-style: italic;
  margin-top: 1rem;
}

I then used headless Chrome to export the PNG (Firefox would probably have worked as well, though I haven’t yet tested it for this):

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --headless --disable-gpu --screenshot --window-size=375x812 index.html

It’s not the world’s most amazing wallpaper or anything, but I’m still pleased that I was able to make something I’m reasonably happy with using technologies I love. (I could have also used WebGL shaders or Canvas. Lots of options!)

Here’s to the open web.

Reply via email

Downside of Firefox, courtesy of Google: Gmail’s performance in Firefox is abysmal. Not only is it d...

Ben Crowder — Tue, 02 Oct 2018 12:00:00 GMT

Downside of Firefox, courtesy of Google: Gmail’s performance in Firefox is abysmal. Not only is it deathly slow, but buttons and keyboard shortcuts don’t register most of the time, and things are wonky across the board. (For example, deleting emails doesn’t actually delete them half the time.)

I’m leaning toward using Chrome just for Gmail (and perhaps other Google products as well).

Reply via email

Switched from Chrome to Firefox yesterday. (I don’t really trust Google anymore and figured it was f...

Ben Crowder — Tue, 25 Sep 2018 12:00:00 GMT

Switched from Chrome to Firefox yesterday. (I don’t really trust Google anymore and figured it was finally time to make the move.) Other perks: multi-account containers, theming via userChrome.css, supporting Rust. Happy so far, though it’s admittedly only been a day.

Reply via email

Slow localhost in Chrome

Ben Crowder — Wed, 24 Oct 2012 12:00:00 GMT

For a while now I’ve been doing most of my web coding locally on my laptop, creating virtual .local hosts in Apache (like unbindery.local) and aliasing them to localhost in /etc/hosts. That was all well and good, but in Chrome there would always be a two or three second delay when first hitting a page on one of these local vhosts. Subsequent page views would be fast, but if I waited more than a minute or two, it would be slow again.

I finally googled around and just found that the problem is the .local — it’s used by Bonjour on the Mac, causing conflicts that Chrome doesn’t quite know how to resolve quickly. (Safari does, though.)

So, all you have to do is change the name of the vhost to something else — from unbindery.local to unbindery.dev, for example. Works like a charm, and my goodness, I can’t believe I waited this long to fix it.

Update: Turns out this is also the reason my terminal tabs would take two or three seconds to come up. It’s really fast now. Alleluia.

Reply via email