Spacing Problem

Bone612 · 2005-03-14 16:19:21

I was wondering if anyone figured out a solution to the spacing problem. I know I need to put requests into a ticket, but I thought I would write to see if anyone has the solution. I have tried replacing the with a on the server side but that does not work for multiple reasons. If anyone has a way to fix the issue of rending the tag every time an enter button is clicked, Id appreciate the help.

Yermo · 2005-03-15 01:58:39

Bone612 wrote:

I was wondering if anyone figured out a solution to the spacing problem. I know I need to put requests into a ticket, but I thought I would write to see if anyone has the solution. I have tried replacing the with a on the server side but that does not work for multiple reasons. If anyone has a way to fix the issue of rending the tag every time an enter button is clicked, Id appreciate the help.

Check htmlarea.js around line 197:

this.mozParaHandler = 'built-in'

You should probably set it on the calling page which, in the full-example_body.html file in STEP 2 should be

xinha_config.mozParaHandler = 'built-in';

But unfortunately that is not working for me. Haven't tracked down why yet, so I just changed htmlarea.js for the time being.

I dont' yet understand the full side-effects of using 's. The "correct" thing is to use the paragraph tags (and possibly a stylesheet entry?) but users want the newline behavior the expect.

adamp · 2005-03-15 08:06:13

If you want to keep the tags but have it look like line breaks, just set a style

p { margin:0; }

