How to Write HTML, CSS, and JavaScript to Make Back-End Developers’ Work Easier

csshtmljavascriptjquery

When I get a design from a designer, I get it as a PSD (Photoshop) file. I always expect proper layer and folder names, basically a clean and managed PSD. From this desigbn I develop HTML, CSS and JavaScript and deliver it to the back-end developers. To make it easy for them to understand, I

write semantic code,
keep JavaScript and CSS in external files,
add useful comments in HTML, CSS and JS files,
use CSS sprites (though developers don't like it),
use HTML5 boiler plate,
use jQuery for JavaScript,
try to use new HTML5 tags and CSS3 whenever possible and
sent a Zip file containing the HTML, CSS, JS and images.

I expect that if small changes will need to be made to the layout, the developers can handle that.

I would like to hear from back-end developers and other CSS ninjas what more one could do in terms of organization of files and mark-up to make the integration with back-end systems easier (i.e. back-end technologies, PHP, .NET, Ruby etc.) Different client uses different systems.

Best Answer

A lot of these answers are going to cover the broad swaths of ideas, but here's my personal ones:

Leave room in the form design for error messages.
Don't put labels in the input boxes!
Put your CSS and JavaScript in a separate file, unless you know what you're doing and feel properly bad about it.
Keep design elements the same between pages. It's infuriating when a design component (like a "recently viewed" box) has different markup on every page.
Don't do what's easy for you, do what's right. <button> tags suck. backround-image for things that really should be <img> tags suck.
Make sure that if you're creating a page component, it can scale. I know most good front-end developers do this, but I've had plenty of instances where someone used a single image in what should have been a top/bottom cap situation. Programmers don't like opening up Photoshop.
Proofread your templates. Programmers (good ones) are dedicated, detail oriented people. If they start seeing issues in your design (maybe the footer navigation has spelling errors or inconsistent spelling) it's going to make them ask questions and slow down their work.

Finally, and maybe most importantly:

Learn the basic conventions of the language that is being developed in the back-end. Being able to look at a PHP template and understand the basic syntax behind a foreach or an if statement and how to format an echo statement or move a <?php ?> tag around will greatly increase your value as a front-end developer - I love when a front-end developer needs to make a simple change and can do it in the template instead of handing me a new zip of all of their files.
As an addendum, learn to use version control software. You don't need to be an expert, but if I can look at a diff instead of having to try and figure out what changed between two zip files it makes my job a hundred times easier.

Those are just a few - I'm sure there are many more, but if you accomplish all of these you're sure to earn the respect and appreciation of whoever is turning your templates into a web site.

Related Solutions

Javascript – Guidelines for HTML/CSS/JS optimization process

I worked on a project which were very close to your situation. The requirements were the following:

On development side, each page can have one or several JavaScript files and one or several CSS files. All those files are local.
In production, there must be one and one only JavaScript file and one and one only CSS file. Those two files are hosted on a distant server, optimized for static files and configured for client and server side caching.
Each page has a link to JQuery hosted at Google CDN in both development and production environments.
The deployment process must be automated.
The deployment process must not modify files other than JavaScript and CSS files for compression.
The website is written in ASP.NET.
Every page of the website uses the same CSS and the same JavaScript.
On development side, CSS and JavaScript files are always in a specific predefined directory.

Here what was done by my colleague who worked on this part of the project.

All files except JQuery are minified and combined into two files: g.css and g.js, g for global. This is simply done by walking though the specific directory and searching for those files. After minifying them, the two files are send to the static content server, if they were changed since the last deployment.
The process is executed at every build, since we couldn't find how to execute it at deployment only. It doesn't matter, after all, since it takes a few milliseconds to walk through all files and check if they were modified since the last build.
The website is deployed as is, except the original JavaScript and CSS files. We don't need them in production.
The masterpage (in ASP.NET) contains a specific method which is adjusting the calls to the JavaScript and CSS files depending of the context.

This method is like this:

public string MakeCssCalls(IList<string> cssFiles)
{
    // ...
}

In development environment, it returned the links to CSS files inside the cssFiles argument. In production, it ignored this argument and just returned "<link rel="stylesheet" href="http://static.example.com/g.css" type="text/css" />". It made the difference between production and development by comparing the machine name to the list of names in Web.config file: some machines were configured as being development machines; all machines outside this list were assumed production servers.

Performance-wise, it would be smarter to have a different Web.config file for production, indicating that we are actually in production (and, for example, precising the exact link to the static server with those files; in our case it was hardcoded, and that sucks). We couldn't do it this way because one of the requirements of this project was to have a single Web.config file for all environments, but if you can, do it.

Also when is the testing generally performed? I think it should be performed on the optimized files (just in case the compressors have some bug).

We tested the website on non-minified versions of files. We never had any bug coming from Google Closure (nor our home-made crappy CSS minifier).

Is using Javascript/JQuery for layout and style bad practice

If the problem can be solved using CSS, it shouldn't be solved in Javascript, and it's a definitely bad practice to do so:

I guess no one has JS disabled nowadays, but NoScript is probably not completely negligible
Harder to debug and maintain
Probably will introduce a noticeable and ugly effect when JS loads and "fixes" the layout

Of course, there are things which cannot be achieved in CSS alone. In that case, of course, JS is the right solution if you strictly need it.

Best Answer

Related Solutions

Javascript – Guidelines for HTML/CSS/JS optimization process

Is using Javascript/JQuery for layout and style bad practice

Related Topic