We use the Web a lot. And we put up with a lot. Ask anyone who spends any amount of time using a browser, and they're sure to have a list of little things that bug them. Ask someone who spends time actually designing Web content, and they're likely to have quite a long list.
From downloadable type to advances in layout models, we gathered the top 10 features or trends that would make us happy to have in our browsers right now. Most are obvious. (Standard cross-platform color? Of course!) Others less so. But they all share a common thread - they are all elements of a mature publishing environment.
We expect to see many of these things in the mainstream browsers in the very near future. And many of these features exist in some browsers today. But until a standard, reliable solution for each one of these technological advances hits critical mass, we'll probably keep complaining about the state of the Web.
We also assume that we're merely scratching the surface with this list, especially outside the niche of Web designers.
Now, on to the good stuff...
How sick are you of the Web's ridiculous "color-safe" palette of 216 colors? Anyone with cursory experience in Web graphic production knows how limited the color space in today's browsers is. It's not necessarily a browser issue (although browsers could do a better job rendering in diverse environments). It's a matter of older machines having been sold in years past with a limited ability to display more than 8-bit color.
Even Web-based electronic commerce may depend on a mature and sophisticated color model. Sure, graphic artists may be clamoring for a fraction of the colors they've come to rely on. But for absolutely accurate color, there may be no more vocal proponents than those offering goods online. Not only must products be presented in an attractive (and undithered) display, but some items, notably clothing, absolutely require an exact reproduction.
This hasn't happened yet for a number of reasons. Cross-platform arguments will abound, since different hardware produces different color. Good color is expensive, too - a high-end color-matching monitor costs a bit more than the standard 14-inch job that ships with most multimedia boxes. And we won't even get into gamma issues....
Where to start? Give designers the ability to link their own color palettes to their pages. Is that so hard? Sounds simple, doesn't it? The ability to rotate an object has long been a feature of desktop publishing packages and graphics applications. Now, as the layout capabilities of browsers mature and the dynamic capabilities of our screen-based presentations become a reality, we can begin to dream of the more interesting effects.
Rotation is a great text effect and a valuable one for Web pages with limited on-screen real estate. Currently, the only way to achieve this effect, though, is by using an image. This, of course, is bad. Not only do you lose the searchability of the text by encoding it in a graphic, but the bandwidth consumption is considerable.
And when it comes to images, rotation makes any graphic more versatile. Add to that the ability to script the rotation dynamically in 4.0 browsers with JavaScript, and you have a powerful animation effect built into the browser.
We feel rotation of text and images should be a fundamental component of a Web-page layout system. We'd like to see it included in a future version of cascading stylesheets (CSS). Images, icons, and illustrations aren't always square, and a basic part of a print designer's toolkit is the ability to wrap text around these non-rectangular shapes.
We've seen the simple beginnings of a feature like this with the incremental additions to the tag. Early inclusions of align=top, middle, or bottom, gave way to the basic concept of text-wrap with the addition of left and right. Then, simple hspace and vspace gave us the ability to push text away from images in a rudimentary way.
Text needs to follow the contours of images, based either on a graphic's transparency setting, the available alpha channel, or an author-specified path. Again, this belongs in the cascading stylesheet specification. How many times have you built a GIF containing a headline just to give your page a bit more character? Ever notice how nice the larger-sized type looks compared to the junk the browser spits out? That's because the graphics program you use probably does antialiasing - fading the edges of the type between the foreground and background colors. The smoothing effect that results makes for better-looking type.
Netscape's font downloading engine (supplied by Bitstream) does antialiasing, as does Microsoft's SmoothType technology which ships as part of its PlusPack for Windows 95. Both are good starts. Neither places the power of good antialiasing in the hands of Web-page designers. The Netscape solution renders every font at every size with one level of antialiasing. Microsoft's offering must be installed and turned on by users.
Instead, we'd rather see antialiasing as a feature of cascading stylesheets, and we'd like the ability to set the level of dithering into the background. The Portable Network Graphic format is cool. It does alpha channels and gamma correction and even filtered compression. Yet support for this magical standard is spotty at best. Both IE and Communicator have limited support for PNG, but nobody actually renders all the powerful features encoded in a file.
Alpha channels, for example, are especially important now that images can move around the screen via dynamic HTML. Since the additional channel in the image can be set to transparent, PNG images can be antialiased against any background image or pattern. That way, when your image moves across the page over different colored backgrounds, you can avoid ugly halo effects.
Gamma correction, like a mature color spec, is crucial for accurate color representation across multiple platforms, and with different monitors and monitor settings. Variable compression allows images to be compressed based on their content, making the current distinction between GIF and JPEG irrelevant. These are all very good things.
The latest browser versions have given us native PNG support by using the tag, rather than having to rely on a plug-in or ActiveX control. Now, give us all the power the specification has. Absolute positioning through cascading stylesheets is without a doubt the future of page layout on the Web. It's a powerful way to make very degradable pages and avoid the nasty layout-via-tables hacks we've been using for so long. But the CSS-P spec is also just a start. We'd like to see more.
Currently, using CSS-P requires adding a height and width to an element, as well as specifying how far from the top and left of the start of the page the positioning should begin. If the box you specify is smaller than the amount of text you have, you can tell the browser how to deal with the overflow. Options include clip, which cuts it off; scroll, which adds scroll bars to the box; or auto, which resizes the box to fit.
This is very similar to the way desktop publishing programs like Quark XPress and PageMaker deal with text and images on a page. What's lacking, however, is the ability to link to another box, so that overflowing text jumps to a new position. This is how advanced magazine layouts can have text running at different lengths across a page, and it would be very valuable for interesting layouts on the Web, too.
Positioning an element in a fixed position on the page would be a powerful addition as well. Imagine anchoring a
on the page so that it didn't scroll with the rest of the page's contents. Add an overflow: scroll attribute and then you could build framesets like we have today, but with only one document (and therefore only one trip to the server - fast!). CSS-P has been included in the CSS2 draft, so it's probably too late to add "overflow: link" and "position: fixed". We can look forward to CSS3 though, can't we? This one is easy. Having two separate font specifications is stupid.
We could write story after story about the intricacies of intellectual property when distributing fonts online. And the design implications of letting people run amok with a gazillion typefaces could fill a library of books. But none of that will matter if you have to write a backend conditionalizing script just to send out a simple typeface to both halves of your audience.
Netscape aligned with Bitstream to incorporate its TrueDoc type-rendering technology in Navigator 4. Microsoft, conversely, sided with Adobe to include OpenType in Internet Explorer 4. The result? Incompatible implementations for delivering typefaces to your audience.
It's ridiculous. You need to design your pages twice, with two different typefaces, both of which you need to own and have licensed to embed in your page. Then, you need to burn the two separate fonts into downloadable files, and figure out a way (probably through a sever-side CGI script) to determine which font to send to which user. In other words, you have to spend your time struggling with the technology, rather than designing pages. Hardly elegant.
Typography on the Web will remain untapped until this nonsense has been fixed. Imagine a graphic-file format that let you create images that were infinitely scalable, could antialias to any background, were incredibly fast and small, and had a built-in animation engine. Too good to be true? Well, at the moment, yes.
These qualities all point to a standard vector-graphics format for the Web. Vector graphics are the opposite of bitmapped graphics - rather than row after row of colored pixels making up the image, a series of algorithmic lines and curves generate the shapes you see on the screen. Since the graphic is rendered in the browser rather than in a graphics application, the height, width, background color, and a number of other variables can be changed at will, giving these illustrations many benefits over their pixel-based cousins.
There are a number of excellent vector formats, each excelling in different ways. Adobe's Encapsulated Postscript, Microsoft's Structured Graphics, and Macromedia's Flash all accomplish much the same finished product, and all with different approaches. Unfortunately, none of these formats enjoys the ubiquity or designation as a standard of GIF, JPEG, or PNG - the de facto formats of the Web.
If it were up to us, we'd choose Flash from Macromedia. It's absolutely the best format for creating vector-based illustrations and animations on the Web. It's much faster and smaller than other offerings and can be controlled and scripted through the browser using JavaScript. Macromedia has a challenge ahead, however. It needs to attain a large market share with Flash, and that's difficult when the format isn't a standard. We love cascading stylesheets and have been vocally proclaiming their value for quite some time now. That's why it's so hard for us to see the mess they've become in the current round of browsers.
A cottage industry of sorts has cropped up offering information on which browser supports which feature of the CSS spec. Some features work in one browser and not another. Some don't show up at all. Others are rendered incorrectly. We're even beginning to wonder what "compliance" with the CSS spec actually means, considering the atrocious liberties that have been taken when interpreting the language in a browser.
The sum of these annoyances is the inability of designers to rely on one of the most powerful presentation features yet developed on the Web. The basic aspects of typography and layout - like margin definitions and line height - are taken as suggestions rather than absolutes in the current implementations, at the cost of widespread confidence in the design community.
Granted, the Web in general, and HTML in particular, haven't propertied to offer pixel-level control to the graphic arts. But CSS actually offers a glimpse at a mature design environment and then pulls it away as quickly as it was promised.
Let's get this right in the next version, OK? All I really want, above everything else, is a browser that is rock solid on my system. I want this so bad that I would even give up the hyperspeed cycle of new features and new betas every few months. The evangelists are already out testing the waters for 5.0 browsers, dangling new advances in Web technology before us. Can't we spend a little time getting the basic stuff down first?
How do browser companies set priorities when developing the software we use on the Web? Why were we able to navigate 3-D worlds in our browsers before we could even select a font or search the documents in our history lists? Unfortunately, simplicity and common sense fail to demo as nicely as streaming video and rendered fly-throughs.
It's an easy excuse to say the Web is still such a new medium, and that sort of stability and maturity takes time to evolve. But we rely on the Web. Every day. When was the last time you picked up the phone and didn't hear a dial tone, or turned on the TV to a snowy gray field? If we truly are building a new mass medium for information, communication, and entertainment, then browsers can never crash. Ever.
This article appeared originally in HotWired.
