Currently this throws:

cue.snapToLines = false;
cue.line = -1; // throws IndexSizeError

but this doesn't throw:

cue.snapToLines = true;
cue.line = -1;
cue.snapToLines = false; // this should not be allowed

This bug was cloned to create bug 18185 as part of operation convergence.

Good point.

Should we throw, or force .line to a valid value? What's the conceptual model here? Is it that you can pick one or the other of two boxes, one of which has a wheel that turns from 0..100 and the other allows you to pick any integer? Or is it that there are is a dial interlocked with a switch, and the dial picks any integer, and the switch blocks the dial to the range 0..100, e.g. because the dial has a groove in the range 0..100 that the switch pushes a rod into?

To put it another way, what's the expected way this will be used? Do we expect to see this kind of code?:

   function (c, newSnapValue, newLineValue) {
     c.snapToLines = newSnapValue;
     c.line = newLineValue;
   }

If so, we presumably want the two-block mode (i.e. reset line when setting snapToLines, if line is out of range), otherwise it'll randomly throw and you'll always have to test the current values first...

Hmm. Since scripts might set these in any order, it might be in an invalid state when the first is set but then be valid again when the other is set. Clamping and resetting would result with the end result. Throwing would stop the script.

I think we should allow setting to any value, i.e. not force a valid state in the DOM API, but for the purpose of rendering, while these are in an invalid state, ignore them both (default to "auto"). This would allow scripts to set them in any order without worrying about it getting the wrong values, and if they end up with something invalid, it gets ignored, just like in the WebVTT syntax.

(In reply to comment #4)
> Clamping and resetting would result with the end result.

...the wrong end result.

The only way it can be invalid is if snapToLines is true and the value is negative or > 100, right? So "auto" in that case is always just equivalent to "100".

I've done as you suggest in comment 5. I think this is the opposite of all the previous comments, as well as bug 17027, which I'll now mark INVALID.

An invalid state should be rendered as if the webvtt line setting was absent, i.e. as if snapToLines = true; line = 'auto'. The spec now says to use as if line:100% which is different from auto.

(In reply to comment #6)
> I've done as you suggest in comment 5.

http://html5.org/tools/web-apps-tracker?from=7327&to=7328

Simon, we can close this bug now, right? This looks sane to me:

http://dev.w3.org/html5/webvtt/#dfn-dom-vttcue-snaptolines
http://dev.w3.org/html5/webvtt/#dfn-dom-vttcue-line
http://dev.w3.org/html5/webvtt/#dfn-text-track-cue-line-position

Resolving as fixed, please reopen if there are still bugs.

lgtm