document.write and buffer data

  • Thread starter Radek Maciaszek
  • Start date
R

Radek Maciaszek

Hi

It's very interesting problem. I couldn't even find any inforamtion
about it on the google.
I think that the best way of explain will be this simple example:

<html>
<body>
<script language="JavaScript" type="text/javascript"
src="write.js"></script>
</body>
</html>

write.js:
document.write("start<br />\n");
document.write("<" + "script language='JavaScript'
type='text/javascript' src='test.js'><" + "/script>");
document.write("end<br />\n");

and test.js:
document.write('middle <br />');


The expected output is:
start
middle
end

but the real output is:
start
end
middle

This output has to be generated inside "write.js" file and I have to
use sometimes some external files like this "test.js".
I'm trying to find a solution to force a browser to output everything
from test.js before the "end".

I found only this info:
http://www.web-developer-india.com/web/jscript/refp_95.html
where I found that placing HTML tag (without JavaScript) force a
browser to output the buffer. But unfortuanetly I couldn't output any
HTML tag inside write.js file.

Is it possible to force a browser to render the content before "end"
document.write?
 
M

McKirahan

Radek Maciaszek said:
Hi

It's very interesting problem. I couldn't even find any inforamtion
about it on the google.
I think that the best way of explain will be this simple example:

<html>
<body>
<script language="JavaScript" type="text/javascript"
src="write.js"></script>
</body>
</html>

write.js:
document.write("start<br />\n");
document.write("<" + "script language='JavaScript'
type='text/javascript' src='test.js'><" + "/script>");
document.write("end<br />\n");

and test.js:
document.write('middle <br />');


The expected output is:
start
middle
end

but the real output is:
start
end
middle

This output has to be generated inside "write.js" file and I have to
use sometimes some external files like this "test.js".
I'm trying to find a solution to force a browser to output everything
from test.js before the "end".

I found only this info:
http://www.web-developer-india.com/web/jscript/refp_95.html
where I found that placing HTML tag (without JavaScript) force a
browser to output the buffer. But unfortuanetly I couldn't output any
HTML tag inside write.js file.

Is it possible to force a browser to render the content before "end"
document.write?
Click to expand...

Is ASP an option?

If so then you could use the FileSystemObject to merge the includes.
 
R

Radek Maciaszek

McKirahan said:
Is ASP an option?

If so then you could use the FileSystemObject to merge the includes.
Click to expand...

I have PHP on server but unfortunately I couldn't use it in this case
because HTML, write.js and test.js are on three different servers. So
for example I could include "write.js" by PHP but I don't know if
write.js return just a "document.write" or will try to include
"test.js" or any other js file. And I couldn't change these
requirements... So the only solution (IMO) is to force a browser to
finish rendering everything before the "end" tag but there is no such
possibility in pure JavaScript in IE nor in Mozilla. I hope I am
wrong..
 
E

Evertjan.

Radek Maciaszek wrote on 04 apr 2005 in comp.lang.javascript:
With Ultimater help I've found a solution to this problem.
Click to expand...

What problem?

Without your quoting of the posting you are reacting on,
how the hell should we know what you are talking about?
 
T

Thomas 'PointedEars' Lahn

Radek said:
document.write("<script src='start.js'>\</script>");
document.write("<script src='test.js'>\</script>");
document.write("<script src='end.js'>\</script>");
Click to expand...

Firstly, don't call document.write() consecutively if you can avoid it.
Doing otherwise is known to be error-prone, and inefficient compared to
the alternative(s).

Secondly, you don't have to escape the `<' character, but you should escape
the `</' (ETAGO delimiter) with `<\/' if these statements are part of a
HTML document (note that document.write() is not supposed to work in XHTML,
you have to use W3C DOM Level 2+ Methods there).

Thirdly, your `script' elements are lacking the `type' attribute, required
for Valid (X)HTML 4.01/1.0+.

Use instead:

var
scripts = new Array("start.js", "test.js", "end.js"),
s = "";

for (var i = 0; i < scripts.length; i++)
{
s += '<script type="text/javascript" src="'
+ scripts
+ '"><\/script>\n';
}

document.write(s);

However, note that your method using `scripts' element alone may not work
as expected. But if you concatenate the output strings to be generated,
your original problem should disappear. Yet, making your document dependent
on client-side scripting this way, could raise usability issues, depending
on the expected environment it should run.
here is the link:
http://www.webdeveloper.com/forum/showthread.php?t=61386
Click to expand...

Alas, there are no competent people there. Not a surprise to me, though.


PointedEars
 
K

Kevin Yarmak

It doesn't matter where you break your End Script tags.

The left-than-character doesn't need to be escaped, but neither does the
forward-slash.

document.write("<script src='start.js'>\</script>");
is the same as:
document.write("<script src='start.js'><\/script>");

You Simply cannot Write it out: </script> or you will actually end the
"real" SCRIPT tag.


Yeah, the script tags are lacking the TYPE attribute...
They are also lacking the LANGUAGE attribute.
Even though the LANGUAGE attribute is deprecated in the newer browsers,
it doesn't mean that older browsers don't still use it, because they do.
It's best to include both of the attributes.
(note: deprecated means that it is no longer supported and kinda
abandoned)
Thus:
document.write("<script type="text/javascript" language="javascript"
src='start.js'>\</script>");
 
M

Michael Winter

Kevin said:
It doesn't matter where you break your End Script tags.
Click to expand...

Yes, it does.

[snip]
document.write("<script src='start.js'>\</script>");
is the same as:
document.write("<script src='start.js'><\/script>");
Click to expand...

In so far as an ECMAScript parser is concerned, yes, but not from the
point of view of an SGML parser. The HTML specification states that a
user agent is permitted to terminate a SCRIPT element on the first
occurance of ETAGO (</). Even though no-one knows of a user agent that
does this, breaking this token with a backslash will prevent markup
validators from issuing errors on every occurance.

Of course, if you place the script in an external file, which is surely
where the bulk of any script should go in most cases, how an SGML parser
behaves is of no consequence; no escaping is required at all.

[snip]
They are also lacking the LANGUAGE attribute.
Even though the LANGUAGE attribute is deprecated in the newer browsers,
it doesn't mean that older browsers don't still use it, because they do.
Click to expand...

Not in any way that is really desirable or necessary.
It's best to include both of the attributes.
Click to expand...

I strongly disagree.

[snip]

Mike
 
K

Kevin Yarmak

If an older browser "sees" the TYPE attribute, it ignores it.
If a newer broswer "sees" the LANGUAGE attribute, it also ignores it.

You can provide as many illegal attributes in any HTML tag as you like!

example:

<input id="blah" bbfgbbb="Hello World!">
<script id="scriptId" megaId="custom id"></script>
<script type="text/javascript" language="javascript"><!--
alert(document.getElementById("blah").bbfgbbb)
alert(document.getElementById("scriptId").megaId)
//--></script>

My conclusion is that the LANGUAGE attribute still servers a purpose --
for older browers.
You never know, maybe one outta a hundred of the guests to your website
will have an old browser.
It may be extra typing to also include the LANGUAGE attribute but it
does still serve a purpose -- these older browers.
It can't hurt to include the LANGUAGE attribue because it's not gonna
cause any browers to mis-behave.
 
L

Lee

Kevin Yarmak said:
My conclusion is that the LANGUAGE attribute still servers a purpose --
for older browers.
You never know, maybe one outta a hundred of the guests to your website
will have an old browser.
Click to expand...

And what percentage of the browsers that don't understand
type="text/javascript" are going to understand all of your
code? Would it be better for them to not try to execute it?
 
T

Thomas 'PointedEars' Lahn

Kevin said:
If an older browser "sees" the TYPE attribute, it ignores it.
Click to expand...

Most certainly.
If a newer broswer "sees" the LANGUAGE attribute, it also ignores it.
No.

You can provide as many illegal attributes in any HTML tag as you like!
Click to expand...

There is nothing like "illegal" attributes. Either a document conforms to
a HTML specification or it does not. Either it is Valid HTML or it is no
HTML at all. BTW: HTML parsing is not restricted to Web browsers, and even
then there are a user agents out there that use strict SGML parsers.
example:

<input id="blah" bbfgbbb="Hello World!">
<script id="scriptId" megaId="custom id"></script>
Click to expand...

The `script' element does not have a `megaId' attribute, this is invalid
HTML, i.e. *no* HTML. Tagsoup parsers will silently ignore it, SGML
parsers will yield an error and are allowed to display nothing else but
the error.
<script type="text/javascript" language="javascript">
Click to expand...

This can be included in Valid HTML 4.01 Transitional only.
<!--
Click to expand...

Scripts do not need to/should not be commented out this way any longer.
alert(document.getElementById("blah").bbfgbbb)
alert(document.getElementById("scriptId").megaId)
Click to expand...

Although this is a test case, note that this kind of referring to
objects is known to be error-prone and therefore not recommended.

//--></script>

My conclusion is that the LANGUAGE attribute still servers a purpose --
for older browers.
Click to expand...

You are mistaken. language="JavaScript1.2" affects Mozilla's behavior,
that's all.
You never know, maybe one outta a hundred of the guests to your website
will have an old browser.
Click to expand...

A browser older than 10 (in words: TEN!) years?
It may be extra typing to also include the LANGUAGE attribute but it
does still serve a purpose -- these older browers.
Click to expand...

No, it does not. Those older browsers do not need that attribute, as you
have correctly stated above. It is because there is no HTML specification
or UA reference that says that the attribute must be included and no
ECMAScript specification that says the value of that has to be "javascript"
and the like for the script to be executed by a JavaScript/ECMAScript
conforming script engine.
It can't hurt to include the LANGUAGE attribue because it's not gonna
cause any browers to mis-behave.
Click to expand...

It can hurt if you use a Strict document type or XHTML 1.1+. It is simply
Voodoo: You know that it most certainly changes nothing but you include it
anyway, wasting your time and disk space and the time and bandwidth of your
visitors whose user agents have to download, parse and error-correct it.

Of course. Lots of Voodoo coding originates at this source.


PointedEars
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

How to treat an input data as variable? 4
external javascript breaks document.write() recursion 0
How could I redirect document.write to a new page/tab? 8
Help with my responsive home page 2
Issue with textbox script? 0
document.write 1
What "might" I be doing wrong with this snippet? 6
How can I get this code to run 4

Members online

No members online now.
Total: 37 (members: 0, guests: 37)
Robots: 458

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,054
Latest member
TrimKetoBoost

Latest Threads

Top