Josh On Design

This is part of my series on the humanist programming language I’m building called (currently) HL. Read the rest here.

For years I’ve had this idea of a programming language (really a programming system) designed not for building software, but for exploring ideas. If built, it would be a system where you can easily access data both locally and remotely, process the data in many different ways, and use built in tools to visualize the answers. The current way we code just isn’t very amenable to exploring and thinking (outside of an Emacs Lisp buffer).

I’m happy to finally release a Javascript library I wrote at least four years ago. (I say ‘at least’ because the last commit was 4 years ago, but I don’t remember when or where I wrote the original code it came from). Presenting the parser from TallyCat!

If you havn't seen the news, 25% of Mozilla was laid off this week, including me, so I'm looking for a new job managing an engineering or developer relations team.

Every now and then I trumble around with building visual editors. Sometimes they are for vector graphics, sometimes raster. Sometimes for building GUIs, sometimes for editing JSON structures. These editors are almost always for fun and they never see the light of day. Why build a new editor when the world already has so many. Or at least that's what I tell myself.

At this point I’ve been working on the browser for over a month and I’ve learned a ton about Rust. Sadly, it’s time for me to stop. I’ve taken it about as far as I can.

Rendering. The big payoff. This is where we actually get to see something drawn to the screen. This is where the mini-browser starts to feel real. It’s also where the code is straight forward and the hard part is picking the library.

Now we get to the big dramatic part of building a browser. Layout. Until now we’ve just had a tree of data. This is the part where we position actual rectangles and colors and text blocks. The part where we do line wrapping and worry about font sizes. This is the real deal! Let’s dive in.

Styling in a browser is conceptually very simple. We’ve parsed the DOM into a tree structure of elements. We’ve parsed the CSS into a tree structure of rules.

I have greatly enjoyed the reliability of Rust so far, but a few things really annoy / mystify me. One is the type annotations. I understand that type annotations lets you say what type another type is defined in terms of. The common case is a vector of points, with something like:

I had hoped to be talking more about how to build a browser, but reality has intervened. It’s taken about a week, but the family is starting to calm down now and get used to the new normal of staying home. I’ve stocked up on supplies and prepped for exclusively working from home. Jesse is recovered from pink-eye and a cold, and we’ve scrubbed the house clean. Now all we can do is wait and try to help others as best we can.

In the last part I talked about my motivations for building a new web browser / rendering engine in Rust. Today I'll tackle how I parse HTML and CSS.

I have done something very foolish. I've started building a new web browser. From scratch. Not a new wrapper around Chromium or WebKit or Gecko. No, an actual new browser. Why have I done such a thing?!

In my side gig as a science fiction writer I'm trying to suss out the modern market. I grew up reading golden age sci-fi authors like Asimov and Heinlein. The are less than relevant today. When I was a kid YA (Young Adult) scifi/fantasy wasn't really a genre. Now it's dominated by modern blockbusters like Harry Potter and Divergent. So, if I'm to understand the modern market I should actually read some of this stuff. So that's why I read the first Hunger Games novel. Spoiler alert, I didn't like it but I do get it.

thoughts on build systems

I'm rebuilding my HTML Canvas Deep Dive book so I need a way to compile various source files into a final thing. I'm not producing an executable but rather a directory full of generated HTML, CSS, and Javascript, and possibly some other stuff; but it's the same basic idea. I need to turn a collection of things into another collection of things. I need a build system. So which should I use?

I'm optimistic about humanity's abillity to deal with climate change. I know that sounds ridiculous in the current political environment of the US, where one party can't agree on what to do and the other party denies that the problem even exists. But still I'm optimistic. Why? Because of the bomb.

When you think of a book you probably think of prose. A bunch of paragraphs with section headers and chapter names, and perhaps a few illustrations. In short, you are thinking of a paper book. When I first wrote the HTML Canvas Deep Dive I was thinking along those lines as well, but I also wanted interactivity. What’s the point of having an educational book on the web if we can’t push the envelope a bit.

Some years ago I wrote a book called the HTML Canvas Deep Dive. To be truthful the writing was an accident. I taught a workshop four years in a row at OSCON, back when it was in Portland. Whenever I teach a workshop I want the students to have something to take away with them in case they don't finished, so I structure it as a series of lessons with hands on activities. Eventually I realized that if I simply called these chapters instead of lessons then I'd have a book on my hands. So that became the first release of HTML Canvas Deep Dive.

I'm happy to announce that as of today there is no Google on my website. In fact, there is nothing loaded from any other domains than my own. No fonts, no images, and absolutely no trackers. Here's how I did it.

I had the great pleasure to meet lots of dedicated engineers, researchers, and scientists at the W3C Immersive Web Working Group face to face meeting this week. This is the team dedicated to creating standards for mixed reality so that we can all enjoy future interactive content from the web-browser of our choice.