By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,375 Members | 1,376 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,375 IT Pros & Developers. It's quick & easy.

"print" in JavaScript

P: n/a

I have just had a problem that I cannot find any reference to in any
docs. Admittedly, I am a JavaScript newbie, but this sure seems like a
bug or an "undocumented feature" in Opera 7.11. I have some debugging
code that writes messages to a TEXTAREA. I named the function that
writes to the TEXTAREA "print", e.g.

content = "";
cnt = 0;
function print(aLine) {
content += (aLine + "\n");
cnt++;
document.getElementById.transcript.value = content;
};
print("some message");

The problem is that when I accidently mis-specified a DOM path to point
to an .html page and invoked "print", e.g.

print(self.parent.frames.transcript);

then Opera gave me a popup Print Dialog. I replied OK and got printout
of the page currently being displayed by Opera. I looked in the docs
and "print" is not a reserved word in JavaScript. Can anyone tell me
what is going on?

--
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

Jul 20 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
I just discovered that Opera 7.11 does in fact implement a "print()" as
a non-standard extension to ECMA. Still, it is a peculiar
implementation: all of my "print" statements do in fact end up in my
TEXTAREA except when I inadvertantly try to print a page. Whatever...I
changed all occurances of print to tprint. Not a problem, just a
mystery.

--
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

Jul 20 '05 #2

P: n/a
"Albert Wagner" <al******@tcac.net> wrote in message
news:20030918190229.2ee43bb1.al******@tcac.net...
I just discovered that Opera 7.11 does in fact implement a
"print()" as a non-standard extension to ECMA. Still, it
is a peculiar implementation: all of my "print" statements
do in fact end up in my TEXTAREA except when I
inadvertantly try to print a page. Whatever...I changed
all occurances of print to tprint. Not a problem, just a
mystery.


The ECMA script specification describes a scripting language. It is the
intention that it be used to script an object model. In a web browser
that object model is implemented by the browser and consists of a
structure of objects (generally tree like and rooted at the global
object (the window object)) some of which have methods specific to web
browsers.

print() is implemented as a function property of the global object in
many web browsers to allow the scripting of the browser's ability to
print web pages and will usually open the print dialog box. This mans
that print is not a non-standard extension of ECMA script, it is not
part of ECMA script at all.

Generally it is unwise to use element names, IDs or JavaScript
identifiers that correspond with existing defined properties within the
browser object model, especially properties of the global object. Though
your specific problem would only manifest itself in browsers that follow
IE in making named/IDed HTML elements named properties of the global
object, unfortunately quite a number of browsers (including Opera 7) do.

Richard.
Jul 20 '05 #3

P: n/a
JRS: In article <bk*******************@news.demon.co.uk>, seen in
news:comp.lang.javascript, Richard Cornford
<Ri*****@litotes.demon.co.uk> posted at Fri, 19 Sep 2003 02:44:41 :-

Generally it is unwise to use element names, IDs or JavaScript
identifiers that correspond with existing defined properties within the
browser object model, especially properties of the global object. Though
your specific problem would only manifest itself in browsers that follow
IE in making named/IDed HTML elements named properties of the global
object, unfortunately quite a number of browsers (including Opera 7) do.


Unfortunately, that otherwise-excellent rule requires a knowledge of all
such existing properties in all such browsers, including those that may
be written after the page in question.

A more pragmatic approach is never to use a name (except in a scope
where a new definition certainly rules) that anyone might, reasonably or
moderately unreasonably, build or have built into a system.

It seems that most lesser-known names in javascript begin with a lower-
case letter; so one could avoid that.

Also, it is commonly convenient when programming to do a general string
search or replace on a page or a page set. Therefore, avoid correctly-
spelt well-known words in the natural language of the page, and in HTML.
Once upon a time, at least one system designer understood this problem.
In software for the Elliott 905, names beginning with Q-but-not-QU
"belonged" to the system software authors. They could be used by
ordinary programmers; they could be redefined, but only at the
programmer's understood risk. All other names were either not used by
the system, or were "well-known".

And in implementations of Algol, "reserved words" were indicated by
punctuation; in some, the word begin was coded as "begin" or
'begin'; in another, as !begin, and then reserved words could be
abbreviated once unambiguous - so !begin could be !be. but not (if
!boolean existed) !b. .
--
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.
Jul 20 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.