Re: new lines missing in innerHTML (FF 1.5.0.4)
Martin Honnen
Nevis wrote:
> I switched to FF 1.5.0.4 as soon as it had been marked stable
> in gentoo portage. The previous stable version was 1.0.8.
> And here's the problem:
> I load a plain text file into a hidden iframe and
> then copy innerHTML to a div:
> div.innerHTML=iframe.document.body.innerHTML;
> This div has an explicit style='white-space: pre;' attribute.
> The problem is there are no more new lines left in iframe.innerHTML
> and the whole file shows up as one very long line.
> It used to be working in 1.0.8. Is it a known problem
> or should I file a bug?
I have made a test case at
<http://home.arcor.de/martin.honnen/mozillaBugs/domLevel2/html/iframeTextInnerHTML1.html>
and see the problem with Firefox 1.5 as well as a trunk nightly of
today, it shows that the innerHTML of the virtual body of the plain text
document is
Line 1. Line 2. Line 3. Line 4.
whereas with Gecko/Mozilla 1.7 it is
<pre>Line 1.
Line 2.
Line 3.
Line 4.
</pre>
so both the pre element and the line breaks are missing in Gecko 1.8 and
1.9.
I am not sure there is any spec telling what is right besides IE setting
a precedent, with IE 6 the innerHTML shows as
<PRE>Line 1.
Line 2.
Line 3.
Line 4.
</PRE>
Does anyone have an idea what caused that change for the text document's
body.innerHTML?
--
Martin Honnen
http://JavaScript.FAQTs.com/
Boris Zbarsky
> Does anyone have an idea what caused that change for the text document's
> body.innerHTML?
Looks like the change from bug 155723 -- we used to always serialize innerHTML
as HTML, but that change made us serialize it as whatever type the document
really is (so that XML works right). I'm not sure why the newlines are getting
lost, though -- that seems broken.
Is there a bug filed?
-Boris
Boris Zbarsky
> I am not sure there is any spec telling what is right besides IE setting
> a precedent, with IE 6 the innerHTML shows as
The spec says nothing. The fact that there is even a DOM for text/plain content
is an implementation detail; one that's not guaranteed to continue.
-Boris
Nevis
> Crosspost and followup-to mozilla.dev.tech.dom
Thanks Martin,
Didn't know there's a group for tech questions.
Sasha
Nevis
>> I am not sure there is any spec telling what is right besides IE
>> setting a precedent, with IE 6 the innerHTML shows as
> The spec says nothing.
Somehow this works in both IE and Mozilla.
As a web developer I'd like to have a standard DOM method which
would parse html/xhtml into a document fragment and vise versa.
> The fact that there is even a DOM for text/plain
> content is an implementation detail; one that's not guaranteed to continue.
Why shouldn't text/plain content of an iframe be part of a DOM tree?
FYI: The purpose of the original script was to avoid server-side
includes and still be able to display a collection of text/plain files
with various styles and colors on the client.
Sasha
Boris Zbarsky
> Somehow this works in both IE and Mozilla.
> As a web developer I'd like to have a standard DOM method which
> would parse html/xhtml into a document fragment and vise versa.
Sure. but in this case you're not working with HTML/XHTML.
>> The fact that there is even a DOM for text/plain
>> content is an implementation detail; one that's not guaranteed to continue.
>
> Why shouldn't text/plain content of an iframe be part of a DOM tree?
Because there's no inherent DOM for text/plain. DOM is a concept that relies on
a tree structure to the language; where's the tree structure for text/plain?
> FYI: The purpose of the original script was to avoid server-side
> includes and still be able to display a collection of text/plain files
> with various styles and colors on the client.
Sure. That doesn't require that there be a <pre> around, right?
-Boris
Alexander Kirillov
>> As a web developer I'd like to have a standard DOM method which
>> would parse html/xhtml into a document fragment and vise versa.
>
> Sure. but in this case you're not working with HTML/XHTML.
Yep. Creating complex fragments with existing DOM methods is a pain in
the tail. So I prefer to clone hidden templates changing some essential
parameters instead. I think innerHTML is a convenient MS helper property
and hope an equivalent of this will make it into DOM standard sooner or
later:)
>>> The fact that there is even a DOM for text/plain
>>> content is an implementation detail; one that's not guaranteed to
>>> continue.
>>
>> Why shouldn't text/plain content of an iframe be part of a DOM tree?
>
> Because there's no inherent DOM for text/plain. DOM is a concept that
> relies on a tree structure to the language; where's the tree structure
> for text/plain?
Could be just text node in one piece.
>> FYI: The purpose of the original script was to avoid server-side
>> includes and still be able to display a collection of text/plain files
>> with various styles and colors on the client.
>
> Sure. That doesn't require that there be a <pre> around, right?
Right.
Sasha
Boris Zbarsky
> Could be just text node in one piece.
That's not a valid DOM -- you can't have Text nodes as direct children of the
Document.
-Boris
Alexander Kirillov
>
> That's not a valid DOM -- you can't have Text nodes as direct children
> of the Document.
You must be right. I didn't read the specs in great detail.
Hope the bulging brains will come up with something
to attend to the needs of dumb end consumers of DOM standard:)
Thanks for your patience,
Sasha
Boris Zbarsky
> I have made a test case at
> <http://home.arcor.de/martin.honnen/mozillaBugs/domLevel2/html/iframeTextInnerHTML1.html>
So what seems to be going on here is that the plaintext serializer is broken
when used in Raw mode -- it loses newlines. It should just preserve them in Raw
mode, imo.
That said, maybe we should switch to just serializing innerHTML as HTML for any
case-insensitive document (including text/plain) instead of serializing as the
actual content type?
-Boris
Alexander Kirillov
http://bugzilla.mozilla.org/show_bug.cgi?id=340800
and gave a reference to Martin's test page.
Thanks for your help,
Sasha