28072 2015-02-22 10:25:40 +0000 [WebVTT] Consistent use of snap-to-lines flag 2017-07-10 06:07:14 +0000 1 1 1 Unclassified TextTracks CG WebVTT unspecified PC All RESOLVED FIXED v1 widereview decided P2 normal --- 1 silviapfeiffer1 dave.null philipj silviapfeiffer1 singer tai public-texttracks oldest_to_newest 118073 0 silviapfeiffer1 2015-02-22 10:25:40 +0000 The snap-to-lines flag is of type Boolean that can be "set" to "true" or "false". Instead of referring to these values sometimes the setting of the values is described with the verbs "set" (for setting to "true") and "unset" (for setting to "false"). It would be more consistent and help the reader if the operation is always described as "set to true" and "set to false". As per feedback from Andreas Tai: http://lists.w3.org/Archives/Public/public-texttracks/2015Feb/0005.html 118156 1 philipj 2015-02-25 06:30:31 +0000 I can only find one such instance, in http://dev.w3.org/html5/webvtt/#dfn-vttcue-snaptolines "On setting, the text track cue snap-to-lines flag must be set if the new value is true, and must be unset otherwise." I guess this could be simply be "On setting, the text track cue snap-to-lines flag must be set to the new value." 118157 2 philipj 2015-02-25 06:33:43 +0000 But I would value consistency with https://html.spec.whatwg.org/#dom-texttrackcue-pauseonexit so would prefer no change. I found an unrelated problem though: https://github.com/w3c/webvtt/pull/175 118428 3 silviapfeiffer1 2015-03-08 08:58:38 +0000 Actually, there is a difference in what the browser stores internally during processing (parsing, rendering, API) to what the concept's value is. The concept's value is more closely related to what an author would set in a HTML attribute. Since a boolean attribute is "set to true" with any value, it's only false when unset. I think we need to leave this as is. 127725 4 singer 2016-10-11 17:49:58 +0000 I cannot find any places where we describe snap-to-lines as merely 'set'; it's always true or false now. 128681 5 tai 2017-07-10 06:07:14 +0000 The terminology was changed in https://github.com/w3c/webvtt/commit/78605993eead104efa3b1b5bafc8d040f26d2659. So although this issue is not referenced in the commit message it resolved the issue by following the proposal.