Year: 2006

Categories
Stuff

100 Things

SB of Watermark was bitten by the “100 thing…” meme, which she proceeded to answer in a whimsical, humorous, and charming way. As she wrote, This is a narcissistic exercise; who would want to know 100 things about a stranger on the Internet?. Rather than sit, looking into the pond, she entered the phrase, “SB is…”, into a Google search, and then summarized the results of what she found.

Speaking of 100 things Seth Finkelstein writes on the burden of a Wikipedia entry, and a recent discussion on whether his entry should be deleted. I can empathize and agree with Seth, but for opposite reasons: what if one’s Wikipedia bio sits, like an immovable stone not even gathering moss? Wouldn’t it be better to be to show some signs of wear over time than to show a smooth, unchanging face, no matter how pleasant?

There are actually far worse things that can happen to the bio of a living person than trolls saying something nasty. Come to think on it, the same thing can be said about the person, directly.

Categories
Technology

Safe for eyes…maybe

Recovered from the Wayback Machine.

I had pulled the colors for the Bb Gun from an old ad for Red Ryder BB guns. If you’ve watched the movie, “A Christmas Story”, you’ll recognize both the gun and the ad. I also originally had an image of the gun on the site. However, when I asked permission to use the image, the Daisy air gun company said they’d prefer that I remove it; as is their right, and I was happy to comply.

I kept the colors, though, as I thought a good strong dose of color was appropriate for the content. I had a chance yesterday, though, to check it out on a Mac where I hadn’t modified the gamma setting to be between that of a pure Mac, and that of a PC. My first reaction was, “Argggghhhh!”

Thinking that the site’s tagline starts with “Safe for eyes…”, it behooved me to make it safe for eyes. I’ve set the background color to white, for now.

Even if I hadn’t set it, I do provide full feeds at all the sites and a person could forgo the pleasure of directly reading the page at the site in favor of reading it in an aggregator. Yes, I’ve come fully around on feeds, and it was my recent book project that led to this change in attitude.

I don’t agree with the Ajax enthusiastas who say that one can blow off both valid markup and accessibility in the interests of creativity. When I was working on the Learning JavaScript book, what kept going through my mind in providing an accessible alternative to a site heavily JavaScripted and DHTMLized is to use a content management tool, like a weblog, to create multiple templates: one with ‘the goods’, one without.

(If the site was XHTML, one could also use XSLT to transform the page, but let’s face it, working with XSLT sucks.)

Still, even providing a ’site safe’ template, you can’t plan for all types of user agents. The best we can do, then, is provide a syndication feed. If we provide a properly formatted syndication feed, no matter the user agent, the site writing and the annotation that accompanies the writing is accessible. That’s the most important component of our pages, the contents of the individual posts. If all else is stripped away, this still comes through–if you use a properly formatted syndication feed, that is.

As such, I agree with DeWitt Clinton that providing type information for syndication feed consumers is imperative–especially if you have sites that provide a great deal of structured data. Where I don’t agree is that I don’t provide multiple feeds at my site. One feed is sufficient.

(And it irks me that I have to edit the default wp-atom.php that comes with WordPress in order to generate valid Atom.)

Using NOSCRIPT to add whatever is needed when JavaScript is not enabled, and making sure all content is accessible by keyboard, properly labeled, as well as logically layed out for speech-to-text browsers is the major first step in making a valid and accessible site. Providing a carefully formatted and precise syndication feed, with support for rich markup, is the second. Between the two, your word (and your metadata, and we all know how big I am on metadata) gets out.

Now, back to shopping for a new background color for Bb Gun. What think? A pale lime chiffon pie green, maybe?

PS: An good article, Reading and Subscribing to Blogs Through RSS: How Accessible is this world to people with vision loss, covers accessibility and RSS. The issue with being able to properly manage markup in addition to the recommendations outlined in this article means that if there is microformatted data associated with the post, such as calendar data, it also can be processed without undo intervention of the web page reader. An example can be to add an event to a reader’s calendar, or other such metadata related processes.

Categories
Photography Places

Keep the Faith

Recovered from the Wayback Machine.

There’s a famous Catholic cathedral here in St. Louis: The Cathedral Basilica. It’s a beautiful building, with its green tiled dome and solid, hewn stone walls. What makes it unique, though, is its collection of mosaics. Only the Vatican has more mosaics.

Main church alter

I visited the Cathedral this week to scope it out for photographs for the MissouriGreen site. All visitors are welcome, with the only limitation on no photography in one small chapel to the side. They provide formal tours, but there are usually people about answering questions, providing stories of the mosaics, and the Byzantine architecture that inspired it. For instance, did you know that the balconies in many earlier churches were added so that pilgrims who traveled from afar could camp out there at night?

Church Balconies

The cathedral has three inner arches, with the main one over an inner dome with a white marble statue of Jesus Christ on the cross. On either side are chapels, four in all, and each very different from the others. There’s also a museum, though I spent my time this first visit wondering about the main area.

I didn’t take a tripod, but will my next visit. I also didn’t have strobe lighting, and as such had to use the camera flash or a fast (and grainy) ISO and large aperture. However, I’ve seen photographs of the Cathedral all lit up and it doesn’t do the Church justice. The magic of the place is the muted shadows of the simple, dark wooden pews, and the dark gray of the limestone and marble walls, offset by the color of the glass tiles–all around you, above you, high above you so that you stand staring up until you become dizzy with the effort.

(I have been reassured that if I wish to lay down on the ground to take photographs of the ceiling, I am more than welcome, and they’ll try not to step on me.)

The Resurrection Mosaic

The mosaics range from a very old Italian style created by Tiffany’s of New York, to very modern style. One section depicts scenes of the Church in St. Louis, including images representative of various Native American tribes in the area. The other sections of the cathedral portray traditional bible stories. Surrounding the scenes are geometric shapes, brilliant in color, filling in here and there: on podiums, around alters, and even on signs. Not gaudy though, because of the quiet neutral color of the stone and wood–little in the way of gold work, and that mainly in touches of gold leaf, or brass.

Mother Mary and Child

There are only two relatively colorful stained glass windows; in fact few windows at all. It’s not a dark place, though. The lighting is soothing rather than penetrating, and even that on the tiles is just enough to display the pattern without overwhelming.

It’s hard for me to say what was my favorite mosaic. Probably the more modern ones because of the unusual scenes and subtle coloring. There was one, though, in the lobby, that caught my interest. It showed Christ holding up his hands in a gesture of welcome, and surrounding him were the words:

I have fought a good fight. I have kept the faith.

mosaic of Jesus Christ

I rather liked the seal because its focus was on faith rather than religion; after all, keeping the faith extends beyond church, book, and priest.

I fight the good fight; I keep the faith. Sometimes that’s all I have in life, but I’m not religious. I like to believe that the rules, the dogma, the small and large intolerances come from religion; the acts of kindness and beauty, the serenity of place come from faith.

Slideshow of the photos

Categories
Technology

More Script, Less Teasing

Recovered from the Wayback Machine.

I finally rolled out the ScriptTeaser site tonight. My first writing focuses on the Dojo fisheye effect I created for the menu bar, and is titled Geegaws can be accessible. Valid, too.. In the article, I covered all of the code I created to make this particular geegaw valid, and partially accessible.

I have found with Dojo and many other of the Ajax libraries, most do not produce either accessible content, or content that validates (either as XHTML or HTML). Though I appreciate the effects, one of the mental decisions I had made in regard to my new sites was that I wasn’t going to be bringing any bad habits with me when I started again. If I’m going to start fresh, I’m going to start fresh.

This means clean and valid page source, clean and valid stylesheets, JavaScript that works with all my target test browsers, as well as accessible content. The sites are now in various stages of not meeting these good intentions, but over the next few weeks, they’ll shape up.

Categories
Diversity JavaScript

Gewgaws can be accessible. Valid, too.

One of the DHTML (Dynamic HTML) effects not built into my own libraries is a fish-eye effect. Those of you who have a Mac will know the effect I’m talking about: when you move your mouse over a menu bar, the items expand but in a way that emulates a ‘fish-eye’ magnifier.

This isn’t a trivial effect to create. You not only have to capture the web page reader’s mouse movements, you also have to size objects in relation to each other and the mouse. Luckily, the popular Ajax library Dojo Toolkit, created by a consortium of interested developers has just such an effect.

Though Dojo has documentation, it’s coverage is like Wikipedia’s coverage: it’s added by interested parties, and as such, there are gaps in how to use some of the library objects–including the Fisheye Widget. However, there are plenty of demos, includin one for this object.

To use this functionality, according to the demo, you create a series of div elements: one outer, one that acts as control, and several inner (for each menu item). You then add Dojo class names, as well as element attributes providing information for the menu caption, source file for the icon, minimum and maximum image sizes and so on. The markup in the demo is as follows:


<div class="outerbar">

<div class="dojo-FisheyeList"
	dojo:itemWidth="50" dojo:itemHeight="50"
	dojo:itemMaxWidth="200" dojo:itemMaxHeight="200"
	dojo:orientation="horizontal"
	dojo:effectUnits="2"
	dojo:itemPadding="10"
	dojo:attachEdge="top"
	dojo:labelEdge="bottom"
	dojo:enableCrappySvgSupport="false"
>

	<div class="dojo-FisheyeListItem" onClick="load_app(1);" 
		dojo:iconsrc="images/icon_browser.png" caption="Web Browser">
	</div>

	<div class="dojo-FisheyeListItem" onClick="load_app(2);"
		dojo:iconsrc="images/icon_calendar.png" caption="Calendar">
	</div>

	<div class="dojo-FisheyeListItem" onClick="load_app(3);"
		dojo:iconsrc="images/icon_email.png" caption="Email">
	</div>

	<div class="dojo-FisheyeListItem" onClick="load_app(4);"
		dojo:iconsrc="images/icon_texteditor.png" caption="Text Editor">
	</div>

	<div class="dojo-FisheyeListItem" onClick="load_app(5);"
		dojo:iconsrc="images/icon_update.png" caption="Software Update">
	</div>

	<div class="dojo-FisheyeListItem" onClick="load_app(6);"
		dojo:iconsrc="images/icon_users.png" dojo:caption="Users" >
	</div>
</div>

</div>

It’s an interesting approach to take: embed the necessary information as tag attributes, so that the person doesn’t have to touch code. However it has two major drawbacks: it doesn’t validate, and it’s not accessible.

Dojo, like many other of the new Ajax libraries, make use of custom attributes on standard HTML and XHTML objects, which don’t validate as either HTML or XHTML. In addition, the menu is JS driven, so a person who doesn’t have JavaScript enabled won’t have access to the menu. Not only JavaScript driven, it’s also mouse driven menu, which makes it unusuable within text-to-speech browsers.

Modifying the code so that it validates is a bit tricky, but doable. What is required is removing the tag attributes for the elements, and adding these using the DOM, or Document Object Model, API.

I have six menu items, which means removing the custom attributes for one controller and the six menu item div elements:


<div class="dojo-FisheyeList" id="controller">

        <div id="menu1" class="dojo-FisheyeListItem">
        </div>
...
        <div id="menu6" class="dojo-FisheyeListItem">
        </div>

</div>

In JavaScript, I use the DOM setAttribute to re-set these custom attributes. The following code re-sets the attributes for the controller object:


  var cont = document.getElementById("controller");
  cont.setAttribute("itemWidth","60");
  cont.setAttribute("itemHeight","100");
  cont.setAttribute("itemMaxWidth", "200");
  cont.setAttribute("itemMaxHeight", "300");
  cont.setAttribute("orientation","horizontal");
  cont.setAttribute("effectUnits","2");
  cont.setAttribute("itemPadding","10");
  cont.setAttribute("attachEdige","top");
  cont.setAttribute("labelEdge","bottom");
  cont.setAttribute("enableCrappySvgSupport","false");

