[uf-discuss] Tutorial on AHAH (such a cool technology!)

[Paul Wilkins]

From: "Mike Schinkel" <mikeschinkel at gmail.com>
> What's incredibly ironic is someone such as Eric Meyer who focuses on 
> visual
> presentation would make such an error.  Heck, his example presentation 
> does
> not have visible controls; at least he could have included a "help" link 
> to
> his keyboard shortcuts!

If you mouse to the bottom right of the presentation (or press C) you'll 
find there are some minor controls, but you've got to either stumble upon 
them or know about them beforehand.

What's really needed is for someone to take the S5 system and built upon it 
an easily discoverable system for nagivation and control, but that would 
mean finding someone with the time to put together the interface.

> BTW, it seems one can press "T" to toggle and get a printable view.
> If he added visible controls it would sure be the heck out of Powerpoint 
> for
> the web!

Unfortunately T only switches the view from slideshow to content. The 
printout isn't affected from either view. Perhaps there needs to be two 
print stylesheets, and have them switched to match the view.

>> I don't like the idea of javascript scraping the page for
>> class names. Dustin Diaz covers this particular issue
>> very well in
>
> Did I say "class"?  No, I said "rel" ;-)

Class or rel, they're both handled the same, where some code typically has 
to go through every single element on the page and scrape up the wanted 
attributes.

ID attributes are different because the computer creates a list of them 
beforehand. The significance is that having several scripts scrape over the 
page after it's loaded can be troublesome. For example, if a hot finger 
clicks on an anchor before it's had time for the event to be attached.

In this case finding them via the id attributes isn't viable, so the next 
best thing to do it limit the number of elements that need to be searched 
through, to help the computer do its thing more quickly than if it were 
using some generic getElementsByClassName function.

At least some of them allow you to supply extra info to help narrow down and 
pleed up the search, like http://www.dustindiaz.com/getelementsbyclass

> Interestingly reading Diaz' article there were a lot of people with good
> points that disagreed with his suggestion. But whatever, I was more
> discussing an overall concept, not a specific implementation of Javascript
> or how to optimize it.  Seems like I accidentially hit on one of your
> hotbuttons, though? :-)

Code performance is one of those, that's for sure. I'm glad we're using the 
rel attribute here though, for I perceive some trouble down the road with 
class names.

With the growth in class names being used for purposes other than styling, 
there will be in a few years more and more trouble with them clashing 
together. Looking at the list of class names for microformats alone, 
http://microformats.org/wiki/existing-classes I can see names that have been 
used in previous created stylesheets.

In light of this, my own development is going to feature a slow down in 
class names for attaching javascript events, and instead focus on methods 
that should prove to be more compatible with less troubles in the future.

>> While it's convenient, it's slow, demanding,
>> and at high
>> risk of breaking.
>
> And microformats, as currently envisioned, are *not* at a high risk for
> breaking?

They *are*are at more of a risk of breaking, but it's the best solution we 
have at the moment.

> As an aside, rel="ahah" wouldn't be at a high risk of breaking
> because the author using the technique would author it so it didn't break
> (or can you see potentials where his authoring would break that are not
> abstract hypotheticals?)

Sure thing. Take for example the case where some webmaster decides to 
specify the relevance of outgoing links. He may have a script that goes 
through adding rel tags to certain known links and domains, and leave empty 
those that it doesn't know about.

That example is the problem I eventually tracked down, to help someone who's 
attributes weren't sticking, because another script that nobody had looked 
much at was playing around where it shouldn't have.

The good thing about the rel is that "The rel attribute specifies the 
relationship of the linked document with the current document." So 
rel="ahah" is perfect to state that the link goes out to some AHAH content.

> Also, how would Diaz' article apply if these AHAH links were littered
> throughout the document?  His article addressed what seemed like typically 
> a
> single widget, not multiple instances of the same widget scattered
> throughout a document.

The dilemma is when there are several types of widgets scattered throughout 
a document. Then each widget is going to be lining up behind each other, 
waiting for the chance to scan through and find the bits it needs.

> I think it would be a heavy burden to place on a
> content author to require them to write the Javascript code he talks about
> if they had to tag 10 different segments rather than just scan for <a
> rel="ahah">. I think these may well be two different use-cases that might
> deserve two different approaches.

It would be a heavy burden, so I'm suggesting that the javascript code he 
talks about is moved into the function itself, so that the content author 
just has to bring in the code and apply a rel attribute and a few id 
attributes.

> On a similar note, one a partner of mine is would on, how do you feel 
> about
> scraping a document to find heading tags (H1..H3) so as to build a table 
> of
> contents?

I know what you're on about because Web Developer already has a View 
Document Outline
http://chrispederick.com/work/webdeveloper/

The biggest issue at hand is if this stuff is happening after the page 
finished loading, that the user received feedback on when these things have 
finished and the page is ready for use. When a page appears on the screen 
people expect to be able to use it immediately. If there is some 5 seconds 
of waiting required (without feedback of some kind) before everything is 
ready, that's where the trouble lies.

> Anyway, I'm fundamentally not really a Javascript guy, I'm a URL guy.  So 
> my
> comments were focused on ensuring the URLs were treated right. If you are 
> a
> Javascript guy that can optimize that stuff so it is still usable for the
> content author, it's all yours!

Dead right, for URLs to work properly the href must link to to a usable 
document. If javascript isn't enabled it'll then still work. If javascript 
is enabled then it can fiddle around and perform its magic, just so long as 
it works and doesn't take too long.

-- 
Paul Wilkins