Should I write HTML or CSS first?

Question

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

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

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

Answer 1

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.)

Answer 2

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.

Answer 3

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.

Answer 4

Even though this is a very old Q&A, I feel the need and responsibility to comment on it.

Yes, HTML should be written before CSS, however...

You do NOT write all HTML on the page, and then go back to write the CSS. This would make it extremely difficult to clearly remember the sections as you build it out, even with proper spacing and comments.

You build a website in layers, as if you are making a multi-layered cake.

1st Layer - First you build the base, the container div, with it's min-height and width css.

2nd Layer - Then you build the next layer, the large sections of the page (divs and styling for structure), such as rows or sections looking like columns.

3rd Layer and beyond - Then you keep adding within the second layer of sections.

In this way, you write some HTML, add then style it with CSS for the structure, rinse and repeat. In my experience, this is a much more effective way of building web pages, and in my opinion much faster than the alternative of all HTML first.

Lastly, try using " * { outline: 1px dotted red }" to get an outline of all your elements, as you add them on your page with styling, you can see their outline and not have to worry about guessing what it looks like until you add your background colors. I avoid border for this particular use case because borders add pixels on the elements, outline is an overlay.

Give it a try, thanks!

Answer 5

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.

Answer 6

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.

Answer 7

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).

Answer 8

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.

Answer 9

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

Answer 10

As you comparing a web page to a house:

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

How are you going to float the walls in mid-air until you build the foundations that they sit on? How can you write CSS to style your page until you have the HTML tags written that you are applying the styles to.

Each piece of CSS is styling specific HTML tags. Those tags need to exist in order to be able to style them. If you have no HTML to style then the CSS file should be empty as any styles in it are redundant as they don't actually style anything.