16917 2012-05-03 11:57:32 +0000 WebVTT: snapToLines should throw InvalidStateError if the new value is false and "line" is negative or greater than 100 2014-01-30 09:39:43 +0000 1 1 1 Unclassified TextTracks CG WebVTT unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#text-track-api v1 P3 normal --- 1 contributor philipj ian mike philipj public-texttracks zcorpan dave.null oldest_to_newest 67285 0 contributor 2012-05-03 11:57:32 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html Multipage: http://www.whatwg.org/C#text-track-api Complete: http://www.whatwg.org/c#text-track-api Comment: snapToLines should throw InvalidStateError if the new value is false and "line" is negative or greater than 100 Posted from: 88.131.66.80 by simonp@opera.com User agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.7.3; U; en) Presto/2.10.229 Version/11.62 67286 1 zcorpan 2012-05-03 11:59:09 +0000 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 70837 2 contributor 2012-07-18 17:36:03 +0000 This bug was cloned to create bug 18185 as part of operation convergence. 73078 3 ian 2012-08-30 18:19:31 +0000 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... 73401 4 zcorpan 2012-09-07 08:26:11 +0000 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. 73402 5 zcorpan 2012-09-07 08:27:45 +0000 (In reply to comment #4) > Clamping and resetting would result with the end result. ...the wrong end result. 73636 6 ian 2012-09-11 22:29:23 +0000 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. 73702 7 zcorpan 2012-09-12 16:36:52 +0000 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. 77183 8 zcorpan 2012-10-27 09:27:41 +0000 (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 99139 9 philipj 2014-01-27 09:47:00 +0000 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 99277 10 philipj 2014-01-28 08:31:04 +0000 Resolving as fixed, please reopen if there are still bugs. 99471 11 zcorpan 2014-01-30 09:39:43 +0000 lgtm