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.
So.
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?
trobrock (2 comments) ( 10 Jul 2008 )
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.
Jrf (4 comments) ( 10 Jul 2008 )
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
Jrf (4 comments) ( 10 Jul 2008 )
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.
Charlie Park (2 comments) ( 10 Jul 2008 )
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.
Charlie Park (2 comments) ( 10 Jul 2008 )
(That was supposed to be “div#intro”, but you know what I was getting at.)
Emil Stenström (561 comments) ( 10 Jul 2008 )
@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 < instead of starting angel bracket.
@Charlie Park: ah, I knew I forgot about one important point. I also have a CSS structure I use.
James Socol (8 comments) ( 10 Jul 2008 )
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.
Heather (1 comments) ( 10 Jul 2008 )
Interesting read, even though I was a little taken aback by the headline. Great tips to help streamline the process.
Stephen (1 comments) ( 10 Jul 2008 )
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.
zcorpan (19 comments) ( 10 Jul 2008 )
Looks fine in Opera, Firefox 3 and IE7.
James Socol (8 comments) ( 10 Jul 2008 )
@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.)
Emil Stenström (561 comments) ( 10 Jul 2008 )
@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 :)
James Socol (8 comments) ( 11 Jul 2008 )
@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.
Rasmus Kaj (16 comments) ( 12 Jul 2008 )
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! :-)
Tyler (1 comments) ( 18 Jul 2008 )
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.
Tyler,
http://www.whatdivs.com
David McNorton (2 comments) ( 20 Jul 2008 )
Excellent tips!
ask (1 comments) ( 22 Jul 2008 )
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.
Emil Stenström (561 comments) ( 28 Jul 2008 )
@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!
Rasmus Kaj (16 comments) ( 28 Aug 2008 )
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.
Johan (20 comments) ( 1 Sep 2008 )
- File versioning to improve workflow (simply a last modified date hard-coded can be a good start)
- Reusing code blocks
Justin Ferrara (1 comments) ( 2 Sep 2008 )
Thanks for the tips. I’ve found that tip #3 is very helpful when developing larger web applications, especially frameworks.
chrisco (1 comments) ( 3 Sep 2008 )
Hi Emil,
Found your blog through a link on the Geek Meet Stockholm page. Glad I found it :)
Thanks,
Chris
BuzzPal.com/Team
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.
Emil Stenström (561 comments) ( 4 Sep 2008 )
@chrisco: Sorry, I’m not looking for another job at the moment. Please don’t use my comment board as an advertising system.
James Socol (8 comments) ( 5 Sep 2008 )
@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.
Emil Stenström (561 comments) ( 6 Sep 2008 )
@James Socol: So what do you propose? Which are the longest word you will allow in your boxes? No limit?
James Socol (8 comments) ( 8 Sep 2008 )
@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 +.Emil Stenström (561 comments) ( 8 Sep 2008 )
@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.
James Socol (8 comments) ( 22 Sep 2008 )
@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.
Emil Stenström (561 comments) ( 22 Sep 2008 )
@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.
James Socol (8 comments) ( 22 Sep 2008 )
@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.”Emil Stenström (561 comments) ( 23 Sep 2008 )
@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!
Denver Web Development (1 comments) ( 19 Dec 2008 )
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…
Anonymous (5 comments) ( 7 Apr 2009 )
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.
Justin (2 comments) ( 24 Jun 2009 )
Hah! I never thought I’d see the day when someone would finally post this about our lovely html…
thanks,
makingcolor staff