For years, one of the great things about the Web has been the browser's ability to easily view a page's source to see the HTML mark-up. But now links to external stylesheets and scripts are commonly used for presentation of pages. Depending on server configuration, that's made it harder to impossible to see how somebody did something on a page. You can't swipe (or avoid) the code if you can't see it.
All the other pages on this site link to the pages.css and pages.js files. So, for your enjoyment (in case you have trouble opening those in your browser) I've exposed in the head of this page the code from those stylesheet and javaScript files.
The use of inline tags for HTML's mark-up is intuitive and rapidly learned. Tables in HTML have worked fine for years for most page layout, with an occasional bit of fussing around. Since tables provide the most robust, consistent cross-browser solution for most layout, page designers are still using them where appropriate (and whenever they don't want to have to try to prove and tweak the CSS for half-a-dozen different platforms).
CSS is very powerful, giving the designer control over page layout and element presentation that HTML alone could never hope to achieve. Further, moving layout and presentation from inline mark-up to linked stylesheets cleans up documents, makes maintenance and changes far easier, reduces file size, and keeps the folks at the W3C happy.
Unfortunately, CSS today has problems. The W3C tries hard to leave nothing out. As a result CSS syntax is comparatively cumbersome, it requires the use of its inheritance scheme, and overall it takes significant effort to learn. More importantly, much of the CSS positioning system is arcane and its implementation on different platforms is still wildly inconsistent. This can be a significant time-wasting problem:
Using only CSS for layout and presentation, I re-wrote YogaWithMarnell.com to include a CSS a:hover that displayed an information box that moved with the anchor. It took a javaScript browser sniffer and three different stylesheets to try to cover all the platform differences for five different browsers, and still wasn't completely successful. I've since simplified the hover, and by being very careful, have managed to display the site consistently on five browsers using one stylesheet.
On this site I wanted a footer to stay at the bottom of the text or the browser window (the so-called "viewport") whether the text filled the window or not. HTML tables make this trivially easy, using height="100%" and valign="bottom". CSS has so far provided no easy way to do this, short of using CSS hacks and funky javaScript—which may fail with new browser versions. Read the article in A List Apart.
So on this site I still use tables for some of the layout, and have migrated the rest of the layout and all of the presentation to styles. It still requires great care to get consistency across browsers and platforms. Future browser versions will converge on the W3C CSS standard—if the standard that they're aiming at will just hold still. And we can hope that future versions of CSS positioning will be a bit more rationalized.
One of the main issues of webpage design is caused by the historical 4 by 3 aspect ratio of most computer monitors – still the same as for a TV set. A page designer has two choices:
(1) use very short paragraphs so the eye can easily track back to the start of the correct next line (as here); or
(2) keep the text to a comfortably narrow column width (as on most commercial multi-column sites).
Now, choice (1) leads the writer to a journalistic style of short, choppy paragraphs, which greatly decreases the ability to leisurely expand her sentences, let alone her ideas. Choice (2), for the naïve or any designer who has a fear of white space, often leads her to want fill in on the sides of the page, and we're back to the unnecessary use of frames or multiple columns.
Fortunately, the use of frames has become much less common in the last couple of years.
Where they are still used in inappropriate ways, they can introduce problems of their own:
They can make searching a site, viewing the source (but see above), and saving or printing a page difficult to impossible.
Page designers commonly put a site navigation menu in a side frame. If the main frame includes the same menu (as it often does), the reader can find himself clicking on the same things over again as he browses for information. That is, rather than helping him find what he wants, the use of frames just gets in the way.
Thankfully, many of the sites that do use frames (usually for good reasons) include links to unframed versions of their pages, allowing simple printing or saving of their information.
Most animations are terrible. No one likes trying to read text with things flashing and
whirling and scrolling around on the screen. Everyone agrees that the <>
tag was a bad idea so nobody uses it, and (to Microsoft's credit) Internet Explorer has never
supported it.
But now, especially on most commercial sites, we're swamped with moving stuff. A browser's stop button might work on animated GIFs, but most flashing irritations these days seem to be Flash animations. Unless we can disable them in our browsers we're stuck with them.
Java and javaScript, by themselves, are very useful tools. For a simple example, see attractor.html for Java, or www.fourmilab.to/gravitation/foobar
for clever use of javaScript.
When combined with CSS, javaScript yields so-called dynamic HTML (DHTML) giving the scripter seemingly endless possibilities for "user interactivity." DHTML allows all kinds of snazzy things on a page. While few of these help a user to gather information, they do help to gather his attention.
Unfortunately, implementations of both javaScript and CSS are still inconsistent, varying among the W3C standards and the various browsers and platforms, making their use awkward for anyone worried about cross-platform compatability.
We don't all upgrade everytime it's offered. Anyone using an older browser version is bound to have run across pages that display oddly and "features" that are unusable. And even the latest browsers (versions 6 and 7) implement the "document object model" in idiosyncratic ways. So it strikes me that the game is to stay a little behind the curve, and for both javaScript and CSS coders to write to a lower common denominator.
As time goes on and the browsers converge on the standard, this issue will finally become moot, I'm sure. ;-)
Maybe it helps to remind oneself that even simple text wrapped in <pre>tags</pre>
is a Web page, tho' I guess it ain't really hypertext.
This site can be viewed with any damn browser.
endRant