Hi guys,
I have put together a flexible client-side user agent detector (written in
js). I thought that some of you may find it useful. Code is here: http://fotios.cc/software/ua_detect.htm
The detector requires javascript 1.0 to work. This translates to netscape
2.0 and IE 3.0 (although maybe IE 2.0 also works with it)
Cheers,
Fotios
-- http://fotios.cc/ 60  7191 
"Fotios" <f_****@yahoo.com> writes: I have put together a flexible client-side user agent detector (written in
js). I thought that some of you may find it useful. Code is here:
http://fotios.cc/software/ua_detect.htm
My only real problem with this code, is the problem it tries to solve.
You are trying to make a white-list of allowed browsers. White-lists
are not a very good idea, since they require constant updating. A
black-list is better. If you give a warning for browsers that you know
are *not* compatible with your page, and you write code that works
with modern standards, then you will rarely have to update the list.
That is, give an unknown browser the benefit of the doubt.
You also base the detection solely on the navigator.userAgent string.
That is not a reliable method, as some browsers are known to fake that
string.
There are some minor stuff:
- You use parseInt with only one argument. (And which browser has the
length of an array as a string?)
- You use "new Array(elem1,elem2,...,elemn);", which doesn't seem to
initialize the array in Netscape 2.02 (nor does the length property
of the array work).
- You write <script language="JavaScript">, which is illegal in HTML 4+.
The type attribute is required.
The detector requires javascript 1.0 to work. This translates to
netscape 2.0 and IE 3.0 (although maybe IE 2.0 also works with it)
IE 2 didn't have scripting at all. That was introduced in IE 3.0b2,
IIRC. I don't think the script is compatible with Netscape 2.
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'
"Fotios" <f_****@yahoo.com> wrote in message
news:3f*********************@news.gradwell.net... I have put together a flexible client-side user agent detector (written
in js). I thought that some of you may find it useful. Code is here:
http://fotios.cc/software/ua_detect.htm
The detector requires javascript 1.0 to work. This translates to
netscape 2.0 and IE 3.0 (although maybe IE 2.0 also works with it)
User agent detecting is unnecessary in almost all cases but of the
methods that have been attempted the use of the browser's
navigator.userAgent string is easily the most useless as very few
current browsers report consistent or accurate information in this
string. Often in order to avoid this type of clumsy and misguided
detection categorising them as "unknown" or "declined" when their
JavaScript and DOM support is entirely up to the requirements of the
majority of scripts and their authors can see no reason for them to be
excluded just because some script author only knows enough to recognise
7 browsers by name.
<URL: http://jibbering.com/faq/#FAQ4_26 >
Richard.
Hi Lasse,
thanks for taking the time to help me (or us) improve this code!
My only real problem with this code, is the problem it tries to solve.
You are trying to make a white-list of allowed browsers. White-lists
are not a very good idea, since they require constant updating. A
black-list is better. If you give a warning for browsers that you know
are *not* compatible with your page, and you write code that works
with modern standards, then you will rarely have to update the list.
I understand what you are trying to say but my experience from web
development says that if you want to play it safe you should only allow your
code to run on specific browsers - the browsers you have tested it with.
However, if you review the code you will see that is uses a list that is
both black and white; i.e. you can have both white listed and black listed
browsers (Black listing takes precedence)
That is, give an unknown browser the benefit of the doubt.
If you check the code you will see there is an option just for that (i.e.
whether you want to allow an unknown browser to continue or not)
You also base the detection solely on the navigator.userAgent string.
That is not a reliable method, as some browsers are known to fake that
string.
Well, let's say that I won't be interested in covering this case just yet.
AFAIK all major browsers have a default user agent string that is
distinctive in some way and the rest of them (not major) should as well.
There are some minor stuff:
- You use parseInt with only one argument. (And which browser has the
length of an array as a string?)
- You use "new Array(elem1,elem2,...,elemn);", which doesn't seem to
initialize the array in Netscape 2.02 (nor does the length property
of the array work).
You are right on both of these two remarks. The first one was due to my
sloppy testing of NN 2.0; I was getting an error and I assumed this was due
to wrong typing of the length property of arrays but further testing I just
did shows that this property is simply undefined (thus the error).
And yes, this style of Array initialization does not seem to work with NN
2.0.
So, what I still need to make this work under NN 2.0 is:
- write a function that counts the length of an array in a way that is JS
1.0 compatible.
- initialize the array with arr[index] = value; type of statements
I should have the revised version soon.
BTW, there is a great old browser software archive here:
http://browsers.evolt.org/
- You write <script language="JavaScript">, which is illegal in HTML 4+.
The type attribute is required.
Thanks for letting me know. I added it.
The detector requires javascript 1.0 to work. This translates to
netscape 2.0 and IE 3.0 (although maybe IE 2.0 also works with it)
IE 2 didn't have scripting at all. That was introduced in IE 3.0b2,
Yeah, some crooked hypothesis making on my part there. That was Netscape's
golden era.
Later,
Fotios
User agent detecting is unnecessary in almost all cases but of the
methods that have been attempted the use of the browser's
navigator.userAgent string is easily the most useless as very few
current browsers report consistent or accurate information in this
string. Often in order to avoid this type of clumsy and misguided
detection categorising them as "unknown" or "declined" when their
JavaScript and DOM support is entirely up to the requirements of the
majority of scripts and their authors can see no reason for them to be
excluded just because some script author only knows enough to recognise
7 browsers by name.
I rarely read something as inacurate as what you have just written.
What about the fact that most script that goes around does not run properly
in more than one or two browsers? A detector is about "what is" not about
"what ought to be".
F.
"Fotios" <f_****@yahoo.com> wrote in message
news:3f*********************@news.gradwell.net... User agent detecting is unnecessary in almost all cases but of the
methods that have been attempted the use of the browser's
navigator.userAgent string is easily the most useless as very few
current browsers report consistent or accurate information in this
string. Often in order to avoid this type of clumsy and misguided
detection categorising them as "unknown" or "declined" when their
JavaScript and DOM support is entirely up to the requirements
of the majority of scripts and their authors can see no reason for
them to be excluded just because some script author only knows
enough to recognise 7 browsers by name.
I rarely read something as inacurate as what you have just written.
So you haven't bothered to read the comp.lang.javascript FAQ before
posting then:-
<URL: http://jibbering.com/faq/#FAQ4_26 >
- as it says essentially the same thing. (Still, I don't expect you
would consider that a document that is subject the scrutiny and review
of all of the regular poster to this group as having anything accurate
to say on the subject of browser scripting.)
What about the fact that most script that goes around does not run
properly in more than one or two browsers?
"most script that goes around" is written (or more often cut-n-pasted)
by people who do not really understand what they are doing and should
not be taken as an example of best (and in many cases not even
acceptable) practice.
A detector is about "what is" not about "what ought to be".
So test "what is" not "what ought to be" which is what you are testing
by assuming that the navigator.userAgent string ought to be a
discriminating indicator of the type and version of a web browser. It is
not and has not been for quite some time now.
As it is your code will identify Konqueror 3 as IE, Netscape, Opera,
Konqueror and unknown depending on which of the userAgent string I
choose form the list of 20 odd provided in the drop-down in the
preferences. While the same script will be absolutely convinced that my
Palm OS web browser is IE 6, but a script that treats it as IE 6 will
fail horribly. To qualify as a "detector" a script should be expected to
produce discriminating results. The navigator.userAgent string just
cannot provide that.
But, as I said, it is almost never necessary to know the browser type or
version. Feature detection is the preferred strategy. A script author
should know what features a browser must support in order for a script
to work. Testing for the existence of those features prior to execution
allows a script to execute in any browser that supports them and if they
are not available it can cleanly and harmlessly exit. A strategy that is
only interested in "what is" available on the browser in question, but
without any interest in which browser that actually is. Also a strategy
that can work successfully in a completely unknown browser, exploiting
any browser up to its ability to support the script.
Richard. So you haven't bothered to read the comp.lang.javascript FAQ before
posting then:-
<URL: http://jibbering.com/faq/#FAQ4_26 >
I do not need to read the FAQ before or after I post.
- as it says essentially the same thing. (Still, I don't expect you
would consider that a document that is subject the scrutiny and review
of all of the regular poster to this group as having anything accurate
to say on the subject of browser scripting.)
I don't know what to answer to you as I have not read the FAQ.
What about the fact that most script that goes around does not run
properly in more than one or two browsers?
"most script that goes around" is written (or more often cut-n-pasted)
by people who do not really understand what they are doing and should
not be taken as an example of best (and in many cases not even
acceptable) practice.
Isn't it still a fact that most script that goes around is not
cross-browser?
I have also heard that no scripter really knows what he/she is doing. What
do you think about that?
A detector is about "what is" not about "what ought to be".
So test "what is" not "what ought to be" which is what you are testing
by assuming that the navigator.userAgent string ought to be a
discriminating indicator of the type and version of a web browser. It is
not and has not been for quite some time now.
One can easily write a lynx-like user agent that supplies any user string
he/she damn pleases.
Why does that shatter the status of things? (The status being that all major
browsers have - and should have - distinctive default strings)
As it is your code will identify Konqueror 3 as IE, Netscape, Opera
Konqueror and unknown depending on which of the userAgent string I
choose form the list of 20 odd provided in the drop-down in the
preferences.
Well, if you change the string you are on your own.
While the same script will be absolutely convinced that my
Palm OS web browser is IE 6, but a script that treats it as IE 6 will
fail horribly. To qualify as a "detector" a script should be expected to
produce discriminating results. The navigator.userAgent string just
cannot provide that.
Only because you were naughty and you changed the string.
What is the motivation in coding for the miniscule percentage of users who
not only use virtually non-existent browsers but also play with their user
agent strings?
But, as I said, it is almost never necessary to know the browser type or
version. Feature detection is the preferred strategy. A script author
should know what features a browser must support in order for a script
to work.
Testing for the existence of those features prior to execution
allows a script to execute in any browser that supports them and if they
are not available it can cleanly and harmlessly exit. A strategy that is
only interested in "what is" available on the browser in question, but
without any interest in which browser that actually is. Also a strategy
that can work successfully in a completely unknown browser, exploiting
any browser up to its ability to support the script.
1. Detecting a browser type is not necessarily for scripting purposes. For
instance, you may not like the way something renders in gecko.
2. I don't want to build a detector every time depending on what I want to
use.
3. A generic feature based browser detector seems to be much more work than
the one I posted. If you build one let me know and I will give it a try.
F.
Hi,
I have amended the code in a few places in order to be Netscape 2.0 (JS 1.0)
compatible:
* The JS1.0 parseFloat() function needed some help as it returns 0 (instead
of the NaN in later JS versions) when the initial char of the string is not
a digit.
There is now a helper function named: skipNonDigits()
* The array is now populated in a way that is JS 1.0 compatible
* I use substring() instead of substr(). This is because the former seems to
be working better in Netscape 2.0 although both are supported by JS 1.0
* In lack of the length property for arrays under JS 1.0 the length of the
browser array needs to be specified by the user along with the rest of the
parameters.
Revised code here: http://fotios.cc/software/ua_detect.htm
Cheers,
Fotios
"Fotios" <f_****@yahoo.com> wrote in message
news:3f*********************@news.gradwell.net... So you haven't bothered to read the comp.lang.javascript FAQ before
posting then:-
<URL: http://jibbering.com/faq/#FAQ4_26 >
I do not need to read the FAQ before or after I post.
You won't be jailed, but it seriously harms both your insight and our
sympathy if you don't.
I have also heard that no scripter really knows what he/she is doing. What
do you think about that?
No one can speak but for themselves, especially if they spend their time
behind computer screens. I for one haven't a clue. While the same script will be absolutely convinced that my
Palm OS web browser is IE 6, but a script that treats it as IE 6 will
fail horribly. To qualify as a "detector" a script should be expected to
produce discriminating results. The navigator.userAgent string just
cannot provide that.
Only because you were naughty and you changed the string.
What is the motivation in coding for the miniscule percentage of users who
not only use virtually non-existent browsers but also play with their user
agent strings?
I started reading this thread with a positive feeling, but this turns sour.
What is the movitation behind writing a script that scrutinizes something so
irrelevant? The bottom line is the navigator agent string thing can be
changed at will both by browser-makers and end-users. Mine is a Shakespeare
quote.
If I want my script to bark up the document.images tree, I will not test for
document.styleSheets or screen.availWidth or navigator.anyThing.
Regards,
Ivo
In article <3f***********************@news.wanadoo.nl>, "Ivo" <no@thank.you>
writes:
<snip> I do not need to read the FAQ before or after I post.
You won't be jailed, but it seriously harms both your insight and our
sympathy if you don't.
Not to mention credibility. He multi-posted these same thoughts in the
microsoft.public.scripting.jscript NG
<snip> Only because you were naughty and you changed the string.
What is the motivation in coding for the miniscule percentage of users who
not only use virtually non-existent browsers but also play with their user
agent strings?
I started reading this thread with a positive feeling, but this turns sour.
You too?
<snip>
--
Randy
You won't be jailed, but it seriously harms both your insight
maybe, but it helps uncalcify my thinking.
and our
sympathy if you don't.
awwwww! Please? Pretty Please?
I have also heard that no scripter really knows what he/she is doing.
What do you think about that?
No one can speak but for themselves, especially if they spend their time
behind computer screens. I for one haven't a clue.
This philosophy of yours is very deep.
The bottom line is the navigator agent string thing can be
changed at will both by browser-makers and end-users. Mine is a
Shakespeare quote.
my friend, you are too kewl!
If I want my script to bark up the document.images tree, I will not test
for document.styleSheets or screen.availWidth or navigator.anyThing.
In your limited universe (browser detection) = (browser detection for
javascript running purposes)
Regards,
Ivo
More regards,
Fotios
> Not to mention credibility. He multi-posted these same thoughts in the microsoft.public.scripting.jscript NG
<snip>
I do not see what credibility has to do with posting in two groups instead
of one.
Then again, if it is so, I wonder how this original theory of yours applies
to multi-NG whiners.
You too?
hey, you found company! You guys should build on this.
F.
On Mon, 22 Sep 2003 06:23:59 +0100, "Fotios" <f_****@yahoo.com> wrote: Isn't it still a fact that most script that goes around is not
cross-browser?
Who knows.
I have also heard that no scripter really knows what he/she is doing. What
do you think about that?
I think that sounds like flame bait. I think that if you believe
that, then you just insulted yourself. I think you need better
sources of information. I think that if you stick around the
newsgroup for a while you will discover that statement is wrong.
2. I don't want to build a detector every time depending on what I want to
use.
Yeah, if you want to test whether the browser is capable of doing,
say, image rollovers, writing
var fSupportsScriptableImages = (document.images ? true : false);
sure is a real pain.
3. A generic feature based browser detector seems to be much more work than
the one I posted. If you build one let me know and I will give it a try.
No one would ever write a "generic feature based browser detector".
Whatever that is. You don't need to know every feature the browser
supports; you only need to know if it supports the specific feature(s)
you are trying to use.
This isn't an argument you'll win; feature/object detection has long
been recommended over browser detection. It's less prone to error and
it requires less maintenance because it's backward and FORWARD
compatible.
Regards,
Steve
JRS: In article <3f*********************@news.gradwell.net>, seen in
news:comp.lang.javascript, Fotios <f_****@yahoo.com> posted at Mon, 22
Sep 2003 06:23:59 :- So you haven't bothered to read the comp.lang.javascript FAQ before
posting then:-
<URL: http://jibbering.com/faq/#FAQ4_26 >
I do not need to read the FAQ before or after I post.
It would, however, be a useful precaution against appearing to be a
person of inadequate sagacity. Of course, that appearance would in that
case not be misleading.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> JS maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/JS/&c., FAQ topics, links. I have also heard that no scripter really knows what he/she is doing.
Whatdo you think about that?
I think that sounds like flame bait. I think that if you believe
that, then you just insulted yourself. I think you need better
sources of information. I think that if you stick around the
newsgroup for a while you will discover that statement is wrong.
Looks like you are biting. BTW, I have been around this group for years.
Yeah, if you want to test whether the browser is capable of doing,
say, image rollovers, writing
var fSupportsScriptableImages = (document.images ? true : false);
sure is a real pain.
Wouldn't you rather skip that part?
No one would ever write a "generic feature based browser detector".
Whatever that is.
Yeah, I suppose it is not mentioned in the FAQ; so FAQ puppies get
short-circuited.
This isn't an argument you'll win; feature/object detection has long
been recommended over browser detection.
This world is not black and white. Browser detection using the useragent
string still has a place and a function for the reasons I mentioned and
without claiming it is a panacea.
BTW, I am still waiting for your answer on the rest of my points about why
one would use useragent string based detection.
F.
It would, however, be a useful precaution against appearing to be a
person of inadequate sagacity. Of course, that appearance would in that
case not be misleading.
This is a javascript group doc. If you are looking for sagacity per se maybe
you are looking in the wrong place. If your way of achieving sagacity is
reading JS FAQs then maybe you ought to wonder if something is wrong with
you. Finally, if you wish to rephrase the syntactic and semantic abomination
you just posted, I'll still read it (although I don't know if I really
should).
F.
-- http://fotios.cc/
"Fotios" <f_****@yahoo.com> wrote in message
news:3f*********************@news.gradwell.net... So you haven't bothered to read the comp.lang.javascript
FAQ before posting then:-
<URL: http://jibbering.com/faq/#FAQ4_26 >
I do not need to read the FAQ before or after I post.
- as it says essentially the same thing. (Still, I don't
expect you would consider that a document that is subject
the scrutiny and review of all of the regular poster to
this group as having anything accurate to say on the
subject of browser scripting.)
I don't know what to answer to you as I have not read
the FAQ.
You could try to explain why you "do not need to read the FAQ". It
certainly isn't because you are already familiar with its contents, or
that you know JavaScript and browser scripting better than its
collective authors (though it may be because you believe one, or both,
of those to be the case).
<snip>Isn't it still a fact that most script that goes around
is not cross-browser?
Yes, it is also a fact that some scripts do not even manage to be
multi-browser (which is all that your scripting actually aspires to be,
judging by your other posts in this thread). But why would
comp.lang.javascript promote the lowest common denominator as the
acceptable standard in a world where the norm is so poor? In fact the
poverty of the mass of current Internet script authoring is probably the
best justification for promoting only the highest standards in browser
scripting: True cross-browser scripting; authoring for any and every
browser, including the ones that will not execute JavaScript at all. And
the only strategy that is capable of delivering scripts that function,
or gracefully degrade (as appropriate), in JavaScript enabled browsers
is feature detecting to determine browser support for the features
required by the script.
I have also heard that no scripter really knows what
he/she is doing. What do you think about that?
If you did hear that it will have been from the lips of someone who did
not know what they were doing and was looking to justify their
unwillingness to find out.
A detector is about "what is" not about "what ought to be".
So test "what is" not "what ought to be" which is what
you are testing by assuming that the navigator.userAgent
string ought to be a discriminating indicator of the type
and version of a web browser. It is not and has not been
for quite some time now.
One can easily write a lynx-like user agent that supplies
any user string he/she damn pleases.
It appears (from existing web browsers) that it is not too difficult to
write an IE-like web browser that supplies whatever user agent string
the user chooses (or its authors prefer). It has been done, many times.
Why does that shatter the status of things? (The status being
that all major browsers have - and should have - distinctive
default strings)
Of what value is it that some browsers have default user agent string
that are distinct from each other when they are indistinguishable from
the user agent strings of a cluster of other browsers? Of what value is
it when those strings are only the default values and the user has easy
access to mechanisms for changing them; mechanisms that (usually) have
zero impact on the actual abilities of the browser? And why "should
have"? Because it suites you?
The status of things is that the navigator.userAgent string is no longer
a discriminating identifier of web browsers and, if it ever was, it
never will be again.
As it is your code will identify Konqueror 3 as IE,
Netscape, Opera Konqueror and unknown depending on which
of the userAgent string I choose form the list of 20 odd
provided in the drop-down in the preferences.
Well, if you change the string you are on your own.
Web browsers are user configurable software. If the user has the options
in the software preferences then it is just unrealistic not to expect
them to configure their browser to reflect their preferences. In all of
the web site/application specifications I have seen to date I have seen
requirements to work with only a limited set of named browsers/versions
and even requirements to work only with JavaScript enabled browsers but
I have never seen it stated that scripts were only required to work with
those browsers in their _default_ configurations.
Of course your "browser detecting" followed by the assumption that
everything is then going to be the way that you are expecting it is
going to fall down with many non-default configurations even on IE.
While the same script will be absolutely convinced that
my Palm OS web browser is IE 6, but a script that treats
it as IE 6 will fail horribly. To qualify as a "detector"
a script should be expected to produce discriminating
results. The navigator.userAgent string just cannot provide
that.
Only because you were naughty and you changed the string.
No I did not. Pals OS web browser is just one of a number of browsers
that use a user agent string that is indistinguishable from an IE user
agent string, and it doesn’t give the user any direct access to
alternatives. And indistinguishable means indistinguishable, there is no
telling substring that can be used to distinguish them from IE versions
(on the Palm even the reported OS is fictional).
What is the motivation in coding for the miniscule percentage
of users who not only use virtually non-existent browsers
but also play with their user agent strings?
Because feature detecting does not have any interest in the type or
version of the web browser so there is no extra effort or work involved
in coping with any minority browser. (assuming of course that these
browsers that are indistinguishable from IE are actually minority
browsers. It is impossible to tell if they always appear in the browser
statistics as IE). You just write the script and if the browser supports
the required features then you are in business and if not its time to
gracefully degrade.
But, as I said, it is almost never necessary to know the
browser type or version. Feature detection ...
<snip>
1. Detecting a browser type is not necessarily for scripting
purposes. For instance, you may not like the way something
renders in gecko.
Rendering is presentation, so CSS. Use CSS solutions for CSS problems,
involving scripting is unnecessary (and unreliable) but you cannot make
a discriminating identification of a Gecko browser from its user agent
string anyway as several Gecko variants (most notably Gostzill) are ser
up to report any of a range of preference settable userAgent strings
(including spoofing IE 100%) and a few even provide the user with the
option to type in anything they want as a user agent string. (these are
normal GUI configuration settings available under preferences not some
devious hack. However, all Gecko userAgent strings are amenable to
alteration by devious hack as well).
2. I don't want to build a detector every time depending
on what I want to use.
You are still thinking in terms of browser detecting. Feature detecting
is an integral part of scripting; there is no distinct "detector" at
all.
3. A generic feature based browser detector seems to be
much more work than the one I posted. If you build one
let me know and I will give it a try.
The reason that I use the term "feature detecting" as opposed to the
more common term "object detecting" (apart from the fact that you also
have to be testing functions, properties with primitive values and
sometimes language implementation characteristics) is that "object
detecting" is associated with attempts to detect browser types and
versions based on objects present in their DOMs. That technique was
widely adopted when it initially became clear that browser detecting
based on userAgent strings was no longer viable and initially produced
code like:-
var isIE = document.all?true:false;
var isNet4 = document.layers?true:false;
The response to this type of browser detecting (attempts at a generic
object detecting based browser detector) was that other browser
manufacturers started implementing document.all collections, or
document.layers collections or any other object/feature that someone had
hit upon as a discriminating indicator of a particular browser. And they
did this for exactly the same reasons that they started spoofing each
other’s user agent strings in the first palace. We now live in a world
where as many browsers have a document.all collection as don’t and the
last thing that its presence in a DOM means is that the browser is IE.
And it goes on; someone hits upon the idea of using the ActiveXObject
constructor as a discriminating indicator of IE 5+ and then uses that to
exclude non-IE 5+ browsers, and then we find that IceBrowser 5 has an
ActiveXObject constructor.
Pick a feature as a discriminating indicator of a browser and implement
your browser detecting based on that and the next thing you know a
couple of other browsers will have implemented that feature, or faked
it, and your browser detecting script is no longer doing what it was
designed to do.
The recurring theme here is that the purpose that you, and most others,
put browser detecting to motivates the browser manufacturers (including
Microsoft; witness the "Mozilla 4.0" that its userAgent string starts
with) to do what ever it takes to sidestep that browser detection.
The result is that browser detection as a practice has resulted in its
own invalidity.
The solution is to abandon browser detection as an idea and concentrate
on detecting the specific features that a script actually needs in order
to run. Never interested in the type of version of the browser, never
assuming that the existence of on feature implies the presence of
another and resulting in scripts that do what they can when they can and
fail cleanly when they can't, even on the browsers that will not be
released until next year and whose names are as yet unknown.
Richard. You could try to explain why you "do not need to read the FAQ".
Sure. For the same reason I do not need to read the bible in order to be a
good Christian.
I suppose one can find many similar ways to explain what you asked.
I'll tell you the truth tho. I have read the FAQ about 2 years back.
Since then so much has happened that I do not even remember what was in
there and what not.
It
certainly isn't because you are already familiar with its contents, or
that you know JavaScript and browser scripting better than its
collective authors
(though it may be because you believe one, or both,
of those to be the case).
I don't even ponder over such questions. It is just that I like solving
problems on my own. I am in this business strictly for the fun that this
entails.
<snip>Isn't it still a fact that most script that goes around
is not cross-browser?
Yes, it is also a fact that some scripts do not even manage to be
multi-browser (which is all that your scripting actually aspires to be,
judging by your other posts in this thread).
Well, the scripts that I have posted are certainly multi-browser so what you
say here is obviously wrong.
True cross-browser scripting; authoring for any and every
browser, including the ones that will not execute JavaScript at all. And
the only strategy that is capable of delivering scripts that function,
or gracefully degrade (as appropriate), in JavaScript enabled browsers
is feature detecting to determine browser support for the features
required by the script.
Read below for an answer to that.
I have also heard that no scripter really knows what
he/she is doing. What do you think about that?
If you did hear that it will have been from the lips of someone who did
not know what they were doing and was looking to justify their
unwillingness to find out.
You sound hurt. Why don't you tell us what else you do well except scripting
(if we assume that you even do that well).
Maybe you can prove that you don't have any ego-related reason in making
this claim.
Of what value is it that some browsers have default user agent string
that are distinct from each other when they are indistinguishable from
the user agent strings of a cluster of other browsers? Of what value is
it when those strings are only the default values and the user has easy
access to mechanisms for changing them; mechanisms that (usually) have
zero impact on the actual abilities of the browser? And why "should
have"? Because it suites you?
Have you ever wondered why the user agent string is there at all? Why was it
introduced and kept in countless versions and builds?
I quote from RFC 2616:
----
14.43 User-Agent
The User-Agent request-header field contains information about the
user agent originating the request. This is for statistical purposes,
the tracing of protocol violations, and automated recognition of user
agents for the sake of tailoring responses to avoid particular user
agent limitations. User agents SHOULD include this field with
requests. The field can contain multiple product tokens (section 3.8)
and comments identifying the agent and any subproducts which form a
significant part of the user agent. By convention, the product tokens
are listed in order of their significance for identifying the
application.
User-Agent = "User-Agent" ":" 1*( product | comment )
Example:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
----
After all the computer world only revolves because there are standards that
are followed by majorities.
The status of things is that the navigator.userAgent string is no longer
a discriminating identifier of web browsers and, if it ever was, it
never will be again.
The point is that it should be.On the other hand perhaps your faith that
object/property testing will remain a good way to test is overly inflated.
Web browsers are user configurable software. If the user has the options
in the software preferences then it is just unrealistic not to expect
them to configure their browser to reflect their preferences. In all of
the web site/application specifications I have seen to date I have seen
requirements to work with only a limited set of named browsers/versions
and even requirements to work only with JavaScript enabled browsers but
I have never seen it stated that scripts were only required to work with
those browsers in their _default_ configurations.
You are not supposed to fake user agent strings. Period.
This feature has only become available in various browsers and only because
it is very easily implementable.
Of course your "browser detecting" followed by the assumption that
everything is then going to be the way that you are expecting it is
going to fall down with many non-default configurations even on IE.
What percentage do you think? I say it works 99%.
No I did not. Pals OS web browser is just one of a number of browsers
that use a user agent string that is indistinguishable from an IE user
agent string, and it doesn't give the user any direct access to
alternatives. And indistinguishable means indistinguishable, there is no
telling substring that can be used to distinguish them from IE versions
(on the Palm even the reported OS is fictional).
Too bad. I think Opera also had the unfortunate idea of defaulting to
completely faking the IE ua string a few versions back. It seems they did
not keep it up for long.
(assuming of course that these
browsers that are indistinguishable from IE are actually minority
browsers. It is impossible to tell if they always appear in the browser
statistics as IE).
Heh, sorry but this reminds me of comical Ali.
1. Detecting a browser type is not necessarily for scripting
purposes. For instance, you may not like the way something
renders in gecko.
Rendering is presentation, so CSS. Use CSS solutions for CSS problems,
Yeah but CSS does not always work the way one wants and the detection is
done in JS not CSS.
You are still thinking in terms of browser detecting. Feature detecting
is an integral part of scripting; there is no distinct "detector" at
all.
wow, that is tew kewl (and deep).
A few points to keep you busy:
* Should every browser preferably have a distinctive user agent string or
not? Don't read the RFC just use your common sense.
* You are trying to make a rule out of the exception (exception being the
faked strings)
* I can write a user agent that fakes the existence of certain JS objects
but provides others while for the faked ones has Shakespeare quotes as the
return value of various methods. I could name this product Fudgilla (create
say 10 variants of it under different names like Geekzilla), make it freely
available to the geek crowds and then argue that because these products
exist the feature detection method is no good anymore for deciding what kind
of browser we got.
Don't scratch your head too hard.
F.
"Fotios" <f_****@yahoo.com> writes: Yes, it is also a fact that some scripts do not even manage to be
multi-browser (which is all that your scripting actually aspires to be,
judging by your other posts in this thread).
Well, the scripts that I have posted are certainly multi-browser so what you
say here is obviously wrong.
Uhm, no. He said that it is multi-browser, but not cross-browser, so
you agree with him.
Have you ever wondered why the user agent string is there at all? Why was it
introduced and kept in countless versions and builds?
....
User-Agent = "User-Agent" ":" 1*( product | comment )
Example:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
----
After all the computer world only revolves because there are standards that
are followed by majorities.
It is *not* followed by the majorities. Internet Explorer doesn't follow it!
IE claims to be Mozilla/4.0 and then adds a comment saying that it is really
(Compatible; MSIE 6,0;...).
Every time someone makes a page that restricts access to some
browsers, most likely including IE, a browser will change, or allow
the user to change, how it identifiers itself. It does that, not because
it doesn't care about the standard, but because it has to work in a world
where page authors force them to lie.
The status of things is that the navigator.userAgent string is no longer
a discriminating identifier of web browsers and, if it ever was, it
never will be again.
The point is that it should be.
The point is also that browser detection shouldn't be necessary.
But it isn't. Browsers should support standards, but the most widely
used browser doesn't understand proper CSS 2 and doesn't follow the W3C
DOM specifications.
On the other hand perhaps your faith that object/property testing
will remain a good way to test is overly inflated.
Care to explain why?
You are not supposed to fake user agent strings. Period.
You are not supposed to restrict access to a page based on the
browser. That is counter to the very basic concept of the web.
But they do, and browsers adapt.
It is sad that faking your user agent string is necessary, but
blame the page authors, not the browser vendors or users. They
started it.
This feature has only become available in various browsers and only
because it is very easily implementable.
And not because there was a need?
Do you really mean that?
* Should every browser preferably have a distinctive user agent string or
not? Don't read the RFC just use your common sense.
They should.
Do they? No.
Your code is meant to solve a real life problem: That browsers are different.
In an ideal world, your program is not necessary.
In the real world, it should consider the real life problem that the user
agent string can not be trusted in all cases.
I don't know the percentage of people faking their user agent string.
I do when I access MSDN, because otherwise they won't show me the
page. I am smart enough to handle it in Proximitron, so not all pages
are affected. Not everyone is.
I do know that your program would have problems with detecting Netscape 4,
since it identifies itself as Mozilla/4, and so does IE.
Your test relies on the comment part of the userAgent string to identify
IE, which is not following the standard anyway.
Built-in user-agent strings in the browsers you try to identify.
Opera:
Opera/7.20 (Windows NT 5.1; U) [en]
Mozilla/5.0 (Windows NT 5.1; U) Opera 7.20 [en]
Mozilla/4.78 (Windows NT 5.1; U) Opera 7.20 [en]
Mozilla/3.0 (Windows NT 5.1; U) Opera 7.20 [en]
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.20 [en]
Netscape 4.08:
Mozilla/4.08 [en] (WinNT; I ;Nav)
Mozilla Firebird 0.6
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Mozilla/4.8 [en] (Windows NT 5.0; U)
Opera/7.11 (Windows NT 5.1; U) [en]
Internet Explorer 6:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; MyIE2; .NET CLR 1.1.4322)
This doesn't count browsers on other platforms, still mostly Mac and
Unix, but increasingly also mobile devices.
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'
On Mon, 22 Sep 2003 13:14:45 +0100, Dr John Stockton
<sp**@merlyn.demon.co.uk> wrote: JRS: In article <3f*********************@news.gradwell.net>, seen in
news:comp.lang.javascript, Fotios <f_****@yahoo.com> posted at Mon, 22
Sep 2003 06:23:59 :-
I do not need to read the FAQ before or after I post.
It would, however, be a useful precaution against appearing to be a
person of inadequate sagacity. Of course, that appearance would in that
case not be misleading.
Touche, John.... Well, the scripts that I have posted are certainly multi-browser so what
you say here is obviously wrong.
Uhm, no. He said that it is multi-browser, but not cross-browser, so
you agree with him.
yup, I misread that part. I guess I do agree with him on this one.
It is *not* followed by the majorities. Internet Explorer doesn't follow
it!
IE claims to be Mozilla/4.0 and then adds a comment saying that it is
really (Compatible; MSIE 6,0;...).
The mozilla string is there because of known historical reasons. What you
should ask yourself is why the MSIE
part is there. Is it by chance?
Every time someone makes a page that restricts access to some
browsers, most likely including IE, a browser will change, or allow
the user to change, how it identifiers itself. It does that, not because
it doesn't care about the standard, but because it has to work in a world
where page authors force them to lie.
And has to do that because there are millions of scripts that are blocking
access to various browsers.
In your js circumscribed world you fail to see that as long as a browser
cannot claim to work in every aspect of its rendering and runtime behavior
exactly as a different one then it should not (and is not in its interest)
fake the string of the other browser or the results will be embarrasing.
Furthermore as long as two browsers fail to be identical in their behavior
the motivation for distinguishing between them is *very* real and with it
the motivation for writing discriminating browser detection scripts.
A couple of facts:
-----------------
* Faked strings by browsers (and not robots) are a *very* rare occurence
overall.
* When the ua string is faked the standard is not followed properly.
The point is also that browser detection shouldn't be necessary.
Yes, and also pain and poverty in this world.
But it isn't. Browsers should support standards, but the most widely
used browser doesn't understand proper CSS 2 and doesn't follow the W3C
DOM specifications.
So, you are a proponent of non-compliance with the standards then?
On the other hand perhaps your faith that object/property testing
will remain a good way to test is overly inflated.
Care to explain why?
I did explain at the very end of my previous message but you seem to have
skipped that part.
Let us know when you read it. Dying to hear your comments! :)
You are not supposed to fake user agent strings. Period.
You are not supposed to restrict access to a page based on the
browser. That is counter to the very basic concept of the web.
But they do, and browsers adapt.
Can you please quote an official standard that says that?
In my house I don't let in people who have stepped on dirt.
A site is somebody's house of sorts.
It is sad that faking your user agent string is necessary, but
blame the page authors, not the browser vendors or users. They
started it.
Ah, that reminds me of the days I was playing Hide n Seek.
Those were the days!
This feature has only become available in various browsers and only
because it is very easily implementable.
And not because there was a need?
Do you really mean that?
Sure there is a need. There is also a need behind cracking.
* Should every browser preferably have a distinctive user agent string
or not? Don't read the RFC just use your common sense.
They should.
Do they? No.
Your code is meant to solve a real life problem: That browsers are
different. In an ideal world, your program is not necessary.
In the real world, it should consider the real life problem that the user
agent string can not be trusted in all cases.
yes, but it works at a very high percentage of cases. No?
Isn't percentage of success the measure in Internet related systems?
Why would this be perfect? (although I certainly would like it to be).
As for the "real world" read the end of this message (don't skip it this
time)
I do know that your program would have problems with detecting Netscape
4, since it identifies itself as Mozilla/4 , and so does IE.
Sure. There are cases that this script will not work properly. The addition
of some feature based detection logic for discriminating between certain
browsers would help it. Maybe version 2. The raison d'etre of this script is
browser discrimination and the easy and quite efficient way to do that (with
a very high percentage of success) is the ua string. As for the reason for
discrimination I have briefly explained it above and will explain it more
below.
About the need to disciminate browsers
----------------------------------------
* This is a real need as long as various browsers do even one thing
differently. This thing does not necessarily have to do with how scripts
execute. It may have to do with how things render, what is supported and
what not and even various bugs.
* In this quest there are no perfect solutions but there are good solutions
and there are solutions that can become even better.
* It is better to deny services to a particular browser (and suggest a free
alternative instead) than have your site misrender embarrassingly on various
untested browsers.
I state again that the misrendering does not need to be related to
javascript issues.
* Most commercial sites currently have similar detection logic for either
excluding browsers or varying their services depending on the browser.
* I can see how circumscribing one's Internet experience to things that
revolve around a single technology (or a couple) can create confusion and
questions that tend to be metaphysical in nature.
F.
"Fotios" <f_****@yahoo.com> wrote in message
news:3f*********************@news.gradwell.net... You could try to explain why you "do not need to
read the FAQ".
Sure. For the same reason I do not need to read the
bible in order to be a good Christian.
Judging by your posts to microsoft.public.scripting.jscript under this
subject you are not a good Christian so perhaps you should RTFM.
I suppose one can find many similar ways to explain
what you asked.
And they could all be equally misguided.
I'll tell you the truth tho. I have read the FAQ about
2 years back. Since then so much has happened that I do
not even remember what was in there and what not.
So you read the explanation of the futility of browser detecting and the
recommendations of better alternatives and then went and spent the
intervening years writing scripts based on browser detecting?
<snip>Isn't it still a fact that most script that goes
around is not cross-browser?
Yes, it is also a fact that some scripts do not even
manage to be multi-browser (which is all that your scripting
actually aspires to be, judging by your other posts in this
thread).
Well, the scripts that I have posted are certainly
multi-browser so what you say here is obviously wrong.
You have suffered a deficit in English comprehension.
<snip>I have also heard that no scripter really knows what
he/she is doing. What do you think about that?
If you did hear that it will have been from the lips of
someone who did not know what they were doing and was
looking to justify their unwillingness to find out.
You sound hurt.
You think? I can see not reason for assuming that I would have any
emotional response to a hearsay report of an assertion by third party
who cannot be qualified to judge the validity of their own statement.
Why don't you tell us what else you do well except scripting
That would be irrelevant to a discussion of browser scripting and OP for
this newsgroup.
(if we assume that you even do that well).
Why make assumptions when you have access to information.
Maybe you can prove that you don't have any ego-related
reason in making this claim.
I can prove that as easily as you can prove that you heard the assertion
in the first place.
<snip>Have you ever wondered why the user agent string is there at all?
Why was it introduced and kept in countless versions and builds?
I haven’t had to wonder for as long as I have known. But before I knew I
don’t recall caring.
I quote from RFC 2616:
----
14.43 User-Agent
The User-Agent request-header field contains information about the
user agent originating the request. This is for statistical purposes,
the tracing of protocol violations, and automated recognition of user
agents for the sake of tailoring responses to avoid particular user
agent limitations. User agents SHOULD include this field with
requests. The field can contain multiple product tokens (section 3.8)
and comments identifying the agent and any subproducts which form a
significant part of the user agent. By convention, the product tokens
are listed in order of their significance for identifying the
application.
User-Agent = "User-Agent" ":" 1*( product | comment )
Example:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
----
After all the computer world only revolves because there are
standards that are followed by majorities.
RFC 2616 is the HTTP 1.1 standard. Can you point me to a standard that
says that the string used in the user agent header in HTTP 1.1 should be
made available to client-side scripting? No . . . perhaps some caution
should be exercised before citing standards as a justification for
client side browser detecting based on that string.
But standard hang heavily upon the words MUST (compulsory), SHOULD
(probably should be treated as compulsory) and MAY (clearly optional
(but possibly recommended)).
In the User Agent specification we find a SHOULD:-
<quote>
User agents SHOULD include this field with requests.
</quote>
And our browsers are complying by sending that header (100% to the
specification). As to the contents of that header we read:-
<quote>
The field can contain multiple product tokens (section 3.8) and comments
identifying the agent and any subproducts which form a significant part
of the user agent. By convention, ...
</quote>
- and the operative word is CAN, not MUST, not SHOULD, not even MAY but
CAN. Clearly the specification leaves the contents of the string up to
the implementer. That is not surprising because this was 1999 and IE was
already spoofing Netscape 4’s UA string so placing any strong
requirements on the content of the string would have been closing the
stable door after the horse has bolted.
So if a browser sends any user agent header it is conforming to the
letter of RFC 2616. The only way in which it can be considered as not
conforming to the standard that you cited is that it may not follow the
spirit of the standard. However, RFC 2616 starts:-
<quote>
The User-Agent request-header field contains information about the user
agent originating the request.
</quote>
-and our browser's User Agent headers are sending information about
themselves. It may not be very useful information, asserting little more
than that they consider themselves to be user agents, but that is still
information.
RFC 2616 then goes on:-
<quote>
This is for statistical purposes,
</quote>
Which is fine as the information can be used for statistical purposes.
You can use it to count the number of requests from software that
asserts its user agentness.
The spirit of:-
<quote>
the tracing of protocol violations,
</quote>
- can be conformed with by not making protocol violations (so there is
no need to trace them).
And it was the abuse of:-
<quote>
and automated recognition of user agents for the sake of tailoring
responses to avoid particular user agent limitations.
<quote>
- by not using the UA information to _avoid_ particular user agent
limitation, but rather to avoid dealing with those limitations by
blocking unrecognised and unwanted user agents, that caused the User
Agent string to become close to meaningless in the first place. But if
the browser manufacturers do not believe their browser to suffer from
limitations then there is no reason for them to need a response tailored
any differently to Some other browser’s.
But in all of this I do not see it stated that the User Agent header
MUST (even SHOULD) contain a discriminating identifier of the user agent
software. The closest RFC 2616 comes to that is to suggest that such an
identifier is an option.
The status of things is that the navigator.userAgent string is
no longer a discriminating identifier of web browsers and, if
it ever was, it never will be again.
The point is that it should be.
Says who? Apparently not RFC 2616.
On the other hand perhaps your faith that object/property
testing will remain a good way to test is overly inflated.
If it was a personal belief, unsupported by facts, at odds with expert
opinion and contrary to logic then I might question it. Fortunately that
is not the case.
Web browsers are user configurable software. ...
<snip>You are not supposed to fake user agent strings. Period.
Again, says who?
This feature has only become available in various browsers
and only because it is very easily implementable.
Ease of implementation is far from the reason (let alone the only
reason) that this has become available. It has happened because browser
detection based on user agent strings (even if all browsers did use a
discriminating string) requires so much data to implement effectively
that it never has been, and the consequences were that unrecognised
browsers were excluded from sites for no better reason than that they
could be discriminated from recognised browsers. And so the
manufacturers of the unrecognised browsers became motivated to make
their browsers indistinguishable from the recognised browsers so that
the misguided script authors had no way of excluding them.
It is browser detecting as a practice that is the problem. It doesn’t
matter how it is done, whatever method is used will result in that
method becoming ineffective. It is just the case that userAgent string
based browser detecting became ineffective long ago and the smart
scripters moved on to something better.
Of course your "browser detecting" followed by the assumption
that everything is then going to be the way that you are
expecting it is going to fall down with many non-default
configurations even on IE.
What percentage do you think? I say it works 99%.
Given that browser usage statistics are notoriously based on a faulty
premise and that a browser that sends a user agent string that is
indistinguishable from IE’s will be reported as IE making it impossible
to even guesstimate their usage I think that the question is futile. But
common reported statistics for browsers with JavaScript unavailable or
disabled seem to be in the 8-12% range so no script could "work" more
than 88-92% (if you define work as successfully execute). Disabling
JavaScript is just one of the many ways in which browsers can deviate
form their default settings (though some default to having JavaScript
disabled in the first place so enabling it is non-default), I would
imagine that almost everyone plays with their settings at some point
(even if they just screw something up and end up having to re-set the
defaults in the end).
<snip>(assuming of course that these browsers that are
indistinguishable from IE are actually minority
browsers. It is impossible to tell if they always
appear in the browser statistics as IE).
Heh, sorry but this reminds me of comical Ali.
You see a flaw in the logic?
1. Detecting a browser type is not necessarily for scripting
purposes. For instance, you may not like the way something
renders in gecko.
Rendering is presentation, so CSS. Use CSS solutions for
CSS problems, ...
Yeah but CSS does not always work the way one wants and the
detection is done in JS not CSS.
Go and ask in comp.infosystems.www.authoring.stylesheets and they will
tell you how to use CSS to fix rendering glitches in browsers. They will
also tell you (every last one of them) that you do not _ever_ use
JavaScript to fix CSS problems.
You are still thinking in terms of browser detecting. Feature
detecting is an integral part of scripting; there is no
distinct "detector" at all.
wow, that is tew kewl (and deep).
There is nothing like a well reasoned argument.
A few points to keep you busy:
* Should every browser preferably have a distinctive user agent
string or not? Don't read the RFC just use your common sense.
The RFC doesn’t say that they have to (only that they send the UA
header), and I can see not reason why they should as there is no need to
be interested in specific browser types anyway. I also can’t see any
reason for the UA string to be exposed to client side scripting for much
the same reason.
* You are trying to make a rule out of the exception (exception
being the faked strings)
I am trying to demonstrate that the proposition that it is possible to
use the navigator.userAgent string to uniquely identify web browsers is
false.
It is in the nature of logic that a billion instances of circumstances
corresponding with a proposition do not prove that proposition to be
true, yet just one instance (properly verified) of circumstances failing
to correspond with the proposition do _prove_ it to be false. And we do
not have just one instance where browser detection by userAgent string
will fail to identify a browser (or will misidentify it) we have many.
The proposition that it is possible to use the navigator.userAgent
string to uniquely identify web browsers _is_ false.
* I can write a user agent that fakes the existence of certain
JS objects but provides others while for the faked ones has
Shakespeare quotes as the return value of various methods. I
could name this product Fudgilla (create say 10 variants of it
under different names like Geekzilla), make it freely available
to the geek crowds and then argue that because these products
exist the feature detection method is no good anymore for deciding
what kind of browser we got.
<snip>
That would be your prerogative and feature detecting can cope with that.
It is exactly the sort of situation that it is expected to cope with
anyway. On discovering that your browser does not support the required
features it would cleanly degrade as designed. Your approach, on the
other hand, only offers the options of refusing the browser access (and
encouraging another round of UA string faking) or erroring until it made
a very ungraceful exit.
On the other hand, is it likely that a new browser would be introduced
that deliberately re-defined the DOM to the extent that you describe?
Reality seems to be moving towards standardising around the various W3C
DOM specifications rather than diverging from the existing browser DOM’
s. While we have already discussed why browser manufactures are well
motivated to fake userAgent strings and offer their users a selection of
easy alternative options.
Your scenario, if taken to an extreme, may eventually negatively impact
on feature detecting as a technique. (Though scripts that used the
technique would stand up longer and better than scripts that used your
browser detecting approach.) But it is an unlikely scenario.
My scenario, of browsers offering users choices of userAgent strings
that are indistinguishable from those of other common (usually IE)
browsers (or just using those strings by default) is already a
demonstrated reality.
Richard.
In article <bk**********@hercules.btinternet.com>, "Richard Cornford"
<ri*****@litotes.demon.co.uk> writes: Sure. For the same reason I do not need to read the
bible in order to be a good Christian.
Judging by your posts to microsoft.public.scripting.jscript under this
subject you are not a good Christian so perhaps you should RTFM.
His last post being the one to me that convinced me he was under the false
impression he possesses some intelligence.
My hats off to you Richard, you have argued your point (successfully) with the
moron way longer than I ever would have.
--
Randy
Hey Randy, does you momma know you still up?
His last post being the one to me that convinced me he was under the false
impression he possesses some intelligence.
Randy, tell us (please?) what is wrong with this: "...being the one to me
that convinced me...".
You don't even listen to your teacher you naughty boy you.
My hats off to you Richard, you have argued your point (successfully) with
the moron way longer than I ever would have.
Hey Randy, how many hats do you wear at once? Itz kewl. I did it too (when I
was 14)
F.
In article <3f*********************@news.gradwell.net>, "Fotios"
<f_****@yahoo.com> writes:
His last post being the one to me that convinced me he was under the false
impression he possesses some intelligence.
Randy, tell us (please?) what is wrong with this: "...being the one to me
that convinced me...".
You don't even listen to your teacher you naughty boy you.
Let me explain it in a way that you might understand it. The last post you made
in the microsoft.public.script.jscript group with regards to this assinine
belief of yours is the post that convinced me that you are under the false
impression that you possess some intelligence.
But, if browser detection is the way to go, as you claim, could you _please_
show me how to do this simpler? Using Browser Detection:
if (document.images){
//lets work with images
}
Your move stupid.
--
Randy hi************@aol.com (HikksNotAtHome) writes: But, if browser detection is the way to go, as you claim, could you _please_
show me how to do this simpler? Using Browser Detection:
if (document.images){
//lets work with images
}
I would say "let's work with document.images". I often see people writing
if (document.images) {
var img1 = new Image();
img1.src = "foo.png";
...
}
Statistically, it appears that there is a strong correlation between
document.images and window.Image (both introduced in Netscape 3 and
both exists in all later browsers), but it is not object detection.
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'
In article <pt**********@hotpop.com>, Lasse Reichstein Nielsen <lr*@hotpop.com>
writes: I would say "let's work with document.images". I often see people writing
if (document.images) {
var img1 = new Image();
img1.src = "foo.png";
...
}
Statistically, it appears that there is a strong correlation between
document.images and window.Image (both introduced in Netscape 3 and
both exists in all later browsers), but it is not object detection.
Its not browser detection either though. But another example can be:
if (document.getElementById){
//lets use document.getElementById
}
Not wanting to get into the testing argument again, but neither of these is
browser detection, nor do I need to know the browser. Its irrelevant, no?
--
Randy hi************@aol.com (HikksNotAtHome) writes: In article <pt**********@hotpop.com>, Lasse Reichstein Nielsen <lr*@hotpop.com>
writes:Statistically, it appears that there is a strong correlation between
document.images and window.Image (both introduced in Netscape 3 and
both exists in all later browsers), but it is not object detection.
Its not browser detection either though.
No, it is ... "object inferenece"? It is similar to testing for
document.all and assuming the browser works like IE, only with a much
higher positive rate :)
But another example can be:
if (document.getElementById){
//lets use document.getElementById
}
Yes, that is a good one. Your example could very well be one too, if
you only used document.images in the body of the test. I was just
griping about having seen a lot of "if (document.images) {new Image...}"
recently.
Not wanting to get into the testing argument again, but neither of these is
browser detection, nor do I need to know the browser. Its irrelevant, no?
Absolutely. I advocate object detection too, but all object detection will
eventually assume something about the detected objects. Finding a property
called "getElementById", or even a function by that name, doesn't tell us
what it does. We have to assume that the browser manufacturer isn't being
stupid or deliberatly malicious. But I prefer trusting the behavior of a
feature to trusting its existence.
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'
Haven't you yet learned the futility of trying to have a debate with the
mentally challenged? :p
Don't have a battle of wits with an unarmed opponent. It isn't nice.
Or are you just playing with him because you're bored? *LOL*
heehee! Kaeli, you are such a cutie! *LOL* ooooxxxx
New agey love,
F.
-- http://fotios.cc/
Richard,
I have read your lengthy reply. Many thanks.
I don't believe that continuing this thread has anything more to offer to
the group or us.
It is obvious we disagree but I sure can live with that.
My views on the subject have basically been expressed to a good extend in my
last two lengthy posts.
I want to believe that everybody's (whether reader or poster) grasp of the
involved issues has been either improved or refreshed.
At the very least, we got the fairly new idea of deceiving objects to show
for.
Who knows? Maybe Fudgilla will become a reality at some point just to show
that there are no certainties except temporary ones.
I promise you; it will not be me who puts it together :)
Best regards,
Fotios
-- http://fotios.cc/
"Richard Cornford" <ri*****@litotes.demon.co.uk> wrote in message
news:bk**********@hercules.btinternet.com... "Fotios" <f_****@yahoo.com> wrote in message
news:3f*********************@news.gradwell.net...You could try to explain why you "do not need to
read the FAQ".
Sure. For the same reason I do not need to read the
bible in order to be a good Christian.
Judging by your posts to microsoft.public.scripting.jscript under this
subject you are not a good Christian so perhaps you should RTFM.
....
<snip>
"HikksNotAtHome" <hi************@aol.com> wrote in message
news:20***************************@mb-m04.aol.com... Sure. For the same reason I do not need to read the
bible in order to be a good Christian.
Judging by your posts to microsoft.public.scripting.jscript under
this subject you are not a good Christian so perhaps you should RTFM.
His last post being the one to me that convinced me he was under
the false impression he possesses some intelligence.
Yes, that is exactly the post that I had in mind. Resorting to
unsubstantiated sarcastic abuse did not strike me as consistent with the
teachings of Christ as reported in the Bible (not that I have any
expertise, being an atheist, but I am not unfamiliar with scripture),
nor as the resort of someone who believes they have a valid rational for
their position.
My hats off to you Richard, you have argued your point
(successfully) with the moron way longer than I ever would have.
Well, it is not as if it was ever possible to fail when arguing against
userAgent string based browser detection (as Steve pointed out a couple
of days ago). Not that I was expecting to convince him. To be convinced
by reasoned argument you have to be rational (and possibly intelligent)
to start with (and the ability to accurately comprehend written English
would also have been useful in this context).
My main motivation is to provide a service to those who may in future,
believing that they need to detect browsers, search c.l.j. on google and
find their keywords directing them to this thread. I would not want them
to go away the impression that browser detecting by userAgent string was
a good idea, possible, acceptable ,actually necessary or in any way
endorsed by this group, and to give some alternative keywords to search
on. There is no need to let people who are new to the subject repeat the
mistakes of the past.
I suspect you had a similar intention when responding to him on
microsoft.public.scripting.jscript.
Richard.
"Fotios" <f_****@yahoo.com> wrote in message
news:3f*********************@news.gradwell.net...
<snip> I don't believe that continuing this thread has anything more
to offer to the group or us.
So a thread in which you have challenged people to reply to your points
at least twice comes to an end when you find yourself unable to respond
to mine. That suites me, and I would agree that the subject has been
satisfactorily addressed.
<snip>My views on the subject have basically been expressed to a good
extend in my last two lengthy posts.
Yes they have, and my last two lengthy posts have addressed them all.
I want to believe that everybody's (whether reader or poster)
grasp of the involved issues has been either improved or refreshed.
Maybe some readers, I don't think that any of the other posters in this
thread have seen anything that they were not already familiar with.
At the very least, we got the fairly new idea of deceiving
objects to show for.
Fairly new idea? That concept was in the FAQ when you supposedly read it
two years ago. c.l.j. has been discussing and refining the techniques of
feature/object detecting on a regular basis for as long as I have been
reading it. That is why we are all so confident that it is the _only_
viably approach to Internet browser scripting. (Though individual
opinions on how the technique is best applied still varies, but that is
what would be expected when individuals address complex problems.)
Who knows? Maybe Fudgilla will become a reality at some point
just to show that there are no certainties except temporary ones.
I promise you; it will not be me who puts it together :)
And I promise you that if you don't write it nobody else is going to.
What could possibly motivate anyone else to put their effort into
writing a browser with a deliberately broken DOM? That is the sort of
thing that people only do by accident. If they wanted a browser that
predictably would not execute any existing JavaScript they could just
strip scripting support from the browser entirely, and if they wanted a
browser that would only execute their own scripts it would be easier to
swap the scripting language from JavaScript to some other.
Richard.
Richard,
I will not deal with the rest of the stuff that you mention (to which I
disagree) or the fact that you seem to have somehow gotten emotionally
involved (sorry if I caused this).
I will not even try to get into a theological discussion with you (which I
don't see how it is not OT - you being so sensitive about OT stuff).
I will even hold my ironic remarks to your admission that you are an atheist
(I don't want you to have a stroke or anything).
However, I will respond to the following just to demonstrate to you how
intensive FAQ reading and adherence (and other dogmatisms) can impair
imagination.
And I promise you that if you don't write it nobody else is going to.
What could possibly motivate anyone else to put their effort into
writing a browser with a deliberately broken DOM? That is the sort of
thing that people only do by accident.
Imagine this dear Richard: Let's say I am an open source proponent who is
sick and tired of Microsoft's marketing tricks and the way they undermine
public standards. So, I build this excellent open source browser which
supports all W3C DOM objects (in a very proper way) but I also choose to
attack Microsoft in my own way by faking the proprietary Microsoft objects
or methods/properties; that is they exist but they give erroneous values
(like: "Billy is a custard face" instead of some other string that is
expected). Why would I do that? But because this way I would break scripts
that try to support these objects. This would be an angry open sourcer's way
of fighting back and saying out loud "Scripters! Do not script for
Microsoft's proprietary objects/methods/properties that antagonize and
undermine W3C standards". Extreme in a way but I think conceivable - in my
opinion, not more extreme that having Shakespeare quotes as your agent
string.
F.
On Thu, 25 Sep 2003 10:42:11 +0100, "Fotios" <f_****@yahoo.com> wrote: I also choose to
attack Microsoft in my own way by faking the proprietary Microsoft objects
or methods/properties; that is they exist but they give erroneous values
(like: "Billy is a custard face" instead of some other string that is
expected).
Well the script will almost certainly reject your browser when it
checks for the document object, which doesn't exist in the W3 DOM.
However the object detection technique, will have no problem with
this, consider document.all.chicken returning your string instead of
an object, that will fail when you check the chicken object is what
you expect, or that the chicken.style is indeed an object, your
intentional spoofing only works if you don't spoof objects, but make
them do intentionally wrong things (e.g. have a style visibility
change the colour instead or something) So you'd have to deliberately
break the objects behaviour not just have them return a string.
However, all of it's academic, as you've implemented the W3 DOM, and
clj has always advocated checking and using that first, so our scripts
won't see your mess, just old ones...
Do not script for
Microsoft's proprietary objects/methods/properties that antagonize and
undermine W3C standards".
Except of course that doesn't work, because the W3 simply hasn't
standardised huge gaping holes which are requied to do any scripting,
de facto standards are required.
Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/
In article <3f*********************@news.gradwell.net>, f_****@yahoo.com
enlightened us with...
Haven't you yet learned the futility of trying to have a debate with the
mentally challenged? :p
Don't have a battle of wits with an unarmed opponent. It isn't nice.
Or are you just playing with him because you're bored? *LOL*
heehee! Kaeli, you are such a cutie! *LOL* ooooxxxx
New agey love,
F.
--
*snicker*
smooches!
-------------------------------------------------
~kaeli~
All I ask for is the chance to prove that money
cannot make me happy. http://www.ipwebdesign.net/wildAtHeart http://www.ipwebdesign.net/kaelisSpace
-------------------------------------------------
On Thu, 25 Sep 2003 04:29:45 +0100
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote:
<snip> I would not want them
to go away the impression that browser detecting by userAgent string
was a good idea, possible, acceptable ,actually necessary or in any
way endorsed by this group, and to give some alternative keywords to
search on. There is no need to let people who are new to the subject
repeat the mistakes of the past.
I note the use of the phrase: "actually necessary." Is there some
concensus, even among a few, that browser detection, of any kind, is not
necessary or desirable? I am new to JavaScript and am just curious. At
this point I have doing HTML strict 4.01 on Opera 7.11, with no concern
for cross-browser compatibility.
--
Don't you see that the whole aim of Newspeak is to narrow the range of
thought? In the end we shall make thoughtcrime literally impossible,
because there will be no words in which to express it.
-- George Orwell, 1984
Jim,
you seem to have comprehension problems.
F.
"Jim Ley" <ji*@jibbering.com> wrote in message
news:3f****************@news.cis.dfn.de... On Thu, 25 Sep 2003 10:42:11 +0100, "Fotios" <f_****@yahoo.com> wrote:
I also choose to
attack Microsoft in my own way by faking the proprietary Microsoft
objectsor methods/properties; that is they exist but they give erroneous values
(like: "Billy is a custard face" instead of some other string that is
expected).
Well the script will almost certainly reject your browser when it
checks for the document object, which doesn't exist in the W3 DOM.
However the object detection technique, will have no problem with
this, consider document.all.chicken returning your string instead of
an object, that will fail when you check the chicken object is what
you expect, or that the chicken.style is indeed an object, your
intentional spoofing only works if you don't spoof objects, but make
them do intentionally wrong things (e.g. have a style visibility
change the colour instead or something) So you'd have to deliberately
break the objects behaviour not just have them return a string.
However, all of it's academic, as you've implemented the W3 DOM, and
clj has always advocated checking and using that first, so our scripts
won't see your mess, just old ones...
Do not script for
Microsoft's proprietary objects/methods/properties that antagonize and
undermine W3C standards".
Except of course that doesn't work, because the W3 simply hasn't
standardised huge gaping holes which are requied to do any scripting,
de facto standards are required.
Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/
"Fotios" <f_****@yahoo.com> wrote in message
news:3f*********************@news.gradwell.net... I will not deal with the rest of the stuff that you mention
(to which I disagree) or the fact that you seem to have
somehow gotten emotionally involved (sorry if I caused this).
Given your demonstrated shortcomings in extracting literal meaning from
written English I think you would be best advised to concentrate on that
and abandon efforts to interpret emotional overtones until you have that
under your belt. As I recall my emotional response to your last post was
nothing more than slight amusment (at the fact that Steve's predicted
outcome had come to pass).
I will not even try to get into a theological discussion
with you (which I don't see how it is not OT - you being
so sensitive about OT stuff).
It would be OT, but should you consider yourself properly equipped for a
theological discussion if you have not read the Bible?
I will even hold my ironic remarks to your admission that you
are an atheist (I don't want you to have a stroke or anything).
I see no irony (or anything unusual) in an atheist being able to
recognise hypocrisy.
<snip>Imagine this dear Richard: Let's say I am an open source
proponent who is sick and tired of Microsoft's marketing
tricks and the way they undermine public standards. So,
I build this excellent open source browser which supports
all W3C DOM objects (in a very proper way) but I also
choose to attack Microsoft in my own way by faking the
proprietary Microsoft objects or methods/properties; that
is they exist but they give erroneous values (like: "Billy
is a custard face" instead of some other string that is
expected). Why would I do that? But because this way I
would break scripts that try to support these objects.
This would be an angry open sourcer's way of fighting
back and saying out loud "Scripters! Do not script for
Microsoft's proprietary objects/methods/properties that
antagonize and undermine W3C standards". Extreme in a way
but I think conceivable - in my opinion, not more extreme
that having Shakespeare quotes as your agent string.
Mozilla already says "Scripters! Do not script for Microsoft's
proprietary DOM" by the simple measure of not implementing very much of
it (though you might break innerHTML just to be comprehensive).
The browser you are describing is not significantly different from the
W3C DOM compliant browsers that fake objects from the Microsoft DOM in
order to avoid being ostracised by scripts that attempt browser
detection by object inference. And feature detecting as a technique
already copes quite happily with those browsers. To the best of my
recollection, as you describe it this browser is going to happily
execute _every_ feature detecting script I have ever written because I
have always favoured using W3C DOM methods over proprietary ones, only
falling back to a proprietary methods if a W3C DOM approach is not
available/functional on the browser.
To significantly impact on the effectiveness of feature detecting as a
technique you would have to pervert the _entire_ browser DOM well beyond
the point at which no existing browser detecting based script could work
on it either. And even then the chances are still good that a feature
detecting script would recognise its inability to execute and be in a
position to degrade cleanly under control, while the browser detection
based scripts (assuming that they were allowed the opportunity to run on
this unrecognised browser) would just error until they failed entirely.
The result would be a browser that could _only_ execute scripts that
were specifically written for its perverse DOM. If making scripting the
browser require specialist knowledge was the goal of the browser authors
then it would be easiest achieved by just switching to a non-standard
scripting language, and if the goal was a browser that would not
successfully execute anyone's scripts then that would be easiest
achieved by just stripping scripting out entirely.
That leaves you as the only person motivated to go down the totally
perverse DOM route. And yes it may demonstrate that feature detecting
scripts cannot cope 100% with anything at all. On the way you have also
killed off all browser detecting scripts, so all that such a browser
would server to demonstrate is that while feature detecting cannot be
100% it is still significantly more robust than browser detecting. I
don't see that as contributing in any way towards an argument in favour
of browser detecting, quite the reverse.
Richard.
"Albert Wagner" <al******@tcac.net> wrote in message
news:20030925075408.72410c05.al******@tcac.net...
<snip> I note the use of the phrase: "actually necessary." Is
there some concensus, even among a few, that browser
detection, of any kind, is not necessary or desirable?
There is complete consensus that browser detecting based on the
navigator.userAgent string cannot uniquely identify individual web
browsers, that is just a truth. There may be approaches based on object
inference that can uniquely identify some (but not all) browsers, but it
would be necessary to have complete details of _all_ browser DOMs in
order to have any confidence in the results, and that is impractical.
The individuals with the widest familiarity with browser DOMs freely
admit that even they do not know enough to implement a truly
discriminating object inference based browser detecting script. And even
if it was done such a script would need to be updated whenever a new
browser was released (world wide).
So if there are circumstances under which it is *necessary* to uniquely
identify a web browsers then the impossibility of doing that becomes an
insurmountable problem.
People do occasionally propose circumstances under which they believe
that they need to identify browsers but these usually turn out to arise
due to a lack of understanding of HTML or CSS and when they are genially
JavaScript problems there is often either an alternative approach that
circumvents the problem or and examination of the logic of the problem
indicates a specific test that will discriminate browsers that have the
problem from those that don't without the need to know which browsers
those are. And, of course, there are a few things that just cannot be
done (or tested) with sufficient reliability to be appropriately used
outside of an Intranet.
There is a very wide consensus (at least among those knowledgeable about
browser scripting) that testing the features specifically required by a
particular script is the only viable technique for cross-browser
scripting, thus side-stepping the fact that browsers cannot be uniquely
identified by never asking that question.
You can judge the support for browser detection by the total number of
people contributing to this thread in support of that approach.
I am new to JavaScript and am just curious. At this
point I have doing HTML strict 4.01 on Opera 7.11, with
no concern for cross-browser compatibility.
Client-side Internet JavaScript is probably unique in computer
programming terms in that it has to be authored with zero certainty
about the environment in which it will be executing. To be effective its
authors have to embrace that fact and adopt a different attitude towards
achieving their goals. But without that challenge cross-browser
scripting would be no more interesting than working with many other
programming languages. I would always recommend aspiring to author
cross-browsers scripts. After all a cross-browser scripter can author
for any specific browsers, the reverse is not true.
Richard.
Richard,
your lengthy mantras serve to prove my point perfectly. On the other hand
your attempt to prove that my point is of no real significance is pathetic.
Anyone who can think straight can see how a browser like the one I have
described would make the detection style you are a proponent of a big
problem in many cases. Perhaps I should I write an FAQ for you in order to
understand.
F.
"Fotios" <f_****@yahoo.com> writes: Anyone who can think straight can see how a browser like the one I have
described would make the detection style you are a proponent of a big
problem in many cases.
A browser that implements W3C DOM perfectly[1], but which maliciously
distorts proprietary IE features, will work perfectly with object
detection ... because you should always test for W3C DOM first.
/L
[1] Including widely accepted non-W3C objects that are not originated
at Microsoft, e.g., the global "document" and "window" variables.
--
Lasse Reichstein Nielsen - lr*@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'
A browser that implements W3C DOM perfectly[1], but which maliciously
distorts proprietary IE features, will work perfectly with object
detection ... because you should always test for W3C DOM first.
Lasse,
Have you noticed how you are suddenly on a "should" basis?
F.
On Thu, 25 Sep 2003 23:25:17 +0100, "Fotios" <f_****@yahoo.com> wrote: A browser that implements W3C DOM perfectly[1], but which maliciously
distorts proprietary IE features, will work perfectly with object
detection ... because you should always test for W3C DOM first.
Have you noticed how you are suddenly on a "should" basis?
Well you're the perfect example of how people don't understand object
detection... what other word than SHOULD do you think Lasse should be
using? it can't be MUST, we have no control over people, so what
exactly do you suggest?
Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/ Well you're the perfect example of how people don't understand object
detection... what other word than SHOULD do you think Lasse should be
using? it can't be MUST, we have no control over people, so what
exactly do you suggest?
No, it should be SHOULD which is exactly my point. To make it more explicit
for you, gone is the certainty that object and property checking just works.
BTW, the first Fudgilla Service Pack was released. Fudgilla will now check
for instances of proprietary Microsoft objects/properties anywhere in the
script and if it finds even one it will mess up the script anyway.
F.
On Thu, 25 Sep 2003 23:48:01 +0100, "Fotios" <f_****@yahoo.com> wrote:
Well you're the perfect example of how people don't understand object
detection... what other word than SHOULD do you think Lasse should be
using? it can't be MUST, we have no control over people, so what
exactly do you suggest?
No, it should be SHOULD which is exactly my point. To make it more explicit
for you, gone is the certainty that object and property checking just works.
Of course it does work if it's written correctly, however your user
agent sniffing cannot be written correctly in such manner that works
with even known browsers, you're relying on some very weird
hypothetical browser that does not exist - making it with IE would be
pretty easy.
BTW, the first Fudgilla Service Pack was released. Fudgilla will now check
for instances of proprietary Microsoft objects/properties anywhere in the
script and if it finds even one it will mess up the script anyway.
So it will "mess up the script" across the proprietary Microsoft
object like "document" then? and pray tell me how this is done, the
code analysis methods would be really useful to me for other things,
any language is good.
Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/
Jim,
So it will "mess up the script" across the proprietary Microsoft
object like "document" then? and pray tell me how this is done, the
code analysis methods would be really useful to me for other things,
any language is good.
"mess up the script across the object" ?!
"code analysis methods" when all that would be needed is simple substring
detection?
GeeWiz bro; go read an FAQ or sometin.
F.
This thread grows tiresome.
"Fotios" <f_****@yahoo.com> wrote in message
news:3f*********************@news.gradwell.net...
<snip> "code analysis methods" when all that would be needed is
simple substring detection?
And now a browser that supposedly was created to promote web standards
is in breach of ECMA 262.
Richard.
On Fri, 26 Sep 2003 00:12:17 +0100, "Fotios" <f_****@yahoo.com> wrote: "code analysis methods" when all that would be needed is simple substring
detection?
no, that doesn't work...
all='getElementById'
document[all]()
or even just
document.fred
that uses IE proprietary, yet ain't gonna be found by simple substring
detection.
Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/
Jim,
it is obvious that it does not have to be a "catch all" right away.
Can't you see that you cannot win this argument as long as I control
Fudgilla?
F. "code analysis methods" when all that would be needed is simple substring
detection?
no, that doesn't work...
all='getElementById'
document[all]()
or even just
document.fred
that uses IE proprietary, yet ain't gonna be found by simple substring
detection.
Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Raventhorn |
last post by:
I am having problems that I also saw people having in the ASP.NET forums with
menus and people coming to a site with weird user agent values. Is there a
way to access the user agent before the user...
|
by: RobG |
last post by:
Seems developers of mobile applications are pretty much devoted to UA
sniffing:
<URL: http://wurfl.sourceforge.net/vodafonerant/index.htm >
--
Rob
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |
