AmberWeinberg.com » HTML http://www.amberweinberg.com Design, Development and Freelance Articles and Tutorials Thu, 09 Sep 2010 14:37:37 +0000 en hourly 1 http://wordpress.org/?v=3.0.1 XHTML & CSS For Mobile Development http://www.amberweinberg.com/xhtml-css-for-mobile-development/ http://www.amberweinberg.com/xhtml-css-for-mobile-development/#comments Tue, 07 Sep 2010 14:30:02 +0000 Amber Weinberg http://www.amberweinberg.com/?p=3427

If you follow me on Twitter or on Facebook, you’ve probably heard me talk about the mobile site I’ve been developing for Amazon Audible.

The mobile site consists of over 50 mockups that needed to be developed in HTML/CSS and made to work for the iPhone, Android and Blackberry. While coding simple HTML/CSS mockups sounded pretty easy, I found that there were several hurdles and differences from doing mobile HTML and normal HTML.

Doing a mobile site from scratch was a big learning experience, so I’d thought I’d share some of the things I learned, that differed greatly for mobile dev.

Think Small

Doing mobile development means you have to think small and in terms of percentages, not pixels. You can’t have a 320px layout for the iPhone, because if you rotate the phone into landscape mode, you’ll have a skinny site running down the middle. You have to make sure the layout stays consist, while expanding for both portrait and landscape modes on the phone.

CSS3 Wonders

One of the biggest changes that were difficult for me to get over, and one of the best, was the fact that I could use CSS3 freely. I no longer had to worry about Internet Explorer, and al of the prominent mobile devices support it.

When trying to do some tricky styling without adding additional markup, I caught myself remembering that I could actually do it with nth-of-type and not having to worry about it breaking! So feel free to break out your CSS3 and even some of your HTML5 skills.

Special Meta Tags

There are a lot of little quirks in some mobile devices, but since I have an iPhone I’ll mention the ones I found in that device. The iPhone has this neat trick, where it links phone numbers in the browser and allows you to click on them and call them instantly.

This is awesome, except for the fact when it tries to do it on non-phone numbers. It seems to have difficulty sometimes determining what is and isn’t a number, especially when it comes to things like part/order numbers.

The awesome thing about Apple, however, is the fact they came up with a ton of meta tags that allow you to manipulate the way the iPhone device reads the website. I think these tags may also work on the Android, but don’t quote me on that.

To disallow the linking of phone numbers of your site, simple add this in between your <head> tags:

<meta name="format-detection" content="telephone=no">

I also ran across a problem where the iPhone likes to blow up the size of text in landscape mode, which was obviously a no-no and broke our layout. This was fixed simply by adding this style to the body property:

body { -webkit-text-size-adjust: none; }

The IE of Mobile

Of course, there’s always something that has to make a developer’s life difficult, and in this case it’s Blackberry. While it’s not as bad as Internet Explorer, it still became a thorn in my side.

Apparently, some models of Blackberries don’t support CSS3 properties, like opacity. I haven’t had any problems with advanced selectors though, so I’m not sure what is and isn’t supported.

The Blackberry also seemed to interpret spacing and paddings differently from the Android and the iPhone. For the most part, besides a few text differences, the Android and iPhone were quite similar in rendering the site.

Browser-Testing

Browser, or device, testing for mobile is a bit more difficult to do than normal web browser testing. While you can download pretty much al of the web browsers if you’re on a Windows machine (or use a simulator on a Mac), I’m fairly sure most devs don’t have an iPhone, Android AND a Blackberry.

For beginning testing, it was enough to resize my Firefox window as small as possible, but most of the testing I did on my iPhone, especially because the iPhone renders inputs and some backgrounds and paddings quite differently than Firefox.

For Android and Blackberry testing, I had to rely on the help of several of my Twitter friends (thanks guys!). A lot of the simulators you can download, especially the iPhone ones, never seem to actually renders the site like the actual device would. The client also had access to all three devices, so there were a big help in finding bugs.

Teaching the Client

The problem with percentage based designs, is that it’s impossible to have it “pixel-perfect” with the mockups, because you’re not using pixels. This was something I discovered early on, and something I had to teach the client about as well, especially because they had handed me size guides with the exact pixels everything was spaced out to.

This is a bit difficult to explain to a client who wants the mockups to look exactly the same in portrait and landscape mode, but with a little persistence and documentation, it wasn’t impossible for them to become relaxed in their layout expectations. You just have to be a bit more fluid when it comes to the mobile world.

Progress

