Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.javascript > #23471 > unrolled thread

Re: JavaScript in a PRE element of an HTML document

Started by"Jukka K. Korpela" <jkorpela@cs.tut.fi>
First post2014-03-09 07:01 +0200
Last post2014-03-10 07:30 +0200
Articles 11 — 6 participants

Back to article view | Back to comp.lang.javascript

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: JavaScript in a PRE element of an HTML document "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2014-03-09 07:01 +0200
    Re: JavaScript in a PRE element of an HTML document "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2014-03-09 17:05 +0200
      Re: JavaScript in a PRE element of an HTML document Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-03-09 17:15 +0100
      Re: JavaScript in a PRE element of an HTML document "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2014-03-09 19:25 +0200
        Re: JavaScript in a PRE element of an HTML document "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-03-09 19:44 +0100
      Re: JavaScript in a PRE element of an HTML document Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-03-10 18:01 +0000
        Re: JavaScript in a PRE element of an HTML document "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-03-11 09:59 +0100
    Re: JavaScript in a PRE element of an HTML document Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-03-09 16:54 +0100
    Re: JavaScript in a PRE element of an HTML document Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-09 16:30 +0000
    Re: JavaScript in a PRE element of an HTML document Denis McMahon <denismfmcmahon@gmail.com> - 2014-03-09 22:16 +0000
      Re: JavaScript in a PRE element of an HTML document "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2014-03-10 07:30 +0200

#23471 — Re: JavaScript in a PRE element of an HTML document

From"Jukka K. Korpela" <jkorpela@cs.tut.fi>
Date2014-03-09 07:01 +0200
SubjectRe: JavaScript in a PRE element of an HTML document
Message-ID<lfgsk3$hlv$1@dont-email.me>
2014-03-09 1:15, Stefan Ram wrote:

>    Is it alright to have a script in <code><pre>...</pre></code>
>    as in the following text that is intended to be an HTML5 document?

Depends on your definition for "alright". You can put a <script> element 
inside a <pre> element and add content there with document.writeln(). It 
has a defined effect. But it's not regarded as good coding style due to 
various pitfalls, which may become a problem in real life - and your 
example is probably not quite as complex as the real case would be.

Nesting <pre> inside <code> is invalid by any HTML spec. Browsers seems 
to construct the DOM the way we might naively expect, but things won't 
work normally, as you can see e.g. if you try to style the <code> element.

You can nest them the other way around. On the other hand, the <code> 
element would be rather useless here, even if the content is actually 
computer code. The <code> markup does not have much effect beyond 
setting font family to monospace, and <pre> already does that here.

> <!DOCTYPE HTML><html><head><title>T</title><meta charset="UTF-8"></head><body><code><pre><script>
> var a = 5;
> document.writeln( a + 1 );
> document.writeln( a );
> </script></pre></code></body>
>
>    Anything else that is wrong with the above page (except for
>    that the first line might be deemed too long)?

There is no limit on line length in HTML. People who read the code might 
not like long lines.

The most obvious thing with the page is that it makes no sense. I 
suppose the intended real use case would have a loop that generates 
lines of text. Whether that makes sense depends on the content. But 
assuming it makes sense to do so client-side, it would be more suitable, 
and not really more difficult, to add the content by appending to the 
value of the innerHTML property.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [next] | [standalone]


#23478

From"Jukka K. Korpela" <jkorpela@cs.tut.fi>
Date2014-03-09 17:05 +0200
Message-ID<lfi00o$4mi$1@dont-email.me>
In reply to#23471
2014-03-09 16:31, Stefan Ram wrote:

>>> var a = 5;
>>> document.writeln( a + 1 );
>>> document.writeln( a );
[...]
>    The above is intended to be a teaching example used to
>    explain JavaScript. In this specific case, the intention is
>    to show that the evaluation of »a + 1« does not change the
>    value of »a«.

Using console.log() for output would set a better example. You probably 
intend to show the output in an element on your page, so the user won't 
need to know how to look at the console log (though he should learn it).

>    I plan to use
>
> <!DOCTYPE HTML><html><head><title>T</title><meta charset="UTF-8"></head><body><pre><code><script>
> ...
> </script></code></pre></body>

This will cause the page to display

1
2

The <script> element will be parsed and executed, not displayed. To make 
it displayed, escape the "<" in its start and end tag as "&lt;".

An alternative to doing so is to use the <xmp> element, which works 
well, though it has been declared as outdated/deprecated/obsolete in 
HTML specs and drafts for about 20 years:

...<body><xmp><script>...</script></xmp></body>...

(Within <xmp>, no markup whatsoever is recognized, except the element's 
own end tag.)

>    as a general frame for such JavaScript teaching examples:
>    The frame will stay the same, while the JavaScript inserted
>    at »...« will change. But before I replicate this frame, I
>    would like to know whether it contains any major flaws from
>    an HTML5 POV.

