-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Normative reference to the File API working draft #57
Comments
The MSE spec has only two referencing points to the File API spec: in the definition of the MediaSource object URL by using the Blob URL and in the extension to the createObjectURL interface which creates and binds a Blob URL to a MediaSource object. In the File API spec, both the Blob URL and the createObjectURL interface are defined in the section 10, A URL for Blob and File reference. The content of the section is:
The section 10 seemingly contains exactly what MSE needs and nothing more than that. The section looks well-isolated from other parts of the spec: it contains no reference to other parts of the File API spec except for generally mentioning the term, "blob object", in the introduction of the Blob URL concept. So, both the option 2-b) and 3) would be feasible. However, the option 2-b) has some benefits over 3) since we don't need to prepare testing for it if we choose 2-b). The section 10 of the File API spec has, at least, two normative reference issues: a) it refers not HTML5.1 but HTML5 and b) it has normative reference to URL Specification. We need to change the former to HTML5.1 and check the stability of the URL specification to claim the section 10 is stable when we request the transition to PR on June. I'll ask the WPWG co-chairs if they are willing to make it clear that the section 10 is stable in File API spec and their plan about the two normative references towards September, when they are going to publish HTML5.1. If their plan is in line with ours, we could go with the option 2-b). Otherwise, we would need to choose the option 3). |
@yfuna: Can we get a report on where this stands? |
I think we can close this issue with no action. As said earlier, media source uses a Blob URL, which is a string as defined in https://www.w3.org/TR/FileAPI/#DefinitionOfScheme . Now, MSE doesn't care about the details of that string. It gets one from createObjectURL and gives it directly to the src attribute. We could certainly do some tests to see if we get a Blob url scheme but we're likely to have enough interop there. Btw File API/Blob is also referenced normatively from HTML 5.0 (https://www.w3.org/TR/html5/infrastructure.html#dependencies) so we have enough precedence there to move along imho without changes. |
@plehegar - Please close this issue since no one has objected to your above rationale for making no change here. |
Closing per #57 (comment) |
The File API spec, which MSE refers normatively, is not yet a Recommendation or Proposed Recommendation but still a Working Draft. It means that, before we submit our transition request to PR, we have to make it stable if needed. (See Normative References)
The File API spec currently covers five features:
Given that MSE only uses the fifth item, Blob URL, which is relatively a small portion and seems stable, there would be four ways we can take to achieve the stability.
2-a) we'll ask the WPWG chairs to split the WD into two specs, one is about Blob URL and the other is for other stuffs, and make the Blog URL spec PR.
2-b) we'll ask the WPWG chairs to make it clear in the spec that the Blob URL part is stable and won't change in a short term.
Through the initial conversation with the WPWG chairs, the team found that the option 1) was not the case there(the spec currently has a development proposal in the group), and the option 2-a) was not what the chairs wanted because they think they should keep the spec inclusive on file related features.
Thus, the options left to us currently are 2-b) and 3).
I'll start analyzing these two options and list up their pros and cons, while, at the same time, welcome your thoughts on other or different options we can pursue to resolve this issue.
The text was updated successfully, but these errors were encountered: