Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

There are a lot of analogies for HTML/CSS development; which can be a bit confuse for a beginner.

   HTML = foundations/house
   CSS = walls/blueprint/wallpaper

Is there any best practice here? Which one should we write first?

share|improve this question
5  
I'm not sure how you should go about writing CSS first, if you wanted to do that. –  TRiG Dec 15 '12 at 22:35
add comment

8 Answers

up vote 68 down vote accepted

You should build a house first, then paint it.

An HTML document can stand on its own, even though it may look dull. A CSS style sheet cannot; it is nothing displayable (except as code) but instructions for display.

It’s a different issue that during painting, you may wish to do changes to the house. With real houses that’s usually not feasible, but in HTML+CSS development, it’s commonplace to notice that you need extra markup in your HTML document to make styling easier. (It’s less common than it used to be, thanks to powerful CSS3 selectors.)

share|improve this answer
    
I mostly agree. The only problem is when you use CSS for layout..aka grid system. –  Daniel Dec 15 '12 at 10:44
    
@Daniel, why would that be a problem? There are several ways to do layout in CSS. Some of the older ways do not let you rearrange elements freely, independently of their order in the HTML document. But e.g. absolute positioning lets you do that, and so does the CSS3 grid system (which is under development). If older layout tools are used, then indeed HTML document may need to be reorganized if ideas about layout change. –  Jukka K. Korpela Dec 15 '12 at 11:09
1  
@The more layout you do with css the easier the design will be to maintain down the road. Most sites undergo design changes through their life times. This is much easier to accomplish if all you have to do is change the css. –  Kenneth Dec 15 '12 at 12:08
3  
It is not realistic that CSS and HTML are completely separated. In real life you would, in most projects, write at least some HTML that is just for styling purposes. I suggest an iterative model, where you start out with some HTML, add CSS and then add some more HTML. Do this in a fashion that you first write the structure (like a grid) for the website, then work your way into finer details. –  Thomas Dec 15 '12 at 16:33
2  
One thing I'd add to this fine answer: not only can an HTML document stand on its own, but it should be reasonably clear and comprehensible when it does so. Remember, that unstyled HTML is basically what the search engines are going to see. Take a look at it, is it well organized with headings and lists and other such semantic markup? –  Carson63000 Dec 15 '12 at 22:36
add comment

I always use pen and paper first, full size paper, to-scale drawings.

That is if you don't have your design ironed out. If you are confident in your design, I have a balanced approach; html is the structure, css the glue. Keep building up in (HTML,CSS) concept 'tuples'.

(HTML,CSS) + (HTML,CSS) -> (bigHTML,bigCSS)

(bigHTML,bigHTML) + (bigHTML,bigCSS) -> (biggerHTML, biggerCSS)

and so on.

That's how I do it, anyway.

share|improve this answer
add comment

A lot depends on the type of website / web application you make, and the kind of context in which it is going to be used.

