I 've got a very interesting thing with an html here.
<html>
<head>
<script language="Javascript">
var str="me&myhtml";
function delimit(){
document.write(str);
document.write("<hr>");
}
</script>
</head>
<body onload="delimit()">
</body>
</html>
You see 'me&myhtml' with a line beneath. However, if you comment //document.write("<hr>");
then you just see 'me', which is weird.
Thing is, javascript normally doesn't read '&', but rather interprets as a command. However, if you have any document.write() with at least 6 characters, or a 'br', or 'hr', then it displays '&' as it is.
Any ideas?
If there is no HTML tag after &myhtml JavaScript or the HTML rendering engine probably interprets it as an unrecognized or incomplete entity (lacking an ending ;) and does not render it. If you follow me&myhtml with an HTML tag, then JavaScript or the HTML rendering engine recognizes that &myhtml is not an incomplete entity because it is followed by an HTML tag instead of a ;.
It doesn't matter what HTML tag you follow the string with, <a> or <p> work just as well as <br>.
The behavior is not consistent across all browsers. IE 6, 7 & 8 and Firefox 2, 3 & 3.5 behave the way you describe, Safari for Windows 3 & 4 render nothing when you comment out the second document.write() or do something like document.write("abc");. Opera 9.64 & 10b3 render the text correctly regardless of the content of the second write().
Note that using document.write() in the onload event without writing out correctly formatted and valid HTML (complete with doctype and <html>, <head>, etc) is probably a bug anyway. Note the problem does not manifest itself if you do:
<html>
<head>
<script>
function delimit() {
document.write('me&myhtml');
}
</script>
</head>
<body>
<script>
delimit();
</script>
</body>
</html>
To answer your question, it is a bug in either the implementation of a specification, or an undefined part of a specification that each browser implements differently. What you are doing is slightly incorrect, the outcome of that slightly incorrect code is not defined and it can not be relied on to behave consistently across all of the major browsers in use today. What you are doing should be avoided.
Try str = "me&myhtml";
I just wanted to know why this is happening.
Well, the browser doesn't yet know whether your &myhtml is an entity reference you haven't finished writing yet, or just broken code it will have to fix up. For example you can say:
document.write('&eac');
document.write('ute;');
(Of course there is no entity reference like &myhtmlpotato; that you could be referring to, but the parser doesn't know that yet.)
If you let the parser know there's no more bits of entity reference coming, by document-writing something that couldn't possibly be in an entity reference, such as a <tag>, or spaces, it'll give up and decide your code was simply broken, and fix it.
Normally the end of the page would be a place where this would happen, but you don't have an end of the page, because the script isn't doing what you think it's doing.
Instead of calling document.write() during the original page loading process when it can write some content to your current page, you're calling it in the onload, by which time the document is completely loaded and you can't add to it. In this state, calling document.write() actually calls document.open() implicitly, destroying the current page and starting a new one, to which you then write ‘my&myhtml’. That new page you have opened stays open and not fully loaded until you call document.close() to tell it you aren't going to write any more to it. At that point your partial entity reference will be resolved as bad markup and fixed.
It probably has to do with the fact that & is essentially an escaping character in HTML. If you want to write out an ampersand to the page, you should use &
Related
I am working on some pretty old code and in every jsp file where there is a javaScript block I see some bizarre Syntax. It goes like :
<script language="JavaScript">
<!--
here is the main code (mixed jsp and javaScript)
//-->
</script>
neccesity <!-- code here //-->
I don't find any necessity for <!-- //--> this syntax. But to remove these from the whole project I really have to be sure why these syntax was used.
Does those had any significance previously, I mean for browser issue or something?
Or,
Just a simple mistake which were carried on.?
HTML style comments in javascript date back to a time when not all browsers supported javascript, so would render the code as text. The <script> tag was just assumed to be just like any other unknown tag, so the tag itself was not rendered, but the contents were
I don't think any current browser would have a problem with it, but I would recommend getting rid of it, because who knows what the future will bring
Does those had any significance previously, I mean for browser issue or something?
Yes, it used to. Remember that a script tag embeds non-HTML inside an HTML document, in this case JavaScript code. Since the content of the script tag isn't HTML, but is being parsed by an HTML parser (while it looks for the ending tag), the idea was to use an HTML comment (<!-- ... -->) to contain the JavaScript code, so the HTML parser wouldn't get confused by HTML-like things within the JavaScript code, and so really old browsers that didn't understand script tags at all wouldn't show the "text" inside them.
The one you've quoted is one of many variations.
There's no need, at all, to do this in an HTML document, with modern browsers — or even with really old browsers, at this point.
In an XHTML document, you do need to do something, but what's shown there is likely to be insufficient; you'd need a CDATA section instead.
Assuming you're writing HTML5 documents (<!doctype html>), you can remove those comments from the JSPs.
As stated here: http://www.w3schools.com/tags/tag_comment.asp
You can also use the comment tag to "hide" scripts from browsers without support for scripts (so they don't show them as plain text)
Nowadays not really an issue I suppose. But may not be the best idea to get rid of them.
Those are comments, just removed if no documentation comments are there
Back in the days there were all sorts of tricks used to make sure that the content looked decent even if the user had javascript or cookies disabled.
This looks like it was meant for hiding the javascript, if the browser didn't understand Javascript.
I just did a little test and if I add a script in the manner illustrated below it seems to execute in most modern major browsers. It executes before the page is loaded, I was wondering if this would work across all browsers (including historic)?
<script type="text/javascript">
alert("hello world");
</script>
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
</body>
</html>
I am of course trying to find a way to execute a script to set a page up before any of it is loaded...any input towards this end would be greatly appreciated. Would it be wrong to use this method?
Thanks in advance for any help!
The script gets executed, but the the markup (any element before a DOCTYPE string) puts some browses to quirks mode, which means a large number of poorly documented quirks and oddities, and mess, too.
So whatever your reasons are, you should at least put the element in the first syntactically correct place, namely right after the <head> tag. This can hardly matter as compared with placing it at the start of the document.
Whether the placement solves your real problem is an entirely different thing. You should ask a separate question, clearly describing the problem (rather than an assumed solution), preferably illustrated by some code that demonstrates the problem.
According to the specs,
A conformant document in the HTML syntax must consist of the following
parts, in the following order:
Optionally, a single U+FEFF BYTE ORDER MARK (BOM) character.
Any number of comments and space characters.
A doctype.
Any number of comments and space characters.
An html element, with its attributes (if any) and its contents (if any).
Browsers follow these specs, and your code (even though works now) may break in the future, since
it clearly breaks the rule of order of elements.
Secondly, it's almost always better to load the scripts last for performance gain.
You mention in the comments that you want to hide/show elements before the page is displayed and that onload is too slow. Try using the DOMContentLoaded instead is it triggers as soon as the HTML DOM is built but before all images CSS and other external references is loaded.
That has always worked for me - though I use jQuery's ready event to make it work cross-browser. And it keeps your HTML valid.
I'm seeing malicious Javascript code injected exactly like this, which somehow makes a blank space at the top of a WordPress page. If you click that blank space, you're taken to a site that talks about crypto. The malicious script uses the Javascript atob() function which when then deconverted with base64 and html-escaped causes the crypto page to be loaded.
Just so you know...
I know that a web page has an implied <head> tag even when there is none declared in the file. I was just curious in testing getElementsByTagName('head') when there is none and it does return a <head> tag.
However, when I placed more than one <head> in the page... it returns a unified head. why is this?
That's because the browser "corrects" your HTML to always include a single <head>. Otherwise your HTML is invalid.
HTML parsers are said to be very much forgiving(I heard this feature makes them faster, not sure) about errors in parsing and evaluating HTML. Whatever you give, it will parse it without any error trying to be near to what you meant. So you are only supposed to have one head element. The browser will change it to a correct form, depending on the implementation. So when the javascript executes it will return the existing head element, after the correction.
I have the following:
<html>
<body>
<script type="text/javascript">
document.write('Hello\nWorld')
</script>
</body>
</html>
As you probably all know, \n doesn’t work and I have to use <br> instead. It won’t work either if I link to an external .js file. Here are my questions:
Why doesn’t \n work?
Why does <br> even work? Shouldn’t everything that’s inside the script tags be strictly JavaScript instead of a dirty mix between HTML and JS?
Is it possible to make \n work somehow?
I know \t doesn’t work either. Any other stuff that won’t work inside HTML files?
Unrelated question (I didn’t want to open a new question just for this): I installed Node.js to be able to try out JS scripts from inside vim but when I run this script I get the error "document is not defined". Same thing happens when I try from the REPL. Any ideas?
When searching for similar questions, all I got was that I should use <br> instead of \n.
I had:
<div>Hello\nworld</div>
I added the below css to div class and it's working now:
div {
white-space: pre-wrap;
}
I hope this solve your problem too.
Why doesn’t \n work?
Because white space is just white space in HTML.
Why does <br> even work?
Because it is the HTML for a line break
Shouldn’t everything that’s inside the script tags be strictly JavaScript instead of a dirty mix between HTML and JS?
That’s subjective. document.write is considered dirty by many as well.
You can always use createElement and createTextNode
Is it possible to make \n work somehow?
<pre>, white-space
I know \t doesn’t work either. Any other stuff that won’t work inside HTML files?
HTML is not plain text. Listing all the differences would be time-consuming, and out of scope for Stack Overflow. Try reading the specification.
Unrelated question (I didn’t want to open a new question just for this)
It is completely unrelated. Open a new question.
\n works. If you have a debugger of sorts (or similar developer tool), you can see the document source, and you will see that there is indeed a newline character. The problem is the way you are looking at the page: you’re not reading its source, you’re reading it as an HTML document. Whitespace in HTML is collapsed into a single space. So when you change the source, it does indeed change, although when interpreted as an HTML document, that change isn’t shown.
Your Node.js error is most probably caused by the fact that you’re running browser scripts on the server. I.e. scripts that refer to the document are intended to be run in a browser, where there is a DOM etc. Although a generic node process doesn’t have such a global object because it isn’t a browser. As such, when you try and run code that references a global object called document on the assumption that it exists just like in the browser, it will throw an error. document.write doesn’t exist; if you want to write to the screen, try console.log or look into the other util functions.
When HTML renders, it ignores whitespace. Thus the only way is to use line breaks.
Use <br/> instead of \n and it will work fine
The document.write() function writes HTML into the element.
Use <pre></pre> on the html and it will respect the text format from JS.
When you write to the page, you're not writing JavaScript; you're writing HTML. \n is a special "line feed" character that doesn't create a line break in the browser's rendering of the HTML. It WILL create a line break in the HTML file itself, but the browser doesn't take this into consideration when it renders out the markup.
Thus, the br tag is required.
Use the html tag <br/> to input line endings (your output is interpreted by an html parser), for example:
Javascript:
document.write("Hello<br/>World");
Whitespace emitted by JavaScript works like any other whitespace in your HTML file. That seems the expected behavior to me.
1) \n works in plain text files.
2) <br /> works because you are doing HTML in string. Strings can hold characters without breaking the rest of the JS script.
3) Not really. Perhaps when you are using <textarea>s.
4) Most other \*'s
5) More info needed.
1,3. "\n" does work. If you do a document.write inside the body tag you can check document.body.innerHTML and see that the line break is indeed there.
4.Anything HTML specific will be rendered HTML specific, so you will have to escape < and > into < and > for instance.
5.document is an object available in browsers, it is not used in node since the DOM doesn't exist there. require("sys"); and use sys.print in nodejs.
The document object represents an HTML document; any text written to the document will be processed by the browser's HTML renderer. In HTML, all adjacent whitespace, including line breaks (e.g., "\n"), are collapsed into a single space when rendered. This is why you need <br />, which is rendered as a line break. You can make \n work by replacing it with <br /> or by writing into a <pre> element:
Hello
World
Actually your code is works. When you run it on browser console like Firefox, it will show you:
<html><head></head><body>
<script type="text/javascript">
document.write('Hello\nWorld')
</script>Hello
World
</body></html>
Note on the Hello and World that is separated.
But when displayed on HTML, line break (whitespace) will be ommited.
To display "as is", you may surround the javascript with PRE tag, like:
<html>
<body>
<pre>
<script type="text/javascript">
document.write('Hello\nWorld')
</script>
</pre>
</body>
</html>
You will get your line break displayed on HTML.
Everyone has said what it was to be said but in case if you are using firebug/chrome Javascript console ..then try this >
console.log("Hello\nWorld");
This is the key difference. When you are printing something in HTML, the HTML rules apply. Elsewhere you can see the line breaks work.
I've seen this tag used after javascript functions for over a decade now and never asked WHY. It's seen in most of the tutorials I've seen over this time, but I usually leave it out... it doesn't seem to have an effect one way or another. Can anyone enlighten me as to why this is used?
If it's just to signify the end of a javascript function, wouldn't the right brace be adequate? If it's for a series of functions, the ending script tag is used.
I doubt I need an example, but for all the other readers out there that are also wondering what it's for, here's some code:
function helloWorld() {
document.write('Hello World');
}
//-->
Thanks in advance!
It's a holdover from the days when browsers without JS support were reasonably common. If you were including JS code directly in an HTML file, you'd include HTML comment tags (<!-- -->) around the code so those browsers didn't display it as part of the page. The reason for // --> is so that browsers that do support JS didn't try to interpret the closing HTML comment as part of the JS code.
Back in the days, some browsers did not handle javascript so to avoid errors, you'd put the javascript code inside an HTML comment block "".
Today, the XHTML standards says you should escape your script like
<script type="text/javascript">
<![CDATA[
... unescaped script content ...
]]>
</script>
You don't have to do that for HTML. Refer to:
http://www.w3.org/TR/xhtml1/
http://www.w3schools.com/tags/tag_script.asp
It's to comment out the code, so legacy browsers that don't support JS won't see it.
That's probably pretty much useless nowadays.
Note that it also needs a <!-- in the beginning to make it a comment.
Read this: http://lachy.id.au/log/2005/05/script-comments
If you notice, you can also usually see a <!-- before the scripts.
That syntax is used so browser that don't support Javascript will ignore the body of those scripts.
In fact, in html, anything surrounded by <!-- and --> is considered to be a comment
It's also useful if you're validating your html code, so the js doesn't appear as invalid html markup. As everyone mentioned however, it's fairly obsolete. I personally try never to have inline javascript, always in an external file that can be cached, which makes this style of coding useless
For browsers that do not understand JavaScript or if JavaScript is manually turned off these start <!-- and end html_comment_tags --> will help the bad_data inside the script > / ? < & ^ % # ) ! - ( to be commented out
If a browser understands javascripts it will not parse the last comment_ending tag--> due to the // placed before the html_comment_end tag--> and if the browser does not understand the meaning of // comment tags of javascript(simply because jscript is turned off) then it obviously parses the --> in the usual way and comments out everything inside the <script></script> including the //