Safari support for window.status

Re: Safari support for window.status

yb a écrit :[color=blue]
> Hi,
>
> In Mozilla and IE, setting an event handler for "onmouseove r" for a
> link, (i.e. 'a' element) and return false will prevent the status
> message from showing the links href value.[/color]

.... if and only if the user has not check
Edit/Preferences.../Advanced/Allow scripts to:/Change status bar text
[color=blue]
> Safari displays the link anyway,[/color]

....which is a good thing IMO
[color=blue]
> and also trying to use DOM 2 API and
> eventhandler with "preventDefault " function does not solve the problem
> either.
>
> Is there anyway with Safari to stop the status message from showing?
>
> Thank you[/color]

What you are trying to do is NOT user-friendly. Only hackers and some
"original"/strange unorthodox web designers try to mask or hide the url
of their links.

Gérard
--
remove blah to email me

Re: Safari support for window.status

Gérard Talbot wrote:
[color=blue]
> [hide URIs in status bar]
> What you are trying to do is NOT user-friendly. Only hackers and some
> "original"/strange unorthodox web designers try to mask or hide the url
> of their links.[/color]

s/hackers/crackers/

And it is still not entirely true. There are good reasons for hiding the
URI and there are good reasons for not doing so. For example, there is
not much point in letting the user agent show a "#" URI used in the `href'
attribute of script-only `a' elements; it is much more reasonable to show
a more detailed description what the element will do when it is activated.


PointedEars

Re: Safari support for window.status

Thomas 'PointedEars' Lahn said the following on 11/8/2005 3:58 PM:
[color=blue]
> Gérard Talbot wrote:
>
>[color=green]
>>[hide URIs in status bar]
>>What you are trying to do is NOT user-friendly. Only hackers and some
>>"original"/strange unorthodox web designers try to mask or hide the url
>>of their links.[/color]
>
>
> s/hackers/crackers/
>
> And it is still not entirely true. There are good reasons for hiding the
> URI and there are good reasons for not doing so. For example, there is
> not much point in letting the user agent show a "#" URI used in the `href'
> attribute of script-only `a' elements; it is much more reasonable to show
> a more detailed description what the element will do when it is activated.[/color]

There is *never* a "good reason" for screwing with my browser, no matter
what your intent is. If you want to show me additional information, then
show it in the page.

Besides, a "script only 'a' element" is next to useless. If it is script
only, then have script create a button. Problem solved with regards to
the # URL

--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Re: Safari support for window.status

Thomas 'PointedEars' Lahn wrote:[color=blue]
> Gérard Talbot wrote:
>[color=green]
>> [hide URIs in status bar]
>> What you are trying to do is NOT user-friendly. Only hackers and some
>> "original"/strange unorthodox web designers try to mask or hide the url
>> of their links.[/color]
>
> s/hackers/crackers/
>
> And it is still not entirely true. There are good reasons for hiding the
> URI and there are good reasons for not doing so. For example, there is
> not much point in letting the user agent show a "#" URI used in the `href'
> attribute of script-only `a' elements; it is much more reasonable to show
> a more detailed description what the element will do when it is activated.[/color]

That is usually left to interface design - what something will do in
response to some user action should be obvious without the user having
to actually do the action. Relying on the status bar to give feedback
is pretty useless.

Different browsers put different things into the status bar - Safari,
for example, advises if clicking a link will open a new window.
Presumably if users take any notice of the status bar they will chose a
browser that puts information in there that is useful to them.

Most users never look at the status bar, their attention might be drawn
to it by animated scrolling banners, but that's about it. For general
advice it is almost worthless, hence the use of script-driven elements
and the title attribute as tool tips.

I like web designers who keep their attention inside the window frame
and not mess with anything outside that.



--
Rob

Re: Safari support for window.status

Thomas 'PointedEars' Lahn a écrit :[color=blue]
> Gérard Talbot wrote:
>
>[color=green]
>>[hide URIs in status bar]
>>What you are trying to do is NOT user-friendly. Only hackers and some
>>"original"/strange unorthodox web designers try to mask or hide the url
>>of their links.[/color]
>
>
> s/hackers/crackers/
>
> And it is still not entirely true. There are good reasons for hiding the
> URI and there are good reasons for not doing so. For example, there is
> not much point in letting the user agent show a "#" URI used in the `href'
> attribute of script-only `a' elements;[/color]


Using a pseudo-link is already a design flaw; trying to mask it is
another error... unless your intent are malicious to begin with.
Modifying the normal, standard behavior of a browser for dubious intent
or poor design purposes will never be acceptable from a fundamental
security perspective. The web designer can do whatever he wants inside a
sand box; he never should have powers outside that sand box.

Gérard
--
remove blah to email me

Re: Safari support for window.status

Gérard Talbot wrote:[color=blue]
> yb a écrit :[color=green]
>> Hi,
>>
>> In Mozilla and IE, setting an event handler for "onmouseove r" for a
>> link, (i.e. 'a' element) and return false will prevent the status
>> message from showing the links href value.[/color]
>
> ... if and only if the user has not check
> Edit/Preferences.../Advanced/Allow scripts to:/Change status bar text[/color]

Hey! Which version of Safari has Preferences in the Edit menu? Last time
I looked, it was in the 'Safari' menu!! ;-)

[...]

--
Rob

Re: Safari support for window.status

Gérard Talbot wrote:
[color=blue]
> Thomas 'PointedEars' Lahn a écrit :[color=green]
>> [...] There are good reasons for hiding the URI and there are good
>> reasons for not doing so. For example, there is not much point in
>> letting the user agent show a "#" URI used in the `href' attribute
>> of script-only `a' elements;[/color]
>
> Using a pseudo-link is already a design flaw; [...][/color]

No, it is not. That "pseudo-link", as you call it, is of course created
by client-side script and the possibility of using an input[type="button"]
or button element instead was considered and rejected (not out of a lack
of CSS knowledge, I assure you).


PointedEars

Re: Safari support for window.status

RobG wrote:
[color=blue]
> Thomas 'PointedEars' Lahn wrote:[color=green]
>> [...] There are good reasons for hiding the URI and there are good
>> reasons for not doing so. For example, there is not much point in
>> letting the user agent show a "#" URI used in the `href' attribute
>> of script-only `a' elements; it is much more reasonable to show a
>> more detailed description what the element will do when it is
>> activated.[/color]
>
> That is usually left to interface design - what something will do in
> response to some user action should be obvious without the user having
> to actually do the action. Relying on the status bar to give feedback
> is pretty useless.[/color]

Of course, nobody said it is to be relied on it. I thought that "more
detailed description" implied that this element already has content.


PointedEars

I came up with the following:

NOTE: The onMouseMove code:is two single quotes preceded by a slash (\'') and NOT a double-quote preceded by a slash, in case you get flustered by quotes like me!

In Safari, it needs a setTimeout() function to change the window status, but if you move your cursor around while it's over the link (after the original mouseOver event), Safari replaces the "TEXT GOES HERE" with the URL. Therefore, I made the Safari function work on an onMouseMove event. I also needed to include the onMouseOver event, because without it, Windows IE would bounce between the URL and the "TEXT GOES HERE" text as I moved my mouse over the link.

Please post any problems/insights you may have to this issue!