Workout with flexbox

I started and completed the Code School flexbox course today, and then started and finished the surprisingly fun Flexbox Froggy exercises to reinforce what I’d just reviewed. It was very helpful to do this combination.

I wrote some Flexbox notes here back in August. Now I’ve got a more complete set of notes (offline) and a new Pen to remind me how to use flexbox the next time I need it.

Leaflet for interactive maps

The latest update I’ve made to a handout for students is Introduction to Leaflet.js. Leaflet is a JavaScript library for creating very flexible interactive maps, using a variety of tile sets — which enables you to make a map that looks quite different from a Google Map. There are lots of options for customization.

The Leaflet Quick Start Guide is good, but it doesn’t walk a beginner through how to enable the use of Mapbox tile sets, even though Leaflet recommends using them. Mapbox changed drastically about a year back, and those changes made it necessary to rewrite my tutorial.

Separately, I have a Leaflet assignment for students in their seventh week of working with JavaScript.

Highcharts for data charts and graphs

I had to update my resource document Getting Started with Highcharts because the library has been updated, and jQuery is no longer required. The document covers:

  • Installation
  • Your First Chart
  • Changing Colors and Styles
  • Setting and Changing Chart Options
  • Licensing and Payments
  • Interactive Demos with jsFiddle
  • Which Chart Type Should I Use?

Separately, I have a Highcharts assignment for students in their third week of learning JavaScript. It includes a GitHub repo.

Accessibility resources

Last night I went to a local developers meetup. Two people spoke about accessibility and shared these tips and links.

Web Content Accessibility Guidelines (WCAG)

These guidelines come from the W3C, and there are three levels of compliance. Level A is the minimum, and level AAA is the highest standard.

How to Meet WCAG 2.0 is the most user-friendly guide (there are several, with various amounts of complexity and details).

Web Content Accessibility Guidelines (WCAG) Overview is much more detailed (and less user friendly).

General tips to make sites accessible

  • Indicate errors (e.g. in a form submission) with icons and/or text — not only with color.
  • Popups and overlays must be able to be closed with a keyboard action, and not require a mouse click.
  • Field labels must be provided as readable text; do not use only the overwritable placeholder text inside a form field.
  • Use focus as well as hover if you have popup information. That is, make it appear on focus as well as on hover.
  • Line-height should be 1.5x (ugh — I prefer 1.4x).
  • Use @media print { } to write CSS specifically for printing — this might help with accessibility for some users (media queries).
  • I always tell students: “Don’t use click here as a link.” A good way to explain why: Make sure the purpose of the link can be determined by the link text alone.

Tools and sites to help you make your pages, apps accessible

Audits in Chrome Developer Tools — this is awesome! Use it to test your pages.

tota11y.js “helps visualize how your site performs with assistive technologies.” It is “a single JavaScript file that inserts a small button in the bottom corner of your document. (It’s on this very page.)” Go there, click the small button, be amazed.

Color Safe — this site generates color palettes! “Empowering designers with beautiful and accessible color palettes based on WCAG Guidelines of text and background contrast ratios.

WAVE, an online website analyzer — open this, paste in a URL, and see what happens. Also mind blowing.

ChromeVox is a free screen reader. Blind people use a screen reader to read the web out loud to them. If you install this Chrome extension, you can hear how a screen reader reads your page.

The A11Y Project: “A community-driven effort to make web accessibility easier.” Nice resources! Just take a look and you’ll see at a quick glance how helpful this can be.

Use an a11y linter — this advice applies especially if you’re using grunt or gulp in your workflow. If not (e.g. you only make small projects), the tools listed above will suffice.

aXe Chrome extension — not sure we need this if using Audits (see above), but it will find accessibility defects on your site.

NOTE: Accessibility is often abbreviated as a11y, where the number 11 refers to the number of letters omitted. It is often pronounced like alley.

ReactJS notes, part 2

Docs for learning React: Hello, World!

Chrome extensions for React:

In the browser, React is faster than plain JavaScript because it relies on JavaScript objects. We never read from the DOM, and we only write to it the things that have changed. After watching several of the videos in React.js Essential Training (, I’m more than ever convinced that few, if any, journalism projects or apps would call for using React.

Local server with Node

Install and start a local server: httpster (note: This requires Node and npm, which were covered here, including how to install them). Tip: cd into the directory containing your files before entering the command to start the server.

thedirectory $ httpster

The default: http://localhost:3333/

With a basic Hello, World app running in my browser, here’s what the React Developer Tools gave me (open the usual Chrome Developer Tools; find React on the far right side or on the drop-down menu):

Image: React Developer Tools

There’s no requirement that you use httpster specifically, but you need to be running some server locally.

Likely you will use Webpack with React, so you can just use webpack-dev-server.


This is when I wanted to scream, but I contained myself: JSX stands for “JavaScript as XML.” Hearing that was enough to make me want to scream, but the clincher was when the video instructor said it allows us to “use tags that look a whole lot like HTML.” Argh! We already have HTML!

Then: “JSX is not natively supported by the browser.” This is why we need Babel (also covered in my earlier post) to transpile the code. It just gets worse and worse.

Project file structure

You’ll need two distinct folders in your project (in addition to node_modules): one for the stuff you actually build, and other for the files that run in the user’s browser. In the first videos I watched, these were named build and app. In this set of videos, they’re named src and dist.

What you name these folders doesn’t really matter — you will define their roles in the webpack.config.js file (assuming you’re using Webpack), but you have to be clear on what the purpose of each one is — so you’re putting your files in the correct place.


In the last video in section 2 (React.js Essential Training), I understood how the loaders work, or rather, how they are set up in the webpack.config.js file. The test property uses a regex string to indicate which file extensions will be governed by the specified loader. Each loader must be installed with npm, and it is specified in the loaders array.

Image: Code for React loaders

In the strings for CSS and SCSS, the slam (!) separates multiple loaders, which will run in the order given, left to right.

Conclusions today

  1. Obviously there’s no point in learning React to build tiny little websites or apps.
  2. Using a Python framework (e.g. Flask) is simpler than this.
  3. I haven’t gotten to the components yet. Maybe when I do, I will feel more friendly toward React.

ReactJS notes, part 1

I’m watching a video series from O’Reilly (also Addison-Wesley, LiveLessons, InformIT, Pearson) called ReactJS Fundamentals, by Charles David Crawford.

Step 1: Install Node. If you’ve installed Homebrew on a Mac, you can install Node with this:

brew install node

Having installed Node, you now have npm, a package manager for JavaScript.

Step 2: Use npm to create a file, package.json, which you can do simply with this command:

npm init

Since you’re just getting started, you can press Return/Enter for each option until you get back to the bare command prompt. Now you have package.json in whatever directory you’re in.

If instead of just hitting Return you wanted to fill in all the options properly, which of course you would do for a real project, here’s a guide. See also this. The package.json file is going to manage all your dependencies for the project, app, site, whatever.

Step 3: Since you’re starting a ReactJS project, you install it like this:

npm install --save react

This created a new file, package-lock.json, and a new folder, node_modules, inside of which is a whole bunch of crap that ReactJS apparently needs. This is why you had to install Node to get npm, etc. — because ReactJS needs all this stuff.

The guy in the video goes through all of this in less than 4 minutes, which is a bit overwhelming if you’ve never used npm or any of this before now.

Important: In a production environment, where you’re committing changes to GitHub, you will commit package.json, but you will add the folder node_modules to your .gitignore file. The package.json file will handle all the dependencies on the server. Therefore, you do NOT want to commit/upload the node_modules folder.

Step 4: Install even more stuff to make it all work.

In the videos, the guy is using Webpack to smush all the JavaScript into one file, so you have only one <script> tag in your HTML. It doesn’t minify the code, though. More about Webpack.

He’s also using Babel, a JavaScript compiler, to convert ES6 for old browsers. He has separate videos explaining these in some detail.

npm install --save-dev webpack -g
npm install --save-dev babel-loader
npm install --save-dev babel-preset-es2016
npm install --save-dev babel-preset-react
npm install --save-dev react-dom

Yeah, I know — it’s a lot. And we haven’t even learned any ReactJS yet.

Step 5: Create webpack.config.js file and write a bunch of things in it.

I’m dying here. The code is not supplied with the library’s link to these video files. At this point I was getting lost because the guy is running code he’s got in the project, but he hasn’t shown us how to write it. I was able to cobble together working code based on a repo I found on GitHub, but I realized at this point I couldn’t continue this course without the code.

In package.json I’ve got (among other code):

"scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "build": "webpack"

So when I enter the following command, Webpack is invoked, and Webpack runs Babel:

npm run build

Babel applies ES6 transformations and React transformations (because webpack.config.js tells it to; it’s not automatic, and we did install the presets for those). Webpack also bundles all JavaScript files into one concatenated file, creating or rewriting bundle.js in the build directory. The directories app and build, as well as the filename bundle.js, are all set up in webpack.config.js.

Step 6: OMG another install:

npm install --save-dev webpack-dev-server

This is when I abandoned the ReactJS Fundamentals videos, because the guy opened a new set of files with a bunch of new code, and lacking those files, I couldn’t run anything.

Force HTTPS in WordPress

I’ve been testing pages and files on various sites of mine to make sure they always use HTTPS (not insecure HTTP).

WordPress sites turn out to have an annoying tendency to ignore the root’s .htaccess file in which you have added code to supposedly force all files and pages to use HTTPS.

The solution is nicely detailed here. The first part — where he edits Settings in WordPress — was already in place for me. The key turned out to be adding two lines to the .htaccess file inside my WordPress directory. He’s got that under the subheading Fix .htaccess to process website assets such as CSS and JavaScript under HTTPS.

If you don’t fix that, a URL to a WordPress post or page pasted into the browser address bar will open insecurely.

NOTE: Do not ignore what he says about your WordPress cache. I had to manually change an http: to https: in the settings for the WP Super Cache CDN. Before I did so, my blog was wrecked and unreadable!

Flexbox notes

Reviewing some flexbox concepts today. Flexbox is really handy for coding things like a row of social icons, as shown in this image:

Image: Social icons in a row

  • “A flex container expands items to fill available free space, or shrinks them to prevent overflow.”
  • “Flexbox layout is good at small-scale layouts, whereas the (emerging) Grid layout is intended for larger-scale layouts.”
  • “Instead of talking about horizontal (inline) and vertical (block), flexible boxes use the terms main axis and cross axis. … The main axis is the axis along which the flex items follow each other. The cross axis is the axis perpendicular to the main axis.” (source)

In today’s browsers (2017), this calls for various prefixes and several lines of CSS to declare the main axis:

-webkit-box-orient: horizontal;
-webkit-box-direction: normal;
-ms-flex-direction: row;
flex-direction: row;

Having supplied those four lines of CSS, you’ve determined that the main axis of the element is horizontal. Following the flexbox standards, you can write simply flex-direction: row; and then (when you’ve written all your CSS) run the file through a formatter (such as Atom’s autoprefixer package) to get all the extra lines added for you.

“By default, flex items will all try to fit onto one line. You can change that and allow the items to wrap as needed” with flex-wrap: wrap; (source). This is important to consider if you have a lot of things in a row (such as the social icons above), and you don’t want them to shrink to little dots on a vertical phone screen — which they will do if you don’t wrap the line. Using wrap will make the icons do this on a phone:

Image: Social icons with flex wrap

Since I don’t use flexbox often, I always have to look this stuff up.


jQuery AJAX cheat sheet

I know the Fetch API is probably going to replace AJAX, and soon.

I also know that learning jQuery is less important now than it has been for a number of years.

However, jQuery Ajax commands are very useful, compact, and still necessary for many APIs. So these ready-to-use code snippets for every day can really come in handy when you just need to get some external data into your HTML quickly and easily.

The snippets cover $.get()$.post()$.load(), $.getJSON, JSON.parse() (which is pure JavaScript), and the all-purpose form tool, $.serialize(). They do not cover $.ajax(), which essentially does everything, but with more lines.

Another post in favor of PWAs

This post — Your Site—Any Site—Should be a PWA — makes the argument in its title and also includes some helpful links.

PWAs don’t require you use a particular JavaScript framework or any JavaScript framework at all. You don’t need to be building a Single Page App either. In fact, it will probably be easier if you’re not.

You do, however, need a service worker.