fix more intellij warnings

Jaguar0625 · Jaguar0625 · commit facf895f2d53 · 2015-10-02T19:23:34.000-04:00
diff --git a/NisApi.src.html b/NisApi.src.html
@@ -1,3 +1,4 @@
+<!--suppress HtmlUnknownTag -->
 <html>
 
 <head>
diff --git a/index.html b/index.html
@@ -1,3 +1,4 @@
+<!--suppress HtmlUnknownTag -->
 <html>
 <head>
 <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
@@ -2388,7 +2389,7 @@ <h2 id="mosaics">Mosaics</h2>
             mosaic name is 32 characters. Allowed characters are
             <ol><li>a, b, c, ..., z, A, B, C, ..., Z, 0, 1, 2, ..., 9, ', _ , - </li></ol>
             but the first character must be a letter from the alphabet.
-        </br></li>
+        <br/></li>
 <li>
 <b>description</b>: Each definition needs a description of the mosaic. The description may not exceed a length of 512 characters. There is no
             limitation for the characters used in the description.
@@ -2403,7 +2404,7 @@ <h2 id="mosaics">Mosaics</h2>
 <li><b>divisibility</b>: The divisibility determines up to what decimal place the mosaic can be divided into. Thus a divisibility of 3
                     means that a mosaic can be divided into smallest parts of 0.001 mosaics, i.e. milli mosaics is the smallest sub-unit.
                     When transferring mosaics via a transfer transaction the quantity transferred is given in multiples of those smallest parts.<br>
-                    The divisibility must be in the range of 0 and 6. The default value is "0".</br></li>
+                    The divisibility must be in the range of 0 and 6. The default value is "0".<br/></li>
 <li><b>supplyMutable</b>: The creator can choose between a definition that allows a mosaic supply change at a later point or an immutable supply.
                     Allowed values for the property are "true" and "false". The default value is "false".</li>
 <li><b>transferable</b>: The creator can choose if the mosaic definition should allow for transfers of the mosaic among accounts other than
@@ -2542,7 +2543,7 @@ <h1 id="initiating-transactions">Initiating transactions</h1>
         <div class="warning">
             The <span class="JSON">/transaction/prepare-announce</span> API
             should be <br> used only on <strong>TRUSTED</strong> and <strong>LOCAL</strong> nodes!
-        </br></div>
+        <br/></div>
 <p>Note: keep in mind, that NCC does <strong>NOT</strong>
             use this API. It does all the transaction signing on it's own.
         </p>
@@ -2656,7 +2657,7 @@ <h3 id="version-2-transfer-transactions">Version 2 transfer transactions</h3>
 <p>However, version 2 transfer transaction are more powerful as they let you transfer mosaics too.<br>
         Suppose you already have created a mosaic with id 'makoto.metals.silver * coin' with a divisibility of 0 and you want bundle the transfer
         of those silver coin mosaics with a transfer of 100 XEM for each silver coin. For transferring 3 silver coin mosaics and 300 XEM with a single
