Composer preferences let you choose between "reformat" and "retain formatting"; the latter does not do a very good job. Particular problem areas: - The entire file head (DOCTYPE-html-head-title) may all joined onto a single line, and/or blank lines (containings some spaces) inserted; similarly, the terminal </body></html> are placed on a single line. - <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. - an inline style such as "background: yellow" is expanded to include all the possible fields for 'background'. - spurious <br> tags added (see bottom of test file) There may be other areas as well; the first two are what I've been running up against. To reproduce: In Composer, set preference to "Retain formatting." Open a typical HTML file from another source (e.g. handcoded). "Save As" to a new file. The changes can be seen in a diff. Will add demo source file as attachment. I'm using Mozilla 1.1 (20020826).

--> charley. Charley, what is the intent behind retain formatting, and do we really live up to it?

I've recently installed 1.2.1 (20021130) and checked how this feature performs, compared to 1.1. One improvement: the spurious <br> tag is no longer generated in this test file. (I can't say if that's the case across the board, but I believe this item was the core of another bug.) The other items mentioned all stand. Also, regarding the first item, about the reformatting of the head and closing lines: I noticed that in both 1.1 and 1.2.1, if Retain Formatting is OFF, these sections are still reformatted -- but the formatting used for this mode is much different, and, as it happens, closer to the formatting I use when coding the HTML in a text editor.

I have exactly this problem on Mozilla 1.1/FreeBSD 4.7/XFree86 4.2. The undesired reformatting of text within <pre>...</pre> is extremely annoying - sufficient for me to avoid using composer.

see also bug 179531 and bug 145196

I believe this to be a dup of Bug #25141, marking as such. *** This bug has been marked as a duplicate of 25141 ***

It seems to me that, rather, Bug 25141 describes one of the several symptoms described in comment 1. That bug (which appears to be truly duplicated by Bug 97278 and Bug 176866, both still open) deals only with the Composer's inability to maintain newlines in the HTML source. Bug 197018 covers the wrapped tag issue noted here. I don't know of another bug that covers the <PRE> tag problem noted here. It seems to me that the issue of Composer not maintaining the original file's format is an overarching issue. There are probably other symptoms not reported here, or not at all. The title of this bug seems appropriate to that purpose. If you disagree, then I'll have to open a new bug for the <PRE> issue.

The way I see it is that the <pre> issue is part of the bigger picture where CRLF's are being stripped from the HTML source resulting in long lines of HTML. The way it manifests itself with <pre> and in maintaining "correct" page layout is by inserting <BR>'s (which of course is totally wrong [see XHTML v2.0 spec 31Jan2003]). Rather than file a seperate bug for the <pre> issue, may I suggest that you add that example to Bug #25141. The reason I suggest this is because the <pre></pre> is a clear example where the HTML source must not be altered by Composer as white space and CR, LF's are significant. I'm still looking at the other bugs you mention to determine duplicity.

Per David's comments, I have copied the relevant info to Bug 25141, and opened a new Bug 199000 for the issue of the expansion of the 'style' attribute.

Bug 25141 is a very small and specific issue: whitespace information outside the body is lost by the parser, and the editor therefore can't preserve it. That has nothing to do with newlines inside <pre> being turned into <br>. The reason for the newline-to-br conversion is explained in bug 92921: it is a workaround for a longstanding layout bug, bug 85505. I think there's another bug on the spurious br tags; in fact, I think there's a fix in progress. I don't have a bug number to point to, but try a search on editor bugs changed in the last week or two. The lack of formatting inside tags (e.g. long a or img tags) is another layout limitation: that information simply isn't in the dom, so composer has no way of recreating it. I think I filed a bug on that long ago but don't have the number handy (and I see little hope that it will be fixed since the dom doesn't offer any mechanism to store that information) so the best we're likely to do is smarter prettyprinting inside tags. Incidentally, I don't think we have a good meta-bug for tracking all the issues related to "preserve formatting" not working well. A bug like that (perhaps this bug) might be useful, if someone wanted to do the work of collecting dependencies. Otherwise there's not much point in reopening it even though I agree it's not a dup of 25141.

Hmmm, two more bugs I didn't find in my searching. I agree, we need a META tracking bug. I could turn this bug into the tracking bug (with Mike C's permission), however I wont always have time to keep it up to date (I'm going through a divorce and moving country). However, if noone else steps forward, I'll do it.

Perfectly OK with me if this becomes a tracking bug. Altho I did email everyone who had a vote for this asking them to switch it to the ostensible duplicatee, and it looks like most of them complied. Guess I was hasty. :)

Changing to a meta tracking bug as per prior comments.

Hmmm, this tracking bug probably should be assigned to me.

Probably related: Bug 200264 - "Composer changes the format of entities" Prog.

Adding Bug 200264 and Bug 174216. Somehow, I get the feeling that I'm going to have to find some time to sort out any dups in this list of bugs.

Hmmm, strickly speaking, Bug# 167262 isn't caused by the "Retain Formatting" switch, however I'll leave it on here as it is another example of Composer not retaining formatting.

This bug is still open in 1.7RC1. Retain formatting does not work. Another simple test case, enter this in source view: <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="content-type"> <title> </title> </head> <body> <br> </body> </html> Composer always puts the <html><head> on the same line as well as the </head><body>. Also, it messes up internal elements like form. This was the first time I tried to use Composer and I was surprised something as simple as this is broken (and has been for this long). Now I have to switch to something else.

DEFINITELY still exists in v1.7 on MacOSX build. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040616 Preference is "retain"; results always mangled.

*** Bug 257125 has been marked as a duplicate of this bug. ***

The option "Preserve original source formatting" does not preserve original source formatting. Not at all. Never. It even produces junk like "</td><td>" (merging lines in complete violence of the structure) which it handles more decent without that option.