{"action":"created","issue":{"url":"https://api.github.com/repos/WICG/media-capabilities/issues/96","repository_url":"https://api.github.com/repos/WICG/media-capabilities","labels_url":"https://api.github.com/repos/WICG/media-capabilities/issues/96/labels{/name}","comments_url":"https://api.github.com/repos/WICG/media-capabilities/issues/96/comments","events_url":"https://api.github.com/repos/WICG/media-capabilities/issues/96/events","html_url":"https://github.com/WICG/media-capabilities/issues/96","id":358227046,"node_id":"MDU6SXNzdWUzNTgyMjcwNDY=","number":96,"title":"Revert the \"DOMString framerate\" change from issue #12","user":{"login":"jernoble","id":1557428,"node_id":"MDQ6VXNlcjE1NTc0Mjg=","avatar_url":"https://avatars0.githubusercontent.com/u/1557428?v=4","gravatar_id":"","url":"https://api.github.com/users/jernoble","html_url":"https://github.com/jernoble","followers_url":"https://api.github.com/users/jernoble/followers","following_url":"https://api.github.com/users/jernoble/following{/other_user}","gists_url":"https://api.github.com/users/jernoble/gists{/gist_id}","starred_url":"https://api.github.com/users/jernoble/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jernoble/subscriptions","organizations_url":"https://api.github.com/users/jernoble/orgs","repos_url":"https://api.github.com/users/jernoble/repos","events_url":"https://api.github.com/users/jernoble/events{/privacy}","received_events_url":"https://api.github.com/users/jernoble/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":13,"created_at":"2018-09-07T22:13:02Z","updated_at":"2018-12-11T22:04:47Z","closed_at":null,"author_association":"NONE","body":"The issue of accurately representing \"rational integer\" time values in JavaScript is much larger than frame rate, and we should push for a general solution.  Above and beyond this general objection, we shouldn't be adding any complicated string parsing logic to represent media times.  The current specification allows the following values as valid `framerate`s:\r\n\r\n\"1\"\r\n\"1.5\"\r\n\"3/2\"\r\n\r\nBut it also considers the following as valid `framerate`s:\r\n\r\n\"1.5/1\"\r\n\"3/0.5\"\r\n\r\nAnd given that the justification for doing this parsing was to ensure that values could be accurately compared to one another without floating-point rounding, the following (pseudocode) comparisons will all evaluate to false:\r\n\r\n```\r\nframerate(1) != framerate(\"1/1\")\r\nframerate(1.5) != framerate(\"2/1\")\r\nframerate(\"1.\") != framerate(\"1\")\r\nframerate(\"1/1\") != framerate(\"2/2\")\r\n```\r\n\r\nSo we should either completely revert the change, and return the following entry to the `VideoConfiguration` dictionary:\r\n\r\n```\r\n    required double framerate;\r\n```\r\n\r\n...until such a time where we have an actual \"media time\" value to be used in place of double.  Or, if we must provide a way to pass a rational value into this API (and I don't believe we do), we should revert the change as above and add an additional property:\r\n\r\n```\r\n    double framerateDenominator = 1;\r\n```"},"comment":{"url":"https://api.github.com/repos/WICG/media-capabilities/issues/comments/446380057","html_url":"https://github.com/WICG/media-capabilities/issues/96#issuecomment-446380057","issue_url":"https://api.github.com/repos/WICG/media-capabilities/issues/96","id":446380057,"node_id":"MDEyOklzc3VlQ29tbWVudDQ0NjM4MDA1Nw==","user":{"login":"jernoble","id":1557428,"node_id":"MDQ6VXNlcjE1NTc0Mjg=","avatar_url":"https://avatars0.githubusercontent.com/u/1557428?v=4","gravatar_id":"","url":"https://api.github.com/users/jernoble","html_url":"https://github.com/jernoble","followers_url":"https://api.github.com/users/jernoble/followers","following_url":"https://api.github.com/users/jernoble/following{/other_user}","gists_url":"https://api.github.com/users/jernoble/gists{/gist_id}","starred_url":"https://api.github.com/users/jernoble/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jernoble/subscriptions","organizations_url":"https://api.github.com/users/jernoble/orgs","repos_url":"https://api.github.com/users/jernoble/repos","events_url":"https://api.github.com/users/jernoble/events{/privacy}","received_events_url":"https://api.github.com/users/jernoble/received_events","type":"User","site_admin":false},"created_at":"2018-12-11T22:04:47Z","updated_at":"2018-12-11T22:04:47Z","author_association":"NONE","body":"> @jernoble regarding long long I have no strong preference but looking at different rational implementations in languages, I can't find any that requires the denominator to be positive and it's not mathematically needed either. Why would you like to see this change?\r\n\r\nOnly because it seems unnecessary and complicated to try to spec the behavior of {-1, -1} === {1, 1}. If this `Rational` object is cast-able to a double, then the spec is going to have to have to include a \"normalization\" step that would be unnecessary if the denominator was defined to be positive.\r\n\r\nIs there any use case for a `Rational` that would require the denominator to be negative?"}}
{"actor":{"display_login":"jernoble"}}