I haven’t completed all the mockups yet, but you can check out the progress on the mobile site I’m working on for Audible for the next week or so before it’s taken down to become live.

Your Thoughts

What are some of the differences and difficulties you’ve experienced while coding for mobile sites?

]]> http://www.amberweinberg.com/xhtml-css-for-mobile-development/feed/ 9 Building Findable Websites http://www.amberweinberg.com/building-findable-websites/ http://www.amberweinberg.com/building-findable-websites/#comments Mon, 16 Aug 2010 14:30:41 +0000 Amber Weinberg http://www.amberweinberg.com/?p=3315 Building Findable Websites by Arron Walter is one of the best books I’ve read on the subject of SEO, web standards and accessibility in the world of code.

Aimed specifically to developers, Building Findable Websites is 264 pages based on several topics. This isn’t a regular SEO book, but teaches “findability” through good coding practices, including best practices for Flash, Javascript and AJAX. It also includes basic SEO information on keywords in titles, alts and density.

I skipped over a few sections because it included basic information I already knew or beginners info on things like using Feedburner, but I still found a ton of relevant material to keep me interested.

The book has a ton of resources and code examples and even gives access to several bonus chapters on online.

You can find Building Findable Websites on Amazon for $30.

]]> http://www.amberweinberg.com/building-findable-websites/feed/ 8 Common Mistakes Front-End Developers Make When Coding http://www.amberweinberg.com/common-mistakes-front-end-developers-make-when-coding/ http://www.amberweinberg.com/common-mistakes-front-end-developers-make-when-coding/#comments Wed, 04 Aug 2010 14:30:57 +0000 Amber Weinberg http://www.amberweinberg.com/?p=3271
I’m by no means perfect when it comes to web development, however I always strive to improve my code with each new site I make.

I’ve noticed a lot of common mistakes made by both beginning and advanced developers (including myself). While some of these mistakes may seem trivial, they go a long way to making the difference between the average developers and the great ones.

Let’s take a look at these mistakes and discuss why they’re bad.

Using <br/> Tags To Space Divs

This practice was something I used to do often back in the table layout days, but sadly the practice hasn’t died out among the development community. When editing other developers’ code, it’s still fairly common to see developers using
<br/> tags instead of margins or padding.

While the document will still validate, this isn’t a good practice. Browsers render spacing inconsistently, so your layout will end up being off in each one. It also muddies up your HTML and crosses the line of separating structure from presentation.

Using Inline CSS

I was hoping that with the recent popularity in semantics and the separation of structure and design, that the practice of using inline CSS would disappear. It hasn’t

Not only does inline CSS complicated your HTML, but it also defeats the purpose of CSS itself, which is to have one place to keep your styles so the site remains easily updatable. It can also penalize you SEO-wise by making it take longer for spiders to download your website, since they have to navigate through CSS (which they can’t use). Inline CSS also won’t validate if you’re using XHTML 1.0 Strict, which brings me to…

Using A Transitional Doctype

Using a transitional doctype is akin to that annoying friend of yours who can never make up their mind between two choices. Basically, a transitional doctype is halfway between the last and the next doctypes.

If you’re going to be a developer, be a good developer. Transitional doctypes let you get away with rookie mistakes like inline CSS and other presentational markup that have no place residing in your HTML.

Putting Full CSS and Javascript in The Header

You should always try to avoid putting actual CSS in your HTML, even if it’s in the header where it validates. Remember, design should be separate from markup. The only CSS you should have in your header is the link to the external stylesheet itself.

A lot of beginners (and annoyingly enough, WordPress plugin developers) put their Javascript in their header. While this isn’t technically wrong code-wise, it can seriously slow down the loading of the page, especially if you have multiple scripts. Place your scripts in the footer of your site, so the rest of the site can load before your JS. While it might not make a noticeable difference on small sites, it can really speed a larger one up.

Containers Within Containers Within Containers Within…

I think some developers are scared silly. Scared that if they don’t use six containers for that left content area, the whole site will blow up and the internet will point and laugh at said developer.
This can also be classified as a form of divitis, but it’s actually worse – it’s container divitis.

No, you do not need that many containers, when normally one or two should be the most you ever need.

Of course, there are always exceptions. I once had a client that had a ton of expanding rounded corner boxes within each other and they all had to work in IE6. I finally made the decision to drop support for IE6 after that one…

Tables, IE6 and Other Dead Things of The Night

People have always been fascinated with monster and the undead and developers are no exception. We love dead things like tables for layouts, making sites work in IE6 and other practices that should’ve been laid to rest long ago. Just stop already ok? There’s never a happy ending, you’ve seen the movies.

