This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
WebKit have implemented tolerating whitespace on the cue setting such that spaces between cue names and values (behind the colon) are ignored. Basically, in http://dev.w3.org/html5/webvtt/#parse-the-webvtt-settings between steps 2 and 3 there is a "skip whitespace" (except that we now can't leave step 1 as is any more and have to do explicit parsing string by string). Should this be a WebKit bug or should we be more generous in the spec?
I agree. It's natural to type a space after a colon. Many do it in CSS and JS where it is tolerated. I think I have reported this before, but I can't find it right now (though I found annevk asking for this also in IRC). IIRC, Hixie WONTFIXed my suggestion because he wanted settings to be whitespace-*separated*. I don't understand why that is desirable, and would rather support a syntax that authors write naturally. I'm OK with not skipping whitespace before the colon, but I'd also be OK with doing that.
These settings are, as Simon says, space-separated tokens. If you put a space after the colon, then it's a separate token. This isn't like CSS; in CSS, properties are semi-colon separated. It's not like JS; in JS, fields are comma-separated. Here, they are space-separated.
OK, apparently WebKit is actually parsing it exactly as you say. However, at http://dev.w3.org/html5/webvtt/#parse-the-webvtt-settings we have the sentence "splitting input on spaces" (which incidentally is not linking anywhere but has a green underline). There is nothing actually describing what that means. It should likely accept both spaces and horizontal tabs as separators. Webkit in fact tolerates an infinite number of ' ' and '\t' as separators.
(In reply to comment #3) > However, at http://dev.w3.org/html5/webvtt/#parse-the-webvtt-settings we have > the sentence "splitting input on spaces" (which incidentally is not linking > anywhere but has a green underline). There is nothing actually describing what > that means. It should likely accept both spaces and horizontal tabs as > separators. Webkit in fact tolerates an infinite number of ' ' and '\t' as > separators. That's http://dev.w3.org/html5/spec/single-page.html#split-a-string-on-spaces. I think this is missing from 2.1.
OK, let's fix this link then.
I really wish we hadn't pulled this stuff out of the HTML spec where it belongs, it's just going to keep causing these problems. But yeah, I'll add that <dfn> to 2.1.
Checked in as WHATWG revision r7445. Check-in comment: Fix some cross-reference issues. http://html5.org/tools/web-apps-tracker?from=7444&to=7445