PHP Advent 2011 / Keep the Front in the Front

22^nd Dec 2011, by Rachel Andrew:

I’m both a front- and back-end developer, and, at edgeofmyseat.com, we mainly work on projects where we get to control the full stack — from server configuration, through PHP and the database, to the front-end markup, CSS, and JavaScript. However, we also sometimes work on projects where we are developing the front end only, so we get to feel the pain of spending time carefully constructing semantic markup and optimized JavaScript to find the back end is filling it with additional HTML and adding inline styles that override our CSS.

On the flipside, our product Perch is a small content management system that aims to make it easy for non-developers to deploy a site. In this situation, we have to try and stay out of our customers’ markup. In doing so, we’ve learned a lot about how to keep out of the front-end code while still enabling powerful functionality.

Don’t Assume a Flavor of HTML

Currently, people are using one of several flavors of markup. You might come across front-end developers using HTML4 (which allows unclosed tags, unquoted attributes, and upper or lowercase tags), XHTML (which requires a well-formed document, quoted attributes, closed tags, and must be lowercase), and, increasingly, HTML5 (which can be written HTML or XML style).

This variety of markup means that if your PHP is outputting any markup, it may well invalidate the documents created by the front-end developers. If they are good front-end developers, this is likely to irritate them. It will also make their job harder, as each time they validate a document, they will see the errors for the incorrect markup style, making it hard to see errors they may have introduced.

Quoted attributes are optional in HTML4 and HTML5 when written in an HTML manner. However, they are valid in HTML4, XHTML, and HTML5 (whichever way you code it). So, ensuring that you quote any attributes you must output (for example when displaying form elements) will mean they are valid for all DOCTYPES. Similarly, XHTML and XML require that elements are correctly nested and that tags are lowercase, and while these are not requirements for HTML, ensuring things are correctly nested, tags are lowercase, and that the document is “well formed” will be valid across all flavors.

That really just leaves the thorny issue of self-closing elements. Elements that have a separate closing tag — for example paragraphs or list items — are optionally closed in HTML DOCTYPES, but closing them is valid across all flavors. However, self-closing elements (for example, images <img> and line breaks <br>) are invalid in HTML if they have the closing forward slash, and invalid in XHTML without. If you need to output these elements, which include input elements for forms as well as images, you should ideally allow the front-end developers to set their preference as to which they use.

In Perch, we have a number of options that can be set by the designer implementing the CMS. These include whether tags should be closed and using HTML5 so we can utilize the new HTML5 form elements if that is the case. We can then safely output form elements using the correct syntax from our templating engine.

Output Single Elements Only

Even when using a templating engine, there are times when you might have to output some markup. If this is the case, a good rule to follow is that you should only output a single element at a time. This lets the front-end developers wrap that markup in some other element if needed. For example, if you are generating a list and need to output the li elements, avoid also outputting the list itself. Find a way to let the front-end developer decide whether this should be an ordered or unordered list.

Avoid Inline Styles

Try to avoid the temptation to output any inline CSS. Due to the rules of the cascade, inline styles take precedence over those set in the stylesheet, therefore your styles will overwrite those created by the front-end developer. This will displease them greatly, and it also means they need to contact you to get those inline styles changed should the need arise. If you need to add something to show that a particular item is distinct from others, it would be preferable that you added a class to the element and tell the front-end developer what that is and in which circumstance it will appear. That way the front-end developer keeps control over how the element looks.

Allow HTML Class Attributes to Be Passed

If you need to generate markup such as an image element, let the front-end developer pass a string that will be added to the element as an HTML class attribute. This helps them add their required CSS without needing to add additional markup around the element and putting a class on that.

Use Familiar Syntax for Templating

Many web designers and front-end developers are unfamiliar with PHP, so when implementing any kind of templating that will be used by non-PHP developers, it can make all the difference to use a syntax that will seem friendly and familiar to them.

We do this in Perch by using XML tags within our templates. For our designer customers — many who have never installed a CMS before — these tags and attributes look like something they understand. To see how use of familiar syntax can promote use of a system you need only look at jQuery, which has become the JavaScript library of choice for so many designers due to its use of CSS selectors to target elements in the DOM. A familiar syntax goes a long way toward helping front-end developers and designers feel confident that they can work with the back end without breaking anything.

Let Front-End Developers Control Their Area of Expertise

Good front-end developers will be as concerned about the performance of their code as you are about the back end. For performance reasons, it is seen as good practice to include JavaScript at the bottom of the page rather than at the top. Ensuring that the developers have control over this sort of thing means they can place them there, if appropriate.

By handing control of the front-end development to front-end developers, you allow them to do their job to the best of their ability, unhampered by things appearing in their markup that they were not expecting. You also shift responsibility for that area of the site to them. If you generate reams of markup via PHP, then any time it needs to be changed, or if there is a problem with validation or any CSS issues, the request will come back to you.

Developer Gift

I don’t wear a lot of jewelry. However, I would definitely make an exception for the iNecklace:

“Sophisticated. Elegant. Open Source. The iNecklace is a gorgeously machined aluminum pendant with a subtle pulsating LED.”

There are also iCufflinks, if you are not the necklace wearing type.

About Rachel Andrew

“I am a front- and back-end web developer, and founder of edgeofmyseat.com, a company I now run alongside my husband Drew McLellan. When I’m not writing code, I write about writing code and have authored a number of books including the CSS Anthology for Sitepoint. I blog about business and technology on my personal site and speak at conferences on a fairly diverse range of subjects.”

• URL: rachelandrew.co.uk
• Location: Maidenhead, UK

Other posts

• ← Social-Driven Development, by Chris Cornutt
• Look Ma! No Passwords!, by Dan Mills →