W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > September 2019

[mediacapture-main] getUserMedia() and getSupportedConstraints() don't have useful `lt` values (#621)

From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
Date: Mon, 09 Sep 2019 22:21:38 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issues.opened-491354683-1568067697-sysbot+gh@w3.org>
tabatkins has just created a new issue for https://github.com/w3c/mediacapture-main:

== getUserMedia() and getSupportedConstraints() don't have useful `lt` values ==
So, this *looks* like a problem in ReSpec itself, not the spec document, but for whatever reason, the `dfn` for getUserMedia() has busted/incorrect `lt` values.

In particular, in the rendered source, it has `data-lt="mediadevices.getusermedia()|mediadevices.getusermedia|getusermedia()|getusermedia"`.

Every single one of these is wrong, because all of the casing has been lost. Thus, when Bikeshed reads this spec and extracts all the definitions, someone correctly attempting to autolink to the definition with `{{getUserMedia()}}` will get a linking failure.

Since the HTML source doesn't appear to have any `lt` at all, I'm pretty sure this is something broken in ReSpec attempting to generate Bikeshed-compatible `lt` values. I dunno how this work - can y'all override this or something? Maybe just add `data-lt="getUserMedia()|getUserMedia(constraints)"` to the element?

You also need to add a type to the definition, which I guess is done by manually adding `data-dfn-type=method`? Maybe that'll fix it the first problem, in fact.

getSupportedConstraints() has the exact same problem, so you're gonna want to apply the fix there as well. And maybe other methods in the spec, I haven't checked.

Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/621 using your GitHub account
Received on Monday, 9 September 2019 22:21:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:28 UTC