Spacing Problem

Yermo · 2005-03-18 21:25:36

dlst wrote:

Sorry Yermo, I disagree. I've never had a problem teaching users to do "shift-enter" to get a line break. Certainly (in my case) the majority of users understand that they are on a computer, not a type writer, and a minor concession is not a problem.

It doesn't sound like you intend to support 1000's of users used to word processors.

Ideally I'd like to be in a position to train people; but it's too expensive. My design requirements are that I have to sell into an existing base of concepts. One of those concepts is that the enter key produces a newline.

The technical solution I hope to implement here shortly is to take care of the problem with style sheets. That way the end users can get the behavior they want while the technology is technically correct.

dist wrote:

On the other hand, I can appreciate your point. All I would ask is that _if_ it's decided that <enter> should do a line break instead of a new paragraph, that I have the ability to turn this off (to stay very consistent).

/absolutely/. Actually in the end it'll be 's always, just different style classes.

gogo · 2005-03-19 02:34:26

There are a few things I'll point out here.

1. There was a bug in EnterParagraphs (that I think I introduced) that made enter effectivly do a double paragraph break. This is the same bug that stopped lists from working properly. It was fixed a while back.
2. P is the preferred markup because that's the way that word processors work, hitting enter produces a new paragraph rather than a line break. The difference is that in html P creates a top/bottom margin. In word etc it doesn't (at least, in OOWriter which I'm looking at right now), you can see this in say OOWriter or Word (havn't actually looked, but I guess) by typing some text, hit enter, type some more, then right align - only one of the texts will align, because they are separate paragraphs. If you use shift-enter then both will align because they are the same paragraph.

Because of that, I think the best solution is for the developer implementing Xinha to just use CSS to style-out the margins of paragraphs defined within content that has been edited by Xinha.

I don't see how it would be a problem for the developer to do

<div class="fromxinha"><?php echo $stuffFromXinha ?></div>

and have CSS with

.fromxinha p { margin-top:0px; margin-bottom:0px }

and similarly

config.pageStyle ='p { margin-top:0px; margin-bottom:0px; }'

I don't see a reason for there to be code included into xinha to accomplish this, as long as what Xinha produces is wellformed HTML markup, the developer can use CSS to do whatever he/she wants with it.

Yermo · 2005-03-19 02:42:47

gogo wrote:

Because of that, I think the best solution is for the developer implementing Xinha to just use CSS to style-out the margins of paragraphs defined within content that has been edited by Xinha.
I don't see how it would be a problem for the developer to do
<div class="fromxinha"><?php echo $stuffFromXinha ?></div>
and have CSS with
.fromxinha p { margin-top:0px; margin-bottom:0px }
and similarly
config.pageStyle ='p { margin-top:0px; margin-bottom:0px; }'

I did not know that styles works in that heirarchical of a fashion. I had the right idea but the wrong implementation.

Once again demonstrating clearly that I've still got alot of coming up to speed to do. Before long I'll be contributing constructively. It's been quite a long time since I've had to come up to speed on something as entirely new as this stuff. Thanks again for all the tutorial information.

I'll change the ticket I created to WontFix.

adamp · 2005-03-19 18:05:22

The only problem then is that within the editor it'll appear with margins and that's where people will complain, so you'd have to edit the iframe code that Xinha uses to add the styled div and it's back to editing Xinha again.

Yermo · 2005-03-19 18:11:31

adamp wrote:

The only problem then is that within the editor it'll appear with margins and that's where people will complain, so you'd have to edit the iframe code that Xinha uses to add the styled div and it's back to editing Xinha again.

I thought that as well initially but I believe

config.pageStyle ='p { margin-top:0px; margin-bottom:0px; }'

takes care of it.

adamp · 2005-03-19 18:36:44

True

Bone612 · 2005-03-19 21:43:37

gogo wrote:

I don't see how it would be a problem for the developer to do
<div class="fromxinha"><?php echo $stuffFromXinha ?></div>
and have CSS with
.fromxinha p { margin-top:0px; margin-bottom:0px }
and similarly
config.pageStyle ='p { margin-top:0px; margin-bottom:0px; }'
I don't see a reason for there to be code included into xinha to accomplish this, as long as what Xinha produces is wellformed HTML markup, the developer can use CSS to do whatever he/she wants with it.

