JavaScript Writing

Future. Perfect.

I finished copy edits on my JavaScript Cookbook, which now enters the production process.

The first half of the book focuses on the basic components of JavaScript, while the latter half gets into the more complex material. I touch on the basic JavaScript objects, such as String and Number, but also spend a considerable amount of time covering new ECMAScript 5 and HTML5 scripting features: HTML5 drag and drop, postMessage, the Files API, worker threads, the wonderful new object methods, and so on.

I devoted one chapter to covering ARIA, Accessible Rich Internet Applications, as well as some other accessibility features. The more I work with ARIA, the more I view it as more of a rendering semantics than something purely for screen readers. For a data person like myself, ARIA is a very comfortable technology to use. I’ll have more on ARIA in later writings at MyTech.

Speaking of which, I’ve added ARIA landmarks to my web sites. Use View->Source to look for the role attribute, which is how ARIA landmarks are added. It was easy to update the Drupal templates to incorporate the new material. Unfortunately, the pages don’t validate, but I no longer care about validation. Frankly, the days of trying to code your pages to meet some validation criteria are over. Nowadays, pragmatism is the word in web development.

I am at work on my next book, but it’s not going to be for O’Reilly. Instead, I’m going to try my hand at self-publication, which is why I’m spending so much time working with ePub and other eBook formats. I’m also trying to strengthen my self-editing skills. After 18 books, I’ve become dependent on copy editors—my writing has become sloppy, and full of typos. Speaking of which, I strongly recommend, Paula LaRocque’s “The Book on Writing: The Ultimate Guide to Writing Well.” LaRocque’s book has proven invaluable as I root out my bad writing habits.

Just Shelley

Thirty years ago: Mount St. Helens

Thirty years ago I was living at my Dad’s in Yakima, going to college. That Sunday was a beautiful day, and Dad was outside in the garden as I was getting ready to go to work. I worked for a photographer, who had a studio in the Yakima Mall. I liked working Sundays. Sundays were always quiet, especially when the weather was nice.

I heard a loud boom, but didn’t think much of it. Yakima was right next to a military training center, and it wasn’t too unusual to have a hot dog pilot break the sound barrier. Some minutes later, my Dad yelled for me to come outside. I ran out and saw this ugly dark brown/black cloud rolling towards the town. We knew that Mount St. Helen’s had erupted.

We ran inside and quickly shut everything up, as fast as we could. My boss called to jokingly tell me that I didn’t have to go into work. Little did we both know that the Mall didn’t shut down the air intake system quickly enough, and when we were able to get into the studio three days later, all of my employer’s cameras would be ruined.

The day suddenly begin to turn into night. The ash started falling all around us. It was quiet, except for the ash, which made a slight hissing sound when it fell—like a snake who is only going through the motions. We turned the TV on, finding it interesting to see our quiet little town being the top story for most of the major networks. The President flew by. We waved.

My cat was still outside. Well, I say “my” cat, but Bonzo was really Dad’s cat—a case of love at first sight between those two. I thought he would come back when he saw the cloud, but evidently, the ash must have panicked him. I told my Dad I had to go find him. Dad was torn between wanting to keep me inside, and being worried about Bonzo. Go find him, Baby Doll, he said, But don’t stay out too long.

Yes, he called me Baby Doll. Dad’s been dead a few years now—I don’t mind telling you he used to call me Baby Doll.

I put on a plastic rain coat I bought on a lark, once, and never wore. It ended up being a perfect cover for the ash fall. I wet a handkerchief to wrap around my nose and mouth, though it didn’t work as well as I hoped.

Walking through the streets, looking for my cat, was like walking on the moon. The ash was very fine, but so persistent. It covered everything, though it slithered off the plastic of my coat. After about half an hour, I couldn’t handle the ash anymore and came home— hoping Bonzo would be smart enough to find cover.

During the day, the ash cloud would sometimes thin out, leading us to hope the worst was over. Then the ash would thicken, the day darken again. I must admit to being more than a little worried about how long the ash would fall. Would we be evacuated if it fell for days?

Were we in danger?

Towards evening, we heard a faint meow at the back door. I opened it, and there on the step was a mound of ash with two brilliantly blue, and really pissed off eyes. Bonzo had made it home.

The ash fell throughout the day and into the evening. The darkness was oppressive, the acrid smell overwhelming at times. Sometime during the night, though, it finally stopped. When we woke the next day, we woke to another world. Ash covered everything.

