Make separator styling consistent

[bartaz]

Context

This partially reverts changes done in #5241.

The state of the separators that this PR proposes is as follows:

Rule p-rule component is not deprecated, it aims to be the default and main way to create separators. Base <hr> element has default separator styling, same as .p-rule component. Both are horizontal lines with bottom margin.

Any additional styling options (muted, highlighted, accented) are provided by rule component. The "variants" of hr element are deprecated.

So ideally everything should be covered by rule component:

• default separator between sections <hr class="p-rule"> or (<hr> for shortcut)
• muted separator inside sections <hr class="p-rule--muted">
• highlighted separator (thicker border) <hr class="p-rule--highlighted">
• accent colour <hr class="p-rule--highlighted is-accent">

Open questions

1. Should we keep both "Separators" and "Rule" component documentation pages? If we decide to merge them into one, where should it live?

As discussed, the base "Separators" page will be removed. All options (including mention of deprecated styles) are going to be covered by Rule component page.

3. How useful is the hr.is-fixed-width styling. Currently it allows to limit the width of hr to the size of grid without wrapping it in grid. But it's inconsistent with rest of the framework and technically we should avoid doing it on "base" element. a) drop it, and expect devs to wrap separators inside the grid properly (adds a bit of markup) b) move it to p-rule component, but deprecate on base "hr" (keeps the variants of base elements, more consistent) c) keep as is?

For now we are keeping the is-fixed-width class name, as devs find it useful. We are officially moving it into rule component (and deprecating on base hr element).

Done

To achieve the status mentioned above, in this PR:

• we are reverting the deprecation of rules component (it was not released yet)
• we are removing unnecessary styling options from hr element (that haven't been released yet)
• we are deprecating styling options on hr element (as rule component should be used instead).
• we are removing the "base" separators page and moving all relevant docs to rule component page

QA

• Open demo
• Review affected examples:
  • horizontal lines https://vanilla-framework-5338.demos.haus/docs/examples/base/hr/combined?theme=light
  • rules: https://vanilla-framework-5338.demos.haus/docs/examples/patterns/rule/combined?theme=light
• Review updated documentation:
  • base separator documentation (should redirect to rule component): https://vanilla-framework-5338.demos.haus/docs/base/separators
  • check the deprecated section on the bottom
  • rule documentation: https://vanilla-framework-5338.demos.haus/docs/patterns/rule

Check if PR is ready for release

If this PR contains Vanilla SCSS code changes, it should contain the following changes to make sure it's ready for the release:

• [x] PR should have one of the following labels to automatically categorise it in release notes:
  • Feature 🎁, Breaking Change 💣, Bug 🐛, Documentation 📝, Maintenance 🔨.
• [x] Vanilla version in package.json should be updated relative to the most recent release, following semver convention:
  • if CSS class names are not changed it can be bugfix release (x.x.X)
  • if CSS class names are changed/added/removed it should be minor version (x.X.0)
  • see the wiki for more details
• [x] Any changes to component class names (new patterns, variants, removed or added features) should be listed on the what's new page.

[webteam-app]

Demo

Jenkins

demos.haus

[jmuzina]

Discussed in pair programming meeting today:

Should we keep both "Separators" and "Rule" component documentation pages? If we decide to merge them into one, where should it live?

I think "Separators" page can be removed, in favor of just using "Rule" page. This PR seems like it makes HR behave much like the default button which is documented as a component, despite it not needing p-button class

How useful is the hr.is-fixed-width styling. Currently it allows to limit the width of hr to the size of grid without wrapping it in grid. But it's inconsistent with rest of the framework and technically we should avoid doing it on "base" element. a) drop it, and expect devs to wrap separators inside the grid properly (adds a bit of markup) b) move it to p-rule component, but deprecate on base "hr" (keeps the variants of base elements, more consistent) c) keep as is?

@pastelcyborg You made this point more succinctly, but I'll summarize my understanding: I think the general direction we're going for is to keep grid behavior under the grid page & mixin, and expect people to add markup to support it. Though that would be a breaking change, so maybe it should be set for next major version.

[immortalcodes]

I have applied p-rule--muted class to <hr> within a section, in this case it becomes very close to the button, will this be considered fine?

[bartaz]

I have applied p-rule--muted class to <hr> within a section, in this case it becomes very close to the button, will this be considered fine?

@immortalcodes In current version of Vanilla that's what happens. But this PR fixes it by adding margin to p-rule (consistent with plain <hr>). So once this PR is merged and released this will be a correct way to do it.

[mtruj013]

re: the open questions:

1. IMO it there should only be one documentation page for hrs. Since p-rule is the base component for quite a lot of variants I think that it should be the one that stays
2. I find hr.is-fixed-width to be pretty useful and my vote would be for option B, move it to the rule component