Tag: Web Development

The more I see how JavaScript gets used in websites I visit, the more I despair. Like when extra content gets loaded in, I click a link in that extra content to go to another page – so far, fine. But then if I click the back button in browser it won’t jump to where I was previously because that content isn’t there any more – not until I scroll down or click the ‘load more’ link at least. I dare say there is a responsible way to approach this. Here’s my idea – just paginate the results and provide page links. Zany idea I know.

I finally did it

Update: I’m now using WordPress again.

Ever since I can remember having my own website, for the most part, I have used WordPress. I’ve loved using it and will always recommend it to clients as being the best way for them to publish online. Of course, with me being a web developer I’m always wanting to tinker. There isn’t a day that goes by without me messing about with something on my site.A concept that I learned about, about six months ago or so, was that of the indieweb. Now this isn’t some new platform or anything like that. Rather it’s a set of principles, a way to approach publish on the web. In fact it’s the oldest method of publishing on the web: publishing on your own website.WordPress is great for publishing. But as my needs became more complex, and needing to make more fine grained choices when publishling different sorts of posts, I found my self neglecting to post notes/thoughts because the process of ticking the correct meta values and category was a bit combersome. The process adding a quick note or thought, like that of jotting something in a notepad, should be quick and effortless.So what I wanted was a stripped back UI from which to post notes, as well as other kinds of posts. Because of this I decided to go with a framework as opposed to a CMS platform, choosing ultimately to go with Laravel.The process is still on going as I still need to configure 301 redirects from my old site. But at least I am now publishing from my new site, and new domain, and it’s never been easier to do.

WordPress “Must Use” Plugins Directory

The Issue

I wanted to build a site with some custom post types, taxonomies and the like. But what if somebody who has used my theme decided to try another theme later on? What guarantee do they have that those custom post types will be recognized by a future theme?

None — that’s what.

WordPress obviously has its plugin directory, which is designed for adding in pieces of functionality that should span across themes. But what if these are essential to the working of the site due to custom post types, taxonomies or shortcodes?

Either it can be a plugin — which could be accidentally deactivated, or added to the theme’s functions.php — which would need copying over to any future theme.

A Hidden Gem of a Solution

Well it turns out that there is a third option — a way for WordPress to auto load essential plugins irregardless of the theme being used. Simply by creating a directory in the ‘wp-content’ folder called ‘mu-plugins’ — which stands for “must use plugins” — and adding plugins as you would into the regular plugins folder, they will be auto loaded with any theme and just work.

These ‘must use’ plugins will then be viewable in the plugin admin page, in a new option called ‘must use’ — grouped with the other plugin page navigation items, ‘All’, ‘Active’ and ‘Inactive’.

‘Must use’ plugins can’t be deactivated in the admin — creating a nice separation of essential plugins for a particular user.

Thanks to Justin Tadlock for this piece of info.

WYSIWYGs will kill us all

So okay, maybe they wont literally kill us all, but you’ve got to admit — they can be pretty damn annoying. At least with ones I have used.

I’m not dissing wysiwygs — just what they get used for.

Firstly let me just say that I use a wysiwyg editor on my own blog and it does exactly what I need it to. I type text and it saves that text. I click to add a link and it adds a link. Brill!

For a blog, where writing long posts with the odd link and / or bolding of text, a wysiwyg really is great. But what I don’t believe in is using a wysiwyg for anything more than that.

Let me explain.

With a standard WordPress install, when you write a post or page, the content from the wysiwyg is spat out by the function the_content(). This displays all that content in one block within the page. Of course WordPress is — at its roots, a blogging platform (and a damn good one) so the ease of writing and publishing has always been at the forefront.

But what if our content is more than just a blog post? What if it’s an album or film review? Or specifications for a car? If we bundle all of the content into one block then we are a stepping away from what we need most nowadays, which is structured content.

The need for Structured Data

The need for structured data these days is more important then ever. With the whole multi device landscape, a site’s content needs to be able to display beautifully whereever it is viewed. We need to be able to control as much of the content in as much of a modular way as possible. Also, as a result of making content more modular, it means it can be a lot easier to group and sort that content.

For example, if we have a database of 500 albums with all of the content for each album in its own single block of content, it makes it extremely difficult to categorize those into various artists or genres. Whereas if it was set it up in a way that has separate fields for each content chunk — an artist field; a genre field; etc — then those albums could be easily sorted and categorized.

