Docs polish

chrome/common/extensions/docs/static/content_scripts.html

 <div id="pageData-title" class="pageData">Content Scripts</div>
 <div id="pageData-showTOC" class="pageData">true</div>
 
 <p>
 Content scripts are JavaScript files that run in the context of web pages.
 By using the standard
 <a href="http://www.w3.org/TR/DOM-Level-2-HTML/">Document
 Object Model</a> (DOM),
 they can read details of the web pages the browser visits,
 or make changes to them.
@@ skipping 118 matching lines @@
 
 <h2 id="execution-environment">Execution environment</h2>
 
 <p>Content scripts execute in a special environment called an <em>isolated world</em>. They have access to the DOM of the page they are injected into, but not to any JavaScript variables or functions created by the page. It looks to each content script as if there is no other JavaScript executing on the page it is running on. The same is true in reverse: JavaScript running on the page cannot call any functions or access any variables defined by content scripts.
 
 <p>For example, consider this simple page:
 
 <pre>hello.html
 ==========
 &lt;html&gt;
-  &lt;button id="button"&gt;click me&lt;/button&gt;
+  &lt;button id="mybutton"&gt;click me&lt;/button&gt;
   &lt;script&gt;
-    var greeting = "hello!";
-    function sayGreeting() {
-      alert(greeting);
-    }
-    document.getElementById("button").onclick = sayGreeting;
+    var greeting = "hello, ";
+    var button = document.getElementById("mybutton");
+    button.person_name = "Bob";
+    button.addEventListener("click", function() {
+      alert(greeting + button.person_name + ".");
+    }, false);
   &lt;/script&gt;
 &lt;/html&gt;</pre>
 
 <p>Now, suppose this content script was injected into hello.html:
 
 <pre>contentscript.js
 ================
-console.log(greeting);  // undefined
-console.log(sayGreeting);  // undefined
-console.log(document.getElementById("button").onclick);  // still undefined
-document.getElementById("button").onclick = function() {
-  alert("hola!");
-}</pre>
+var greeting = "hola, ";
+var button = document.getElementById("mybutton");
+button.person_name = "Roberto";
+button.addEventListener("click", function() {
+  alert(greeting + button.person_name + ".");
+}, false);
+</pre>
 
 <p>Now, if the button is pressed, you will see both greetings.
 
 <p>Isolated worlds allow each content script to make changes to its JavaScript environment without worrying about conflicting with the page or with other content scripts. For example, a content script could include JQuery v1 and the page could include JQuery v2, and they wouldn't conflict with each other.
 
 <p>Another important benefit of isolated worlds is that they completely separate the JavaScript on the page from the JavaScript in extensions. This allows us to offer extra functionality to content scripts that should not be accessible from web pages without worrying about web pages accessing it.
 
 
 <h2 id="host-page-communication">Communication with the embedding page</h2>
 
@@ skipping 18 matching lines @@
 
 document.getElementById('myCustomEventDiv').addEventListener('myCustomEvent', function() {
   var eventData = document.getElementById('myCustomEventDiv').innerText;
   port.postMessage({message: "myCustomEvent", values: eventData});
 });</pre>
 
 <p>In the above example, example.html (which is not a part of the extension) creates a custom event and then can decide to fire the event by setting the event data to a known location in the DOM and then dispatching the custom event. The content script listens for the name of the custom event on the known element and handles the event by inspecting the data of the element, and turning around to post the message to the extension process. In this way the page establishes a line of communication to the extension. The reverse is possible through similar means.</p>
 
 <h2 id="security-considerations">Security considerations</h2>
 
-When writing a content script, you should be aware of two security issues.
+<p>When writing a content script, you should be aware of two security issues.
 First, be careful not to introduce security vulnerabilities into the web site
 your content script is injected into.  For example, if your content script
 receives content from another web site (e.g., by <a
 href="messaging.html">asking your background page to make an
 XMLHttpRequest</a>), be careful to filter that content for <a
 href="http://en.wikipedia.org/wiki/Cross-site_scripting">cross-site
 scripting</a> attacks before injecting the content into the current page.
 For example, prefer to inject content via innerText rather than innerHTML.
 Be especially careful when retrieving HTTP content on an HTTPS page because
 the HTTP content might have been corrupted by a network <a
@@ skipping 41 matching lines @@
 just like you would any other URL,
 as the following code shows.
 </p>
 
 
 <pre>
 <em>//Code for displaying &lt;extensionDir>/images/myimage.png:</em>
 var imgURL = <b>chrome.extension.getURL("images/myimage.png")</b>;
 document.getElementById("someImage").src = imgURL;
 </pre>