[announcement] ISKEET library 0.0.2

Discussion in 'Javascript' started by Ekkehard Morgenstern, Jan 17, 2004.

  1. Hi,

    I'd like to announce version 0.0.2 of my ISKEET library for ECMAScript / JavaScript.

    http://www.iskeet.de

    It helps to encapsulate browser-specifics and provides a unified document API.

    Current main features:

    o Free of charge, licensed under the terms of the GNU General Public License.
    o Encapsulates event handling for all event types.
    o Supports Document Object Model (DOM) 1.0 and 2.0.
    o Simplifies finding elements and getting actual element size and position.
    o Supports all JavaScript-enabled versions of Internet Explorer.
    o Supports all JavaScript-enabled versions of Netscape / Mozilla.
    o Implemented in ECMAScript (ECMA 262 standard of JavaScript).
    o Truly object-oriented implementation.

    The ISKEET website is implemented using the ISKEET library.

    Current downsides:

    o Since it is version 0.0.2, a very early release, it does not directly
    support other browser types other than those mentioned. It'd be great
    if someone could test it on old or unusual browsers. :)

    I will add Opera support soon, but it'd be great if someone could test it on Opera,
    perhaps it might already work.

    ISKEET website defects:

    o Requires JavaScript and HTML Frames enabled browsers.

    The website is using XHTML 1.0, if you experience any problems viewing it, please
    notify me. :)

    On the website, you'll find download and manual areas. :)

    greetings,
    Ekkehard.
    Ekkehard Morgenstern, Jan 17, 2004
    #1
    1. Advertising

  2. Ekkehard Morgenstern wrote:
    > Hi,
    >
    > I'd like to announce version 0.0.2 of my ISKEET library for
    > ECMAScript / JavaScript.
    >


    <snippet>
    this.HTTPUserAgent = usrag;
    if ( usrag.indexOf( "MSIE", 0 ) != -1 ) {
    /* defined by Microsoft Internet Explorer */
    var msie = usrag.indexOf( "MSIE", 0 );
    var dot = usrag.indexOf( ".", msie );
    this.IsIE = true;
    </snippet>

    As mentioned many times in this NG, parsing the user agent property is an
    unreliable way of browser detection.

    See http://jibbering.com/faq/#FAQ4_26 for info.


    JW
    Janwillem Borleffs, Jan 17, 2004
    #2
    1. Advertising

  3. "Ekkehard Morgenstern" <> wrote in
    message news:bub8hn$qpb$...
    >I'd like to announce version 0.0.2 of my ISKEET library for
    >ECMAScript / JavaScript.
    > http://www.iskeet.de
    >
    >It helps to encapsulate browser-specifics and provides a
    >unified document API.

    <snip>

    A home page that does not work with Opera 7 is not a place to visit when
    looking for a script designed to "encapsulate browser-specifics and
    provides a unified document API". What's up, a full Core and HTML DOM
    level 2 and ECMA Script implementation not good enough for you?

    Richard.
    Richard Cornford, Jan 17, 2004
    #3
  4. "Richard Cornford" <> wrote:
    > A home page that does not work with Opera 7 is not a place to visit when
    > looking for a script designed to "encapsulate browser-specifics and
    > provides a unified document API". What's up, a full Core and HTML DOM
    > level 2 and ECMA Script implementation not good enough for you?


    Well, if you had read my post properly, you would've noticed that I
    mentioned that I haven't tested it with Opera yet.

    But thanks for telling me! :)
    Ekkehard Morgenstern, Jan 17, 2004
    #4
  5. "Janwillem Borleffs" <> wrote:
    > As mentioned many times in this NG, parsing the user agent property is an
    > unreliable way of browser detection.
    >
    > See http://jibbering.com/faq/#FAQ4_26 for info.


    Yes, I've read many concerns about doing so. Thanks for link! :)
    Ekkehard Morgenstern, Jan 17, 2004
    #5
  6. "Janwillem Borleffs" <> wrote:
    > As mentioned many times in this NG, parsing the user agent property is an
    > unreliable way of browser detection.
    >
    > See http://jibbering.com/faq/#FAQ4_26 for info.


    BTW, in other languages, like PHP, the HTTP user agent string is the only
    way to recognize the user's web browser.

    In my library, I might use browser identification by objects, but it's
    unsafe also, because it doesn't tell you exactly what browser the user
    has, and hence it might be that a presumed implementation does not behave
    as expected, whereas when I use the HTTP user agent string, I can
    identify the browser.

    If the user doesn't tamper with the UserAgent string, it should be
    sufficient, so I could use object recoginition as a fallback method.

    And if the user sets the UserAgent string to a particular value,
    they might _want_ to pretend they use a specific browser. Either for
    testing, or for other purposes. If someone changes the string just
    for the fun of it or to introduce some "anonymity" (which doesn't
    exist on the internet anyway), then it's their problem, IMO.

    There are also lots of browser-version specific JavaScript issues,
    which can only be shipped around by checking the HTTP user agent string.

    These issues have to be considered very carefully, because a library
    like ISKEET is a major endeavor. Once used, tested, and spread around,
    it'll be impossible to change some of the design basics.
    Ekkehard Morgenstern, Jan 17, 2004
    #6
  7. Ekkehard Morgenstern wrote:
    > BTW, in other languages, like PHP, the HTTP user agent string is the
    > only way to recognize the user's web browser.
    >


    But it is never used here to influence the page or script behaviour.

    > In my library, I might use browser identification by objects, but it's
    > unsafe also, because it doesn't tell you exactly what browser the user
    > has, and hence it might be that a presumed implementation does not
    > behave as expected, whereas when I use the HTTP user agent string, I
    > can identify the browser.
    >


    Take a look at Opera, the user can specify how this browser should identify
    itself.

    > If the user doesn't tamper with the UserAgent string, it should be
    > sufficient, so I could use object recoginition as a fallback method.
    >


    It's not the user, but the vendor which may temper the user agent string
    because it's never a fixed value as a rule. Per example, when the developers
    of the Mozilla browser decide to use "gecko" instead of "Gecko", your
    detection is broken.

    Sure, you can fix this by lowercasing the user agent string, but it is
    better to skip detection all together and test for the objects/methods you
    want to use...


    JW
    Janwillem Borleffs, Jan 17, 2004
    #7
  8. "Janwillem Borleffs" <> wrote:
    > Take a look at Opera, the user can specify how this browser should identify
    > itself.


    Actually, for version 0.0.4, which I've just released, I had to work around
    a specific Opera bug (non-standard JavaScript implementation that does not
    conform to the ECMAScript 262 standard, unlike Netscape/Mozilla and Internet
    Explorer). If the user changes the user agent string to omit "Opera", then
    *poof* all sites using ISKEET will not load properly anymore. Tough luck, eh!

    As soon as the Opera developers correct their JavaScript implementation
    to conform to the standard (i.e. do proper parameter passing of objects
    by reference), then I can lift the workaround for the new version.

    This would be impossible to detect without the HTTP UserAgent field,
    and that's exactly what it's there for.

    > It's not the user, but the vendor which may temper the user agent string
    > because it's never a fixed value as a rule.


    Then the user has to deal with the results. Many sites depend on the
    UserAgent string, especially PHP sites, but also JavaScript sites.

    > Per example, when the developers
    > of the Mozilla browser decide to use "gecko" instead of "Gecko", your
    > detection is broken.


    Which will never happen, because then a lot of sites depending on this
    will stop working. For example, PHP sites that generate optimized JavaScript
    code for specific browser types.

    > better to skip detection all together and test for the objects/methods you
    > want to use...


    Which doesn't work for problems like a broken JavaScript implementation
    in Opera 7.

    See my website, http://www.iskeet.de for a detailed problem description.
    Download version 0.0.4 to see my workaround.
    Ekkehard Morgenstern, Jan 18, 2004
    #8
  9. "Richard Cornford" <> wrote:
    > A home page that does not work with Opera 7


    I've added Opera 7 support in Version 0.0.4 of ISKEET now! :)

    http://www.iskeet.de

    (which also means the website is working with Opera 7)
    Ekkehard Morgenstern, Jan 18, 2004
    #9
  10. Ekkehard Morgenstern

    Randy Webb Guest

    Ekkehard Morgenstern wrote:
    > "Janwillem Borleffs" <> wrote:
    >
    >>Take a look at Opera, the user can specify how this browser should identify
    >>itself.

    >
    >
    > Actually, for version 0.0.4, which I've just released, I had to work around
    > a specific Opera bug (non-standard JavaScript implementation that does not
    > conform to the ECMAScript 262 standard, unlike Netscape/Mozilla and Internet
    > Explorer). If the user changes the user agent string to omit "Opera", then
    > *poof* all sites using ISKEET will not load properly anymore. Tough luck, eh!


    Opera 7, in any spoof mode, contains the word "Opera" in the user agent
    string. If you had bothered testing that, you would know it. And your
    statements seem to indicate that your knowledge base of Opera is very
    limited with regards to its userAgent string and how to detect Opera in
    general.

    > As soon as the Opera developers correct their JavaScript implementation
    > to conform to the standard (i.e. do proper parameter passing of objects
    > by reference), then I can lift the workaround for the new version.
    >
    > This would be impossible to detect without the HTTP UserAgent field,
    > and that's exactly what it's there for.


    if (window.opera){
    //opera code here.
    }

    <sarcasm>
    Wait, I didn't check the userAgent string, I must have done it wrong.
    </sarcasm>


    >
    >>It's not the user, but the vendor which may temper the user agent string
    >>because it's never a fixed value as a rule.

    >
    >
    > Then the user has to deal with the results. Many sites depend on the
    > UserAgent string, especially PHP sites, but also JavaScript sites.


    Then "many sites" are poorly written by amateurs posing as professionals
    that know what they are doing.

    >
    >>Per example, when the developers
    >>of the Mozilla browser decide to use "gecko" instead of "Gecko", your
    >>detection is broken.

    >
    >
    > Which will never happen, because then a lot of sites depending on this
    > will stop working. For example, PHP sites that generate optimized JavaScript
    > code for specific browser types.


    Again, if you are trying to "optimize" javascript, PHP is *not* the
    place to try to do it. If you want javascript optimized, use javascript
    to do it.

    --
    Randy
    Randy Webb, Jan 18, 2004
    #10
  11. On Sat, 17 Jan 2004 23:42:12 +0100, Ekkehard Morgenstern
    <> wrote:

    > "Janwillem Borleffs" <> wrote:
    >> As mentioned many times in this NG, parsing the user agent property is
    >> an unreliable way of browser detection.
    >>
    >> See http://jibbering.com/faq/#FAQ4_26 for info.

    >
    > BTW, in other languages, like PHP, the HTTP user agent string is the only
    > way to recognize the user's web browser.


    And that has what bearing on JavaScript? In any event, it is unreliable
    and should not be used for the purpose of detecting implemented
    functionality.

    > In my library, I might use browser identification by objects, but it's
    > unsafe also, because it doesn't tell you exactly what browser the user
    > has, and hence it might be that a presumed implementation does not behave
    > as expected, whereas when I use the HTTP user agent string, I can
    > identify the browser.


    As I said above, you can't. For example, Opera, by default, masquerades as
    Internet Explorer 6.0, probably to get around sites like yours that use
    the user agent string to distinguish between browsers for no valid reason.

    > If the user doesn't tamper with the UserAgent string, it should be
    > sufficient, so I could use object recoginition as a fallback method.
    >
    > And if the user sets the UserAgent string to a particular value,
    > they might _want_ to pretend they use a specific browser. Either for
    > testing, or for other purposes. If someone changes the string just
    > for the fun of it or to introduce some "anonymity" (which doesn't
    > exist on the internet anyway), then it's their problem, IMO.


    If a user wishes to change the User-Agent header, or a browser uses a
    value that does not accurately reflect the actual software, it is you that
    should suffer the consequences, not the user. There is nothing in either
    RFC 1945 or RFC 2616 about what the User-Agent header must contain, other
    than the general syntax of the value. In fact, the header isn't even
    required.

    If you intend to write a viable, robust library, you must to accept the
    fact that the User-Agent header can be inaccurate, particularly when such
    a situation is perfectly valid.

    > There are also lots of browser-version specific JavaScript issues,
    > which can only be shipped around by checking the HTTP user agent string.


    Such as?

    On to a different subject (you've probably seen enough of "User-Agent
    header"). From your website:

    "...Also, the toString() method is defined differently than the
    toSource() method. Have a look at the ECMA 262 standard!..."

    I don't quite know what you're referring to there, but I think you should
    look at ECMA-262. There is no such method, of any object, called toSource.

    "...Also you mention in the documentation for Opera 7, that it
    doesn't support the script tag in XHTML, which isn't true. Also,
    event handling for IE-type mouseovers do work (in contrast to the
    documentation). DOM 2.0 implementations have to support
    document.implementation.hasFeature( "Core", "2.0" ), which Opera 7
    doesn't. Hence, it's not DOM 2.0 compliant, unlike what you state
    in the documentation.)"

    The Opera documentation does NOT state that the SCRIPT element in XHTML is
    unsupported. It states that with XHTML 1.0 and 1.1 "in 'XML mode'...the
    script element is not supported". For 'XML mode' to be enabled, a document
    must have a MIME type other than "text/html". According to W3C's SGML
    parser, your documents have a MIME type of "text/html", so Opera will not
    interpret them as XML and so the SCRIPT element will be supported.

    There is no mention of 'IE-type mouseovers' in the Opera documentation
    that I could see. Could you point to it?

    Opera does NOT state that is DOM Level 2 compliant. It specifically
    states that "Opera 7 has full support for the [DOM Level 2 Core]
    Fundamental interfaces, apart from these exceptions...". As it does
    not fully support the Core module, it is not supposed to, and does
    not, return 'true' in response to
    document.implementation.hasFeature('core', '2.0').

    Mike

    --
    Michael Winter
    d (replace ".invalid" with ".uk" to reply)
    Michael Winter, Jan 18, 2004
    #11
  12. "Ekkehard Morgenstern" <> wrote in
    message news:bubvr3$53m$...
    <snip>
    > Well, if you had read my post properly, you would've noticed that I
    > mentioned that I haven't tested it with Opera yet.


    My expectation would be that any code intended to provide a consistent
    API for browsers including any good DOM browsers would work unaltered on
    any browser with a good DOM implementation, and especially Opera 7. When
    Opera 7 was first released about 14 months ago I was very happy to find
    that they had done such a good job of their DOM implementation that I
    did not have to alter one line of the code I had written previously.

    But the problem is not only that it failed on Opera for no good reason,
    but how it failed. The result of that failure was to render a site that
    could have been functionally implemented with pure HTML unusable. That
    demonstrates a shortfall in script design, as it doesn't plan for either
    the certain condition where the script fails entirely due to the absence
    of client-side script support, or the inability of the script to
    successfully execute due to the browser's lack of support for the
    required language features. Preventing any chance of achieving clean
    degradation.

    Failing to make suitable provision for clean degradation is a common
    feature of attempts to provide API libraries for browsers. That isn't
    particularly surprising as the path of fall-back and clean degradation
    is something that relates almost entirely to the application the script
    is put to. So the best that any library can do is provide a clear
    indicator of its inability to act and leave it to the author employing
    the API library to test those indicators and react accordingly.

    That significantly undermines the usefulness of API libraries as the
    page author's task still includes all of the design and planning for
    appropriate degradation and he/she still has to implement all of the
    testing and checking code needed to achieve a reliable outcome.

    So instead of learning browser DOMs and then coding to test, examine and
    exploit those they need to learn a library specific API and how to cope
    with its behaviour. Relying on the library to handle the task of
    standardising the interface with the browser and appropriately indicate
    the viability and outcome of that interaction.

    One of the consequences of an author understanding browser DOMs and
    scripting directly for the problem(s) specific to the page/site is that
    he/she only creates enough code to address the situation and no more.
    While the API library approach usually requires that the entire library
    be downloaded whenever any of its components/features are used. And in
    trying to shield the author from learning the DOMs of the browsers the
    API library also serves to shield such an author from understanding how
    to trim the library down to just those parts needed in the situation of
    application.

    That is particularly the case for libraries based on a small number of
    large complex objects as in order to trim those down to only the
    required code the page author also has to fully understand the code for
    those objects. But an API based on a small number of large objects
    would also find it hard to exploit a browser that implements enough to
    address an isolated problem but not sufficient to fully support the
    whole API.

    On the whole I don't think that API libraries are suited to the problem
    of browser scripting. The benefits can be achieved with a collection of
    useful functions and objects tailored to isolated parts of the
    browser-scripting task. But the overheads in attempting to completely
    standardise the whole DOM in one API quickly become significant and
    still doesn't significantly reduce the design and implementation task.

    Richard.
    Richard Cornford, Jan 18, 2004
    #12
  13. "Richard Cornford" <> wrote:
    > My expectation would be that any code intended to provide a consistent
    > API for browsers including any good DOM browsers would work unaltered on
    > any browser with a good DOM implementation, and especially Opera 7. When


    That is what I also expected.

    In the ISKEET library, the ISKEET_DocEncap class encapsulates DOM.
    Only things not supported in DOM are passed to the compatibility layer,
    in the ISKEET_CompatEncap class.

    Unfortunately, DOM isn't even implemented the same across browsers.
    Refer to the Gecko DOM reference (for Netscape/Mozilla), the Opera DOM
    reference, and Internet Explorer's DOM reference.

    For example, Internet Explorer and Opera support some aspects of DOM 2.0,
    but instead of supporting all features to justify DOM 2.0 Core, Event
    and CSS compliance, which would've been simple to implement, they
    expose simply some 2.0 features that they happen to support.

    DOM 2.0 is already old, and 3.0 in the works. This shows how browser
    implementors adhere to standards.

    The ISKEET library relieves the programmer from thinking about such
    stuff. If a feature doesn't work, I can put it into the DocEncap or
    CompatEncap layers without the programmer knowing about it.

    Abstract libraries have been proven successful on Java, C++, C,
    and other languages, and ECMAScript / JavaScript makes no exception.

    I certainly don't want to hardcode my JavaScript support for every
    web page I'm writing.

    JavaScript is not a toy language for little bits of script, it's a
    full-blown object-oriented scripting language that can be used for
    other things than providing little expressions in HTML tag script
    attributes.

    > Opera 7 was first released about 14 months ago I was very happy to find
    > that they had done such a good job of their DOM implementation that I
    > did not have to alter one line of the code I had written previously.


    If the DOM implementation was good, they would've supported all relevant
    modules of DOM 2.0, which is already an old standard.

    But you're right, Opera is suprisingly compatible to Internet Explorer,
    which is a good thing. :)

    > But the problem is not only that it failed on Opera for no good reason,


    It would've also failed if I had used object-recognition for browser
    detection, since in Opera 7, the JavaScript implementation is broken,
    which I provided a workaround for. So all my pages using ISKEET 0.0.4 are
    working now unchanged on Opera 7.

    > but how it failed. The result of that failure was to render a site that
    > could have been functionally implemented with pure HTML unusable.


    I'm using mouseovers and click handlers on the ISKEET web site, which can't
    be implemented in pure HTML.

    > That
    > demonstrates a shortfall in script design, as it doesn't plan for either
    > the certain condition where the script fails entirely due to the absence
    > of client-side script support,


    When JavaScript isn't enabled, the ISKEET library is never called.

    Hence, the web site developer has to include "<noscript>" tags on their
    web site. (currently I haven't done so on the ISKEET home page, but that
    hasn't anything to do with the ISKEET library itself)

    > or the inability of the script to
    > successfully execute due to the browser's lack of support for the
    > required language features. Preventing any chance of achieving clean
    > degradation.


    ISKEET 0.0.4 provides clean degradation. Refer to the ISKEET manual.

    > That isn't
    > particularly surprising as the path of fall-back and clean degradation
    > is something that relates almost entirely to the application the script
    > is put to.


    That is not true -- if the application programmer can rely on a library
    to handle browser-specifics, they don't have to code browser-specifics
    for any script application.

    If their script application fails, it's a problem that can be corrected
    in the library then, in the ideal case.

    > That significantly undermines the usefulness of API libraries as the
    > page author's task still includes all of the design and planning for
    > appropriate degradation and he/she still has to implement all of the
    > testing and checking code needed to achieve a reliable outcome.


    With ISKEET, the program can rely entirely on the library.

    > So instead of learning browser DOMs and then coding to test, examine and
    > exploit those they need to learn a library specific API and how to cope
    > with its behaviour.


    The behaviour of the ISKEET library is supposed to be a black box, but the
    programmer can have a look at the manual to find out what it exactly does.

    > Relying on the library to handle the task of
    > standardising the interface with the browser and appropriately indicate
    > the viability and outcome of that interaction.


    Yes. ISKEET is designed just for that purpose.

    If there's an incompatibility, it can be corrected within ISKEET.

    > One of the consequences of an author understanding browser DOMs and
    > scripting directly for the problem(s) specific to the page/site is that
    > he/she only creates enough code to address the situation and no more.


    That is a common misconception about JavaScript.

    ECMAScript / JavaScript is a full object-oriented scripting language.
    It is designed for more than just small bits of script code.

    With DOM 2.0, and DOM 3.0, provided there'll be standard-conformant
    implementation across all browsers, JavaScript becomes the standard
    tool for scripting web sites.

    If a JavaScript developer hardcodes a script, they're not protected
    from browser incompatibilities. A library can do that.

    > While the API library approach usually requires that the entire library
    > be downloaded whenever any of its components/features are used.


    ISKEET is a small, modular library. The programmer decides which modules
    they use.

    > And in
    > trying to shield the author from learning the DOMs of the browsers the
    > API library also serves to shield such an author from understanding how
    > to trim the library down to just those parts needed in the situation of
    > application.


    In the ISKEET manual, it is mentioned how the programmer can omit parts
    of the library.
    Ekkehard Morgenstern, Jan 18, 2004
    #13
  14. "Michael Winter" <> wrote:
    > > BTW, in other languages, like PHP, the HTTP user agent string is the only
    > > way to recognize the user's web browser.

    >
    > And that has what bearing on JavaScript?


    That JavaScript can safely use the HTTP User Agent string.

    Of course, you have to know what you're doing.

    > In any event, it is unreliable
    > and should not be used for the purpose of detecting implemented
    > functionality.


    I need it to work around a specific Opera 7 bug, but I've added object
    detection support and proper fall-back mechanisms in version 0.0.4 of ISKEET.

    It's not that I wouldn't listen to members of this NG! ;-)

    > As I said above, you can't. For example, Opera, by default, masquerades as
    > Internet Explorer 6.0, probably to get around sites like yours that use
    > the user agent string to distinguish between browsers for no valid reason.


    ISKEET 0.0.4 can recognize Opera, Opera 6 and Opera 7.

    For compatibility-mode document and event handling, ISKEET 0.0.4 assumes
    the Internet Explorer semantics, which seems to work.

    > If a user wishes to change the User-Agent header, or a browser uses a
    > value that does not accurately reflect the actual software, it is you that
    > should suffer the consequences, not the user. There is nothing in either
    > RFC 1945 or RFC 2616 about what the User-Agent header must contain, other
    > than the general syntax of the value. In fact, the header isn't even
    > required.


    So, yeah, the ISKEET library 0.0.4 currently relies on the de-facto usage
    of the HTTP User Agent string.

    It is only the matter of minutes to change it into using object detection
    only.

    However, my library wouldn't have worked on Opera 7 that way, because
    it has a bug in its JavaScript implementation.

    > If you intend to write a viable, robust library, you must to accept the
    > fact that the User-Agent header can be inaccurate, particularly when such
    > a situation is perfectly valid.


    Yes, and 0.0.4 has stronger checks for that. If the string contains
    no useful information, it resorts to pure object presence detection.

    > > There are also lots of browser-version specific JavaScript issues,
    > > which can only be shipped around by checking the HTTP user agent string.

    >
    > Such as?


    Like the JavaScript bug in Opera 7, that permits setting a load handler
    for a window only hardcoded.

    If you pass the window and code objects thru a number of function calls
    and then assign them, it doesn't work.

    The internal function ISKEET_CEO_AddEventHandler() handles that special
    case, which would be impossible without HTTP User Agent check.

    > On to a different subject (you've probably seen enough of "User-Agent
    > header"). From your website:
    >
    > "...Also, the toString() method is defined differently than the
    > toSource() method. Have a look at the ECMA 262 standard!..."
    >
    > I don't quite know what you're referring to there, but I think you should
    > look at ECMA-262. There is no such method, of any object, called toSource.


    JavaScript on Opera, for function objects, assumes toSource() semantics
    where toString() would be appropriate.

    toSource() is a browser-specific function introduced in Netscape Navigator.
    It is present on all Netscape/Mozilla-type implementations.

    That's just minor glitch in Opera that I've noticed that doesn't affect
    the ISKEET library.

    > The Opera documentation does NOT state that the SCRIPT element in XHTML is
    > unsupported. It states that with XHTML 1.0 and 1.1 "in 'XML mode'...the
    > script element is not supported". For 'XML mode' to be enabled, a document
    > must have a MIME type other than "text/html". According to W3C's SGML
    > parser, your documents have a MIME type of "text/html", so Opera will not
    > interpret them as XML and so the SCRIPT element will be supported.


    OK.

    But why not support the script tag in XML mode?

    > There is no mention of 'IE-type mouseovers' in the Opera documentation
    > that I could see. Could you point to it?


    In the event reference for Opera 7, it says that images support only
    "complete". However, mouse down, up, over and out events are also
    supported. :)

    > Opera does NOT state that is DOM Level 2 compliant. It specifically
    > states that "Opera 7 has full support for the [DOM Level 2 Core]
    > Fundamental interfaces, apart from these exceptions...". As it does
    > not fully support the Core module, it is not supposed to, and does
    > not, return 'true' in response to
    > document.implementation.hasFeature('core', '2.0').


    Yeah, but some people think it _is_ DOM 2.0 compliant.

    Since I have Opera 7 now, I can take all browser-specifics of it
    into account when extending the ISKEET library.

    Version 0.0.4 already works for Opera 7 with my sites, and that
    just suits me well.

    I will also test with a number of other browsers, like Konqueror
    and the like, as soon as I get around to it.
    Ekkehard Morgenstern, Jan 18, 2004
    #14
  15. "Randy Webb" <> wrote:
    > Opera 7, in any spoof mode, contains the word "Opera" in the user agent
    > string.


    That's sufficient for the ISKEET library to detect Opera.

    Version 0.0.4 now supports Opera 7.

    > If you had bothered testing that, you would know it. And your
    > statements seem to indicate that your knowledge base of Opera is very
    > limited with regards to its userAgent string and how to detect Opera in
    > general.


    I have downloaded and installed Opera 7, so I'll be able to test the
    current and future versions of ISKEET with it.

    > > As soon as the Opera developers correct their JavaScript implementation
    > > to conform to the standard (i.e. do proper parameter passing of objects
    > > by reference), then I can lift the workaround for the new version.
    > >
    > > This would be impossible to detect without the HTTP UserAgent field,
    > > and that's exactly what it's there for.

    >
    > if (window.opera){
    > //opera code here.
    > }
    >
    > <sarcasm>
    > Wait, I didn't check the userAgent string, I must have done it wrong.
    > </sarcasm>


    What I was referring to was a JavaScript bug in Opera 7.

    By testing "window.opera" you can only detect you're running on Opera.

    But thanks, I will use this to detect Opera in the fall-back mechanism.

    > > Then the user has to deal with the results. Many sites depend on the
    > > UserAgent string, especially PHP sites, but also JavaScript sites.

    >
    > Then "many sites" are poorly written by amateurs posing as professionals
    > that know what they are doing.


    In PHP you have no other way to detect the browser type, since it's
    server-based. A PHP script runs on the server side.

    There are valid reasons for using the UserAgent string in JavaScript also,
    despite this NG might think you can do without it.

    > > Which will never happen, because then a lot of sites depending on this
    > > will stop working. For example, PHP sites that generate optimized JavaScript
    > > code for specific browser types.

    >
    > Again, if you are trying to "optimize" javascript, PHP is *not* the
    > place to try to do it. If you want javascript optimized, use javascript
    > to do it.


    PHP sites that generate browser-specific HTML and JavaScript, can reduce
    the amount of data transferred to the user.

    It's not very uncommon and also used by high-end web sites and content-management
    systems.

    And "using JavaScript to do it", is just what I've done with ISKEET 0.0.4.

    Perhaps someday I will add a JavaScript generator to my PHP library
    (formerly named TigerPaw PHP Toolkit), and incorporate all of ISKEET's
    functionality into it. Which might be a significant portion of code, in
    the future.
    Ekkehard Morgenstern, Jan 18, 2004
    #15
  16. "Ekkehard Morgenstern" <> wrote in
    message news:bucn7n$sme$...
    >"Janwillem Borleffs" <> wrote:
    >>Take a look at Opera, the user can specify how this browser
    >>should identify itself.

    >
    >Actually, for version 0.0.4, which I've just released, I had to
    >work around a specific Opera bug (non-standard JavaScript
    >implementation that does not conform to the ECMAScript 262 standard,
    >unlike Netscape/Mozilla and Internet Explorer). If the user changes
    >the user agent string to omit "Opera", then *poof* all sites using
    >ISKEET will not load properly anymore. Tough luck, eh!


    So following recommendations of techniques that avoid any need to be
    interested in the User Agent string your reaction to failure due to your
    insistence on using the UA string is "Tough luck"?

    >As soon as the Opera developers correct their JavaScript
    >implementation to conform to the standard (i.e. do proper
    >parameter passing of objects by reference), then I can
    >lift the workaround for the new version.
    >
    >This would be impossible to detect without the HTTP UserAgent field,


    There is very little that cannot be determined by feature detection,
    including language bugs. That is a good thing as in reality it is
    impossible to identify the browser with the User Agent string.

    >and that's exactly what it's there for.


    The User Agent header has nothing to do with client side scripts at all.
    And its (unspecified) inclusion as a property of the - navigator -
    object has no implications beyond possibly letting a script find out how
    the browser is identifying itself.

    >>It's not the user, but the vendor which may temper the user
    >>agent string because it's never a fixed value as a rule.

    >
    >Then the user has to deal with the results.


    If the vendors did not include mechanisms for spoofing other browsers
    then the consequences would be worse for the users of their browsers.

    >Many sites depend on the UserAgent string,
    >especially PHP sites, but also JavaScript sites.


    Authoring to the lowest observable standard?

    What do you expect those sites to return if the UA identified itself as
    "IceBrowser 5.4" or "Web Browser 2.0"? They are going to either be
    excluded from the site or get a minimal default (possibly text based)
    pages, aren't they? Your attitude is not to support either in your API
    library. Yet they both are capable of displaying images, using CSS,
    executing ECMA Script and they even have W3C DOM support (dynamic in the
    first case). In reality they both claim to be IE, what other option do
    they have?

    >>Per example, when the developers of the Mozilla browser decide to
    >>use "gecko" instead of "Gecko", your detection is broken.

    >
    >Which will never happen, because then a lot of sites depending
    >on this will stop working. For example, PHP sites that generate
    >optimized JavaScript code for specific browser types.


    Of current Gecko browsers, one has a type-in field in its preferences
    for the user to enter a User Agent string of their own choosing and at
    least one other has a drop-down list which includes UA strings identical
    to both Opera and IE (and others).

    Your PHP sites that attempt to use the UA string to identify the browser
    are broken now, its just that their authors are not bright (or don't
    care) enough understand the issues.

    A large part of the reason that browsers spoof other browsers
    (habitually, or by user options) is to avoid the consequences of this
    sort of server-side browser detecting, because these idiots do not
    recognise many browsers by name so the only way the unrecognised
    browsers can access these sites is to give the impression that they are
    recognised browsers. Very simply, the strategy of making
    content/script/CSS decisions based on the UA string on the server sowed
    the seeds of its own invalidity as a technique. It is currently invalid
    and the results meaningless, browsers cannot be identified using the UA
    string.

    >>better to skip detection all together and test for the
    >>objects/methods you want to use...

    >
    >Which doesn't work for problems like a broken JavaScript
    >implementation in Opera 7.


    To demonstrate a language implementation problem on Opera you need to
    produce an isolated test case. Mixing it with the rest of your garbled
    code demonstrates nothing beyond your limited understanding of ECMA
    Script authoring.

    But even if there were a language implementation problem it would still
    be entirely feasible to create a discrimination test for that feature
    rather than relying on bogus attempts to identify the browser. And, as
    usual, directly testing the feature will produce results that always
    have a one to one relationship with the occurrence of that feature, even
    if that feature is a language bug.

    >See my website, http://www.iskeet.de for a detailed problem
    >description. Download version 0.0.4 to see my workaround.


    Notes which read:-

    <quote cite=" http://www.iskeet.de/ ">
    (if Opera developers are viewing: parameter passing or sth. in your
    JavaScript implementation doesn't seem to work, have a look at the file
    "iskeet_compatencap.js", what workaround I had to do in
    ISKEET_CEO_AddEventHandler(), setting a load handler for a window works
    only hard-coded, as it seems, correct me if I'm wrong! In JavaScript,
    objects are always passed by reference. Also, the toString() method is
    defined differently than the toSource() method. Have a look at the ECMA
    262 standard!). Also you mention in the documentation for Opera 7, that
    it doesn't support the script tag in XHTML, which isn't true. Also,
    event handling for IE-type mouseovers do work (in contrast to the
    documentation). DOM 2.0 implementations have to support
    document.implementation.hasFeature( "Core", "2.0" ), which Opera 7
    doesn't. Hence, it's not DOM 2.0 compliant, unlike what you state in the
    documentation.)
    </quote>

    The toSource and toString method should not be expected to do anything
    but return a string in the case of toString. The ECMA spec has this to
    say:-

    <quote cite="ECMA 262 page 87">
    15.3.4.2 Function.prototype.toString()
    An implementation-dependent representation of the
    function is returned.
    ...
    </quote>

    - and implementation-dependent means that Opera cannot be wrong whatever
    it does. While the toString method of Object.prototype appears to do
    exactly what is required of it.

    And toSource is no part of ECMA Script at all so there can be no
    expectation of its behaviour.

    Whatever you do you can only use window.onload or window.attachEvent in
    Opera 7 as from about 7.02 they removed the addEventListener method from
    the global object. As the global object is not part of the DOM specs
    there are no grounds for complaining about this.

    Opera's XHTML documents do not currently support script elements (only
    intrinsic events) but your pages written as - XHTML 1.0 Strict - are
    being served as - text/html - instead of - application/xhtml+xml - and
    if you tell a browser that you are sending it an HTML page then they
    have a strong tendency to take you at your word and treat what they get
    an unusually formed HTML document and error-correct it back to normal
    tag soup HTML. The result is an HTML DOM and support for any feature
    normally found in HTML DOMs. (Appendix C is a bit of a con really it
    does not result in XHTML documents)

    The claim about passing objects by reference seems to be a
    misinterpretation of the consequences of other conditions and there are
    plenty of those in your code. For example:-

    <quote cite="iskeet_document.js">
    function ISKEET_DocEncap_AddEventHandler( EventType, Elem, Code ) {
    var listener = new Array();
    listener.handleEvent = Code;
    listener.iskeet = new Array();
    listener.iskeet.elem = Elem;
    listener.iskeet.type = EventType;
    if(this.HasDOM && this.HasCoreDOM2 && this.HasDOM2Events){
    listener.iskeet.elem.addEventListener
    (listener.iskeet.type,listener,false);
    }
    else {
    ISKEET_CEO_AddEventHandler
    (listener.iskeet.type,listener.iskeet.elem,
    listener.handleEvent );
    }
    return listener;
    }
    </quote>

    - in which you are creating an Array (and for some reason not the Object
    that would better suite the usage) as the - listener - local variable.
    and then implementing the w3C events Level 2 - EventListener interface
    on it (as defined in the IDL, with a handleEvent method). But the ECMA
    Language Binding defines EventListener as:-

    <quote cite="http://www.w3.org/TR/2000/
    REC-DOM-Level-2-Events-20001113/ecma-script-binding.html">
    Object EventListener
    This is an ECMAScript function reference. This method has
    no return value. The parameter is a Event object.
    </quote>

    - which unambiguously state that the interface _is_ a reference to a
    function object (and the example code demonstrates this). Your
    implementation is Java style rather than ECMA Script style. If it works
    the Java way as well on Gecko browsers then good for them, but it also
    works the ECMA Script way and that is how Opera have implemented it.

    Richard.
    Richard Cornford, Jan 18, 2004
    #16
  17. "Richard Cornford" <> wrote:
    > So following recommendations of techniques that avoid any need to be
    > interested in the User Agent string your reaction to failure due to your
    > insistence on using the UA string is "Tough luck"?


    If I can use window.opera to test for Opera, as someone else suggested,
    then it'll be no problem to detect Opera in the absence of the UA string.

    I had to work around a bug with window.onload = code, which seems to
    work only hard-coded.

    Have a look at the ISKEET_CEO_AddEventHandler() function and its documentation
    for details.

    (version 0.0.4)

    > There is very little that cannot be determined by feature detection,
    > including language bugs.


    How so?

    How can I detect a language bug?

    > That is a good thing as in reality it is
    > impossible to identify the browser with the User Agent string.


    In fact, it's very possible to do that, since not only PHP sites
    depend on the proper setting of it.

    I do not compare the entire string for equality, I just for keywords
    in the string, like "Opera <version>" or "MSIE <version>", which
    are guaranteed to be set anyway.

    > The User Agent header has nothing to do with client side scripts at all.
    > And its (unspecified) inclusion as a property of the - navigator -
    > object has no implications beyond possibly letting a script find out how
    > the browser is identifying itself.


    In version 0.0.4 I use object and feature detection in conjunction with
    the UA string, and it also works when the UA string isn't set at all,
    so I guess the problem is solved now.

    > If the vendors did not include mechanisms for spoofing other browsers
    > then the consequences would be worse for the users of their browsers.


    If you know what you're doing when parsing the UA string, it's not
    a problem that it contains flags to indicate compatibility with
    other browsers.

    > What do you expect those sites to return if the UA identified itself as
    > "IceBrowser 5.4" or "Web Browser 2.0"? They are going to either be
    > excluded from the site or get a minimal default (possibly text based)
    > pages, aren't they?


    Nope. If they support DOM, they'll get as much DOM-handling as possible,
    if they support "document.all", they'll get MSIE-compatible handling,
    and if they support "document.layers", they'll get old Netscape-compatible
    handling.

    Refer to the documentation of ISKEET 0.0.4 for more information.
    Ekkehard Morgenstern, Jan 18, 2004
    #17
  18. On Sun, 18 Jan 2004 10:56:48 +0100, Ekkehard Morgenstern
    <> wrote:

    > "Richard Cornford" <> wrote:


    <snip>

    >> But the problem is not only that it failed on Opera for no good reason,


    <snip>

    >> but how it failed. The result of that failure was to render a site that
    >> could have been functionally implemented with pure HTML unusable.

    >
    > I'm using mouseovers and click handlers on the ISKEET web site, which
    > can't be implemented in pure HTML.


    Links can't be implemented in pure HTML. Since when? True, mouseover and
    click events can't be used, but something as simple as a link can easily
    be dual-natured. Any competent JavaScript author knows that one can do
    this:

    <A href="resource.html" onclick="<jscode>;return false">...</A>

    to provide both a scripted, and pure HTML, interface for the site.

    >> That demonstrates a shortfall in script design, as it doesn't plan for
    >> either the certain condition where the script fails entirely due to
    >> the absence of client-side script support,

    >
    > When JavaScript isn't enabled, the ISKEET library is never called.
    >
    > Hence, the web site developer has to include "<noscript>" tags on their
    > web site. (currently I haven't done so on the ISKEET home page, but that
    > hasn't anything to do with the ISKEET library itself)


    Based on your logic, it's OK that 99% of a site is completely unusable, as
    long as NOSCRIPT is used. Ideally, if JavaScript is non-functional (for
    whatever reason), the entire site will still be fully usable.

    >> or the inability of the script to
    >> successfully execute due to the browser's lack of support for the
    >> required language features. Preventing any chance of achieving clean
    >> degradation.

    >
    > ISKEET 0.0.4 provides clean degradation. Refer to the ISKEET manual.


    <snip>

    ISKEET might, but your site certainly doesn't.

    Mike

    --
    Michael Winter
    d (replace ".invalid" with ".uk" to reply)
    Michael Winter, Jan 18, 2004
    #18
  19. "Michael Winter" <> wrote:
    > > I'm using mouseovers and click handlers on the ISKEET web site, which
    > > can't be implemented in pure HTML.

    >
    > Links can't be implemented in pure HTML. Since when?


    I didn't say that. I won't degrade the website, which works with Internet Explorer,
    Netscape/Mozilla and Opera, as long as JavaScript is enabled, just to satisfy
    your notion to do whatever thing with links.

    > True, mouseover and
    > click events can't be used, but something as simple as a link can easily
    > be dual-natured. Any competent JavaScript author knows that one can do
    > this:
    >
    > <A href="resource.html" onclick="<jscode>;return false">...</A>
    >
    > to provide both a scripted, and pure HTML, interface for the site.


    Which may cause a page load failure on browsers that aren't scripted
    by JavaScript. Then, the script tag could refer to whatever default
    language the browser uses, like MyGreatScriptLanguage 128.39.

    Hence, ISKEET and site-specific scripts are loaded on the ISKEET web page
    explicitly by script tags in the header, declaring the language used
    as JavaScript.

    > Based on your logic, it's OK that 99% of a site is completely unusable, as
    > long as NOSCRIPT is used. Ideally, if JavaScript is non-functional (for
    > whatever reason), the entire site will still be fully usable.


    I didn't say that. I just said I haven't included NOSCRIPT and NOFRAME
    handling on the website yet.
    Ekkehard Morgenstern, Jan 18, 2004
    #19
  20. On Sun, 18 Jan 2004 13:24:11 +0100, Ekkehard Morgenstern
    <> wrote:

    > "Michael Winter" <> wrote:
    >
    >> True, mouseover and click events can't be used, but something as
    >> simple as a link can easily be dual-natured. Any competent JavaScript
    >> author knows that one can do this:
    >>
    >> <A href="resource.html" onclick="<jscode>;return false">...</A>
    >>
    >> to provide both a scripted, and pure HTML, interface for the site.

    >
    > Which may cause a page load failure on browsers that aren't scripted
    > by JavaScript. Then, the script tag could refer to whatever default
    > language the browser uses, like MyGreatScriptLanguage 128.39.


    How? If I state that intrinsic events use JavaScript[1] and the browser
    doesn't support it, it won't handle the event. If it does, that's a flaw
    in the browser's implementation, not my authoring.

    I don't rely on the browser's default scripting language. It states
    clearly in Section 18.2.2 of the HTML 4.01 Recommendation that authors
    must explicity inform the browser of the scripting language used for both
    intrinsic events and SCRIPT elements.

    Mike

    [1] Performed by including the following META element, as per the W3C HTML
    4.01 Recommendation, Section 18.2.2 - Specifying the scripting language.

    <META http-equiv="Content-Script-Type" content="text/javascript">

    --
    Michael Winter
    d (replace ".invalid" with ".uk" to reply)
    Michael Winter, Jan 18, 2004
    #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. Peter Rilling
    Replies:
    0
    Views:
    400
    Peter Rilling
    Feb 9, 2006
  2. Gianni Mariani
    Replies:
    0
    Views:
    357
    Gianni Mariani
    Jun 1, 2004
  3. Maxim Khesin

    [announcement] - python graph library

    Maxim Khesin, Mar 4, 2005, in forum: Python
    Replies:
    1
    Views:
    402
    Harlin Seritt
    Mar 5, 2005
  4. Manu Garg
    Replies:
    0
    Views:
    299
    Manu Garg
    Dec 17, 2007
  5. Ekkehard Morgenstern

    [announcement] ISKEET library 0.0.5

    Ekkehard Morgenstern, Jan 19, 2004, in forum: Javascript
    Replies:
    0
    Views:
    92
    Ekkehard Morgenstern
    Jan 19, 2004
Loading...

Share This Page