[uf-discuss] Tutorial on AHAH (such a cool technology!)
mikeschinkel at gmail.com
Tue Mar 6 01:33:16 PST 2007
Paul Wilkins wrote:
> 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
> 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.
heh. If I didn't have so many other projects, I'd jump on it (would be a
good way to learn JS.) Maybe after I finish all my other projects... :)
> > 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.
Strange; S5's intro DOES print correctly in outline mode, but Roger's
AHAH slideshow does not.
> 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
That looks like a good middle ground.
> 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
I don't know if you are aware, but I made a big deal about that issue on
this list several months ago but it seemed that most people didn't feel like
my concerns were going to be an issue. So rather than beat a dead horse, I
moved on to work in other areas. I still monitor this list occassionally,
but not in real time.
> In light of this, my own development is going to feature
> 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.
Actually, there are solutions I've proposed I think are better, but they
fell on deaf ears on this list. I can dredge them up again if you like.
> > 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.
Well, that would break all of Microformats and sounds like the problem is
the rogue webmaster not realizing that existing rel tags need to be
maintained. I can see a potential for such a problem, but in the same
context I can see that webmaster creating far greater problems than just
> > 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.
can take offline is anyone objects): would it be possible to pipeline in a
common file with a single scanner that any such widgets could attach to? (I
> > I think it would be a heavy burden to place on a
> > 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
> itself, so that the content author just has to bring in
> the code and apply a rel attribute and a few id
I don't see it. Can you give code examples?
> > 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
> 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.
5 seconds is a lot! Maybe there are better techniques, like having the
links be inactive and greyed-out until available?
http://atlanta-web.org - http://t.oolicio.us
"It never ceases to amaze how many people will proactively debate away
attempts to improve the web..."
More information about the microformats-discuss