Remove HTMLAreaElement.hreflang and .type

[foolip]

There's a review to add HTMLAreaElement.hreflang in Blink: https://codereview.chromium.org/1381913002/

However, it doesn't look like the hreflang attribute is actually used internally, and no other engine exposes the HTMLAreaElement.hreflang attribute, while HTMLAnchorElement.hreflang appears to be universally supported.

The situation is the same with HTMLAreaElement.type.

[annevk]

I tend to think we should either keep them on both, or obsolete them on <a>. I don't like the muddy middle ground.

[foolip]

If you mean merely moving them to the obsolete section, then that sounds fine to me, but trying to remove things already shipping on HTMLAnchorElement doesn't seem worthwhile.

[foolip]

I'd be interested to know if the hreflang or type content attributes have any effect in any browser. It's not super grep-friendly, but I can't find anything in Blink.

[zcorpan]

My understanding is that these don't do anything on a/area, they just exist as a styling hook or for other tools.

[foolip]

I see that HTMLLinkElement also has hreflang and type. If we obsolete these IDL attributes, should the content attributes remain valid?

[annevk]

Technically user agents were supposed to create all kinds of cool UI around these attributes, but they didn't. So I would say that the content attributes should also move. However, link might have processing requirements related to type.

[foolip]

Right, for the link element it looks like type="application/opensearchdescription+xml" has special behavior in Blink.

[annevk]

Yeah, so my tentative proposal would be that we obsolete hreflang on all three, and type on a and area. We'd need to raise that on the list though.

[foolip]

Do you think we should make them obsolete but conforming, or non-conforming?

[annevk]

I'm not sure. They are useless since there's no support. But we might not want to annoy folks that have added them anyway with validator messages.

[zcorpan]

I see 14,347 instances of hreflang on link/a/area in webdevdata.org data set 2015-01-08 (780 Mb) 87,000 pages.

1,161 instances of type on a/area.

I don't think we should obsolete these, that seems like wasting authors' time, similarly to obsoleting <samp> would (which is less common, 175 instances). Implementing the missing IDL attribute is relatively low cost, isn't it?

[foolip]

It's very low cost, by why must we have the IDL attributes just because we can't emit validator warnings?

[annevk]

@zcorpan what is wrong with obsolete but conforming? They don't anything useful after all.

[zcorpan]

Things in the spec are obsolete but conforming because we want the validator to issue warning (but not error). I don't think that is good here. Saying that it is obsolete but conforming but validators shouldn't whine about it, either, seems confusing. How do you explain samp being conforming but hreflang obsolete when the latter is almost two orders of magnitude more common?

The IDL attributes should be there for consistency; I consider it a bugfix from HTML4.

[zcorpan]

cc @sideshowbarker

[annevk]

Maybe we should drop samp too. There's really not much point in explaining and promoting features that bring no benefit when used.

[domenic]

Does the spec always have IDL attributes corresponding to valid content attributes? I guess since we removed the microdata API that's no longer strictly true, right? Are there other cases?

[annevk]

ARIA and manifest="".

[zcorpan]

Also charset on meta. But in general there are IDL attributes for content attributes.

We could remove the not-implemented IDL attributes from the spec but still leave the attributes as conforming, saying that this is a historical quirk and you have to use setAttribute for these (although personally I would prefer to have the IDL attributes implemented, since people use these attributes).

[annevk]

I still think we should also dissuade folks from the notion that they might be useful. Obsolete, but conforming seems fine. The validator can simply opt not to show a warning for them since they're harmless.

[foolip]

Given that these are currently interoperably non-implemented, I don't think going through a period of many years where some browsers have the reflected IDL attributes and others don't would be worthwhile. A "all conforming content attributes should be reflected" design rule doesn't seem important enough to me, at least.

I think the "obsolete but conforming" category seems fine, so that we continue to say "all conforming content attributes should be reflected".

[domenic]

I'm OK with removing the IDL attribute since there's precedent. But there are a lot of attributes that don't do anything useful according to user agents, but are useful hooks for scripts, styles, or other parts of the ecosystem. (E.g. microdata, cite attribute, datetime attribute, ...) I don't see any reason to mark this as obsolete.

[foolip]

OK, I've submitted a pull request that merely removes the IDL attributes. Does there need to be an explanation of why the IDL attributes are missing?

Note that the spec still says "The rel, hreflang, and type attributes may be used to indicate to the user the likely nature of the target resource before the user follows the link" for both the a and area element.

[annevk]

@domenic I guess I did not articulate things carefully enough. The precedent for missing IDL attributes all were carefully considered. None of them were omitted due to not being implemented (in fact, Chrome at some point supported <html>.manifest). They were omitted because that would not make sense, .e.g., manipulating <html>.manifest or <meta>.charset has no meaningful effect.

What we have now does not make sense and has created a logical inconsistency.

[foolip]

We could make these attributes non-conforming for just area, that ought not affect very many pages assuming that area itself isn't common. Other ideas?

[zcorpan]

In webdevdata I see 37 instances from two sites, skoda-club.ru (uses <area type="rect" ...>, should be shape) and agriaffaires.it (uses area hreflang for the flags in the footer).

[foolip]

About how many pages are in that data set in total?

[zcorpan]

87,000 pages

[foolip]

OK, so the outrage of making these non-conforming would probably be very small. @annevk, does that sounds OK, or do you have some other preference?

[annevk]

It still seems weird to have our hyperlink elements diverged again, but it seems somewhat better than the new status quo.

