This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In Section 4.8.6, we currently have this example code: -- snip -- <object type="application/x-shockwave-flash"> <param name=movie value="http://www.macromedia.com/shockwave/download/triggerpages_mmcom/flash.swf"> This page requires the use of a proprietary technology. Since you have not installed the software product required to view this page, you should try visiting another site that instead uses open vendor-neutral technologies. </object> -- snip -- I don't think that examples are a good place to promote a specific agenda ("plugins are bad"). A *typical* example would have fallback content with instructions where to find the plugin. Also, changing this not to mention a *specific* plugin probably would be good as well.
> Also, changing this not to mention a *specific* plugin probably would be good as well. I disagree. It's useful for the spec to provide real-world working examples. I agree that the fallback text could be changed to somehting else.
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: As far as I can tell the fallback text is a completely accurate and appropriate statement. It might not be what most authors would actually want to put on their site, but it is nonetheless what every author is really saying when they don't provide a useful fallback.
I agree that the example needs to be changed, at the minimum the URI. We shouldn't pick on Adobe, Apple, Google, or Microsoft for their plugins and certainly not in the HTML specification. Plugins are supported by the HTML specification. Ian, if you want to pick on a plugin company, at least pick your company.
I can see how it's good to make examples realistic, but editorializing about proprietary technologies is not realistic.
(reopening based on comments)
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: Partially Accepted Change Description: see diff given below Rationale: I moved the Flash example (which had been added based on questions about how to embed flash) into the <object> section, and added some fallback to show how to do fallback. I changed the example in the <param> section (which shows the problems of not using fallback) to use O3D.
Checked in as WHATWG revision r4768. Check-in comment: Change the examples around to pick on Google products instead of Adobe products. http://html5.org/tools/web-apps-tracker?from=4767&to=4768
Thanks for the change. However, it only addresses one of the concerns raised here, thus reopening.
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: Did Not Understand Request Change Description: no spec change Rationale: Could you be specific about which concern is not addressed? Generally speaking, this is why bugs should only cover one specific issue, by the way. Please file exactly one bug per issue.
(In reply to comment #9) > 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: Did Not Understand Request > Change Description: no spec change > Rationale: Could you be specific about which concern is not addressed? > > Generally speaking, this is why bugs should only cover one specific issue, by > the way. Please file exactly one bug per issue. The specific concern was: "A *typical* example would have fallback content with instructions where to find the plugin. Also, changing this not to mention a *specific* plugin probably would be good as well." The text currently says: This page requires the use of a proprietary technology. Since you have not installed the software product required to view this page, you should try visiting another site that instead uses open vendor-neutral technologies. which I don't think is a good example -- why would a page *ever* want to display this as fall back text, unless for the purpose of an anti-plugin agenda? A more realistic example would be This page requires the use of FOOBAR technology. Since you have not installed the FOOBAR plugin required to view this page, you should try installing it, it's a available from...
(In reply to comment #10) > > The specific concern was: > > "A *typical* example would have fallback content with instructions where to > find > the plugin. Also, changing this not to mention a *specific* plugin probably > would be good as well." > It's incorrect process to both reopen the bug *and* request escalation. Please pick one of the following: 1) Reopen bug for fresh consideration by the editor - you will get a full Editor's Response with rationale and a spec diff link if any spec changes are made. 2) Escalate to tracker for consideration by the full Working Group - a Change Proposal will be required. In case of (1), the TrackerRequest keyword should be removed for now (you will still be entitled to request escalation once the editor replies again). In case of (2), the bug should be moved back to VERIFIED - it will remain there and will not be closed pending a Working Group Decision. If you do not pick one of these in a couple of days, we will assume option 2. (Note to Julian: since you provided a very specific description of the remaining problem, and proposed a solution, I suggest treating this as reopened at first to give the editor another crack at it. If you would like, I can request higher priority to avoid creating unnecessary delay. But the choice is yours.)
(In reply to comment #11) > It's incorrect process to both reopen the bug *and* request escalation. Please > pick one of the following: > > 1) Reopen bug for fresh consideration by the editor - you will get a full > Editor's Response with rationale and a spec diff link if any spec changes are > made. > > 2) Escalate to tracker for consideration by the full Working Group - a Change > Proposal will be required. > > In case of (1), the TrackerRequest keyword should be removed for now (you will > still be entitled to request escalation once the editor replies again). I'm removing the TrackerRequest keyword, and wait for a new response. > ...
> The specific concern was: > > "A *typical* example would have fallback content with instructions where to > find the plugin. A "typical" page would say nothing, or, at best, would just say "Your browser doesn't support flash". I don't see what the relevance of a _typical_ example is; the spec's examples are anything but typical. > Also, changing this not to mention a *specific* plugin probably > would be good as well." I believe that using concrete examples is a good thing in a spec. > The text currently says: > > This page requires the use of a proprietary technology. Since you > have not installed the software product required to view this > page, you should try visiting another site that instead uses open > vendor-neutral technologies. > > which I don't think is a good example -- why would a page *ever* want to > display this as fall back text, unless for the purpose of an anti-plugin > agenda? Because it's honest. > A more realistic example would be > > This page requires the use of FOOBAR technology. Since you > have not installed the FOOBAR plugin required to view this > page, you should try installing it, it's a available from... This assumes that one can install the plugin, which is a rather naïve assumption these days, given the millions of Web-enabled devices for which either the plugins do not exist or for which plugins cannot be created at all. 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: The bug is merely a difference of opinion on an editorial matter.
Will raise a tracker issue.
Raised as issue 107 (<http://www.w3.org/html/wg/tracker/issues/107>)