Categories
JavaScript Technology Web

The Bubble Popper

Recovered from the Wayback Machine.

Over at ScriptTeaser a participation exercise where you can help pick what Ajaxian tech is hot, or not, for a weblog. Feel free to jump in, as opinions are not only welcome, they’re being actively recruited.

I have one more for the list: The Ajax Bubble Popper. When enabled, any post that contains an over abundant use of Web 2.0 terms and fuzzy feel goodness, as well as earnest assurances that the ‘bubble is not over, no sirree’, will automatically *POP* before you even have to spend any time on it.

Come to think of if, this is probably more of a Firefox extension, since I never ever say the bubble is not ove…

*POP*

Categories
JavaScript Technology Weblogging

Back to work

Recovered from the Wayback Machine.

I’m looking at all the possible areas where one can apply Ajaxian technologies to a weblog. Some uses strike me as just pushing the bits around for the fun of it. Others, such as my live preview for comments, seem to be so handy they’re worth having JavaScript turned on.

Before blasting script, willy nilly at my sites, I wanted to gather opinions from those most impacted: you. Of the following, which do you consider useful as compared to frivolous? Are there any you consider important enough to introduce invalid XHTML?

  1. Live Preview, where a comment is previewed as the person writes it.
  2. Spellcheck of comment. Which of the two options: Live spellchecking or the current open new window spellchecking.
  3. In-place editing of comment as compared to server-side editing of comment (as currently enabled at this site).
  4. In-place editing of comment as compared to having no post-comment editing.
  5. Live update of list of comments or posts, as you’re reading and without page refresh.
  6. Expanding comments in the main page when the comments link is clicked (in-page reading).
  7. Animated or otherwise activated menus, such as the one currently implemented at ScriptTeaser.
  8. Dropdown menus that expand to show all menu options.
  9. Summarized posts on the front page, which then expand when a plus sign (’+’) is clicked.
  10. Be able to turn photos off, and have the site remember to filter photos.
  11. Only display photos if a button of some form is clicked (or if JavaScript is disabled).
  12. Expand code blocks on demand.
  13. Being able to re-arrange weblog page and have the new arrangement ’stick’. (IE being able to size main content, sidebars, move sidebars, eliminate sidebars, and so on.)
  14. Being able to pick stylesheet.
  15. Being able to choose font: family and size.
  16. Being able to change site colors based on a pick list.
  17. Autosaving of longer comments, as they’re being written.
  18. Expandable metadata sections for each post.
  19. Mouseover that pop up information associated with post, such as related posts.
  20. Use of microformats for reviews, events, where microformat exists.
  21. Being able to access Google/Yahoo map through link, metadata, expandable section, or live embedding when post is somehow geographically related (such as with photos, events, and so on).
  22. Being able to add your tags to post.
  23. Being able to add other metadata, such as related links, to the post.
  24. Being able to expand a photo in the page.
  25. Add a slider to darken or lighten the page text.
  26. Adding a live chat feature.
  27. Being able to opaque everything but a post you’re currently reading (remove distraction).
  28. Persist commenter’s name, email, and URL.
  29. Live search (posts/comments returned as search term being input)
  30. Games. Yes, games. Just like the paper mat you used to color on when you went out to the pancake house when you were a kid.

If I missed any ideas, let me know. Appreciations for the feedback.

Categories
JavaScript

Dojo creator interviewed

Recovered from the Wayback Machine.

Agile Ajax is interviewing Dojo creator Alex Russell (via Ajaxian) and I was pleased to read the comment about closure:

As a language, JavaScript is still horribly misunderstood. All real power in JavaScript comes from understanding closures, the “everything is always mutable” property, and the prototype chain.

These are actually concepts I covered in my book, though they are complex and I was concerned about the ‘learning’ part of Learning JavaScript. However, these are concepts that pop up in conversation among the Ajaxian set, and in regards to the Ajaxian libraries. As such, I thought it was important people be aware of what they are.

Update

Second part of interview. Some translation: GWT is Google Web Toolkit, a Java/Ajax framework. COMET is a description of streaming Ajax accessed content, rather than using polling. Think of IRC channels, and you’ll see streaming in action. Apollo is Adobe’s new effort to merge Acrobat and Flash. Dojo uses Flash for client-side storage that extends beyond the cookie limits.

Categories
JavaScript

‘ware

The Head Lemur sent me the link to this important story about a security threat based on JavaScript. This is a tough type of event to prevent, because it is increasingly difficult to turn JS off–so much of online content is JS dependent.

Typically most attacks of this nature will occur because malicious script is embedded into a web site through a cross-site scripting attack (XSS). The only way to prevent these is to scrub your form entry fields to make sure script or other unwanted material isn’t getting through. (Which reminds me that I have to check my new sites’ comments, to make sure these are ‘clean’.)

This is a threat, but I would say it’s of secondary concern compared to some others. No, don’t shoot me. It requires that a lot of factors be in place before it can work: your router not have password protection, your printers always be on and have a built-in web server and so on. The more sophisticated your home network, the more vulnerable you are. However, the more sophisticated the home network, the more we have to assume you know how to protect such network.

Still, not sure what we can do so plug such breaks. Would be a shame to start crippling JavaScript, just when it started to get interesting. As for ‘firewalling’ the browser, I agree that browsers need to make us more aware of what is happening behind the scenes. I’m also all for extensions such as Firefox’s NoScript to ‘whitelist’ JavaScript sites (though XSS can make this mute if the whitelisted site provides openings for malicious JavaScript insertion.)

(Slashdot coverageOriginal press release and white paper on the exploit.)

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.