This is the commit.
My name is now in the acknowledgements.
This is the original post.
Hello. I'm part of the Seneca College student who are implementing the WebVTT spec for Mozilla. The syntax rules state, "Each component must not be included more than once per WebVTT cue settings string." The parsing rules allow for duplicate settings implicitly because it makes no such check. The splitting on a space creates a list, not an ordered list. That means a cue with duplicate settings will parse but with unpredictable results. Question. Should this simply be left as unpredictable behaviour? Or should the parser make the behaviour predictable? If the settings could be tokenized in to an ordered list then either it could use the first or last duplicate setting (last should be easier). My feeling is that it should remain unpredictable because the syntax states only one is allowed and therefore duplicate settings should not be supported. If this is the case, it might be useful to have a note in the setting paring section stating that while duplicate settings will be parsed, the behaviour will be unpredictable. http://dev.w3.org/html5/webvtt/#parse-the-webvtt-settings http://dev.w3.org/html5/spec//common-microsyntaxes.html#split-a-string-on-spaces Thank you, Kyle Barnhart
My second post.
Let me point out why I asked this question. Twice in the WebVTT specification it is explicitly pointed out that an "ordered list" is used. - WebVTT Internal Node Objects have an ordered list of child WebVTT Node Objects  - WebVTT Internal Node Objects also have an ordered list of class names  In addition the word "append" is used 27 times in the specification indicating that order is important. In the parse WebVTT settings algorithm , it only states that there is a list of setting token. There is no reference to order. In the split a string on spaces algorithm , it specifies only that a list is created. It also states "add" to the list and not "append". The common micro syntax document  uses the word "append" 9 times. In addition there are explicit instruction for ordered and unordered sets of tokens. The order of a list is so often explicitly stated or implied through the phrases "ordered list" and "append" it appears to be the precedent that lists which must be ordered must use those phrases. I looked very hard for some sort of clarification that lists are ordered by default but I could not find any. If explicitly stating or implying that something is ordered is the precedent, then when it is not explicitly stated or implied, I must assume that it may not be ordered. What it means is that I could create the list from adding to the start or inserting to the middle or some other method. Or use some complex data structure that adds key value pairs by some means that does not preserver order. All of this would be perfectly valid according to the specifications, but would mean that the order of the list across implementations is unpredictable.  http://dev.w3.org/html5/webvtt/#webvtt-cue-text-parsing-rules  http://dev.w3.org/html5/webvtt/#parse-the-webvtt-settings  http://dev.w3.org/html5/spec//common-microsyntaxes.html#split-a-string-on-spaces
Ian Hickson's response.
I've made it clearer that these lists are ordered, just so that there's no ambiguity here. > http://dev.w3.org/html5/spec//common-microsyntaxes.html#split-a-string-on-spaces See http://whatwg.org/html#split-a-string-on-spaces for the most up to date copy of this text. (In particular, WebVTT references the terms as defined in the WHATWG HTML spec; I make no guarantees that the references make sense if you use the W3C HTML5 spec for the HTML terms.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'