Easy Reader

In reaction to my latest article for A List Apart, on FigureHandler, many folks have boldly claimed that this sort of thing should be done server-side. Below are my thoughts on the matter as posted as a comment in the article’s discussion thread.

Many of you have brought up that this should be done server-side and, while I agree that it could, it would need to be done in the most flexible way possible (which many won’t bother with). You see, what this script allows quite easily is redesign; a designer can change page layout—of an entire site or section by section—without ever having to touch the back-end. It also allows for different columns to receive different figure classification schema.

If this were done on the content-entry side (as some have suggested), the image classifications would be stored in the database (or XML or whatever) along with the rest of the content HTML. That means that if the design were to shift to a wider column (for example), the figures that once occupied a half-column, may no longer continue to do so, making the classifications hard-coded in the HTML incorrect.

The only way to truly do this flexibly on the back end (as far as I can see) is to leave the classification step to be handled by a function which pre-processes the page output, dynamically assigning the classifications to each figure based on values obtained from the CSS for that page. Essentially, the script would need to go through the same steps as the JavaScript, but it would need to be able to go the extra step of determining applicable CSS rules to obtain the column width. Thankfully, most server-side languages support some means of DOM walking (albeit sometimes in less-than-desirable ways), but, as far as I know, none have a CSS parser, so you’d likely need to write that as well. From a server overhead point-of-view, I imagine that preprocessing would be fairly costly (most DOM-related stuff is), but the output for each page could be cached, reducing it somewhat.

If you’re interested in doing something like this, goodonya. I’ve built you a pretty decent roadmap for implementation, but I don’t imagine it will be easy to get it up and running. That said, I wish you luck…it would be yet another great tool for enabling designers to create consistent layouts with figures.

First off, let me preface this by saying I just got back to the East Coast after catching a red-eye from San Francisco on Saturday night, so if I seem a bit incoherent, that’s likely why.

In perhaps the most intellectually-stimulating session at The Rich Web Experience, Alex Russell (of Dojo Toolkit fame) tackled the topic of Standards Heresy.

For those who are not aware, Alex was once a staunch standards advocate who has turned to what he considers, “the dark side.” In truth, he’s sick and tied of the dysfunctional nature of the W3C and other similar organizations and I can’t say I blame him. As his session pointed out, the W3C has 60+ paid, full-time staff and yet we saw literally no movement on either (X)HTML or CSS for over five years. That is a travesty.

In my opinion, fault lies not with the individuals on the various committees and sub-committees, but rather, with the process. And this isn’t just a problem in the W3C, an organization comprised almost entirely of representatives from the various software vendors (Microsoft, AOL, Opera, etc.) which pay tens of thousands a year to take part. Look at what’s happening with JavaScript 2 in ECMA. Or HTML5 for that matter—just because it is an “open” organization which “anyone can join” doesn’t make the WHAT WG any better. They are all flawed because the process is flawed, and I think that is Alex’s main point (despite his assertion that the WHAT WG is not dysfunctional).

So why is the process flawed? Well, for one, spec writing is largely an academic undertaking. In many cases there are invited experts in a Working Group (such as Andy Clarke in the CSS one), but, for the most part, specs are written by people who are not in the trenches. As Alex rightly points out, in fact, many times, the specs are nothing more than an official blessing of some proprietary technique or technology created by a member company. And good ideas that may be very useful to designers or developers are lost because of internal politics or because a browser vendor thinks it would be “too hard” to implement.

Which brings me to Alex’s “heresy.” In his session, he proudly declared himself a heretic because he sees a need for innovation in (X)HTML which is currently unavailable because the specs are not evolving quickly enough. I feel his pain, but I think he is looking at the problem the wrong way. He sees the spec (and web standards in general) as stifling innovation. I see web standards as facilitating innovation. After all, were it not for the firm foundation of well-formed documents and a unified DOM (no matter how piecemeal the implementations), we’d still be writing spaghetti code whenever we tried to do anything with JavaScript. It is because of web standards that we can write clean JavaScript and that we can make truly innovative interactions that take us beyond what is allowed for in the specs themselves.

But back to Alex’s complaint…as his example of how Dojo is heretical, he showed this code example:

<div dojoType="dijit.form.HorizontalSlider"
     name="horizontal1"
     onChange="dojo.byId('slider1input').value=arguments[0];"
     value="10"
     maximum="100"
     minimum="0"
     showButtons="false"
     intermediateChanges="true"
     style="width:50%; height: 20px;"
     id="slider1">
  ...
</div>

The problem that Dojo is attempting to solve here is the inclusion of a slider form control, which does not exist under the current HTML Forms spec. In order to function, the widget requires several custom attributes to be placed on the element to provide information to assist in the creation of that slider. The fact that Alex “cannot” add these attributes to the document and maintain XHTML validity is a major source of annoyance for him and part of why he has decided that validation is no longer important.

