Closed Bug 39048 Opened 25 years ago Closed 21 years ago

xul does not support document.write

Categories

(Core :: XUL, defect, P3)

x86
All
defect

Tracking

()

RESOLVED WONTFIX
Future

People

(Reporter: pete, Assigned: pete)

Details

(Keywords: helpwanted)

Attachments

(2 files)

This is something i think is real important to have. It could be a great solution to skinning path issues etc. pete
Pete: can you flesh this out a little, for example, how does this solve the skinning path issue (or define the problem a little more). What does document.write give you that you can't do by createTextNode/appendChild. And how do you preserve _well-formedness_ if you allow arbitrary 'writes' to the document tree (aren't you better served by using the DOM api to be explicit about container/child relationships.
Hey John, My initial idea is for dynamically generating paths to skins, overlays, js files etc. Driven from a saved pref or whatever. for example: document.write('<?xml-stylesheet href="chrome://"+skinName+"/skin/" type="text/css"?>'); document.write is just another tool that could make alternative solutions available. pete
waterson's area, reassigning.
Assignee: trudelle → waterson
The "right way" to do this in XML is to use DOM ranges and createContextualFragment(). IIRC, this is in the DOM L2 spec. Unfortunately, we don't do it! Wish we did. -> Mfuture
Status: NEW → ASSIGNED
Keywords: helpwanted
Target Milestone: --- → Future
See also bug 5222.
Well, if it isn't against the law or anything, how hard is it to implement document.write in xul? If it is not to bad then i can think of lots of other good uses for it. How about for authoring tools , like a xul plain text editor. It can use document.write() to write xul to a preview window. document.write() is a widely used js method that web developers have come to know and love, i think it would be a great addition to xul. pete
Chris, range.createContextualFragment() is *not* part of the DOM Range spec, it was just added to the mozilla Range interface. And document.write() is only part of the DOM HTML spec, IOW doesn't and shouldn't apply for XUL documents. IMHO there's nothing you can do with document.write/ range.createContextualFragment() that you can't do without it, admittedly it sometimes takes more code in the client scripts to get the same thing done, and there are things in mozilla that currently don't work without these, for instance, dynamically adding a <?xml-stylesheet ...?> pi to a document should load the stylesheet the pi referes to but this doesn't currently work. I'm not saying that we absolutely should not add something like this, I'm saying that I think there are other standards supported sollutions to the problems typically solved with document.write().
(add brendan, he loves document.write!) jst: while you *are* correct that you can do anything with the DOM L1 standard that document.write() could do, it's often very unintuitive and computer sciency. I personally *favor* adding document.write (hey, it's XUL, we can do what we want, DOM spec be damned!), or at least createContextualFragment. But getting it and all of its subtleties worked out is probably not going to be easy. (Waterson throws down the gauntlet!)
Chris, assign this to me, I realize that this isn't a priority right now. But it is a cool thing to have. --pete
assigning to myself
Assignee: waterson → petejc
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
I don't know if this would work, but MAYBE you could assign a method to document.write in JSLib like: document.write = some function in JSLib. The function would use DOMParser to parse the contents. This is some BS code: write(content) { p = new DOMParser('text/xml'); tree = p.parse('<box xmlns="http://..mozilla...xul">' + content + '</box>'); tree = tree.childNodes[0]; parentnode = I don't know parentnode.appendChild(tree); } I don't know how the document's DOM tree gets built, or if this would even work with inline scripts. Well, time to work more on my presentation... San Diego has been decent so far. Expensive though :-(
Eric it is probably easier to just implement it in c++. --pete
Target Milestone: Future → mozilla0.9.4
Attached file test.xul
This file should change your mind. I made it in about 10 mins. Surely it can be improved, but at least you get the idea ;-)
If this is ever implemented make sure it's implemented in a way that works with other parsers than expat...
Detail: document.write is variadic, it concatenates its 0 or more arguments and parses them as if they occurred in place of the writing script tag. The patch's function should loop over [0, arguments.length) and build up a local string of code to parse. Also, I'm no guru, but does wrapping the code in a xul box tag really emulate document.write's behavior that the generated content is parsed as if it came in place of the writing script tag? /be
Umm, I know that my example does not work correctly. However, it does generate the same dom as it would without the script tag and added XML. Why? Because I am only appending the child of the <box>. I am merely using <box> as something to attach an xmlns attribute to, so it can be parsed into XUL nodes. OK, what needs to be done? 1. Loop through all <box> children, inserting them all into the document. Right now, it is just the first child. 2. For document.lastChild.appendChild(xul), document needs to be changed to the last and second deepest node in the document tree. This should be the parent node of the script tag, I think. It's doable, and should not be too hard to finish. Pete, what do you think???
eric: I think what you did is very cool and maybe even right, I was just asking (really, does document.lastChild refer to the script element when you use it from within a document.write call from that script tag? What does HTML's version of document.write do: append to the issuing script element, or in place of it, or after it in the same container? I don't know, but I thought I would ask here -- sorry if I was unclear). Sounds like you have the right approach, I'll just watch for the answers and go back to lurking. /be
The html implementation is here: http://lxr.mozilla.org/seamonkey/source/content/html/document/src/nsHTMLDocument.cpp#2296 It looks like it parses param *text_to_write. The only thing i'm not sure of, is if we made this a js component, can you map a single implementation to a single method? This method needs to live in nsIDOMXULDocument.idl --pete
Brenden, when the inline script runs, that script tag is the last elment in the document *at that time*. It's very cool how the document tree can be modified while the document is still loading :-) That does bring up a good point. The script node should be removed from the tree in the process. All this thing would need, is to be included at the top of the document, just like any other JS document. That's why it could be in JSLib or something similar.
Maybe my secondary point is that document.write really should be an option via JS, rather than integrated into Mozilla directly.
Eric, if it's an option, then we can just slap in into jslib w/ perhaps some variations like writeln(). But i think this is a worthy bug to implement, because the first thing any xul developer is going to say is "you can't do document.write in XUL?". document.write is *such* a popular method it is worth having around in XUL world IMHO. --pete
Eric, what's cool about your implementation, is i can do something like: parser.parseFromString(f.read(), 'text/xml'); Where f.read() is a file initialized from jslib File object. --pete
Personally, I think document.write is hackish. I hardly ever used it for HTML, and XUL should need a real extreme case to justify using it ;-) Ah, yeah. Cool idea with the file :-)
Target Milestone: mozilla0.9.4 → mozilla0.9.5
I'll try to finish up my JS implementation of this soon... maybe this weekend.
OK, I apparently either made a bad assumption, or found a bug. I need to append the element in the same childNodes area as the <script> tag is in. Unfortunately, I cannot know where this is because the <script> tag is not in the DOM when the JavaScript is invoked. For a simple example: <script id="this_doesnt_exist_yet"> alert(document.getElementById('this_doesnt_exist_yet')); // alerts null </script> I have attached a detailed example of this. I will post to DOM newsgroup to help determine if this is a bug.
Attached file write.xul
Well, I got an answer from Heikki: "At the point the script is executing, we have not closed the script element and hence it can not appear in the DOM. In my opinion it is not a bug, and it seems IE handles this as we do." I think there may be a way around this using some better logic, or at least a simple hack of some sort (a requirement for usage).
pushing back
Target Milestone: mozilla0.9.5 → mozilla0.9.7
marking future
Target Milestone: mozilla0.9.7 → Future
Depends on: 124412
No longer depends on: 124412
uuh, 2001 :) Any updates? I am interested in this feature.
I think this should be WONTFIXed. I don't want to carry around the maintenance burden of document.write() for XUL; there are DOM APIs that can do pretty much anything equivalent.
Yea, this is old and really a wontfix now. document.write is very popular. The same can be accomplished using DOM API's.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: