Only an enhancement request XML Data Islands are a Microsoft IE5 feature. I wouldn't expect you to provide all MS extensions. However, this is a pretty useful one for thin clients which use http to transfer data as XML. The crux of it is that we'd get a consistent way to get at the XML embedded into documents. This is a really exciting example of its use in IE5. <HTML> <BODY onload=alert(document.getElementById("D").XMLDocument.childNodes.item(0).nodeName)> <XML ID="D"><CARROT/></XML> </BODY> </HTML> I presume you'll have no trouble finding details of MS's documented element.
Ian Richards, I believe this request is a duplicate of bug 15119, which has been marked fixed. Can you check if it is?
Summary: Enhancement Request: Can XML Data Islands be supported? → RFE: XML Data Islands support
It is :-) Gerv *** This bug has been marked as a duplicate of 15119 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
Marking verified then :-)
Status: RESOLVED → VERIFIED
I re-open this bug because the requested functionality is in no way implemented at this time. The original enhancement request describes inline data islands. http://bugzilla.mozilla.org/show_bug.cgi?id=15119 (fixed) describes out-of-band XML loading&parsing. This functionality is in Mozilla now, and working. (See the xml n.g. for details) Data island functionality is related to 15119, but not the same thing. The request here is for an easy way to include XML fragments into (non-XHTML) HTML. One possible approach is to just include custom XML into the HTML document and hide it using CSS. However, empty elements (<carrot/>) are not recognized by the HTML parser. This prevents correct DOM access to the embedded XML data. The IE5 browser implements inline xml data islands using the <XML> tag. One other valid syntax is, IIRC, <SCRIPT language="XML"> To summarize: We need a cutom tag (or an extension of an existing (script?) tag that will have the following properties: -all tags inside the delimiter tag are ignored by the HTML parser&rendering engine -the XML tree inside the delimiter tag is acessible as a XML Document interface
Status: VERIFIED → UNCONFIRMED
Resolution: DUPLICATE → ---
setting to New
I'm adding this copy of a posting to the xml n.g. to this bug. Some useful links: Here's the online MSDN documentation: Microsoft syntax: http://msdn.microsoft.com/xml/xmlguide/dataIslandHowTo.asp http://msdn.microsoft.com/library/psdk/xmlsdk/xmlp504z.htm Sample: http://msdn.microsoft.com/xml/_archive/access_island.asp This gives a good overview: (W3C XML in HTML Meeting Report) http://www.w3.org/TR/NOTE-xh To summarize: -inline xml data islands should always be enclosed in a specific tag -a property ("XMLDocument") should be used to access the XML Document from the enclosing HTML level tag.
This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
I would like to add that both "inline" and "external" islands (as implemented in IE5) have their uses. A common pattern is to use two islands, one for xml data, and the other for XSL/XSLT.
adding helpwanted... (i'd sure find this feature helpful and useful!)
A possible hack would be to reuse the SCRIPT element (that has CDATA contents) for XML, as described in http://www.w3.org/TR/NOTE-xh At the moment, you can get the CDATA contents of SCRIPT elements through HTML DOM1. That character string can then be passed to the XML Parser component from the "xmlextras" module. Unfortunately, this workaround only works for "embedded/inline" script elements, since the "loadstate" and contents of SCRIPT SRC=... elements is not available through HTML DOM1. If there is a lowel-level Mozilla interface to access the readystate/loadstate and CDATA contents of external SCRIPT elements, a small wrapper component could be written that takes an element ID of a SCRIPT element, checks if the element is loaded (when external/SRC=...), gets the CDATA string, parses it, and returns a XML DOM Document reference. SCRIPT elements containing XML could be marked language="XML" or type="text/xml", as mentioned in the W3C DOM note.
I know it's been over a year since anyone commented on this bug, but here's my two cents: There should be no need for an <xml>...</xml> tag. There are a number of ways we can import an XML document into an HTML document and its corresponding DOM. iframe elements and object elements are two of the ideas which come to mind. With iframes, it'd be window.frames[frameid].document. With object elements, it'd be document.getElementById(frameid).contentDocument. Microsoft's support for the same is quite different -- they force a default stylesheet on us when we don't use an XML data island. In short, I don't see a reason to break HTML compliance for this, when current HTML support -- and the current, good state of the Document Object Model -- will be more than enough. I recommend INVALID or WONTFIX for this bug.
I'm guessing that if this is ever implemented it would only work in quirks mode as by including xml data islands it would render a page non w3c html4 compliant. I'm also guessing that this is not exactly an xml feature but really a html feature.
See also bug 116277.
Because we have a bug to document a workaround for this, I'll mark this WONTFIX. Please see bug 116277 for details about the workaround.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago → 17 years ago
Resolution: --- → WONTFIX
*** Bug 278501 has been marked as a duplicate of this bug. ***
*** Bug 305562 has been marked as a duplicate of this bug. ***
*** Bug 327577 has been marked as a duplicate of this bug. ***
*** Bug 327577 has been marked as a duplicate of this bug. ***
That is the different with Microsoft. They most support Java... Why? Java is common. Over 70% user using IE in the world. If user can't see content with other browser, what will they do? Ans: use IE. If technical support don't waste time to solve this. what will they do? Ans: Add the sentence at bottom "Best viewed with IE ....." Because they are the common browser.
You need to log in before you can comment on or make changes to this bug.