Closed Bug 490 Opened 27 years ago Closed 25 years ago

[Dogfood] Editor needs to insert formatting whitespace

Categories

(Core :: DOM: Editor, defect, P3)

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: Klaus.Malorny, Assigned: akkzilla)

References

Details

(Whiteboard: [PDT-])

Created by Klaus Malorny (Klaus.Malorny@knipp.de) on Thursday, July 16, 1998 11:39:10 AM PDT Additional Details : The Composer creates '\n<BR>' for line breaks, e.g. entering Hello World! (RETURN) How are you today? (RETURN) generates ... <BODY> Hello World! <BR>How Are You Today <BR>&nbsp; ... The Linefeed before the <BR> tag creates additional white space, which is anoying in several circumstances (eg. you set the font size of the line to size=-2, then the '\n' produces a white space of size=0, which changes the line height). A better solution would be '<BR>\n', since whitespace is removed after a <BR>. You should review the following code for that: lib/layout/edtele.cpp, lines 6842, Method void CEditContainerElement::PrintOpen( CPrintState *pPrintState )
Assignee: brade → kostello
Reassign bug to kostello@netscape.com for further reassignment. I assume this will be fixed with the Raptor version of Composer but we should keep it around until we can verify that we properly format output to what Klaus (and I) think we should.
Status: NEW → ASSIGNED
Setting all current Open/Normal to M4.
Component: Composer → Editor
Product: MozillaClassic → Browser
Summary: Composer creates '\n<BR>' for line breaks (bad whitespace) → Composer creates '\n<BR>' for line breaks (bad whitespace)
Version: 1998-06-03 → other
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Target Milestone: M4 → M5
Changed Milestone to M5
Target Milestone: M5 → M8
Changed to M8
Assigning all kostello bugs to akkana
Assignee: kostello → akkana
Status: ASSIGNED → NEW
Summary: Composer creates '\n<BR>' for line breaks (bad whitespace) → XIF: Composer creates '\n<BR>' for line breaks (bad whitespace)
Somehow the status on all of these got set back to New; re-accepting them.
Just an update on this bug: I recently fixed the html content sink so that text and whitespace nodes outside of paragraph tags are saved in the html output. This means that whitespace from an original html document will be preserved. So in order to make br tags appear as <br>\n (which I agree is a good format, and no one on the newsgroup disagreed), the editor needs to include a node with the newline in the document whenever it inserts a <br> tag. I expect to do this for M8.
Target Milestone: M8 → M9
Sadly, I won't be able to commit to fix these in time for M8; we've had a huge flood of regressions in the last few days and I'll need to spend my time on tracking down where the bustage happened.
Summary: XIF: Composer creates '\n<BR>' for line breaks (bad whitespace) → Editor needs to insert formatting whitespace
Changing summary to reflect the real issue: that now that gecko and XIF pass through the formatting of the original document, the editor needs to insert formatting whitespace at appropriate places, e.g. InsertBreak needs to insert a <br> node plus a text node containing a linebreak. This isn't on the editor schedule yet but I'm working on an estimate for how much time we need to schedule for this.
I've checked in the fix for br tags. However, I've discovered that we need them in other places, too, like lists, so I'm keeping the bug open until I fix a few more.
Target Milestone: M9 → M11
I need to come up with a more general interface for specifying formatting, and this will depend on Joe's refactoring the InsertText code so that there will be a way to distinguish editable vs. noneditable nodes. This isn't in yet, so formatting will have to wait. Marking M11 for the whole thing but I'll try to get at least the basics in early in M10.
Target Milestone: M11 → M14
*** Bug 22423 has been marked as a duplicate of this bug. ***
Summary: Editor needs to insert formatting whitespace → [Dogfood] Editor needs to insert formatting whitespace
This bug makes editor unusable for submitting documents to www.mozilla.org. As with any other source code, HTML should be formatted in a way that's readable by humans, not obfusticated by removing whitespace. I'm not terribly picky about how its formatted, but keeping lines under 80 characters (except for things like long urls) should be a goal. Humans should be able to edit the documents and be able to make test cases for bugzilla. "cvs diff" should be able to return something meaningful after a document is edited. (not some giant 900character long monstrosity). There are several problems with accepting documents created with 4.x and I'd really like it if I could get composer users switched over to Mozilla but I can't do that until this is fixed. This applies to both the editor and to mail compose since people are likely to submit documents (rough drafts especially) via email.
marked [Dogfood]
Target Milestone: M14 → M13
I tend to agree with endico's comments; certainly for me, reasonable formatting (doesn't have to be perfect) is a dogfood requirement for an html editor. Bumping this up to M13 in the hopes that whoever is approving these things will agree that this is important. It's not a lot of work, and won't require any big infrastructure changes, just going in and fixing the places where this has regressed in the last month or so.
Whiteboard: PDT-
marking PDT-
Blocks: 22662
I've added some formatting whitespace when new nodes are inserted ... that should help a lot with the "lines too long" problem. Leaving this open because there are still lots of places where we should insert formatting, but we don't, and because we should also insert newlines in long text runs so that the source has reasonable (e.g. 72 column) line lengths.
Whiteboard: PDT- → [PDT-]
Whiteboard: [PDT-]
22662, which depends on this bug (in fact, it's really probably a dup of this bug) has just been marked PDT+, so this one needs to be, too. Removing PDT- so the PDT team can mark this PDT+.
Target Milestone: M13 → M15
I've taken 22662 -- an important manifestation of this need -- to M13, so I'm treating this bug as the more general issue (need to get formatting right, and pretty, and all that) and bumping it off to M15. Soliciting comments on whether M15 (post beta 1) is okay and whether the [dogfood] designation can be removed given the assumption that I'll get in enough formatting (after most tags and splitting long text nodes, but not necessarily always with the perfect line lengths or before/after tags in the most pleasing way).
This doesn't seem like the same issue as bug 22662. With 22662, there's no opportunity for the editor to insert formatting whitespace after HTML tags because it's one continuous stream of characters with no whitespace. So I don't think this bug should be PDT+ just because 22662 is. I still think this should be PDT-.
Whiteboard: [PDT-]
Do not believe this is a dup...please see phil is you have questions. Putting on pdt- radar.
Putting dogfood in the keyword field.
Keywords: dogfood
Now that we've switched over to the new model, the formatting is so much better than I don't think I need this tracking bug any more. Marking this fixed. If there are specific issues remaining with whitespace/newlines in html output, please file specific bugs against me.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
verified....please file new bugs if any other issues aren't fixed...
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.