In most cases, the best way to go is to build semantically sound HTML, then add CSS for standards-compliant browsers, and then applying non-intrusive hacks and rules (e.g., IE's conditional comments, -vendor-something CSS rules, javascript compliance layers, etc.) to support nonstandard browsers and enable vendor-specific features.

However, sometimes you have a bunch of independent web applications that share stylesheets (e.g. as part of a house style), and you may even be in the luxury position to control the HTML output of each one. In that case, writing the CSS first, and then tweaking the HTML to work with it, may be a better way to go. If you do this, the way to go is to first analyze what kind of page elements you are going to need, define classes for these, then write a some static test document that use them, write the stylesheets, and only then start writing the applications that use them.

In all honesty, though, I suspect that such a luxury position is extremely rare, and few companies actually recognize the value of a unified house style at the CSS level; more often, practicality dictates that a designer makes the house style, and then independent sets of stylesheets are written for each application that needs to follow it. The reason for this is, mainly, that most companies use off-the-shelf software with limited modification possibilities for at least some of their stack, and often, changing their HTML output to fit a given stylesheet is much harder (or even impossible for some proprietary packages) than rewriting the CSS. Additionally, the effort of maintaining a dozen sets of stylesheets is often underestimated, and some minor differences and quirks are deemed acceptable.

share|improve this answer
add comment

I believe that working with the websites structure (HTML) first makes more sense as you then will have an idea of the elements and there names for when it comes to styling and formatting your website.

share|improve this answer
add comment

This depends on your actual role and primary goal of development. If the goal is to determine what should be shown to which extend at a web page, one should start with HTML. If the goal is to create a pleasant and uniform design, one may start with CSS. In both cases one might better first start with paper and pencil, and if the current goal is to develop a web application, one should not start with HTML or CSS at all. The best practice is to first think about what you want to develop and then divide the task into goals and sub-goals instead of just hacking everything together.

share|improve this answer
add comment

Design the house (grid layout) along with an idea of how it will be decorated; Build the house (HTML) with the grid; then decorate it (CSS style sheet).

After you have built the first house (HTML page), you can just apply the same decoration (CSS style sheet) as you go along. You may tweak the decoration as you go along.

Eventually, you may want to redecorate (redo the CSS style sheet).

share|improve this answer
add comment

You've picked a really poor framing for learning and building.

There are two orthogonal issues at hand here.

  1. How do i build a site that serves my needs?
  2. How do i learn to build a website?

Those are two very different tasks can (and often do) require different potentially conflicting approaches.

If you are familiar with the skills, technologies, and requirements of a project, one starts with a discussion about the needs of a site, and go through design exercises in order to determine what it is that needs to be implemented. That often means markups and design stuff, which will often have nothing to do with either HTML or CSS (although some people do mockup with HTML & CSS).

If you are trying to learn how to build a site, while also building a site, there is a process of exploration and learning that you must engage in before you know what is even possible to build.

This is where a modular and iterative design and build strategy has become popular. When you don't necessarily know where you're going with your end product (because you don't know what's possible), you build small chunks of functionality, experiment with whether it meets your requirements, and then incorporate that smaller experiment into the larger whole.

So, what does that actually mean in concrete terms? Building a site can be like building a house, where you draw up architectural plans (design mockups) and then start doing the engineering to calculate whether your house will stand up and meet your aesthetic needs. But building a site can (and often should) look more like building a series of small experiments, and taking a step by step approach to reaching a product that meets your original concept.

As a very practical matter, almost everyone futzes with both their HTML and their CSS at the same time.

share|improve this answer
add comment

This is the common problem in any software development project imho and as such you could benefit from using any of the concepts such as Rapid Prototyping, DSDM. Combinable with any style e.g. agile (extreme programming or Feature Driven Design (my favourite)). Sticking to common principles that you decide at the beginning as you face them, and hang on to them (KISS, YAGNI).

So for me it is: - build a basic functional 'prototype' first, covering one functional block of the demand Restrict yourself from diving into 'this might be nice'/ 'i may need to reuse this later' things unless they are OBVIOUS. Tell yourself, you aren't gonna need it! (YAGNI). - Write down decisions you make as a 'coding convention' and stick to them e.g. php tags: I use short ones because for my scenario argument .. applies and ... does not. - add basic styling but restrict yourself again.

Then expand your code until you reach a higher-level prototype which covers more functional blocks. In line with it, make your css model grow. As soon as you face decisions that affect all you already did (you will), read up on it, make a decision and write down in your coding conventions why you went left or right.

'Circle' your way towards a more mature and final product.

Don't be afraid about the big decisions you may be facing, because worrying about them may cost you more time than fixing it down the road. Also, don't worry about the internet community looking over your shoulder with a frown, in the end when you have a product that works, you have learned a lot, and the imaginative judge of bad source code is going to be pleased more by the next thing you build (notice the iteration here).

Just my 50cts

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.