Hi,
"*just* accessibility" does not exist ;o)

I wasn't using the word "just" to imply importance here. I used it in the sense of "quantity". I value accessibility very highly myself.

Accessibility is not about blind grandmas using an old 386 with braille
keyboard, it is about an application being easy to use for us all,
regardless of the device we are using, the device ranges from a PDA,
iPhone, PS2 to a thin client in a corporate network that doesn't allow
modifyinf strict securoity settings or remote ssh access to a computer
that only allows using a text-based browser like Lynx, up to ease of use
for regular users too.


Funny that you should mention the iPhone, since there is no way at all to open an email message in Round Cube on an iPhone, but I digress . . . .

I haven't followed this bug from the beginning, so I'm not sure exactly  
what is affected, but if it is the title of the email that you click to  
read the mail, having it as an <a>-tag also allows one to click it with  
the middle mouse-button to open that email in a new browser-tab

Actually, the click event gets cancelled if javascript is enabled, so having the subject text be an <A> tag here does not allow special behaviors for opening in new windows/tabs. In fact, it is the ctrl-click in IE 7 for "open in new tab" that is the very source of this problem and the whole reason we are discussing it. If IE7 didn't have this bug, you would not be able to open this in a new tab. Remember it is a double click that opens a message in Round Cube. There is no other way to open it.

, so  
multiple emails can be opened together, it allows bookmarking emails, it  
allows saving the email locally and the back-button might work for paging  
between emails - of course this bug might be regarding a different  
<a>-tag, so I might be way off-base here.

I think you have a valid point with bookmarking. If we didn't have the real URL in the A tag in the message list, you could not bookmark from that page, though you could once you opened the message of course. 


Regarding a fix for the problem:
Have you tried replacing the 'onclick' event with an 'onmouseup' event?  

Now this is pure genius! It WORKS! Test it out on http://orionweb.net/joelstuff/click.html I had to capture both onclick and onmouseup because for some reason in Safari cancelling onmouseup did not cancel the click. I didn't do much testing though so maybe i am missing something. What does everyone think? Is this a workable solution? onmouseup has some quirks. For example, if you start a click somewhere else, hold the button, then move the mouse above the link and release it, mouseup fires for the object you are under, not the one you originally clicked. Personally, I think I could live with that though.

This is exciting :-)


Personally I always use onmouseup anyway, as it better mirrors the way an  
OS works, where you can click something, and if you see you are on the  
wrong button you can move your mouse to the correct button and release it  
there without fireing the first one.
Another solution might be to detect the exact version of IE that has this  
problem, and then do a DOM-replacement replacing the <a> by a <span> only  
for that browser-version - this would leave all other browser alone, as  
well as people using that browser-version without javascript.

Unfortunately, IE7 is fast eclipsing IE6 and will soon be the dominant browser for years to come. If we disable <a> tags in IE7, we are breaking accessibility for a very large audience. I wish it wasn't true, but this is life.

Hope all that helps in some way...

It helped immensely. Thank you!



Richard.
_______________________________________________
List info: http://lists.roundcube.net/dev/
Joel Clermont
joel@orionweb.net
262-377-9930