Don’t waste time writing HTML and CSS

When you’ve worked with front-end development for a while, you start thinking about effectiveness. So without further ado, here’s my four best ways to be a more effective front-end developer. Feel free to add more ideas as comments!

1. Do you need HTML or CSS for this?

Lots of times when I get stranded on hard problem and sit back, I realize that I really shouldn’t be trying to use CSS to solve all layout problems. Assuming a rounded corner box will have to scale in all directions (up to 8 images!), when it really is fixed width and height (1 image), is an indescribable waste of everyone’s time. Look closely at the design you’re trying to implement: does it really have to be as flexible and scalable as you think? Shifting to that mindset saves me hours of work per day.

One thing that many developers forget is that not all designers care for exact pixels. If something is really hard to develop, walk over to their table and suggest a change. You’ll soon start to notice that designers are real people too, and that they have as much flexibility as you do. It’s just as easy to call them up, so don’t let shyness waste your time.

2. Try to set properties once

When you know you have to do something (see above), try to do things once. This is really tricky in both HTML and CSS, languages that have no variables, and generally makes code reuse a pain. But it is possible.

With CSS; set widths of elements once, and trust inner elements to fill their parent. That’s the default behavior of block level elements, and you can set display: block, or width: 100% on most other elements. Don’t set heights at all if you can avoid them, and let elements expand to fill their containers. Combine similar CSS selectors to avoid typing things twice, and make new ones for common properties when few properties differ. Use floats and clearing instead of absolute positioning, and you’ll won’t have to micromanage positions all the time.

With HTML, make sure that you really know the template language. I’ve fighted with ASP.NET, JSP, JSTL, Smarty, WordPress Themes, RHTML, and Django’s Templating Language, and now know enough about all of them to be productive. You should never have to type the same structure out twice, even in HTML. If your template language have loops, if-clauses and includes you really have no excuse to copy large chunks of HTML around. Refactor your HTML and make your own life easy.

3. Learn your text editor

When code reuse isn’t possible, use search/replace in your favorite text editor.

Replacing all instances of one HTML tag name with another is about replacing “element>” with “element2>” (without the opening bracket). That way you replace both opening and ending tags at once. Check to see if your editor supports regular expressions in its search/replace tool. If it does you can save lots of time by learning it. Matching a HTML tag is “<[^>]+>”, a starting angel bracket, one or more non-brackets, followed by an ending angel bracket. Naive regexps can make you match the starting bracket of one tag and the end of another, which makes for a mess.

There’s lots of little tricks like that, if you learn them you save massive amounts of time.

4. Make sure your environment supports you

There’s more than the text editor that you have to work with. One essential part of front-end development is trial and error. It sounds silly but no matter what your skill is, sometimes you must resort to trying and testing your way to a solution. With HTML and CSS, this means being able to quickly make a change, switch window, and see that change in the browser. If that cycle takes more that 5 seconds, you’re losing valuable time.

Don’t use a virtual machine (even if it’s only for IE6) that you can’t quickly Alt-Tab out of. If you’re stuck using one, you need to have the text editor on that machine too. It’s worth your time fixing it.

Don’t accept build processes that makes you wait more than 5-10 seconds before you see your changes. With trial and error coding you will then waste 50% of your capacity doing nothing. Most often you can bypass this by copying just the HTML and CSS to the right place, without touching other source-code. I’ve managed to do this in all kinds of crappy environments, and it’s always worth it.


I hope some of the above can help you save some time each day. The little things add up you know. What’s your best time-saver?

