Jeremy Keith on getting started

Jeremy Keith writes:

I got an email recently from a young person looking to get into web development. They wanted to know what languages they should start with, whether they should a Mac or a Windows PC, and what some places to learn from.

I’ve gotten the question myself on more than one occasion; how should I get into front end development? Besides my recommendation of starting out with HTML, then moving on to CSS and lastly get into JavaScript, I often had to dig deep to find good sources for people to read that would help and inspire them. Thanks to Jeremy, that job has been done for me. From now on, I’ll link to his post.

I would like to add that Jeremy’s own excellent book “Resilient Web Design” should be part of the curriculum. Best of all is that it’s available for free online.

Thanks, Keith!

Tags in JSON Feed

It seems I just can’t stop tinkering with my site. I was doing some optimizing of my deploy scripts (which now runs via Docker, because why the hell not), when I out of the blue re-read the JSON Feed spec and saw that there was an optional support for tags.

From the JSON Feed spec:

tags (optional, array of strings) can have any plain text values you want. Tags tend to be just one word, but they may be anything. Note: they are not the equivalent of Twitter hashtags. Some blogging systems and other feed formats call these categories.

An array in JSON is pretty much just this:

[ "item-1", "item-2", "item-3" ]

In context, according to the spec, each item in the items array would need the following (assuming our post has the tags “css” and “html”):

"tags": [
  "css",
  "html"
]

Getting things done in Jekyll

So this whole exercise revolves around you putting an array of tags in your front matter for each post. I’m pretty much assuming that this is something that you’ve already done, but just in case, here’s a sample post:

---
title: My blog post
tags:
  - css
  - html
---

Some thoughtful content…

Considering my previous post about getting JSON Feed in Jekyll, here’s the additional Liquid we need to get these tags in the JSON Feed code:

{% if post.tags %}
"tags": [
{% for tag in post.tags %}
  "{{ tag }}"{% if forloop.last == false %},{% endif %}
{% endfor %}
],
{% endif %}

Since JSON is picky with trailing commas, we need to utilize foorlop.last in order to keep tabs on whether we’re at the last item in the loop or not. Also note the trailing comma after the last bracket on the sixth row. Depending on where you put this snippet in your JSON Feed template, you may or may not need it.

Putting it all together

Here’s the full code for my own feed.json template, complete with the new section for tags.

---
layout: null
sitemap:
  priority: 0.7
  changefreq: weekly
---
{
  "version" : "https://jsonfeed.org/version/1",
  "title" : "{{ site.title }}",
  "home_page_url" : "{{ site.url }}",
  "feed_url" : "{{ "/feed.json" | absolute_url }}",
  "author" : {
    "url" : "{{ site.url }}",
    "name" : "{{ site.author }}"
  },
  "icon" : "{{ "/apple-touch-icon.png" | absolute_url }}",
  "favicon" : "{{ "/favicon-32x32.png" | absolute_url }}",
  "items" : [
  {% for post in site.posts %}
    {
      "title" : {{ post.title | jsonify }},
      "date_published" : "{{ post.date | date_to_xmlschema }}",
      {% if post.updated %}
      "date_modified": "{{ post.updated | date_to_xmlschema }}",
      {% else %}
      "date_modified": "{{ post.date | date_to_xmlschema }}",
      {% endif %}
      "id" : "{{ post.url | absolute_url }}",
      "url" : "{{ post.url | absolute_url }}",
      "author" : {
        "name" : "{{ site.author }}"
      },
      "summary": {{ post.description | jsonify }},
      {% if post.tags %}
      "tags": [
      {% for tag in post.tags %}
        "{{ tag }}"{% if forloop.last == false %},{% endif %}
      {% endfor %}
      ],
      {% endif %}
      "content_text": {{ post.content | strip_html | strip_newlines | jsonify }},
      "content_html": {{ post.content | strip_newlines | jsonify }}
    }{% if forloop.last == false %},{% endif %}
  {% endfor %}
  ]
}

There we go! We now have tags from each post in our JSON Feed.

Improved feeds

I get the feeling that things are happening when it comes to syndicated feeds online. A few years back, JSON Feed entered the scene, courtesy of Brent Simmons and Manton Reece. This summer, the very same Brent Simmons released version 5 of NetNewsWire, a free and open source, pure-Mac application, that’s a joy to use. While light on features on its initial release, it’s snappy and stable. Even better, Brent made the decision to at least support one feed service on day one. As luck would have it, he chose the very excellent Feedbin, a service that I’ve happily been paying for since day one of its release after the demise of Google Reader.

