The spec is weird (emphasis mine):

The offset parameter supplies a playhead position where playback will begin. If 0 is passed in for this value, then playback will start from the beginning of the buffer. A RangeError exception MUST be thrown if offset is negative. If offset is greater than loopEnd, playback will begin at loopEnd (and immediately loop to loopStart). offset is silently clamped to [0, duration], when startTime is reached, where duration is the value of the duration attribute of the AudioBuffer set to the buffer attribute of this AudioBufferSourceNode.

There are a number of issues and questions here, all answered by the algorithm:

• This is true only when playbackRate is > 0. If no, then it will go backward in the loop. The normative algorithm says yes, only when looping is enabled. This could be fixed by changing the prose.
• Does this need to happen only when looping is enabled? The algorithm, which is normative says says yes. This is fine, but we need to change the prose.
• Does the opposite happen when playbackRate is < 0, meaning the offset should be clamped in [loopStart, loopEnd] ? The normative algorithm says no. This seems inconsistent, but is the current normative requirement.
• In this case, is it allowed to start after the looped region, and then enter the looped region like it is for the positive playbackRate case? The normative algorithm says no. his seems inconsistent, but is the current normative requirement.

Examples:

Normal case

With a buffer of 3.0 seconds: starting, say, at 0.0, with a playbackRate of 1.0, and end/start loop points of respectively 1.0 and 2.0, will play [0.0, 1.0], then looping continuously in [1.0, 2.0].

Backward case

With a buffer of 3.0 second: starting, say, at 3.0, with a playbackRate of -1.0, and end/start loop points of respectively 1.0 and 2.0, will play [2.0, 3.0] backwards, then looping continuously (also backwards) in [1.0, 2.0].