Wednesday, March 25, 2009

A Little Knowledge…

I don't believe there is any such thing as wasted knowledge, but I do believe in the old saying "A little knowledge is a dangerous thing". This is especially true when dealing with Cascading Stylesheets, CSS.

The last book has probably already been written showing CSS as an afterthought. When the specifications were first gelled, back in the Clinton administration, I could see why authors of the HTML books of the day just tacked on a new chapter dealing with the new rules. Usually, this was at the back of the book, the clean part of any well-thumbed tome that indicates most people never quite got around to reading it, or reading it to any degree, anyway. This was understandable, and I would have probably done the same thing, but it still wasn't a good idea.

CSS needs to be taught on the same level and at the same time as HTML. I know dozens of people who have never finished a book on computer technology. You start at the beginning, 'You are about to embark upon a wonderful journey…' and cruise through the early examples, "Hello, World!", and then you pretty much put them aside at some point after that. CSS deserves better.

We all lead busy lives. Especially now, we are all trying to do more, trying to increase our productivity so as to keep our names off of The List. We can't be bothered to pick up every detail, and especially not the details of things we may never need to actually use in real life. I need to know how to get these words on these pages in this order, about "here" on the page. Show me how. You can learn all of that between pages 32 and 47 and it just doesn't occur to most people to then also go to the back of the book to find out how to adjust the text, color it, shade it, move it around, constrain it or otherwise style it. If the information was really important, it would be at the front of the book, right? Who has time for all of that?

CSS is finally coming out of that kind of attitude. As more and more developers pick up more and more of the simple rules, we are seeing fewer and fewer tables used for page layout, fewer <font> tags, fewer <p></p> tag pairings
and fewer multiple–<br />'s used to adjust on-screen placement.

I'm encouraged. I have fallen victim to this kind of thinking, myself. I teach HTML in one workshop and CSS in another. And so once again, if you don't take the CSS training, you don't know what you don't know. That may be doing a disservice to anyone looking to learn about how to mark up a page. Maybe CSS should be included in that very first introductory class, to reinforce the idea that This Is Important.

I applaud anyone who wants to learn anything. I just know that the Web of 2012 and 2015 will be a much nicer place as support for Internet Explorer 6, tables-for-layout and the endless parade of <font> tags recedes into the middle distance. We need to do a better job of "building value" in CSS, and in teaching it as an important part of building Web pages, not an afterthought.

Wednesday, March 18, 2009

A New Template

A new Template is coming. This isn't probably news to anyone. It was probably a smart bet that work began on the next one as soon as the last one was officially published. And while there may have been a self-congratulatory weekend taken off, that's pretty much how I remember things.

People expect change, on the Web. It's built into the promise of linking documents from all around the world. And that change extends not only to content, but also to the design of the content, the presentation of the content and even how we work and interact with the content.

Even if Web technology was fully mature and never changed again, there are still many good reasons to change things every now and then. Retailers routinely move the coffee and cereal aisles in grocery stores, or the power tools and the nuts and bolts in hardware stores. People have this amazing capacity to discount things that don't change.

Apparently it's buried deep within our Lizard Brains and has been there for centuries. Remember the scene in Jurassic Park when everyone stood still so the Velociraptor wouldn't see them? 'Raptors visual processing greatly discounted anything that wasn't moving, that wasn't new, in a way of thinking. If an animal moved, its relative position changed, something was new, and so those signals went straight to the brain. But rocks and trees were more or less motionless and could easily be discounted in a day spent almost entirely looking for food.

Similarly, it's been said that most people cannot draw an accurate representation of either their wristwatch or their car dash board. Isn't that interesting? They see these displays sometimes dozens of times per day, so often that what starts to register is the un-changing-ness of most of it. Sure, the hour and minute hands move from glance to glance, and you note the passing of time that way, but are your numbers Arabic, Roman, or just dots in the position of 3, 6, 9 and 12? Are you sure? We notice our speed changing as we get out on the highway, but how high does your speedometer read? 85 miles per hour? 100 miles per hour? More? What about your gas gauge? Does just sweep from "E" to "F" or does it have factions of a tank marked off, somehow? See what we mean? We're lucky we recognize members of our own families, I guess.

