[uf-discuss] Tutorial on AHAH (such a cool technology!)
pmw57 at xtra.co.nz
Mon Mar 5 18:18:47 PST 2007
From: "Mike Schinkel" <mikeschinkel at gmail.com>
> What's incredibly ironic is someone such as Eric Meyer who focuses on
> presentation would make such an error. Heck, his example presentation
> not have visible controls; at least he could have included a "help" link
> 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
> 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.
>> 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
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
> 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
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
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
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
> 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
> 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.
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
> On a similar note, one a partner of mine is would on, how do you feel
> scraping a document to find heading tags (H1..H3) so as to build a table
I know what you're on about because Web Developer already has a View
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.
> comments were focused on ensuring the URLs were treated right. If you are
> content author, it's all yours!
Dead right, for URLs to work properly the href must link to to a usable
is enabled then it can fiddle around and perform its magic, just so long as
it works and doesn't take too long.
More information about the microformats-discuss