For years there has been a constant struggle between front-end and back-end developers. While programmers have refined their skills at making their code efficient, the evolution of their (X)HTML and CSS is behind 4 or 5 years. I’m not here to blame programmers for making me have to redo their code, I’m simply here to help make the process of back-end to front-end development more harmonious. While I was a freelancer working with other freelance developers I was faced with doing a lot of extra work when receiving code from back-end programmers. They used tables cells in their loops, and very outdated (X)HTML such as center, italic, and bold elements to name a few. Even now as I transition to a job as a front-end developer for a well established e-commerce company, I still run into this hurdle.Â
So what I did was try to come up with some basic elements and style properties that can be easily remembered. The items in these lists are semantic and flexible. This way when the code gets handed off to a designer or front-end developer they will have been set up with a strong foundation to add to.
Once again I’m not pointing fingers or criticizing programmers. I’m simply trying to make this very common process of back to front-end development run more smoothly.
- divisions instead of tables -This is the big one. As a “standards minded” developer IÂ rarely use tables when coding, and never when forming layout for a site. The way that most every front-end developer creates structure is through divisions, also known as div elements.
Here the a snippet code you might be familiar with:
< table > < tr > < td >Some output< /td > < /tr > < /table >The semantic and easier way would be do it like so:
< div > < p > Some output < /p > < /div >Think of a division as a lightweight, more flexible table that makes styling and layout designing much easier on your designer. Another advantage to divisions is that, when embedded, they are much easier to work with than embedded tables. With every table comes rows and cells, and all that code gets really messy really quick.
- lists -Sometimes I feel sorry for HTML lists because they are often neglected when programmers are outputting text. Think about how many times you create a loop in your programming language of choice. On almost every occasion that a back-end loop is used, it will output into an HTML list. A lot of programmers I have worked with will usually use line-breaks instead of lists. Sound familiar?The reason line breaks are frowned upon by designers is because they make that text unable to be styled easily. With an unordered or ordered list there is the the block-level parent and block-level child elements that are easy to style with CSS. Here are some examples.
Not preferred:
< ?php for ($i = 0; $i < 10; $i++) { echo $i . '< br / >'; } ? > < /ul >Preferred:
< ul > < ?php for ($i = 0; $i < 10; $i++) { ? > < li >< ?php echo $i; ? >< /li > < ?php } ? > < /ul >Now the list of items is wrapped in a block-level element so no need for a division around the list, and inside the loop are list-items that are very versatile and work well with CSS. In my example I use and unordered list for items that have no particular order. An easy switch can be made to the list to make it an ordered list and have incrementing numbers representing each line-item. Simply switch the ul with an ol.
- headings -Heading elements are often neglected. Have you ever wanted to make a certain word stand out at the top of the body, and used a bold, italic, or font element? I’ve seen it countless times. Along with these elements comes more code, such as the deprecated center element to center the text on the page and other inline styles. Using an h1 - h6 heading element is the correct and easier way of accomplishing the same task.
< h1 >ello guvna< /h1 >
I’m sure that there are more elements that should be added to this list, but I felt that these were the most important to start with. In my working experience the lack of these three elements has caused a considerable amount of frustration and extra work. Having a sound knowledge of both ends of development can do wonders for productivity.Â
I can also see how some might take this as a condescending post. I’ve tried to word it otherwise, but might have failed miserably. Sorry. Please leave a comment with any questions, or if you have any suggestions for elements to add to the list. I hope this helps to clarify some questions people might have had, or even possibly shown you a problem you haven’t thought of before now.
- Categorys:
- Accessibility
- CSS
- Sites
- Web Standards
- Zappos
- design
Amen brotha! I agree on everything, few things are worse than cleaning out tables and bold tags. Still I’m guilty of using br’s to break up list items. It’s just one easy extra string concatenation.
Tyler - I too have been guilty of using line-breaks to break up list items in testing with the intension of fixing it before going live with the code. I often times would forget that last step and push the test code live. That drove me nuts especially working with version control systems where committing isn’t just saving and viewing.
So now when coding I try to make it a practice of doing it right the first time.
Excellent post. Definitely did not sound condescending whatsoever. Programmers should be doing this if they aren’t already. It’s not just being picky on your part. This is the right way to do it.
@Gabe - Thanks for the comment. It is the right way to do it, but not always the easiest for some people. It’s hard to teach an old dog new tricks. This post was just meant to spread awareness to those programmers who haven’t updated their front-end sills in the last 4 or 5 years.