Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

<h1> heading semantics #33

Closed
jonaskuske opened this issue Apr 9, 2019 · 16 comments
Closed

<h1> heading semantics #33

jonaskuske opened this issue Apr 9, 2019 · 16 comments
Labels
bug Something isn't working

Comments

@jonaskuske
Copy link
Collaborator

jonaskuske commented Apr 9, 2019 •
edited

Styling for <h1> headings is currently broken, as all <h1> headings are forced to have the same font size.

HTML allows you to have multiple <h1> elements on a page¹, with one being the main site title and the others being nested e.g. inside <article> elements and acting as the main title for the respective article.

Browsers respect this and display nested <h1> elements smaller than the main one, but water.css breaks this because it forces all <h1> elements to have the same font-size.

<html>
  <body>
    <h1>Main title</h1>
    <article>
      <h1>Sub title</h1> <!-- Should have same size as <h2> -->
    </article>
  </body>
</html>

¹ The Document Outline as intended by HTML5 – but while browsers visually adhere to it by scaling down <h1> elements, they don't implement the Outline algorithm on a semantic level, unfortunately.
@kognise
Copy link
Owner

kognise commented Apr 10, 2019

Ooh, I didn't know that! Thanks.

@kognise
Copy link
Owner

kognise commented Apr 10, 2019

In an article should an h2 be smaller than an h1?

@jonaskuske
Copy link
Collaborator Author

This is what Chrome renders:

image

Font size of <h1> elements is adjusted according to nesting level, other headings keep their initial size.
Though it might be interesting to check out what exactly the spec says here, as browsers deviate from time to time.

But one way or another, I guess the best approach is not touching font-size and just letting UA styles do their thing there?

@kylejrp
Copy link
Collaborator

kylejrp commented Apr 10, 2019

http://scratchpad.io/numberless-flock-8487

For reference, Chrome uses these default styles for the example above:

:-webkit-any(article,aside,nav,section) :-webkit-any(article,aside,nav,section) h1 {
    font-size: 1.17em;
    margin-block-start: 1em;
    margin-block-end: 1em;
}
:-webkit-any(article,aside,nav,section) h1 {
    font-size: 1.5em;
    margin-block-start: 0.83em;
    margin-block-end: 0.83em;
}
h1 {
    display: block;
    font-size: 2em;
    margin-block-start: 0.67em;
    margin-block-end: 0.67em;
    margin-inline-start: 0px;
    margin-inline-end: 0px;
    font-weight: bold;
}

@jonaskuske
Copy link
Collaborator Author

Yup, though it doesn't stop there – you can nest all the way down until font-size of <h1> equals the font-size of <h6>.

@kylejrp
Copy link
Collaborator

kylejrp commented Apr 11, 2019

Seems like the best course of action is to set a root font size and let browsers set the correct heading sizes. This would probably require some cross browser testing to make sure that most browsers set some reasonable defaults in both the nested and non-nested cases.

@philsherry
Copy link

Browsers don’t support the document outline algorithm. Plus it's not great for accessibility to have more than one h1 on the page. For these reasons, I'd advise against this. No changes required.

Read more here: http://adrianroselli.com/2013/12/the-truth-about-truth-about-multiple-h1.html

@jonaskuske
Copy link
Collaborator Author

jonaskuske commented Apr 11, 2019 •
edited

Huh, you're right! That's too bad – so HTML has no way of writing reusable markup without ruining semantics? 😶
Really hope we'll get the generic <h> element at some point so we don't have to hard-code heading levels... (until then, React has your back)

This article on CSS tricks gives a great overview over the whole problem:
https://css-tricks.com/document-outline-dilemma/

@kognise kognise added the bug Something isn't working label Apr 11, 2019
@kognise
Copy link
Owner

kognise commented Apr 11, 2019

@jonaskuske @philsherry I'm finally jumping in the conversation - are you suggesting it's probably not very semantic to have multiple h1s in a page so we probably shouldn't style them? Sorry if I got it all wrong 😛

@philsherry
Copy link

@kognise Short answer: yes.

Longer answer: yes, because we're in the education business and shouldn't make allowances for people doing the wrong thing. If schooled correctly, the correct behaviour will (hopefully) prevail.

@kognise
Copy link
Owner

kognise commented Apr 12, 2019

And now I'm educated 😄
Think I should close this?

@jonaskuske
Copy link
Collaborator Author

Yep, whether or not this stylesheet should actively educate its users is the question here 😅

  • water.css acts as an enhancement to default user agent styles, therefore it should be compatible and not break sites that would work if you'd just use UA styles. The browsers are the ones "making allowances" here and water.css should just focus on staying in line with browsers

and

  • water.css should educate its users, even if it means breaking sites that would work with UA styles. If browsers get semantics wrong, we can at least correct it here and ensure markup that works with screen readers.

...are both valid stances imo.

But I'm fine with either, so close if you want. 👍🏻

@kognise
Copy link
Owner

kognise commented Apr 12, 2019

I'm gonna be bold and go for the second 👌

It's almost always similar - if enough people encourage best practices or use a new standard browsers will change to support it. Although Water.css isn't such a big player yet, we can at least start.

Thank you!

@kognise kognise closed this as completed Apr 12, 2019
@kylejrp
Copy link
Collaborator

kylejrp commented Apr 12, 2019

@jonaskuske @kognise How does this philosophy play with vendor prefixes for vendor specific features? For example, styling scrollbars doesn't have an official specification yet.

I do like choosing the second option though! We've got a lot of semantic HTML contributors.

@jonaskuske
Copy link
Collaborator Author

@kylejrp

While it's no final spec yet, there is a Working Draft for scrollbar styling and it's implemented in Firefox already.
Spec | MDN

Other than that, I don't know of a good CSS-only way to style scrollbars, anyhow:

  • The -ms- options for IE and Edge are non-starters as neither hiding completely nor auto-hiding are sensible defaults imo.

  • The ::-webkit- options in WebKit/Blink force scrollbars to always stay visible, even when the user has opted for auto-hiding/floating scrollbars (e.g. macOS or Chrome with flag #overlay-scrollbars on Windows). You'd need a tiny JS script to detect whether the browser has an always-visible scrollbar so you can conditionally style it – I think that's out of scope for water.css.

But if you want to discuss scrollbar styling further, we should probably make that a separate issue?

@kylejrp
Copy link
Collaborator

kylejrp commented Apr 12, 2019

There's already a separate issue for scrollbars (#14) but I'm more concerned with the general case of vendor specific features. The scrollbars are just one example.

What should be our stance for when a vendor implements a new feature without it being in Working Draft or Spec? I'm only finding selectors (eg. -webkit-text-stroke) that are non-standard and vendor specific, so I can't find another great example, but I'm sure there's some out there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@philsherry @kylejrp @jonaskuske @kognise