I used to smoke in those days. I had run out of cigarettes, and we also needed milk and some other odds and ends. We couldn’t drive because of the ash, but there was a neighborhood store a couple of blocks away. I knew the store would be open—you’d have to bury that store under lava for it not to open—so I again donned my plastic coat and set off.

If the walk during the ash fall was unnerving, the walk the next day was surreal. You could see tracks of animals, including that of a bee that had become so weighted down, all it could do was squiggle along the sidewalk. Bird tracks, cat tracks, other small critters—no people though.

People were out and about, primarily shoveling ash off roofs, because the weight was enough to cause some real concerns. Others, seemingly indifferent to the effects of mixing ash and engine, were out driving, and their cars would send up clouds of acrid dust. Some of our more enterprising neighbors built a speed bump of ash mixed with water, which worked pretty good, until the street crews knocked it down.

For the next three months we cleaned up ash. In the beginning we wore a lot of masks, and some folks took off for ashless climes. Silly, really, because bad stuff happens everywhere. If you’re going to leave a place, you leave it before the bad stuff happens. Otherwise, you’re just moving from bad stuff to bad stuff, like a ball in a pinball machine.

My Dad used some of the ash from around our place to mix into cement for a new sidewalk. Other people created souvenir statues from the ash. I bought a t-shirt that said something about the mountain and Yakima, but I can’t remember the words now. Probably something that seemed clever then, but would be stupid, now.

A day by day account at the Yakima Herald Republic.

The Mount St.Helen’s photo essay.

HTML5 Specs

Progress Element: what I’ve found

To recap my weekend effort with the WebKit nightly implementation of the HTML5 progress element:

  • I created a application that uses the progress element and provides a text-based fallback for the element. You need to use setAttribute and getAttribute to get the progress element’s value attribute, as accessing the attribute directly on the object only works when progress is implemented in the browser. Apple’s VoiceOver seems to only audibly announce the state of the progress bar when it first receives focus. I can’t test with Firefox and NVDA on Windows, as Firefox has not yet implemented the element.
  • I created another application that provides a graphical progress bar fallback using two div elements. I also use ARIA to provide audible signals of progress bar state. During this experimentation, I found that you can’t change the background-color of the progress element, as this will wipe out the progress effect.
  • I created a third application, this time embedding the graphical progress bar fallback directly in the progress element. This approach works, but is invalid, since the progress element does not allow flow content. The assumption we take from the allowable content is that we’re supposed to accept a text-only progress bar fallback. This assumption of text-only fallback completely disregards the state of the art when it comes to progress bars that exists today.
  • I created a indeterminate progress bar application today. I discovered that you can’t change height or width of the progress element after all. If you do change the progress bar’s style setting, it adversely impacts on the indeterminate progress bar display. You have to accept the exact presentation of the progress bar, as determined by the browser. Frankly, I’ve never been overfond of the “blue gel” progress bar for Apple, and I think the progress bars, as implemented in WebKit, are ugly. Again, the indeterminate progress bar completely ignores the state of the art of “throbbers” that exists today. Can you see using this progress bar in Twitter?

I would move on to testing other new HTML5 elements, except for one small problem: the majority of new HTML5 elements have no real world implementation. Even many of the input elements, which have been around for six years have no implementation, or only partial implementation in one user agent, Opera.

As I wrote in an email to the HTML WG:

There are many new and modified elements in the HTML5 specification that do not have any implementation, and several that only have partial implementation by one User Agent. There are no implementations of any of the new or modified elements by any User Agent other than browsers (such as in authoring tools, or WYSIWYG plug-ins). Lack of implementation, or plans for implementation, especially when an element has been part of the WD for years, seems to meet the criteria for “features at risk”. Features at risk are those most likely to be challenged during Last Call, which could impede progress of the document through the Last Call process.

We get so caught up in the gee whiz newness of HTML5, and all its perceived glamor and sexy techiness that we forget that, for all intents and purposes, three-quarters of the specification is untried.

Just Shelley

Car advice

OK, time to ask the auto gurus among you for some help.

My car has had a relay clicking sound in the dash for some time (driver’s side, left of steering column, bottom part of dash). It occurs erratically, though lately it’s become much more frequent. The sound only occurs when I’m driving, and seems to be related to the position of the RPM indicator. I swear it occurs more frequently when the weather is warmer, too, but that could be my imagination.

