New Kilogram!

What news! There’s a new kilogram on the block! Le Grande K is being replaced by defining Planck’s constant to \(\Large{h=6.626\ 070\ 15\times10^{-34}{\rm J\ s}}\). The kilogram is hiding in the “J”, the joule, which is a compound unit \(\Large{{\rm kg}\frac{{\rm m}^2}{{\rm s}^2}}\). It isn’t official until May 2019, but it nails down another universal constant!

It’s perhaps less exciting, but just as important, that other constants are also being defined. The highlighted rows are the new definitions:

\(\Large{\Delta v_{\rm Cs}}\) \(\Large{9\ 192\ 631\ 770{\rm Hz}}\)
\(\Large{c}\) \(\Large{299\ 792\ 458\frac{\rm m}{\rm s}}\)
\(\Large{h}\) \(\Large{6.626\ 070\ 15\times10^{-34}{\rm J\ s}}\)
\(\Large{e}\) \(\Large{1.602\ 176\ 634\times10^{-19}{\rm C}}\)
\(\Large{k}\) \(\Large{1.380\ 649\times10^{-23}\frac{\rm J}{\rm K}}\)
\(\Large{N_A}\) \(\Large{6.022\ 140\ 76\times10^{23}\frac{1}{\rm mol}}\)
\(\Large{K_{cd}}\) \(\Large{683\frac{\rm lm}{\rm W}}\)

This allows the definition of the seven SI units to universal constants.

Unit Definition
second (s) \(\Large{\frac{1}{\Delta\nu_{Cs}}}\)
meter (m) \(\Large{\frac{c}{\Delta\nu_{Cs}}}\)
kilogram (kg) \(\Large{\frac{c^2}{h\cdot\Delta\nu_{Cs}}}\)
ampere (A) \(\Large{\frac{1}{e\cdot\Delta\nu_{Cs}}}\)
kelvin (K) \(\Large{\frac{k}{h\Delta\nu_{Cs}}}\)
mole (mol) \(\Large{N_A}\)
candela (cd) \(\Large{\frac{1}{h\cdot\Delta\nu_{Cs}^2\cdot K_{cd}}}\)

The compound units used in the definitions of the constants are a shorthand.

