hgroup element removal

[JohnnyWalkerDigital]

This was first raised over two years ago (here: #180). It's been raised several times since then: #268 #227 #316 #317. However, most of these are simply posts telling people to read #180. Things have changed since this was first raised, including the fact that the hgroup element has now been formally removed from the final HTML5 spec (http://www.w3.org/TR/html5/obsolete.html), so I thought I would try and raise a modern discussion about it.

The only argument I've read for keeping this obsolete element in Normalize.css is this: Some people have previously used it (before the HTML5 was finalised), and so future versions of Normalize.css should support these people.

Personally, I think this seems backwards facing. I fully support attempts at pushing both users and developers to use modern tools and standards.

Regardless of what I think, however, I'd love to hear what others have to say.

Thanks a lot.

[Volker-E]

👍

[Alhadis]

Fully agreed.

In fact, I wasn't even aware hgroup is still used in Normalise.css (I use a compressed copy for my work). Removing it from my boilerplate.

[LasseRafn]

I just realised it after looking at the code. I think removing it is the only correct thing to do.

[alwillis]

A couple of points:

• It may have been removed from W3C's spec for dubious reasons, it's still in WHATWG's "Living Standard", updated September 1, 2015.
• It's also on Mozilla's HTML reference, with this pragmatic note:

This element has been removed from the HTML5 (W3C) specification, but it still is in the WHATWG version of HTML. It is partially implemented in most browsers, though, so is unlikely to go away. As the outline algorithm is not implemented in any browsers, the hgroup semantics are in practice only theoretical.

Translation: it's not hurting anybody; if it appears in markup, it's no big deal, so don't worry about it.

Personally, I'd just leave it alone…

[Volker-E]

Hi @alwillis, what you're referring to as "Mozilla's HTML reference" is in it's fundamentals a wiki, where everybody can participate in and Mozilla might go over certain contributions or take care of certain articles in doubt.
If you're looking into the history of the article, the latest contribution, altering the paragraph that you're citing, comes from well-respected @stevefaulkner -- he was also participating in #180.

hgroup was not removed by dubious, but for good reasons.

[alwillis]

I don't want to rehash the whole thing; the point I was making is hgroup is still in WHATWG's living specification and that should count for something regarding what Normalize should address.

As a web developer, I’m familiar with @stevefaulkner and his work; however, I don't believe one person should be able to change what's supposed to be a global, open, and consensus-driven specification just because he disagrees with it.

[Volker-E]

Ok, I wasn't by any means saying that one person should or is able to change a specification, nor does any of the links I've included. But your reference to MDN made it look like it's one of the places for looking for the definitive answer, whereas it is IMHO a consensus based collection of knowledge, partly clarified by employers of one of the big browser vendors.

For the decision here, it should be taken into account what

1. the standard says (and that's for me preferably W3C over WHATWG for historical reasons and for following points in this special case),
2. the browser vendors implemented and
3. the vast majority of developers are using.

Otherwise normalize is handling a rare edge case, and that should be up to the single developers on rare edge cases.

[stevefaulkner]

@alwillis On this point, which is an unecessary mischaracterisation:

I don't believe one person should be able to change what's supposed to be a global, open, and consensus-driven specification just because he disagrees with it.

<hgroup> was removed by consensus, it was not added by consensus, The whatwg spec is by design NOT developed via consensus, so please take the time to understand reality before making such assertions.

In regards to including CSS rules for hgroup in normalize.css, I see no issue, note that although it is obsolete in HTML5 the parsing rules and UA default CSS advice for it remains in the spec as do the rules for other obsoleted elements such as <font> or <center>

[alwillis]

In regards to including CSS rules for hgroup in normalize.css, I see no issue, note that although it is obsolete in HTML5 the parsing rules and UA default CSS advice for it remains in the spec as do the rules for other obsoleted elements such as or

I agree with that no issue is caused by leaving hgroup in Normalize. If anything, leaving it in may prevent potential unexpected behavior in the future if a developer's CSS is based on the current version of Normalize styling hgroup as display: block in IE 8/9 upgrades to a version of Normalize missing hgroup styling.

[JohnnyWalkerDigital]

Thanks to all the responses. They make interesting reading.

In regards to including CSS rules for hgroup in normalize.css, I see no issue, note that although it is obsolete in HTML5 the parsing rules and UA default CSS advice for it remains in the spec as do the rules for other obsoleted elements such as <font> or <center>

I don't quite follow the logic here. Should we include of <font> and <center> in Normalize.css? I understand the argument that keeping hgroup that "does no harm", but personally I think it's imperative that industry standard tools (like Normalize.css) push their users to adopt the latest standards. Standards are what help us embrace and develop using new technologies quickly, and without issue. The push for the standardisation of HMTL is what has lifted us out of the Internet Explorer doldrums of yesteryear, and I have no desire to return to them.

Although I acknowledge there is no real world harm at the moment, I do think that allowing developers to decide for themselves which elements they wish to use, regardless of their status within agreed standards, is step backwards. It does not help the industry, other developers, or ultimately, their customers.

Just my personal view on the matter.

[alwillis]

Providing styling for a hgroup, an element previously standardized by W3C and is still a recognized element by the most current WHATWG HTML 5.1 living standard is nothing like providing styling for FONT or any of the other proprietary tags put forth by Microsoft and Netscape back in the day.

Normalize is supposed to be about giving developers a consistent starting point for CSS across a wide variety of browsers; not about the politics of browser standards or telling developers what they should and shouldn’t do.

Normalize styles hgroup as a block element for browsers that don't themselves provide styling in the UA’s default stylesheet even when hgroup was fully supported by all standards bodies. That’s it.

And there’s nothing about that prevents developers from using current or future standards.

Providing styling for hgroup is just being thorough while proving for compatibility with both recognized HTML standards while not interfering anything else that might become a standard in the future.

— Al

On Sep 4, 2015, at 6:40 AM, Johnny Walker [email protected] wrote:

Thanks to all the responses. They make interesting reading.

In regards to including CSS rules for hgroup in normalize.css, I see no issue, note that although it is obsolete in HTML5 the parsing rules and UA default CSS advice for it remains in the spec as do the rules for other obsoleted elements such as or

I don't quite follow the logic here. Should we include of and

in Normalize.css? I understand the argument that keeping hgroup that "does no harm", but personally I think it's imperative that industry standard tools (like Normalize.css) push their users to adopt the latest standards. Standards are what help us embrace and develop using new technologies quickly, and without issue. The push for the standardisation of HMTL is what has lifted us out of the Internet Explorer doldrums of yesteryear, and I have no desire to return to them.

Although I acknowledge there is no real world harm at the moment, I do think that allowing developers to decide for themselves which elements they wish to use, regardless of their status within agreed standards, is step backwards. It does not help the industry, other developers, or ultimately, their customers.

Just my personal view on the matter.

—
Reply to this email directly or view it on GitHub.

[stevefaulkner]

most current WHATWG HTML 5.1 living standard

you are getting your specs mixed up

the WHATWG HTML standard is unversioned

The latest W3C HTML specification working draft is 5.1 http://www.w3.org/TR/html51/
and in it <hgroup> is still obsolete.

As a side note I recently raised a related issue on the WHATWG HTML spec in regards to the outline algorithm and there is suggestion that the algorithm and the section element will be dropped from the WHATWG HTML along with hgroup (as it was added to support the algorithm).

[alwillis]

you are getting your specs mixed up

the WHATWG HTML standard is unversioned

The latest W3C HTML specification working draft is 5.1 http://www.w3.org/TR/html51/
and in it

is still obsolete.

True—the WHATWG HTML standard isn’t versioned; what I meant was as of today, hgroup is in WHATWG’s HTML standards document.

To me, the issue isn’t so much about that; Normalize is supposed to give a sane staring point for styling CSS across different browsers, including applying display: block to elements in some browsers that neglected to do that in their default stylesheets. That’s it.

Here’s WebKit’s default stylesheet; line 50 styles hgroup to display: block; Normalize does this for browsers (like IE 8 and 9) that neglected to do so. Normalize addressing this shouldn’t be controversial IMHO.

[alwillis]

Standards are what help us embrace and develop using new technologies quickly, and without issue. The push for the standardisation of HMTL is what has lifted us out of the Internet Explorer doldrums of yesteryear, and I have no desire to return to them.

It’s kind of disingenuous and misguided to suggest setting hgroup to display: block—something every current browser’s default stylesheet does—in Normalize is the path that leads back to the days of the wild west of browser standards.

Since the most current versions of Chrome, Firefox, IE 11, Edge and Safari all set hgroup to display: block, it’s probably okay that Normalize does it for browsers like IE 8 and 9, which should have done the same thing but neglected to do when they were released. IE 8 and 9 are still over 10% of global browser use.

hgroup haters—don’t worry; if things stay on the their current path, even WHATWG will eventually disavow hgroup and a year or two after that, Google, Mozilla, Microsoft and Apple will remove support for it from their codebases and Normalize 5.0 (or whatever) can drop it too. But we’re not there yet.

[stevefaulkner]

hgroup haters—don’t worry; if things stay on the their current path, even WHATWG will eventually disavow hgroup and a year or two after that, Google, Mozilla, Microsoft and Apple will remove support for it from their codebases and Normalize 5.0 (or whatever) can drop it too. But we’re not there yet.

Hi Al, please tone down the rhetoric, it's not helpful. You appear to misunderstand how standards and implementations in browsers work, even if the whatwg spec obsoletes hgroup, browsers will not remove default styling and parser support for it as long as there are statistically significant instances of its use on the web, the same as for the many other elements and attributes that have been implemented in browsers and later been made obsolete in HTML

[alwillis]

You appear to misunderstand how standards and implementations in browsers work…

Appearances can be deceiving.

Steve, I was just being sarcastic; I know the default styling and parsing won’t change, for example, as I may have implied in my mini-rant. But I also didn’t expect it to be taken literally either. Before I became a full-time web developer, I worked many years in MIT’s main IT organization; believe me, I get what means to change the support status of something and the the details regarding that.

What you didn’t mention is what I wrote in all seriousness that was intended to understood as I wrote it, which was is factual and not sarcasm:

Since the most current versions of Chrome, Firefox, IE 11, Edge and Safari all set hgroup to display: block, it’s probably okay that Normalize does it for browsers like IE 8 and 9, which should have done the same thing but neglected to do when they were released. IE 8 and 9 are still over 10% of global browser use.

Hopefully we can move on from this now?

[jonathantneal]

Since <hgroup> has already been deprecated in both specifications, Normalize.css can deprecate <hgroup> in the next release, and then remove it in the release after that. It will be resolved and handled in a responsible, semver fashion.

If there is an issue with how things are deprecated or removed from Normalize.css, I think it’s fair to create a new issue for that. If there is an issue with the spec, that is pretty out of scope for Normalize.css to resolve.

[battaglr]

If there is an issue with how things are deprecated or removed from Normalize.css, I think it’s fair to create a new issue for that. If there is an issue with the spec, that is pretty out of scope for Normalize.css to resolve.

Thank you!

[alwillis]

On Sep 5, 2015, at 1:30 AM, Jonathan Neal [email protected] wrote:

Since

has already been deprecated in both specifications, Normalize.css can deprecate in the next release, and then remove it in the release after that. It will be resolved and handled in a responsible, semver fashion.

In all seriousness, how can you say that when it’s clearly still in the WHATWG specification: https://html.spec.whatwg.org/multipage/semantics.html#the-hgroup-element. There’s not even a note or a warning suggesting it might be removed at some point. Just saying.

[LasseRafn]

Okay, let's just remove this issue, seems like we're going nowhere. I'll personally just continue to remove it from Normalize whenever I use it; mainly because I NEVER - in my entire life - used

[JohnnyWalkerDigital]

Providing styling for a hgroup, an element previously standardized by W3C and is still a recognized element by the most current WHATWG HTML 5.1 living standard is nothing like providing styling for FONT or any of the other proprietary tags put forth by Microsoft and Netscape back in the day.

The <font> element is actually a valid part of the W3G HTML 3.2 specification. Conversely <hgroup> has never been part of the HTML 5 specification. It was featured in a draft of HTML 5 (used by many eager developers wanting to move on from XHTML, with the knowledge that the specification wasn't finished), but dropped before finalisation. It has never been standardised HTML 5.

Edit: Clarified my point better. I initially made a few mistakes -- claiming hgroup had never been part of any HTML specification.

[alwillis]

It has never been standardised HTML.

And yet here’s a description of <hgroup>, as plain as day, in section 4.3.7 of the most current WHATWG specification.

And for something that you claim has never been standard HTML, Chrome 45, Firefox 40, Safari 9.0 and Edge provide styling for <hgroup> in their default stylesheets.

[JohnnyWalkerDigital]

Sorry Al, I miswrote in my last post. My apologies. I was on my phone and should have waited until I was back at my desk. I meant to say that <hgroup> has never been part of the finalised HTML5 specification. As you have already correctly pointed out in this discussion, it does exist in the WHATWG "Living Standard" specification of HTML (note the lack of a version number -- WHATWG does not do versions of HTML as part of its spec). It has never been part of HTML5 (the standard set down by the W3C), however.

I suppose if you subscribe to the WHATWG version of HTML, then <hgroup> is still valid, and it should remain in Normalize.css. As a developer, however, I think most of us follow the W3C spec as it is doesn't change as frequently, allowing for things to be clearly defined long enough for us to use them without too much worry about UA support, but maybe I'm wrong about that.