This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section: http://www.whatwg.org/specs/web-apps/current-work/#dom-navigator-canplaytype Comment: canPlayType should return enum instead of string Posted from: 92.116.150.2
Returning strings usually slows down the program and is error prone. It would be more stable to have canPlayType() return an enum, or a short int instead, like many other properties/functions do.
I think this ship has sailed.
(In reply to comment #2) > I think this ship has sailed. Exactly.
Why? HTML5 is still under development. AFAIK, HTML5 is not even a TR.
Do you really want to leave it this way? This is a design flaw, leaping to the eys. Leaving it as is would ignore any software design priciples. We're talking about the "official" HTML specification here, not a personal DVD database.
(In reply to comment #4) > Why? HTML5 is still under development. Because it has shipped in 3 browser engines. > AFAIK, HTML5 is not even a TR. Perhaps you mean CR?
(In reply to comment #6) > (In reply to comment #4) > > Why? HTML5 is still under development. > > Because it has shipped in 3 browser engines. I'd call that hard luck. HTML5 isn't final yet. So changes may always be possible until it's finished. I regard the necessary changes as being: * Three enum constants * Change of one function prototype * Change of three return values. I guess the function isn't called internally, because it wouldn't make sense to use a hypothetical return value for rendering. But if it was, this would be one or two if condition updates. All in all, the effort to write this reply is about four times the amount to update the browser code. No one is (officially) using the code yet, either. So I don't see a reason for not amending the specification. > > AFAIK, HTML5 is not even a TR. > > Perhaps you mean CR? Yes, sorry for that. I mixed it up with the URL which always uses "TR"... My mistake.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: I concur with those saying that this ship has sailed. Implementations have shipped. Changing this unless there's a real problem is not a good use of resources. There's really nothing wrong with strings as output here anyway, it's done all over the Web API.
I frankly don't know any function returning a type as a string. Again, it has many drawbacks to use strings as return values when the result is just a very restricted codomain. After all, it's a dirty definition. Perhaps nowadays there is no more room left for clean definitions. Ten years ago leaving this would have been inacceptable. Those implementation being shipped are *not* officially implementing HTML5. They are just Beta versions. Taking followers of a working-draft as a constraint means the tail is wagging his dog.
Please don't change the resolution, thanks. Also, you can call these implementations what you want, but they have shipped to hundreds of millions of end-users and authors rely on the fact that implementations return strings.