Anyway. After years of questionable alternatives to syndicated feeds (like Facebook, Twitter and whatever else people say they use instead), I’ve kept using RSS and Atom like a stubborn mule. Most sites worth its salt support syndicated feeds in some form, which allows users to easily consume content.

There’s of course the occasional fly in the ointment. And what’s worse, I myself am guilty of it. I’m talking about only providing a short summary in the feed in order to drive traffic to the site itself. Well, no more. As of today, I’ve run a deploy that provides full content both via JSON Feed and Atom for this site. The reasons were quite simple:

  • I don’t actually need to drive traffic to my site since I’m not doing any kind of advertising
  • You as a reader have the option of consuming the content any way you like

The counter point, as mentioned by someone online, is that this makes it easier for less than honest people to “steal” content and publish it as their own somewhere else. My position on this is that these people very likely would do so anyway, and it’s not a strong enough argument against not making things easier for everyone else.

And so, here we are.

Improving the fixed/sticky bookmarklet

Last week I wrote about a bookmarklet I found online. I found that there was some room for improvement since the bookmarklet didn’t handle the more modern variant of position: sticky;.

While using my new and (sort of) improved bookmarklet, I noticed that on some sites, annoying overlays not only covered the content, but also disabled scrolling of the entire page. So if you were to remove all elements that were either fixed or sticky, you still couldn’t scroll the page. Normally, I would often reach for the built-in reader mode of Safari to get to the content. However, this might not always be possible or applicable, depending on the site’s content.

Most sites disable scrolling by simply setting overflow: hidden; on the <body>. So all we have to do is look for this property and then unset it.

The code – improved

I took the liberty of adopting more modern ES6 syntax this time. This of course limits the browser support, but if you’re using something older, like Internet Explorer – well, sucks to be you, my friend. 😉

(function () {
  const elements = document.querySelectorAll('body *');
  const body = document.querySelector('body');

  if (getComputedStyle(body).overflow === 'hidden') {
    body.style.overflow = "unset";
  }

  elements.forEach(function (element) {
    if (["-webkit-sticky", "sticky", "fixed"].includes(getComputedStyle(element).position)) {
      element.parentNode.removeChild(element);
    }
  });
})();

It’s important to use the unset property for overflow, since any CSS we’re setting via JavaScript in this manner becomes a style attribute on the target element. So this means that we have to override any styling set via an external stylesheet.

Improved, but not perfect

So this improvement might handle most cases, but not all of them. There’s almost as many ways to mess with the user experience as there are websites. I’d be happy for any feedback and suggestions to improve this bookmarklet. The easiest way is of course via the public Gist I’ve set up for the bookmarklet code. There’s also a CodePen if you want to fork and play around easily.

Finally, here’s the updated bookmarklet, for your convenience.

Kill sticky/fixed

Happy browsing!

Killing both fixed and sticky headers

Last year someone linked to an article by Alisdair McDiarmid containing a bookmarklet that killed any element on a page that had the property position: fixed;.

Knowing how the modern web sometimes might look, this type of bookmarklet is easy to love. However, with the advent of more modern solutions in CSS such as position: sticky;, the bookmarklet is in need of some updating. What better way than to do it yourself, then?

Here’s the code

There’s just a few minor additions needed to the original code. In addition to checking for position: fixed;, we also need to check for position: sticky;. There’s one caveat, though. Safari still uses a vendor prefix for sticky positioning, so we need to make sure to look for -webkit-sticky as well.

(function () {
  var i, elements = document.querySelectorAll('body *');

  for (i = 0; i < elements.length; i++) {
    if (["-webkit-sticky", "sticky", "fixed"].includes(getComputedStyle(elements[i]).position)) {
      elements[i].parentNode.removeChild(elements[i]);
    }
  }
})();

All done! But this won’t do us any good unless it comes in the form of a handy bookmarklet, so here’s that as well. Drag this link to the bookmark bar of your browser of choice (or just save it).

Kill fixed/sticky

The caveat with these kinds of bookmarklets is that they are only working on the current page. If you leave the page or reload it, the effect disappear.

There’s a public gist up if you want to fork the code and play around with it yourself. There’s also a really neat online tool for generating bookmarklets of your own.

That’s it! Enjoy!