37 responses to “Don’t waste time writing HTML and CSS

  1. These are some very good tips. I often times find myself writing way too much code for the project I’m working on just because I want it to be too portable. Thanks for this, bookmarking it for when I get stalled.

  2. Good article. Flagged.

    One remark about the regex and matching more than you want:
    This can be easily avoided. You rightly point out that regexes are greedy. To make a regex non-greedy, add an ‘?’ after the repetition qualifier.

    For your example:
    <.+> is greedy
    <.+?> is the non-greedy version

  3. Darn.. your comment filter does not like regexes with less than/more than signs in the comments…. oh well…
    I hope the example is still clear enough even though the regex has been cut in half.

  4. Probably my best time saver is to have a bomb-proof structure for the CSS file, that I know cold. I’ve developed one that takes a while to explain (won’t bore you with it now), but that works really well, even for huge, gangly files. Whatever your method for managing your CSS file, having a standard way of executing it, and knowing exactly where to look to find “div#into p.highlight a:hover {}” is key. I know exactly where in the file that would be.

  5. @Jrf: Good catch, I didn’t know about that. I hope many of the regexp dialects used knows it! I (think) I fixed your regexp by using &lt; instead of starting angel bracket.

    @Charlie Park: ah, I knew I forgot about one important point. I also have a CSS structure I use.

  6. Interesting read, even though I was a little taken aback by the headline. Great tips to help streamline the process.

  7. Good tips, but I disagree with your first point. If something contains text, I want it to be flexible and scalable so that when people change the font size, my entire layout does not break. To see what happens when you don’t make things scalable, go to the New York Times website and hit Ctrl-+ a couple of times.

    And like Emil and @Charlie Park, I have a similar CSS structure that I use to avoid breaking things. It saves a lot of time.

  8. I’d add neat, organized, readable coding to the list. You can make good coding a habit such that it takes little or no additional time but saves loads of time when you or someone else has to come back and modify that code. I can’t tell you how many times I’ve scratched my head wondering, “How many close div tags do I need here?” because the designer hadn’t used proper indentation.

  9. Pingback: Design Inspirations for July 10th |
  10. To see what happens when you don’t make things scalable, go to the New York Times website and hit Ctrl-+ a couple of times.

    Looks fine in Opera, Firefox 3 and IE7.

  11. @zcorpan: When you get 100% of users to adopt those three browsers, you can stop worrying about it. Try in FF2. (Of course, IE6 only has 5 text sizes, but if your margin of error is too small, it’ll still break.)

  12. @James Socol: Even though you want oldfashon text-size increase you can fix the width, but make it scalable in height. Piece of cake, and save lots of time there too.

    @Heather: Sorry for the headline! Thanks for the linkback :)

  13. @Emil: That works until you have a long word. Accessibility is a key requirement for most of the work I do, and people do triple or quadruple font-size, but even when it’s not, I want to control the number of characters per line. Changing line lengths changes the way people read your text. People read shorter lines faster, and tend to skim and miss information. Long lines, on the other hand, slow people down. If I make a column wide or narrow, it’s usually on purpose, and I don’t want to give that up.

  14. Fixed content widths is excusable in one case only: When more time is spent writing the css than the sum of the time all readers spend on the site!

    And I’d like to reverse the first item! :-)

    Most of a site can and should be developed in plain html+css. When that is no longer practical, some xslt/jsp/php/etc and/or javascript can be usefull. In extreme cases, even flash can have its points.

    Lots of sites seems to use flash and/or giant javascript toolboxes for no actual reason. That’s fine for a playground project, but a real project for a real client should be built up from the usecase, not down from the cool widget …

    Despite this, a good text and sound advice. Thanks! :-)

  15. Great Post.

    Many good tips for increasing productivity. One suggestion with tip #4 is to get a second monitor. Having side by side monitors has made me close to 30% more efficient. It’s difficult to work without 2 monitors now.


  16. I’d like to add one to your list. Prototype everything that you’re not 100% sure you can do for real. The earlier you can flag items that are going to be difficult or will take a long time to build, the less time your customer, or designer, or stakeholder has to get attached to them. And I’ve found that customers can be real people too and will def drop items if they know they’re gonna take an age to build. Cheers. Ask.

  17. @James Socol: There is no good way to handle long words in CSS, so I can’t see how that matters in the case of rounded corners. Do you mean that all boxes should be wide enough to be able to contain long words?

    @Rasmus Kaj: For the special case of expert users I agree with you. But for most other cases, people don’t have any idea of how to resize the browser window, so they will get too long lines.

    @Tyler, ask: Good tips!

  18. No, I’m not saying that you should use the full browser width for text, just that pixels are the wrong unit for it. Use the em unit or a percentage! I tend to use percentages, but also specify a max-width for the actual text containers in ems.

    Too many sites specify a content width in pixels, and a tiny font. A user who finds tiny fonts uncomfortable soon learns to change the font size (ctrl +), but then many layouts break down.

  19. – File versioning to improve workflow (simply a last modified date hard-coded can be a good start)

    – Reusing code blocks

  20. Hi Emil,

    Found your blog through a link on the Geek Meet Stockholm page. Glad I found it :)


    PS: I am looking for concept development / user experience / user interaction design type folks. Let me know if you know any good ones or send them my way. Thanks.

  21. @Emil I didn’t mean CSS should be used to handle long words; I meant that if you have the word “Corporation” in a pixel-width box, and make the text bigger in the still-extremely-common last generation of browsers, or even Chrome, it will bleed over the edge, unless you overflow: hidden, I suppose. (The New York Times’ site always comes to mind.)

    Two things which are, in my experience, true: people change the text size, and lots of people still use IE6 and Firefox 2.

    Maybe you can choose to ignore the needs of that audience. I can’t. Especially in light of the Target vs NFB settlement in this country.

  22. @Emil: There’s no arbitrary, universal limit for word-length. But long words don’t wrap when you scale the text in a fixed-width box (pixels or percent). Use ems or another flexible-width measurement.

    I’m not worried about default behavior. Hopefully the design properly handles all the text at its default size (or you can manually hyphenate). I’m worried about what happens when you hit ctrl +.

  23. @James Socol: I understand what you mean. My argument goes like this: You don’t know what text people will put on the site (it changes all the time). You have to somehow select what font-size you want to support, by looking at some sample text and guessing. If you still do that, it’s not that hard to pick a pixel size that handles two zoom levels well, and stick with that. If it saves lots of time, you can focus on hacking .NET to make it accessible instead. It’s all about priorities.

  24. @Emil: Two zoom sizes is not enough. And since this is about not “wasting time,” why write functions to scale the text to your predetermined sizes when you can just use scaling layouts? Surely wasting time in .NET (or whatever else) is as bad as wasting time in HTML and CSS.

  25. @James Socol: is it never enough? I’m not talking about writing functions to accommodate for just a couple of zoom levels, I’m talking about using scaling layouts, but don’t care if it breaks when you zoom too much. When something like that is enough or not is determined by the project and is not something general you can decide without a context.

  26. @Emil: Accessibility is general, at least not in the US. The National Federation of the Blind vs. Target settlement, while not the strong precedence of a ruling, still sets a legal precedent. Everything needs to be accessible or is open to suit.

    Now, maybe you can say the risk of law suits is minimal, or you’re too small to care, or you just don’t care. But if you use ems, it will scale by itself, so it can’t zoom “too much.”

  27. @James Socol: Well, it seems our ways of looking at accessibility are different. I’m very much against the notion of forcing accessibility by the law. People just following the law will make a shitty job.

    We seem to also have different ideas about how to make a scaling layout. It’s not just about throwing some ems in there. But we’re not getting anywhere with this discussion, so lets just concentrate on something else. Thanks!

  28. Since there are so many layout tricks out there now, especially using layered Div’s combined with tables even can be very effective. Once you find your grove and what works best for you, go for it…

  29. These are excellent tips, I think that helps a great deal is having a reset css file. If some of you readers haven’t heard of those, it is a css file that will set all your html element margin and padding to 0. Having everything set to 0, then you can decide how much spacing everything needs, instead of the browser.

  30. Hah! I never thought I’d see the day when someone would finally post this about our lovely html…

    makingcolor staff

  31. Yep, this is what I recommend to my associate too..he’s wasting way too much time on CSS for every round corner to have a nice time. And when you’re done doing everything and you see that an IE6 just cannot run your new designs, you need to start doing “the hard job”. I strongly believe that Internet 2.0 is more and more affected by the state of simplicity. All good websites have clear CSS and HTML structure. Few succeed in their way for always improving their product, as it simply gets more complex.

    The Anonymous above me gave an excellent advice, ty for sharing it mate!

Comments are closed.