|Professional Services||Second Signal||Presentations||Andrew's Blog||Support|
So called "Designers" take their artsy-fartsy training with Adobe Illustrator or Photoshop to create "Mockup" pages, then ask us as developers to make web pages that look the same way. Sometimes I think they don't really know when what they're asking us to do is particularly difficult.
These are my tips to "Designers" -- I hope they'll understand what they're asking us for.
I realize that these are "best case" recommendations. Sometimes you want color fades or other things for the look they achieve. Its a trade off. I just want the designers to understand when they're making that trade off, so they can decide if its worth it. There are combinations of images and overlays and tricks we can do to make it appear that these things work, but they all take a lot more time and limit the overall flexibility of the page for growing based on browser width or content size.
1. Solid Color Choice
In Illustrator, you can choose a color from a palate of process colors. The web doesn't have these. The web uses only RGB colors. Even then, some combinations are more "web safe" than others, meaning they'll appear the same on a wide range of monitors. Here is a specific list of the "most safe" ones: http://www.w3schools.com/html/html_colornames.asp. When you use a color in Illustrator that is a "Process Color", as a developer I have to try to find the closest RGB conversion to match that process color. Sometimes its easy, sometimes it isn't. It would be even more helpful if you could provide an editor's mark at the side of the page -- perhaps as an overlay layer with arrows pointing to specific details on the page -- that showed clearly the RBG color code you've chosen. The problem with "process colors" is that they'll look very different on each person's screen even in Illustrator. They're meant to look good in print and refer to specific inks. For that reason, if I match an RGB color to what I see on my screen as your choice for a process color, you may see it as wildly off base.
2. Color fades, overlays, filters, and transitions
These do not exist in HTML. There is no program code to say that this 'area' fades from blue to red. There is also no matching technology for all the overlay fade types that Illustrator offers. Any time you use these in Illustrator, whatever part of the page that is must be reproduced as a graphic image. The problem with doing things as graphic images, is that they don't expand or contract smoothly without pixilation if that area of the screen needs to resize. The result is that we must limit the page's ability to go wider or longer based on content or based on the size of the user's screen. On the web, this is considered unprofessional.
3. Transparencies, and transparent overlays
There are some severe limits to this on the web. If something has to be an image due to some of the reasons above, or those listed below, it must be done as a ".GIF" image. The problem with .GIF images is that they are much more limited in the number of supported colors. You won't see photography done as GIFs. For high resolution, you need a .JPG. JPG, unfortunately, doesn't support transparency. There is the alternative of a .PNG image - but these are not well supported by older browsers, so using them causes other problem. To simulate the look of an overlay that has this, we have to make them a part of the image they appear to be on top of. There is support for transparent overlays of non-graphical content -- like text with a transparent background -- that can be overlayed onto images, but its only really good for either 100% transparent, or 100% opaque. Any point in the middle of that will vary across browsers and systems.
4. Shapes - other than rectangular.
If it doesn't have a 90 degree corner, then HTML doesn't do it. Period. Absolutely any part of any page that isn't perfectly squared off with right angles absolutely has to be done with graphic image trickery. This gets especially difficult if you have a long curve or arc that goes through many areas of the page which are otherwise content specific and have to line up. The biggest problem we run into here, is that the things we have to do to make it look right really limit the ability to grow the page based on content and browser width.
5. Fonts - Sadly
The web browser world supports only a very small subset of fonts reliably. Any others depend entirely on the seemingly random choices of end users for their other software. Unfortunately, there is no reliable method for embedding other fonts that works across enough browser versions to be considered a good practice. There ARE ways to embed fonts for some browsers. In fact there are several. There just doesn't seem to be a reliable way to do it across many browsers and operating systems. Two pages which show which fonts are well supported are listed below:
One of the things you'll notice on each page, is that several different fonts are listed "together" as if they are they same. As a designer, you'll say "but they're not the same at all". That is true, but this is how a browser sees them. It will try the first, then move to the second, and so on through the row until it finds one in that row that the user has. It will show that font. Oh -- and users may have made local changes to their "font substitution" table as well, so even these sometimes get tossed out the window.
I hope this helps somewhat.
AUTHOR'S NOTE ADD 3/23 --
If you're going to declare "CSS Is the solution to HTML problems" you need to re-read. CSS is included in the tools I'm talking about. It doesn't change the issues I've mentioned at all. It does make doing those things possible, but nobody is saying they're impossible to accomplish. What I'm saying is they're more difficult than most designers think, and the tricks you have to do to make them work reduce the flexibility of the page.
Please wait while your document is saved.