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
registering
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
keep
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.
<img src="foo.png">
<object src="foo.png">
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
former case.
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
objectionable feature.
dave
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
