From: "Mike Schinkel" <[EMAIL PROTECTED]>
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
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
