[IR] settings line test failing

[gkatsev]

The settings line test is failing across the board.
In Chrome and Safari a value of .5 and 5. are parsed as 0.5 and 5.0 respectively. The spec specifically calls numbers beginning and ending with . as invalid values.
Chrome and Safari do not support line align, which is being marked as at risk in #460 and may warrant splitting out line align tests from regular line tests.
Safari also defaults to the value -1 rather than auto and a very large negative number is set to zero rather than Number.MIN_VALUE as the test suggests.
Firefox is failing due to it's very strict parser.

[css-meeting-bot]

The Timed Text Working Group just discussed [IR] settings line test failing webvtt#468, and agreed to the following:

• RESOLUTION: Split line alignment from the rest of the line tests, into a new test.
• RESOLUTION: Mark line alignment as at risk
• RESOLUTION: Wait for implementation updates for line options, leave as not at risk in the spec.

The full IRC log of that discussion

<nigel> Topic: [IR] settings line test failing webvtt#468
<nigel> github: https://github.com//issues/468
<nigel> Gary: This test needs splitting.
<nigel> .. The settings line test tests both the line property and line alignment.
<nigel> .. Line alignment is a fairly new feature.
<nigel> .. It would be best to split the test into two, one for each of those features.
<nigel> .. Line Alignment has no support, except Firefox theoretically - I'm not sure if it does the right thing, it may.
<nigel> .. There's also an interesting bug in Chrome and Safari which is probably from their shared heritage where
<nigel> .. the line value of .5 or 5. is processed as 0.5 or 5.0 but the spec explicitly says this is invalid.
<nigel> Nigel: That's an interop problem then?
<nigel> Gary: Yes
<nigel> Eric: I believe that this is a result of a spec change because that value used to be defined as a float.
<nigel> .. The old logic means Safari and Chrome were doing the right thing.
<nigel> .. When it was defined as a float then it made sense.
<nigel> .. Now it is an integer... [looks at code] ... line position used to be a -, a % or a digit at the beginning.
<nigel> .. If it was digit then it was a floating point number, so the . was valid because it was part of the number.
<nigel> Nigel: Was a . treated as a digit? Starting with a . seems to be none of those.
<nigel> Eric: In any case it's a bug in the implementations vs the current spec.
<nigel> Gary: It sounds like the current spec is what we want.
<nigel> Eric: Correct
<nigel> Gary: The other weird thing, maybe an implementation issue is Safari defaults to -1 instead of auto.
<nigel> .. And line alignment is not supported.
<nigel> .. To me it sounds like the way that we want to proceed is wait for implementations to fix the bug with line,
<nigel> .. and mark line alignment as at risk and likely to be removed from this version. Then hopefully it makes sense to add it
<nigel> .. back in to v.next, because I think it will take too long for implementations.
<nigel> Nigel: Marking as at risk means you remove the dependency on implementations.
<nigel> PROPOSAL: Split line alignment from the rest of the line tests, into a new test.
<nigel> PROPOSAL: Mark line alignment as at risk
<nigel> PROPOSAL: Wait for implementation updates for line options, leave as not at risk in the spec.
<nigel> Gary: Any objections to any of those?
<nigel> Eric: Not from me
<nigel> Gary: No objections
<nigel> RESOLUTION: Split line alignment from the rest of the line tests, into a new test.
<nigel> RESOLUTION: Mark line alignment as at risk
<nigel> RESOLUTION: Wait for implementation updates for line options, leave as not at risk in the spec.