Remove inline HTML for images (#98)

* Remove inline HTML for images. Also using relative paths for images will enable mkdocs to give build-time warnings about any missing images or incorrect image paths. * More relative image paths
decred · Sep 15, 2021 · 4440d33 · 4440d33
1 parent 65f1099
commit 4440d33
Show file tree

Hide file tree

Showing 30 changed files with 52 additions and 51 deletions.
diff --git a/docs/contributing/contributor-guidelines.md b/docs/contributing/contributor-guidelines.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Question.svg" /> Contributor Guidelines
+# ![](../img/dcr-icons/Question.svg){ .dcr-icon } Contributor Guidelines
 
 ---
 

diff --git a/docs/core-blockchain-concepts/blockchain.md b/docs/core-blockchain-concepts/blockchain.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Blocks.svg" /> Blockchain
+# ![](../img/dcr-icons/Blocks.svg){ .dcr-icon } Blockchain
 
 ---
 
@@ -9,7 +9,7 @@ chain, and that those blocks conform to the consensus rules.
 
 Below is a high-level diagram of the Decred blockchain.
 
-![Block Chain Overview](/img/core-blockchain-concepts/blockchain-overview.svg)
+![Block Chain Overview](../img/core-blockchain-concepts/blockchain-overview.svg)
 
 A block of one or more new transactions (Block 1) is collected into
 the transaction data part of a block. These transactions are then
@@ -31,7 +31,7 @@ The input of one transaction is the output of a previous transaction.
 Below is a high-level diagram of atoms (the smallest unit of DCR)
 being propagated through a series of transactions.
 
-![Transaction Propagation](/img/core-blockchain-concepts/transaction-propagation.svg)
+![Transaction Propagation](../img/core-blockchain-concepts/transaction-propagation.svg)
 
 A transaction can create multiple outputs.
 However, each output can only be used as an input once.

diff --git a/docs/core-blockchain-concepts/proof-of-stake/stake-enabled-height.md b/docs/core-blockchain-concepts/proof-of-stake/stake-enabled-height.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/TicketLive.svg" /> Stake Enabled Height
+# ![](../../img/dcr-icons/TicketLive.svg){ .dcr-icon } Stake Enabled Height
 
 ---
 

diff --git a/docs/core-blockchain-concepts/proof-of-stake/stake-validation-height.md b/docs/core-blockchain-concepts/proof-of-stake/stake-validation-height.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/TicketLive.svg" /> Stake Validation Height
+# ![](../../img/dcr-icons/TicketLive.svg){ .dcr-icon } Stake Validation Height
 
 ---
 

diff --git a/docs/developer-guides/addresses.md b/docs/developer-guides/addresses.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Transactions.svg" /> Address Details
+# ![](../img/dcr-icons/Transactions.svg){ .dcr-icon } Address Details
 
 ---
 
@@ -38,4 +38,4 @@ The table below provides the locking script and prefix details for each address
 
 When hashing a public key to generate an address (e.g. a Pay-to-PubkeyHash (P2PKH) address), Decred uses blake256r14 instead of SHA-256. The full algorithm to create an address is blake256r14+ripemd160+base58, as illustrated below.
 
-![How a P2PKH address is generated](/img/p2pkh_address_gen.svg)
+![How a P2PKH address is generated](../img/p2pkh_address_gen.svg)
diff --git a/docs/developer-guides/block-header-specifications.md b/docs/developer-guides/block-header-specifications.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/BlockHeader.svg" /> Block Header Specifications
+# ![](../img/dcr-icons/BlockHeader.svg){ .dcr-icon } Block Header Specifications
 
 ---
 

diff --git a/docs/developer-guides/blockchain-parameters.md b/docs/developer-guides/blockchain-parameters.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Blocks.svg" /> Blockchain Parameters
+# ![](../img/dcr-icons/Blocks.svg){ .dcr-icon } Blockchain Parameters
 
 ---
 

diff --git a/docs/developer-guides/merkle-root-construction.md b/docs/developer-guides/merkle-root-construction.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Code.svg" /> Merkle Root Construction
+# ![](../img/dcr-icons/Code.svg){ .dcr-icon } Merkle Root Construction
 
 ---
 
@@ -11,7 +11,7 @@ A Merkle tree is a data structure that can be used to store hashes of arbitrary
 
 Merkle trees are created by repeatedly hashing pairs of nodes until there is only one hash left, the Merkle Root. They are constructed from the bottom up, from hashes of the leaf nodes (hashes of the raw input data). The diagram below shows a Merkle root constructed from eight leaf nodes. 
 
-![Merkle Tree](/img/core-blockchain-concepts/merkle_tree.svg)
+![Merkle Tree](../img/core-blockchain-concepts/merkle_tree.svg)
 
 Merkle trees are particularly useful for blockchains, as they efficiently and compactly summarize larger data sets.
 
@@ -42,7 +42,7 @@ All Merkle trees **must** be constructed according to the unique Merkle tree con
 
 The below diagram illustrates these steps.
 
-![Merkle Tree Calculation](/img/core-blockchain-concepts/merkle_root_calc.svg)
+![Merkle Tree Calculation](../img/core-blockchain-concepts/merkle_root_calc.svg)
 
 
 

diff --git a/docs/developer-guides/reproducible-builds.md b/docs/developer-guides/reproducible-builds.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Code.svg" /> Reproducible Builds
+# ![](../img/dcr-icons/Code.svg){ .dcr-icon } Reproducible Builds
 
 ---
 

diff --git a/docs/developer-guides/script-extensions.md b/docs/developer-guides/script-extensions.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Code.svg" /> Script Extensions
+# ![](../img/dcr-icons/Code.svg){ .dcr-icon } Script Extensions
 
 ---
 
@@ -13,7 +13,7 @@ Some longstanding bugs in the Bitcoin scripting language have been also been fix
 
 ---
 
-## <img class="dcr-icon" src="/img/dcr-icons/Sources.svg" /> References
+## ![](../img/dcr-icons/Sources.svg){ .dcr-icon } References
 
 [^1]: Wuille P. 2015. [Segregated witness for Bitcoin](https://prezi.com/lyghixkrguao/segregated-witness-and-deploying-it-for-bitcoin/).
 [^2]: Todd P. [The difficulty of writing consensus critical code: The SIGHASH_SINGLE bug](https://decred.org/research/todd2014.pdf).

diff --git a/docs/developer-guides/ticket-selection.md b/docs/developer-guides/ticket-selection.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/QuestionTicket.svg" /> Ticket Selection
+# ![](../img/dcr-icons/QuestionTicket.svg){ .dcr-icon } Ticket Selection
 
 ---
 

diff --git a/docs/developer-guides/transactions/transaction-extensions.md b/docs/developer-guides/transactions/transaction-extensions.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Transactions.svg" /> Transactions Extensions
+# ![](../../img/dcr-icons/Transactions.svg){ .dcr-icon } Transactions Extensions
 
 ---
 
@@ -8,6 +8,6 @@ the only way to remove a transaction from the mempool was to double spend it.
 
 ---
 
-## <img class="dcr-icon" src="/img/dcr-icons/Sources.svg" /> References
+## ![](../../img/dcr-icons/Sources.svg){ .dcr-icon } References
 
 [^1]: ByteCoin. 2010. [Need OP_BLOCKNUMBER to allow "time" limited transactions](https://decred.org/research/bytecoin2010.pdf).
diff --git a/docs/developer-guides/transactions/transaction-format.md b/docs/developer-guides/transactions/transaction-format.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Transactions.svg" /> Transaction Format
+# ![](../../img/dcr-icons/Transactions.svg){ .dcr-icon } Transaction Format
 
 ---
 

diff --git a/docs/developer-guides/transactions/transactions.md b/docs/developer-guides/transactions/transactions.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Transactions.svg" /> Transactions
+# ![](../../img/dcr-icons/Transactions.svg){ .dcr-icon } Transactions
 
 ---
 

diff --git a/docs/developer-guides/transactions/txscript/opcodes.md b/docs/developer-guides/transactions/txscript/opcodes.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Code.svg" /> Opcodes
+# ![](../../../img/dcr-icons/Code.svg){ .dcr-icon } Opcodes
 
 The complete txscript language includes over 100 operation codes, or opcodes,
 however only a small number of these are used in the vast majority of the

diff --git a/docs/developer-guides/transactions/txscript/overview.md b/docs/developer-guides/transactions/txscript/overview.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Code.svg" /> txscript
+# ![](../../../img/dcr-icons/Code.svg){ .dcr-icon } txscript
 
 ---
 
@@ -71,22 +71,22 @@ just uses some small integers.
 This script contains five instructions, which will be executed as follows:
 
 1. The value 6 is pushed onto the stack
-  ![Simple addition step 1](/img/txscript/addition-1.png)
+  ![Simple addition step 1](../../../img/txscript/addition-1.png)
 
 1. The value 5 is pushed onto the stack
-  ![Simple addition step 2](/img/txscript/addition-2.png)
+  ![Simple addition step 2](../../../img/txscript/addition-2.png)
 
 1. `OP_ADD` pops the top two values from the stack, adds them together, and pushes
    the result, 11, onto the stack
-  ![Simple addition step 3](/img/txscript/addition-3.png)
+  ![Simple addition step 3](../../../img/txscript/addition-3.png)
 
 1. The value 12 is pushed onto the stack
-  ![Simple addition step 4](/img/txscript/addition-4.png)
+  ![Simple addition step 4](../../../img/txscript/addition-4.png)
 
 1. `OP_EQUAL` pops the top two values from the stack, compares them, and pushes 0
    (false) onto the stack. If the values were equal, 1 (true) would be pushed
    instead.
-  ![Simple addition step 5](/img/txscript/addition-5.png)
+  ![Simple addition step 5](../../../img/txscript/addition-5.png)
 
 ---
 

diff --git a/docs/developer-guides/wallets/deterministic-wallet-formats.md b/docs/developer-guides/wallets/deterministic-wallet-formats.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Wallet.svg" /> Deterministic Wallet Formats
+# ![](../../img/dcr-icons/Wallet.svg){ .dcr-icon } Deterministic Wallet Formats
 
 ---
 
@@ -14,7 +14,7 @@ In HD wallets, a special parent seed based on [BIP0032](https://en.bitcoin.it/wi
 
 Below is a diagram showing how child private keys are generated from the parent seed. 
 
-![HD wallet overview](/img/hd-overview.svg)
+![HD wallet overview](../../img/hd-overview.svg)
 
 dcrd provides an API for generating and interacting with HD extended keys via the hdkeychain package. Documentation for hdkeychain can be found [here](https://github.com/decred/dcrd/blob/3e2208f8c1d123841919221734ec463ef3ece544/hdkeychain/README.md).
 
diff --git a/docs/developer-guides/wallets/mnemonic-seed.md b/docs/developer-guides/wallets/mnemonic-seed.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Wallet.svg" /> Seed Generation Process
+# ![](../../img/dcr-icons/Wallet.svg){ .dcr-icon } Seed Generation Process
 
 ---
 
@@ -10,4 +10,4 @@ The mnemonic seed generation process can be understood in three steps:
 1. Create a checksum by hashing the seed with SHA-256d, and append the first byte of the hash to the initial seed.
 1. Look up each of the 33 bytes on the [PGP Word List](https://en.wikipedia.org/wiki/PGP_word_list); (a list of 512 words split into 256 even and odd phonetically distinct words), using even words for even bytes and odd words for odd bytes. 
 
-![Decred mnemonic seed process](/img/seedgen.svg)
+![Decred mnemonic seed process](../../img/seedgen.svg)
diff --git a/docs/developer-guides/wallets/overview.md b/docs/developer-guides/wallets/overview.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Wallet.svg" /> Wallets
+# ![](../../img/dcr-icons/Wallet.svg){ .dcr-icon } Wallets
 
 ---
 

diff --git a/docs/environments/mainnet.md b/docs/environments/mainnet.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Dcrtl.svg" /> Mainnet
+# ![](../img/dcr-icons/Dcrtl.svg){ .dcr-icon } Mainnet
 
 ---
 

diff --git a/docs/environments/regnet.md b/docs/environments/regnet.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Dcrtl.svg" /> Regnet
+# ![](../img/dcr-icons/Dcrtl.svg){ .dcr-icon } Regnet
 
 ---
 

diff --git a/docs/environments/simnet.md b/docs/environments/simnet.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Dcrtl.svg" /> Simnet
+# ![](../img/dcr-icons/Dcrtl.svg){ .dcr-icon } Simnet
 
 ---
 
@@ -32,7 +32,7 @@ The following is an overview of the most important properties that distinguish s
 
 ---
 
-## <img class="dcr-icon" src="/img/dcr-icons/AtoB.svg" /> Getting Started
+## ![](../img/dcr-icons/AtoB.svg){ .dcr-icon } Getting Started
 
 Running a single `dcrd` node on simnet is simply starting `dcrd` with the `--simnet` flag.
 However, in order to be really useful, you'll typically want to be able to send coins amongst addresses which implies that blocks will need to be mined and interfacing with a wallet will be needed.

diff --git a/docs/environments/testnet.md b/docs/environments/testnet.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Dcrtl.svg" /> Testnet
+# ![](../img/dcr-icons/Dcrtl.svg){ .dcr-icon } Testnet
 
 ---
 

diff --git a/docs/projects.md b/docs/projects.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Info.svg" /> Projects
+# ![](img/dcr-icons/Info.svg){ .dcr-icon } Projects
 
 All projects listed on this page are currently in active development.
 All projects are open source with their source code available on GitHub.

diff --git a/docs/protocol-p2p-network/initial-block-download.md b/docs/protocol-p2p-network/initial-block-download.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Blocks.svg" /> Initial Block Download
+# ![](../img/dcr-icons/Blocks.svg){ .dcr-icon } Initial Block Download
 
 ---
 
@@ -26,15 +26,15 @@ dcrd uses a simple IBD method called *blocks-first*.
 The goal is to download the blocks from the best block chain in sequence.
 Below is a high-level diagram of the blocks-first method.
 
-![Overview Of Blocks-First Method](/img/protocol-p2p-network/en-blocks-first-flowchart.svg)
+![Overview Of Blocks-First Method](../img/protocol-p2p-network/en-blocks-first-flowchart.svg)
 
 The first time a node is started, it only has a single block in its
 local best block chain, the hardcoded genesis block (block 0).
 We will refer to this as the "IBD node".
 This node chooses a remote peer, called the "sync node", and sends it the
 `getblocks` message illustrated below.
 
-![First GetBlocks Message Sent During IBD](/img/protocol-p2p-network/en-ibd-getblocks.svg)
+![First GetBlocks Message Sent During IBD](../img/protocol-p2p-network/en-ibd-getblocks.svg)
 
 In the header hashes field in the payload of the `getblocks` message, this new node
 sends the header hash of the only block it has, the genesis block
@@ -48,7 +48,7 @@ replies with 500 block inventories (the maximum response to a
 `getblocks` message) starting from block 1. It sends these inventories
 in the inventory (`inv`) message illustrated below.
 
-![First Inv Message Sent During IBD](/img/protocol-p2p-network/en-ibd-inv.svg)
+![First Inv Message Sent During IBD](../img/protocol-p2p-network/en-ibd-inv.svg)
 
 Inventories are unique identifiers for information on the network. Each
 inventory contains a type field and the unique identifier for an
@@ -65,7 +65,7 @@ hash of block 1 (4860…0000).
 The IBD node uses the received inventories to request 128 blocks from
 the sync node in the `getdata` message illustrated below.
 
-![First GetData Message Sent During IBD](/img/protocol-p2p-network/en-ibd-getdata.svg)
+![First GetData Message Sent During IBD](../img/protocol-p2p-network/en-ibd-getdata.svg)
 
 It's important to blocks-first nodes that the blocks be requested and
 sent in order because each block header references the header hash of
@@ -79,7 +79,7 @@ of the blocks requested. Each block is put into serialized block format
 and sent in a separate `block` message. The first `block` message sent
 (for block 1) is illustrated below.
 
-![First Block Message Sent During IBD](/img/protocol-p2p-network/en-ibd-block.svg)
+![First Block Message Sent During IBD](../img/protocol-p2p-network/en-ibd-block.svg)
 
 The IBD node downloads each block, validates it, and then requests the
 next block it hasn't requested yet, maintaining a queue of up to 128
@@ -89,7 +89,7 @@ requesting the inventories of up to 500 more blocks.  This second
 `getblocks` message contains multiple header hashes as illustrated
 below:
 
-![Second GetBlocks Message Sent During IBD](/img/protocol-p2p-network/en-ibd-getblocks2.svg)
+![Second GetBlocks Message Sent During IBD](../img/protocol-p2p-network/en-ibd-getblocks2.svg)
 
 Upon receipt of the second `getblocks` message, the sync node searches
 its local best block chain for a block that matches one of the header

diff --git a/docs/protocol-p2p-network/memory-pool.md b/docs/protocol-p2p-network/memory-pool.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Pool.svg" /> Memory Pool
+# ![](../img/dcr-icons/Pool.svg){ .dcr-icon } Memory Pool
 
 ---
 

diff --git a/docs/protocol-p2p-network/orphan-blocks.md b/docs/protocol-p2p-network/orphan-blocks.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Blocks.svg" /> Orphan Blocks
+# ![](../img/dcr-icons/Blocks.svg){ .dcr-icon } Orphan Blocks
 
 ---
 
@@ -8,7 +8,7 @@ hasn't seen yet. In other words, orphan blocks have no known parent
 (unlike stale blocks, which have known parents but which aren't part of
 the best block chain).
 
-![Difference Between Orphan And Stale Blocks](/img/protocol-p2p-network/en-orphan-stale-definition.svg)
+![Difference Between Orphan And Stale Blocks](../img/protocol-p2p-network/en-orphan-stale-definition.svg)
 
 When dcrd downloads an orphan block, it will not validate
 it. Instead, it will send a `getblocks` message to the node which sent

diff --git a/docs/protocol-p2p-network/peer-discovery.md b/docs/protocol-p2p-network/peer-discovery.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/AtoB.svg" /> Peer Discovery
+# ![](../img/dcr-icons/AtoB.svg){ .dcr-icon } Peer Discovery
 
 ---
 

diff --git a/docs/protocol-p2p-network/transaction-broadcasting.md b/docs/protocol-p2p-network/transaction-broadcasting.md
@@ -1,4 +1,4 @@
-# <img class="dcr-icon" src="/img/dcr-icons/Transactions.svg" /> Transaction Broadcasting
+# ![](../img/dcr-icons/Transactions.svg){ .dcr-icon } Transaction Broadcasting
 
 ---
 

diff --git a/mkdocs.yml b/mkdocs.yml
@@ -65,6 +65,7 @@ markdown_extensions:
   - markdown.extensions.toc:
       permalink: True
   - markdown.extensions.tables
+  - markdown.extensions.attr_list
   - pymdownx.details
   - pymdownx.emoji:
       emoji_index: !!python/name:materialx.emoji.twemoji