Closed
Bug 39048
Opened 25 years ago
Closed 21 years ago
xul does not support document.write
Categories
(Core :: XUL, defect, P3)
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
Comment 1•25 years ago
|
||
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.
Assignee | ||
Comment 2•25 years ago
|
||
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
Comment 4•25 years ago
|
||
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
Assignee | ||
Comment 6•25 years ago
|
||
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
Comment 7•25 years ago
|
||
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().
Comment 8•25 years ago
|
||
(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!)
Assignee | ||
Comment 9•24 years ago
|
||
Chris, assign this to me, I realize that this isn't a priority right now.
But it is a cool thing to have.
--pete
Assignee | ||
Comment 10•24 years ago
|
||
assigning to myself
Assignee: waterson → petejc
Status: ASSIGNED → NEW
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 11•24 years ago
|
||
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 :-(
Assignee | ||
Comment 12•24 years ago
|
||
Eric it is probably easier to just implement it in c++.
--pete
Assignee | ||
Updated•24 years ago
|
Target Milestone: Future → mozilla0.9.4
Comment 13•24 years ago
|
||
Comment 14•24 years ago
|
||
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 ;-)
Comment 15•24 years ago
|
||
If this is ever implemented make sure it's implemented in a way that works with
other parsers than expat...
Comment 16•24 years ago
|
||
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
Comment 17•24 years ago
|
||
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???
Comment 18•24 years ago
|
||
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
Assignee | ||
Comment 19•24 years ago
|
||
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
Comment 20•24 years ago
|
||
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.
Comment 21•24 years ago
|
||
Maybe my secondary point is that document.write really should be an option via
JS, rather than integrated into Mozilla directly.
Assignee | ||
Comment 22•24 years ago
|
||
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
Assignee | ||
Comment 23•24 years ago
|
||
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
Comment 24•24 years ago
|
||
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 :-)
Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Comment 25•24 years ago
|
||
I'll try to finish up my JS implementation of this soon... maybe this weekend.
Comment 26•24 years ago
|
||
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.
Comment 27•24 years ago
|
||
Comment 28•24 years ago
|
||
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).
Comment 31•21 years ago
|
||
uuh, 2001 :) Any updates? I am interested in this feature.
Comment 32•21 years ago
|
||
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.
Assignee | ||
Comment 33•21 years ago
|
||
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.
Description
•