Website interfaces often require a large starting point to get going. You’ll need to spend some time planning out a design style or simple prototype in advance. But how do you go about starting the HTML5/CSS3 development cycle?
In this article I would like to share a few tips and tricks for coding a spectacular frontend. Web development has never been easier to learn, but there are also a lot of ideas to follow along with. Experienced developers know what to look for and how to construct their pages for easy readability. These models are great to use not just for your own personal projects, but also on collaborations and with open source code releases.
Make your Documents Simple
This is my golden rule which I cannot pass onto enough developers. There is a tendency to overuse HTML elements and implement a lot of different classes within your markup. However I feel that any amount of space saved will improve the final result.
For example, most of my core div IDs are composed of the fewest letters possible. I’ll use #w for my wrapper div since it’s a quick reference and easy to identify. I would suggest carrying this method further into your CSS classes, because those are often used repeatedly in a webpage.
As another example I will often use .c for my container classes. These are often set to a maximum width and contain internal elements within a layout. Utilize this naming scheme to the point where you can still quickly recognize the conventions without becoming overly confusing. Obviously the class .tag is still shorter and easier than .linktag or .linkTag.
Data markup should also be fairly straightforward and easy to scroll through. Use HTML elements where they are appropriate – list items for lists, code/pre tags for source code, and tables for displaying tabular data.
Perform Browser Checks
This rule should be relative to your layout but still pertains onto all web developers. When you’re coding a website layout it’s commonplace to initially test your changes in a single browser. This is just easier since you don’t want to open 3 or 4 browsers after every little change.
But it’s important that you do take the time for browser-specific updates and bug fixes. You would be surprised how many valid HTML5 layouts will still break when ported over into Safari, Opera, or IE9. A good strategy is to build your layout to fit perfectly into whatever you normally use for a web browser. Then after you feel the job is complete enough go back and run some tests in all the other various rendering engines.
My default list includes Google Chrome, Mozilla Firefox, Internet Explorer 7-9, Opera, and Safari. If you are building a responsive layout it’s not a bad idea to check on mobile browsers, too. Both iOS and any Android smartphones will have different screen resolutions. These come into play if your responsive media queries aren’t implemented correctly.
Frontend Code Validation
This isn’t a requirement in the coding process but it’s nice to get into the habit of validating your webpages. The newest models do not cater to every meta tag and older XHTML specifications, so it’s common to find errors in your validation. But keep in mind this doesn’t mean your website is improperly coded. And it definitely doesn’t mean you must go back and “fix” your code.
For some clients these validation services may be mandatory. Not everybody will care about these labels since they are exactly that – just a label. But for those interested here is a nice HTML5 validator put out by the W3C(World Wide Web Consortium).
The W3C is full of people who debate the rules for new specs such as HTML5 and CSS3, so their website is certainly an authority on development techniques. They also have a CSS Validator if you want to give that a shot, too. There are many properties which will return an error such as -webkit-text-size-adjust. This is completely valid for mobile webkit browsers, and although it’s just an example you should try to ignore these egregious blacklistings of vendor-specific prefixes.
Learning from Past Mistakes
I think we all make mistakes at times because we’re only human. But mistakes come with the responsibility of admitting you were wrong and changing your techniques in the future. Not everybody will do this last step, and so they’ll continue making the same mistakes repeatedly.
It can be rough to accept there are parts of a website layout that you’ve completely overlooked. It can be helpful to have a couple web developers who you trust look over any skeptical source code. There are times when you’re staring at a project for hours and just cannot find the problem. It has happened to me a number of times and the quickest solution is often through a third party.
If you are not familiar with Stack Overflow then I definitely recommend setting up an account. You can register with an e-mail/password or through another service like Twitter or Google. OAuth is a very secure method since it’s one-click login without memorizing another password. The community is extremely helpful and very intelligent on a number of languages.
But my final point is to never get discouraged and never give up! Other developers are usually very friendly and happy to offer support where possible. Just be sure you can learn from other devs and take their lessons to heart. In a big world there will always be people with more knowledge on these topics. Advancing your education is all about what you do with this knowledge and how you apply any new found skills into your future projects.
Related Links
- 40+ Useful HTML5 Examples and Tutorials
- New HTML5 Tutorials on Frontend Development Techniques
- Be A Creative Developer Using HTML5 Tutorials
- Powerful New CSS Techniques and Tools
- Awesome CSS3 Generators to Simplify Frontend Development
Final Thoughts
Web development encompasses such a wide spectrum of languages and server knowledge. You really do need to spend a long time studying techniques and practicing your ideas before you will feel completely comfortable. But what a better time to advance your knowledge than right now?
I hope this article can offer just a few ideas to get you focused on bare-bones frontend development. HTML5/CSS3/JS are all individual languages within themselves. But as you go through the process to learn each one you’ll understand how they fit into the grandiose schematic for brilliant websites. Along with my suggested links feel free to share your own ideas with us in the post discussion area below.
“I’ll use #w for my wrapper div since it’s a quick reference and easy to identify”
Seriously? Really?
[sarcasm]
Because a year or two later, when another developer picks up your work, the letter “W” makes lot of sense.
[/sarcasm]
I can only imagine how much time I could possibly spend/waste trying to decipher the ancronyms in your code and the committing them to memory. If your code is not Self-documenting (https://en.wikipedia.org/wiki/Self-documenting), then I hope you are backing up your work by other means.
I would disagree because I’ve never had anybody confused with the purpose of a wrapping div. You could give it the div ID #acorn and its purpose should still be obvious to skilled developers.
Classing and documenting your code is usually for your team and yourself. If you can’t read your own code then maybe it’s time to change the formatting! However, I feel that shortened class names do actually save time especially when they need to be repeated many times in the same document.
Agreed. I do a lot of websites, and sometimes I need to get back to them, and I always name my wrappers the same in all my projects and they all have the same logic behind them so it is really easy for me find stuff.
But I also name things so that programmers can easily understand what div does what and so forth.
You can’t take short cuts like that.
recently getting more and more dissapointed with WDL posts… 🙁
I agree.. Every class or ID used in HTML elements should be easy to remember. Using one letter, such as “w” for ID is really not a good practice. “w” can means “well”, “wrapper”, “widget”, “white”, or else. Too random!
Learning from past mistakes? Easier said than done, really!
I get the “learning from past mistakes”. I will say it’s a good habit to document some of the pitfalls you run into for future reference so you don’t spend time on them again in the next project.
I ran into a problem with a drop down not showing up despite using z-index in IE7. I didn’t document the problem, I fixed it, but I ran into it again. After this happening twice, I made sure to add a note in my CSS framework. Now I learn from my mistakes in code instead of repeating them.
“And it definitely doesn’t mean you must go back and “fix” your code”…. …however, it’s more along the rock star path to have fixed code!
HTML 5 is not the norm yet; it’s new, fresh both a buzz concept and practical but it’s not required either so there are literally millions of web pages out there not using HTML 5 of which most versions of IE benefit from having validated html as will Safari and even, in some cases, Firefox.
The doctype is vastly misunderstood by most developers. It’s not just a determining factor of what kinds of tags one uses, it tells the browser how to render a page so I would say validate as a best-practice step and only skip errors that specifically relate to an odd-ball link using asp! (always encode ampersands)
Especially if you ever have to code html emails!
Thanks for useful tips!
Inspired 🙂