This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Feedback by Addison Phillips from W3C I18N group: http://lists.w3.org/Archives/Public/public-tt/2015Mar/0060.html I18N comment: https://www.w3.org/International/track/issues/427 A WebVTT percentage is defined (in part) as: -- A WebVTT percentage consists of the following components: One or more ASCII digits. -- There is no upper length limit given for the integer portion of the percentage. Is this intentional?
I think the syntax should say that if interpreted as a real number, a WebVTT percentage must in the range 0..100, matching the parsing. This still makes 0000050% valid, which seems OK If we want it to not be valid we'd have to say that the first digit cannot be a zero.
(In reply to Philip Jägenstedt from comment #1) > I think the syntax should say that if interpreted as a real number, a WebVTT > percentage must in the range 0..100, matching the parsing. > > This still makes 0000050% valid, which seems OK If we want it to not be > valid we'd have to say that the first digit cannot be a zero. A percentage can never be larger than 100%? Some CSS percentages make sense as larger numbers... just not as unbounded values. Anyway, this comment is just a grammatical nit.
Percentages can of course be any real number, but in WebVTT any attempt to set a percentage outside the range [0,100] is ignored, both in the parser and on the VTTCue interface.
yes, but am I required to be able to parse 85.3629386749238923498798234923488021037096308373833999473908334903333222647850993774663884% for example?
Yes, the WebVTT parser will collect that whole string, however long, and interpreted as a real number. The result is only exposed as a double in the VTTCue interface, so there's no requirement to store it as an arbitrary precision number, though.
Prepared https://github.com/w3c/webvtt/pull/199
Patch landed
satisfied.