FAQ Topic - How do I detect Opera/Netscape/IE?

[FAQ server]

-----------------------------------------------------------------------
FAQ Topic - How do I detect Opera/Netscape/IE?
-----------------------------------------------------------------------

The `` navigator '' object contains strings which
specify the browser and version; however, this is in general not
very genuine. Mozilla (and therefore Netscape 6+) allows this to
be freely set, and Opera and IE allow it to be modified. There
are also at least 25 other javascript capable browsers with
their own strings here.

Generally though, you don't need to identify which browser is
being used. There are alternative techniques, but which one you
choose depends on why you want to redirect browsers. If it's to
offer different CSS stylesheets, then

http://w3development.de/css/hide_css_from_browsers/

shows many techniques. For Scripting, _object_ detection
is a better method to use.

http://www.quirksmode.org/js/support.html

It is also known as feature detection.

Object/feature detection means checking that the object you wish
to use is supported by the browser before using it. This means
that you don't need to know what browsers support what methods,
and your code will automatically be usable on any browser that
can execute it.

if (document.getElementById &&
document.getElementById('el') &&
document.getElementById('el').style ) {
// We know that this browser supports getElementByID and has
// a style object, so we can set a style property.
document.getElementById('el').style.color="red";
}

Browser bugs can often be detected and overcome in similar ways.

http://www.jibbering.com/faq/faq_notes/not_browser_detect.html

http://developer.apple.com/internet/webcontent/objectdetection.html


===
Postings such as this are automatically sent once a day. Their
goal is to answer repeated questions, and to offer the content to
the community for continuous evaluation/improvement. The complete
comp.lang.javascript FAQ is at http://www.jibbering.com/faq/.
The FAQ workers are a group of volunteers.

 

[Randy Webb]

FAQ server said the following on 9/7/2006 7:00 PM:<snip>

That needs to be modified so that it uses the same quoting on both
sides. The FAQ itself does not have that issue.

 

[Bart Van der Donck]

FAQ server said the following on 9/7/2006 7:00 PM:

That needs to be modified so that it uses the same quoting on both
sides. The FAQ itself does not have that issue.

Okay, <icode> is now regexed to '' , so `` navigator '' would become
'' navigator '' . Here is the complete current list:

"p" => "\n",
"/p" => "\n",
"em" => "_",
"/em" => "_",
"url" => "\n\n",
"/url" => "\n\n",
"ul" => "\n",
"/ul" => "\n",
"li" => "* ",
"/li" => "",
"moreinfo" => "\n\n",
"/moreinfo" => "\n\n",
"resource" => "\n\n",
"/resource" => "\n\n",
"icode" => "'' ",
"/icode" => " ''",
"code" => "\n\n",
"/code" => "\n\n",

Other tags than the above and besides <CONTENTS>, <CONTENT>, <FAQ>,
<TITLE> are regexed to empty string.

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated Thu,
7 Sep 2006 23:00:01 remote, seen in FAQ

FAQ Topic - How do I detect Opera/Netscape/IE?

Object/feature detection means checking that the object you wish
to use is supported by the browser before using it.

That's Object detection. Feature detection should be used for detecting
what the Object, method, or other entity actually does. An example
might be using new Date("01/02/03") and seeing what day, month,
year, and century it gives. Or checking to see whether /a??/ is an
acceptable RegExp.



Sep 2006 22:13:13 remote, seen in Randy Webb

<snip>

That needs to be modified so that it uses the same quoting on both
sides.

Not necessarily. If the characters are generally available, and
correctly reproduced in all likely fonts, then « and » (squashed << andliterate) to be quotes yet not in use in English or ECMAScript.

Perhaps ECMAscript or ECMAScript should be the generic term in the FAQ.

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated
Thu, 7 Sep 2006 22:13:13 remote, seen in

<snip>

That needs to be modified so that it uses the same quoting on both
sides.

Not necessarily. If the characters are generally available, and
correctly reproduced in all likely fonts, then « and » would be a good
choice, since they are characters well-known (to the literate) to be
quotes yet not in use in English or ECMAScript. There may be other
possibilities.

Perhaps ECMAscript or ECMAScript should be the generic term in the FAQ.

 

[Richard Cornford]

FAQ server posted :


That's Object detection. Feature detection should be used
for detecting what the Object, method, or other entity
actually does.

<snip>

Isn't the object (if present) a feature of the browser's object model? I
have always promoted "feature detection" over "object detection" as the
term for the type of testing required because it encompassed the
detection of the existence of objects/properties and their behaviour.

(That and because "object detection" is often used to label the
object-inference type testing that is used for 'browser detecting' (and
the basis of other irrational assumptions) and so can be easily be
misinterpreted. The term "feature detection" has also been applied to
object inference, but that is significantly less common than using
"object detection".)

Richard.

 

[Bart Van der Donck]

JRS: In article <[email protected]>, dated
Thu, 7 Sep 2006 22:13:13 remote, seen in

Not necessarily. If the characters are generally available, and
correctly reproduced in all likely fonts, then « and » would be a good
choice, since they are characters well-known (to the literate) to be
quotes yet not in use in English or ECMAScript.

I think that's a good idea and I adapted the programme as such. « and
» are also less likely to occur inside javascript code compared to
single quotes, thus improving readability and unambiguity.

While non-ASCII, « and » should not cause problems:

- They're part of ISO-8859-1 (Latin-1, from 1987), which is the
character set in which the daily Usenet message is sent;
- ISO-8859-1 is the 'default' character set on the internet since the
IANA registered it as such in 1992. It's since then the standardized
default encoding of documents delivered via HTTP with a MIME type
beginning with "text/";
- It's pretty safe to state that a news reader that can't handle
ISO-8859-1 is no good;
- ISO-8859-1 is the basic 'pure' Latin charset after ASCII (there are
many OS/vendor variants on it though)
- Using «» this way is exactly just as "dangerous" as using é or §
or à.

There may be other possibilities.

Not that much, I'm afraid (unless you take extra "risks" of course):

http://www.htmlhelp.com/reference/charset/latin1.gif
http://www.htmlhelp.com/reference/charset/

 

[John G Harris]

Perhaps ECMAscript or ECMAScript should be the generic term in the FAQ.

ECMAScript (capital S says ECMA) is only the core language. It doesn't
include i/o facilities such as Alert and file access.

The advantage of "javascript" is that the lack of capital letters
suggests that it's not restricted to the products of one company or
organisation.

John

 

[Bart Van der Donck]

While non-ASCII, « and » should not cause problems
[...]

Actually they did, but on a different level than I expected. Last night
at 00:00 WET the bot said:

"Error: XML file not well-formed after Usenet format regexes."

Obviously, the problem was at « and ». It appears that 127-255
characters result in invalid XML if the charset isn't specified. This
XML is okay:

<foo>bar</foo>

While this throws an error because of the "invalid character" (read:
non-ASCII):

<foo>bar « more bar</foo>

I've found a workaround so that this error is now solved. I just made
bot post today's message by hand (so today's delay was 9h15 min).

My tests show that this problem would not have occurred if the first
line of http://www.jibbering.com/faq/index.xml would have been in a
standard <?xml...?> format. This is valid XML:

<?xml version="1.0" encoding="ISO-8859-1"?>
<foo>bar « more bar</foo>

I kindly request the FAQ maintainer to add

<?xml version="1.0" encoding="ISO-8859-1"?>

as initial line of http://www.jibbering.com/faq/index.xml.

Thanks,

 

[Richard Cornford]

Bart Van der Donck wrote:

I kindly request the FAQ maintainer to add

<?xml version="1.0" encoding="ISO-8859-1"?>

<snip>

What is wrong with the UTF-8 default for XML?

Richard.

 

[Bart Van der Donck]

What is wrong with the UTF-8 default for XML?

It's not a good idea to rely on UTF-8 towards Usenet. It might be a
choice, yes, and I have considered it in the code design. But it will
cause problems in many news readers; even on Google Groups, as shown
in:

http://groups.google.com/group/comp.lang.javascript/msg/ad5cb8686dd1bc2a
http://groups.google.com/group/comp.lang.javascript/msg/63c89138f128ae84

And even Google (of whom one would expect to be the nr 1
Unicode-compliant website) prefers non-Unicode sets when e.g. sending
Chinese characters:

http://groups.google.com/group/comp.lang.javascript/msg/28ffbfeb05c8da4d

I preferred maximum compatibility rather than UTF-8 compliance. Note
that http://www.jibbering.com/faq/index.xml contains ASCII only (it's
in English + javascript syntax consists of ASCII chars only). If any
char >127 would have been used in the FAQ, the XML would become
invalid, even with

<?xml version="1.0" encoding="UTF-8"?>

