Remove <br> and replace GFM blockquote with the Markdown general

[ci skip]

doc/development/ux_guide/basics.md

@@ -10,15 +10,11 @@
 
 ---
 
-<br>
-
 ## Responsive
 GitLab is a responsive experience that works well across all screen sizes, from mobile devices to large monitors. In order to provide a great user experience, the core functionality (browsing files, creating issues, writing comments, etc.) must be available at all resolutions. However, due to size limitations, some secondary functionality may be hidden on smaller screens. Please keep this functionality limited to rare actions that aren't expected to be needed on small devices.
 
 ---
 
-<br>
-
 ## Typography
 ### Primary typeface
 GitLab's main typeface used throughout the UI is **Source Sans Pro**. We support both the bold and regular weight.
@@ -36,8 +32,6 @@ This is the typeface used for code blocks. GitLab uses the OS default font.
 
 ---
 
-<br>
-
 ## Icons
 GitLab uses Font Awesome icons throughout our interface.
 
@@ -62,14 +56,10 @@ An 'x' is used for closing UI elements such as dropdowns.
 ![Add icon](img/icon-add.png)
 A plus is used when creating new objects, such as issues, projects, etc.
 
->>>
-TODO: update this section, add more general guidance to icon usage and personality, etc.
->>>
+> TODO: update this section, add more general guidance to icon usage and personality, etc.
 
 ---
 
-<br>
-
 ## Color
 
 ![Blue](img/color-blue.png)
@@ -87,26 +77,18 @@ Red is reserved for delete and other destructive commands
 ![Grey](img/color-grey.png)
 Grey, and white (depending on context) is used for netral, secondary elements
 
->>>
-TODO: Establish a perspective for color in terms of our personality and rationalize with Marketing usage.
->>>
+> TODO: Establish a perspective for color in terms of our personality and rationalize with Marketing usage.
 
 ---
 
-<br>
-
 ## Motion
 
 Motion is a tool to help convey important relationships, changes or transitions between elements. It should be used sparingly and intentionally, highlighting the right elements at the right moment.
 
->>>
-TODO: Determine a more concrete perspective on motion, create consistent easing/timing curves to follow.
->>>
+> TODO: Determine a more concrete perspective on motion, create consistent easing/timing curves to follow.
 
 ---
 
-<br>
-
 ## Voice and tone
 
 The copy for GitLab is clear and direct. We strike a clear balance between professional and friendly. We can empathesize with users (such as celebrating completing all Todos), and remain respectful of the importance of the work. We are that trusted, friendly coworker that is helpful and understanding.

doc/development/ux_guide/components.md

@@ -17,8 +17,6 @@
 
 ---
 
-<br>
-
 ## Tooltips
 
 ### Usage
@@ -33,8 +31,6 @@ By default, tooltips should be placed below the element that they refer to. Howe
 
 ---
 
-<br>
-
 ## Anchor links
 
 Anchor links are used for navigational actions and lone, secondary commands (such as 'Reset filters' on the Issues List) when deemed appropriate by the UX team.
@@ -57,8 +53,6 @@ The focus state should match the hover state.
 
 ---
 
-<br>
-
 ## Buttons
 
 Buttons communicate the command that will occur when the user clicks on them.