So after a time, it's common to change things. And change provides a great chance to introduce new technologies and/or new ideas into the mix. When our first Web page showed up, there wasn't much need of JavaScript. Then there was, and then there wasn't, again. Now it's back again with a lot of light shining on AJAX. This is one of those things that we can plug into the page now and get real benefit from. We used to spend a lot of calories wrestling with differences between different Web browsers. We have to do much less of that kind of thing, now.

Kids coming in today have grown up in a world that has always had an Internet. Web pages have always added new features and new technologies have come along at irregular intervals that needed to be reckoned with. The Web page we show him should be at least as cool as the one his high school had, shouldn't it? He just spent a bag of money on a new laptop and a new smart cell phone. Our pages should work on those, too, right? Wouldn't you be expecting that much?

So we are coming down to the wire on a new Template design. As before, several groups have been working on several designs. Within each, the battle for supremacy has been raging since last fall (not to sound too WWE or anything). Should the new navigation menu be over here? Or over there? Are people still using QuickLinks, or should we move everyone into the Search box? And what about that Search box? Do we really need to explain that we want to search for people or pages? If we took that question away we could present both and maybe speed things up for people. Hmm….

We expect to have three good candidates, soon. You'll be able to see them and comment about them, and then there'll be… one. And then we'll deploy the new design, suffer the abuse from detractors and bask in the glow of the praisers and… start the whole process over, again. You've been warned.

Wednesday, March 11, 2009

Obituary

We are sad today to note the passing of Tables for Layout.

Tables for Layout was born in David Raggett's late–1993 draft of HTML markup formats. This paper was adapted and adopted into the May, 1996 RFC and, ultimately became a part of the specification for HTML v3.2 in January, of 1997.

Tables for Layout really came into its own with the release of Netscape's Navigator 3 and especially Navigator 4 browsers, along with Microsoft's Internet Explorer, in version 3 and again especially in version 4 release.

Tables for Layout was the tool of choice for professional Web designers and developers throughout the late 1990s and into 2000. As the Web became more commercial, large corporations with sometimes millions of dollars invested in logos, colors and other branding identity had little patience for a Web where they could not control the precise positioning of various elements on a page.

While never designed specifically for Layout (Tables were originally meant only for tabular data), Tables were drafted into the role of constraining various content elements on Web pages with more precision than was otherwise available at the time. Tables seemed especially well-suited to this task by most at the time, and it is conceded by even the most ardent detractors that the Web of today would never have happened without the contribution of Tables for Layout during the second term of the Clinton administration.

These were heady days in the evolution of the Web and of Web design and development, and many tags briefly developed a non-standard usage during this period. Mostly, this practice has fallen away with the appearance of the "Internet Appliance" style of thinking, and the realization that content may now appear in massive monitors or on handheld devices like cell phones or anything in between, or indeed in other media.

Tables for Layout will probably be best remembered for its stubborn tenacity in a role it was never designed to fill, only finally yielding its commanding position to Cascading Stylesheets when the first decade of the twenty-first century drew to a close. Until then, it was storied in Web pages throughout the world detailing Web development technique and in a great many well-considered books on "Good Design Practice". Even many of the popular Web editing environments of the day, NetObjects' Fusion, Microsoft's FrontPage and Macromedia (now Adobe) Dreamweaver, supported and celebrated Tables for Layout for a number of years.

Ultimately, the evolution of the very standards that gave rise to Tables for Layout served to weaken and finally kill it. The rise of Cascading Stylesheets and the improved support of popular Web browsers gave designers even more control, and at lower cost, than Tables for Layout could ever provide. As fidelity to the Designer's idea became more and more important, Tables for Layout simply could no longer compete in an area it was never designed to work in.

Tables for Layout is preceded in death by the <blink> tag and spacer .gif, and is survived by the <font> tag, the serial <br /> tag and the empty <p>

pairing, both still in wide use for visual alignment. Visitation is available at any little-maintained Web site from the middle-late 1990s, or sites for firms with little or no Web budget. The family has asked that, in lieu of flowers, donations be made to the WorldWide Web Consortium in support of their HTML and CSS validators, and ask that friends of Tables for Layout finally spend a few moments in quiet meditation with Eric Meyer's excellent CSS: The Definitive Guide.

Wednesday, March 4, 2009

Quiet the Echo

If you have ever printed a UNL Templated Web page, you have doubtless noticed a few differences between the page as presented online, in a Web browser, and as it comes out of your printer.

The biggest difference, the one that gets the most positive comment, is that Navigation does not print. Since you cannot click on a link on a piece of paper, that whole block disappears from the page, leaving more room for the #maincontent area that, presumably, people really wanted anyway.

