Markdownlint lint fixes batch #3

Author: muuki88

dev-docs/add-rtd-submodule.md

@@ -6,16 +6,17 @@ sidebarType: 1
 ---
 
 # How to Add a Real Time Data Submodule
+
 {:.no_toc}
 
 Sub-modules interact with the Real-Time Data (RTD) core module to
 add data to bid requests or add targeting values for the primary ad server.
 
-
 * TOC
 {:toc }
 
 ## Overview
+
 The point of the Real Time Data (RTD) infrastructure is to make configuration consistent for publishers. Rather than having dozens of different modules with disparate config approaches, being a Real-Time Data sub-module means plugging into a framework
 for publishers to control how sub-modules behave. For example, publishers can define how long the auction can be delayed and give some
 sub-modules priority over others.
@@ -40,13 +41,13 @@ Here is the flow for how the RTD-core module interacts with its sub-modules:
 The activities performed by the RTD-core module are on the left-hand side, while the functions
 that can be provided by your RTD sub-module are on the right-hand side. Note that you don't need to implement all of the functions - you'll want to plan out your functionality and develop the appropriate functions.
 
-
 ## Creating a Sub-Module
 
 When you create a Real-Time Data sub-module, you will be operating under the umbrella of the Real-Time Data core module. Here are the services core provides:
-- your sub-module will be initialized as soon as pbjs.setConfig({realTimeData}) is called. If you can initialize at the time of code load, that can be done at the bottom of your javascript file.
-- whenever any of your functions is called, it will be passed the config params provided by the publisher. As a result, you should not call getConfig().
-- your functions will also be passed all available privacy information. As a result, you do not need to query to get GDPR, US Privacy, or any other consent parameters.
+
+* your sub-module will be initialized as soon as pbjs.setConfig({realTimeData}) is called. If you can initialize at the time of code load, that can be done at the bottom of your javascript file.
+* whenever any of your functions is called, it will be passed the config params provided by the publisher. As a result, you should not call getConfig().
+* your functions will also be passed all available privacy information. As a result, you do not need to query to get GDPR, US Privacy, or any other consent parameters.
 
 Working with any Prebid project requires using Github. In general, we recommend the same basic workflow for any project:
 
@@ -65,7 +66,8 @@ with the [module rules](/dev-docs/module-rules.html) that apply globally and to
 Create a markdown file under `modules` with the name of the module suffixed with 'RtdProvider', e.g., `exRtdProvider.md`
 
 Example markdown file:
-{% highlight text %}
+
+```md
 # Overview
 
 Module Name: Ex Rtd Provider
@@ -90,7 +92,7 @@ In order to let RTD-core know where to find the functions in your sub-module, cr
 |  param name | type  | Scope | Description | Params |
 | :------------ | :------------ | :------ | :------ | :------ |
 | name  | string  | required | must match the name provided by the publisher in the on-page config | n/a |
-| gvlid | number | optional | global vendor list ID for your submodule | n/a | 
+| gvlid | number | optional | global vendor list ID for your submodule | n/a |
 | init | function | required | defines the function that does any auction-level initialization required | config, userConsent |
 | getTargetingData  | function | optional | defines a function that provides ad server targeting data to RTD-core | adUnitArray, config, userConsent |
 | getBidRequestData  | function | optional | defines a function that provides bid request data to RTD-core | reqBidsConfigObj, callback, config, userConsent  |
@@ -100,7 +102,8 @@ In order to let RTD-core know where to find the functions in your sub-module, cr
 | onBidResponseEvent | function |optional | listens to the BID_RESPONSE event and calls a sub-module function that lets it know when a bid response has been collected | bidResponse, config, userConsent |
 
 For example:
-{% highlight text %}
+
+```javascript
 export const subModuleObj = {
   name: 'ExampleRTDModule',
   init: init,
@@ -112,20 +115,22 @@ export const subModuleObj = {
 
 Register submodule to RTD-core:
 
-{% highlight text %}
+```javascript
 submodule('realTimeData', subModuleObject);
 ```
 
 #### User Consent
 
 Several of the interfaces get a `userConsent` object. It's an object that carries these attributes:
-- [gdpr](/dev-docs/modules/consentManagement.html#bidder-adapter-gdpr-integration) - GDPR
-- [usp](/dev-docs/modules/consentManagementUsp.html#bidder-adapter-us-privacy-integration) - US Privacy (aka CCPA)
-- [coppa](/dev-docs/publisher-api-reference/setConfig.html#setConfig-coppa) - the Child Online Privacy Protection Act
+
+* [gdpr](/dev-docs/modules/consentManagement.html#bidder-adapter-gdpr-integration) - GDPR
+* [usp](/dev-docs/modules/consentManagementUsp.html#bidder-adapter-us-privacy-integration) - US Privacy (aka CCPA)
+* [coppa](/dev-docs/publisher-api-reference/setConfig.html#setConfig-coppa) - the Child Online Privacy Protection Act
 
 These are provided so you can do the right thing with respect to regulations. The only privacy requirement imposed by the RTD-core is that sub-modules make make use of the StorageManager instead of attempting to access cookies or localstorage directly.
 
 #### The init() function
+
 1. This function receives module configuration and userConsent parameters
 2. If the function returns `false`, the submodule will be ignored.
 
@@ -137,7 +142,8 @@ This is the function that will allow RTD sub-modules to merge ad server targetin
 
 1. RTD-core will call this function with an array of adUnits, config, and userConsent as parameters
 2. Your sub-module should respond with per-adslot data that should be set as key values on the ad server targeting in this format:
-{% highlight text %}
+
+```json
 {
   "slotA":{
       "p":0.56,   // ad server targeting variable (e.g. p) for slotA is 0.56
@@ -150,7 +156,7 @@ This is the function that will allow RTD sub-modules to merge ad server targetin
 
 **Code Example**
 
-{% highlight text %}
+```javascript
 /** @type {RtdSubmodule} */
 export const subModuleObj = {
   name: 'ExampleRTDModule',
@@ -177,27 +183,27 @@ submodule('realTimeData', subModuleObj);
 This is the function that will allow RTD sub-modules to modify the AdUnit object for each auction. It's called as part of the requestBids hook.
 
 1. RTD-core will call this function with:
-    - reqBidsConfigObj: a slightly modified version of the object that's passed to `pbjs.requestBids` (see [below](#reqBidsConfigObj)). Note that several auctions can happen concurrently, so the sub-module must be ready to support this.
-    - callback: lets RTD-core know which auction the sub-module is done with.
-    - config: the sub-module's config params provided by the publisher
-    - userConsent object (see above)
+    1. reqBidsConfigObj: a slightly modified version of the object that's passed to `pbjs.requestBids` (see [below](#reqBidsConfigObj)). Note that several auctions can happen concurrently, so the sub-module must be ready to support this.
+    2. callback: lets RTD-core know which auction the sub-module is done with.
+    3. config: the sub-module's config params provided by the publisher
+    4. userConsent object (see above)
 2. Your sub-module may update the reqBidsConfigObj and hit the callback. To inject data into the bid requests, you should follow one of these conventions:
-    - Recommended: use one of these [First Party Data](/features/firstPartyData.html) conventions:
-        - For AdUnit-specific first party data, set AdUnit.ortb2Imp.ext.data.ATTRIBUTES
-        - For global first party data, including bidder-specific data, modify the `reqBidsConfigObj` as shown [below](#reqBidsConfigObj) 
-    - Not recommended: Place your data in bidRequest.rtd.RTDPROVIDERCODE.ATTRIBUTES and then get individual adapters to specifically read that location. Note that this method won't pass data to Prebid Server adapters.
+    1. Recommended: use one of these [First Party Data](/features/firstPartyData.html) conventions:
+        1. For AdUnit-specific first party data, set AdUnit.ortb2Imp.ext.data.ATTRIBUTES
+        2. For global first party data, including bidder-specific data, modify the `reqBidsConfigObj` as shown [below](#reqBidsConfigObj)
+    2. Not recommended: Place your data in bidRequest.rtd.RTDPROVIDERCODE.ATTRIBUTES and then get individual adapters to specifically read that location. Note that this method won't pass data to Prebid Server adapters.
 
-<a id="reqBidsConfigObj" />
+<a id="reqBidsConfigObj"></a>
 
 The `reqBidsConfigObj` parameter is a copy of the object passed to [`requestBids`](/dev-docs/publisher-api-reference/requestBids.html), except for:
 
-- `adUnits` and `timeout` are always defined (if the publisher didn't provide them, the default values are filled in - `pbjs.adUnits` and `getConfig('bidderTimeout')` respectively)
-- `ortb2` is replaced with an `ortb2Fragments` object, intended to be inspected and / or modified by your module.
+* `adUnits` and `timeout` are always defined (if the publisher didn't provide them, the default values are filled in - `pbjs.adUnits` and `getConfig('bidderTimeout')` respectively)
+* `ortb2` is replaced with an `ortb2Fragments` object, intended to be inspected and / or modified by your module.
 
 The `ortb2Fragments` parameter is an object containing two properties:
 
-- `global`, an object containing global (not bidder-specific) first party data in the same OpenRTB format used by `setConfig({ortb2})`
-- `bidder`, a map from bidder code to bidder-specific, OpenRTB-formatted first party data.
+* `global`, an object containing global (not bidder-specific) first party data in the same OpenRTB format used by `setConfig({ortb2})`
+* `bidder`, a map from bidder code to bidder-specific, OpenRTB-formatted first party data.
 
 Your module may modify either or both with additional data. If adding bidder-specific data in `ortb2Fragments.bidder`, it should also support a parameter to allow the publisher to define which bidders are to receive the data.
 
@@ -207,7 +213,7 @@ at the time `requestBids` is called, and RTD submodules that wish to modify it a
 
 **Code Example**
 
-{% highlight text %}
+```javascript
 /** @type {RtdSubmodule} */
 export const subModuleObj = {
   name: 'ExampleRTDModule2',
@@ -236,18 +242,21 @@ submodule('realTimeData', subModuleObj);
 ```
 
 #### beforeInit
+
 1. Use this function to take action to make sure data will be served as soon as possible (AJAX calls, pixels, etc..)
 2. This function is **not** invoked by the RTD module, and should be invoked at the bottom of the submodule.
 
 #### Using event listeners
+
 1. The RTD-core module listens for 3 events - `AUCTION_INIT`, `AUCTION_END`, and `BID_RESPONSE`.
 2. Each time one of the events fires, RTD-core will invoke the corresponding function on each sub-module, allowing the sub-module to make changes to the event object.
 3. To use this on your sub-module, define the required functions as noted in the table above and the examples below.
 
 **Code Example**
 
 Here is a code example with both mandatory and optional functions:
-{% highlight text %}
+
+```javascript
 /** @type {RtdSubmodule} */
 export const subModuleObj = {
   name: 'ExampleRTDModule3',
@@ -288,7 +297,6 @@ function beforeInit(){
 beforeInit();
 ```
 
-
 ### Step 3: Add unit tests
 
 1. Create a JS file under `test/spec/modules` with the name of the bidder suffixed with 'RtdProvider_spec', e.g., `exRtdProvider_spec.js`
@@ -305,7 +313,7 @@ Once everything looks good, submit the code, tests, and markdown as a pull reque
 
 2. Create a new file for your RTD sub-module in dev-docs/modules/ExampleRtdProvider.md. Take a look at the other *RtdProvider.md files in that directory for the important header values. Specifically it requires the following:
 
-    ```
+    ```markdown
     ---
     layout: page_v2
     title: Example Module
@@ -322,6 +330,7 @@ Once everything looks good, submit the code, tests, and markdown as a pull reque
 
     [Useful publisher-facing documentation]
     ```
+
 3. Submit the pull request to the prebid.github.io repo.
 
 ### Step 6: Wait for Prebid volunteers to review

dev-docs/add-video-submodule.md

@@ -9,10 +9,10 @@ sidebarType: 1
 {:.no_toc}
 
 Video submodules interact with the Video Module to integrate Prebid with Video Players, allowing Prebid to automatically:
-- render bids in the desired video player.
-- mark used bids as won.
-- trigger player and media events.
-- populate the oRTB Video Impression and Content params in the bid request.
+* render bids in the desired video player.
+* mark used bids as won.
+* trigger player and media events.
+* populate the oRTB Video Impression and Content params in the bid request.
 
 * TOC
 {:toc }
@@ -28,11 +28,12 @@ Publishers who use players from different vendors on the same page can use multi
 ## Requirements
 
 The Video Module only supports integration with Video Players that meet the following requirements:
-- Must support parsing and reproduction of VAST ads.
-  - Input can be an ad tag URL or the actual Vast XML.
-- Must expose an API that allows the procurement of [Open RTB params](https://www.iab.com/wp-content/uploads/2016/03/OpenRTB-API-Specification-Version-2-5-FINAL.pdf) for Video (section 3.2.7) and Content (section 3.2.16).
-- Must emit javascript events for Ads and Media.
-  - see [Event Registration](#event-registration).
+
+* Must support parsing and reproduction of VAST ads.
+  * Input can be an ad tag URL or the actual Vast XML.
+* Must expose an API that allows the procurement of [Open RTB params](https://www.iab.com/wp-content/uploads/2016/03/OpenRTB-API-Specification-Version-2-5-FINAL.pdf) for Video (section 3.2.7) and Content (section 3.2.16).
+* Must emit javascript events for Ads and Media.
+  * see [Event Registration](#event-registration).
 
 ## Creating a Submodule
 
@@ -49,7 +50,8 @@ Working with any Prebid project requires using Github. In general, we recommend
 Create a markdown file under `modules` with the name of the module suffixed with 'VideoProvider', i.e. `exampleVideoProvider.md`.
 
 Example markdown file:
-{% highlight text %}
+
+```md
 # Overview
 
 Module Name: Example Video Provider
@@ -73,7 +75,7 @@ Your page must link the Example Player build from our CDN. Alternatively you can
 Vendor codes are required to indicate which submodule type to instantiate. Add your vendor code constant to an export const in `vendorCodes.js` in Prebid.js under `libraries/video/constants/vendorCodes.js`.
 i.e. in `vendorCodes.js`:
 
-{% highlight text %}
+```javascript
 export const EXAMPLE_PLAYER_VENDOR = 3;
 ```
 
@@ -89,7 +91,7 @@ Your submodule should also import the `submodule` function from `src/hook.js` an
 
 **Code Example**
 
-{% highlight text %}
+```javascript
 import { submodule } from '../src/hook.js';
 
 function exampleSubmoduleFactory(videoProviderConfig) {
@@ -121,7 +123,8 @@ The submodule object must adhere to the following interface:
 | destroy | function | required | Deallocates the submodule and destroys the associated video player. n/a | void | void |
 
 For example:
-{% highlight text %}
+
+```javascript
 const exampleSubmodule =  {
   init: init,
   getId: getId,
@@ -134,7 +137,7 @@ const exampleSubmodule =  {
 };
 ```
 
-<a name="event-registration" />
+<a name="event-registration"></a>
 
 #### Event Registration
 
@@ -158,7 +161,8 @@ Submodules must support attaching and detaching event listeners on the video pla
 #### Update .submodules.json
 
 In prebid.js, add your new submodule to `.submodules.json` under the `videoModule` as such:
-{% highlight text %}
+
+```json
 {
   "parentModules": {
     "videoModule": [

dev-docs/bidder-adaptor.md

@@ -9,6 +9,7 @@ sidebarType: 1
 
 
 # How to Add a New Prebid.js Bidder Adapter
+
 {:.no_toc}
 
 At a high level, a bidder adapter is responsible for:
@@ -23,10 +24,10 @@ This page has instructions for writing your own bidder adapter.  The instruction
 
 ## Planning your Adapter
 
-+ [Required Adapter Rules](#bidder-adaptor-Required-Adapter-Conventions)
-+ [Required Files](#bidder-adaptor-Required-Files)
-+ [Designing your Bid Params](#bidder-adaptor-Designing-your-Bid-Params)
-+ [HTTP Simple Requests](#bidder-adaptor-HTTP-simple-requests)
+* [Required Adapter Rules](#bidder-adaptor-Required-Adapter-Conventions)
+* [Required Files](#bidder-adaptor-Required-Files)
+* [Designing your Bid Params](#bidder-adaptor-Designing-your-Bid-Params)
+* [HTTP Simple Requests](#bidder-adaptor-HTTP-simple-requests)
 
 <a name="bidder-adaptor-Required-Adapter-Conventions" />
 
@@ -43,24 +44,24 @@ In order to provide a fast and safe header bidding environment for publishers, t
 {: .alert.alert-danger :}
 The above list is **not** the full list of requirements. Failure to follow any of the required conventions defined in the [Module Rules](/dev-docs/module-rules.html) could lead to delays in approving your adapter for inclusion in Prebid.js. If you'd like to apply for an exception to one of the rules, make your request in a new [Prebid.js issue](https://github.com/prebid/Prebid.js/issues).
 
-<a name="bidder-adaptor-Required-Files" />
+<a name="bidder-adaptor-Required-Files"></a>
 
 ### Required Files
 
 With each adapter submission, there are two files required to be in the pull request:
 
 * `modules/exampleBidAdapter.js`: the file containing the code for the adapter
 * `modules/exampleBidAdapter.md`: a markdown file containing key information about the adapter:
-   * The contact email of the adapter's maintainer.
-   * A test ad unit that will consistently return test creatives. This helps us to ensure future Prebid.js updates do not break your adapter.  Note that if your adapter supports video (instream and/or outstream context) or native, you must also provide example parameters for each type.
+  * The contact email of the adapter's maintainer.
+  * A test ad unit that will consistently return test creatives. This helps us to ensure future Prebid.js updates do not break your adapter.  Note that if your adapter supports video (instream and/or outstream context) or native, you must also provide example parameters for each type.
 
 Example markdown file:
 
-{% highlight text %}
+```md
 
 # Overview
 
-```
+```markdown
 Module Name: Example Bidder Adapter
 Module Type: Bidder Adapter
 Maintainer: [email protected]
@@ -71,7 +72,8 @@ Maintainer: [email protected]
 Module that connects to Example's demand sources
 
 # Test Parameters
-```
+
+```javascript
     var adUnits = [
         {
             code: 'test-div',
@@ -188,11 +190,11 @@ If you're the type that likes to skip to the answer instead of going through a t
 {: .alert.alert-warning :}
 If your adapter interfaces with an ORTB backend, you may take advantage of Prebid's [ORTB conversion library](https://github.com/prebid/Prebid.js/blob/master/libraries/ortbConverter/README.md), which provides most of the implementation for `buildRequests` and `interpretResponse`. 
 
-+ [Overview](#bidder-adaptor-Overview)
-+ [Building the Request](#bidder-adaptor-Building-the-Request)
-+ [Interpreting the Response](#bidder-adaptor-Interpreting-the-Response)
-+ [Registering User Syncs](#bidder-adaptor-Registering-User-Syncs)
-+ [Registering on Timeout](#bidder-adaptor-Registering-on-Timout)
+* [Overview](#bidder-adaptor-Overview)
+* [Building the Request](#bidder-adaptor-Building-the-Request)
+* [Interpreting the Response](#bidder-adaptor-Interpreting-the-Response)
+* [Registering User Syncs](#bidder-adaptor-Registering-User-Syncs)
+* [Registering on Timeout](#bidder-adaptor-Registering-on-Timout)
 
 <a name="bidder-adaptor-Overview" />
 
@@ -1317,5 +1319,5 @@ The Prebid.org [download page](/download.html) will automatically be updated wit
 
 ## Further Reading
 
-+ [Prebid.js Repo - Bidder Adapter Sources](https://github.com/prebid/Prebid.js/tree/master/modules)
-+ [Module Rules](/dev-docs/module-rules.html)
+* [Prebid.js Repo - Bidder Adapter Sources](https://github.com/prebid/Prebid.js/tree/master/modules)
+* [Module Rules](/dev-docs/module-rules.html)