Require navigator.productSub to be either "20030107" or "20100101"

[foolip]

WebKit-like engines use "20030107" and Gecko uses "20100101".

This is better than nothing, but worse than a single value. At this
time it seems hard to actually converge on a single value, however.

Fixes https://www.w3.org/Bugs/Public/show_bug.cgi?id=27954

[zcorpan]

Do we not want this to depend on what the user agent string contains?

[foolip]

Yeah, that would be better, I think. There's no internal concept for what navigator.userAgent returns, OK to just say "If the User-Agent header contains the string 'WebKit' ..." or similar? That would make the Gecko case look like the default although it's in the minority, but I don't think that's a big issue.

[foolip]

There's a bigger issue here of documenting how e.g. navigator.vendor depends on the other values. taintEnabled() has the same issue, but there the method shouldn't be exposed at all by non-Gecko browsers, so that can't be expressed with prose.

(For these purposes I think we have 3 classes of user agents left: Gecko, WebKit, and Chromium.)

[zcorpan]

We can introduce a concept and use it for this and taintEnabled()

[annevk]

Yeah, however, how is that not going to be a slippery slope? Will we avoid using it outside the legacy Navigator stuff?

[zcorpan]

That's a risk. Certainly we should advice against using it, but if something non-Navigator ends up having the same fate as taintEnabled() and doesn't show signs of fixing itself, it seems as reasonable for it to use this as for taintEnabled(), I think.

On the face of it, this seems like it goes against interop, but OTOH, having it documented how these things depend on each other might make it possible for a browser to change all features at once (like Edge changed from "IE" to "WebKit") or for new engines (e.g. Servo) to get a Web-compatible set without spending resources reverse-engineering others for this.

Finally, defining things with multiple conforming alternatives, or leaving undefined even, has been done in the past and it hasn't caused us to slip down that slope yet. So long as interop is one of the primary goals of the spec, I don't think we need to worry too much about this slope.

[foolip]

Specifying this is certainly a failure of sorts, but on balance I think it's a good thing to document the compat constraints, not least because that could then be tested in web-platform-tests and that could catch some gratuitous diversification like when Opera changed navigator.vendor.

The only two big buckets now remaining are Gecko and WebKit, and WebKit can be divided into Chromium and non-Chromium. Not sure if we should define the buckets in terms of the User-Agent header or vice-versa, any thoughts?

[annevk]

I think you should define a concept of sorts. Maybe "navigator compatibility mode"? And that mode is one of Gecko/WebKit/Chromium. And then for each feature affected by this, we branch on that mode. I think this is basically what @zcorpan suggested, but a tad more explicit.

[foolip]

OK, that SGTM, I'll give that a try, probably first converting navigator.vendor to use that concept.

[domenic]

So this is being rolled in to #207?

[annevk]

No, this will build on top of that one. That one is just a refactoring to pave the way.

[foolip]

This has now been rebased to make use of the compat mode, PTAL.

[zcorpan]

LGTM