This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27800 - Lang attribute of spec itself should remove -x-hixie private use sub-category
Summary: Lang attribute of spec itself should remove -x-hixie private use sub-category
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
Depends on:
Reported: 2015-01-11 23:26 UTC by Adrian Roselli
Modified: 2015-01-15 23:33 UTC (History)
2 users (show)

See Also:


Description Adrian Roselli 2015-01-11 23:26:49 UTC
The <html> tag of the page at (and its related pages/URLs) has the following @lang: en-GB-x-hixie

-x-Hixie is a private-use sub-tag (-x denotes the start of a private-use sub-tag).

W3C states [1] that:

Private-use subtags do not appear in the subtag registry, and are chosen and maintained by private agreement amongst parties.

Because these subtags are only meaningful within private agreements and cannot be used interoperably across the Web, they should be used with great care, and avoided whenever possible.

Further, IETF BCP 47 Section 2.2.7 [2] states:

   5.  No source is defined for private use subtags.  Use of private use
       subtags is by private agreement only.

   6.  Private use subtags are NOT RECOMMENDED where alternatives exist
       or for general interchange.  See Section 4.6 for more information
       on private use subtag choice.

Given that the HTML spec is public and -x-Hixie seems to be more about vanity than having some functional value, I recommend removing the sub-tag altogether and leaving the @lang as en-GB.

Comment 1 Ian 'Hixie' Hickson 2015-01-13 23:06:32 UTC
It's not about vanity, it's the only version of English that has a normative spec, and that's the version the spec uses.

Does it cause any harm?
Comment 2 Adrian Roselli 2015-01-15 15:38:46 UTC
It is my understanding that the lang attribute should reference the language in which the page is written, not the nearest match to a normative spec.

If the page was written in American English, then using en-GB would be misleading to how screen readers and other tools that parse the language (which uses @lang for pronunciation cues, for example). If the spec is written in British English, then en-GB part of the @lang is appropriate.

That doesn't support the private-use sub-tag, however.

To your question about whether it causes any harm, I don't know. It may (owing to bugs in SR implementation). I cannot test all the screen readers currently in use and verify that no harm is caused. I would instead err on the side of caution and omit the private-use sub-tag since it doesn't appear to offer additional benefit to readers. Unless (citing a normative spec):

1. There is a private agreement in place (which I assume would be signed on to by all members of WHATWG).

2. There is a compelling reason that the spec is not considered to be for general interchange.
Comment 3 Ian 'Hixie' Hickson 2015-01-15 20:17:30 UTC
The spec is written in Hixie English, British variant. This seems to me the most accurate way of denoting this. It's also funny (though less and less the more we're discussing this). Unless it causes actual harm, I'm not inclined to change this.
Comment 4 Adrian Roselli 2015-01-15 22:18:50 UTC
I agree that it's funny. I had a chuckle when I saw it, as I have done similar things when developing projects. They never go to production, however.

I suspect we've already spent more time on this than it would take to yank it out of the templates. I've seen developers challenge and stall before to make this very argument, so I already know how this ends.

I've made my case. I think it doesn't belong in a standards document, sends an odd message given the description of the private-use sub-tag, and carries the risk (however small) of adversely affecting some AT users with no corresponding benefit to any end users. I've seen no arguments to counter any of this ("becoming less funny" isn't one).

I hope that you reconsider your position the next time you are updating templates, as then it's a negligible amount of extra time to correct.
Comment 5 Ian 'Hixie' Hickson 2015-01-15 23:33:07 UTC
If there's a concrete harm, I'm absolutely happy to change it.

In the meantime, I'm going to leave it. (It's not in a template, by the way; it's right there at the top of the source file. Changing it would be trivial.)