A few ideas come to my mind. You could use <iframe> (or <frame>) that 
refers to a JavaScript file as such, a .js file containing only 
JavaScript code. The risk is that in some situations some odd browsers 
may start interpreting and executing the code, instead of just showing 
it, even if you serve it with Content-Type: text/plain.

A better idea might be to have an element on your page and just write 
content to it, using the innerText property, avoiding HTML parsing. This 
means that the pieces of code that you wish to show would appear  in a 
JavaScript array, rather than in separate files. Or you could have an 
array of objects, each containing some code, its sample output, and 
explanations.

>    »document.writeln« is intended to be used to make values
>    visible for JavaScript-teaching purposes, but will not be
>    recommended for real-life DOM-changing code.

I see, but generally, if you tell people to use X for some purpose and 
you yourself, in your presentation, use Y for that purpose, most people 
will use Y. That is, people learn from examples rather than 
explanations. There's some truth in the saying that a good tutorial is a 
collection of good examples, though it needs to have some prose to 
separate the examples, and to be casually consulted if the reader does 
not quite understand an example.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]


#23481

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2014-03-09 17:15 +0100
Message-ID<1778151.TF629ioy90@PointedEars.de>
In reply to#23478
Stefan Ram wrote:

> "Jukka K. Korpela" <jkorpela@cs.tut.fi> writes:
>> The <script> element will be parsed and executed

No, the resource referred by the script element, or the content of the 
script element (that remains after markup parsing) (or both) will be parsed 
and executed by a script engine.
 
>   Yes, this was my intention. (I already know how to display
>   the source code, but was wondering whether it was
>   technically correct to execute it within a pre element.)

That depends on the HTML version and what is generated by it.  But AISB, it 
would be better if beginners were not taught to use document.write() this 
way.

<https://developers.google.com/speed/articles/optimizing-javascript>

whereas s/class/prototype/.


PointedEars
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]


#23485

From"Jukka K. Korpela" <jkorpela@cs.tut.fi>
Date2014-03-09 19:25 +0200
Message-ID<lfi878$5pu$1@dont-email.me>
In reply to#23478
2014-03-09 17:35, Stefan Ram wrote:

> "Jukka K. Korpela" <jkorpela@cs.tut.fi> writes:
>> The <script> element will be parsed and executed
>
>    Yes, this was my intention. (I already know how to display
>    the source code, but was wondering whether it was
>    technically correct to execute it within a pre element.)

Oh. Yes, it is technically correct to put <script> inside <pre>. But I 
don't think it's a good idea. You would anyway have to have two copies 
of the script code if you wish to show both the code and its results, so 
you could just as well have it in a variable. Or you could have code 
that copies the content of a <script> element into a visible element.


-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]


#23487

From"Evertjan." <exxjxw.hannivoort@inter.nl.net>
Date2014-03-09 19:44 +0100
Message-ID<XnsA2EBC8D728056eejj99@194.109.133.133>
In reply to#23485
"Jukka K. Korpela" <jkorpela@cs.tut.fi> wrote on 09 mrt 2014 in 
comp.lang.javascript:

> Or you could have code 
> that copies the content of a <script> element into a visible element.

Just write it in a <pre>:

<style type='text/css'>
pre {color:#800;}
</style>

<pre>
&lt;script type='text/javascript'><script type='text/javascript'>
document.write(document.scripts[0].text)
</script>&lt;/script>
</pre>


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]


#23507

FromDr J R Stockton <reply1400@merlyn.demon.co.uk.invalid>
Date2014-03-10 18:01 +0000
Message-ID<L9A0EiOt3fHTFwcE@invalid.uk.co.demon.merlyn.invalid>
In reply to#23478
In comp.lang.javascript message <lfi00o$4mi$1@dont-email.me>, Sun, 9 Mar
2014 17:05:59, Jukka K. Korpela <jkorpela@cs.tut.fi> posted:

>The <script> element will be parsed and executed, not displayed. To
>make it displayed, escape the "<" in its start and end tag as "&lt;".

There is code in my Web site for displaying a preceding script element,
in (as nearly as possible?) the form in which it was written.

There is also code for displaying functions, in (as nearly as possible?)
the form in which they were written.

Some browsers display the true original, others a de-tokenised tokenised
version.

In each case, the input to the code is the thing itself, not an
alternate version.

See in <http://www.merlyn.demon.co.uk/js-boxes.htm>.
<http://www.merlyn.demon.co.uk/js-nclds.htm>.

-- 
 (c) John Stockton, nr London UK        Reply address via Merlyn Home Page.
   news:comp.lang.javascript FAQ <http://www.jibbering.com/faq/index.html>.
   <http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
   <http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[toc] | [prev] | [next] | [standalone]


