Open
Bug 25141
Opened 25 years ago
Updated 3 years ago
new lines are removed from outside the <BODY>
Categories
(SeaMonkey :: Composer, defect, P3)
SeaMonkey
Composer
Tracking
(Not tracked)
NEW
People
(Reporter: rubydoo123, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
|
(deleted),
text/html
|
Details |
using build 200001252 on win95
the new lines in an HTML above the body element start tag are being removed --
for example, if I create a file with the html element start tag and head element
content that looks like this:
<HTML>
<HEAD>
<TITLE>Test</TITLE>
</HEAD>
ends up like this:
<HTML><HEAD><TITLE>Test</TITLE></HEAD>
why are they being stripped?
|
Reporter | |
Comment 1•25 years ago
|
||
talked with harish about this one this morning, assigning to him
Assignee: rickg → harishd
This bug has been marked "future" because the original netscape engineer working
on this is over-burdened. If you feel this
is an error, that you or another known resource will be working on this bug,or
if it blocks your work in some way -- please
attach your concern to the bug for reconsideration.
|
||
Comment 4•25 years ago
|
||
Is this in composer or View Source or what?
|
|
Reporter | |
Comment 6•24 years ago
|
||
this was happening when a user had an exisitng file, displayed it in the
application, opened it in Composer, saved it and then reviewed it in an external
app such as notepad or vi.
*** Bug 177303 has been marked as a duplicate of this bug. ***
Also affected:
</style>
</head>
becomes:
</style></head>
and
</body>
</html>
becomes:
</body></html>
This applies when "Retain Original Source Formatting" is selected in Composer
Preferences. See bug 177303 for more info.
|
||
Comment 10•22 years ago
|
||
|
||
Comment 11•22 years ago
|
||
*** Bug 174361 has been marked as a duplicate of this bug. ***
|
|
||
Comment 12•22 years ago
|
||
*** Bug 197018 has been marked as a duplicate of this bug. ***
|
|
||
Comment 13•22 years ago
|
||
Per David King's suggestion, copying information from one of the dups,
Bug 174361; these items have not been explicitly mentioned in this current bug:
- <PRE> text in multiple lines is all joined together as a single line with
<br> tags. This can result in lines that are too long to read in a standard
text editor.
- long <A> tags that are entered in multiple lines are all pulled together on
a single line.
See this attachment:
http://bugzilla.mozilla.org/attachment.cgi?id=102806&action=view
(That bug also mentioned an item covered by Bug 145196, and an item which
is unrelated to this bug, now described in Bug 199000.)
|
|
||
Comment 14•22 years ago
|
||
Also, note that Bug 197018, recently marked as a dupe of this, complains of the
opposite behavior for long tags: my original report complained that the tags
were wrapped onto one line, that bug complains that long tags are wrapped onto
multiple lines. Either way, if Retain Formatting is selected, ideally the
HTML source would not change at all.
|
||
Comment 15•22 years ago
|
||
Please don't morph this into a general tracking bug for all the problems with
"retain formatting". It would be useful to have such a bug, but this isn't it.
This bug describes a very specific and localized parser bug (which,
incidentally, is cross platform -- marking accordingly). This also applies to
newlines after the body, e.g. </body>\n</html> gets turned into </body></html>,
dropping the newline.
OS: Windows 95 → All
Hardware: PC → All
Summary: new lines are removed from above the <BODY> → new lines are removed from outside the <BODY>
|
|
||
Comment 16•22 years ago
|
||
Bug 174361 is now the tracking bug for problems with Composer's
"Retain formatting" behavior. Comment 13 and comment 14 should be
considered extraneous; mea culpa.
|
||
Comment 17•20 years ago
|
||
I'm not sure this is parser. When I removed the code in the parser that strips
newlines after </html>, etc. I still saw the bug. Perhaps composer is doing this
without parser's help?
|
||
Updated•15 years ago
|
Assignee: harishd → nobody
Status: ASSIGNED → NEW
QA Contact: moied → parser
This should be INVALID/WONTFIX per HTML5. If not, this needs to be escalated as a spec bug. HTML5 now preserves whitespace in <head> but hoists whitespace trailing </body> into body.
Tracking HTML5 now. HTML5 endorses the WebKit-ism described in comment #18.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
|
|
||
Comment 20•15 years ago
|
||
This bug has been (long) misfiled, as Blake suggested in comment 17 -- the problem is seen in the files saved by Composer. See reporter's comment 6.
Steps to reproduce are in comment 9.
It's not clear from comment 18 whether any of that was understood -- it seems that Henri Sivonen was treating this as a parser bug.
I'm reassigning this to the right component. Reopen? Problem still present in 2.0b2pre.
Component: HTML: Parser → Composer
Product: Core → SeaMonkey
QA Contact: parser → composer
Target Milestone: Future → ---
Reopened per comment 20. I was treating this as a parser bug, because it was in the parser component.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Note that it will be impossible for a DOM-based HTML editor to preserve formatting with the HTML5 parsing algorithm without some serious additional data on top of what the DOM provides. Storing that kind of additional data doesn't really make perf and code complexity sense for a parser designed for validators and browsers.
|
|
||
Comment 23•15 years ago
|
||
It is a parser bug -- the newlines are removed before composer ever gets the data. Composer can't preserve whitespace it never gets to see. That's why it was (and should be, IMO) in the parser component. If HTML5 makes that impossible, so be it (though it's sad).
Preserving formatting within tags would be a major per-impacting change to the HTML5 parser. (That is, preserving formatting in cases like
<foo
bar = "baz" > would be a WONTFIXable change, in my opinion.)
Preserving whitespace before <html> would be doable as an option but would increase code complexity for very minor gain. (In my opinion, it's Good Enough if editor reformats those bits nicely, i.e. adds a line break after doctype and each comment and throws away bogus comments that start with "?xml".)
Not hoisting whitespace after </body> and </html> into body would be doable as an option but would increase code complexity. Doing that would be sensible for the editor use case, though. Unfortunately, baking this property into the spec would harm the streamability properties of the HTML5 parsing algorithm, so on balance I'd rather leave the non-editor spec behavior as is here.
From the HTML5 parser POV, the easiest implementation for a Good Enough approximation of this feature would be making the parser insert a marker node where the first </body> was seen, so editor could reformat whitespace after that point if there's nothing but whitespace after that point. If editor has a strong need for this, please file a bug scoped to this issue against the HTML5 parser.
s/per-impacting/perf-impacting/
|
||
Comment 26•12 years ago
|
||
Still here with "retain formatting" enabled
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 SeaMonkey/2.13a1
Build identifier: 20120712003002
Status: REOPENED → NEW
You need to log in
before you can comment on or make changes to this bug.
Description
•