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)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: TailsTheKitsune, Unassigned)
Details
Attachments
(1 file)
495 bytes,
text/html
|
Details |
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.
Comment 2•20 years ago
|
||
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.
Comment 4•20 years ago
|
||
> 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.
Comment 5•20 years ago
|
||
(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 ----
Comment 6•20 years ago
|
||
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.
Comment 8•20 years ago
|
||
> or regular expressions to search innerHTML
Er, yes you can. You just have to be a little more careful with your regular
expressions.
Updated•11 years ago
|
Component: DOM: Mozilla Extensions → DOM
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•