So I'm quite convinced that ISO-8859-1 is the best choice here. It's
compatible with every reader and nationality, and it offers more than
enough room for the characters that are in the FAQ.

P.S. I see you don't specify any character set in your own message
header; so you actually leave the choice to the reader. Which is okay
as long as you don't do anything exotic. But e.g. Russians will see
your 'é' (é) as 'И' (И) by default, because Latin-1 ties
E9 to 'é' and KOI8-R to 'И'.

 

[Bart Van der Donck]

[...]
And even Google (of whom one would expect to be the nr 1
Unicode-compliant website) prefers non-Unicode sets when e.g. sending
Chinese characters

Google Groups only switches to UTF-8 when necessary, as eg. in my
previous post in order to display Russian signs. Or, as in the Chinese
post, it turns to charset "gb2312", which is apparently a Chinese
character matrix.

Google Groups defaults to ISO-8859-1 if the offered characters can be
represented in it (which is mostly the case with Western posts), and
which is, IMHO, a good policy.

 

[Richard Cornford]

It's not a good idea to rely on UTF-8 towards Usenet.

<snip>

The XML files is a data file, it is not "towards Usenet".

Richard.

 

[Martin Honnen]

Bart Van der Donck wrote:

Obviously, the problem was at « and ». It appears that 127-255
characters result in invalid XML if the charset isn't specified.

Where do you get that idea from?

First of all, the right term is well-formed or not well-formed and not
valid or invalid as the latter with XML do only apply to validation
against a DTD or schema.
And of course you can use « and » in an XML document, these characters
do not break well-formedness. Encoding characters properly matters, but
that is not specific to these two characters or Unicode characters in a
specific range.

My tests show that this problem would not have occurred if the first
line of http://www.jibbering.com/faq/index.xml would have been in a
standard <?xml...?> format. This is valid XML:

<?xml version="1.0" encoding="ISO-8859-1"?>
<foo>bar « more bar</foo>

Well this document is well-formed XML
<http://home.arcor.de/martin.honnen/xml/test2006091001.xml>
and it does not have an XML declaration.
If you use UTF-8 as the encoding (like that document does) then the XML
declaration is optional. And any XML parser should be able to deal with
the document.

<http://www.jibbering.com/faq/index.xml> is well-formed as well. And it
does not contain « at all. Thus if you have parsing problems then I
don't think they result from <http://www.jibbering.com/faq/index.xml>
not being well-formed XML.

 

[VK]

Where do you get that idea from?

From the practical experience I guess. ;-)

There is a number of problem connected with the typography quotes
("curly quotes") on the Web. The original "hit" can be viewed at
<http://groups.google.com/group/comp..._frm/thread/ab614b71f413220e/0e05d1e7a5b33dda>


This later resulted in off-clj experience exchange and finally in a
very informative section in the wiki-article:
<http://en.wikipedia.org/wiki/Quotation_mark> (search for "curly
quotes", "XML")

First of all, the right term is well-formed or not well-formed and not
valid or invalid as the latter with XML do only apply to validation
against a DTD or schema.
Right.

And of course you can use « and » in an XML document, these characters
do not break well-formedness. Encoding characters properly matters, but
that is not specific to these two characters or Unicode characters in a
specific range.

I would argue with this point as it is not totally correct in
application to XML. The best option (if decided to use curly quotes)
would be to keep the text "ASCII-clean" and define needed entities
ldquo and rdquo in internal DTD subset (external DTD cannot be used
because of the known Gecko issue with external DTD's).

 

[Bart Van der Donck]

First of all, the right term is well-formed or not well-formed and not
valid or invalid as the latter with XML do only apply to validation
against a DTD or schema.

You're right - I mixed up both terms.

And of course you can use « and » in an XML document, these characters
do not break well-formedness.

Well, they may break well-formedness depending on their encoding, e.g.:

http://www.dotinternet.be/temp/UTF8.xml -> okay
http://www.dotinternet.be/temp/ANSI.xml -> not okay

The latter doesn't pass Microsoft's XP XML parser and Perl's
XML:arser. Firefox doesn't bark officially, but does replace « and
» by a question mark. If the file would contain only 7-bit ASCII, both
links above would be okay.

[...]
Well this document is well-formed XML
<http://home.arcor.de/martin.honnen/xml/test2006091001.xml>
and it does not have an XML declaration.
If you use UTF-8 as the encoding (like that document does) then the XML
declaration is optional. And any XML parser should be able to deal with
the document.

Apparently I wasn't well aware how important it was to handle the data
as UTF-8. Yes, everything parses correct here then.

<http://www.jibbering.com/faq/index.xml> is well-formed as well.

Yes it's ASCII only, my tests indicate that it doesn't matter then how
the file was encoded (as long as it contains no more than ASCII).

And it does not contain « at all.

I added « and » myself, as a regexp towards the Usenet message for

Thus if you have parsing problems then I don't think they result from
<http://www.jibbering.com/faq/index.xml> not being well-formed XML.

The problem was indeed not caused by the XML file but by my own regexp.
It's solved in mean time. It appears my understanding of UTF-8 encoding
was not entirely complete. I would need to handle
http://www.jibbering.com/faq/index.xml as UTF-8 towards the future,
especially when the FAQ could come to a point where it's no ASCII
anymore. And then send the Usenet message as UTF-8 in stead of
ISO-8859-1.

For maximum compatibility I'll keep the message as ISO-8859-1 at this
time though; I think this is much safer since not all news readers like
UTF-8, even known clients as Eudora have issues with it (which is of
course an entire different discussion than XML encoding).

Thanks for your comment. I learnt from it.

 

[Martin Honnen]

VK wrote:

I would argue with this point as it is not totally correct in
application to XML. The best option (if decided to use curly quotes)
would be to keep the text "ASCII-clean" and define needed entities
ldquo and rdquo in internal DTD subset

Based on what section in the XML specification do you want to argue? Any
XML processor has to support UTF-8 and UTF-16
<http://www.w3.org/TR/REC-xml/#charencoding>
so there is no reason to restrict a document to ASCII characters and
escape other characters with character or entity references. Unless you
happen to use an editor that can't create/save files as UTF-8 (or
UTF-16) but that is not a question then of what is correct or not
correct in terms of the XML specification.

 

[VK]

Based on what section in the XML specification do you want to argue? Any
XML processor has to support UTF-8 and UTF-16

God prohibits me to argue with XML specifications!! Not at this month!

:-|
I expressed my considerations about *practical* use of curly quotes in
different "web-based environments". And some considerations about some
practical obstacles one can meet while processing HTML/XML source with
curly quotes using JavaScript/JScript.

<http://en.wikipedia.org/wiki/Quotation_mark#Quotation_marks_in_English>
has nothing against of any specifications. It is mainly a set of
*suggestions* (not requirements) inspired by this or that real case.

If these considerations related with curly quotes seem not important,
anyone please feel free to disregard them.

 

[Bart Van der Donck]

Any XML processor has to support UTF-8 and UTF-16
<http://www.w3.org/TR/REC-xml/#charencoding>
so there is no reason to restrict a document to ASCII characters and
escape other characters with character or entity references.

One such example could be this very discussion. A possible NNTP
requirement towards the XML file could be like "Gimme ASCII in Subjects
and ISO-8859-1 anywhere else, because we don't like UTF-8 on Usenet".

The XML could then make sure for itself that it meets that requirement
by DTD/XSL/schema/... It would be a software design choice of course to
lay this responsibility at the XML's side. But that was why <?xml
version="1.0" encoding="ISO-8859-1"?> would have solved the issue with
'«' and '»', because it declares «/» to be okay, with or without an
UTF-8 encoding.

I agree that UTF-8 is the more XML-ish modern way of course.

 

[Richard Cornford]

One such example could be this very discussion. A possible
NNTP requirement towards the XML file could be like "Gimme
ASCII in Subjects and ISO-8859-1 anywhere else, because we
don't like UTF-8 on Usenet".

The XML could then make sure for itself that it meets that
requirement by DTD/XSL/schema/... It would be a software
design choice of course to lay this responsibility at the
XML's side.

While another approach may suggest that the XML is just data and let it
assert, or default, its character encoding and leave it to the software
that generated the output to do any translating of encodings necessary
to build the desired output.

But that was why
<?xml version="1.0" encoding="ISO-8859-1"?> would have
solved the issue with '«' and '»', because it declares
«/» to be okay, with or without an UTF-8 encoding.

<snip>

But would the script that builds the HTML version have been happy with
the change? However, I could not see where the issue would be as UTF-8
is entirely capable of representing those characters so there shouldn't
have been any problem including them in a UTF-8 encode XML file.

Richard.