Closed Bug 237330 Opened 20 years ago Closed 20 years ago

javascript split() can't match innerHTML string if broken up into separate lines in the source

Categories

(Core :: DOM: Core & HTML, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: TailsTheKitsune, Unassigned)

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040219
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040219

See attachment. Let's say we have A, B, C, and D in a paragraph each separated
by a pair of <br> tags. We can access the innerHTML of the paragraph and split
the letters up by the 2 <br> tags in between. However, if those 2 <br> tags
aren't written on the same line in the source, the <br> tags will be mistaken as
part of the string and that part won't be split. InnerHTML shouldn't rely on how
many lines apart elements are in the source.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Actual Results:  
The pair of <br> tags when on different lines aren't found as a matching string
in a javascript string.split('<br><br>') statement.

Expected Results:  
The 2 <br> tags, even though they are lines apart, should be seen as being on
the same line in the innerHTML. Adding blank lines into the source shouldn't
affect the innerHTML. Coders should be able to space their tags out however they
want since line breaks in the source shouldn't affect the document.

Also reproducable in Firefox. This seems to be a bug in the Gecko engine.
View the source of the page to see break between the 2 <br> tags and how this
causes a problem.
Um.. innerHTML should be returning exactly what the HTML was, no?  Does it not
do that in IE?

It can't strip out whitespace because whitespace in HTML can be significant
depending on what the white-space CSS property is set to....
Component: DOM: HTML → DOM: Mozilla Extensions
The issue more about line spacing than space characters. If there's 01 or 100
blank lines between 2 <br> tags, there is no visual representation that gets
modified on the page. And on further note for the CSS whitespace property, that
doesn't give reason for whitespace to be floating around the body where text
doesn't belong.
> If there's 01 or 100 blank lines between 2 <br> tags, 
> there is no visual representation that gets modified on the page

That's not true.  If the container of those <br> tags has "whites-space: pre"
the rendering will be _very_ different.  Try it.

As for where text belongs, it's allowed pretty much anywhere in the document....
 In particular, in that testcase text is most definitely allowed between the two
<br> tags.

You still haven't answered my question as to what IE does.  Please test both the
case you posted here and the case when the <p> tag has "white-space: pre" set.
(In reply to comment #4)

> You still haven't answered my question as to what IE does.  Please test both the
> case you posted here and the case when the <p> tag has "white-space: pre" set.

IE 6 doesn't seem to understand white-space:pre. 
<p style="white-space: pre; ">
a
b
</p>

is rendered as 
a b

besides that, alert(document.getElementById('x').innerHTML;) from the example
shows up as "A<BR><BR>B<BR><BR>C<BR><BR>D" the tags become uppercase and the
line feed is removed.
Changing the <p> to <pre> keeps the line feed, but again the rendering in the
screen is different. 
In mozilla it's shown as:
----
A

B

C


D
----

in IE 6 is:
----
A
B
C

D
----
I see.  Sounds like IE and Mozilla just have different DOMs there, and both
serialize their DOM out when you get innerHTML.  Unfortunately, we can't
generate the IE DOM because it would result in incorrect layout....
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
Also note that you cannot use \n or regular expressions to search innerHTML when
there are line breaks in the source.
> or regular expressions to search innerHTML 

Er, yes you can.  You just have to be a little more careful with your regular
expressions.
Component: DOM: Mozilla Extensions → DOM
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: