Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Hiding script in certain browsers

0 views
Skip to first unread message

Christopher Benson-Manica

unread,
Sep 14, 2004, 3:51:46 PM9/14/04
to
Obviously, compiliant browsers that encounter

<script type="text/javascript">
<!--
// your script here
// -->
</script>

will either execute the script or ignore it completely. However, we are
encountering some browsers running on mobile phones that can't handle
the <script> tag, and will fail to render any page containing the tag.
Can anyone suggest some other mechanism of hiding script from such
browsers in such a way that they will render the page normally aside
from the script? Might there be some correctable mistake causing the
problem?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

Michael Winter

unread,
Sep 14, 2004, 4:24:09 PM9/14/04
to
On Tue, 14 Sep 2004 19:51:46 +0000 (UTC), Christopher Benson-Manica
<at...@nospam.cyberspace.org> wrote:

> Obviously, compiliant browsers that encounter
>
> <script type="text/javascript">
> <!--

Don't place script content in SGML. That practice is outdated and
unnecessary. If you want to prevent a script from being rendered, place it
in an external file. It's advisable to do this for production code, anyway.

> // your script here
> // -->
> </script>
>
> will either execute the script or ignore it completely. However, we are
> encountering some browsers running on mobile phones that can't handle
> the <script> tag, and will fail to render any page containing the tag.

I find it difficult to believe that the page won't render if a user agent
can't handle an element. The HTML Specification explicitly instructs user
agents to ignore the element and render the contents if it's unknown. As
you're scripts should have no content, there will be no effect.

Try placing an empty SCRIPT element in a minimal page (that is, the
smallest, valid page). If it doesn't render the page, inform the vendors:
that's a serious bug.

This should do the trick:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">

<title>Test</title>

<script type="text/javascript"></script>
</head>

<body>
<p>This is a test page.</p>
</body>
</html>

If your server sends the content type and character set, you can remove
the META element.

> Can anyone suggest some other mechanism of hiding script from such
> browsers in such a way that they will render the page normally aside
> from the script?

If they're choking on the SCRIPT element, rather than the script itself,
it'll be difficult. The only thing I can think of at the moment is to
sniff the browser on the server and send a different page with no SCRIPT
elements. Hardly a nice solution, though.

[snip]

Good luck,
Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

Ben Measures

unread,
Sep 14, 2004, 4:30:10 PM9/14/04
to
Christopher Benson-Manica wrote:
> Obviously, compiliant browsers that encounter
>
> <script type="text/javascript">
> <!--
> // your script here
> // -->
> </script>
>
> will either execute the script or ignore it completely. However, we are
> encountering some browsers running on mobile phones that can't handle
> the <script> tag, and will fail to render any page containing the tag.
>
> Can anyone suggest some other mechanism of hiding script from such
> browsers in such a way that they will render the page normally aside
> from the script?

Put the JS in an external file and link it with
<script type="text/javascript" src="uri_to.js"></script>

--
Ben M.

Richard Cornford

unread,
Sep 14, 2004, 5:12:20 PM9/14/04
to
Michael Winter wrote:

> Christopher Benson-Manica wrote:
>> Obviously, compiliant browsers that encounter
>> <script type="text/javascript">
>> <!--
>
> Don't place script content in SGML. That practice is outdated ...
<snip> ^

SGML Comments? :)

>> // your script here
>> // -->
>> </script>
>>
>> will either execute the script or ignore it completely. However, we
>> are encountering some browsers running on mobile phones that can't
>> handle the <script> tag, and will fail to render any page containing
>> the tag.
>
> I find it difficult to believe that the page won't render
> if a user agent can't handle an element.

I also find it difficult to believe that "some browsers" have been
written for mobile devices (and so presumably relatively recently) such
that they do not conform to the HTML specs (while accepting that content
type). However, we might finally have examples of browsers that take the
rules about un-escaped '</' sequences within javascript string literals
seriously.

<snip>
> ... . The only thing I can think of at the moment


> is to sniff the browser on the server and send a different
> page with no SCRIPT elements. Hardly a nice solution, though.

The only information the server has is the UA header, so that won't be
of much use.

Richard.


Michael Winter

unread,
Sep 14, 2004, 6:16:01 PM9/14/04
to
On Tue, 14 Sep 2004 22:12:20 +0100, Richard Cornford
<Ric...@litotes.demon.co.uk> wrote:

> Michael Winter wrote:

[snip]

>> Don't place script content in SGML. That practice is outdated ...
> <snip> ^
>
> SGML Comments? :)

Umm, yeah. Thanks. :)

[snip]

>> ... . The only thing I can think of at the moment
>> is to sniff the browser on the server and send a different
>> page with no SCRIPT elements. Hardly a nice solution, though.
>
> The only information the server has is the UA header, so that won't be
> of much use.

It may be of use, but how much depends on reliability. Assuming that the
UA in question doesn't flawlessly spoof another browser, what's the
likelihood of someone spoofing a mobile browser? There isn't much benefit
in pretending to be an embedded Opera browser, for example.

But first things first: is this a browser bug that needs to be
circumvented, or an error on the OP's part? We'll have to wait and see.

Mike


Just for the record, I don't like entertaining the idea of browser
sniffing, but if this is a browser bug, there aren't many alternatives,
are there?

0 new messages