Double-document.write('<scr'+'ipt>...) insert <br>-like space?

[Richard]

<div id="right" >
<script type="text/javascript">
if (IsThis)
document.write('<img src="images/foo.gif" />');
else
{
document.write('<div id="too_right"><scr' + 'ipt type="text/
javascript" src="http://external.com/script.js"></scr' + 'ipt></
div>');
}
</script>
</div>

Now here's the good part: http://external.com/script.js returns (wait
for it) 'document.write("<img src="..." />");'

This actually works, except that it acts like I have put in <br/>
elements. The <img> is top-aligned (good) but the image returned by
the script.js is pushed to the bottom, AND (worse) the whole <div>
height is increased, pushing all the later elements on the page down.

Does the legacy of write() imply a newline at the end?

If CSS is the answer, I would prefer not trying to position the
"right" div; trying to restrain the height would be easier.

 

[RobG]

Randy Webb wrote:
[...]

Then why not just write the image tag anyway? Or, is the src attribute
different?

if (!IsThis){document.write('<div id="too_right">')}
document.write('<img src="images/foo.gif">');
if (!IsThis){document.write('</div>')}

I am always wary of writing opening and closing tags in separate
document.write statements. It is much better I think to build the
string, then write it in one go:

var html = '';
if (IsThis) {
html += '<img src="images/foo.gif">';
} else {
html += '<div id="too_right"><script'
+ ' type="text/javascript" '
+ ' src="http://external.com/script.js">'
+ '<\/script><\/div>';
}
document.write(html);

 

[Richard]

1. Do you mean the 'scr' + 'ipt' thing? I had some browser get
confused and end the real script tag once. Perhaps it is unnecessary
these days.

2. The goal is to sometimes embed the <img> and sometimes embed the
<script>.

3. I have to do it this way because I do not own script.js; I cannot
control what it does, and currently, it does a document.write(). If I
want to use it based on a JavaScript value, I have to do this nested
document.write weirdness processing at page parse-time. I would prefer
to use div.innerHTML = ..., but as the external script returns
"document.write(...)", that is not an option.

4. Why XHTML? XML editors prefer it, and they will tell me if I am
missing something. While 90% of the web might not know what it is,
they do not seem to mind it.

Cheers

 

[RobG]

1. Do you mean the 'scr' + 'ipt' thing? I had some browser get
confused and end the real script tag once. Perhaps it is unnecessary
these days.

Please do not top-post, reply below trimmed quotes.

The characters </ are the official official end-of-tag markers, so
that's want you need to "hide" from the browser (although most will
not end it until </script> is encountered).


[...]

4. Why XHTML? XML editors prefer it, and they will tell me if I am
missing something.

Your choice of editor should not drive the language you use, it should
be the other way around.

While 90% of the web might not know what it is,
they do not seem to mind it.

<URL: http://www.spartanicus.utvinternet.ie/no-xhtml.htm >

 

[Thomas 'PointedEars' Lahn]

1. Do you mean the 'scr' + 'ipt' thing? I had some browser get
confused and end the real script tag once. Perhaps it is unnecessary
these days.

[...]
The characters </ are the official official end-of-tag markers, so
that's want you need to "hide" from the browser (although most will
not end it until </script> is encountered).

Note that this condition applies to CDATA (character data) content only (and
IIRC not to XML applications). In XHTML the content model of the `script'
element is PCDATA (parsed character data), where no such restriction exists
(there exist other restrictions such as escaping markup characters, or
including the `script' content in a CDATA declaration block, or you don't
use inline scripts at all).

However, if the XHTML is HTML-compatible and when served as text/html, the
condition mentioned by you would apply as well, because so far there is no
context-sensitive parser selection implemented in UAs (it all depends on
the Content-Type; the W3C Validator in contrast is context-sensitive).

[...]

4. Why XHTML? XML editors prefer it, and they will tell me if I am
missing something.

Your choice of editor should not drive the language you use, it should
be the other way around.

But these *two* are generally considered valid arguments for using XHTML.
However, he should then do it properly, i.e. write HTML-compatible XHTML
as much as possible (it can't be done with `<br />' as `<br></br>' for
example), and serve it as application/xhtml+xml to UAs which support that
(Accept-* evaluation, either through built-in or user-defined Content
Negotation).


PointedEars