Who Needs Validation?

There are those out there who think validation is stupid and pointless. Well I think they’re stupid and pointless. Validation gives you a proper standard to hold your code to, helps prevent browser rendering issues and makes you responsible for that rat’s nest you call a website.

I don’t think I’ve ever seen any developer who doesn’t validate have good, clean, semantic good. They don’t exist.

Not Properly Indenting or Spacing Your Code

While the actual structure of your code is mostly up to you and what makes it easier for you to read and develop under, your coding structure should at least contain some sort of consistent indention and spacing.

I can’t tell you how many times I’ve viewed code with no indention, too many indentions (i.e. code goes off the screen with indents when it’s parent element is indented only once) and about 50 returns between one element and the next. This is not only very, very ugly, it increases file size and makes it near impossible for the next developer to figure out what’s going on.

Thinking HTML and CSS Are “Easy”

I’ve heard some developer “experts” claim that HTML and CSS are easy and everyone should know how to do them. This is not only a HUGE annoyance to front-end developers like myself, it’s also untrue.

Yes, learning the basics of CSS and HTML are pretty easy compared to backend languages. However, becoming an expert in HTML and CSS is NOT. I know plenty of backend programmers who know several languages, but still can’t write clean, semantic HTML. Nor can they figure out the basics of validation (or write a simple paragraph without 100 errors).

Anyone can change font colors. But it takes a real expert in front-end development to code a complicated site from scratch that’s validated, clean, semantic and cross-browser friendly in under a few hours without looking. So no, real HTML and CSS isn’t easy.

Picky Picky Picky!

I’m very, very picky about the way HTML and CSS is written, because this is what I’ve spent most of my like trying to perfect. I think it’s important to hold yourself to the highest standard no matter what you do. As mom always said, :if you’re going to do it, do it right the first time.”

Your Thoughts

What are some of the coding mistakes you or other developers you’ve noticed make?

image by Foxtongue

]]> http://www.amberweinberg.com/common-mistakes-front-end-developers-make-when-coding/feed/ 50 The Difference Between $150 and $700 http://www.amberweinberg.com/the-difference-between-150-and-700/ http://www.amberweinberg.com/the-difference-between-150-and-700/#comments Tue, 03 Aug 2010 13:00:08 +0000 Amber Weinberg http://www.amberweinberg.com/?p=3243 I’ve always been curious as to how much money those cheap PSD to XHTML companies make. It seems impossible that they make a ton of money by only charging $150 per site, plus I’ve noticed that they always take out big ads on large blog sites that charge over $600 a month per ad.
This also leads me to another thought – just how good can their code really be for only $150?
I went through several of these PSD to XHTML sites, looked at the source code of both their sites and their portfolios, and here’s what I’ve found.

It’s Raining Scripts!

One thing I can’t figure out is why all of these sites insist on having 10+ scripts in their header. Is really necessary? Have they heard of optimization or minifying their JS?

Divitis

While several of these sites claim to have “handwritten” code, I really find that hard to believe. They always look like they’ve been run through those slice n’ dice programs. The div names are always funky and generic. They contain divs wrapped around divs wrapped around some more divs. Most of these seem to come from some kind of template.

Weirdo Meta Tags

One of the sites I viewed had the weirdest meta tags I’d ever seen, a bunch I’d never even heard of. It’s like they read a beginner’s HTML book from 1994 and decided to use everything the book talked about, whether necessary or not.

IE Or Bust

All of these sites used IE hacks, which meant that none of these developers really know how to properly code, especially since almost ALL of the hacks were for IE8! IE8 is the easiest IE browser to code in, and you normally shouldn’t have any problems with it if you’re coding correctly.

Go To Class

Not everything needs a class, but according to these sites, everything must have some kind of class or ID. While it seems marginal, you should always try to use the cascade to style your elements, instead of classing everythin. Not only does that save on file size, but reduces confusion and mess in both your HTML and CSS.

Validation

The best part of all of these sites – most of them were validated, and in XHTML Strict no less. Kudos to them.
But validation isn’t everything. Semantics is just as important and is something missing in all of the PSD to XHTML sites. Someone please tell me what the divs “b-box” and “c-150″ are supposed to do?

Logoworks and Factories

These PSD to XHTML places remind me a lot of Freelancer.com, Logoworks and other crowd-sourcing factory type sites. Sure, you’ll get the work done quickly and cheaply, but you’ll sacrifice in quality and it’s very, very noticeable.

The Difference

