Make unordered lists conform to styleguide

- Also makes other minor Markdown fixes that were near the main fixes.

doc/administration/high_availability/redis.md

@@ -545,10 +545,10 @@ discussed in [Redis setup overview](#redis-setup-overview) and
 Here is a list and description of each **machine** and the assigned **IP**:
-* `10.0.0.1`: Redis Master + Sentinel 1
-* `10.0.0.2`: Redis Slave 1 + Sentinel 2
-* `10.0.0.3`: Redis Slave 2 + Sentinel 3
-* `10.0.0.4`: GitLab application
+- `10.0.0.1`: Redis Master + Sentinel 1
+- `10.0.0.2`: Redis Slave 1 + Sentinel 2
+- `10.0.0.3`: Redis Slave 2 + Sentinel 3
+- `10.0.0.4`: GitLab application
 Please note that after the initial configuration, if a failover is initiated
 by the Sentinel nodes, the Redis nodes will be reconfigured and the **Master**

doc/administration/high_availability/redis_source.md

@@ -214,10 +214,10 @@ For this example, **Sentinel 1** will be configured in the same machine as the
 Here is a list and description of each **machine** and the assigned **IP**:
-* `10.0.0.1`: Redis Master + Sentinel 1
-* `10.0.0.2`: Redis Slave 1 + Sentinel 2
-* `10.0.0.3`: Redis Slave 2 + Sentinel 3
-* `10.0.0.4`: GitLab application
+- `10.0.0.1`: Redis Master + Sentinel 1
+- `10.0.0.2`: Redis Slave 1 + Sentinel 2
+- `10.0.0.3`: Redis Slave 2 + Sentinel 3
+- `10.0.0.4`: GitLab application
 Please note that after the initial configuration, if a failover is initiated
 by the Sentinel nodes, the Redis nodes will be reconfigured and the **Master**

doc/administration/housekeeping.md

@@ -17,19 +17,18 @@ The housekeeping function will run a `repack` or `gc` depending on the
 For example in the following scenario a `git repack -d` will be executed:
-+ Project: pushes since gc counter (`pushes_since_gc`) = `10`
-+ Git GC period = `200`
-+ Full repack period = `50`
+- Project: pushes since gc counter (`pushes_since_gc`) = `10`
+- Git GC period = `200`
+- Full repack period = `50`
 When the `pushes_since_gc` value is 50 a `repack -A -d --pack-kept-objects` will run, similarly when
 the `pushes_since_gc` value is 200 a `git gc` will be run.
-+ `git gc` ([man page][man-gc]) runs a number of housekeeping tasks,
-such as compressing filerevisions (to reduce disk space and increase performance)
-and removing unreachable objects which may have been created from prior invocations of
-`git add`. 
-
-+ `git repack` ([man page][man-repack]) re-organize existing packs into a single, more efficient pack.
+- `git gc` ([man page][man-gc]) runs a number of housekeeping tasks,
+  such as compressing filerevisions (to reduce disk space and increase performance)
+  and removing unreachable objects which may have been created from prior invocations of
+  `git add`.
+- `git repack` ([man page][man-repack]) re-organize existing packs into a single, more efficient pack.
 You can find this option under your **[Project] > Edit Project**.
@@ -39,4 +38,4 @@ You can find this option under your **[Project] > Edit Project**.
 [ce-2371]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2371 "Housekeeping merge request"
 [man-gc]: https://www.kernel.org/pub/software/scm/git/docs/git-gc.html "git gc man page"
-[man-repack]: https://www.kernel.org/pub/software/scm/git/docs/git-repack.html
\ No newline at end of file
+[man-repack]: https://www.kernel.org/pub/software/scm/git/docs/git-repack.html

doc/administration/integration/terminal.md

@@ -14,17 +14,17 @@ A detailed overview of the architecture of web terminals and how they work
 can be found in [this document](https://gitlab.com/gitlab-org/gitlab-workhorse/blob/master/doc/terminal.md).
 In brief:
-* GitLab relies on the user to provide their own Kubernetes credentials, and to
+- GitLab relies on the user to provide their own Kubernetes credentials, and to
   appropriately label the pods they create when deploying.
-* When a user navigates to the terminal page for an environment, they are served
+- When a user navigates to the terminal page for an environment, they are served
   a JavaScript application that opens a WebSocket connection back to GitLab.
-* The WebSocket is handled in [Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse),
+- The WebSocket is handled in [Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse),
    rather than the Rails application server.
-* Workhorse queries Rails for connection details and user permissions; Rails
-  queries Kubernetes for them in the background, using [Sidekiq](../troubleshooting/sidekiq.md)
-* Workhorse acts as a proxy server between the user's browser and the Kubernetes
+- Workhorse queries Rails for connection details and user permissions. Rails
+  queries Kubernetes for them in the background using [Sidekiq](../troubleshooting/sidekiq.md).
+- Workhorse acts as a proxy server between the user's browser and the Kubernetes
   API, passing WebSocket frames between the two.
-* Workhorse regularly polls Rails, terminating the WebSocket connection if the
+- Workhorse regularly polls Rails, terminating the WebSocket connection if the
   user no longer has permission to access the terminal, or if the connection
   details have changed.
@@ -40,10 +40,10 @@ However, if you run a [load balancer](../high_availability/load_balancer.md) in
 front of GitLab, you may need to make some changes to your configuration. These
 guides document the necessary steps for a selection of popular reverse proxies:
-* [Apache](https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html)
-* [NGINX](https://www.nginx.com/blog/websocket-nginx/)
-* [HAProxy](http://blog.haproxy.com/2012/11/07/websockets-load-balancing-with-haproxy/)
-* [Varnish](https://www.varnish-cache.org/docs/4.1/users-guide/vcl-example-websockets.html)
+- [Apache](https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html)
+- [NGINX](https://www.nginx.com/blog/websocket-nginx/)
+- [HAProxy](http://blog.haproxy.com/2012/11/07/websockets-load-balancing-with-haproxy/)
+- [Varnish](https://www.varnish-cache.org/docs/4.1/users-guide/vcl-example-websockets.html)
 Workhorse won't let WebSocket requests through to non-WebSocket endpoints, so
 it's safe to enable support for these headers globally. If you'd rather had a
@@ -60,8 +60,8 @@ the `Connection` and `Upgrade` hop-by-hop headers in the *first* HTTP reverse
 proxy in the chain. For most users, this will be the NGINX server bundled with
 Omnibus GitLab, in which case, you need to:
-* Find the `nginx['proxy_set_headers']` section of your `gitlab.rb` file
-* Ensure the whole block is uncommented, and then comment out or remove the
+- Find the `nginx['proxy_set_headers']` section of your `gitlab.rb` file
+- Ensure the whole block is uncommented, and then comment out or remove the
   `Connection` and `Upgrade` lines.
 For your own load balancer, just reverse the configuration changes recommended

doc/administration/raketasks/check.md

@@ -52,9 +52,9 @@ and these checks will verify them against current files.
 Currently, integrity checks are supported for the following types of file:
-* CI artifacts (Available from version 10.7.0)
-* LFS objects (Available from version 10.6.0)
-* User uploads (Available from version 10.6.0)
+- CI artifacts (Available from version 10.7.0)
+- LFS objects (Available from version 10.6.0)
+- User uploads (Available from version 10.6.0)
 **Omnibus Installation**

doc/administration/repository_storage_types.md

@@ -7,8 +7,8 @@
 Legacy Storage is the storage behavior prior to version 10.0. For historical
 reasons, GitLab replicated the same mapping structure from the projects URLs:
-* Project's repository: `#{namespace}/#{project_name}.git`
-* Project's wiki: `#{namespace}/#{project_name}.wiki.git`
+- Project's repository: `#{namespace}/#{project_name}.git`
+- Project's wiki: `#{namespace}/#{project_name}.wiki.git`
 This structure made it simple to migrate from existing solutions to GitLab and
 easy for Administrators to find where the repository is stored.

doc/administration/troubleshooting/debug.md

@@ -211,5 +211,5 @@ The output in `/tmp/unicorn.txt` may help diagnose the root cause.
 # More information
-* [Debugging Stuck Ruby Processes](https://blog.newrelic.com/2013/04/29/debugging-stuck-ruby-processes-what-to-do-before-you-kill-9/)
-* [Cheatsheet of using gdb and ruby processes](gdb-stuck-ruby.txt)
+- [Debugging Stuck Ruby Processes](https://blog.newrelic.com/2013/04/29/debugging-stuck-ruby-processes-what-to-do-before-you-kill-9/)
+- [Cheatsheet of using gdb and ruby processes](gdb-stuck-ruby.txt)

doc/api/lint.md

@@ -20,7 +20,7 @@ Be sure to copy paste the exact contents of `.gitlab-ci.yml` as YAML is very pic
 Example responses:
-* Valid content:
+- Valid content:
     ```json
     {
@@ -29,7 +29,7 @@ Example responses:
     }
     ```
-* Invalid content:
+- Invalid content:
     ```json
     {
@@ -40,7 +40,7 @@ Example responses:
     }
     ```
-* Without the content attribute:
+- Without the content attribute:
     ```json
     {
@@ -49,4 +49,3 @@ Example responses:
     ```
 [ce-5953]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5953
-

doc/api/oauth2.md

 # GitLab as an OAuth2 provider
-This document covers using the [OAuth2](https://oauth.net/2/) protocol to allow other services access GitLab resources on user's behalf. 
+This document covers using the [OAuth2](https://oauth.net/2/) protocol to allow other services access GitLab resources on user's behalf.
 If you want GitLab to be an OAuth authentication service provider to sign into other services please see the [OAuth2 provider](../integration/oauth_provider.md)
 documentation.
-This functionality is based on [doorkeeper gem](https://github.com/doorkeeper-gem/doorkeeper). 
+This functionality is based on [doorkeeper gem](https://github.com/doorkeeper-gem/doorkeeper).
 ## Supported OAuth2 Flows
-GitLab currently supports following authorization flows: 
-* *Web Application Flow* - Most secure and common type of flow, designed for the applications with secure server-side.
-* *Implicit Flow* - This flow is designed for user-agent only apps (e.g. single page web application running on GitLab Pages).
-* *Resource Owner Password Credentials Flow* - To be used **only** for securely hosted, first-party services.
+GitLab currently supports following authorization flows:
+- *Web Application Flow* - Most secure and common type of flow, designed for the applications with secure server-side.
+- *Implicit Flow* - This flow is designed for user-agent only apps (e.g. single page web application running on GitLab Pages).
+- *Resource Owner Password Credentials Flow* - To be used **only** for securely hosted, first-party services.
 Please refer to [OAuth RFC](https://tools.ietf.org/html/rfc6749) to find out in details how all those flows work and pick the right one for your use case.
-Both *web application* and *implicit* flows require `application` to be registered first via `/profile/applications` page 
-in your user's account. During registration, by enabling proper scopes you can limit the range of resources which the `application` can access. Upon creation 
+Both *web application* and *implicit* flows require `application` to be registered first via `/profile/applications` page
+in your user's account. During registration, by enabling proper scopes you can limit the range of resources which the `application` can access. Upon creation
 you'll obtain `application` credentials: _Application ID_ and _Client Secret_ - **keep them secure**.
->**Important:** OAuth specification advises sending `state` parameter with each request to `/oauth/authorize`. We highly recommended to send a unique 
-value with each request and validate it against the one in redirect request. This is important to prevent [CSRF attacks]. The `state` param really should 
+>**Important:** OAuth specification advises sending `state` parameter with each request to `/oauth/authorize`. We highly recommended to send a unique
+value with each request and validate it against the one in redirect request. This is important to prevent [CSRF attacks]. The `state` param really should
 have been a requirement in the standard!
-In the following sections you will find detailed instructions on how to obtain authorization with each flow. 
-### Web Application Flow 
+In the following sections you will find detailed instructions on how to obtain authorization with each flow.
+### Web Application Flow
 Check [RFC spec](http://tools.ietf.org/html/rfc6749#section-4.1) for a detailed flow description
@@ -48,7 +48,7 @@ You should then use the `code` to request an access token.
 #### 2. Requesting access token
-Once you have the authorization code you can request an `access_token` using the code, to do that you can use any HTTP client. In the following example, 
+Once you have the authorization code you can request an `access_token` using the code, to do that you can use any HTTP client. In the following example,
 we are using Ruby's `rest-client`:
 ```
@@ -73,13 +73,13 @@ You can now make requests to the API with the access token returned.
 Check [RFC spec](http://tools.ietf.org/html/rfc6749#section-4.2) for a detailed flow description.
-Unlike the web flow, the client receives an `access token` immediately as a result of the authorization request. The flow does not use client secret 
-or authorization code because all of the application code and storage is easily accessible, therefore __secrets__ can leak easily. 
->**Important:** Avoid using this flow for applications that store data outside of the GitLab instance. If you do, make sure to verify `application id` 
-associated with access token before granting access to the data 
-(see [/oauth/token/info](https://github.com/doorkeeper-gem/doorkeeper/wiki/API-endpoint-descriptions-and-examples#get----oauthtokeninfo)). 
- 
+Unlike the web flow, the client receives an `access token` immediately as a result of the authorization request. The flow does not use client secret
+or authorization code because all of the application code and storage is easily accessible, therefore __secrets__ can leak easily.
+
+>**Important:** Avoid using this flow for applications that store data outside of the GitLab instance. If you do, make sure to verify `application id`
+associated with access token before granting access to the data
+(see [/oauth/token/info](https://github.com/doorkeeper-gem/doorkeeper/wiki/API-endpoint-descriptions-and-examples#get----oauthtokeninfo)).
 #### 1. Requesting access token
@@ -89,7 +89,7 @@ To request the access token, you should redirect the user to the `/oauth/authori
 https://gitlab.example.com/oauth/authorize?client_id=APP_ID&redirect_uri=REDIRECT_URI&response_type=token&state=YOUR_UNIQUE_STATE_HASH
 ```
-This will ask the user to approve the applications access to their account and then redirect back to the `REDIRECT_URI` you provided. The redirect 
+This will ask the user to approve the application's access to their account and then redirect back to the `REDIRECT_URI` you provided. The redirect
 will include a fragment with `access_token` as well as token details in GET parameters, for example:
 ```
@@ -100,7 +100,7 @@ http://myapp.com/oauth/redirect#access_token=ABCDExyz123&state=YOUR_UNIQUE_STATE
 Check [RFC spec](http://tools.ietf.org/html/rfc6749#section-4.3) for a detailed flow description.
-> **Deprecation notice:** Starting in GitLab 8.11, the Resource Owner Password Credentials has been *disabled* for users with two-factor authentication 
+> **Deprecation notice:** Starting in GitLab 8.11, the Resource Owner Password Credentials has been *disabled* for users with two-factor authentication
 turned on. These users can access the API using [personal access tokens] instead.
 In this flow, a token is requested in exchange for the resource owner credentials (username and password).
@@ -109,7 +109,7 @@ client is part of the device operating system or a highly privileged application
 available (such as an authorization code).
 >**Important:**
-Never store the users credentials and only use this grant type when your client is deployed to a trusted environment, in 99% of cases [personal access tokens] 
+Never store the user's credentials and only use this grant type when your client is deployed to a trusted environment, in 99% of cases [personal access tokens]
 are a better choice.
 Even though this grant type requires direct client access to the resource owner credentials, the resource owner credentials are used
@@ -148,7 +148,7 @@ puts access_token.token
 ##  Access GitLab API with `access token`
-The `access token` allows you to make requests to the API on a behalf of a user. You can pass the token either as GET parameter 
+The `access token` allows you to make requests to the API on a behalf of a user. You can pass the token either as GET parameter
 ```
 GET https://gitlab.example.com/api/v4/user?access_token=OAUTH-TOKEN
 ```
@@ -160,4 +160,4 @@ curl --header "Authorization: Bearer OAUTH-TOKEN" https://gitlab.example.com/api
 ```
 [personal access tokens]: ../user/profile/personal_access_tokens.md
-[CSRF attacks]: http://www.oauthsecurity.com/#user-content-authorization-code-flow
\ No newline at end of file
+[CSRF attacks]: http://www.oauthsecurity.com/#user-content-authorization-code-flow

doc/api/projects.md

@@ -7,30 +7,29 @@ This is determined by the `visibility` field in the project.
 Values for the project visibility level are:
-* `private`:
+- `private`:
   Project access must be granted explicitly for each user.
-* `internal`:
+- `internal`:
   The project can be cloned by any logged in user.
-* `public`:
+- `public`:
   The project can be cloned without any authentication.
 ## Project merge method
 There are currently three options for `merge_method` to choose from:
-* `merge`:
+- `merge`:
   A merge commit is created for every merge, and merging is allowed as long as there are no conflicts.
-* `rebase_merge`:
+- `rebase_merge`:
   A merge commit is created for every merge, but merging is only allowed if fast-forward merge is possible.
   This way you could make sure that if this merge request would build, after merging to target branch it would also build.
-* `ff`:
+- `ff`:
   No merge commits are created and all merges are fast-forwarded, which means that merging is only allowed if the branch could be fast-forwarded.
-
 ## List all projects
 Get a list of all visible projects across GitLab for the authenticated user.

doc/ci/pipelines.md

@@ -241,9 +241,9 @@ So each job would be represented as a `Period`, which consists of
 `Period#first` as when the job started and `Period#last` as when the
 job was finished. A simple example here would be:
-* A (1, 3)
-* B (2, 4)
-* C (6, 7)
+- A (1, 3)
+- B (2, 4)
+- C (6, 7)
 Here A begins from 1, and ends to 3. B begins from 2, and ends to 4.
 C begins from 6, and ends to 7. Visually it could be viewed as:

doc/ci/yaml/README.md

@@ -332,10 +332,10 @@ jobs are created:
 There are a few rules that apply to the usage of job policy:
-* `only` and `except` are inclusive. If both `only` and `except` are defined
+- `only` and `except` are inclusive. If both `only` and `except` are defined
    in a job specification, the ref is filtered by `only` and `except`.
-* `only` and `except` allow the use of regular expressions (using [Ruby regexp syntax](https://ruby-doc.org/core/Regexp.html)).
-* `only` and `except` allow to specify a repository path to filter jobs for
+- `only` and `except` allow the use of regular expressions (using [Ruby regexp syntax](https://ruby-doc.org/core/Regexp.html)).
+- `only` and `except` allow to specify a repository path to filter jobs for
    forks.
 In addition, `only` and `except` allow the use of special keywords:

doc/development/adding_database_indexes.md

@@ -113,9 +113,9 @@ the meaning of the various columns can be found at
 Because the output of this query relies on the actual usage of your database it
 may be affected by factors such as (but not limited to):
-* Certain queries never being executed, thus not being able to use certain
+- Certain queries never being executed, thus not being able to use certain
   indexes.
-* Certain tables having little data, resulting in PostgreSQL using sequence
+- Certain tables having little data, resulting in PostgreSQL using sequence
   scans instead of index scans.
 In other words, this data is only reliable for a frequently used database with

doc/development/background_migrations.md

@@ -25,9 +25,9 @@ should only be used for data migrations.
 Some examples where background migrations can be useful:
-* Migrating events from one table to multiple separate tables.
-* Populating one column based on JSON stored in another column.
-* Migrating data that depends on the output of external services (e.g. an API).
+- Migrating events from one table to multiple separate tables.
+- Populating one column based on JSON stored in another column.
+- Migrating data that depends on the output of external services (e.g. an API).
 ## Isolation

doc/development/contributing/index.md

@@ -97,28 +97,28 @@ When your code contains more than 500 changes, any major breaking changes, or an
 This [documentation](issue_workflow.md) outlines the current issue process.
-* [Type labels](issue_workflow.md#type-labels)
-* [Subject labels](issue_workflow.md#subject-labels)
-* [Team labels](issue_workflow.md#team-labels)
-* [Release Scoping labels](issue_workflow.md#release-scoping-labels)
-* [Priority labels](issue_workflow.md#priority-labels)
-* [Severity labels](issue_workflow.md#severity-labels)
-* [Label for community contributors](issue_workflow.md#label-for-community-contributors)
-* [Issue triaging](issue_workflow.md#issue-triaging)
-* [Feature proposals](issue_workflow.md#feature-proposals)
-* [Issue tracker guidelines](issue_workflow.md#issue-tracker-guidelines)
-* [Issue weight](issue_workflow.md#issue-weight)
-* [Regression issues](issue_workflow.md#regression-issues)
-* [Technical and UX debt](issue_workflow.md#technical-and-ux-debt)
-* [Stewardship](issue_workflow.md#stewardship)
+- [Type labels](issue_workflow.md#type-labels)
+- [Subject labels](issue_workflow.md#subject-labels)
+- [Team labels](issue_workflow.md#team-labels)
+- [Release Scoping labels](issue_workflow.md#release-scoping-labels)
+- [Priority labels](issue_workflow.md#priority-labels)
+- [Severity labels](issue_workflow.md#severity-labels)
+- [Label for community contributors](issue_workflow.md#label-for-community-contributors)
+- [Issue triaging](issue_workflow.md#issue-triaging)
+- [Feature proposals](issue_workflow.md#feature-proposals)
+- [Issue tracker guidelines](issue_workflow.md#issue-tracker-guidelines)
+- [Issue weight](issue_workflow.md#issue-weight)
+- [Regression issues](issue_workflow.md#regression-issues)
+- [Technical and UX debt](issue_workflow.md#technical-and-ux-debt)
+- [Stewardship](issue_workflow.md#stewardship)
 ## Merge requests
 This [documentation](merge_request_workflow.md) outlines the current merge request process.
-* [Merge request guidelines](merge_request_workflow.md#merge-request-guidelines)
-* [Contribution acceptance criteria](merge_request_workflow.md#contribution-acceptance-criteria)
-* [Definition of done](merge_request_workflow.md#definition-of-done)
+- [Merge request guidelines](merge_request_workflow.md#merge-request-guidelines)
+- [Contribution acceptance criteria](merge_request_workflow.md#contribution-acceptance-criteria)
+- [Definition of done](merge_request_workflow.md#definition-of-done)
 ## Style guides

doc/development/fe_guide/components.md

 # Components
 ## Contents
-* [Dropdowns](#dropdowns)
-* [Modals](#modals)
+
+- [Dropdowns](#dropdowns)
+- [Modals](#modals)
 ## Dropdowns
 See also the [corresponding UX guide](https://design.gitlab.com/#/components/dropdowns).
 ### How to style a bootstrap dropdown
+
 1. Use the HTML structure provided by the [docs][bootstrap-dropdowns]
 1. Add a specific class to the top level `.dropdown` element
-
     ```Haml
     .dropdown.my-dropdown
       %button{ type: 'button', data: { toggle: 'dropdown' }, 'aria-haspopup': true, 'aria-expanded': false }

doc/development/fe_guide/droplab/droplab.md

@@ -177,28 +177,28 @@ droplab.init().addData('trigger', [{
 DropLab adds some CSS classes to help lower the barrier to integration.
-For example,
-* The `droplab-item-selected` css class is added to items that have been selected
-either by a mouse click or by enter key selection.
-* The `droplab-item-active` css class is added to items that have been selected
-using arrow key navigation.
-* You can add the `droplab-item-ignore` css class to any item that you do not want to be selectable. For example,
-an `<li class="divider"></li>` list divider element that should not be interactive.
+For example:
+- The `droplab-item-selected` css class is added to items that have been selected
+  either by a mouse click or by enter key selection.
+- The `droplab-item-active` css class is added to items that have been selected
+  using arrow key navigation.
+- You can add the `droplab-item-ignore` css class to any item that you do not want to be selectable. For example,
+  an `<li class="divider"></li>` list divider element that should not be interactive.
 ## Internal events
 DropLab uses some custom events to help lower the barrier to integration.
-For example,
-* The `click.dl` event is fired when an `li` list item has been clicked. It is also
-fired when a list item has been selected with the keyboard. It is also fired when a
-`HookButton` button is clicked (a registered `button` tag or `a` tag trigger).
-* The `input.dl` event is fired when a `HookInput` (a registered `input` tag trigger) triggers an `input` event.
-* The `mousedown.dl` event is fired when a `HookInput` triggers a `mousedown` event.
-* The `keyup.dl` event is fired when a `HookInput` triggers a `keyup` event.
-* The `keydown.dl` event is fired when a `HookInput` triggers a `keydown` event.
+For example:
+- The `click.dl` event is fired when an `li` list item has been clicked. It is also
+  fired when a list item has been selected with the keyboard. It is also fired when a
+  `HookButton` button is clicked (a registered `button` tag or `a` tag trigger).
+- The `input.dl` event is fired when a `HookInput` (a registered `input` tag trigger) triggers an `input` event.
+- The `mousedown.dl` event is fired when a `HookInput` triggers a `mousedown` event.
+- The `keyup.dl` event is fired when a `HookInput` triggers a `keyup` event.
+- The `keydown.dl` event is fired when a `HookInput` triggers a `keydown` event.
 These custom events add a `detail` object to the vanilla `Event` object that provides some potentially useful data.
@@ -233,9 +233,9 @@ droplab.init(trigger, list, [droplabAjax], {
 ### Documentation
-* [Ajax plugin](plugins/ajax.md)
-* [Filter plugin](plugins/filter.md)
-* [InputSetter plugin](plugins/input_setter.md)
+- [Ajax plugin](plugins/ajax.md)
+- [Filter plugin](plugins/filter.md)
+- [InputSetter plugin](plugins/input_setter.md)
 ### Development

doc/development/fe_guide/droplab/plugins/ajax.md

@@ -8,10 +8,10 @@ Add the `Ajax` object to the plugins array of a `DropLab.prototype.init` or `Dro
 `Ajax` requires 2 config values, the `endpoint` and `method`.
-* `endpoint` should be a URL to the request endpoint.
-* `method` should be `setData` or `addData`.
-* `setData` completely replaces the dropdown with the response data.
-* `addData` appends the response data to the current dropdown list.
+- `endpoint` should be a URL to the request endpoint.
+- `method` should be `setData` or `addData`.
+- `setData` completely replaces the dropdown with the response data.
+- `addData` appends the response data to the current dropdown list.
 ```html
 <a href="#" id="trigger" data-dropdown-trigger="#list">Toggle</a>

doc/development/fe_guide/droplab/plugins/filter.md

@@ -7,8 +7,8 @@ to the dropdown using a simple fuzzy string search of an input value.
 Add the `Filter` object to the plugins array of a `DropLab.prototype.init` or `DropLab.prototype.addHook` call.
-* `Filter` requires a config value for `template`.
-* `template` should be the key of the objects within your data array that you want to compare
+- `Filter` requires a config value for `template`.
+- `template` should be the key of the objects within your data array that you want to compare
 to the user input string, for filtering.
 ```html

doc/development/fe_guide/droplab/plugins/input_setter.md

@@ -6,9 +6,9 @@
 Add the `InputSetter` object to the plugins array of a `DropLab.prototype.init` or `DropLab.prototype.addHook` call.
-* `InputSetter` requires a config value for `input` and `valueAttribute`.
-* `input` should be the DOM element that you want to manipulate.
-* `valueAttribute` should be a string that is the name of an attribute on your list items that is used to get the value
+- `InputSetter` requires a config value for `input` and `valueAttribute`.
+- `input` should be the DOM element that you want to manipulate.
+- `valueAttribute` should be a string that is the name of an attribute on your list items that is used to get the value
 to update the `input` element with.
 You can also set the `InputSetter` config to an array of objects, which will allow you to update multiple elements.