Karen McGrane gave a fantastic talk at An Event Apart, Boston in 2012, where she talked about the TV Guide who made a wise decision about their content structure back in the 1980s. She talked about how the TV Guide wrote out three different descriptions of the same programmes — One small, one medium and one long. This was before TV on demand or Tivo, where now that sort of structured content is invaluable for use across different devices and contexts.

I recommend you watch the video, but I wanted to include a great quote from that talk here:

…a clean base of presentation–independent, well–structured content that you have designed, from the start, with the intent that you may want it to go out and live on a wide variety of different platforms. In fact you know from the beginning this content is going to have to live in a variety of different places…

Karen McGrane An Event Apart, Boston, 2012

Example – content for a music album

All the content for an album in one chunk: 

<-- Output Html of the_content() in a wordpress site --> 
<p>This Train features 12 songs from the angelic, sometimes haunting, voice of Chrysta Bell. It was produced by David Lynch and features songs written by them both, including the track 'Polish Poem' from the film 'Inland Empire'.</p> 
<p>Artist: Chrysta Bell</p> 
<p>Produced by : David Lynch</p> 
<p>Release Date: September 29, 2011</p> 
<p>Tracklisting:</p>
<ol>
<li>This Train</li>
<li>Right Down To You</li>
<li>I Die</li>
<li>Swing With Me</li>
<li>Angel Star</li>
<li>Friday Night Fly</li>
<li>Down By Babylon</li>
<li>Real Love</li>
<li>Bird of Flames</li>
<li>Polish Poem</li>
<li>The Truth Is</li>
<li>All the Things</li>
</ol>

So while the above html code is okay, it doesn’t allow for much flexibility.

What happens if — in a few years — the website gets a complete redesign? Imagine there are 500 albums in the site’s database. Well then we’ve got a problem. We can have a lovely new shiny design but the bulk of the content is already set in stone somewhat.

In the example above we have the track listing below the review. What if we wanted to flip that? Or better yet, what if the new design wanted the track listing removed? What do we do then? Use regular expressions on the html to remove the track listing from the content?

No.

Also, as mentioned in Karen McGrane’s talk, the content should be able to live in a variety of different places. What happens if the content is viewed through a smart watch, or internet fridge? Will we want all of that content handed to us in one chunk?

Probably not.

Maybe we want to display just the Album title and artist with the option of loading in the track listing if needed.

In the music album example above, we can see sensible chunks of content that could be easily separated into sensible content chunks:

  • Track Listing
  • Review / Description (perhaps differing versions for use in different contexts?)
  • Producer
  • Artist
  • Title
  • Release Date

Using separate input fields for each of these chunks, means that each part of the content is individually available and much more flexible in how and where this content can be displayed.

WordPress has custom fields that can be entered on a per page/post basis, as well as the ability to add custom post types. No doubt other CMSs have similar options available — I’m just not very clued up on those ones.

The use of these custom fields is definitely a step in the right direction, but what we need is for CMSs to be more content-modular at their core. Like I said before, I’m not clued up on CMSs — other than WordPress and OpenCart — so please don’t hunt me down and shoot me in the face if there are indeed CMSs out there already like this.

And if there are please let me know of some good ones.

Tar!

Inspiring this post

This post was originally going to be me snivel–bitching about wysiwygs. But I heard this podcast on the web ahead, which talks about content structure in great depth and it got me thinking about it in more detail than my initial post. The podcast also mentioned that talk by Karen McGrane.

On the evening of me writing this post, before publishing the following day, I travelled down to Milton Keynes Geek Night and saw five fantastic talks.

One of those talks was by Relly Annett-Baker called ‘Future Perfect Tense: creating good content for an imperfect web’. A lot of what Relly was talking about was stuff I had been thinking about that day — so that was nice.

I will link the recording of the talk when it goes online as it is well worth a listen.

HTML 5: Omitting unnecessary speech marks

In my last post I described how it is possible to cut down on your HTML filesize and save some time in your coding by omitting optional closing tags.

As a follow up to that post I thought I’d also describe another process to save even more on your filesize and a little bit more time still.

Please note however, these examples i’m describing are really micro-optimizations. For every project you make to be the best that it can be, I would strongly recommend looking into combining your scripts into one single file and minifying it. Minifying your CSS can also go a long way to improving speed. Those techniques, as well as others, are a seperate issue but are definiately worth your time in learning.

Back to the speech marks

A lot of us developers, me included, have a habit of wrapping up our attributes in speech marks, whether single or double, as in the following example:

<head>
  <meta charset="utf-8">
  <title>Example Title</title>
  <link rel="stylesheet" href="css/style.css">
</head>