#23513

From"Evertjan." <exxjxw.hannivoort@inter.nl.net>
Date2014-03-11 09:59 +0100
Message-ID<XnsA2ED65978A48Feejj99@194.109.133.133>
In reply to#23507
Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> wrote on 10 mrt 2014 
in comp.lang.javascript:

> In each case, the input to the code is the thing itself, not an
> alternate version.

Deep thought!

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]


#23480

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2014-03-09 16:54 +0100
Message-ID<1824351.zCUI6fBnqU@PointedEars.de>
In reply to#23471
Stefan Ram wrote:

>   The above is intended to be a teaching example used to
>   explain JavaScript. In this specific case, the intention is
>   to show that the evaluation of »a + 1« does not change the
>   value of »a«. (Some beginners believe that »a + 1« means,
>   »Go ahead and increment the value of "a" by 1!«.)

What sorry losers would that be?
 
>   I plan to use […]

I strongly suggest you learn the basics, and more, before you start teaching 
others.  There are enough bad teachers on this topic out there as it is.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]


#23483

FromBen Bacarisse <ben.usenet@bsb.me.uk>
Date2014-03-09 16:30 +0000
Message-ID<0.e697a5c0533e75d3b431.20140309163013GMT.87vbvn1giy.fsf@bsb.me.uk>
In reply to#23471
ram@zedat.fu-berlin.de (Stefan Ram) writes:
<snip>
>   The above is intended to be a teaching example used to
>   explain JavaScript. In this specific case, the intention is
>   to show that the evaluation of »a + 1« does not change the
>   value of »a«. (Some beginners believe that »a + 1« means,
>   »Go ahead and increment the value of "a" by 1!«.)

For the basic of the language itself, I would use a command-line
EcmaScript implementation like nodejs.  It has a REP loop so you can get
students to test things like this:

  > var a = 42;
  undefined
  > a
  42
  > a + 1
  43
  > a
  42

I think it helps to learn something of the language (in particular a bit
about higher-order functions and how 'this' works in ES) before mixing
it with a web page.  The web page uses do allow students to do "real"
things very quickly, but the fact that they are learning so much in
parallel makes it problematic in my opinion.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]


#23488

FromDenis McMahon <denismfmcmahon@gmail.com>
Date2014-03-09 22:16 +0000
Message-ID<lfip84$46g$1@dont-email.me>
In reply to#23471
On Sun, 09 Mar 2014 14:31:15 +0000, Stefan Ram wrote:

> I plan to use
> 
> <!DOCTYPE HTML><html><head><title>T</title><meta
> charset="UTF-8"></head><body><pre><code><script>
> ...
> </script></code></pre></body>

>   as a general frame for such JavaScript teaching examples:

It might be a good idea to add a type attribute to your script element.

I see no closing tag for the html element.

I believe it is suggested that a charset line should appear as early as 
possible, as it's presence may require that the document be reprocessed. 
This usually means that, as I understand it, best practice is for it to 
be the first element in the document head.

Have you considered using a textarea as the output region, rather than an 
inline part of the document? Doing so would allow output from interactive 
elements on the page at some future point, and would allow you to 
separate the script code from the document structure.

<!DOCTYPE HTML>
<html>
    <head>
        <meta charset="UTF-8">
        <title>T</title>
        <script type="text/javascript">
            function the_code() {
                var o = document.getElementById("output");
                var a = 5;
                o.value = ""; // clear the output area
                o.value += "1) a = " + a + "\n";
                o.value += "2) a + 1 = " + ( a + 1 ) + "\n";
                o.value += "3) a = " + a + "\n";
            }
        </script>
    </head>
    <body>
        <p><input type="button" value="Run The Code" onclick="code();"></
p>
        <h3>Output:</h3>
        <textarea cols="80" rows="10" id="output" readonly="readonly"></
textarea>
    </body>
</html>

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]


#23491

From"Jukka K. Korpela" <jkorpela@cs.tut.fi>
Date2014-03-10 07:30 +0200
Message-ID<lfjil1$9kf$1@dont-email.me>
In reply to#23488
2014-03-10 0:16, Denis McMahon wrote:

> It might be a good idea to add a type attribute to your script element.

No it isn't.

> I see no closing tag for the html element.

None is needed.

> I believe it is suggested that a charset line should appear as early as
> possible,

By whom? A Candidate Recommendation says: "The element containing the 
character encoding declaration must be serialized completely within the 
first 1024 bytes of the document." I don't think there's much risk of 
exceeding that limit here.

> Have you considered using a textarea as the output region, rather than an
> inline part of the document?

A textarea element is an inline element.

And it is for user input of text. Using it for mere data presentation 
was popular in the mid-1990s when web technologies were slightly more 
primitive than today.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.javascript


csiph-web