News Archive
PhpRiot Newsletter
Your Email Address:

More information

Keep the Front in the Front

Note: This article was originally published at Planet PHP on 20 April 0.
Planet PHP

I'm both a front- and back-end developer, and, at, we mainly work on projects where we get to control the full stacka-afrom 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 aowell formeda will be valid across all flavors.

That really just leaves the thorny issue of self-closing elements. Elements that have a separate closing taga-afor example paragraphs or list itemsa-aare optionally closed in html DOCTYPES, but closing them is valid across all flavors. However, self-closing elements (for example, images and line breaks
) 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

Truncated by Planet PHP, read more at the original (another 2417 bytes)