But the truth is that Alex could make any or all of these attributes available to whatever elements he wants and still have a validating document by simply creating a DTD (based on any existing (X)HTML one) to include them. After all, the X in XHTML stands for extensible…the language is meant to be improved. Sure, there are some standardistas who think we shouldn’t muck about with the standards, but the powers that be put that extensibility in there for a reason (and I don’t think it was just as a tease). By extending the language to mix in features we desperately need, we drive innovation and, who knows, perhaps someone will take notice and add our extensions into the next version, thereby driving the evolution of the language so many of us desperately want.

The same goes for CSS. The W3C made CSS extensible by allowing for custom properties utilizing the -*- syntax. Chances are, you’ve come across this when implementing -moz-border-radius or -webkit-border-radius (which, honestly, both seem superfluous to me when the CSS3 spec includes border-radius as an actual property…why not just support that?). In my mind, this is ripe for use in extension of CSS, not by individual browser vendors (as that is proprietary and closed), but by us (in an open, cross-browser/cross-platform way) to achieve what we want or need that CSS currently does not offer us. That was the basis for my work on gFSS (an experiment in presentational Flash generated from CSS, debuted at Web Directions North this year) and another project I will be releasing in the next few months.

So, long story, long, I don’t think that Alex is a heretic. I think he can make a solid case for extending the language (and the interface) of the web for his particular needs (or the needs of his toolkit) as long as he backs it up with documentation in the form of a custom DTD.

An aside

I do have one problem with what Alex wants, however (or at least what he chooses as a code example) and that problem is the extension of the language, but rather the way in which it was done (i.e. the DIV in his example will degrade to nothing without JavaScript enabled). Dojo supports WAI-ARIA to improve the accessibility of this and many other widgets, which is commendable, but that extra markup is only generated when the Dojo methods are run. If JavaScript is turned off in his example, no form control is available whatsoever.

What I’d prefer to see is something like this:

<select class="dojo-form-horizontalSlider"
        name="horizontal1"
        showButtons="false"
        intermediateChanges="true"
        id="slider1">
  <option>0</option>
  <option>5</option>
  <option selected="selected">10</option>
  ...
  <option>100</option>
</select>

There’s nothing that could keep Dojo from parsing that bit of XHTML and gleaning from it what it needs to make the slider. And now, when Dojo doesn’t run, there is a degradable interface for the user to adjust the setting. Sure, it may not be nearly as nice, but at least it works. Plus, it allows Dojo to be added as a progressive enhancement, which is what it should be.

And to make this valid syntax, the Dojo team just needs to augment the XHTML 1.0 Strict DTD like this to include the custom attributes:

<!ENTITY % Boolean
  "(true | false)"
  >
...
<!-- attributes for Dojo Toolkit
  showButtons           display buttons (boolean)
  intermediateChanges   display intermediate steps (boolean)
-->
<!ENTITY % dojo-attrs
  "showButtons          %Boolean    #IMPLIED
   intermediateChanges  %Boolean    #IMPLIED"
  >
...
<!ATTLIST select
  %attrs;
  name        CDATA          #REQUIRED
  size        %Number;       #IMPLIED
  multiple    (multiple)     #IMPLIED
  disabled    (disabled)     #IMPLIED
  tabindex    %Number;       #IMPLIED
  onfocus     %Script;       #IMPLIED
  onblur      %Script;       #IMPLIED
  onchange    %Script;       #IMPLIED
  %dojo-attrs;
  >

Sure, it takes a little extra work, but at least it gives users of the Dojo Toolkit the ability to validate their documents, which will help reduce potential CSS and JavaScript conflicts and errors (just one of the many benefits of web standards). Beyond that, it takes advantage of the extensibility of the language to facilitate innovation, and isn’t innovation what we all really want to see?

Back in 2005, I wrote a piece about IE’s abysmal generation of NAMEd elements via the DOM (which, interestingly enough, has proven to be one of the most popular posts on the blog, pointing to the fact that this is an obvious pain point for many DOM scripters out there). The the time, I wrote

function createElementWithName( type, name ){
  var element;
  // First try the IE way; if this fails then use the standard way
  if( document.all ){
    element =
      document.createElement( '< '+type+' name="'+name+'" />' );
  }else{
    element = document.createElement( type );
    element.setAttribute( 'name', name );
  }
  return element;
}

It was a complete hack, but it worked. More importantly, however, it began a discussion of a better way to fix the problem in a cross-browser way. The best solution offered was Anthony Lieuallen’s very efficient one-time function definition:

function createElementWithName(){}
(function(){
  try {
    var el=document.createElement( '<div name="foo">' );
    if( 'DIV'!=el.tagName ||
        'foo'!=el.name ){
      throw 'create element error';
    }
    createElementWithName = function( tag, name ){
      return document.createElement( '<' + tag + ' name="' +
        name + '"></' + tag + '>' );
    }
  }catch( e ){
    createElementWithName = function( tag, name ){
      var el = document.createElement( tag );
      // setAttribute might be better here ?
      el.name = name;
      return el;
    }
  }
})();

And now Brian Adkins has refactored the script to be even fewer lines of code:

