Feature request - semantic typography classes for headings like .h1, .h2

[elisechant]

What I did

Sometimes you need to style heading tags to look like other heading tags but maintain their semantics. A common pattern is to provide .h1, .h2, .h3 etc in addition to raw element styling so I able to style an element like this:

<h2 className="h4">Widgets</h2>

What I expected to see

Refs in gov-au-ui-kit/assets/sass/components/_typography.scss to include heading classes as well as raw element styles, like:

[klepas]

I’m… not a fan of inserting classes like these.

Instead, I’d be really keen to hear about why the ordering is borked stylistically that led to this, or have a team write additional sass to meet their custom needs.

The main reasons why I want to avoid classes like these:

1. it’s presentational markup which in this instance can actually be semantically confusing
2. once you make available these classes a lot of the work we put into enforcing a certain consistency can easily be done away with just with the use of classes.

What do you think @elisechant? (:

[elisechant]

I hear what you're saying and it's ultimately up to you guys. I think there is a bigger discussion to be had here about styling with declarative html classes. Personally I think it's impractical to assume that stylistically semantics will always render desirably.

Often my framework opinions are based on bigger framework implementation detail. In this instance this is a convention in Bootstrap: https://github.com/twbs/bootstrap/blob/v4-npm/scss/_type.scss.

[klepas]

Personally I think it's impractical to assume that stylistically semantics will always render desirably.

I’m getting to the point where I’m feeling that I’ve made an assumption here that purely semantic SASS was gonna work out for both prototyping and prod needs.

From an optim and from a prod QA perspective I really want to avoid having these kinds of things served in a prod env… but I think that my expectation for the kit to work without these kinds of classes for prototyping is kinda flawed.

If we were to proceed in adding classes like these I fear that we might end up not being able to clean up our codebases (both custom SASS and html templates) as they get closer to prod, unless we automate that process (I think there are some optim packages that will try to cull unused CSS for you… but templating still needs solving I suppose)?

[dominikwilkowski]

Hi there,

I'd love to chime in here and add two or three cents. I think in an ideal world @klepas is quit right that the structure of the page should reflect the styling and with that comes great semantic meaning and enforcement.

As we're now moving to a larger audience and begin to think about projects where there might not be a lot of resources available we need to make it easy and straight forward. Some unfortunate soul might have to deal with some legacy system that already comes with styling of the h1 tag and we now clash with them. There could be really tricky and "modern" designs that make a mockery of what we thing is the right semantical design. I can even imagine projects that are bound to some crazy CMS that have no way of changing the actual HTML tag and can only add classes. (Looking at you legacy java CMS)

I personally can't see how we can enforce semantic HTML markup on every level. We can only do our very best to get our own backyard clean and awesome and lead by example. Adding documentation and other resources will add more value than forcing people to do the right thing.

Too radical?

[klepas]

@elisechant @dominikwilkowski After some more chats with Dom, and more musing on the subject I think I’ve come full circle on this — I’m happy to opt for say .display-1, .display-2 or something like that (let’s avoid .h1, .h2, etc though).