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.
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 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.
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:
There are some options available, to define queries and image sizes. These are the defaults:
'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:
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.
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.
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.