-        transfer transaction you would issue a RequestPrepareAnnounce JSON object to NIS which looks like this:</br></p>
+        transfer transaction you would issue a RequestPrepareAnnounce JSON object to NIS which looks like this:<br/></p>
 <pre><code class="JSON">
 {
         "transaction":
@@ -2786,7 +2787,7 @@ <h2 id="initiating-a-multisig-transaction">Initiating a multisig transaction</h2
         Since the account <em>Alice</em> is a multisig account the transfer transaction
         (in the JSON object the "otherTrans" structure) must be wrapped in
         a multisig transaction (see <span><em>Appendix A:</em> <a href="#multisigTransaction">MultisigTransaction</a></span>).
-        The corresponding RequestPrepareAnnounce object would look similar to this (test network):</br></p>
+        The corresponding RequestPrepareAnnounce object would look similar to this (test network):<br/></p>
 <pre><code class="JSON">    {
         "transaction":
         {
@@ -2863,7 +2864,7 @@ <h3 id="cosigning-multisig-transaction">Cosigning multisig transaction</h3>
         two of the three cosignatories have signed the inner transfer transaction (<em>Bob</em>
         indirectly signed by initiating the multisig transaction) and thus the
         multisig transaction can be included in a block.
-    </br></p>
+    <br/></p>
 <h2 id="adding-and-removing-cosignatories">Adding and removing cosignatories</h2>
 <p>It is possible to modify the list of cosignatories for a multisig account. This is
         done via a aggregate modification transaction wrapped in a multisig transaction.</p>
@@ -2921,7 +2922,7 @@ <h2 id="adding-and-removing-cosignatories">Adding and removing cosignatories</h2
         transaction as above but this time with <span class="JSON">"modificationType"</span>
         set to <b>2</b> (which means remove) and using a minimum cosignatories relative change value of <b>-1</b>.<br>
         For removing a cosignatory <em>all</em> cosignatories except the one being removed need to sign the transaction.
-        Once approved by the network <em>Hachi</em> is no longer cosignatory of the multisig account <em>Alice.</em></br></p>
+        Once approved by the network <em>Hachi</em> is no longer cosignatory of the multisig account <em>Alice.</em><br/></p>
 <div class="warning">
         Removal of accounts is <strong>NOT</strong> final and might be subject of change
     </div>
@@ -2931,7 +2932,7 @@ <h2 id="how-to-use-a-multisig-account">How to use a multisig account</h2>
         If for instance all private keys of the cosignatories of a multisig account
         reside on a single computer then the multisig account is essentially as good
         as a normal account because if that computer gets compromised all private
-        keys are disclosed to the attacks at once.</br></p>
+        keys are disclosed to the attacks at once.<br/></p>
 <p>It is therefore essential to have the private key of the cosignatories on
         different computer preferably in different locations.</p>
 <p>If you have read
@@ -2999,7 +3000,7 @@ <h2 id="provisioning-a-namespace">Provisioning a namespace</h2>
         If NIS responses with a success message, the transaction is broadcasted to the network and will get included in a future block.
         After the transaction is included in a block you can check that you are the owner of that namespace by issuing an /account/namespaces
         request, see chapter xyz.
-    </br></p>
+    <br/></p>
 <p>To rent the sub-namespace 'alice.vouchers' you need again send a RequestPrepareAnnounce JSON object to NIS which this time looks like this:</p>
 <pre><code class="JSON">
 {
@@ -3034,7 +3035,7 @@ <h3 id="creating-a-mosaic-definition">Creating a mosaic definition</h3>
 <p>The basics of the NEM mosaic concept can be found in the chapter <a href="#mosaics">Mosaics</a>.<br>
         To define and create a mosaic type you need to issue a <a href="#mosaicDefinitionCreationTransaction">MosaicDefinitionCreationTransaction</a>.
         As usual this is done by sending a RequestPrepareAnnounce JSON object to NIS which in this case would look like this:
-    </br></p>
+    <br/></p>
 <pre><code class="JSON">
 {
         "transaction":
@@ -3095,7 +3096,7 @@ <h3 id="creating-a-mosaic-definition">Creating a mosaic definition</h3>
         The definition also implies a levy with each transfer. The levy section states that there is an additional fee of 10 XEM for each transfer. That fee
         is send to the recipient with address TD3RXTHBLK6J3UD2BH2PXSOFLPWZOTR34WCG4HXH.<br>
         This levy part of the transaction is optional. If that part is ommited no additional fee arises from transferring the mosaics.
-    </br></p>
+    <br/></p>
 <p>Reasons for NIS now accepting the transactions are most likely:
         <li>The transaction signer does not own the namespace that is specified in the mosaic definition or the namespace has expired.</li>
 <li>A mosaic definition with the specified mosaic id already exists (see discussion below about altering mosaic definitions).</li>
@@ -3912,7 +3913,7 @@ <h2 id="transaction-fees">Transaction fees</h2>
                     Applying the above formula gives<br>
                     xemEquivalent = (8,999,999,999 * 15,000) / (1,000,000 * 1000) = 134999<br>
                     The result was rounded to the next smaller integer. Applying 1) to xemEquivalent gives (again after rounding) 72.<br>
-                    So the fee is 72 * 1.25 XEM = 90 XEM.</br></br></br></br></br></br></p>
+                    So the fee is 72 * 1.25 XEM = 90 XEM.<br/><br/><br/><br/><br/><br/></p>
 <p>3) Fees for appending a message to a transaction:<br/>
                     If no message or an empty message is append it costs
                     0 XEM. Else the fee is calculated as<br/>

Original file line number	Diff line number	Diff line change
`@@ -1,3 +1,4 @@`
	`1`	`+<!--suppress HtmlUnknownTag -->`
`1`	`2`	`<html>`
`2`	`3`
`3`	`4`	`<head>`