Another aspect that is not getting much press is the downside of defining the kilogram and Avogadro’s number: 1 mole of 12C no longer has an exact mass of 0.012 kg. Now the mass of 12C is \(\Large{0.0120000000(45)\frac{kg}{mol}}\). Perhaps in the future these definitions can be reintegrated. Technically, they are still related by \(\Large{N_A=\frac{\alpha^2M({\rm e}^-)c}{2R_\infty h}}\), but we aren’t exactly certain about the values of \(\Large{\alpha}\), \(\Large{M({\rm e}}\), or \(\Large{R_\infty}\), so there’s still work to be done! Avogadro’s number may not move, but we may figure out these guys yet!

While these changes are official, they don’t become “the definition” until 20 May 2019, so you’ve still got some time to adjust your voltmeter by 0.00001% or so.

A tous les temps, à tous les peuples.


Web presentation is balled up in Cascading Style Sheets (CSS), but there are additional tools that may be useful to those starting out, or re-learning the art of web development.

There are several critics of CSS preprocessors, and they have their points, but I’ll probably continue to use them. Here are the big ones, their pros and cons, and some options if you wish to write in plain CSS.

All of the below have some things in common:

  • Variables
  • Conditionals
  • Nesting
  • Plugins/Mixins
  • Inheritance
  • Functions
  • Math
  • A vanilla CSS file will pass nearly unaltered through any of these.

CSS Crush

CSS Crush, for the most part, is vanilla CSS with automatic generation of vendor prefixes.


Stylus modifies the syntax by eliminating the need for braces and semicolons. You can include them if you like, but they are optional.


Less, through less.js, allows its use in the browser without running it through a preproccessor, though for production this is discouraged.


Sass comes with two syntaxes, making it perhaps more flexible for writing than the others, provided you utilize the appropriate extension in your file. SCSS uses CSS syntax, and Sass eliminates the braces and semicolons.

So why would you pick any of these? They primarily add a step to deployment of your web page, and that’s about it, right?

It used to be that none of the features mentioned had much, if any, support within the CSS spec or browsers. CSS3, and most browsers, support CSS variables now. Conditionals for their primary use-case exist via @supports and @media. Math is also well-supported with calc, unless you’re trying to do something really fancy (and you can even mix units and percentages, which can’t be done with a preprocessor!).

It should be noted, especially in relation to CSS Crush, that Android, Chrome, iOS, Firefox for iOS, Safari, and newer versions of Opera all use the “-webkit-” browser prefix (Chrome, since v28, uses the Blink rendering engine, but this is a fork of WebKit). Desktop versions of Firefox still use “-moz-“. Internet Explorer and Microsoft Edge still use “-ms-“. But common practice now is for browser makers to hide these experimental features behind user-controlled flags/preferences which can help fast-track their production implementation in ridiculous version release schedules (every six weeks for Chrome and Opera, six-to-eight for Firefox. WebKit prefixes can still be useful, as many, if not most, of these eventually get standardized. So basically, if you use any browser prefix at all, “-webkit-” will allow you to cover between 67% and 73% of the desktop market and 94% to nearly 100% of the mobile market.

Variables in vanilla CSS require five extra characters to reference, and typing “var()” might seem tedious to you.

:root {
  --primary-color: #4042c8; /* pretend this is carefully chosen rather than totally random */

.colorful > p {
  color: var(--primary-color);

Nesting is perhaps not the most elegant, solution, and is arguably less maintainable, than specificity or defining classes for everything.

Lastly, while vanilla CSS files may come out of preprocessors relatively unscathed, those that use features of them may produce CSS files that are somewhat larger than expected.


You’ve probably heard of JavaScript. You may have heard of TypeScript, ECMAScript, JScript, VBScript, LiveScript, CoffeeScript, and ActionScript, and might wonder what any of them have to do with each other, or with Java (as a beverage, island, or computer language).

Essentially, JavaScript and Java appeared at roughly the same time, in 1995, had similar syntax, and JavaScript followed Java’s naming conventions, but that’s pretty much it. It’s possible, perhaps even probable, that JavaScript took its name to capitalize on the popularity of the nascent Java.

Mocha was the development codename of the language, LiveScript was its name when in beta, but it was renamed JavaScript when announced in December 1995 and released with Netscape Navigator 2.0.

TypeScript is a superset of JavaScript developed by Microsoft in 2012. Any valid JavaScript code is valid TypeScript code, but not every valid TypeScript code is valid JavaScript code. Typescript compiles to plain JavaScript.

CoffeeScript is an alternate syntax for JavaScript designed to be more readable. It compiles to plain JavaScript.

ECMAScript is the specification created to standardize JavaScript. The committee that develops these standards is Technical Committee 39 (TC39) of Ecma International, standardized in ECMA-262 and ISO/IEC 16262. While originally the European Computer manufacturer’s Association, the name of the Switzerland-based organization is no longer considered an acronym, but the specification retains it for historical reasons. The name is a compromise between the organizations involved: Sun Microsystems, Netscape, and Microsoft. Since 2015, there have been annual releases of ECMAScript syntax.

As an aside, here are a few other Ecma International standards you probably know but didn’t know who came up with them:

  • 7-bit coded character set
  • FAT12/FAT16 file system
  • CD-ROM volume and filestructure
  • Universal Disk Format
  • C# language specification
  • Eiffel language specification
  • Office Open XML
  • JSON
  • Dart language specification

As ECMAScript is a specification, JavaScript is a subset of ECMAScript. JScript and ActionScript are also subsets. JScript was created for Microsoft’s Active Scripting engine, so it can be used with Internet Explorer, Active Server Pages, and Windows Script Host, along with VBScript (Visual Basic Script) and PerlScript. It is essentially the same as JavaScript with a few additions specific to Microsoft, but a different name was chosen to avoid trademark disputes with Sun Microsystems. ActionScript was created by Macromedia for use with their Flash product and lives on today in Adobe AIR.

Due to the editor-level debugging available through the use of TypeScript, I plan to use it and its enforced typing in tutorials here.

CSS (Step 2: Flexbox)

With the basics and terminology out of the way, we come to layout. I barely touched it last time—all we had was some articles and boring old vertical scroll. Yeah, we did some fancy things, but nothing groundbreaking, or even that interesting.

Today, we’re going to tackle flexbox. Like all of these, this isn’t going to be a comprehensive tutorial, but if you’re reading this, it’s probably at least as new to you as it is to me.

First off, you might be happy to know that flexbox can make vertical centering not only possible, but simple! And it’s not the only solution on that front, but we’ll get there eventually.

You want columns? Easy peasy! You want them to resize proportionally depending on the viewport? No problem! You want them to stay the same size regardless? Still simple! Reorder those columns depending on viewport or media or because it’s Tuesday? Done. You want a different number of columns depending on viewport? Do you want to make sure the space between the columns is even regardless of the column’s size, or make sure the center of the columns are evenly spaced, or there’s an even amount of space between the columns? Do you want to vertically stretch columns so you don’t have a ragged bottom? Would you prefer them all with the same centerline? How about a ragged top and aligned at the bottom? Swap out columns and rows in the above and you’re still set, all with one new tool in your box!

This probably sounds too good to be true, but I promise, it works. It’s not the be-all, end-all for layout, and this won’t cover some designs, but it’s pretty…flexible (I think when writing about flexbox that joke is compulsory)! And you might wonder about browser support, or be worried about a zillion polyfills cluttering your code. Fret not! All real browsers support it, and have for years. IE 11 technically supports it, but it’s buggy.

This time we’re going to change things up. Instead of a blog-like page, let’s build a user testimonials page for a business, Spacely’s Space Sprockets. How, exactly, are they better than Cogswell’s Cogs?

We have to put our testimonial blocks in a container, first, and set that container to display:flex. But if we leave it like that, all the nested divs end up in one horizontal line. Sometimes that’s appropriate, but not typically, and not here.

Now we get on to the magic.

flex-direction tells the browser how to order the boxes. Still in the “container” class of the CSS, play around with the following:


row will have no (additional) effect, because that’s the default once you have the container set to display:flex. row-reverse might confuse you a bit—it does reverse the order of the contained images, but it does this by stacking them from right to left in your viewport. Your browser may not recognize that you may need to scroll left to see some of the nested elements. column will be what you saw before adding display:flex, and column-reverse will be a similar column, but with the opposite order.

What we really want is to wrap these testimonial blocks. flex-wrap to the rescue!


If you add flex-wrap:wrap, you expect that the boxes will stack up nicely next to each other–but they don’t! The divs appear to have been resized horizontally, but are still stacked in a column. flex-direction won’t help here, because they are, technically, in a row, but wrapped as if each box was a word in a paragraph of text (which by default automatically wraps). If you have a wide enough viewport, or you zoom out, you may be able to get them to line up side-by-side, but we need a solution for this, because instead of fixing the problem, we created a new one!

Before we move on, you can combine the above attributes with the shorthand property flex-flow, e.g. flex-flow row-reverse wrap;.

We can ameliorate the issue by defining a specific width to the item, and that’s what we’ll do for now. Since I chose 300px wide images, let’s set the item (.testimonial) width to 300px.

Take note of how wrap-reverse and row-reverse/column-reverse differ. With wrap-reverse, you keep stacking images from right to left but, in the case of a row, when you get to the end (left), you shift the entire row down and begin a new row on top (instead of moving your stacking down a row.

Notice, since I have 11 testimonials, regardless of your viewport (okay, so long as the boxes line up side-by-side and it actually does wrap, i.e. the width is greater than 600px but less than 3300px), the boxes won’t fill up the entire width. What if we want to avoid that annoying whitespace? Add flex:1; to the testimonials class and notice that, however many items are in a row, they will stretch horizontally to fit. Taft, for instance, has more to say than some of the others, so lets give him some more room. Add

.taft { flex: 2; }

These numbers are proportions, so they do not have units. His testimonial won’t necessarily take up twice as much room as the others. Because his flex-grow property is twice as big as the others, the container will do its best to make his item’s width twice as wide, but may not succeed.

I’m introducing the shorthand property right up front here, because that’s probably what you’ll use most. What we’ve specified above is the flex-grow property, but that also implicitly sets the flex-basis to 0. There’s also a flex-shrink property. That really only works without wrapping, and is essentially the inverse of flex-grow, shrinking items proportionally (as available) to attempt to fit in the viewport. Feel free to turn off wrapping, remove the images, and play around with it, but I won’t include examples here. The default for that is 1, however. Anyway, let’s add a flex-basis of auto to the .testimonials class:

.testimonials {
  flex: 1 1 auto;

What happened? Taft’s impressive girth has gone away! His flex-basis, as I said, was implicitly set to 0, so what does that mean? It takes a look at the item’s width property (300px), ignores the whitespace, and uses that as its default size before distributing/flexing the item within the container. What the auto keyword does is takes a look at the item’s width property, then takes all the white space, and distributes that among the items proportionally.

Update the .taft class to flex: 2 1 auto;. Now the whitespace width he gets allocated is twice as big as the whitespace width allocated to the other .testimonials, or as close as your browser can get. If you want him to take up all the space, or as much as possible, without messing up the stretchiness of the bottom/wrapped row(s), set the flex-grow property (the first number) to something absurdly large, like 9999. This basically replicates what we had before we included flex-basis.

What if, instead of stretching the boxes, we wanted to put spacing between them? Take out the flex line in the testimonial, and in the container, add justify-content:space-evenly;. The extra whitespace on each line is split and placed in each gap. If there are four items in a row, and 240px of whitespace at the end, this will put 48px before the first item, 48px between the first and second, etc., and 48px after the last item in that row.

justify-content has some other keywords that can be used:

justify-content:flex-start; //this is the default
justify-content:flex-end; //lines up things at the end (right or bottom of most containers)
justify-content:center; //sounds promising...

space-between would take that theoretical 240px of whitespace on the end of a four-item line and place 80px between each item, but no whitespace before the first or after the last.

space-around takes that whitespace and divides it into 8 chunks, 24px each, and puts it before and after each item. Which means there ends up being twice as much whitespace between items as there is before the first or after the last.

All of these can be quite useful in certain contexts. For this one, space-between and space-evenly probably look the best.

And if you want to put all the whitespace after a specific element, add


(or margin-left, or margin-top, or margin-bottom, whichever is relevant).

We’re not done yet! Notice that, for each row, the testimonial blocks stretch vertically to perhaps an absurd degree, based on whichever item has the most content. Another property, align-items, is here to help.

align-items: flex-start;
align-items: flex-end;
align-items: center;
align-items: baseline;
align-items: stretch; //default

Go ahead and play with these (in the container); some are more self-explanatory than others. Baseline is, perhaps, the confusing one. It will align all items with the baseline of the first nested element, which, in the example, is the images. This is why Bill Murray and the kitten have different image heights in the example. Play around some more by moving some text above the image, and watch how the result aligns. The bottom (baseline) of the first line of text is the line that’s used for alignment.

How about changing the alignment of just one item? The align-items property may be tempting, but it’s for use in a container. align-self is the one to use here. Add to your CSS file

.seagal { align-self:flex-end; }

and watch what happens. The same properties are available for these as with align-items, with the addition of auto, which is the default, and inherits the align-items property of its parent.

Almost finished. Order is something else that can be changed with flexbox using, oddly enough, the order property.

Say we want to move the zombie to the front. One way is to update the HTML to movie his testimonial up. Another way, if this were a data-driven site, would be to update the query such that the brain-eater was returned first. Or, you can do it using CSS.

Add this to the CSS file:

.zombie { order:-1; }

The default value of the order property is 0, so you’d either have to specify everything else with a higher number, or give the particular class a negative number. Either solution is fine.

One major caveat to using the order property: if a speech reader is being used, for example, this will not change the order content is aurally presented. But in a semantic layout, the content should be presented first if no stylesheet is used, thus, for instance, a navigation bar can be coded last in the HTML yet be presented first in a visual medium.

Try to use what you’ve learned to place text of one of the testimonials above the image. Hint: it involves the order property, the flex-flow property, and the display property.

How about the problem we started with? Perfectly centering an item, horizontally and vertically? Add the following:

.center-container {
.centered {

The highlighted lines are all that’s necessary; the width and height ensure we have a sufficiently large container to demonstrate the concept, and the .centered class adds some styling to the bit of graffiti.

Before I wrap this up, I’m going to address responsive images. I’ll cover them more comprehensively later, but we sometimes will want our images to take up the space they’ve been given  in case, for example, we want them to shrink to make room for Taft.

.testimonial img {

You’ll also probably want to add a min-width property to the testimonial class so that the images/items don’t shrink too much. Or a max-width if you don’t want Taft to get too big.

Resources & References


A quick aside to define some terminology you may run across while browsing CSS Tricks, MDN, A List Apart, and other web-focused sites (I may have even used a couple myself):

polyfill: a “shim” for a browser. A method to emulate future features (like CSS drop caps) on browsers that don’t yet support them, usually using JavaScript.

fallback: if code, images, fonts, or other resources aren’t loaded yet, what you might expect to see on your web page. Sometimes also used for accessibility, things like placeholder text for images.

media query: discovering characteristics of the user environment, and conditionally applying styles based on those characteristics. Width of the viewport is probably the most common, followed by “screen” and “print” to define different styles for a printed page than a display. See here for more.

viewport: the window through which a user is viewing your site. This could be a on a 43″ 4K monitor (like the one I typically use), a 4.7″ 1344×750 iPhone display, or an old CGA dinosaur, but the window, typically the browser, can (typically) be resized further. Out of habit, my browser is often set to a window size of 2560×2120 (40px taken by my OS taskbar), but my viewport size, thanks to the window chrome, is 2550×2000.

responsive: this one means what it says on the tin, but it can help to define it in the context of web design. A design is responsive when, depending on, or regardless of, the viewport size, it looks appropriate. This could involve moving a navigation section to the bottom of a page or collapsing it into a hamburger menu at the top when the viewport is narrower than a certain size, loading higher resolution images for displays that can handle them, and/or being flexible to portrait and landscape viewing modes.

specificity: this one I left for last, because I want to talk about it. Specificity, in CSS, has a very technical meaning. Generically, however, it means how targeted your selector is. Are you targeting an element, a class, an ID? Are you using a pseudo-selector? Are you using “!important” (by the way, don’t do that)? Are you specifying styles inline (by the way, don’t do that either)?

Specificity can be calculated as follows:

a=number of ID selectors

b=number of class selectors, attribute selectors, and pseudo-class selectors

c=number of type selectors and pseudo-element selectors

The specificity is a||b||c, where “||” is the concatenation operator, and the number system has an effectively) infinite base.

h1#test {
  //specificity of 101: an id and a type
h1.test, h2.test {
  //specificity of 11: each one is a class and a type
  //because it's lower, h1 will be red and h2 will be blue.
h1, h2, h3 {
  //specificity of 1: each one is a type
  //because it's lower, the h1 will be red, h2 will be blue, and h3 will be green.
h1[id=test], h2[id=test] {
  //specificity of 11: each one has an attribute selector, even though it is an ID, and a type
  //the specificity of the first selector wins, so an h1 with an ID of test would be red; but there's nothing specifying just #test, so h2 with that ID would be yellow. But you're not allowed to have two IDs that are the same in a single document, so don't do that! If the h2 had an ID of test and a class of test, it would still be yellow, since this is the last definition with that specificity in the CSS file.

If you want the dirty details, go here. If you want something a bit more user-friendly, go here.

CSS (Step 1: Basics)

Now that we’ve got content out of the way (I know, I know, content is hard, and pulling it out of clients—or even your own brain—can be even harder), it’s time to make your website look good. We’ll consider a semi-standard blog type site, with posts as excerpts from classic works of fiction. Don’t worry about where the content comes from, or how to pull it from a database or any fancy stuff yet—we’ll get there.

Again, I won’t be covering the details of syntax, rather, I’ll be giving an overview of design elements and how to use them such that you won’t be too surprised at the results. Also, I’ll cover popular designs and how to implement them.

Step one implements some basics, but it’s kind of a hack job. Let’s see how to make it better, and better looking.

Notice that the gradient fill, from a whitish to a blue tint, gets darker as you scroll the page. It might look better if we could fix it, so that the text would scroll but the background would be stable.

Notice that, while the header stays fixed, its background is matched to the original white color. And the footer is matched to the original bluish color, but doesn’t extend all the way to the edges of the browser window.

I used the newish details element to display/hide the author’s name and publication date, but it automatically inserts the word “Details” and a glyph for showing and hiding the info—we can do better.

Let’s make a complete list of what we’ll update:

  • Stable gradient fill background
  • Retain gradient fill for header, but keep it sticky
  • Fade text into header when scrolling
  • Modify “details” element styling
  • Floating “back-to-top” button
  • Sticky chapter titles
  • Simpler, or more flexible, or at least easier to comprehend, drop-cap styling (or raised-cap, or block cap)
  • Use of relative units instead of pixels

The first bit–the fixed gradient–turns out to be easy to fix! Just add

background-attachment: fixed;

But the header looks more out of place with a solid background. The reason it’s solid in the first place is that, without setting a background for the header (comment out that line and try it yourself), the text scrolls right through the header and it looks even worse. What if we copy the body styling for the background image? Turns out, this works fairly well, but now we have a new problem, or at least something we can probably improve upon: the text just disappears as you scroll, a sharp line across the screen.

This, as you might guess, requires a bit more work. Also in the header, add this:

-webkit-mask-image: linear-gradient(rgba(0,0,0,1) 125px,transparent);
mask-image: linear-gradient(rgba(0,0,0,1) 125px,transparent);

This one still requires a prefix in Chrome, at least. What these lines do is add a mask: black at the top down to 125 pixels, fading to transparent. But as it is a mask, the black acts as a filter to block content underneath from showing, save the content to which the mask has been applied, which, in this case, is the original gradient background.

The “Details” element. Could use a bit more flair, I think! First, we add a “summary” tag inside to change the text “Details” to whatever we want—in this case, “Story Info” is as good as anything.

For the rest, we’re going to make things simple. Ish. Instead of the “twisty”—the turning triangle that indicates whether the details element is open or closed—we’ll use a plus and a minus sign, bold, and in red. In Firefox that’s fairly simple, but Chrome makes things a tad difficult.

details > summary {

details > summary::-webkit-details-marker {
  display: none;

summary:before {

details[open] summary:before {
  content: '-';

Highlighting the important bits here, the list style after the details > summary selector is the standards-compliant way of removing the twisty; the pseudo-element -webkit-details-marker is for Chrome. The rest should be fairly self-explanatory: placement of the content within the summary element and its size, and what to show when the element is in its open state. For our example, I also threw a border around it and added some basic styling to the book title, author, and publication date.

How about a “back to top” button? The link href is fairly well-established: "#", but how do we place an element so you can click on it no matter how far down (or up) the page you’ve scrolled? Can it even be done with just CSS?

The answer to that is usually, “Of course!” But, again, as usual, if you want to do slightly fancier things, you have to use JavaScript. We’ll stick to the CSS for now. And this can be done (almost) entirely in CSS, too! Add this code:

#toTop {
#toTop:hover {

The highlighted lines are the important ones. Everything else is looks. We want it to be in the same position, thus “fixed” there, and we want it on top of anything else we put on the page, so a z-index of 99 should do the trick. If you’ve got more layers, maybe tack on another 9 or two.

Nothing will show up until you add an appropriately id’d div in the html also:

<a href="#"><div id="toTop">Top</div></a>

You can put the anchor inside or outside—in this case I prefer outside so I can click anywhere on the element to take me to the top.

You’ve probably seen it before and wondered, “how can I do that”? Every time you scroll to a new article, the title stays at the top, until a new one comes into view. As usual, this is something you can do with only CSS!

article > h3 {
  position: sticky;

At this point, I’ll leave it as an exercise to the reader to handle the fading and text overlapping. There are a few solutions, and the neatest is probably to make the chapter title/heading a full-width banner, and to handle the fading below that. This article also shows off some other cool things you can do with position: sticky.

Nearing the end! Drop caps are a bit of a tricky thing in CSS. You might be tempted to throw in just

article p:first-of-type:first-letter {
  float: left;
  font-size: 5em;

and call it a day, but if you pay attention (and this will vary by font), the letter isn’t aligned with the top of the paragraph, and it looks a bit tacky.


won’t do the trick either, unless you throw in an extra element before the paragraph for the first letter (it should work inside, but it’s not doing what I expect, at least on CodePen). Honestly, for now the best you can do here is experiment. I added


and got what I was looking for.

In the far-flung future, people will be able to use


to achieve roughly the same result.

If you want to be ready for that, use CSS feature queries!

@supports (initial-letter:1) or (-webkit-initial-letter:1) {
  article p:first-of-type:first-letter {

The main reason I’m so insistent on styling with :first-letter (contrary to the advice given in this article) is because I do have visually impaired friends and relatives. While I’m fairly certain these individuals use a computer minimally, if at all, I’m sensitive to the ease of use for them. I do intend to make one of these articles focused specifically on accessibility, but for now, take the exhortation to use semantic elements as much as possible, and ensure your site is usable sans any styling.

The last thing I’m going to cover in this “basics” article is length units. Despite the fact that I used pixels throughout my stylesheet, it’s kind of bad form. With “retina” displays and different browser interpretations, a pixel isn’t always a pixel anymore. Also, with modern CSS, we have a lot more units available to us! The first 7 of the long list below are the ones to avoid, especially when defining font sizes. Some of them are more reliable than others. Nobody supports “cap”, “ic”, “ih”, “vb”, or “vi” yet; support for “Q” is spotty, and support for “vmin” and “vmax” is inconsistent. Even so, you have a lot of options!

  • px (pixel, often, but not always, defined as 1/96in)
  • in (inch)
  • cm (centimeter)
  • mm (millimeter)
  • Q (1/4mm)
  • pc (pica, defined 12pt)
  • pt (point, defined as 1/72in)
  • em (calculated font size of the element)
  • ex (ideally the height of lowercase (Latin) letters in the current font, often equal to 0.5em)
  • cap (cap height of the current font)
  • ch (advance measure of “0” in the current font)
  • ic (advance measure of “水” in the current font)
  • lh (calculated line height of the current font)
  • rem (calculated font size of the root element, <html>)
  • rlh (calculated line height of the root element, <html>)
  • vh (1% of the viewport height)
  • vw (1% of the viewport width)
  • vi (1% of the initial containing block in the direction of the inline axis)
  • vb (1% of the initial containing block in the direction of the block axis)
  • vmin (smaller of vh and vw)
  • vmax (larger of vh and vw)
  • % (percentage)

HTML Basics (First Steps)

HTML is (typically) what browsers interpret to display web pages. I’m not going to cover syntax in (many of) these documents, the purpose is to give a sense of structure. Also, don’t get peeved if I play a bit fast and loose with the terminology. If you want to know the deets, check out

While HTML used to contain presentational markup like font and center tags, those are gone. b, i, hr, s, small, and u have been redefined “to be media-independent.” People realized that not everyone has access to two working eyes, and screen readers may have difficulty figuring out what, on some cluttered page, might be important.

Thus, HTML is now almost entirely semantic The style attribute and style element exist, but should be considered developer tools rather than production tools.

When writing a new, modern, compliant HTML document, one thing to keep in mind is that it should be usable without any styles beyond the browser’s defaults. Heck, take a look at it using lynx or some other text-based browser. Is it still understandable? Does the most important content still jump out at you? If it’s buried under menus and polls and input boxes and RSS feeds, you might want to move some things around.

If you worked with DTDs “back in the day,” you might recall starting all your HTML documents with something like


This helped during the big browser wars on whether or not to use “quirks mode” to render a page. Now that things have settled down and we’re left with little browser skirmishes instead, HTML 5 simplified things to just

<!DOCTYPE html>

For a little bit of historical context,  browsers used to use the DTD to validate HTML as a subset of SGML. Browsers don’t implement HTML as SGML, though, so who needs a DTD?

There are rules specifying whether or not some elements are required, whether the start or end element can be omitted, but for sanity’s sake, just use them.

Things that are encouraged:

  • Include a “lang” attribute in the HTML element (see here, here, and here for more information)
  • Include a meta element to define character encoding (this tag must be closed within the first 1024 bytes of the beginning of the file)
  • Include a meta element defining viewport, but do not restrict users from the ability to zoom! (The latter part is just bad form, but I’ll explain the why for the first part in the next article)

Thus, your minimal document should look a bit like this:

<!doctype html>
<html lang="en-US">
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width,initial-scale=1.0">
    <title>Document Title</title>

There are lots of other things you might want to add to your document header. Make it look good on Google, have a shortcut icon when people bookmark your page, including open graph data for Facebook, titles for Twitter, and more. I might touch on them later, but if you’re interested, they might be worth a look.

Sins of My Youth

This will be the last post for a while (I think) that won’t have a song title as the post title. The focus of the blog hasn’t changed, but it’s tough to find anything.

I’m going through a journey now. Whether that leads me out of my current career into another one, into entrepreneurship, or staying put with a side gig, I don’t know yet, but I’m not going to go it alone. I may begin by shouting into the void, but I hope someone, someday, takes the journey with me.

Just a preview of what’s to come:

I’m an “old timer” of sorts when it comes to web development. I started with HTML 3.2, Netscape Navigator was king, <blink> and <marquee> were all the rage. I’m sure there are some who have me beat by several years yet. But college and work pushed most of that to the side, and I haven’t done much in the past 18 years. I fiddled with the odd website here and there, even designed and managed a few, but anyone hiring for a web dev job wants experience in technologies that I’ve only heard of in passing.

This is my journey of reinventing myself. Of learning the arcane arts of Node, Angular, React, Typescript, etc. Of perhaps, someday, combining my enjoyment of mathematical beauty, machine learning, the internet, and food into something amazing.

Supposedly Bruce Lee said “Notice that the stiffest tree is most easily cracked while the bamboo survives by bending with the wind.”

It’s time to adapt. To move from “old and busted” to the “new hotness”, (without sacrificing utility for popularity—maybe “old and busted” has an anti-gravity button and an Elvis 8-track up his sleeve). Everyone might say that their paradigm or framework or package manager is the best, but they probably all have strengths and weaknesses. Let’s find out what they are together, and maybe make the world a better place!

Алфавит мы уже знаем

Þe Olde Alphabet

We used to have a bunch of other cool letters, and, of course, thorn (Þþ) was one of them. I didn’t know before today that the “Y” in “Ye Olde ____” was from the abbreviation, “þe“. It was also used in a couple of other nifty abbreviations: “þt” for “that” and “þs” for “this”. We even had an entire letter for “that”: ꝥ.

The ampersand “&” used to be considered a letter unto itself, much like “ꝥ”. While it has (generally) retained its meaning (used to, more correctly, mean “and per se and”; elision converted it to “ampersand”).

I personally think a decent case can be made to make the apostrophe a letter. It can be used to distinguish “its”, “it’s”, “your”, “you’re”, “there” and “their” vs “they’re”. There are rules governing its use which are widely applicable, but they still fail sometimes, and if it was used as a letter, it might be better.

We also have (had) eth (Ðð) for use as the unvoiced dental fricative (the soft “th”).

There are the complicated rules governing the use of the long s: “ſ”, which only has a lowercase form, and is only used if it’s either the only “s” in a word and that “s” is not at the end of the word, or if it’s the first “s” in a word with two (or more?) “s”s.

There’s wynn (Ƿƿ) which is much cooler than “uu”, or as is now more commonly written, “w”, for…well, the sound that “w” makes.

The semi-pretentious ath (ニæ) and ethel (Œœ), and, while the first is supposed to denote a sound “somewhere between ‘A’ and ‘E'” (like, well, æ in the IPA) the second has many sounds (like ɛ, e, i, or iː in the IPA).

Then there’s yogh (Ȝȝ) which probably went away because of how much it looks like the number 3. Or is that a Ȝ… can you even tell? Maybe the font gives it away, but still. This could have been used for things like Baȝ, or Loȝ Ness, or in German or Klingon transcription… The demise of this letter, which has been replaced with “gh”, may explain why many of the “gh” combos in English are now silent.

And eng (Ŋŋ, not the right half of the original Siamese twins) which a guy named “Alexander Gill the Elder” (we know the name of a guy who made up a letter!) created to replace the combination “ng”. Sometimes it was written as ⅁ or g̶, or as G with a descender.


There are now tons of meal kit delivery services out there: Blue Apron, Green Chef, Hello Fresh, Plated, Munchery, Terra’s Kitchen, Fresh Direct, Peach Dish, Chef’d, Takeout Kit, Purple Carrot, and probably more, but despite the variety on offer, few of their menu items are appetizing to me.

A selection from this week’s menu: Khao Soi Burmese Curry Noodles? Rainbow quinoa with pickled red beets and crispy bay-spiced sole? Corn and summer squash risotto with basil and gruyere cheese? Wild swordfish with chimichurri, butternut squash and roasted vegetables? Coconut jasmine rice with fried plantains and corn pico de gallo? Sheet pan-roasted chicken with lemon-arugula potato salad? Beef and eggplant stir-fry with roasted shishito peppers? Soba noodles with snow peas and marinated enoki mushrooms? Chickpea-powered Mediterranean couscous with zucchini and heirloom grape tomatoes?

Some (apparently quite a few) people find this type of variety perfect for their lifestyle. I prefer simple: Meatloaf. Sloppy joe’s. Mac & cheese. Pepperoni pizza. There’s no “with quinoa and arugula tahini and açai zucchini sauce” or any of that nonsense. There’s rarely a “with” involved at all, save perhaps a bit of salt and pepper to taste. Now, I also might be willing to go a bit more adventurous on a few things, like the lemon-herb salmon with Greek feta rice, but—problem—this serves two. I highly doubt I could get my wife to eat it. She’s quite satisfied with a grilled cheese sandwich, or even peanut butter and jelly, with a handful of potato chips and a bottle of water.

My life may be getting a bit more complicated. As of this writing I am…let’s just say overweight, but willing to do something about it. Going to a restaurant where the average item is 1200 calories for the entree (with unlimited french fries) certainly doesn’t help matters, even if it is an occasional thing. My wife is wont to box half of it up and eat it the next day. I’ll eat it all. If I were to box it up, it would be in the refrigerator for 1–3 weeks before winding up in the trash anyway.

What I’d love to see is a meal delivery service that caters to people who are, perhaps, less adventurous, with more of a pick-and-choose ideal, along with recipes for one. I’d be more willing and able to expand my palate if my wife can stick with a can of soup. And make the ingredients such that they’ll survive an extra day or two in the fridge, or so that they can be frozen (with appropriate defrosting instructions) because life happens, and schedules change at the last minute. Some people might think a particular dish sounds great, if they just left out the mushrooms. No opting out as it stands, they go in the trash can when they arrive. How about options for the true novice, who wants to practice in the kitchen. They’re in the “how to boil water” category, not the “stir-fry the chicken with the quinoa and shallots” (“What’s quinoa?” “What’s a shallot?” How do I stir-fry something?” “How do I know when it’s done?”) category. Some people have a rice cooker and garlic press, most probably don’t. Some people have an oven, some only have a crock-pot, or even just a hot-plate and/or microwave. These people are left out.

And another thing! These meal kit delivery services, even though most have their own gimmicks, pretty much all go “wild-caught”, “GMO-free”, “certified organic”, “no antibiotics ever” with their ingredients. I call BS. Stuff your “wild-caught” and go for sustainable. Fuck that “GMO-free” and use what’s reasonable. Those promoting “certified organic” are certifiable. While I agree that antibiotics shouldn’t be misused with livestock, “no antibiotics ever” mean that if any animal gets sick, it may as well be killed and left to rot (away from the herd) because it’s of no use to the farmer. If it can be returned to health with appropriate use of antibiotics, put it back with the herd, no problems.