@@ -87,8 +81,6 @@ Follow the color guidance on the [basics](basics.md#color) page. The default col
 
 ---
 
-<br>
-
 ## Dropdowns
 
 Dropdowns are used to allow users to choose one (or many) options from a list of options. If this list of options is more 20, there should generally be a way to search through and filter the options (see the complex filter dropdowns below.)
@@ -103,8 +95,6 @@ TODO: Will update this section when the new filters UI is implemented.
 
 ---
 
-<br>
-
 ## Counts
 
 A count element is used in navigation contexts where it is helpful to indicate the count, or number of items, in a list. Always use the [`number_with_delimiter`][number_with_delimiter] helper to display counts in the UI.
@@ -115,8 +105,6 @@ A count element is used in navigation contexts where it is helpful to indicate t
 
 ---
 
-<br>
-
 ## Lists
 
 Lists are used where ever there is a single column of information to display. Ths [issues list](https://gitlab.com/gitlab-org/gitlab-ce/issues) is an example of a important list in the GitLab UI.
@@ -141,8 +129,6 @@ List inside panel
 
 ---
 
-<br>
-
 ## Tables
 
 When the information is too complex for a list, with multiple columns of information, a table can be used. For example, the [pipelines page](https://gitlab.com/gitlab-org/gitlab-ce/pipelines) uses a table.
@@ -151,8 +137,6 @@ When the information is too complex for a list, with multiple columns of informa
 
 ---
 
-<br>
-
 ## Blocks
 
 Blocks are a way to group related information.
@@ -178,8 +162,6 @@ Cover blocks are generally used to create a heading element for a page, such as
 
 ---
 
-<br>
-
 ## Panels
 
 >>>
@@ -190,8 +172,6 @@ TODO: Catalog how we are currently using panels and rationalize how they relate
 
 ---
 
-<br>
-
 ## Alerts
 
 >>>
@@ -202,8 +182,6 @@ TODO: Catalog how we are currently using alerts
 
 ---
 
-<br>
-
 ## Forms
 
 There are two options shown below regarding the positioning of labels in forms. Both are options to consider based on context and available size. However, it is important to have a consistent treatment of labels in the same form.
@@ -224,8 +202,6 @@ Horizontal form (`form.horizontal-form`) with label rendered inline with input.
 
 ---
 
-<br>
-
 ## File holders
 A file holder (`.file-holder`) is used to show the contents of a file inline on a page of GitLab.
 
@@ -233,8 +209,6 @@ A file holder (`.file-holder`) is used to show the contents of a file inline on
 
 ---
 
-<br>
-
 ## Data formats
 
 ### Dates
@@ -277,6 +251,4 @@ Referencing GitLab items depends on a symbol for each type of item. Typing that
 
 ![People reference](img/components-referencepeople.png)
 
->>>
-Open issue: Some commit references use monospace fonts, but others don't. Need to standardize this.
->>>
+> TODO: Open issue: Some commit references use monospace fonts, but others don't. Need to standardize this.

doc/development/ux_guide/features.md

@@ -30,8 +30,6 @@ The [GitLab Product Map](https://gitlab.com/gitlab-org/gitlab-design/raw/master/
 
 ---
 
-<br>
-
 ## Filtering
 
 Today, lists are filtered by a series of dropdowns. Some of these dropdowns allow multiselect (labels), while others allow you to filter to one option (milestones). However, we are currently implementing a [new model](https://gitlab.com/gitlab-org/gitlab-ce/issues/21747) for this, and will update the guide when it is ready.
@@ -40,8 +38,6 @@ Today, lists are filtered by a series of dropdowns. Some of these dropdowns allo
 
 ---
 
-<br>
-
 ## Search results
 
 ### Global search
@@ -54,8 +50,6 @@ There are several core lists in the GitLab experience, such as the Issue list an
 
 ---
 
-<br>
-
 ## Empty states
 
 Empty states need to be considered in the design of features. They are vital to helping onboard new users, making the experience feel more approachable and understandable. Empty states should feel inviting and provide just enough information to get people started. There should be a single call to action and a clear explanation of what to use the feature for.

doc/development/ux_guide/principles.md

@@ -2,28 +2,16 @@
 
 These are the guiding principles that we should strive for to establish a solid foundation for the GitLab experience.
 
-<br>
-
 ## Professional and productive
 GitLab is a tool to support what people do, day in, day out. We need to respect the importance of their work, and avoid gimicky details.
 
-<br>
-
 ## Minimal and efficient
 While work can get complicated, GitLab is about bringing a sharp focus, helping our customers know what matters now.
 
-<br>
-
 ## Immediately recognizable
 When you look at any screen, you should know immediately that it is GitLab. Our personality is strong and consistent across product and marketing experiences.
 
-<br>
-
 ## Human and quirky
 We need to build empathy with our users, understanding their state of mind, and connect with them at a human level. Quirkiness is part of our DNA, and we should embrace it in the right moments and contexts.
 
-<br>
-
->>>
-TODO: Ensure these principles align well with the goals of the Marketing team
->>>
+> TODO: Ensure these principles align well with the goals of the Marketing team
\ No newline at end of file

doc/development/ux_guide/surfaces.md

@@ -16,8 +16,6 @@ This menu is to navigate to pages that contain content global to GitLab.
 
 ---
 
-<br>
-
 ## Header
 
 The header contains 3 main elements: Project switching and searching, user account avatar and settings, and a contextual menu that changes based on the current page.
@@ -26,16 +24,12 @@ The header contains 3 main elements: Project switching and searching, user accou
 
 ---
 
-<br>
-
 ## Side pane
 
 The side pane holds supporting information and meta data for the information in the content area.
 
 ---
 
-<br>
-
 ## Content area
 
 The main content of the page. The content area can include other surfaces.

doc/development/ux_guide/tips.md

@@ -41,6 +41,4 @@ Correct file will look like this:
 <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 17" enable-background="new 0 0 16 17"><path d="m15.1 1h-2.1v-1h-2v1h-6v-1h-2v1h-2.1c-.5 0-.9.5-.9 1v14c0 .6.4 1 .9 1h14.2c.5 0 .9-.4.9-1v-14c0-.5-.4-1-.9-1m-1.1 14h-12v-9h12v9m0-11h-12v-1h12v1"/><path d="m5.4 11.6l1.5 1.2c.4.3 1.1.3 1.4-.1l2.5-3c.3-.4.3-1.1-.1-1.4-.5-.4-1.1-.3-1.5.1l-1.8 2.2-.8-.6c-.4-.3-1.1-.3-1.4.2-.3.4-.3 1 .2 1.4"/></svg>
 ```
 
->>>
-TODO: Checkout [https://github.com/svg/svgo](https://github.com/svg/svgo)
->>>
+> TODO: Checkout [https://github.com/svg/svgo](https://github.com/svg/svgo)
\ No newline at end of file

doc/development/ux_guide/users.md

 # Users
 
->>>
-TODO: Create personas. Understand the similarities and differences across the below spectrums.
->>>
+> TODO: Create personas. Understand the similarities and differences across the below spectrums.
 
 ## Users by organization