Refactored readability.js expected files to match readability.php style

1 files changed, 1 insertions, 3 deletions

diff --git a/test/test-pages/001/expected.html b/test/test-pages/001/expected.html
index 458cbce..fa8ffd2 100644
--- a/test/test-pages/001/expected.html
+++ b/test/test-pages/001/expected.html
@@ -1,4 +1,3 @@
-<div id="readability-page-1" class="page">
     <section>
         <p><strong>So finally you're <a href="http://fakehost/code/2013/testing-frontend-javascript-code-using-mocha-chai-and-sinon/">testing your frontend JavaScript code</a>? Great! The more you
 write tests, the more confident you are with your code… but how much precisely?
@@ -92,5 +91,4 @@ describe("Cow", function() {
         <p>As you can see, the report at the bottom highlights that we haven't actually tested the case where an error is raised in case a target name is missing. We've been informed of that, nothing more, nothing less. We simply know we're missing a test here. Isn't this cool? I think so!</p>
         <p>Just remember that code coverage will only <a href="http://codebetter.com/karlseguin/2008/12/09/code-coverage-use-it-wisely/">bring you numbers</a> and raw information, not actual proofs that the whole of your <em>code logic</em> has been actually covered. If you ask me, the best inputs you can get about your code logic and implementation ever are the ones issued out of <a href="http://www.extremeprogramming.org/rules/pair.html">pair programming</a> sessions and <a href="http://alexgaynor.net/2013/sep/26/effective-code-review/">code reviews</a> — but that's another story.</p>
         <p><strong>So is code coverage silver bullet? No. Is it useful? Definitely. Happy testing!</strong> </p>
-    </section>
-</div>
+    </section>
\ No newline at end of file