The W3C HTML spec is broken, and probably shouldn't be referenced

[bzbarsky]

I was pretty confused by https://www.w3.org/TR/html51/browsers.html#relaxing-the-same-origin-restriction step 7.2, as referenced from https://w3c.github.io/webauthn/#dom-webauthentication-makecredential step 3, because it's completely nonsensical: it causes the algorithm to always throw.

Then I realized that this is the W3C version of the HTML spec, which has all sorts of known issues like this. For comparison, https://html.spec.whatwg.org/multipage/browsers.html#relaxing-the-same-origin-restriction step 7.2 is correct...

Please reference the things that actually have the behavior you want. I guess if you have to reference W3C HTML, that makes it your problem to check that it has the behavior you want and push on its editors to fix it if it does not.

[bzbarsky]

Oh, and in particular, browser implementors are, as far as I know, implementing from WHATWG HTML, not W3C HTML. As a result, if you reference the latter there is a good chance that your spec won't match what actually gets implemented, if they instead substitute the behavior of the former... Worse yet would be if different implementors handled this differently and ended up with incompatible implementations.

[equalsJeffH]

see also:
RE: referencing W3C or WhatWG specs (was: [webauthn] new commits pushed by equalsJeffH
https://lists.w3.org/Archives/Public/public-webauthn/2016Sep/0313.html

[bzbarsky]

It's up to you (the WG working on webauthn) if you want to reference W3C HTML, as I said. But then you will have to do due diligence on whether it actually says what you want it to say, because it has a history of all sorts of bugs that get introduced during the forking process.

In the end, of course, either the tests that will presumably be written to test webauthn will catch issues, or the tests won't reflect what the spec actually says (and UAs that try to implement what the spec does say will discover the hard way that it doesn't mean what it says). It's going to be a giant waste of everyone's time either way, of course...

[AngeloKai]

I filed a issue on the W3C HTML spec repo. @bzbarsky thank you for catching it!

[bzbarsky]

Fwiw, I had done that too: w3c/html#705

The real problem is that they keep reintroducing these sorts of issues...

[equalsJeffH]

So, what this issue is illustrating, is that our present web-spec-citation approach, as instigated here by @vijaybh may have submerged, unapparent issues.

At this point, my vote is to reference whatwg specs as necessary and then hopefully at CR time @wseltzer & co will have figured out a remediation regarding the overall w3c <--> whatwg spec issue. if they have not, then we can, if we have to, revise the references to be to W3C specs in order to jump thru the CR hoop.

[wseltzer]

@equalsJeffH not sure I'm drawing the same conclusion. HTML5.2 is fixing issues, and if they're not, team can help keep the pressure on them. I think this one is already in 5.2

/cc @plehegar

[equalsJeffH]

@wseltzer thx, yes, it appears the fix to the particular problem @bzbarsky raised is in HTML 5.2 https://w3c.github.io/html/

so you are proposing we reference HTML 5.2 https://w3c.github.io/html/ as we go along, and only reference whatwg specs if there is no corresponding technically-equivalent W3C spec at the time?

It does look like HTML 5.2 transitively references to whatwg encoding, fetch, and URL specs.

So, maybe this will work. we ought to update present whatwg refs (eg those that @jcjones is adding in #314) to try it out.

[equalsJeffH]

@wseltzer hm, so the above plan to ref HTML 5.2 will not work in all cases, because HTML 5.2 does not itself directly define/embody some things that we need to reference [1] -- eg host parser algorithm, domain (#concept-domain in URL), IPv4 address, IPv6 address -- rather, HTML 5.2 refers directly to https://url.spec.whatwg.org/

[1] in PR #314 07c4d52

[domenic]

Another tactic you can use is to reference the HTML Standard in the EDs (which people implement off of), and then when going through the Process, ask those who would otherwise Formally Object (e.g. W3C staff) to change all the references to the fork, for the purposes of CR/REC/etc. But leave the ED referencing what implementers actually use.

[wseltzer]

where HTML5.2 makes reference to other specs, we're free to refer to them as well. Let's try to miminize the mandatory-rewrites-at-CR.

[jyasskin]

FWIW, I'd endorse @equalsJeffH's proposal in #257 (comment) (which @domenic also endorsed) to have this spec's editor's draft reference the WHATWG HTML spec, and then redirect the references for the more formal publication steps. Even if HTML5.2 picks up all the bugfixes made in the WHATWG spec (which we should keep pushing for), it'll lag a bit, which will impede changes like #319.

The changes at CR should just consist of adding an anchors block with all the HTML references, and might be even smaller if Bikeshed grows an automated way to do that, maybe related to https://tabatkins.github.io/bikeshed/#metadata-default-biblio-status. (@tabatkins?) Assuming HTML5.2 keeps doing a good job of tracking the WHATWG spec, there shouldn't be any need for rewriting.

[tabatkins]

Bikeshed is explicitly not letting [[HTML]] refer to the W3C version right now, because it (the spec) is broken. You can ref specific versions of it by using more specific names from SpecRef if you need to, tho.

[jyasskin]

@tabatkins I was more asking if there's a way to explicitly and in bulk redirect uses of [=current settings object=] and other HTML terms to https://www.w3.org/TR/html52/webappapis.html#current-settings-object, etc. instead of https://html.spec.whatwg.org/multipage/webappapis.html#current-settings-object, etc. Right now the only way I know of is to <pre class=anchors> each one individually.

I totally agree with the default policy of pointing them to the WHATWG's spec, but I also want to be practical as things move through the W3C's REC process.

[tabatkins]

There is intentionally not. You want to point to a broken spec, you have to do it on purpose.

[jyasskin]

@tabatkins Thanks for the clarity. :)

[AngeloKai]

The spec has references to both W3C and WHATWG HTML spec. There are way too many references to keep track now. This is a political issue still heavily discussed in the HTML specs world. If they come up with a result, they should come back and tell us whether they intend to change all the references to the W3C HTML specs in all the existing W3C specs. Closing the issue. This is not in scope for us to discuss.

[tabatkins]

Ignoring the dismissal of this as "political", was the issue raised in the OP actually addressed? That is, is the "make credential" algorithm now pointing to a correct algorithm, in whatever spec it happens to be referencing?

(The link in the OP is broken, so I'm not sure if the question is moot, or if it was just renamed and accidentally broke links.)

[bzbarsky]

The TR version of W3C HTML at https://www.w3.org/TR/html51/browsers.html#relaxing-the-same-origin-restriction still has an incorrect algorithm.

The editor's draft at https://w3c.github.io/html/browsers.html#relaxing-the-same-origin-restriction has been corrected.

The webauthn spec at this point links to https://html.spec.whatwg.org/multipage/origin.html#is-a-registrable-domain-suffix-of-or-is-equal-to from its definition of https://w3c.github.io/webauthn/#relying-party-identifier and hence is not affected by the brokenness of the w3c html spec for the specific issue I have reported.

That said, linking to both the whatwg spec and the w3c spec may cause problems of its own, because the two specs may have mutual contradictions... caveat linker.

[nadalin]

@AngeloKai please close per call today

[AngeloKai]

@nadalin The issue was closed 5 hours ago already.