These attribute settings are exactly as they were found in the tag attributes, other than altering the image sizes to fit my own GIFs.

For each of the menu options, again the element is accessed by identifier, and attributes added with setAttribute. The following sets the attributes for the first menu item, but all other menu objects are modified using the exact same code (but different images and captions):


 var menu1 = document.getElementById("menu1");
  menu1.setAttribute("onClick","load_page('http://learningjavascript.info')");
  menu1.setAttribute("iconsrc","/dotty/dotty.gif");
  menu1.setAttribute("caption","Learning JavaScript");

Since Dojo requires these attribute settings before its functionality, and it processes the data on page load, the function that contains the attribute setting needs to be called right after the div elements are created in the page. One way is to embed a script block calling the function in the web page right after the div elements are created:


<script type="text/javascript">
//<![CDATA[

setMenuProps();

//]]>
</script>

(Notice the use of the CDATA section surrounding the script? This, also, is required in order for the page to validate as XHTML.)

Once the attributes are set, the Dojo fisheye menu loads cleanly, without having to use custom attributes. But something’s still missing: attributes that are required. Each img tag requires an alt attribute, which is a legitimate X(HTML) attribute, but one that’s not provided.

I explored the Dojo code and tried a couple of alternatives to add attributes for the images, but nothing worked. There’s also nothing in documentation. So, back again to my own custom code.

Unlike setting the initial attributes, the alt attribute needs to be added afterDojo has done its work and created the menu. Dojo captures the window.onload event, which I also needed to capture. However, I had to do so in such a way as to not ‘break’, or override Dojo’s event handler.

I needed to use the DOM again, but this time to attach an event handler on the window onload event, chaining it with the Dojo event handler. The following code does the trick:


function addWindowOnLoad(func) {
   // test for object model
   if (window.addEventListener) {
      window.addEventListener("load",finish,false);
   } else if (window.attachEvent) {
      window.attachEvent("onload", finish);
   }
}

addWindowOnLoad(finish);

The finish method then accesses each image in the page, checks for class name, and when it matches the Dojo class name, checks the source attribute on the image. Based on the text, the related alt tag value is set:


function finish() {
  for(var i = 0; i

The page now validates as XHTML transitional. Thought it takes more code, it’s preferable than just blowing off XHTML as ‘not useful’, or unimportant. We haven’t walked three steps forward in our use of web standards the last decade, only to take two steps back now for the sake of a little sizzle.

Even if we decide to blow off valid markup, we can’t justify blowing off accessibilty (of which valid markup is one component). A pretty or cool effect is not worth putting barriers around our pages. Unfortunately, though, accessibility is both easier and more difficult to implement.

The simplest accessibility option is to provide a NOSCRIPT block with content to display if JavaScript is disabled. In this case, a straight menu with hypertext links around images is all that’s needed:


<noscript>
<a href="http://scriptteaser.com/learningjavascript/"><img src="/dotty/dotty.gif"  
  alt="ScriptTeasing News" /></a>
...
</noscript>

Unfortunately, other accessibility issues aren’t as easy to resolve. A truly accessible menu needs to be keyboard sensitive for many text-to-speech browsers. Adding this into the Dojo menu is going to take additional thought. In addition, the behavior of the menu is off with Internet Explorer 6.x (the entire menu doesn’t display until you move your mouse over the bar).

Then there’s the issue of the size of the Dojo libraries. There’s a noticeable delay loading this page with Dojo’s large code base in addition to mine, just to create a visual effect.

Sometimes, though, you want both the sizzle and the steak. I’ll return later with more on whether I’ll keep the Dojo fisheye menu, and how I’ll resolve the last issue of accessibility if I do.