On Mon, 11 Dec 2006 06:25:27 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote:
>> 1.) Inserting Sam Ruby's SVG logo into HTML, for one example. > The <img> element already supports images in HTML. You can even embed > images directly in the page with data: URIs, regardless of the format (be > it PNG, JPEG, or SVG, for example.) You won't be able to manipulate the SVG DOM in this case. Also, data: URIs are inconvenient to write, and they are only usable for very short data strings. >>> We already have such a mechanism, namely, plugins. >> Two extension mechanisms are not possible? > Redundancy is always possible. Whether it is desireable is the question. These are actually two independent aspects: 1. Native support vs. plugins. 2. External resources vs. inline data. Native support + external resources --> e.g. JPEG <img href="http://...";> Plugins + external resources --> e.g. Flash Native support + inline data --> e.g. JPEG <img href="data:..."> Plugins + inline data --> no examples yet, but why not? External resources vs. inline data are the ways that the spec defines things (e.g. data: URIs). Native support vs. plugins is what implementors decide, and it may vary from implementation to implementation (e.g. one browser displays PNG natively, another one does it through a plugin); this choice shouldn't affect how documents are written. -- Alexey Feldgendler <[EMAIL PROTECTED]> [ICQ: 115226275] http://feldgendler.livejournal.com
