JS Enabled But No RegExp Support?

[Matt Kruse]

Are there any current browsers that have Javascript support, but not RegExp
support?
For example, cell phone browsers, blackberrys, or other "minimal" browsers?
I know that someone using Netscape 3 would fall into this category, for
example, but that's not a realistic situation anymore.

And if such a condition exists, then how do you guys handle validation using
regular expressions, if the browser lacks them?

For example:

function isDigits(val) {
if (window.RegExp) {
return !(val.search(/^\d+$/)==-1);
}
else {
// No regexp support
// ????
}
}

If no RegExp support, then should brute-force methods be used using indexOf,
substr, etc? (not for this specific method, but the general case).
And if that's the case, then why even include the duplicate regexp code to
begin with?

Or if the brute-force method should not be used, then what should be
returned? undefined? null? Then the method becomes less useful, because it
doesn't return true or false consistently like a user might expect. Having
an "isX" method that returns "I don't know" makes it very difficult to
validate forms, etc

Just curious what others have concluded, and if the "js enabled but no
RegExp support" condition is even realistic?

 

[Lee]

Matt Kruse said:

Are there any current browsers that have Javascript support, but not RegExp
support?
For example, cell phone browsers, blackberrys, or other "minimal" browsers?
I know that someone using Netscape 3 would fall into this category, for
example, but that's not a realistic situation anymore.

And if such a condition exists, then how do you guys handle validation using
regular expressions, if the browser lacks them?

For what it's worth, my cell phone browser supports regular expressions.
I would handle that case as if it didn't support Javascript at all, since
client-side validation is only for the visitor's convenience, anyway.

 

[Kevin Darling]

Are there any current browsers that have Javascript support, but not RegExp
support?

For work, we have to support Windows CE 3.0 handheld devices (aka HPC
Professional) that use pretty much IE 4.01, and no regular expressions.
The current CE has a far better browser, though.

And if such a condition exists, then how do you guys handle validation using
regular expressions, if the browser lacks them?

It was a pain at first, but now we have a library of validation
routines. As you leave each field, a standard function automatically
validates the field (or group of fields) against attributes of that
field (such as <input required="" timeField=""> ) or by calling a
custom validation routine (<input customValidation='custom(this)'> ).

But that's our burden to bear
Kev

 

[VK]

function isDigits(val) {
if (window.RegExp) {
return !(val.search(/^\d+$/)==-1);
}
else {
/* NOP */
// or
// alert("Where did you get this junk?");
}
}

The first is nicer, the second is more informative and stimulating to
the end user.

Also Konqueror 1.x will very probably crash right on the
(window.RegExp) check.

It seems to crash randomly at the moment you're trying to use
JavaScript for DOM access. This alone kills the imperative "Support for
each and every one". An averagely bad browser producer will always win
against of a good developer however good the developer would be.

About PDA and web-phones: it is too early yet to worry about. IMHO you
should wait until it's clear who's dominating. Did you ever try to use
say an Nokia accessory for Siemens? Or a Siemens charger for Ericsson?
That exact situation with the software: a fight to death, only later
the survivers will start to cooperate to keep away newcomers. I passed
this with WML for the first wave of GPRS phones. The first year one
would have to make a separate solution for each and every phone. And
now WML is pretty set (but getting out of use though).

From my personal experience (I'm having Toshiba with Pocket PC 2002,

now Pocket PC 2005) you always can count on Netscape 2.0 JavaScript
(without document.write() though) and XML/XSLT The latter is a mistery
to me but any prodicer seems to feel obligated to have it. HTMLDocument
DOM will be most probably in absence or cut to a misery state (another
mistery).
All this based on my personal experience and observations therefore it
can be factually, logically and grammatically incorrect.

 

[Evertjan.]

Matt Kruse wrote on 01 dec 2005 in comp.lang.javascript:

return !(val.search(/^\d+$/)==-1);

Your real Q seems to be answered,
but the above line is too complex for me, Mat.

would this do:

return (val.search(/^\d+$/)==0);

or even better[?]

return !/\D/.test(val);

 

[Thomas 'PointedEars' Lahn]

Are there any current browsers that have Javascript support, but not
RegExp support?

Probably not.

And if such a condition exists, then how do you guys handle validation
using regular expressions, if the browser lacks them?

For example:

function isDigits(val) {
if (window.RegExp) {

Do not infer that `window' refers to the Global Object because
it does so in some HTML user agents. The proper feature test
(JavaScript 1.1, JScript 1.0, ECMAScript Ed. 1) is

if (typeof RegExp == "function")

return !(val.search(/^\d+$/)==-1);

Try

return (new RegExp("^\\d+$")).test(val);

I would recommend a RegExp object literal instead of calling
the constructor, but you were asking for a general method where
the latter cannot be assumed.

}
else {
// No regexp support
// ????
}
}

If no RegExp support, then should brute-force methods be used using
indexOf, substr, etc? (not for this specific method, but the general
case).

Yes. For this specific method, I would use a `for' loop,
String.prototype.charAt() and String.prototype.charCode().

And if that's the case, then why even include the duplicate regexp
code to begin with?

Because it is more efficient than the brute-force method, where supported.

[...]
Just curious what others have concluded, and if the "js enabled but no
RegExp support" condition is even realistic?

According to my findings, RegExp literals are supported since JavaScript 1.3
(NN 4.06, 1998), JScript 3.0 (IE 4.0) and ECMAScript Edition 3 (December
1999); the RegExp object and constructor is apparently supported since
JavaScript 1.2 (NN 4.0, June 1997), JScript 3.0 (IE 4.0) and ECMAScript
Edition 3.


PointedEars

 

[Matt Kruse]

Do not infer that `window' refers to the Global Object because
it does so in some HTML user agents.

Name a single exception - then I might agree with you.

Because it is more efficient than the brute-force method, where
supported.

Perhaps, but the need to write, debug, and test two code paths when a single
code path would work for all cases may over-ride the (very) small
performance increase one might see by using regular expressions.

 

[Thomas 'PointedEars' Lahn]

Name a single exception - then I might agree with you.

I do not require your agreement for my statement to be correct.

Perhaps, but the need to write, debug, and test two code paths when a
single code path would work for all cases may over-ride the (very) small
performance increase one might see by using regular expressions.

I did not say you have to.


PointedEars

 

[Thomas 'PointedEars' Lahn]

From http://www.webreference.com/js/column80/6.html:

"The global object is the browser window object,
the one you query the location of by window.location()."

Quoting some thing that calls itself "reference" does not prove anything.

For all practical purposes, the global object is the window object.

That depends on what you call "practical purpose". _Client-side_
scripting in a _(X)HTML_ DOM environment: _probably_ yes, due to history.
Client-side scripting in another environment: not necessarily, and there
are examples of the opposite. Server-side scripting: _no_.

When you name an actual implementation of the global object that is not
browser window-based, then your statement will be more than just what it
is
now: pedantic.

No, examples where it does not apply have already been posted here before.
One just needs to be willing to read and learn. And to know the basics:
There are no windows where they cannot be displayed, hence it would be not
reasonable to have a `window' reference there, let alone let it refer the
Global Object.


PointedEars

 

[Patient Guy]

Quoting some thing that calls itself "reference" does not prove
anything.


That depends on what you call "practical purpose".

That's precisely why the phrase was carefully used. Had I omitted it, I
would have been treated to three paragraphs of needless derision from you
in response, of that I am certain.

_Client-side_
scripting in a _(X)HTML_ DOM environment: _probably_ yes, due to
history. Client-side scripting in another environment: not
necessarily, and there are examples of the opposite. Server-side
scripting: _no_.


No, examples where it does not apply have already been posted here
before. One just needs to be willing to read and learn. And to know
the basics: There are no windows where they cannot be displayed, hence
it would be not reasonable to have a `window' reference there, let
alone let it refer the Global Object.

While it entirely possible to define a global object that is not also a
window object (instance of a class window)----and one should note
carefully that I never claimed that a global object could NOT be something
other than a window object----even those who promulgate the widely agreed-
upon Javascript standard----the ECMA-262 specification----have noted the
following:


10.1.5 Global Object

There is a unique global object (15.1), which is created before
control enters any execution context. Initially the global object
has the following properties:

• Built-in objects such as Math, String, Date, parseInt, etc.
These have attributes { DontEnum }.

• Additional host defined properties. This may include
a property whose value is the global object
itself; for example, in the HTML document object
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
model the window property of the global object is
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
the global object itself.
^^^^^^^^^^^^^^^^^^^^^^^^^

As control enters execution contexts, and as ECMAScript
code is executed, additional properties may be added to
the global object and the initial properties may be changed.

3rd Edition, 1999, p. 38
[underlining mine]


Again, for all practical purposes.....

 

[Thomas 'PointedEars' Lahn]

That's precisely why the phrase was carefully used. Had I omitted it, I
would have been treated to three paragraphs of needless derision from you
in response, of that I am certain.

So at least you do not consider a client-side non-(X)HTML environment (like
SVG or PDF) or (server-side) ASP to be practical. That alone clearly
reflects your level of understanding of JS/ECMAScript programming.

While it entirely possible to define a global object that is not also a
window object (instance of a class window)

There are no classes in JS/ECMAScript implemented in (X)HTML UAs.
(Why am I not surprised?)

Besides, such would not qualify as being practical purpose according
to the standards you dare to set before.

[ECMAScript]
10.1.5 Global Object

[...] Initially the global object has the following properties: | [...]
• Additional host defined properties. This may include
a property whose value is the global object
itself; for example, in the HTML document object
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
model the window property of the global object is
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
the global object itself.
^^^^^^^^^^^^^^^^^^^^^^^^^

That is a "may", not a MUST. That is an informative example, not
a normative statement. The ECMA does specify neither the HTML DOM
nor a UAs _AOM_, of which the `window' reference in fact can be a
feature.


PointedEars

 

[Randy Webb]

Patient Guy said the following on 12/4/2005 9:39 AM:

news:[email protected]:

Again, for all practical purposes.....

Stop arguing with him Patient, he has no grasp of Reality and only knows
about Pedantics and Theory. Classis definition of Troll.......

 

[Matt Kruse]

[ECMAScript]
10.1.5 Global Object
• Additional host defined properties. This may include
a property whose value is the global object
itself; for example, in the HTML document object
model the window property of the global object is
the global object itself.

That is a "may", not a MUST.

A host may define a global object. In the HTML DOM, it's the window object.
Seems pretty clear.

And your original statement:

Do not infer that `window' refers to the Global Object because
it does so in some HTML user agents.

Is unnecessarily argumentative.
Follow the logic if you can:

1. Host objects can implement a property whose value is the global object
2. The HTML DOM this is the window object
3. The original example was written to be used in a browser context
4. Not a single exception to the 'window is the global object' has been
shown for a browser context

Conclusion: In a HTML browser context, you may always assume that the window
object is a reference to the global object.

That was the point, which you tried to stretch into other things, which is
your typical style. It's taken a while for me to realize this, but I'll not
be baited into your ridiculous arguments in the future.

 

[Thomas 'PointedEars' Lahn]

[ECMAScript]
10.1.5 Global Object
• Additional host defined properties. This may include
a property whose value is the global object
itself; for example, in the HTML document object
model the window property of the global object is
the global object itself.

That is a "may", not a MUST.

A host may define a global object. In the HTML DOM, it's the window
object. Seems pretty clear.

Yes, that only _seems_ so.

As I wrote before (which you snipped without marking the omission!), not
the ECMA sets the standard on HTML DOM. The above is a not normative
example.

And your original statement:


Is unnecessarily argumentative.

No, it is not.

Follow the logic if you can:

1. Host objects can implement a property whose value is the global object
2. The HTML DOM this is the window object

There is no such thing as "_the_ HTML DOM"! Browsers that support
client-side scripting implement _an_ HTML DOM, _that_ and _nothing_
more is for sure.


PointedEars

 

[Thomas 'PointedEars' Lahn]

[ECMAScript]
10.1.5 Global Object
• Additional host defined properties. This may include
a property whose value is the global object
itself; for example, in the HTML document object
model the window property of the global object is
the global object itself.

That is a "may", not a MUST.

A host may define a global object. In the HTML DOM, it's the window
object. Seems pretty clear.

Yes, that only _seems_ to be so.

As I wrote before (which you snipped conveniently without marking the
omission!), not the ECMA sets the standard on HTML DOM. The above is
a not normative example.

And your original statement:


Is unnecessarily argumentative.

No, it is not.

Follow the logic if you can:

1. Host objects can implement a property whose value is the global object
2. The HTML DOM this is the window object

There is the flaw in your logic.

There is no such thing as "_the_ HTML DOM". HTML user agents that support
client-side scripting implement _an_ HTML DOM, _that_ and _nothing_ more is
for sure.

And, as I said, the object that can be referred to by `window' is not part
of the _Document_ Object Model, but of the _Application_ Object Model.


PointedEars

 

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 12/4/2005 2:12 PM:

Matt Kruse wrote:

[ECMAScript]
10.1.5 Global Object
� Additional host defined properties. This may include
a property whose value is the global object
itself; for example, in the HTML document object
model the window property of the global object is
the global object itself.

That is a "may", not a MUST.

A host may define a global object. In the HTML DOM, it's the window
object. Seems pretty clear.

Yes, that only _seems_ so.

And until proven otherwise, it will continue to be so. No matter how
argumentative you are about it.

As I wrote before (which you snipped without marking the omission!), not
the ECMA sets the standard on HTML DOM. The above is a not normative
example.

Yes it is. And it will remain normative until you can post the name of a
BROWSER that does not implement the window as the global object.

No, it is not.

You are *always* unnecessarily argumentative.

There is no such thing as "_the_ HTML DOM"! Browsers that support
client-side scripting implement _an_ HTML DOM, _that_ and _nothing_
more is for sure.

That is not even for sure if you want to be really pedantic.

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn said the following on 12/4/2005 2:12 PM:

Thomas 'PointedEars' Lahn wrote:
[ECMAScript]
10.1.5 Global Object
? Additional host defined properties. This may include
a property whose value is the global object
itself; for example, in the HTML document object
model the window property of the global object is
the global object itself.
That is a "may", not a MUST.
A host may define a global object. In the HTML DOM, it's the window
object. Seems pretty clear.

Yes, that only _seems_ so.

And until proven otherwise, it will continue to be so.

Exactly. It will continue to seem to be so.

Yes it is.

Don't be ridiculous. It is definitely not. Examples are never normative
by themself in specifications, the ECMAScript Specification makes no
exception. If it made, it would not deserve to be called a specification
anymore.

And it will remain normative

YMMD. Regarding the HTML DOM, the only _normative_ text would be found
declared as such in the W3C DOM Level 2 HTML Specification. _They_ and
it set the _standard_ for the HTML DOM (which does _not_ mean that there
are no proprietary DOMs [allowed]). But, as I said, windows can contain
documents, they are no part of them, hence cannot be part of a _properly_
called DOM, only of another object model. Since the next greater entity
would be the application, it is reasonable to call that the Application
Object Model as mozilla.org does (the current Wiki is based on a flawed
reference, there are other references that make the distinction).

I wonder if you have any idea what "normative" means regarding a
specification or understood what was written. I seriously doubt it.

That is not even for sure if you want to be really pedantic.

But it is. As stated before, ECMAScript implementations that do not provide
means for output are inherently useless as the language specification
itself does not provide them. Therefore, a script written in an ECMAScript
language implementation in an HTML user agent that is to be used there has
to access host objects to become useful. And if its vendor does not
consider the script language to be an ECMAScript implementation, they
will have to introduce host objects into the language then anyway to
facilitate that feature.

Since we are talking about an _HTML_ UA that supports client-side scripting,
those host objects, whether part of the language or not, are part of a
collection of and objects related to the HTML-based framework, simply
called AOM, or DOM. Since it is highly unlikely that a vendor would
introduce a scripting language solely for the purpose of opening new
windows and showing messages nowadays, considering the competition, that
would _definitely_ include HTML _Document_ object mode objects, hence
there would be a HTML DOM in that UA.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Patient Guy said the following on 12/4/2005 9:39 AM:

Stop arguing with him Patient, he has no grasp of Reality

What you call "Reality" here is merely an assumption based on a handful
of examples, and the irresponsible, illogical, and potentially harmful
wishful thinking that those examples are an indication of all cases.
(Obviously you are not a [computer] scientist.)

If I would follow the logic of some here, including you, from a different
discussion where it was the other way around, I would state that

// global context
var _global = this;

function bla()
{
// _global.RegExp
}

is always reliable and is therefore "better" then the latter while

function bla()
{
// window.RegExp
}

is not always reliable and therefore "worse" than the former.

Now, if you do not follow your own logic when it is used by me because
it does not suit you here, but follow it where it suits you in other
discussions, the objective value that could be placed on your opinion
became perfectly clear: _none_.


PointedEars

 

[VK]

That was the point, which you tried to stretch into other things, which is
your typical style. It's taken a while for me to realize this, but I'll not
be baited into your ridiculous arguments in the future.

You have to admit that the proposed subject *was* provocative (like
many of mines so you should expect some evangelism discussion in
response.

Concerning of the original question from the *practical* point of view:

Regular expressions are supported on all desktop browsers being in use
for the last six years and up to currently.

Individuals still using Netscape 2.x-3.x or IE 2.x-3.x are subject of
the medical attention which neither you nor any other developer can
provide using JavaScript.

Telnet-style browsers (Lynx and others) can be detected on the
server-side and have a mirror site provided *if it is really
needed/required*. Nothing can be done by using JavaScript.

RexExp module still have some different bugs/missing implementations
from one browser to another (Opera is specially bad on it because
RegExp interfers with their Voice module so they still refuse to
implement some RegExp features ). The exact list of glitches should be
on your desktop and you refer to it in each particular occasion. There
is no global decisions to make here.

Web-phones and PDA's are very different spieces in comparison to the
desktop "older brothers". RegExp presence/absence is really one of
*smallest* problems you encounter here. If you get paid for the job (or
just for art) you may develop a separate solution of your site for
handheld devices and redirect to it from the server-side. Otherwise
just hold on for a while until it gets a bit mor standartized (and the
most ugly bugs will be fixed).

*Rough* feature detection should be done in the head block of your
program. From this point out you either branch to the execution or to a
roll-back message/page.
An idea to check *every single method* through the program is bad
(softest to say). This forces a paranoidal code which asks on each
step: "do you have X? and is it that X I'm thinking about? And does it
have Y in it? and is it that Y I'm thinking about? do you tell me
truth? real truth?"

Such behavior is called Anankastic Syndrome and in the programming it
already caused several times some powerful systems run too slow or
crashes from overflow.

Internal checks (besides the startup dispatcher) should be done only
for operations which can fail unrelatedly to the client features: file
access, privilege request, 3rd party module initialization etc.
The commonly accepted way in C-originated languages is to signal using
exceptions. I know that some people in clj react on "throw new Error"
like a young lady seeing an ugly spider on the wall. I guess part of it
may be explained by the terrible word "Error" they see. I agree that
throwing errors is not usual - you're using the softer variant with
Exceptions. But JavaScript doesn't type Error and Exception - they are
all the same for it. But you can easily avoid seeing "Error" in your
code by making your own Exception:

function Exception(m) {
mes = m || 'Unknown error';
return new Error(mes);
}


function something() {
try {
// read file, init XPConnect or ActiveX, etc.
throw Exception('oopsy');
}
catch (e) {
alert(e.message);
}
}

 

[Thomas 'PointedEars' Lahn]

Regular expressions are supported on all desktop browsers being
in use for the last six years and up to currently.

AFAIK not true as the first Opera version that was compliant with
ECMAScript 3, where Regular Expressions were first specified, was
Opera 6.0 (December 2001). Alas I cannot test earlier versions
here.

Internal checks (besides the startup dispatcher) should be done only
for operations which can fail unrelatedly to the client features: file
access, privilege request, 3rd party module initialization etc.
The commonly accepted way in C-originated languages is to signal using
exceptions. I know that some people in clj react on "throw new Error"
like a young lady seeing an ugly spider on the wall. I guess part of it
may be explained by the terrible word "Error" they see. I agree that
throwing errors is not usual - you're using the softer variant with
Exceptions.

In all your rambling speech, you have still not understood that certain
features of the languages discussed here are not downwards compatible and
not compatible to the next implementation. Since we are talking about a
general solution, compatibility is the major issue, if not the only one.
So you have missed the point completely. Again.

But JavaScript doesn't type Error and Exception - they are all the same
for it.
Nonsense.

But you can easily avoid seeing "Error" in your
code by making your own Exception:

function Exception(m) {
mes = m || 'Unknown error';

Creating a global variable as both the `var' and the `this' keyword are
missing.

return new Error(mes);
}


function something() {
try {
// read file, init XPConnect or ActiveX, etc.
throw Exception('oopsy');
}
catch (e) {
alert(e.message);

`e.message' does not refer to `mes'.

}
}

I have already stated before that Exception handling is a Good Thing but
requires a certain version/edition of JavaScript/JScript/ECMAScript to not
result in a syntax error, hence to succeed in the first place. It is
ridiculous design to use Exception handling to test a feature that was
there long before Exceptions were even supported by either language.


PointedEars