[webkit-dev] Augmenting WebKit contextual menus for non-plugin
hyatt at apple.com
Fri May 25 16:56:47 PDT 2007
On May 25, 2007, at 4:39 PM, Nathan Duran wrote:
>> Flimsy in what sense? If QuickTime (or any plugin) can take over
>> PNG, then PNG image support when the <object> tag is used would
>> effectively be broken. Suddenly all sorts of built-in browser
>> functionality breaks. Web sites would break. The end user would
>> have no real understanding of what was going wrong or how to fix it.
> Flimsy in the sense that QuickTime should have simply stopped
> itself to handle that MIME type rather than making it impossible
> for ANY
> plugin to register itself for any MIME type. That's like trying to
> fleas off your dog by draining all the blood out of it.
I think there is some confusion here, so I will try to clarify.
should not render differently in a browser. It would be inconsistent
for a plug-in to render the PNG in the latter case but not in the
Right now plug-ins can only be declared via an <object>/<embed>
element. There is no other way to make a browser plug-in in HTML.
If we allow plug-ins to take over image types in the <object> case,
then suddenly there are two conflicting implementations of PNG at
work depending on what tag the author of the Web page happened to
use. See the problem?
Now maybe you are asking for a feature whereby some hunk of code
could really take over the MIME type regardless of where it occurs in
the browser (e.g., PNGs can occur as background images in CSS, in the
<img> URL, drawn to a <canvas> etc.). If so that goes way beyond the
concept of a plug-in. That may be an interesting feature to
implement, but it would not be a plug-in as defined in browsers today.
>> Augmenting contextual menus really has nothing to do with plug-ins,
>> so I'm not sure how the conversation ended up at plug-ins. :)
>> Changing context menus is getting more into the realm of extensions.
> Semantics are fun, aren't they? How about if we invent a third
> category and
> call them "add-ons" just to delineate some more imaginary
> boundaries that
> keep those bug reports in someone else's inbox?
I'm not playing a semantic game here. Plug-ins have a precise
meaning and a precisely defined API (the Netscape plug-in API). The
Netscape plug-in API defines how a plug-in interacts with the Web
page in a formal cross-browser way.
I'm just distinguishing the defined notion of plug-in in browsers
from something new (that would be better classified as a browser
extension using Firefox terminology).
> I get the fact that it doesn't work the way I want it to and
> probably never
> will. That doesn't mean that this is an ideal situation which I
> have no
> right to find objectionable.
Nobody said the ability to customize context menus was an
More information about the webkit-dev