var createElementWithName = ( function(){
  try {
    var el = document.createElement( '<div name="foo">' );
    if( el.tagName !== 'DIV' || el.name !== 'foo' ){
      throw 'create failed';
    }
    return function( tag, name ){
      return document.createElement( '<' + tag + ' name="' +
        name + '"></' + tag + '>' );
    };
  }catch( e ){
    return function( tag, name ){
      var el = document.createElement( tag );
      el.setAttribute( 'name', name );
      return el;
    };
  }
})();

Geat job Brian, thanks for sharing.

You may recall that the DOM Scripting and Microsoft task forces, in collaboration with JS Ninjas, had been compiling a list of issues, needs, and wants for IE.next over the last few months (a list many of you contributed to as well, via your feedback). The list was to focus on what we wanted to see happen in terms of JavaScript support (as IE7 didn’t get much of an update in that area), but when it came down to it, there were other areas we really felt needed some love.

The list

Last week, our groups voted for what we each saw as priorities and those votes were tallied to create a final list for me to present in Redmond. Though there is obviously a great deal more we want to see in IE.next, we felt several things were critical and wanted to focus on those as a starting point.

Tied for first place, in order of priority, were some sort of fast, arbitrary node-matching API and better error reporting. In the realm of DOM Scripting, node-matching is key (just look at the number of scripts out there performing node matching based on CSS selectors, etc.), so being able to tap into a native XPath implementation (which we generally favored over the Selectors API) would greatly improve the speed of script execution. As for the error reporting, perhaps Justin Palmer (of JS Ninjas) said it best:

We could possibly find ways to fix all the other problems if we could tell what the hell was breaking and why. Without better error reporting, the remaining stuff on that list is just giving us a bigger gun to shoot ourselves in the foot with.

Next up in our list was a desire for mutable DOM prototypes. This would address the issues that arise from IE’s implementation of DOM objects in JavaScript, where elements of the core DOM are not derived from the standard Object prototype. While not technically a standards-support issue, this request does not conflict with standards and it does provide JavaScript developers with the ability to address some of the issues the IE team may not be able to address themselves in the next release. As Andrew Dupont (another Ninja) remarked, I think it’s reasonable to ask that a DOM implementation in JavaScript behave like it’s part of JavaScript.

Next up was a biggie: bring IE’s event system in line with the W3C event model. This has been an issue for a lot of developers and the code to equalize the two event systems makes up a significant chunk of all of the major JS libraries. Getting IE to implement the W3C event system would be a real boon for standards support and would drop the size of many libraries considerably.

Finally, the last of our top 5 was not a JS issue, but rather a CSS one: implement generated content. I don’t know that I really need to get into the reasons why this would be really nice to have.

Two “honorable mentions” were included in the list as well: fixing the issues with getAttribute() and setAttribute() and starting to implement some of the features of JS 1.7 (such as block-scope variables using let, etc.).

Not willing to let the IE team off that easy, the document presented also highlighted several other issues which really need addressing including (among others)

• fixing CSS bugs (including collapsing adjoining margins and z-index);
• various form control fixes (including implementations of the button element, labels, and the disabled attribute);
• correcting its support for object;
• adding support for the q element (which should be a breeze once generated content is enabled); and
• fixing attribute issues (such as alt being used for a tooltip, cite not being supported on q and blockquote, and summary not being supported on tables).

The meeting

In Redmond, I met with Pete LePage, a Product Manager at Microsoft Web Platform and Tools, and several other key members on the IE team. We discussed the list and its implications in great detail for nearly two hours. While I am not at liberty to discuss all of the details of the meeting, I can say for certain that the group I met with was keenly aware of the issues we brought up and are eager to address them. One team member even said that he could have easily guessed our top 5.

The one concern they have—especially with regard to the event model and getAttribute()/setAttribute()—is that any adjustments they make to bring IE in line with the standards not “break the web” for the large number of sites using the proprietary IE event model, etc. We discussed this particular topic at length as it is a valid concern and I’m happy to say that I think we’re close to a solution on that front.

I came away from this meeting with a real sense of hope about where IE is going and am really encouraged by their willingness to engage the standards community (and web developers as a whole) in dialog like this. We did not resolve every issue in our two-hour talk, but I was assured that this was only the first of many steps toward improving IE.next. The IE team wants to continue this conversation and to continue to elicit feedback from the web community as a whole as things progress.

At SXSW, I gave a sneak peek at the new bizhub Pro site I built for Konica Minolta and, in particular, the “scroll and flash” usability enhancement I added to the product pages. I have gotten a lot of questions about it and the technique even generated some discussion over on Geoffrey’s site. Well, the site finally launched and you can now see the “scroll and flash” for yourself.

To check it out, go to a product page (the bizhub PRO 920, for instance) and click one of the links on the upper right of the focal image and watch the show (or you can go directly to a bookmark). AJAX is used to refresh the page content (with bookmarkable links) and then the “scroll and flash” takes over. Feel free to take a gander at the JS file to see how it’s done.

I have to give it up to Shaun Inman and Thomas Fuchs as it was their hard work that made this easy for me to do.

Update: It looks like someone has not taken proper care in managing these pages since I left Cronin and Company (where I had built the site), so not all of the links appear to be working (because their anchors have been removed… tsk, tsk). I’ve let Cronin know and hopefully that will be fixed soon.