Which brings us here – so what’s the real difference between us (the good developers) and them? We’re not a factory. We don’t churn out the same junk over and over. We learn and improve our code with each site we make. We pride ourselves on using the least code possible while maintaining semantics, validation and accessibility.
We don’t hide behind a web form. Clients can find us and talk to a real person and ask questions, instead of simply submitting a design on one end, and having a template spit out the other.
This is why the best clients will always pay more for us.

Your Thoughts

What do you think about these PSD to XHTML places? Worth the price?
image by ecastro

]]> http://www.amberweinberg.com/the-difference-between-150-and-700/feed/ 28 35 Books All Freelance Web Developers Should Read http://www.amberweinberg.com/35-books-all-freelance-web-developers-should-read/ http://www.amberweinberg.com/35-books-all-freelance-web-developers-should-read/#comments Fri, 30 Jul 2010 14:30:59 +0000 Amber Weinberg http://www.amberweinberg.com/?p=3215

If you follow me on Goodreads, you know that I absolutely love to read. I’ve always been a big reader, but since I’ve become a freelance I’ve made sure to read even more than usual, in the field of business, development and the web in general.

Reading is essential to any developer’s improvement. While blogs and magazines are great to read for a quick update, nothing replaces a good informative book. Even though web development isn’t the most interesting topic to read about, I’ve been able to find a lot of interesting and informative books over the years that have helped me to improve both my dev and business skills.

Read the rest of my post on FreelanceFolder »

]]> http://www.amberweinberg.com/35-books-all-freelance-web-developers-should-read/feed/ 0 Review of HTML5 For Web Designers by Jeremy Keith http://www.amberweinberg.com/review-of-html5-for-web-designers-by-jeremy-keith/ http://www.amberweinberg.com/review-of-html5-for-web-designers-by-jeremy-keith/#comments Mon, 26 Jul 2010 14:30:50 +0000 Amber Weinberg http://www.amberweinberg.com/?p=3179

HTML5 for Web Designers by Jeremy Keith is a quick and informative 85 page mini-book all about our favorite development topic, HTML5. The book took me a couple of nights to read, but only because I was super short on time, so anyone could easily read the whole book in one or two sittings.

The layouts of the book were nicely designed, the images are clear and crisp and the text is really easy to read. The book is smaller than you’d think, but comes jam packed with a lot great information and little fluff.

The Bad

I normally don’t start off with the bad points, but I feel it’s necessary here as I was extremely disappointed with the way this book was handled.

First off, I preordered my book the day of, or shortly after, preorder become available. Therefor, I expected to be one of the first people to get the books. I wasn’t. In fact, you could’ve ordered your book a week after it was released and gotten it way before me. It took over THREE weeks from the date of release to get my copy.

Also, when the copy came in, it was banged up, the corners were bent badly and the cover was cheap (a drop of water has literally disintegrated the cover). For $18+ I really expected something of higher quality, especially since it’s a paperback. These fudge ups remind me of the sad Smashing Book.

The Chapters

  • Chapter 1: A Brief History of Markup - My favorite part of the entire book actually had nothing to do with HTML5, but the first chapter. The first chapter was full of really interesting tidbits on the history of markup and the W3C and why XHTML 2.0 failed. It was really, really interesting (to me at least). The chapters in the book were hilariously named after oldies music. It was a really easy and pleasant reading, although HTML5 specs tend to bore the crap out of me.
  • Chapter 2: The Design of HTML 5 – Another great “history” chapter that deals with how HTML5 came to be, what it aims to do and the basics of what the creators were thinking when dreaming up the billion page spec.
  • Chapter 3: Rich Media – To be 100% honest, I’m not too crazy about media in HTML5. Never been too crazy about media ever. eh.
  • Chapter 4: Web Forms 2.0 – For some reason, this chapter made me super excited about HTML5 web forms. Maybe because it makes complicated forms so much easier thanks to the fact you no longer need jQuery for everything.
  • Chapter 5: Semantics – This is a very important issue to me. I’m disappointed that HTML5 takes a lot of the cleanliness out of what XHTML 1.0 forced us to do, but at least semantics are getting better. Not 100% happy with a bunch of this stuff, who uses microformats anyways?
  • Chapter 6: Using HTML5 Today -The most useful chapter was the last one, where it talks about how we can use HTML5 today. Definitely interesting. Have been wanting to try my own HTML5 site for awhile now, but just haven’t gotten the time :(

Must Buy?

Definitely. The book is $18 plus shipping and can be bought at A List Apart.

]]> http://www.amberweinberg.com/review-of-html5-for-web-designers-by-jeremy-keith/feed/ 7