Re: Moving longdesc forward

Benjamin Hawkes-Lewis, Wed, 4 May 2011 08:01:07 +0100:
> On Wed, May 4, 2011 at 2:33 AM, Leif Halvard Silli:
>> Laura, could you add text to say that implementations which open the
>> longdesc URL in a window or tab, should open it in a *new/blank*
>> window/tab
> 
> I do not think we should add this as an expectation or constraint.
> 
> Not all user agents support multiple browsing contexts.

They do not need to implement it then, just as some UAs don't implement 
CSS. I see no problem.

> You mention that users are not usually given a choice about where
> to open @longdesc, but there's no particular reason why they
> should not be given the choice. For example, if I open a context
> menu on a link I am usually given the choice of opening it the
> same or a new browsing context.

I meant: in contrast to ordinary links.

>> and ensure that - when closing the window/tab, the user is
>> taken back to the originating window?
> 
> I do not think we should add this an expectation or constraint.
> 
> It would be poor usability to reuse a standard feature (windows/tabs)
> but then make it behave differently in an edge case to other instances of
> that feature.

Opera has to decide details for themselves. They can let the resource 
be opened in new window if they can't make Tabs work as it should. (I'm 
Mac user and I suspect that Opera for Mac is not as bug free as Opera 
for other platforms - may be that plays a role too.)

> Your description of Opera's behavior does sound problematic, but if 
> one needs to introduce such a difference to correct it, that argues
> strongly in favour of implementing @longdesc a different way for 
> that user agent,

Agree. (In my head lingers a comment from Charles that @longdesc takes 
only 15 minutes to implement. Yes, probably, if one has a good overview 
over all details of how it should function.)

> e.g.  using inline replacement, defaulting to 
> opening in the same browsing context, or using a sidebar.
> 
> Chaals, it would be great to have your view on this.

+1
-- 
Leif H Silli

Received on Wednesday, 4 May 2011 12:38:50 UTC