Hacker News Reader

Comment by hsn915 | Hacker News Reader

I meant more broadly, the header level number should be derived from its nesting level without you specifying it explicitly. This gives you more freedom to re-arrange (refactor?) the text without having to mass-edit header levels.

View on HN

This is what annoys me the most when developing web components. You never know which context your component might be used in, and your <hX> element might be just plain wrong.

I prefer not using them and fall back to using <header> elements inside sections, but styling them globally makes it rather difficult and ugly to work with. What's other people's solution to this? Or am I just picky when it comes to semantics?

You could define a recursion depth parameter for your component. Or a specific header level parameter. I tend to think of spitting out HTML as something with recursive context. The CSS grid and even flex layouts come to mind as well.

If it's super broken or critical, maybe a slot to let the user provide their desired header level would be an option? Or maybe even a simple prop would be enough. If your component is itself header-like, perhaps making 6 versions, fun-header-1, fun-header-2, etc. that are explicitly scoped to that level header would make sense too.

HTML5 allows this, per the spec. Seems that it's not always implemented properly, though.

Specifically, this is the document outline algorithm. But it’s not so much “not always implemented properly” as “not implemented at all”. No user agent has implemented it or seems likely to, and I don’t know of anything other than conformance checkers that implements it. https://github.com/whatwg/html/issues/83 shows a bit of the discussion that’s gone on; whether to remove it, simplify it drastically to the point that it’s actually sanely implementable, &c.

Reply on news.ycombinator.com