H4 element not distinguishable from rest of text (P element)

This is in fact the same problem: different symptom, same cause! Again, see #1936392: Configure CKEditor's "Advanced Content Filter" (ACF) to match Drupal's text filters settings :)

Can't reproduce this one though.

Say, you added the "format" dropbutton to the WYSIWYG iconbar?
And you didn't remove <h4> and <h5> from the "Limit allowed HTML tags" filter in the text format?
And you're using exactly the same WYSIWYG text format you had defined with the "format" dropbutton?
Then, how can this be?

For now, tentatively marking this one active again.

Browsers will render h4 headings with the same size and style than regular text. h5 and h6 headings are even rendered smaller than regular text (see attachment). This behavior is standardized across all modern browsers.

Should we override this default behavior using CSS and e.g. make all headings bold? The usage of too much heading levels isn't accepted as a good practice either...

From an accessibility point of view, the hierarchy has been important.

Particularly with comments, which is where filtered html is often used, you don't want them to have a higher ranking than the main content of the text.

Generally there's been just one H1. H2 tags are used for a lot of default content like block headers.

Thought I'd also point to the Drupal 8 Style Guide for Seven for reference. Although, this is more of a Bartik issue:
https://groups.drupal.org/node/283223

Removing tags that are now proven to be irrelevant.

This is not a bug/problem in filter.module. This is a matter of styling solely, hence this is a problem in the Bartik theme.

I took a look at this and was surprised to see that Bartik only explicitly declares h1 and h2. It seems to me we should not be leaving all the remaining header styles to the whim of the browser.

While @vollepeer is correct that browsers tend to render h4 at 1em, they are usually bold by default, providing the site visitor with a visual differentiation between the header and paragraph text. Because Bartik's header styles are not bold, this distinction has been removed so we need to do something else to provide the reader with a clue that this text is more important.

Here's my first pass at styling the other headers explicitly — I'm not really happy with it but I'm putting it out here for discussion. Hopefully we can figure out the right balance between retaining the Bartik aesthetic and finding a way to distinguish h4 from paragraph text.

Thanks!

11: bartik-header-styles-2020081-11.patch queued for re-testing.

I don't think we should do the ALL CAPS thing.

We need some way of distinguishing the headers from body text when they are that small. Some themes use bold, some use uppercase. Assigning to Jeff to make a stylistic decision.

Comment 11 explains why uppercase was used for Bartik headings instead of bold text.

While @vollepeer is correct that browsers tend to render h4 at 1em, they are usually bold by default, providing the site visitor with a visual differentiation between the header and paragraph text. Because Bartik's header styles are not bold, this distinction has been removed so we need to do something else to provide the reader with a clue that this text is more important.

I'm happy to revise as needed once Jeff weighs in.

What would be peoples general feeling about overhauling all of Bartiks font styles? In particular introducing a real modular scale, much improved whitespace handling and using 1rem base font size rather than 87%? In other words apply some guiding principles and those would be to use whitespace, font-size and weight and pretty much nothing else (maybe not even a specific font-family). Take it as read I am not afraid to change Bartiks styles.

With regards to this issue, the h3 still looks indistinct and to be frank I am not terribly excited by using text-transform - the main reason is that I would prefer Bartik moved more in the direction of minimalism, rather than more decorative, and rely on a more constrained set of design attributes e.g. font-size, whitespace and weight and not intriduce a fourth aspect such as case.

@Jeff I think we need an issue summary update. I can't tell exactly what the next steps are for this issue.

Indeed, you sense my indecisiveness on the issue. IN short - is this worth fixing properly, or fix and repair this one heading. I am not sure, i.e. is Bartik worth saving and building into a proper, modern, base theme, or not?

I am happy to fix and repair for now - in which case the issue summary stands as is, aka, carry on. Patch is good, I need to test a little more however.

What's the status of this issue, since the latest comments was from 3 months ago?

Per #21: the next steps weren't clear 3 months ago. So, the status is unchanged compared to #21, I'd say. NW for #21.

Let's go with upper case, it's a common way in indicate typographical heirachy and no one has proposed any other alternatives. A few minor fixes from #11:

+++ b/core/themes/bartik/css/style.css
@@ -37,6 +37,22 @@ h1 {
+  text-transform: uppercase;
+  letter-spacing: .1em;
+}
...
+  text-transform: uppercase;
+  letter-spacing: .1em;
+}

We should be using 0.1em

Using 0.1em :)

Adding screenshots to help reviews.

Headings side by side comparison.

Headings alongside paragraph comparison.

Thank you!

Committed 982db5f and pushed to 8.0.x. Thanks!

Just correcting status.