I’m in the middle of writing a front end styleguide at the moment. Today, I finished the basic stuff like colours and typography and started to think about the components that I would need to write.

Thinking about these small pieces out of context of a full page layout has been incredibly valuable today, especially in terms of responsive design. I found it a lot easier to make these components adaptable because I didn’t need to think about other parts or modules on the page and could just focus on one thing at a time.

I’m really intrigued by this way of modular front end development and I can’t wait to finally join all those pieces together and see how they interact. That’s what I learnt today.

I’m working on a redesign for one of my clients’ websites at the moment. Their website is not yet responsive and needs to be rethought in terms of structure and information hierarchy.

I’m in the very early stages of the process and the first thing I did was a quick mockup in HTML and CSS to outline the new content hierarchy of a page. Today I reviewed this prototype with the client, got valuable feedback and explained my thought process behind the new page structure.

I got the impression that the client was very pleased with being included at this early stage. Because there wasn’t anything fancy to show in terms of design yet, we focused primarily on the structure of the page. Considering the feedback I got today, I’m convinced that involving the client from the beginning is very important for any project. That’s what I learnt today.

Today I had to deal with hint.css, a little CSS library for non-JavaScript tooltips. It makes use of CSS3 animations, data-* attributes, pseudo elements and the content property. The text for the tooltip itself is stored in a data-hint attribute and gets displayed when hovered over.

I was facing a problem today where I had to display a tooltip with multiple lines. At first it seemed impossible to add line breaks to the content of an attribute. But after reading up on it for a bit I found a way that worked very well for me.

I inserted the line break via an entity like this:

<a href="page.html" data-hint="One line&#10;And another line">My link</a>

and added a white-space: pre to the pseudo element that represented the tooltip. Et voilà: multiline tooltips. That’s what I learnt today.

Some time ago I wrote a Textformatter module for Processwire which scanned the content of a textarea for <img> elements and converted them into their previously configured <picture> equivalents.

This worked well until I introduced the notes section on this website. A note may very well contain an image but unlike the images in regular articles the images in notes are not rendered per textarea field. The note template uses Processwire’s Pageimage methods to put out the URL of the image directly into the template hence the Textformatter module I had written wouldn’t apply.

Enter: ImageToPicture module

So once again I wrote a module to solve the issue. After installing it, the module adds a new method to the Pageimage class which allows rendering any image with proper <picture> element markup.

The new toPicture() method can be called like this:

$image->toPicture();

There are some options available, to define queries and image sizes. These are the defaults:

$image->toPicture(array(
  'fallback' => 450, // width for fallback image
  'altText' => '', // alternative text (default is image description)
  'sources' => array(
    '(min-width: 64em)' => 600, // queries and image widths
    '(min-width: 45em)' => 520 
  )
));

Using toPicture() without any options renders the following output:

<picture>
  <source media="(min-width: 64em)" srcset="img-600px.jpg">
  <source media="(min-width: 45em)" srcset="img-520px.jpg">
  <img src="img-450px.jpg" alt="Image description">
</picture>

A customised call might look like this:

$image->toPicture(array(
  'fallback' => 300,
  'altText' => 'My new description',
  'sources' => array(
    '(min-width: 55em)' => 860,
    '(min-width: 27em)' => 450 
  )
));

Which produces:

<picture>
  <source media="(min-width: 55em)" srcset="img-860px.jpg">
  <source media="(min-width: 27em)" srcset="img-450px.jpg">
  <img src="img-300px.jpg" alt="My new description">
</picture>

The code is available on Github – perhaps it might be useful to somebody.

Today, one of the clients I’m working with asked me to change the rel attribute on a couple of <a> elements to rel="noindex nofollow". I was almost completely sure that there is no noindex value for the rel attribute but I looked it up anyway.

While browsing through the specification of link types, I came across prefetch. I heard of this particular link type the first time in Scott Jehl’s talk at Beyond Tellerand conference in May, but I had almost forgotten about it.

Time to do some research: prefetch basically tells a browser “when you’ve got the time, go and preload this resource and store it in the cache”. An example could look like this:

<link rel="prefetch" href="some-script.js">

This speeds up the page load process when that prefetched resource is needed and works only for cacheable resources.

There is also a dns-prefetch, which preemptively resolves the IP address of a given domain to save time when that resource is requested. For example:

<link rel="dns-prefetch" href="http://some-domain.com">

I guess using these techniques requires a lot of insights on how the user navigates a website. But I think I might give them a try at some point. That’s what I learnt today.

Recently, I’ve been looking for an easy way to use the <picture> element with Processwire. By easy I mean this: the user uploads an image at a reasonable size and Processwire does the rest. (I just noticed you could interchange “easy” with “lazy”)

So I wrote a Textformatter module that allows you to do just that. Via the module configuration page you can specify multiple sizes and media queries which the module will then use as <source> elements when rendering the page. You can also provide a fallback image size for browsers that do not yet understand the <picture> element.

The module uses Processwire’s image sizing capabilities and resizes the original image to the configured sizes, when the page is rendered. It then replaces all the <img> elements with the appropriate <picture> element.

You can get the module from Github. It’s still a bit hacky and I have some more features in mind that I want to add. But it does it’s job quite nicely so far.

I’ve been working alongside a client’s web development team for quite some time now, but it hasn’t always been that way. When I first started working with the company, there were just two of us: a PHP developer—mostly doing Magento e-commerce systems— and me, a front end developer/designer making websites.

The team has grown over the past few years. Today it consists of eleven developers working side by side on projects rather than just working on their own like we did when there were only the two of us.

Challenges of growing teams

As the company grew and people joined the team, we adopted tools like git and JIRA to tackle certain issues such as shared source code, version control and issue tracking. But eventually we were facing another problem: there were no coding standards that defined how we should write certain source code files.

At least none that the whole team agreed upon. Sure, everyone knew how to write HTML documents or style sheets but when it came to things like naming classes, indentation, semantics or using SASS, there were a lot of different opinions on what could be considered readable code.

Frankenstein code

Working without coding conventions can be very time consuming, especially when there are multiple developers involved in a project. Reading and understanding someone else’s code can be a real challenge, especially on large projects.

When developers keep editing the same files without any coding guide lines they often end up with some kind of Frankenstein code that everyone throws their own class names, indentations and document structure at. The result is almost every time very hard to maintain and it takes developers joining the project a very long time to work their way through the potpourri of different coding styles.

How we defined our coding conventions

The first thing we did was to find common ground - rules that we already worked by and that we all silently agreed upon. Then we looked at best practices suggested by w3schools, CSS guidelines and jQuery to develop our own set of rules for writing front end code. These included things like formatting, indentation, using and naming classes, variables and functions and so on.

Last week I ran a workshop on front end coding conventions for that particular development team. I also prepared a cheat sheet for everyone’s desk. You can download it here, perhaps it might be useful to you.

I think coding standards are invaluable in a collaborative environment. They ensure proper document structures, consistency and easier maintenance of legacy code.