If that is done, then how would you get actual spacing when we do want space between paragraphs? From what I understand and have seen, if you set the margins to the to 0, then you will not get the any spacing between text when you want it. I think Yermos solution of the 2 classes is a good idea, unless there is something I am missing regarding the set to 0.

Last edited by Bone612 (2005-03-19 21:44:28)

gogo · 2005-03-19 22:44:01

Bone612 wrote:

If that is done, then how would you get actual spacing when we do want space between paragraphs? From what I understand and have seen, if you set the margins to the to 0, then you will not get the any spacing between text when you want it. I think Yermos solution of the 2 classes is a good idea, unless there is something I am missing regarding the set to 0.

Hmmm. Yes that's a good point. It may work already, but if it doesn what we would need to do is insert a non-breaking-space ( ) into blank paragraphs ( or ). That would do the job (the would create the "blank line" you are seeking).

Actually, thinking about it more, it might be better if and were converted to a in thier entirity, so as to avoid meaningless paragraphs like

ie..
Blah
 
Foo

this would also give the desired effect I think. We could also add a class to the so we can distinguish it from "explicit" breaks created by SHIFT-enter

Blah
 
Foo

so if the developer wanted to remove those breaks they could using CSS (.xinha_implicit_break { display:none} would probably do it).

I think a simple check of the DOM when hitting enter (at the very last step, after enterparagraphs etc) would do that (getElementsByTagName('p') and check for childless ones that are not currently "focused", convert to breaks and add a class).

Last edited by gogo (2005-03-19 22:54:08)

gogo · 2005-03-19 22:46:05

Could somebody try out the method I posted http://xinha.gogo.co.nz/punbb/viewtopic … d=460#p460
and let us know how well it works. Particularly with respect to doing a double-enter to get a blank line.

adamp · 2005-03-20 10:03:53

I think rather than empty paragraphs, this is where Yermo's original idea is worthwhile. Rather than a blank paragraph, you just have a different class applied to normal paragraphs and paragraphs to immitate line breaks (on shift+enter).

If people then want normal enter presses to be like line-breaks, you just swap the styles round and shift-enter becomes a traditional paragraph. It involves addin a bit of code to Xinha, but I think would be better in the long run than having empty paragraphs

gogo · 2005-03-20 11:05:34

The "natural" way to put a blank line between paragraphs is to hit enter twice, you don't want to force people to have to do shift-enter to make a blank line (which would only do a linebreak, not a new paragraph, anyway).

