hiding javascript function call from status bar.

Discussion in 'Javascript' started by Archana, Nov 20, 2008.

  1. Archana

    Archana Guest

    Hi all,

    i am facing one problem with status bar of IE. when i execute any
    javascript function or navigate to any link it is showing me that in
    status bar which i don't want.

    how will ido this?

    any help will be truely appreciated.

    thanks in advance.
     
    Archana, Nov 20, 2008
    #1
    1. Advertising

  2. Archana

    David Mark Guest

    On Nov 20, 7:57 am, Archana <> wrote:
    > Hi all,
    >
    > i am facing one problem with status bar of IE. when i execute any
    > javascript function or navigate to any link it is showing me that in
    > status bar which i don't want.


    That is a shame.

    >
    > how will ido this?


    View | Status Bar will hide those pesky messages.

    [snip]
     
    David Mark, Nov 20, 2008
    #2
    1. Advertising

  3. Archana

    SAM Guest

    Le 11/20/08 1:57 PM, Archana a écrit :
    > Hi all,
    >
    > i am facing one problem with status bar of IE. when i execute any
    > javascript function or navigate to any link it is showing me that in
    > status bar which i don't want.


    <a href="javascript:doThat();"
    onmouseover="window.status='no link';return true;">do that</a>

    With recent browsers that can no more work.
    (protection of status bar)

    --
    sm
     
    SAM, Nov 20, 2008
    #3
  4. Archana

    Robin Guest

    Archana wrote:
    > Hi all,
    >
    > i am facing one problem with status bar of IE. when i execute any
    > javascript function or navigate to any link it is showing me that in
    > status bar which i don't want.
    >
    > how will ido this?
    >
    > any help will be truely appreciated.
    >
    > thanks in advance.


    See: http://jibbering.com/faq/index.html#javascriptURI
     
    Robin, Nov 20, 2008
    #4
  5. Archana

    Archana Guest

    Hi,

    I think you r not getting my question. I want status bar to be
    displayed which is having progress bar. But i don't want url to be
    displayed or javascript call to be displayed on status bar.

    if you know then let me know abt it.
     
    Archana, Nov 21, 2008
    #5
  6. Archana

    David Mark Guest

    On Nov 21, 1:42 am, Archana <> wrote:
    > Hi,
    >
    > I think you r not getting my question.  I want status bar to be
    > displayed which is having progress bar.  But i don't want url to be
    > displayed or javascript call to be displayed on status bar.


    Ah, I see. You are referring to *my* status bar. Sorry, I like it
    the way it is.
     
    David Mark, Nov 21, 2008
    #6
  7. Archana wrote:
    > i am facing one problem with status bar of IE. when i execute any
    > javascript function or navigate to any link it is showing me that in
    > status bar which i don't want.


    See the FAQ, as recommended.

    However, it can be argued that it would be a Good Thing that users see at a
    glance that the pseudo-link they are about to click is only a pseudo-link
    and does not necessarily cause navigation. Insofar I can see nothing wrong
    in using both the href="javascript:..." and the `onclick' attribute in links
    *that are created with scripting*, whereas the `onclick' code would return
    `false' to prevent the default action of the pseudo-link.


    PointedEars
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
     
    Thomas 'PointedEars' Lahn, Nov 21, 2008
    #7
  8. Archana

    dhtml Guest

    Thomas 'PointedEars' Lahn wrote:
    > Archana wrote:
    >> i am facing one problem with status bar of IE. when i execute any
    >> javascript function or navigate to any link it is showing me that in
    >> status bar which i don't want.

    >


    Why not?

    > See the FAQ, as recommended.
    >
    > However, it can be argued that it would be a Good Thing that users see at a
    > glance that the pseudo-link they are about to click is only a pseudo-link
    > and does not necessarily cause navigation. Insofar I can see nothing wrong
    > in using both the href="javascript:..." and the `onclick' attribute in links
    > *that are created with scripting*, whereas the `onclick' code would return
    > `false' to prevent the default action of the pseudo-link.
    >


    Assuming:
    1) The status bar is visible and
    2) User actually looks at the status bar and
    3) The user recognizes text in the statusbar that starts with
    "javascript:" as being a "pseudo link".

    It would be a good idea to just use some other type of indicator for
    styling scripted objects (so they are distinguishable from links). For
    example, use underline for real links, but not for buttons/widgets, et c.

    You may want to F'up to a HCI newsgroup.


    --
    comp.lang.javascript FAQ <URL: http://jibbering.com/faq/ >
     
    dhtml, Nov 23, 2008
    #8
  9. Archana

    David Mark Guest

    On Nov 23, 12:25 am, dhtml <> wrote:
    > Thomas 'PointedEars' Lahn wrote:
    > > Archana wrote:
    > >> i am facing one problem with status bar of IE. when i execute any
    > >> javascript function or navigate to any link it is showing me that in
    > >> status bar which i don't want.

    >
    > Why not?
    >
    > > See the FAQ, as recommended.

    >
    > > However, it can be argued that it would be a Good Thing that users see at a
    > > glance that the pseudo-link they are about to click is only a pseudo-link
    > > and does not necessarily cause navigation.  Insofar I can see nothingwrong
    > > in using both the href="javascript:..." and the `onclick' attribute in links
    > > *that are created with scripting*, whereas the `onclick' code would return
    > > `false' to prevent the default action of the pseudo-link.

    >
    > Assuming:
    > 1) The status bar is visible and
    > 2) User actually looks at the status bar and
    > 3) The user recognizes text in the statusbar that starts with
    > "javascript:" as being a "pseudo link".


    I'm not sure why they would care. The "pseudo link" may just call
    window.open.

    >
    > It would be a good idea to just use some other type of indicator for
    > styling scripted objects (so they are distinguishable from links). For
    > example, use underline for real links, but not for buttons/widgets, et c.


    Yes, and I would go a step further and say that links that are
    obviously part of the navigation can go without underlines (but that
    is just a style choice.) And certainly "links" on widgets should not
    look like links. Nor should buttons, but I see cursor:pointer used on
    them all the time.

    >
    > You may want to F'up to a HCI newsgroup.
    >
    > --
    > comp.lang.javascript FAQ <URL:http://jibbering.com/faq/>
     
    David Mark, Nov 23, 2008
    #9
  10. dhtml wrote:
    > Thomas 'PointedEars' Lahn wrote:
    >> [...] it can be argued that it would be a Good Thing that users see at a
    >> glance that the pseudo-link they are about to click is only a pseudo-link
    >> and does not necessarily cause navigation. Insofar I can see nothing wrong
    >> in using both the href="javascript:..." and the `onclick' attribute in links
    >> *that are created with scripting*, whereas the `onclick' code would return
    >> `false' to prevent the default action of the pseudo-link.

    >
    > Assuming:
    > 1) The status bar is visible and
    > 2) User actually looks at the status bar and


    There are other ways to show the URI of a hyperlink than a statusbar, so the
    latter is in fact *your* assumption.

    > 3) The user recognizes text in the statusbar that starts with
    > "javascript:" as being a "pseudo link".


    Granted, the term "javascript" (and different spellings thereof) needs to be
    known and understood by the user. But I still think `javascript:' in such a
    case is better than nothing or the infamous "#"; it would provide at least
    an indication as to what would (not) happen if the item was activated.

    > It would be a good idea to just use some other type of indicator for
    > styling scripted objects (so they are distinguishable from links). For
    > example, use underline for real links, but not for buttons/widgets, et c.


    I think that would be overkill.


    PointedEars
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
     
    Thomas 'PointedEars' Lahn, Nov 23, 2008
    #10
  11. Archana

    dhtml Guest

    Thomas 'PointedEars' Lahn wrote:
    > dhtml wrote:



    >> Assuming:
    >> 1) The status bar is visible and
    >> 2) User actually looks at the status bar and

    >
    > There are other ways to show the URI of a hyperlink than a statusbar, so the
    > latter is in fact *your* assumption.
    >


    The OPs initial thread was asking about the status bar.

    >> 3) The user recognizes text in the statusbar that starts with
    >> "javascript:" as being a "pseudo link".

    >
    > Granted, the term "javascript" (and different spellings thereof) needs to be
    > known and understood by the user. But I still think `javascript:' in such a
    > case is better than nothing or the infamous "#"; it would provide at least
    > an indication as to what would (not) happen if the item was activated.
    >
    >> It would be a good idea to just use some other type of indicator for
    >> styling scripted objects (so they are distinguishable from links). For
    >> example, use underline for real links, but not for buttons/widgets, et c.

    >
    > I think that would be overkill.
    >

    It's actually not hard at all.

    A little css:

    ..scriptLink {
    color: #00f;
    cursor: default;
    user-select: none;
    -moz-user-select: none;
    -webkit-user-select: none;
    }

    add the following to the scripted element:

    if('unselectable' in el) {
    el.unselectable = "on";
    }

    An anchor has the effect of providing a hyperlink. Preventing that
    behavior by using javascript: is easily avoided by using an element that
    does not have that feature. And it doesn't have the effect of conveying
    the wrong semantic meaning.


    --
    comp.lang.javascript FAQ <URL: http://jibbering.com/faq/ >
     
    dhtml, Nov 24, 2008
    #11
  12. dhtml wrote:
    > Thomas 'PointedEars' Lahn wrote:
    > > dhtml wrote:
    > >> Assuming:
    > >> 1) The status bar is visible and
    > >> 2) User actually looks at the status bar and

    >
    > > There are other ways to show the URI of a hyperlink than a statusbar, so the
    > > latter is in fact *your* assumption.

    >
    > The OPs initial thread


    I beg your pardon?

    > was asking about the status bar.


    You haven't been paying attention. This thread drifted since then.

    > >> It would be a good idea to just use some other type of indicator for
    > >> styling scripted objects (so they are distinguishable from links). For
    > >> example, use underline for real links, but not for buttons/widgets, etc.

    > >
    > > I think that would be overkill.

    >
    > It's actually not hard at all.


    Contrary to your interpretation, the term "overkill" refers to an
    *unnecessary* feature instead.

    > A little css:
    >
    > .scriptLink {
    >    color: #00f;
    >    cursor: default;
    >    user-select: none;
    >    -moz-user-select: none;
    >    -webkit-user-select: none;
    > }


    That's proprietary, user-hostile junk.

    > add the following to the scripted element:
    >
    > if('unselectable' in el) {


    The `in' operation should not be used, especially not on host objects.

    >    el.unselectable = "on";


    Host objects should never tried to be augmented. Where have you been
    the last months?

    > }
    >
    > An anchor has the effect of providing a hyperlink. Preventing that
    > behavior by using javascript: is easily avoided by using an element that
    > does not have that feature. And it doesn't have the effect of conveying
    > the wrong semantic meaning.


    Exactly nothing in my rebuttal called for your posting rubbish of this
    magnitude. <David>I want the last two minutes of my life back!</
    David>


    PointedEars
     
    Thomas 'PointedEars' Lahn, Nov 24, 2008
    #12
  13. Archana

    dhtml Guest

    Thomas 'PointedEars' Lahn wrote:
    > dhtml wrote:
    >> Thomas 'PointedEars' Lahn wrote:
    >>> dhtml wrote:
    >>>> Assuming:
    >>>> 1) The status bar is visible and
    >>>> 2) User actually looks at the status bar and
    >>> There are other ways to show the URI of a hyperlink than a statusbar, so the
    >>> latter is in fact *your* assumption.

    >> The OPs initial thread

    >
    > I beg your pardon?
    >
    >> was asking about the status bar.

    >
    > You haven't been paying attention. This thread drifted since then.
    >
    >>>> It would be a good idea to just use some other type of indicator for
    >>>> styling scripted objects (so they are distinguishable from links). For
    >>>> example, use underline for real links, but not for buttons/widgets, et c.
    >>> I think that would be overkill.

    >> It's actually not hard at all.

    >
    > Contrary to your interpretation, the term "overkill" refers to an
    > *unnecessary* feature instead.
    >
    >> A little css:
    >>
    >> .scriptLink {
    >> color: #00f;
    >> cursor: default;
    >> user-select: none;
    >> -moz-user-select: none;
    >> -webkit-user-select: none;
    >> }

    >
    > That's proprietary, user-hostile junk.
    >


    We're talking about something the user is expected to be clicked on.
    Styling it to indicate that to the user is user-friendly, more than user
    hostile.

    >> add the following to the scripted element:
    >>
    >> if('unselectable' in el) {

    >
    > The `in' operation should not be used, especially not on host objects.
    >
    >> el.unselectable = "on";

    >


    I don't suppose you have an example where using the - in - operator is
    causing problems or working unreliably with a host object. This is
    coming from the same person who checks to see if window exists and
    attempts to justify that line of code, with no test case to show how it
    has failed in the way that he has designed it to fail in that case,
    because you are apparantly unable to reproduce such conditions.

    One case for using the in operator is when checking the setRequestHeader.


    if('setRequestHeader' in anXhr) {
    ....
    }

    Because using object detection will cause errors in IE6:-

    if(anXhr.setRequestHeader) {

    }

    Though I could see argument for using - typeof -, the value for
    "unselectable" would have to be not undefined. Hypothetically, an
    implementation could have el.unselectable (property present), yet have
    the value of that property be undefined.

    It has be revealed the Safari does have a host string type that reports
    undefined with typeof.

    javascript:alert('' == document.body.style.filter);// true
    javascript:alert('' === document.body.style.filter);// false
    javascript:alert(typeof document.body.style.filter);// undefined



    > Host objects should never tried to be augmented. Where have you been
    > the last months?
    >


    Setting a value to a host object property is not augmenting a host object.

    Setting a value:-
    el.style.left = "10px".

    That is considerably different that 'augmenting' a host object.

    Augmenting a host object is a bad practice. You should learn the
    difference between that and setting a property on a host object (before
    posting misinformation).

    The previous line:-

    if('unselectable' in el)
    el.unselectable = 'on'

    - is a feature check. The statement inside sets the value of
    unselectable iff the property exists.

    As to where I've been - I've been working on a project. I'm adding new
    features, teaching how to write acceptance tests, unit testing my JS,
    and trying to fix existing code and development process w/o aggravating
    others. I still read messages here, maintain the FAQ, and post
    occasionally.

    >> }
    >>
    >> An anchor has the effect of providing a hyperlink. Preventing that
    >> behavior by using javascript: is easily avoided by using an element that
    >> does not have that feature. And it doesn't have the effect of conveying
    >> the wrong semantic meaning.

    >
    > Exactly nothing in my rebuttal called for your posting rubbish of this
    > magnitude. <David>I want the last two minutes of my life back!</
    > David>
    >


    Your opinion and candor is as highly regarded as usual. We're not using
    javascript: for indicating the status bar to the user; that is not
    proven to be effective. It might not even be displayed to the user (some
    browsers don't have a status bar). It would not be as intuitive as a
    heuristic for the majority of users who do have a status bar. The user
    might not understand or even speak whatever language you use to your
    name your functions. Function names do not need to be and should not be
    localized and do not need to be and should not be presented to most
    (normal) users.

    To answer the OP's question. Do not use javascript:.


    Garrett

    --
    comp.lang.javascript FAQ <URL: http://jibbering.com/faq/ >
     
    dhtml, Nov 28, 2008
    #13
  14. Archana

    David Mark Guest

    On Nov 27, 10:52 pm, dhtml <> wrote:
    > Thomas 'PointedEars' Lahn wrote:
    > > dhtml wrote:
    > >> Thomas 'PointedEars' Lahn wrote:
    > >>> dhtml wrote:
    > >>>> Assuming:
    > >>>> 1) The status bar is visible and
    > >>>> 2) User actually looks at the status bar and
    > >>> There are other ways to show the URI of a hyperlink than a statusbar, so the
    > >>> latter is in fact *your* assumption.
    > >> The OPs initial thread

    >
    > > I beg your pardon?

    >
    > >> was asking about the status bar.

    >
    > > You haven't been paying attention. This thread drifted since then.

    >
    > >>>> It would be a good idea to just use some other type of indicator for
    > >>>> styling scripted objects (so they are distinguishable from links). For
    > >>>> example, use underline for real links, but not for buttons/widgets, et c.
    > >>> I think that would be overkill.
    > >> It's actually not hard at all.

    >
    > > Contrary to your interpretation, the term "overkill" refers to an
    > > *unnecessary* feature instead.

    >
    > >> A little css:

    >
    > >> .scriptLink {
    > >> color: #00f;
    > >> cursor: default;
    > >> user-select: none;
    > >> -moz-user-select: none;
    > >> -webkit-user-select: none;
    > >> }

    >
    > > That's proprietary, user-hostile junk.

    >
    > We're talking about something the user is expected to be clicked on.
    > Styling it to indicate that to the user is user-friendly, more than user
    > hostile.
    >
    > >> add the following to the scripted element:

    >
    > >> if('unselectable' in el) {

    >
    > > The `in' operation should not be used, especially not on host objects.

    >
    > >> el.unselectable = "on";

    >
    > I don't suppose you have an example where using the - in - operator is
    > causing problems or working unreliably with a host object. This is


    I'd use the typeof operator here. I don't know of any case where a
    host object returns misleading results (or errors) when used with the
    "in" operator, but I avoid it altogether for compatibility reasons.

    > coming from the same person who checks to see if window exists and
    > attempts to justify that line of code, with no test case to show how it
    > has failed in the way that he has designed it to fail in that case,
    > because you are apparantly unable to reproduce such conditions.


    That one is an interesting question. If designing solely for
    browsers, calls to setTimeout, alert, etc. should be called
    referencing the window property of the global object. If designing
    for any host environment, it is more robust to omit the window
    reference entirely (this assumes that there are environments that
    implement these methods as properties of the global object.) In
    either case, browsers behave the same as the window object is
    invariably a reference to the global object. Could there be a past or
    future browser that breaks that rule? I can't imagine, but apparently
    some can.

    >
    > One case for using the in operator is when checking the setRequestHeader.
    >
    > if('setRequestHeader' in anXhr) {
    > ...
    >
    > }
    >
    > Because using object detection will cause errors in IE6:-
    >
    > if(anXhr.setRequestHeader) {
    >
    > }


    Use typeof. That blows up as anXhr is an ActiveX object in IE6 and
    methods of such objects of of type "unknown." When testing host
    methods, always stop short of a type conversion test when a typeof
    operation returns "unknown." Search the group for "isHostMethod."

    >
    > Though I could see argument for using - typeof -, the value for
    > "unselectable" would have to be not undefined. Hypothetically, an
    > implementation could have el.unselectable (property present), yet have
    > the value of that property be undefined.
    >
    > It has be revealed the Safari does have a host string type that reports
    > undefined with typeof.


    I've never used this property. Boolean? If so, it won't blow up on
    testing. If it s primarily methods that do that, though there have
    been strings (href) and objects (offsetParent) too.

    >
    > javascript:alert('' == document.body.style.filter);// true
    > javascript:alert('' === document.body.style.filter);// false
    > javascript:alert(typeof document.body.style.filter);// undefined
    >
    > > Host objects should never tried to be augmented. Where have you been
    > > the last months?

    >
    > Setting a value to a host object property is not augmenting a host object.


    I think he meant that the in operation was suspect, so you could be
    adding an expando. It's reaching.

    >
    > Setting a value:-
    > el.style.left = "10px".
    >
    > That is considerably different that 'augmenting' a host object.
    >


    [snip]
     
    David Mark, Nov 28, 2008
    #14
  15. Archana

    David Mark Guest

    On Nov 27, 10:52 pm, dhtml <> wrote:

    [snip]

    >
    > javascript:alert('' == document.body.style.filter);// true


    This is an odd one. So Safari spoofs this IE style, but does nothing
    with it (as does Opera now.)

    > javascript:alert('' === document.body.style.filter);// false
    > javascript:alert(typeof document.body.style.filter);// undefined


    We know it is not the native undefined. Perhaps it is behind the
    scenes and they added this twist to avoid breaking the many opacity
    scripts that look for typeof "string". It's never caused me any
    trouble as that is what I look for (rather than comparing to ''.)
    Opera didn't have the courtesy, but that isn't a problem if you test
    the quasi-standard opacity property first.

    [snip]
     
    David Mark, Nov 28, 2008
    #15
  16. Archana

    preet Guest

    preet, Nov 28, 2008
    #16
  17. dhtml wrote:
    > Thomas 'PointedEars' Lahn wrote:
    >> dhtml wrote:
    >>> Thomas 'PointedEars' Lahn wrote:
    >>>> dhtml wrote:
    >>>>> It would be a good idea to just use some other type of indicator for
    >>>>> styling scripted objects (so they are distinguishable from links). For
    >>>>> example, use underline for real links, but not for buttons/widgets, et c.
    >>>> I think that would be overkill.
    >>> It's actually not hard at all.

    >> Contrary to your interpretation, the term "overkill" refers to an
    >> *unnecessary* feature instead.
    >>
    >>> A little css:
    >>>
    >>> .scriptLink {
    >>> color: #00f;
    >>> cursor: default;
    >>> user-select: none;
    >>> -moz-user-select: none;
    >>> -webkit-user-select: none;
    >>> }

    >> That's proprietary, user-hostile junk.

    >
    > We're talking about something the user is expected to be clicked on.
    > Styling it to indicate that to the user is user-friendly, more than user
    > hostile.


    You are mistaken. You would deny the user to select the item at all, not
    simply prevent clicking it.

    >>> add the following to the scripted element:
    >>>
    >>> if('unselectable' in el) {

    >> The `in' operation should not be used, especially not on host objects.
    >>
    >>> el.unselectable = "on";

    >
    > I don't suppose you have an example where using the - in - operator is
    > causing problems


    Netscape 4, IE 4, and any other (UA that provides a) script engine that does
    not implement ECMAScript Ed. 3 in this regard. Those are rare, granted, but
    have not vanished yet.

    > or working unreliably with a host object.


    I don't have to present an example as it stands to reason that the `in'
    operation is unreliable on host objects. The ECMAScript Language
    Specification, Edition 3 Final, says:

    | 11.8.7 The `in' operator
    |
    | The production
    | RelationalExpression : RelationalExpression in ShiftExpression
    | is evaluated as follows:
    |
    | 1. Evaluate RelationalExpression.
    | 2. Call GetValue(Result(1)).
    | 3. Evaluate ShiftExpression.
    | 4. Call GetValue(Result(3)).
    | 5. If Result(4) is not an object, throw a TypeError exception.
    | 6. Call ToString(Result(2)).
    | 7. Call the [[HasProperty]] method of Result(4) with parameter Result(6).
    | 8. Return Result(7).

    GetValue() (section 8.7.1) calls [[Get]] (8.6.2.1), which is allowed to be
    implemented for host objects, as other internal methods and properties, "in
    any manner unless specified otherwise" (8.6.2). And "one possibility is
    that [[Get]] and [[Put]] for a particular host object indeed fetch and store
    property values but [[HasProperty]] always generates false." (ibid.)

    > This is coming from the same person who checks to see if window exists


    Yes, as that property, if present, would refer to a host object, and host
    objects have to be handled with more care than native objects due to the
    Specification and experience. I don't see the contradiction here.

    > One case for using the in operator is when checking the setRequestHeader.


    It isn't.

    > if('setRequestHeader' in anXhr) {
    > ...
    > }
    >
    > Because using object detection will cause errors in IE6:-
    >
    > if(anXhr.setRequestHeader) {
    >
    > }


    I thought you understood when to use a type-converting test and when not
    by now. The `typeof' operation is the method of choice here instead.

    > Though I could see argument for using - typeof -, the value for
    > "unselectable" would have to be not undefined.


    Yes, it could be "unknown" in which case we have to assume it is a property
    and handle the exception if one occurs on property access. In any case
    that is more reliable than the `in' operation, which hopefully you see by now.

    > It has be revealed the Safari does have a host string type that reports
    > undefined with typeof.
    >
    > javascript:alert('' == document.body.style.filter);// true
    > javascript:alert('' === document.body.style.filter);// false
    > javascript:alert(typeof document.body.style.filter);// undefined


    Since Safari does not implement Microsoft filters at all, we see the result
    of a wise design decision by Apple and WebKit contributors here.
    Feature-testing code would then not use the branch for Microsoft filters.

    >> Host objects should never tried to be augmented. Where have you been
    >> the last months?

    >
    > Setting a value to a host object property is not augmenting a host object.


    Fair enough. Where have you feature-tested that property in your example?

    > [...]
    > The previous line:-
    >
    > if('unselectable' in el)
    > el.unselectable = 'on'
    >
    > - is a feature check.


    And an inherently error-prone at that.

    > As to where I've been - I've been working on a project.


    You should adjust your irony detector, it produces false negatives.

    > To answer the OP's question. Do not use javascript:.


    No, do not use `javascript:' in `a[href]' elements when no `onclick'
    attribute is specified and using `javascript:' would make an element
    inaccessible to users without scripting. Unless, of course, that
    element was generated dynamically with scripting. (As I have explained
    before.)


    PointedEars
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
     
    Thomas 'PointedEars' Lahn, Nov 28, 2008
    #17
  18. Archana

    dhtml Guest

    David Mark wrote:
    > On Nov 27, 10:52 pm, dhtml <> wrote:
    >> Thomas 'PointedEars' Lahn wrote:
    >>> dhtml wrote:
    >>>> Thomas 'PointedEars' Lahn wrote:
    >>>>> dhtml wrote:



    > I think he meant that the in operation was suspect, so you could be
    > adding an expando. It's reaching.


    Is there any reason believe that the - in - operator would return a
    false positive for an element's unselectable property?



    --
    comp.lang.javascript FAQ <URL: http://jibbering.com/faq/ >
     
    dhtml, Nov 29, 2008
    #18
  19. Archana

    David Mark Guest

    On Nov 29, 1:24 pm, dhtml <> wrote:
    > David Mark wrote:
    > > On Nov 27, 10:52 pm, dhtml <> wrote:
    > >> Thomas 'PointedEars' Lahn wrote:
    > >>> dhtml wrote:
    > >>>> Thomas 'PointedEars' Lahn wrote:
    > >>>>> dhtml wrote:

    > > I think he meant that the in operation was suspect, so you could be
    > > adding an expando.  It's reaching.

    >
    > Is there any reason believe that the - in - operator would return a
    > false positive for an element's unselectable property?


    No other reason than "anything goes" with host objects. That's why it
    is a stretch. Still I would use typeof.
     
    David Mark, Nov 29, 2008
    #19
  20. Archana

    dhtml Guest

    Thomas 'PointedEars' Lahn wrote:
    > dhtml wrote:
    >> Thomas 'PointedEars' Lahn wrote:
    >>> dhtml wrote:
    >>>> Thomas 'PointedEars' Lahn wrote:
    >>>>> dhtml wrote:
    >>>>>> It would be a good idea to just use some other type of indicator for
    >>>>>> styling scripted objects (so they are distinguishable from links). For
    >>>>>> example, use underline for real links, but not for buttons/widgets, et c.
    >>>>> I think that would be overkill.
    >>>> It's actually not hard at all.
    >>> Contrary to your interpretation, the term "overkill" refers to an
    >>> *unnecessary* feature instead.
    >>>
    >>>> A little css:
    >>>>
    >>>> .scriptLink {
    >>>> color: #00f;
    >>>> cursor: default;
    >>>> user-select: none;
    >>>> -moz-user-select: none;
    >>>> -webkit-user-select: none;
    >>>> }
    >>> That's proprietary, user-hostile junk.

    >> We're talking about something the user is expected to be clicked on.
    >> Styling it to indicate that to the user is user-friendly, more than user
    >> hostile.

    >
    > You are mistaken. You would deny the user to select the item at all, not
    > simply prevent clicking it.
    >


    The user is supposed to click on it. If the mouse moves during that
    click, the text will, by default, be selected.

    When the user tries to select text in a link or button, text selection
    does not occur.


    >>>> add the following to the scripted element:
    >>>>
    >>>> if('unselectable' in el) {
    >>> The `in' operation should not be used, especially not on host objects.
    >>>
    >>>> el.unselectable = "on";

    >> I don't suppose you have an example where using the - in - operator is
    >> causing problems

    >
    > Netscape 4, IE 4, and any other (UA that provides a) script engine that does
    > not implement ECMAScript Ed. 3 in this regard. Those are rare, granted, but
    > have not vanished yet.
    >


    Those browsers are much more rare than the problems caused by
    inexperienced scripters using javascript:.

    For most applications, these browsers are not worth testing in. The
    amount of trouble required to get anything to work would not be worth
    it. There is no 'user-select' and a majority of the CSS would fail, as
    would getElementById.

    The - in - operator is generally safe to use.

    >> or working unreliably with a host object.

    >
    > I don't have to present an example as it stands to reason that the `in'
    > operation is unreliable on host objects. The ECMAScript Language
    > Specification, Edition 3 Final, says:
    >


    You've made the assertion that - in - should not be used (because it
    doesn't work in NS 4), and especially not on a Host object.

    I've already covered the NS4 argument.

    You suggested that typeof should be used. Did you think that typeof
    *must* be safe to use on a host object? Always?

    The typeof operator can return anything on a Host object. I showed this
    to be true in my last post where typeof document.body.style.filter is
    undefined in Webkit, even though it is a string value. You've shown no
    example.

    In the case where an object might have a property that might be a
    string, the value could potentially be the value - undefined -.

    In that case, we could use typeof:-

    if(typeof el.unselectable != "undefined") {

    }

    would be true, even if el had an unselectable property.

    >
    >> Though I could see argument for using - typeof -, the value for
    >> "unselectable" would have to be not undefined.

    >
    > Yes, it could be "unknown" in which case we have to assume it is a property
    > and handle the exception if one occurs on property access. In any case
    > that is more reliable than the `in' operation, which hopefully you see by now.
    >


    You're misinterpreting what I wrote.

    The _value_ for the unselectable property would have no be not undefined.

    I did not write that the result of using typeof el.unselectable would
    have to be not "undefined".

    The result of typeof el.unselectable should probably be "string",
    however, detecting if the property exists is sufficient enough.

    >> It has be revealed the Safari does have a host string type that reports
    >> undefined with typeof.
    >>
    >> javascript:alert('' == document.body.style.filter);// true
    >> javascript:alert('' === document.body.style.filter);// false
    >> javascript:alert(typeof document.body.style.filter);// undefined

    >
    > Since Safari does not implement Microsoft filters at all, we see the result
    > of a wise design decision by Apple and WebKit contributors here.
    > Feature-testing code would then not use the branch for Microsoft filters.
    >
    >>> Host objects should never tried to be augmented. Where have you been
    >>> the last months?

    >> Setting a value to a host object property is not augmenting a host object.

    >
    > Fair enough. Where have you feature-tested that property in your example?
    >
    >> [...]
    >> The previous line:-
    >>
    >> if('unselectable' in el)
    >> el.unselectable = 'on'
    >>
    >> - is a feature check.

    >
    > And an inherently error-prone at that.
    >


    It is no more error prone than using the native typeof operator.

    Use javascript when onclick is specified. what would that give you?

    <a href="javascript:something()" onclick="something();return
    false;">check</a>

    Should - something - fail in the onclick, then it would fail again in
    the href, resulting in two errors.

    Should - something - succeed in the onclick, then the javascript: uri
    would be useless.

    The argument that providing javascript: in the status bar as being
    something that could be meaningful to the user is your idea. You could
    take that up on a more relevant group related to HCI (human computer
    interaction) and U/X (that's user experience).

    Garrett

    --
    comp.lang.javascript FAQ <URL: http://jibbering.com/faq/ >
     
    dhtml, Nov 29, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Matt
    Replies:
    0
    Views:
    3,594
  2. John Hann
    Replies:
    0
    Views:
    6,159
    John Hann
    Aug 21, 2004
  3. =?Utf-8?B?SmVmZkI=?=

    Hiding URL in IE status bar

    =?Utf-8?B?SmVmZkI=?=, Mar 25, 2005, in forum: ASP .Net
    Replies:
    5
    Views:
    4,354
    Joerg Jooss
    Mar 26, 2005
  4. Matt
    Replies:
    9
    Views:
    71,227
  5. Matt
    Replies:
    9
    Views:
    613
    kaeli
    Aug 23, 2004
Loading...

Share This Page