Markdown styling - nasty-looking spacing when using nested lists in main issue-description in tracker

When specifying nested lists, there is extra space rendered immediately above the child point(s) that follow a given 'parent' item. This is visually confusing in the case that – if another non-subordinate point appears after the child points – there is no intervening space before the original level of indentation is resumed and the list proceeds. This style gives the impression spatially that the child points belong in a grouping with the next sibling after their actual parent, since they are spaced farther away from the parent item than with its next sibling.

Subordinate lists should appear either: with equal amounts of vertical spacing above and below or: with less spacing above and more below, to give the impression of child items being grouped with the parent item, rather than with the following sibling item.

I have confirmed this applies to both Firefox 49 and Internet Explorer 11. Most browsers are presumably affected. Prefixing lists with a tab-character instead of 4 {{space}}s has no effect on rendering.

Sample:

As an addendum, naming conventions which imply purpose (as opposed to type) should still be acceptable as per our current conventions:

• using singular noun-phrases for relations which accept CRUD-operations
• using plural noun-phrases to describe relations which:

• • exist for display-purposes
  • may or may not accept CRUD-operations
• using the cache suffix for relations which are _not human-reader friendly which store the results of intensive computations and do not *logically* allow CRUD-operations since they represent a digest of information from various tables which would not make sense to edit directly. Such caches should be accessed using a function both to decrease coupling to specific relations, and to give database-users the option to avoid using the cache if they require guaranteed-up-to-date information.

Sample source:

As an addendum, naming conventions which imply ***purpose*** (as opposed to type) should still be acceptable as per our current conventions:

* using ***singular*** noun-phrases for relations which accept [CRUD](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete)-operations
* using ***plural*** noun-phrases to describe relations which:
    * exist for display-purposes
    * ***may*** or ***may not*** accept CRUD-operations
* using the `_cache` suffix for relations which are ***not*** human-reader friendly which store the results of intensive computations and do not **\*logically\*** allow CRUD-operations since they represent a digest of information from various tables which would not make sense to edit directly. Such caches should be accessed using a function both to decrease coupling to specific relations, and to give database-users the option to avoid using the cache if they require guaranteed-up-to-date information.

Problem CSS:

The style that's causing this in the main issue-body is a line from vendor.css which applies to <ul> elements:

.aui-group, .aui-panel, .aui-tabs,
blockquote, dl, form.aui, h1, h2, 
h3, h4, h5, h6, ol, p, pre,
table.aui, ul {
    margin: 10px 0 0;
}