The truth is, however, that in most cases you can leave the speech marks out completely, as in the following example:

<head>
  <meta charset=utf-8>
  <title>Example Title</title>
  <link rel=stylesheet href=css/style.css>
</head>

The browser will still render that correctly, and if you view the page source with the Chrome dev tools ‘inspect element’, you’ll see that the speech marks have in fact been put in for you!

Most Cases you say?

There is one situation where you will still need to use speech marks. This is when attributes have more than one value, or includes any white space. For Example:

<section>
  <span class="main-class secondary-class"></span>
  <img class=section-image src="images/image name with spaces.jpg">
</section>

So as a rule, when declaring attributes on html elements, you can omit all speech marks where there’s no white space contained. This is because the attribute ends when it hits the white space. I hope this helps you all to add an extra little bit of optimization into both your workflow and the size of your code.

If you have any of your own tips for code optimization, please share it in the comments section below. Thanks!

HTML5: On removing optional closing tags

Firstly, an example of some html…

<article>


  <p>Once upon a time there was a web programmer.</p>
  <p>He found that he wanted to cut down on his html filesize.</p>
  <p>He came up with a list of ideas. They were as follows:</p>


  <ul>
    <li>Minifying his code</li>
    <li>Cutting out content, (unacceptable!!!).</li>
    <li>Remove optional tags, speech marks, etc...</li>
  </ul>


  <p>On writing the last item in the list, he exclaimed, <em>That's amazing</em>, now to tell others...</p>


</article>

Lovely and semantic. Now, there’s nothing at all wrong with what I’ve written above. This article is all about showing you how there are certain things in your HTML that can be left out, without breaking any part of it.

You can actually omit many closing tags and still have it render exactly how you planned.

The example above, after removing optional closing tags:

<article>


  <p>Once upon a time there was a web programmer.
  <p>He found that he wanted to cut down on his html filesize.
  <p>He came up with a list of ideas. They were as follows:


  <ul>
    <li>Minifying his code
    <li>Cutting out content, (unacceptable!!!).
    <li>Remove optional tags, speech marks, etc...
  </ul>


  <p>On writing the last item in the list, he exclaimed, <em>That's amazing</em>, now to tell others...


</article>

The elements removed:

Paragraph closing tags can be omitted, because when the next one begins it knows that the last one has finished. Same with the list items also. Each list is begun with its <li>. But you’ll notice other closing tags have been kept.

The elements remaining:

The article still needs to be closed, as the browser will otherwise think the article is ongoing. The </ul> has also been kept, as it wraps the list, and stops the last list item from continuing onwards. And lastly in the example above, the </em> has remained, simply because, if left out, will continue to emphasize the rest of the paragraph.

Common Errors to be aware of:

There may be times when you will omit a closing tag, but find it may mess up your code. For Example:

<article>
  <h1>The heading is as expected. Yay!
  <p>But the paragraph inherits styles from the <h1>, boo!
</article>

The above happens, quite simply, because the browser doesn’t know that the <h1> should close. So as a result the paragraph is treated as though it is ‘wrapped within’ the <h1></h1> tags. The <h1> in the example above is closed by the browser, when it reaches the end of its parent continer, the <article> And so ends up rendering as the following:

<article>
  <h1>The heading is as expected. Yay!
    <p>But the paragraph inherits styles from the <h1>, boo!</p>
  </h1>
</article>

Combating this, however, is easy. See the following:

<article>
  <header>
    <h1>The heading is now contained within both header tags that we close in the code...
  </header>
  <p>...and so now the heading styles wont bleed into this paragraph as they are contained in the <header>
</article>

By way of summary

At first it can feel odd omitting these optional closing tags, but it will, in the long run, save you both time and those precious bytes. You just need to make sure you pick your times carefully. Generally, the rule I try to stick to is: if its a container with more than one type of child element (ie. article, section, div, nav etc.) close them off in your code. But if they are single entities, such as paragraphs, headings(of same number), lists etc, that are immediately preceded by the same tags, and have no differing siblings, omit the closing tag.

It will take a bit of getting used to, but if you nest your code well you will quickly begin to notice where you can omit closing tags.

Developer inspect tools can help

I am a huge fan and regular user of the chrome developer tools. you can use its ‘inspect element’ feature to test out your code to see where the tags are being closed by the browser. Just write a paragraph without the closing tag and view it in the inspector. When you see it in the flesh and get used to how the browser renders your code, it will give you more confidence to omit those optional tags.

In Google Chrome, right click any part of the web page, and you should see the option to ‘inspect element’ towards the bottom.