In the last week, I’ve had my dashboard instruments (tachometer, speedometer, and fuel indicator) peg out a couple of times, and go zero once, but they always return to normal. The battery light sometimes comes on when the problem happens, but turns off almost immediately.

The car runs fine, and the battery and alternator are both new. The repair shop couldn’t see any short when the car was in for some fairly major work a few weeks ago, but I’m not sure how good this shop is when it comes to wiring problems.

I should probably take it into a Ford dealer, but I just spent a massive amount of money on it a couple of weeks ago. I really hope to have a good idea of what’s happened before I take it into the repair shop again, because it seems that every time I take the car in for a fix, something gets fixed, but this problem isn’t it.

The car is a 2002 Ford Focus, with 80,000 miles on it.

If anyone has any suggestions, please send me an email, or maybe tweet something. I’m really afraid to take the car out on the open road, but I just don’t have money to keep taking it into the repair shop.

HTML5 Specs

Cross-browser implementation of the progress element

A useful coincidence: just after I wrote my concerns about the progress element, the WebKit nightly contains the first implementation of this element.

I created an application to test the element. It works as I expected, and is somewhat accessible, though Mac’s VoiceOver would only voice the progress when the element first receives focus. Note, support for the element is only in Webkit nightly on the Mac.

I created a cross-browser version of the application that should work in most modern browsers—modern meaning IE8, not IE5.5, IE6, or even IE7. I had a heck of a time with the application.

The first challenge was the fact that IE8 doesn’t allow dynamic styling of the progress element, even if you use an HTML5 shim. What was more surprising was that Webkit on the PC and Chrome had problems with the progress element, period. Both kept giving me errors about a progress element within a div element, and neither would allow any form of dynamic access.

If you try to emulate the progress element’s effect, using the actual progress element in browsers that don’t currently support the element, setting the background-color for the element wipes out the progress effect with the Webkit nightly. Other than setting width and height, you can’t style the element. Or at least, I’m not sure how to style the element using general CSS properties.

I had to create a separate div element for those browsers that don’t implement progress. To make it work, I tested for progress element support, and if the browser does not support the element, turn off its display and turn on the display of the div element workaround. I had to test on the element’s form property to see if progress was supported. If you access the element, and it isn’t null, and the form property is defined, then the progress element is supported. You can’t test using nodeName, because all browsers return PROGRESS. Unfortunately, there is no elegant way to test for type of DOM object, such as HTMLProgressElement. There’s a hack I found at Sam Ruby’s weblog but that doesn’t work for IE, and again, Chrome and Webkit on the PC had problems with any programmatic access of the element.

You can’t provide a text description of the percentage by using the element’s innerHTML property. I didn’t try creating a new text node and attaching it to the progress element, but I don’t expect this approach to work, either.

You also can’t set a minimum value. The test case the WebKit developers attached for the new element uses the dir attribute to “reverse” the display.


I checked the HTML5 spec definition for progress again and found:

Content model:
    Phrasing content, but there must be no progress element descendants.

The HTML editing and WYSIWYG tools and validators are just going to love this. Anyway, supposedly this does mean that the element can take text. This must mean, then, that the Webkit implementation is incorrect.

second update

I created a variation of the application that embeds the fallback approach within the progress element itself. This seems to work fine. It cuts down a couple of lines of code, and at least looks a little more graceful (though it’s not valid). Note that I had to turn off the display of the elements by default, as Webkit nightly sets the background on the progress element to be transparent by default.

Last Update

The WebKit installation is most likely correct in its handling of the text for the progress element. According to the specification:

Authors are encouraged to also include the current value and the maximum value inline as text inside the element, so that the progress is made available to users of legacy user agents.

Though not a directive to the user agents, we have to assume from this statement that UAs are not supposed to display the text if the progress element is supported. However, the direction is unclear, one has to make an assumption that this is what’s happening in the browser.

This also means that if a person wants to include a text description of the progress, as I do in my original approach—something that happens frequently— you can’t. Instead, you’ll have to overlay the progress element with a div element and add the text to it.

You also have to use getAttribute and setAttribute to get and set the element’s value attribute. Accessing the attribute directly only works when the element is supported.

Frankly, I will never use the progress or meter elements. They are inferior, less accessible, more cumbersome options compared to what we have today. That the elements were poorly thought out is obvious when one tries to actually implement them.