heading

Normal headings:

import { Heading } from '@flixbus/honeycomb-react';
const headings = [1, 2, 3, 4];
<>
  {
    headings.map((headingSize) => (
      <Heading key={headingSize} size={headingSize}>Heading {headingSize}</Heading>
    ))
  }
</>

Section heading modifier removes the padding top of the element, is to be used on sub-titles:

import { Heading } from '@flixbus/honeycomb-react';
const sectionHeadings = [2, 3, 4];
<>
  {
    sectionHeadings.map((headingSize) => (
      <Heading key={headingSize} sectionHeader size={headingSize}>Section Heading {headingSize}</Heading>
    ))
  }
</>

Space flush and sub headings:

import { Heading } from '@flixbus/honeycomb-react';
<>
  <Heading size={1} flushSpace>No spacing here</Heading>
  <Heading size={2} sectionHeader>Allows for a nice heading</Heading>
</>

Visual Hierarchy versus Semantic Hierarchy

Since the content structure and design may not agreed, we very conveniently allow for the a custom tag with the Elem prop. The correct implementation of heading information can be used by user agents to automatically build a table of contents for a document, for example.

Keeping a semantic heading structure is crucial for many assistive technologies but even more so to screen readers and accessibility. So you can mix and match the correct <h#> tag with the desired .hcr-h# class name in order to preserve a semantic hierarchy.

Avoid skipping heading levels: always start from <h1>, followed by <h2> and so on and use only one <h1> per page or view. It should concisely describe the overall purpose of the content.

With that being said, even though we offer only 4 heading class helpers you should (and we strongly encourage you do) use all of 6 heading tags available, as long as it makes sense for your product.

import { Heading } from '@flixbus/honeycomb-react';
const headings = [1, 2, 3, 4];
<>
  {
    headings.map((headingSize) => (
      <Heading key={headingSize} size={headingSize} Elem="h6">We have different sizes but we are all H6</Heading>
    ))
  }
</>