[foolip]

I basically think that all options are better than having implementations diverge by fiddling with attributes that don't actually do anything at all.

Proposal:

• Also remove the hreflang and type content attributes for area, accepting some very small amount of validator warnings for this.
• Make hreflang and type on a obsolete but conforming, moving the HTMLAnchorElement.hreflang and type IDL attributes to https://html.spec.whatwg.org/#other-elements,-attributes-and-apis

This would put hreflang and type in the same category as the charset and name attributes for a.

Objections?

[sideshowbarker]

Proposal:

Also remove the hreflang and type content attributes for area, accepting some very small amount of validator warnings for this. Make hreflang and type on a obsolete but conforming, moving the HTMLAnchorElement.hreflang and type IDL attributes to https://html.spec.whatwg.org/#other-elements,-attributes-and-apis This would put hreflang and type in the same category as the charset and name attributes for a.

Objections?

No objections from me. All sounds reasonable

[zcorpan]

This would put hreflang and type in the same category as the charset and name attributes for a.

Not quite; charset is obsolete on both a and link.

I see 2,565 hreflang on a in webdevdata. 3 charset on a. 36,150 name on a.

I think I would prefer to make hreflang and type obsolete for only area, and leave them conforming for a and link. The motivation is that there is usage for a and link and there is no harm for those. This also aligns the conformingness to which IDL attributes are implemented, and happens to match what was conforming in HTML4.

[annevk]

You don't think consistency between a and area is more important than between a and link? I guess it's messy either way.

[zcorpan]

I think it is, but that is not the only consideration, and I think it is less important than making people spend time thinking about what they should do about their hreflangs if we make it obsolete (or if they should stop caring about validation).

[foolip]

My suggestion was "Make hreflang and type on a obsolete but conforming" so that shouldn't change anything about validation. Only the content attributes on area would be affected, and it doesn't seem like there's very much of that out there.

[zcorpan]

Currently things are obsolete but conforming because we want validators to give a warning (but not an error). I want no message for a hreflang, which in my view maps to conforming. Making things be obsolete but conforming but not give a validator message is imo more confusing, and I don't see much benefit.

[foolip]

OK, I just didn't read past the heading of "Obsolete but conforming features", the first paragraph says "Features listed in this section will trigger warnings in conformance checkers."

I guess we don't have a category of things that are useless and harmless. Unless we introduce such a category, we have to chose between two different forms of inconsistency:

• The area element having hreflang and type content attributes, but no corresponding IDL attributes. (The current situation, after https://github.com/whatwg/html/issues/236)
• The a and area elements diverge also in their content attributes. (If we remove hreflang and type entirely from area.)

I'm really fine either way, or perhaps there are other options. If anyone feels strongly, please make a very concrete suggestion :)

[zcorpan]

Yes. I'm also fine with either of those. @annevk you didn't like the current spec text, are you OK with the other option?

[annevk]

I'm happier with the second option. To have a and area diverge. Perhaps we should consider not making "Obsolete but conforming" trigger warnings though, if we're so afraid of warnings.

[zcorpan]

I don't mind warnings for things where it is useful to make people think about changing their markup, e.g. change <a name> to id (<a name> is a lot more common than <a hreflang> still), but I think commonly used useless and harmless things don't belong there.

[annevk]

<a name> is harmless in much the same way. Folks might know about id and just not want to bother updating legacy content.

[sideshowbarker]

For the record here (I know this issue is resolved now), in implementing warnings in the Nu HTML Checker, I take statements about warnings in the spec to be somewhat advisory (I think we currently implement most of the ones it defines, though not all), so there is room for a gray area here with regard to whether or not to emit warnings for particular cases. And incidentally as I’ve noted in other places, we also emit some warnings that are not necessarily directly associated with any specific requirements in the spec. So the warning-level messages from the checker are already somewhat discretionary in practice, and we can avoid emitting warnings for particular obsolete-but-conforming cases if the prevailing agreement is that’s what we should be doing.

[foolip]

@sideshowbarker, does that mean that you would support making hreflang and type on a obsolete but conforming, while not emitting any warnings for them? If so, maybe we should also s/will/can potentially/ in "Features listed in this section will trigger warnings in conformance checkers."

[sideshowbarker]

@sideshowbarker, does that mean that you would support making hreflang and type on a obsolete but conforming, while not emitting any warnings for them?

Yes, if that's what you and @zcorpan and @annevk and @domenic think would be the best way to deal with it.

If so, maybe we should also s/will/can potentially/ in "Features listed in this section will trigger warnings in conformance checkers."

Yes, some wording refinement like that would be appropriate, I think.

[zcorpan]

I'm a bit confused about what the goal of that section would be if not to trigger warnings in validators. Is it to avoid having people who write tutorials include the feature? Something else?

[foolip]

The point would be to hide useless features from view, much like the things in https://html.spec.whatwg.org/#Document-partial

[prlbr]

I see that the issue is closed and hreflang has fortunately not been removed from the link element. So just for the record: It is not useless! While browser may not make use of these attributes, Google and possibly other search engines "use the rel='alternate' hreflang='x' attributes to serve the correct language or regional URL in search results".

https://support.google.com/webmasters/answer/189077?hl=en

[zcorpan]

Yeah, I don't think it has been suggested to obsolete it for link in particular. If search engines do something for <a hreflang>, that would be interesting to this discussion. It look like from the link above like it's just <link hreflang>.