for the editor pane (and the page/area that's then going to display the text)

Bone612 · 2005-03-15 09:20:39

adamp wrote:

If you want to keep the tags but have it look like line breaks, just set a style
p { margin:0; }
for the editor pane (and the page/area that's then going to display the text)

How do you configure the editor to not have a margin for the tag. Also, doesnt this eleminate spacing all together?

adamp · 2005-03-15 09:30:47

Paragraphs have margins above and below that create the separation you want rid of, so setting the margin to 0 makes them look like they've just been separated by tags. If you want to keep a certain amount of spacing, you can always set margin-top and/or margin-bottom to something greater than 0 for p elements.

If you're using the Stylist plugin, you can set the style by including a .css file with the style I gave earlier (as well as any other styling you want).

Alternatively, you can try editing the default CSS as below:

config.pageStyle = 'p { margin:0; } ';

and then applying config to your HTMLArea when you generate it. I'm not sure if the above still works in Xinha, but it did with HTMLArea.
Hope that helps

niko · 2005-03-15 09:39:20

to remove the margin for p-tags you need this:

xinha_config.pageStyle = "p { margin:0; }";

(+ like adamp and the page/area that's then going to display the text)

Bone612 · 2005-03-15 10:11:13

Yermo wrote:

Check htmlarea.js around line 197:
this.mozParaHandler = 'built-in'

Does this not work in IE. It works nicely in Netscape and Firefox

adamp · 2005-03-15 10:14:59

It won't work in IE because technically the correct way is for it to use tags, which IE uses. Firefox by default uses tags, which is fixed by that option, though can be turned back off again.

Rather than writing reverse code to make IE use br tags or playing with the styling of paragraphs, it may be easier just to put a note above the editor frame that shift+enter will create a line break.

dhscompguy · 2005-03-15 20:40:43

We should really do away with linebreaks, though.

It can be argued that a linebreak has some semantic value (i.e., it further defines what is being written), but most authors use it in an entirely subjective fashion. They add breaks according to what feels right at the time. Usually they will do this based on the current display, which we as developers know changes drastically with different operating systems, browsers, font sizes, and screen resolutions.

Back in the days of the typewriter, authors had to backup one space and strike a key in order to bold a particular letter. This of course was a very time consuming process. To make things easier, the underscore was invented. This allowed certain words to be emphasized with greater ease. However, this convention is still being used today, despite the fact that there is no reason for it.

Underscoring is UGLY!

Like the underscore, the linebreak is a holdover from the days of the typewriter. Using that technology, which is restricted to output on paper, it makes good sense to speak of linebreaks, since the author is working within a well-defined set of constraints, typically 8 x 11. They can see all of the important aspects of the design right there in front of them.

When we're working with a WYSIWYG editor, we usually assume the same thing, even though publishing electronically is something quite different indeed. It's not well-defined. There is no such thing as a "page." These are old constructs... residual mind-garbage. We should dump that mode of backwards thinking.

We should simply tell users that this is a new medium and it doesn't work the same way as a typewriter, rather than caving into the caveman-demands of "ME WANT LINEBREAK! OOGA BOOGA!"

Yermo · 2005-03-15 22:32:20

niko wrote:

xinha_config.pageStyle = "p { margin:0; }";

The problem here is one of configuration because you're got to remember to do this for tags in the generated HTML where you're using it.

What would be cool is to be able to set the style of tags that the editor outputs automatically .. both in the iframe and in the generated text; so you don't have to do a global tag margin style.

What if we did a

config.EnterParagraphs.pStyle = "margin: 0;";

or some such so we could change the behavior of the tag from the configuration?

Yermo · 2005-03-15 22:40:02

dhscompguy wrote:

When we're working with a WYSIWYG editor, we usually assume the same thing, even though publishing electronically is something quite different indeed. It's not well-defined. There is no such thing as a "page." These are old constructs... residual mind-garbage. We should dump that mode of backwards thinking.
We should simply tell users that this is a new medium and it doesn't work the same way as a typewriter, rather than caving into the caveman-demands of "ME WANT LINEBREAK! OOGA BOOGA!"

You have to give customers what they want. I agree that doing away with linebreaks is probably the technically correct thing to do, but it is nevertheless not what customers want. A customer wants to hit "ENTER" and have it act like a word processor. The people who actually use Xinha in real life applications typically have no markup background whatsoever ... for instance my users typically have a little word processing experience and little else. I receive alot of complaints and questions about the "double newline problem".

niko · 2005-03-16 03:05:05

Yermo wrote:

What if we did a
config.EnterParagraphs.pStyle = "margin: 0;";
or some such so we could change the behavior of the tag from the configuration?

i don't see the difference, you have to remember again to do this for tags in the generated HTML where you're using it!

adamp · 2005-03-16 04:51:55

I think Yermo is suggesting that by adding that new value it would then insert any new paragraphs in Xinha as

<p style="[style you entered here]">...</p>

so the above would become

<p style="margin:0;">...</p>

It would of course savetime for the developer as you don't have to set a style in two places, but it's not so good for the maintenance of the site. The point of CSS is to separate style and content, which this doesn't do.

We'll all have to make some trade-off with this - give in and let them use line breaks; set inline styles to hide the fact it's a tag but lose separation of style and content; set styles externally but spend the little bit of extra time to do it in two places. I guess it's down to each webmaster's needs and choice

niko · 2005-03-16 08:40:03

i really don't have a problem with defining a p { margin: 0; }
i do even use the same css-file for Xinha and my frontend...

imho is ugly

but if others would prefer it....

adamp · 2005-03-16 08:49:13

I agree is ugly and I'd personally use the style sheet definition if people get that upset at the use of paragraphs. I was just listing some of the options others may want to use.

dhscompguy · 2005-03-16 08:59:58

You have to give customers what they want.

This is true in some cases, where it is not in opposition to an important design goal.

Educating them is another option (and better imho). It really doesn't take that much effort.

Anyway, as with all things, to each their own.

Yermo · 2005-03-16 14:59:39

dhscompguy wrote:

You have to give customers what they want.
This is true in some cases, where it is not in opposition to an important design goal.
Educating them is another option (and better imho). It really doesn't take that much effort.

When there are enough 0's involved, customers no longer want to be educated. They just want it to work the way they are used to. All a matter of context I guess. Xinha needs to be able to accomodate both contexts.

In that vein, I was thinking tags generated by EnterParagraphs should optionally include a class name, which we can then define in the calling page. This way you don't have to modify the style of tags globally, which might break your design. In addition, it lets you have technically correct html while giving users the appearance they are used to.

I've got it mostly working in a hardcoded test case here ...

Last edited by Yermo (2005-03-16 15:00:45)

Yermo · 2005-03-16 15:06:44

adamp wrote:

I think Yermo is suggesting that by adding that new value it would then insert any new paragraphs in Xinha as
...
so the above would become
...
It would of course savetime for the developer as you don't have to set a style in two places, but it's not so good for the maintenance of the site. The point of CSS is to separate style and content, which this doesn't do.

What I'm working on now instead is changing it to:

<p class="someClass">...</p>

and then defining it in the stylesheet. The stylesheet entry needs to be loaded in two places, once in the editor and then on the page where the content is being used. But this seems to give us the best of both worlds.

I have it mostly working in a test case here ...

Do you see any problems with this approach? (I'm still new at all this DOM javascript stuff .. the biggest problem I'm having coming up to speed is seeing all the contexts and consequences to given choices ...)

Bone612 · 2005-03-16 15:41:32

I am just wondering how you are going to handle the 2 cases (when to insert that class and when not to insert that class). Is the [shift]+[enter] going to insert the class while just hitting [enter] does not?

I most definately agree that we need to give the customer what they want. With that said, im wondering if there can be a config option to alter the functionality of the [enter] vs the [shift]+[enter]. As previously mentioned, most people are used to word processor behavior and that is what they would like this to be. Therefore, I think it would be easier on my clients to hit [enter] and get the or the new proposed and then have them get the unstyled tag with a [shift]+[enter].

Just a thought, not sure if anyone is in agreement or even if its a good idea.

Yermo · 2005-03-16 15:47:46

Bone612 wrote:

I am just wondering how you are going to handle the 2 cases (when to insert that class and when not to insert that class). Is the [shift]+[enter] going to insert the class while just hitting [enter]does not?

SHIFT-ENTER inserts a break, at least in FireFox. I believe it works the same way in MSIE. If it doesn't, it's easy enough to define two classes. (i.e. ENTER => SHIFT-ENTER => )

Bone612 wrote:

I most definately agree that we need to give the customer what they want. With that said, im wondering if there can be a config option to alter the functionality of the [enter] vs the [shift]+[enter]. As previously mentioned, most people are used to word processor behavior and that is what they would like this to be. Therefore, I think it would be easier on my clients to hit [enter] and get the or the new proposed and then have them get the unstyled tag with a [shift]+[enter].
Just a thought, not sure if anyone is in agreement or even if its a good idea.

The core of the problem seems to be that MSIE by default inserts tags. For reasons I don't understand, inserting tags is the "correct" thing to do; maybe because it's more XMLish than the BR tags.

I don't know if anything else (other plugins) breaks if you have tags by default on ENTER.

Originally I wanted to switch the behavior to ENTER == "br", but it seems to me that optionally including a class parameter might be a better solution. That way you can have "correct" HTML while still having the presentation be what users expect.

What do you think?

Bone612 · 2005-03-16 15:59:53

If it doesn't, it's easy enough to define two classes. (i.e. ENTER => SHIFT-ENTER => )

If you are going to define 2 classes that can be configured to the users liking, I think that would be great. So I guess I am wondering if what you are suggesting is the following:

User 1 wants enter== and shit+enter== but user 2 wants enter== and shit+enter==

Is that along the ideas of your suggestion. Basically, we have the 2 classes and we can set them however we want to enter and shit+enter? This would allow us to give the like behavior on the enter, and the regular behavior on the shift+enter or visa versa.

Yermo · 2005-03-16 16:12:51

Bone612 wrote:

If you are going to define 2 classes that can be configured to the users liking, I think that would be great. So I guess I am wondering if what you are suggesting is the following:
User 1 wants enter== and shit+enter== but user 2 wants enter== and shit+enter==
Is that along the ideas of your suggestion. Basically, we have the 2 classes and we can set them however we want to enter and shit+enter? This would allow us to give the like behavior on the enter, and the regular behavior on the shift+enter or visa versa.

As I am very fond of saying, Ayup.

I'm imagining two /optional/ config values for the EnterParagraphs plugins

xinha_config.EnterParagraphs.enterStyle = "somestylename";
xinha_config.EnterParagraphs.shiftEnterStyle = "someotherstyle";

Since the default behavior for SHIFT_ENTER is right now it would require some hacking in htmlarea.js ... so for a first pass I'll probably only support the first option. Might have to get some input from gogo on what the best way to do this would be and whether or not changing the behavior of SHIFT-ENTER to a would break anything else.

adamp · 2005-03-17 05:44:38

I'd say the class definition is going to be the best way to go.

The reason s are 'bad' (although not that bad) XHTML is that the HTML should define structure only, while CSS defines the formatting/presentation. Line breaks are a presentational construct done for effect rather than to start a new body of text, so they're not wholly structural and therefore not 'good' XHTML.

Hopefully gogo will include this as a default part of the Xinha code as it's not worth a plug-in and changing htmlarea.js isn't too good an idea for being able to update later.

Yermo · 2005-03-17 14:37:17

adamp wrote:

I'd say the class definition is going to be the best way to go.
The reason s are 'bad' (although not that bad) XHTML is that the HTML should define structure only, while CSS defines the formatting/presentation. Line breaks are a presentational construct done for effect rather than to start a new body of text, so they're not wholly structural and therefore not 'good' XHTML.
Hopefully gogo will include this as a default part of the Xinha code as it's not worth a plug-in and changing htmlarea.js isn't too good an idea for being able to update later.

Gotcha. Makes sense. As far as the code goes Xinha intercepts ENTER keypresses in firefox .. so in order for this to work it would have to intercept both enter and shift-enter on both browsers. The EnterParagraphs plugins, which is already automatically loaded, is where the actual work of adding the class attributes goes.

I've got a test case working but still have to track down a few things.

dlst · 2005-03-18 20:14:22

Yermo wrote:

dhscompguy wrote:
When we're working with a WYSIWYG editor, we usually assume the same thing, even though publishing electronically is something quite different indeed. It's not well-defined. There is no such thing as a "page." These are old constructs... residual mind-garbage. We should dump that mode of backwards thinking.
We should simply tell users that this is a new medium and it doesn't work the same way as a typewriter, rather than caving into the caveman-demands of "ME WANT LINEBREAK! OOGA BOOGA!"
You have to give customers what they want. I agree that doing away with linebreaks is probably the technically correct thing to do, but it is nevertheless not what customers want. A customer wants to hit "ENTER" and have it act like a word processor. The people who actually use Xinha in real life applications typically have no markup background whatsoever ... for instance my users typically have a little word processing experience and little else. I receive alot of complaints and questions about the "double newline problem".

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.

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).

Xinha Discussion Forum

Announcement

#1 2005-03-14 16:19:21

Spacing Problem

#2 2005-03-15 01:58:39

Re: Spacing Problem

#3 2005-03-15 08:06:13

Re: Spacing Problem

#4 2005-03-15 09:20:39

Re: Spacing Problem

#5 2005-03-15 09:30:47

Re: Spacing Problem

#6 2005-03-15 09:39:20

Re: Spacing Problem

#7 2005-03-15 10:11:13

Re: Spacing Problem

#8 2005-03-15 10:14:59

Re: Spacing Problem

#9 2005-03-15 20:40:43

Re: Spacing Problem

#10 2005-03-15 22:32:20

Re: Spacing Problem

#11 2005-03-15 22:40:02

Re: Spacing Problem

#12 2005-03-16 03:05:05

Re: Spacing Problem

#13 2005-03-16 04:51:55

Re: Spacing Problem

#14 2005-03-16 08:40:03

Re: Spacing Problem

#15 2005-03-16 08:49:13

Re: Spacing Problem

#16 2005-03-16 08:59:58

Re: Spacing Problem

#17 2005-03-16 14:59:39

Re: Spacing Problem

#18 2005-03-16 15:06:44

Re: Spacing Problem

#19 2005-03-16 15:41:32

Re: Spacing Problem

#20 2005-03-16 15:47:46

Re: Spacing Problem

#21 2005-03-16 15:59:53

Re: Spacing Problem

#22 2005-03-16 16:12:51

Re: Spacing Problem

#23 2005-03-17 05:44:38

Re: Spacing Problem

#24 2005-03-17 14:37:17

Re: Spacing Problem

#25 2005-03-18 20:14:22

Re: Spacing Problem

Board footer