So if they do that (hit enter twice) then currently (with enterparagraphs, and probably in IE but I havn't checked) we get something like

<p>Foo</p>
<p></p>
<p>Bar</p>

What you (adamp) are suggesting I think is

<p class="x_normalParagraph">Foo</p>
<p class="x_linebreakParagraph">Bar</p>

and what I am suggesting is

<p>Foo</p>
<br />
<p>Bar</p>

the developer can then use CSS selectors like

 p+br { display:none; }

if they want to hide the "extra" break and use margined paragraphs; or

 p { margin-top:0px; margin-bottom:0px; }

if they want to use non margined paragraphs and use the explicit "blank line".

however I think we would need to add a class to the because I don't think that IE supports the adjacent sibling selector.

I think my way is cleaner (I like to see the HTML out of Xinha be as clean of "Xinha specific oddities" as possible).

All that said however, the use of paragraphs in this way I personally feel is wrong, and unintuitive. Even in OOWriter or Word I often mistake adjoining no-blank-line paragraphs as a single paragraph and am surprised when I change a paragraph property only to have it change only part of what I thought was a paragraph. And also, if we did this (via config value of course) and the user did enter thier data in this way, then it probably doesn't make sense for the data to be displayed with normal paragraphs any more, in which case perhaps it is better to add specific styles.

Yermo · 2005-03-20 15:48:52

gogo wrote:

All that said however, the use of paragraphs in this way I personally feel is wrong, and unintuitive. Even in OOWriter or Word I often mistake adjoining no-blank-line paragraphs as a single paragraph and am surprised when I change a paragraph property only to have it change only part of what I thought was a paragraph. And also, if we did this (via config value of course) and the user did enter thier data in this way, then it probably doesn't make sense for the data to be displayed with normal paragraphs any more, in which case perhaps it is better to add specific styles.

A very good point. Paragraph tags are really supposed to be contiguous paragraphs, structurally speaking, right? So what you're saying is with margin 0px set we might have a

<p>this is a</p><p>test line</p>

which would appear as

this is a
test line

One would like this to behave as a single paragraph so we can set properties on it.

So would the correct thing be:?

<p>this is a<br/>test line</p>

This would imply that we're back to putting in 's on single Enter key presses and in addition swapping in normal 's on double Enter presses.

Thinking as a "normal user" When I'm typing and I hit enter I want it to go to a newline; I don't want it to be a new paragraph. However, if I hit enter twice then I would like it to be a separate paragraph.

It seems that HTML needs to have a new kind of tag that conceptually represents a soft break or soft line of text.

I wonder if maybe the right answer wouldn't be something like:

<p><span class="softline">this is a </span><span class="softline">test line</span></p>

and do away with the use of 's altogether.

This introduces the concept of the soft break without the use of br's. It allows us to set properties on the paragraph and on individual lines and dictate the appearance of everything from the stylesheet.

It does add a little ugliness because it forces the introduction of a class; there may be no good way around it since looks like we've identified a limitation in the design of HTML.

What do you think?

adamp · 2005-03-20 16:27:38

If you were to do something like that it'd probably need to be divs rather than spans as spans are not block-level elements and would appear on the same 'line' as each other unless set to display:block

I'll think about the rest of what's been said later as my brain's not up to it at the moment

Yermo · 2005-03-20 16:38:17

adamp wrote:

If you were to do something like that it'd probably need to be divs rather than spans as spans are not block-level elements and would appear on the same 'line' as each other unless set to display:block

yea, so you have the flexibility to make lines "appear" as part of the paragraph, etc. <div>'s imply the newline presentation, don't they?

I don't know if the idea is a good one, it just does seem to address the problems we're having in that we don't have a line-level-element. I don't know enough about styles at the moment to know if spans or divs are the right thing.

It just seems that conceptually we're talking about a difference in presentation needs for a "line" vs. a "paragraph". HTML doesn't have a "line" concept ... but a or a <div> might do the trick. This will also allow us to programmatically crawl through the hierarchy and know whether or not we're looking at a paragraph or a line. The beginning and end points are then clearly defined (as opposed to having multi-meaning tags or line breaks).

Crawl back to beginning of paragraph: look for an enclosing >

Crawl back to beginning of line: look for enclosing (or <div> .. whichever is the better solution).

It does get a little ugly because we'll have to define some styles to use .. but this should solve alot of problems. The benefits may outweigh the downsides. It'll also make the EnterParagraphs plugin a bit easier.

gogo · 2005-03-21 00:29:05

Yermo wrote:

this is atest line
which would appear as
this is a
test line
One would like this to behave as a single paragraph so we can set properties on it.

Well, you'd think that, but if we are modelling things on the way that Word et al work, that's exactly what they do (I think, at least in the OOWriter instance I'm looking at now). You can see this simply by entering

fooo<hit enter>
bar

place the cursor in fooo somewhere and hit right align, you'll see that only that line aligns, because they are distinct paragraphs. If on the other hand you do

fooo<hit shift-enter>
bar

and cursor into fooo and right align, you'll see both lines align because effectively they are the same paragraph. It's plain crazy if you ask me.

<p><span class="softline">this is a </span><span class="softline">test line</span></p>

What do you think?

Mmm, I really don't like that at all. But as long as it's a plugin that does it I don't give a crap

Actually, can somebody who has MS Word handy confirm that it behaves in the same way?

gogo · 2005-03-21 00:51:30

The other way forward, is to make enter do a , and detect two enters in a row in which case it becomes a . But I have the distinct impression that would be a really difficult code.

You also need to be aware of <li> (maybe others?) because in that case you want to create a new parapraph (which happens to be an <li>) on the first enter.

Yermo · 2005-03-21 02:22:07

gogo wrote:

It's plain crazy if you ask me.
this is a test line
What do you think?
Mmm, I really don't like that at all. But as long as it's a plugin that does it I don't give a crap

Well, you've got far more experience with this kind of thing than I do so I'll defer to your judgement. For my part I just want to be able to give my users the ENTER works like functionality, but have it be "correct".

Unfortunately the EnterParagraphs plugin is seriously broken so we've got to decide on something to do. Using the built-in version also has it's problems (although seemingly less broken than enterparagraphs).

gogo wrote:

Actually, can somebody who has MS Word handy confirm that it behaves in the same way?

Word works exactly the same way. Put an ENTER at the end of the line and it looks like a paragraph. (i.e. each line move separately if you click in it and select center).

Do a SHIFT_ENTER at the end of the line then both lines move.

So of the various designs we've discussed which one should we implement?

gogo · 2005-03-21 05:36:05

Yermo wrote:

Unfortunately the EnterParagraphs plugin is seriously broken so we've got to decide on something to do. Using the built-in version also has it's problems (although seemingly less broken than enterparagraphs).

In what way is EP broken? It seems to work ok for me (after the patch a while back to fix the double-paragraph problem).

gogo wrote:
Actually, can somebody who has MS Word handy confirm that it behaves in the same way?
Word works exactly the same way. Put an ENTER at the end of the line and it looks like a paragraph. (i.e. each line move separately if you click in it and select center).
Do a SHIFT_ENTER at the end of the line then both lines move.

Yea, I was pretty sure that was how it worked. So effectily, in word we get Foo| when hitting enter and Foo | when hiting shift-enter, but it doesn't display breaks between the paragraphs. I wonder what the internal representation of enter-enter is, Foo| ? It think it might be, because in a list if you do enter-enter you'll get two list items (ie two paras, an empty one and the current one).

So of the various designs we've discussed which one should we implement?

Well. I don't know. Which do you want to implement?

Dong the => (or - a whitespace paragraph rather than a null one) would be easiest, a simple dom search when you hit enter. Doing => would be hard to get right I think. Adding spans all over the place is just freakin ugly IMHO, but again, I just wouldn't use the plugin so doesn't matter to me. Adding classes or styles is similarly ugly.

Classes however may be the way..

Hit enter once and we get
Foo
|

hit again and it becomes
Foo
|

so hitting enter in the paragraph would have to detect if the last keypress was also enter,
yes: grab the previous sibling paragraph, remove the class, cancel the enter
no: set the class on the current paragraph, allow the enter to continue (return true)

I think this would be relatively easy.

adamp · 2005-03-21 06:06:41

I have to say imho going back to the original plan (and your last suggested implementation goog) still looks the cleanest solution to the problem. Sometimes the simplest solution is the best

Yermo · 2005-03-21 13:13:31

gogo wrote:

Yermo wrote:
Unfortunately the EnterParagraphs plugin is seriously broken so we've got to decide on something to do. Using the built-in version also has it's problems (although seemingly less broken than enterparagraphs).
In what way is EP broken? It seems to work ok for me (after the patch a while back to fix the double-paragraph problem).

See bug 78.

Clear the editor. Now enter

test

highlight test.

Select link

enter some link doesn't matter what.

click at end of test.

press enter.

get nasty exception on line 256

next problem:

do a bulleted list after the link. hit enter a few times.
now you're stuck.

look at the source. You'll see alot of bank links.

The end case is not being handled correctly. At that line basically holdEnd ends up not being an object. It's false (boolean). Somehow the recursion through foreachnodeunder is not doing the right thing but I haven't had a chance to crawl through it.

Also, try hitting ENTER ENTER in a blank window. You'll get
<body></body>

gogo wrote:

Yermo wrote:
So of the various designs we've discussed which one should we implement?
Well. I don't know. Which do you want to implement?

I just haven't done alot of work in this space so I don't know which would be the best approach. I'd like the one that's the easiest to implement the provides the most "intuitively" correct behavior to both developer and end-user.

gogo wrote:

Adding classes or styles is similarly ugly.
Classes however may be the way..
Hit enter once and we get
Foo
|
hit again and it becomes
Foo
|
so hitting enter in the paragraph would have to detect if the last keypress was also enter,
yes: grab the previous sibling paragraph, remove the class, cancel the enter
no: set the class on the current paragraph, allow the enter to continue (return true)
I think this would be relatively easy.

You'd also have to handle the backspace case. If, in Xinha, you do an ENTER ENTER then a backspace it reduces back to .

Yermo · 2005-03-21 13:55:34

willeffects wrote:

I would have to agree with yermo. In our case the whole purpose of using a wysiwyg editor is based on the fact that our users dont understand HTML nor do they understand the difference between a P or BR. Therefor if they hit enter they expect it to work like microsoft word (which would be a BR for us).
So I agree that there should at least be an option or a way to completely switch this.
Will

What we're focusing on now is a way to get the HTML to be "correct" (i.e. blah ) but have the appearance to the user be what they expect. i.e. that it looks like a standard line break.
An attempt at a "best of both worlds".

willeffects · 2005-03-21 14:54:26

Fantastic. Sorry for the misunderstanding.

If you take a look at http://www.alfmiti.net/demo/tinyRTE_demo.htm , it appears he uses tags on two spaces and on one. This seems to be the way I would expect it to work from both a html and end user pov. Not sure if thats any help, but that editor I think is a good model to look at for use -- It has a lot of features we'd like to see in xinha (though doesnt have xinha type of community/support which is why we are here!).

Will

Last edited by willeffects (2005-03-21 15:03:23)

franzo · 2005-04-24 18:17:05

Has there been any progress on this issue? Here's a workaround for those who need it.

I find that if I set

p {margin: 0pt}

then the editor behaves like MS Word, but when I reload with the produced html (or use the output elsewhere with the same p style), blank lines are removed.

However, if I take the produced html and replace all occurences of with before re-use it works a treat.

Yermo · 2005-04-24 18:37:52

franzo wrote:

Has there been any progress on this issue? Here's a workaround for those who need it.
I find that if I set
p {margin: 0pt}
then the editor behaves like MS Word, but when I reload with the produced html (or use the output elsewhere with the same p style), blank lines are removed.
However, if I take the produced html and replace all occurences of with before re-use it works a treat.

I'm getting there.

On my todo list:

1. unify client to server communications (next on list of todos)
2. fix up Linker plugin to go through a central URL rewriter to take care of MSIE vs FireFox issues
3. fix up EnterParagraphs. (big job) which will take care of this issue.

There's still alot of work to be done I'm afraid. I'm guessing another couple of weeks at least.

niko · 2005-04-25 03:43:52

point 2 +3 are very, very important for the success of xinha imho! (and very difficult too...)

thanks for your work

Xinha Discussion Forum

Announcement

#26 2005-03-18 21:25:36

Re: Spacing Problem

#27 2005-03-19 02:34:26

Re: Spacing Problem

#28 2005-03-19 02:42:47

Re: Spacing Problem

#29 2005-03-19 18:05:22

Re: Spacing Problem

#30 2005-03-19 18:11:31

Re: Spacing Problem

#31 2005-03-19 18:36:44

Re: Spacing Problem

#32 2005-03-19 21:43:37

Re: Spacing Problem

#33 2005-03-19 22:44:01

Re: Spacing Problem

#34 2005-03-19 22:46:05

Re: Spacing Problem

#35 2005-03-20 10:03:53

Re: Spacing Problem

#36 2005-03-20 11:05:34

Re: Spacing Problem

#37 2005-03-20 15:48:52

Re: Spacing Problem

#38 2005-03-20 16:27:38

Re: Spacing Problem

#39 2005-03-20 16:38:17

Re: Spacing Problem

#40 2005-03-21 00:29:05

Re: Spacing Problem

#41 2005-03-21 00:51:30

Re: Spacing Problem

#42 2005-03-21 02:22:07

Re: Spacing Problem

#43 2005-03-21 05:36:05

Re: Spacing Problem

#44 2005-03-21 06:06:41

Re: Spacing Problem

#45 2005-03-21 13:13:31

Re: Spacing Problem

#46 2005-03-21 13:55:34

Re: Spacing Problem

#47 2005-03-21 14:54:26

Re: Spacing Problem

#48 2005-04-24 18:17:05

Re: Spacing Problem

#49 2005-04-24 18:37:52

Re: Spacing Problem

#50 2005-04-25 03:43:52

Re: Spacing Problem

Board footer