This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The HTML5 specification document linked at the W3C has a crossorigin attribute on the media elements and img. However, the Last Call document does not have a crossorigin attribute for these elements. Please link the Last Call document in the HTML WG. Next, please remove the crossorigin attribute from the img and media elements, and any supporting material for this attribute from the HTML specification that is linked in the HTML WG. I don't believe this one was discussed in the HTML WG, and this is a major change. At a minimum clarify the status of crossorigin: is it HTML5? Part of some future HTML? If part of HTML5, where is the use cases for the attribute, as well as the request from the community for its support?
Clarification: I submitted a separate bug about the link to the Last Call document in the web page. This bug is now specifically about the crossorigin attribute.
This appears to be the change in question: http://html5.org/tools/web-apps-tracker?from=6143&to=6144
(In reply to comment #2) > This appears to be the change in question: > > http://html5.org/tools/web-apps-tracker?from=6143&to=6144 But the tracker doesn't show the use cases, nor the discussion about the addition, nor does it show the documentation in support, or the overall community request for such an attribute. These have all been asked of other attributes. It's important that consistency be maintained when it comes to adding or removing attributes. This wasn't discussed in the HTML WG that I could see, yet this is a significant change. More importantly, I'm now confused about whether this is going to be part of HTML5? Or some future version yet to be determined?
(In reply to comment #2) > This appears to be the change in question: > > http://html5.org/tools/web-apps-tracker?from=6143&to=6144 In addition, this was added after the HTML5 was supposed to be frozen for changes other than what was coming through the bug/issue process.
(In reply to comment #3) > (In reply to comment #2) > > This appears to be the change in question: > > > > http://html5.org/tools/web-apps-tracker?from=6143&to=6144 > > But ... I did not mean to imply otherwise. Sorry for the confusion. At this point all I am trying to do is to connect the dots.
(In reply to comment #5) > (In reply to comment #3) > > (In reply to comment #2) > > > This appears to be the change in question: > > > > > > http://html5.org/tools/web-apps-tracker?from=6143&to=6144 > > > > But ... > > I did not mean to imply otherwise. Sorry for the confusion. At this point all > I am trying to do is to connect the dots. Ah, OK. Makes sense. Thanks Sam.
Sam: Would it satisfy process if I file a separate bug to add this attribute and Hixie can then mark that bug fixed? The bug would contain use cases.
(In reply to comment #7) > Sam: Would it satisfy process if I file a separate bug to add this attribute > and Hixie can then mark that bug fixed? The bug would contain use cases. What the proposed process[1] requires is "sufficient prior notice to the group, in the form of a bug, a WG decision, or an on-list discussion" Speaking only for myself: if this is a one time thing, then I don't see a need for a separate bug. Simply use this one. [1] http://dev.w3.org/html5/decision-policy/decision-policy-v2.html#enhanced-cc
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-May/031707.html
(In reply to comment #8) > (In reply to comment #7) > > Sam: Would it satisfy process if I file a separate bug to add this attribute > > and Hixie can then mark that bug fixed? The bug would contain use cases. > > What the proposed process[1] requires is "sufficient prior notice to the group, > in the form of a bug, a WG decision, or an on-list discussion" > ... "If substantial technical changes are made after a Last Call Working Draft, then the Working Group cannot proceed to Candidate Recommendation and must publish another LCWD. While it is not entirely clear what kinds of changes are substantial enough, it seems like feature additions, or for that matter feature removals, probably are." -- <http://dev.w3.org/html5/decision-policy/decision-policy-v2.html#enhanced-cc> I believe it's pretty clear that this is a feature addition, no?
(In reply to comment #10) > (In reply to comment #8) > > (In reply to comment #7) > > > Sam: Would it satisfy process if I file a separate bug to add this attribute > > > and Hixie can then mark that bug fixed? The bug would contain use cases. > > > > What the proposed process[1] requires is "sufficient prior notice to the group, > > in the form of a bug, a WG decision, or an on-list discussion" > > ... > > "If substantial technical changes are made after a Last Call Working Draft, > then the Working Group cannot proceed to Candidate Recommendation and must > publish another LCWD. While it is not entirely clear what kinds of changes are > substantial enough, it seems like feature additions, or for that matter feature > removals, probably are." -- > <http://dev.w3.org/html5/decision-policy/decision-policy-v2.html#enhanced-cc> > > I believe it's pretty clear that this is a feature addition, no? If it stays in the specification. I'm not satisfied with Simon's answer--a link--to withdraw my request to remove this item from the specification. Especially when I read, "This is only a first draft, I'm not sure it's perfect." Frankly, the addition of the attribute seems hacked in, without a great deal of thought.
Evidently the proper procedure is to ask for a revert. Please revert this change.
> Please revert this change. Please don't revert this change. WebKit has already implemented the attribute and it's necessary for WebGL to work both well and securely. If the working group reverts changes like this one, implementors will just stop paying attention to what the working group does.
It is totally clear that this needs to be reverted from HTML5. It's a new feature that was added after LC.
I agree completely with Julian. WebGL has some serious security problems, and this attribute would be nothing more than a bandage, at most. Firefox made the correct decision with WebGL -- they've disabled remote access to image and other files. Even this doesn't begin to address some of the more serious concerns about WebGL. This specification is as at Last Call. Folks from companies that rely on WebKit, both Google and Apple, as well as WebKit folks directly, are groups that participated in the poll to determine whether HTML5 was stable enough for Last Call. From what I remember, all members of these companies/groups have stated that, in their opinion, HTML5 was ready for Last Call. Unless I'm mistaken, a Last Call decision brings with it additional responsibilities for both the group, and the editor. I'm not a member of the HTML WG, but it seems to me if these groups now want to withdraw their support for the stability of the HTML5 specification so that the editor can add and remove new features at will, then reps from the groups should address the HTML WG body and acknowledge their intent. That way folks like me, who are faced with continuing chaos as we do the W3C the courtesy of giving our attention to the specification the organization has asked us to review, at least know to wait until the editor has stopped tossing things into the document. It seems to me that it would have been a simple matter for people to bring the possibility of this change to the attention of the group before the change was made. If this was so important, why did none of you do so? Was it so difficult to submit a bug request, and maybe a follow up email to the group? Or to get the WebGL group to do the _proper_ thing and have it submit requests to the group during the Last Call process? Whatever the reasons for not doing so, you didn't. So here we are. I continue with my request to ask that this change be reverted. Then, if folks are interested, they can properly bring it up to the HTML WG, where it can get the discussion it needs. An item that's related to security should be especially reviewed by members, and yes, outsiders, too. You don't just toss in whatever feels right, and hope it works.
The purpose of last call and CR is to receive feedback from other groups and adjust the specification based on that. In this case adjusting based on such feedback required adding an attribute. This seems entirely appropriate and within process to me. But I do agree that at least sendig an email to the WG list would have been apporiate. If that didn't happen then it needs to happen ASAP.
(In reply to comment #16) > The purpose of last call and CR is to receive feedback from other groups and > adjust the specification based on that. > > In this case adjusting based on such feedback required adding an attribute. > This seems entirely appropriate and within process to me. > > But I do agree that at least sendig an email to the WG list would have been > apporiate. If that didn't happen then it needs to happen ASAP. And there can't be an assumption that the HTML WG and people like myself are just going to passively sit here, either. I disagree with this change, regardless of how it came about. WebGL has some major security issues and this change is nothing more than addressing the tip of the ice berg while ignoring the rest. I think it is more dangerous to add than not. You just don't toss in security changes without due consideration. HTML5 cannot fix WebGL, and we shouldn't have to even try. The WebGL folks should be responding in a controlled manner to the HTML5 Last Call, with proposed changes, as well as analysis of impact on their effort. How this change fits into their new security paradigm should be presented. We don't even know if the WebGL group has asked for this, or only one member. We don't even know if all browser companies are on board with this change. This is not trivial, and shouldn't be approached as a trivial change.
I'm told there's a rule in the HTML WG that those outside the group cannot request for a change to be reverted. That means another tracker issue. I also noticed a new email[1] that just adding the TrackerRequest keyword is no longer sufficient. All of these new and changing rules do make it extremely difficult for people to provide the commentary that the group supposedly has asked for with Last Call. Be that as it may be, following is my TrackerRequest title and purpose: Title: Remove the crossorigin and CORS normative dependency from the HTML WG. Purpose: Recently the editor added an attribute, crossorigin, as well as a normative dependency on the CORS (Cross-Origin Resource Sharing) specification to the HTML5 specification. He did not do in answer to any bug submitted to the W3C bugzilla database, nor based on any request emailed to the group. Only by reverse engineering the documentation for the change are we made aware that this request came about because of a request from someone supposedly related to the WebGL effort. This request was made based on feedback from various security groups about the insecurity of WebGL, specifically one security issue related to the access of images and videos from domains outside of the domain serving the web page (same source). This change does not "fix" the problem related to WebGL--in actuality, the security vulnerability still exists. What this problem does is more or less just shove the responsibility for the problems off the software implementation and on to the application developers. This solution makes several assumptions, not the least of which that it provides a safe way to fulfill the original use cases given within the WebGL for supporting cross-domain resource access for texture use. Originally, WebGL restricted cross-domain resource access for textures, most likely because of security concerns. However, after exploring the original use cases given for adding cross-domain resource access(such as using an ad from an ad service to embed an image into a 3D world, or using images served up at Flickr or AWS), there is no guarantee that this solution will fix the problem. Why? Because those serving the remote resources must also agree to the use of CORS, and I know for a fact that at least one of the services has already expressed reluctance to do so (AWS). Point of fact, I'm not sure any service is going to be willing to incorporate a functionality that is meant to bypass security protocols, for a technology group delivering a product that at least two security organizations have recommended against. In addition, the addition of crossorigin also created a normative dependency in HTML for the CORS specification, which is, itself, a draft specification not currently robust enough for Last Call status. Though CORS was listed as a reference in the LC HTML5 document, I don't believe there was a normative dependency in the HTML5 specification for CORs previous to this. Hard to say, since HTML5 is such a large and far reaching document. My time right now is limited, but I believe I'll also have other strong technical objections to submit against crossorigin in the near future. For now, this will have to do. Not part of the Tracker issue and just a general note: It would help to have an actual bug that someone submitted asking for crossorigin, including actual technical reasons why this functionality is needed, and _why no other solution is viable_. I don't believe the latter was ever answered--at the WHATWG, or here in the W3C. It would help to also know if any other group other than WebGL expressly needs this attribute. Considering that the editor's employer is a big backer of WebGL, I can't help wondering if the editor would be as willing to modify HTML5 if another group--say Adobe or Microsoft--asked for something specifically because of security concerns about any of their products.
Sorry, I forgot to link the email related to TrackerRequests http://lists.w3.org/Archives/Public/public-html/2011Jun/0316.html
One last: the use of TrackerRequest may be premature -- the editor has not addressed this item and the status is still new. I've since removed it. However, if the editor marks it as WONTFIX, will re-add it and the text given earlier will be the text for the tracker issue.
EDITORIAL ASSISTANT'S RESPONSE: This is an Editorial Assistant'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: As far as I can tell, no substantive technical objections have been raised to this feature, only procedural objections. The procedural objections have been adequately rebutted already -- there is no requirement that Last Call drafts not have new features added to them; and the revert request policy also does not bar adding new features entirely. The attribute in question has the support of multiple implementers (see comment #7, comment #13, comment #16) and addresses a specific deficiency in the preexisting standard, and there is no plausible benefit to removing it from the draft when it's already being implemented.
Actually, I believe I did provide technical reasons. I provided more reasons than were provided in support of adding the attribute. But I've now added the TrackerRequest back.
And a correction, Aryeh For crossorigin to work, the concept of "implementor" has to be extended beyond the browsers. Implementors also include untold numbers of service providers. If only browser companies implemented this change, nothing would happen. And there is no deficiency in HTML5--there is a serious deficiency in WebGL, and crossorigin does not fix this deficiency, it only routes around it.
(In reply to comment #22) > Actually, I believe I did provide technical reasons. I provided more reasons > than were provided in support of adding the attribute. > > But I've now added the TrackerRequest back. Please provide a title and text for the issue (including a description of the technical issue at hand) when adding TrackerRequest.
(In reply to comment #24) > (In reply to comment #22) > > Actually, I believe I did provide technical reasons. I provided more reasons > > than were provided in support of adding the attribute. > > > > But I've now added the TrackerRequest back. > > Please provide a title and text for the issue (including a description of the > technical issue at hand) when adding TrackerRequest. See comment 18 (http://www.w3.org/Bugs/Public/show_bug.cgi?id=12888#c18)
(In reply to comment #25) > (In reply to comment #24) > > (In reply to comment #22) > > > Actually, I believe I did provide technical reasons. I provided more reasons > > > than were provided in support of adding the attribute. > > > > > > But I've now added the TrackerRequest back. > > > > Please provide a title and text for the issue (including a description of the > > technical issue at hand) when adding TrackerRequest. > > See comment 18 (http://www.w3.org/Bugs/Public/show_bug.cgi?id=12888#c18) That comment seems to contain quite a bit of extraneous commentary. I've also lightly edited the title: http://www.w3.org/html/wg/tracker/issues/167
mass-move component to LC1