Re: GL 1.3 vs GL 2.4

On Nov 1, 2005, at 1:31 PM, John M Slatin wrote:
> After reading Andi's response (which I now can't find!), I'm still
> concerned about "navigational features" in technologies other than  
> HTML.
>
> Even if it's true that links are the *only* navigational features in
> (X)HTML (and are thus covered by other SC), are there other  
> technologies
> where that isn't true?

Warning: semantic and philosophical rathole ahead. (I'm getting good  
at these.)

Navigation in the context of HTML (minus script) is a relatively easy  
thing to isolate because of the very architecture of the Web. I would  
define it as anything which when activated results in a new URI: that  
is, anchors and submit buttons. Another way of putting it is:  
anything that the back button can undo.

Throw script into the mix, and things get fuzzy again. If I'm  
changing the overall state of the current document without calling a  
URI, I'm not technically _navigating_ anywhere, and I haven't changed  
state in a way that the server would be able to detect. This would be  
true if it were a form element or an image or any of dozens of  
possible interaction modes. This is a bright line, in my mind,  
between Web documents and Web applications.

When we get to Flash, et al., in my opinion, navigation is a much  
more amorphous concept. You can interact with the interface (note  
that I didn't say "document") via buttons and "movie clips", which  
can be anything from frame-based animation with up-down-over-out  
states to prepackaged components that can contain usable metadata,  
like Flash's video functionality.

But in all of this, nothing clearly fits my definition for HTML  
navigation. The biggest problem here is that there's no way to  
cleanly determine in many cases what, if anything, you're navigating  
_to_. There are two reasons for this: Flash objects are often (but  
not always) monolithic blocks of code; and none of the structures in  
place actually have URIs. So what you have here is lots of instances  
of changing state, but only a very subjective means of determining  
what components are actually navigation, and what it is to navigate.

Is it navigation when Flash goes out and pulls down a new URI? Flash  
objects open new connections all the time, to cache audio and video  
files, import smaller chunks of content, access Web services, etc.,  
and a lot of those are not the result of an explicit user request.

The definition of "navigational content" in the 25 June draft says  
it's "Something that allows the user to locate and/or move to a  
different piece of content than the one currently with focus." A game  
is nothing but a bunch of pieces of content to be interacted with.  
So, what is navigation in the context of a game? Is it everything, or  
nothing, or only what is needed to enter and exit gameplay?

SVG shares some of the philosophical troubles I've mentioned, though  
not many of the URI- and semantics-related ones. For one thing, it's  
rare that an app that uses SVG is actually composed solely of  
discrete SVG files, where you navigate from one to the next, as in  
HTML. It's more common that one SVG file acts as the user interface,  
and does those transactions (as in Flash) transparently. SVG also  
lacks semantics that determine what is and what is not "navigation"  
in the interface.

I think SVG is a good tool to clarify what I'm trying to say here.  
Let's say you have an SVG file that is a square with a black outline.  
When you activate a button, this SVG document goes out, reads an  
external SVG file containing a pattern, and displays it in that box,  
without shifting focus to it. Is that interaction, or navigation?  
Would it be navigation if the box was only 5% of the viewable area?  
30%? 80%? Would it be navigation if the pattern were already  
contained in the SVG file, so you didn't have to go out and get it?  
Would it be different if the content of that box were words instead  
of a visual pattern? If it were a single color in a linked SVG file?  
If it were a single color you changed via style? I think we'd have  
lots of different answers among the group as we changed those  
criteria. I also think the same is true if we start talking about the  
Ajax scripting model, because it raises many of the same questions.

As far as MathML does, this guideline wouldn't apply, because it  
doesn't have an interaction model. Anything related to navigation  
would be the user agent's job.

-
m

Received on Tuesday, 1 November 2005 22:30:34 UTC