Re: ALT content question

>   Shouldn't the TITLE attribute convey the information about the
>   destination of a link ?
>   
> I have only tried two, by I have yet to find a browser that does anything
> useful with the TITLE if it is annotated onto this anchor in the HTML.
> This raises the question: "For the purposes of what timeframe are you
> asking?  Now or in the ideal future we want to migrate toward?"  In 
> what follows I will try to separate responses related to a) best workaround
> now and b) framing requirements for a better solution.

The discussion surrounding timeframe are important enough that I'd
like to start a new thread about it.

Some comments on this particular item.

> Given the currently deployed client behavior [range] the best workaround
> now is to use the ALT tag for an alternative anchor content (like its
> acronymous name) and not for a descripiton of the image.

OK, that's one point view, that I tend to agree with.
 
> In terms of framing the context for a solution, I 100% agree that the
> model of the process has to distinguish three things:
> 
> 	1 - the a_priori characteristics of the resource

I appreciate the s in characteristics.

> For the purposes of here-and-now guidelines it is absolutely
> necessary to deal with the demographics of browser behavior
> for the browsers (including versions, sigh) in the field now.

I want to understand why "it is absolutely necessary". Your answer
will probably better fit in the timeframe thread.

> Descriptions for sensitive maps should also embed all the links
> in the map.

Client side image maps solve the problem using a different but similar
mechanism.

> As the size of the display pipe
> goes down, more and more of this infrastructure wants to migrate
> into implicit information displayed only on explicit request and
> not be presented in the default "display" view.

One would hope that Style sheet will help achieving that.
 
> Appropriate accomodation of browsing is not just changing or
> stripping fonts.  The focus or viewframe is going to be scoped
> differently, as well.  Not only breadth of topic but in depth of
> detail, as well.  One way is for the content form to contain
> priorities and the preferences to play off the priorities to
> prune the data presented. 

I'm not sure a priority schema is required, vs. the existing
presentation/structured-content dichotomy that SGML is championing.

> The navigation buttons
> would not turn into presented audio but be aliased to standard
> navigation commands.  

Good point.
I guess something in the line of LINK and meta-data is needed (more
semantics in the markup).
 
> The more we expand the data model, the more important it is to
> understand that there will want to be filter-driven hiding on the
> way to the non-visual browse display.
> 
> What do you think, Mark?  Am I in the ballpark?

Who is Mark ?

Received on Tuesday, 10 June 1997 11:17:54 UTC