AmberWeinberg.com » CSS http://www.amberweinberg.com Design, Development and Freelance Articles and Tutorials Tue, 07 Sep 2010 14:30:02 +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?

Related Posts You Might Like

]]> http://www.amberweinberg.com/xhtml-css-for-mobile-development/feed/ 9 Teaching Graphic Designers About The Web http://www.amberweinberg.com/teaching-graphic-designers-about-the-web/ http://www.amberweinberg.com/teaching-graphic-designers-about-the-web/#comments Tue, 17 Aug 2010 14:30:58 +0000 Amber Weinberg http://www.amberweinberg.com/?p=3324 I was listening to episode #53 of SitePoint’s podcast when they mentioned that old “should designers code?” debate. While I don’t want to beat a dead horse, SitePoint made a great comment – that perhaps someone should figure out how to write a book on how to teach graphic designers how to do web design. After all, merely telling them to look at the code isn’t going to help them.

This got me thinking. I would love to write this book considering that I was trained to be a graphic designer in college, have been coding since middle school and worked as a web designer for a few years. Who better to write this book that someone who’s been on every side?

Unfortunately I’m pretty busy so I don’t think I’ll be writing one any time soon. So I thought I’d spend some time today thinking about some advice I’d give a graphic designer who wanted to move into the web. Here goes.

The Grid is More Important on the Web

Graphic designers love using the grid, so a web-based grid shouldn’t come as a surprise to them. However, grids for web design are much more different than a regular design grid.

Unlike print design, you never have set dimensions. For example, a print designer might be doing something on an 8.5×11 sized paper. On the web however, some people might have 3″ screens, or they might have 30″ monitors and you have to cater to both. Also, there’s technically no limit to how long a web page can be, unlike a real page of paper.

You also run into coding and browser issues when designing off a grid. When designing a website, remember that coded elements can only be rectangle shaped. A developer can’t code a rounded element.

There’s More Than One “Printer” On the Web

When designing for print, you need to know the printer you’re going to use’s type of paper, ink and requirements for files. That’s it. One the web however, you have to remember different screen sizes, different browsers, even the same browser on different operating systems. Plus now we have mobile devices like the iPhone and the *gay* Droid and larger mobile devices like the iPad. Your site should ideally be able to work on all of them with or without mobile versions.

Don’t Squeeze

Unlike print, you don’t have to squeeze every bit of info on one page or in one area. You can set multiple pages in a site, dropdown menus, sliders and tabs to hold extra content.

This means that the website also isn’t static. Unlike paper you can have things moving around, you can change the appearance on the site based on page load or type of browser agent.

Too Little Decoration Please

In print, everything costs extra. Even colors. A two color print costs much less than a 3 or 4 color print. Embossing, gloss, even the type of paper you choose in your design can add up quickly in cost. This isn’t necessarily true in web design though. You can add all sorts of cool effects and decoration to the site design-wise and it won’t cost any more.

Because of this, I’ve seen a ton of print designers who pile on every rounded corner, gradient, swoosh or anything else they can. Please stop!

You Thoughts

What’s some of the advice you’d give to a graphic designer who wanted to move into the web?

image by Ross Catrow

Related Posts You Might Like

]]> http://www.amberweinberg.com/teaching-graphic-designers-about-the-web/feed/ 38 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

Related Posts You Might Like

]]> 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

Related Posts You Might Like

]]> 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 »

Related Posts You Might Like

]]> http://www.amberweinberg.com/35-books-all-freelance-web-developers-should-read/feed/ 0 Overcoming The Fear of HTML5, CSS3 & New Things http://www.amberweinberg.com/overcoming-the-fear-of-html5-css3-new-things/ http://www.amberweinberg.com/overcoming-the-fear-of-html5-css3-new-things/#comments Wed, 14 Jul 2010 14:30:53 +0000 Amber Weinberg http://www.amberweinberg.com/?p=3121

I’ll let you in on a little secret – I’m afraid of learning and using HTML5. And you know what? I bet you are too.

Why would a professional developer be afraid of a much needed upgrade to her favorite language? It seems that fear of the unknown is common among humans and none of us ever like change. Change is scary. Change is bad.

The Development World Is Changing

But then I remembered that eight months ago, I was afraid of letting IE6 go. I was afraid that if I stopped packaging IE6 as a browser I natively supported, that I would lose business. No one would come to me for web development. but I knew the choice I was making was the right one. IE6 usage is not common anymore. We spend too much time developing for it, and continued dev support would only prolong the life of the browser. It was time to move on.

Then around 5 months ago, I was afraid of learning CSS3. Just looking at some of the new features was proof enough that CSS3 was very different from CSS2. There were tons of new selectors to learn, new graphical effects to memorize and practice with. Plus, although most of the main browsers supported the main CSS3 features, you were (and are) forced to learn browser prefixes. Not fun.

But I’ve been using CSS3 regularly now, and what has it done? It’s sped up my development time. It means less slicing, less divs and cleaner, leaner, quicker development.

I find it funny when people tell me that they “don’t want to use CSS3 because IE doesn’t support it”. But you know what? No one notices that rounded corners or shadows are missing from my websites in IE. Basically, no one who would use IE would care anyways. I think these developers are just scared to use something new. Of course, if the rounded corner or effect was pivotal to the design, then sure, use images. Otherwise, what’s the point?

I’m really in love with progressive enhancement, you know?

The Price of Standing Still

Of course we don’t have to learn CSS3 or HTML5 or any other “new” thing in the web development world. You know, there are still developers out there coding unsemantically, with 100 validation errors per page and in tables. Who needs CSS, right? I remember when CSS first came out, developers thought it was going to be a fad! Now look at us.

You don’t have to learn anything new than what you know right now to make some money. But if you want to be anything more than mediocre in the web world, you need to keep up. And keep up daily.

The web changes everyday, which is why it’s important to follow several different blogs, news sources and social media sites. You should always have several books on hand to read from. You should always read about areas related to your field. If you’re a web developer that means design, marketing and UX. Learning from these different mediums will fundamentally change the way you structure and layout your code. It also helps you to understand the web in general. Believe me, you can certainly tell the difference between the developer who only pays attention to code, and the one is who pays attention to everything.

Starting Something New

So what do we do now that we’re ready to start learning? Take a deep breath, relax and start slow. Rome wasn’t built in a day, neither was HTML5.

The way I learned CSS3 was to start with something simple – say the rounded corners. I tried that, learned it as well as I could. Then I tried text-shadows, then some advanced selectors, then some box-shadows. Pretty soon, I was using almost everything regularly, and know the spec of CSS3 well.

That’s how I’m going to start HTML5. My HTML5 for Web Designers book FINALLY came in and it’s pretty small. As soon as I finish reading and reviewing this other web dev book, I’ll be starting this one (and a review to come I promise!). Then I might use it on a site or two (I’m  honestly in love with XHTML though).

Your Thoughts

How do you approach the “new” in the web world? With anticipation? Apprehension? How do you get over your fear?

image by epSos.de

Related Posts You Might Like

]]> http://www.amberweinberg.com/overcoming-the-fear-of-html5-css3-new-things/feed/ 32