This is a terrific example of targeting your styles to their expected media. We spend a lot of effort making our page easier to navigate online, by including things like title attributes to flash little tool-tip messages and so on, but this technology is lost on the printed page, too. You cannot "hover" your finger over a printed link and get a message saying where it goes.

So to restore some of that lost utility to the printed page, it was decided to echo the URL string on the printed page, just behind the linked text.

This:

<a href="newPage.html" title="Links to New Page">New Page</a>



Becomes:

...will take you to a New Page (newPage.html).



...when this page is printed.

But not everyone is happy with this implementation. Some people want to turn off links in some areas of the page, while others would prefer not to echo the URL at all--especially if it is a particularly long strong, common in database and eCommerce pages.

The CSS entry that controls this echo is in the print.css page, which is linked to from UCOMM in the head of every document. Since we cannot comment-out the rule on that page, we need to write a rule locally that un-do what it is doing.

Let's look at the print.css file, available at:
http://www.unl.edu/ucomm/templatedependents/templatecss/layouts/print.css

As you read this file, you are seeing only those rules that go into effect when the presentation media is a printer. We are looking for a rule dealing with links, or anchor tags, here.

There's one in the sixth line! But, as we read it, we see it just underlines the link text and removes any background attached to it. So, that's not our rule, and we'll have to find ours somewhere else in the page.

We are probably looking for either a Class rule, or an ID rule, or some kind of contextual rule. Since this URL will echo on the printed page for any link, we can probably discount Classes and ID s. Recall that Classes can be anything, and ID s are limited to just one per page. Since even a simple link with no Class or ID attributes at all will still echo the URL, we must be looking for a contextual rule because the effect works with every class and every ID and even in the case of links with neither a class nor an id.

As we remember from the Introduction to Cascading Stylesheets training, these are rules built with multiple selectors, separated not by commas, but by only spaces.

h1, h2, h3, h4, h5, h6 { color: Red; } will turn all headings Red.

h1 h2 h3 h4 h5 h6 { color: Red; } will only turn Red any H6 heading, but only if it follows an H5 heading, which follows an H4 heading, which follows an H3, an H2 and an H1 heading.

So we are definitely looking for one of these on our print.css page.

We find it, about three-quarters of the way down the page:

#maincontent a[href]:after {content: " (" attr(href) ") "; font-size: 90%; }

What this is saying is "Any time you find, within the main content area of the page, an anchor tag (a "Link") that includes an http-reference, place the content of that link after the Linked Text, displaying it at nine-tenths the size of the linked text.

Now, if this rule was on our local style sheet, we could just comment-out that rule, with /* and */ characters, and go on. But since it has been linked to the page and already been read by our browser, we have to un-do it, somehow.

We can do that by writing our own page rule having to do with printed media, using the @media. If you already have a local or page style sheet atop your page, you can include this rule there, otherwise, include everything here, including the <style> tags, in the head of your document.

<style type="text/css">

@media print {

#maincontent a[href]:after { display: none }

}

</style>


Again, if you already have page styles in effect, just copy lines 2, 3 and 4, above and place them before the </style tag in your page. Otherwise, copy all five lines.

Now, this rule is a little trickier than most typical CSS rules. For one thing, the whole package is contained within the @media rule's own curly brackets. This rule will only go into effect if the media used is identified as a printer. Remember, the information is already at the browser that it should display the destination after the linked text at 90% of regular size and within parenthesis. We had to find a way to turn that off, and the simplest way is using the display: none; property-value pair.

So now, your browser downloads the print style sheet, with its instruction to echo the link, and then it reads your page style instruction which says "No matter what you may have read or heard elsewhere, on this page, if you are printing, and you encounter an anchor tag within the #maincontent area, do not echo the link destination after the linked text".

Since all of our anchor tags are within the #maincontent area, that's all of our links.

If you need to turn off echoing to just certain links, create a class in your page style.


<style type="text/css">

@media print {

#maincontent a.classname[href]:after { display: none }

}

</style>


Remember that whatever class you assign to .classname, it needs to appear within your link as a class attribute, now.

<style type="text/css">

@media print {

#maincontent a.noprint[href]:after { display: none }

}

</style>



<a href="newpage.html" class="noprint" title="Links to new page">New Page</a>.


The result of all of this is a link that prints, but without echoing out the destination URL.