Editorial: Add a missing ref-name for requestPointerLock method

[NavidZ]

Change the ref-name of the functions to make it
easier in the follow up changes to add parameters

---

Preview | Diff

[NavidZ]

@marcoscaceres There was another place in the spec that was referring to requestPointerLock but with no link at the moment.
Context:
... used to enter fullscreen it is sufficient for a subsequent requestPointerLock.

When I change that to <a>requestPointerLock</a> ReSpec complains that it cannot find the reference. Do you know why? Is that a bug in ReSpec or am I missing something?

[marcoscaceres]

Do you know why? Is that a bug in ReSpec or am I missing something?

You are probably missing: data-link-for="Element" near where you are trying the link... you can add it to the <div class="note" data-link-for="Element"> and it should work.

[marcoscaceres]

hmm... convention is to have methods as "foo()" throughout the spec. Are you sure you want to change them?

[marcoscaceres]

Added data-link-for="Element" to the closest <p>, so hopefully now should link ok.

[NavidZ]

hmm... convention is to have methods as "foo()" throughout the spec. Are you sure you want to change them?

Convention through out this spec or across W3C specs? At least I know we haven't followed this in PointerEvent spec. Is that written somewhere so I can take a look and see how it generally applies? How does that apply to the functions with parameter? Should we just drop the parameters in links or should we mention them all every time in a link?

Added data-link-for="Element" to the closest

, so hopefully now should link ok.

Yup. This fixed it. Thanks.
For my understanding, I tried reading the meaning of data-link-for here but I got even more confused. Why the link to the exitPointerLock method in the previous paragraph works fine but not in this paragraph? There is only one definition of these functions throughout the spec anyway.

[marcoscaceres]

Convention through out this spec or across W3C specs?

W3C.

Is that written somewhere so I can take a look and see how it generally applies?

Not explicitly, but you can see examples, for instance, in the TAG's API Design Guidelines:
https://w3ctag.github.io/design-principles/#live-vs-static

And also in the other specs created by the WG:
https://github.com/w3c/webappswg

(open any, search for "()" to find methods)

How does that apply to the functions with parameter?

There are a number of different ways, depending on what you prefer.

Payment Request defines the methods in a h2, then uses <var>, like so:

<h2><dfn>show()</dfn></h2>
<p>
   The <code>show(optional <var data-type="Promise">detailsPromise</var>)</code> method MUST act as follows:
</p>
<ul class="algorithm">
    <!--- stuff -->
</ul>

What is neat about the above is that the type information propagates in the algorithm.

Alternative, if you ever need to just define a method inline with arguments:

<p>
   <dfn data-lt="requestPointerLock()">requestPointerLock(DOMString <var data-type="DOMString">someArg</var>)</dfn>
</p>

Eventually, plan on adding support support for function parameters to the {{ }} syntax too.

[NavidZ]

Fair enough. So let's follow the pattern here then. I removed my changes and also change the new reference to {{}} as from what you said it seems that will get more support and seems to be the recommended way of referencing here.
I'll follow what you suggested here in the following patches that I will send for adding new params.

[marcoscaceres]

Sounds great. Happy to review changes once new params are added. Looking forward to discussing those.