Closed Bug 17994 Opened 25 years ago Closed 24 years ago

indent and outdent work but skips down a line

Categories

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

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: sujay, Assigned: rubydoo123)

References

Details

(Whiteboard: [PDT+])

using 11/4 build of apprunner(1999110408) on all platforms 1) launch apprunner 2) launch editor 3) enter some text 4) insert cursor at beginning of text 5) hit indent button on toolbar notice it does indent buyt only after jumping down a line.. in 4.x it doesn't do this, it cleanly indent the text to the right w/o moving down a line... all platforms.
Assignee: buster → jfrancis
assigned to floppy moose, but since he doesn't have an account, it goes to joes
Sujay -- this works fine for me on win95 and Mac using the 19991104 build. I'll try on Linux when I get the new build loaded
I can easily reproduce this one...Beth, are you in office? I can come by and show you...
no I'm in SD and I can't get it to reproduce -- this is what I am doing: 1. open apprunner 2. select File|Edit Blank Page 3. Type in aaabbbcccdddeee 4. Select Home 5. Select Right Indent from toolbar Result, the line indents and caret remains on the same line. I tried this on win95 and Mac using today's build
looks like we're both right Beth.... The bug happens when you try it on the "second" line.. so repeat what you did on the seonc line and you'll see the behavior I reported...
Target Milestone: M13
What's happening is the second line is actually nested within a blockquote. Joe, this is one of those rule instances that need to be resolved for the editor. Setting to M13
blockquotes, like paragraphs, have (by default) some vertical margins. 4.x puts things inside lists to indent (but without list items). We cant do that, because it is illformed html and the whole 5.0 story is standards compliance. we could make a style sheet to get rid of vertical margins around blockquotes, but then recipients would be more likely to see something different than the sender intended. cc'ing several folks to get thoughts.
ACCKK! Not another "extra vertical space" problem! HTML sucks! I don't see an easy way around it - no subsitution of another tag as in the <p> to <div type="_moz"> morph. There's a complex substitution: <ul><li><div type="_moz"> Note: 4.6 uses BLOCKQUOTE, but I remember we did use to use <li> (maybe pre 4.5) I think the <div> makes anything under it now legal, which is not true under <li> directly (thus the bad HTML by that earlier version.) If we have to resort to CSS, then we shouldn't use BLOCKQUOTE at all. In fact that is what HTML 4.0 dictates: do indenting via CSS. But that's not good for mail, which has an older compatability requirement. There is not HTML way to do indent except list and blockquote.
Aren't we going to have a different ruleset for the editor?
The ruleset for Composer isn't the problem. We'll have fewerer complaints if we use CSS there. It's mail composer that's the trouble.
Charlie's example is wrong in a couple of ways. First off, you can put anything in an <li>, so the div is unneccessary. Second, the <li> would cause a bullet to appear, which we don't want. You could suppress the bullet with CSS, but what's the point? Might as well use CSS to do the indenting to start with, as Charlie says. Older Communicators put things directly in the <ul>, without an <li>. That solution gets the desired rendering behavior in some clients, but it's illegal html.
Let me test my understanding -- if we use the blockquote and use the style attribute to indent, older versions would just ignore the style attribute -- which is what we want to have happen right?
accepting bug
*** Bug 21876 has been marked as a duplicate of this bug. ***
*** Bug 21437 has been marked as a duplicate of this bug. ***
Target Milestone: M13 → M14
moving this to m14
It's a bugger, this one. Some thoughts/opinions: - When composing HTML pages, pressing "indent" button should definitely _not_ insert a blockquote. We shouldn't confuse these two things. Either lose the button completely or make it insert appropriate CSS instead of a blockquote. (The latter is probably the preferable option, since most people will expect to see a plain old indent button in any editor.) - Since backwards compatibility is apparently needed when composing HTML e-mail messages, could we just insert a <blockquote style="margin:0"> or equivalent _only_ when in "Mail mode"? Can we have "Mail mode" and "Composer mode" separately, anyway? Do we want to?
I agree that using blockqoute is not the best choice, but it was a better alternative in the 4.x app than what was previously being used. One solution that could be used is to insert style="margin-left: 40px" into the text node parent element. The exception would be if the parent was <BODY>, in that case we would probably want to wrap a <DIV> around the text node. We do not want to wrap a <DIV> around the text node parent though. For example, if the text node is currently within a <P>, we would not want it to end up like this: <DIV style="margin-left: 40px"><P>foo</P></DIV> -- this would invalidate any CSS that may be used in conjunction with the file. I believe inserting the CSS into the parent is the right way to go, inserting an additional element should be the exception and not the rule. Of course we could always use an index instead of adding the style into the parent element. Another issue that will need to be resolved is how will we update the indent on the toolbar, especially when the file is saved out and then brought back in again.
beppe: If we want backwards compatibility in HTML mail, we cannot rely on CSS. That's why blockquote is apparently still needed. Correction: In my previous comment, I actually meant <blockquote style="margin-top: 0; margin-bottom: 0"> instead of <blockquote style="margin:0">.
this particular bug is not about mail, that is a separate issue. Granted both issues need to be resolved. However, for Composer constructed web pages, using a CSS solution is most appropriate. For mail, being 4.0 compliant is not as much of an issue. In that respect, yes we could insert a blockquote as you suggest and include the CSS of margin: 0.
i'm completely confused by thies bug. first off, mail is all we are right now when it comes to html editting. we dont have a seperate ruleset at this point for html composer. so we should push this bug off to a later milestone if we are just talking about composer behavior. In mail news, we cant do what 4.x did: putting arbitrary stuff into a <ul>. That's just bad html. We also can't use css if we want to be wysywig with respect to older html mail clients that dont support css. So which bomb do we want to sit on? If we want to keep things like they are now this bug should go away.
Joe -- for mail, we have 2 issues -- 1. be backwards compatible with 4.x and 2. display correctly with seamonkey. If we utilized the blockquote, as we did in 4.x, then the backwards compatible issue is resolved. If we include the style attribut and specifically set the top and right margins to zero, then we can take care of the rendering issue with seamonkey. This of course is a temporary fix, we can modify this coding behavior in the future when the requirement to support 4.x is less critical. Bottom line is this: I recommend that we use the blockquote element, with the style attribute used to set the upper and right margins to zero. 4.x will display the indent as surrent users would expect and seamonkey users will see the indent without the right or top margin. I created a new message with a blockquote containing this: <BLOCKQUOTE STYLE="margin-top: 0, margin-right: 0"> in 4.x, the message displayed as expected -- need to reboot before testing on seamonkey
the right margin in seamonkey is rendering correctly, but the top margin set to 0em is not being honored -- that is happening in mail as well as the browser
ok, I've been doing some experimenting -- I've tried playing with <DIV> and with <BLOCKQUOTE>. Blockqoute is the way to go. The solution I could come up with that will provide an appropriate left indent for both 5.x & 4.x and be beacwards compatible is this: <BLOCKQUOTE STYLE="margin: 0 0 0 40px"> 4.x ignores the style attribute (and we must discuss this solution with the 4.x team) and 5.x renders it as expected.
Keywords: beta1
Whiteboard: [PDT+]
fixed. You may see an extra line after an indent now, but there shouldnt be one before. The one after is part of a different bug: 22331
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
This one appears to be fixed on build 2000021316 (Windows NT4 SP6a) - although I don't see why we're using '0pt' instead of just '0' for the zero margins: <blockquote style="margin-top: 0pt; margin-right: 0pt; margin-bottom: 0pt; margin-left: 40px; "> '0pt' is not wrong, of course, but IMHO losing the unit identifier would make it simpler and clearer. beppe's suggestion (style="margin: 0 0 0 40px") would be even more simple. But then, this is just a matter of taste - so feel free to mark this Verified/Fixed if you disagree (or if there are technical reasons for using '0pt').
in fact, I did use style="margin: 0 0 0 40px". Where are you seeing 0pt? Sounds like something retranslated it before you saw it.
verified in 2/14 build.
Status: RESOLVED → VERIFIED
jfrancis, here's what I do: 1) start Composer 2) type anything 3) indent it with the indent button 4) save the document 5) view the HTML source in any application ...and here's how the indent looks like: <blockquote style="margin-top: 0pt; margin-right: 0pt; margin-bottom: 0pt; margin-left: 40px; "> The result's identical on builds 2000021316 and 2000021408 (WinNT4 SP6a).
hmmm. I guess the output system puts style attributes into some canonical form? I didn't realize it would do this. Akkana, does this sound right?
Here's what I see on linux: I type something into the editor and indent it with the button. Now I do Debug->Dump Content Tree and what I see in the tree is: blockquote@0x852876c _moz_dirty= style=margin-top: 0pt; margin-right: 0pt; margin-bottom: 0pt; margin-left: 40px; refcount=7< Then I do Debug->Output HTML, and what I see in the output is: <blockquote style="margin-top: 0pt; margin-right: 0pt; margin-bottom: 0pt; margin-left: 40px; "> So it's not the output system; the output system is putting out the attributes which are really in the tree. It must be the html elements themselves (or possibly the parser?) which are adding these "pt" specifiers to the zero values. I agree that it would look cleaner if we didn't put these in, so it might be worth filing another bug on this issue if anyone cares enough.
this is not working in recent builds....following scenarios: 1) enter text, hit indent twice...notice it jumps down line 2) enter text, hit indent once, enter text below first line, hit outdent notice it does outdent, but it jumps down one line. so we got two problems here...both with indent and outdent.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Summary: indent works but skips down a line → indentand outdent work but skips down a line
reassigning to beppe. Not sure why this is reopened. isn't it a dead snake? I thought we decided to get rid of the style attributes in order to play better with 4.x. (Note that this bug dates from M14!) I can make this work whichever way we want, it's just tradeoffs...
Assignee: jfrancis → beppe
Status: REOPENED → NEW
the margins is controlled by CSS, looking at the code that is generated it is being generated correctly. Please remember that blockquote is a block element and the top and bottom margins are expected behavior. BTW -- the margin settings messed up the layout of mail notes going to 4.x
Status: NEW → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Summary: indentand outdent work but skips down a line → indent and outdent work but skips down a line
verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.