[Mozile] White space handling

[James A. Overton]

On 2006-Jun-07, at 8:30 AM, leif halvard silli wrote:
> Just now it struck me that perhaps it is not strictly necessary to  
> enable a special key combination for entering no break space,  
> because the normal key combination (ALT + SPACE on my keyboard)  
> already works in Mozile!

I hadn't noticed this either, but you're quite right. On a Mac (for  
those who don't know) Alt + [any key] will insert a special  
character, and Mozile is designed to simply accept them like any  
other character.
	On Windows and Linux (which I don't know as well) I've made Mozile  
treat the Alt key as a command key, so commands like Alt+D won't  
insert a character (Mozile will ignore the command and the address  
bar will be selected). I think this breaks the Windows alt-key  
special characters system. Eventually I'll copy the special  
characters dialog that Max made into Mozile 0.8.
	I think that using shift+space to add a non-breaking space still  
makes sense, especially if that's what MS Word and OpenOffice do. I'd  
appreciate Windows- and Linux-specific advice, if anyone has other  
good ideas.

> So may be we just have a educational problem.

That will certainly be part of it.

> Funny you did not know how to enter the No break space in a regular  
> editor/word processor ... The word processor Mellel (for Mac) seems  
> to have taken this problem into account. It offers 9 different  
> space characters from a submenu of the Insert menu. Which seems  
> like a smart thing to do. Perhaps Mozile also could have the same  
> thing. Instead of (or in addtion to) a special cross-platform shift 
> +space. (Mellel also use have the shift+space for the no break  
> space, btw, even if Apple's TextEdit doesn't.)

 From what I can tell, only normal and non-breaking spaces are widely  
supported. I found this great page on Unicode spaces, <http:// 
www.cs.tut.fi/~jkorpela/chars/spaces.html> and it renders pretty well  
in Firefox. But most of it didn't render correctly for me in Safari  
or IE. The problem is mostly font support for specific characters. So  
our options will be limited by browsers and fonts.

...

>> The general problem with using CSS "white-space: pre" is that it  
>> will show both spaces and newlines. We probably want newlines in  
>> the source to be rendered as spaces, rather than actual newlines.
>
> Yes, if that can be done. (I think it would make sence if CSS had a  
> function that let us govern _which_ of the white-space characters  
> should be collapsed.)
>
> I was more thinking about whether "white-space:pre" would have any  
> effect on the _editing_. Will the (hard-)return key insert a new  
> paragraph when inside a element with "white-space:pre"? Or will it  
> return a new line-break in the source (not a BR, but a "physica"  
> line break.)
>
> But perhaps that problem is allready solved ...

Mozile handles DOM events as they pass through the documentElement.  
It sorts them by properties like the event type, modifier keys, and  
keyCodes/charCodes. Key codes below 32 (which includes tabs, arrow  
keys, and the enter key) are not captured by the insertText command,  
so no characters are inserted.
  	Events can be captured by other commands, and the enter key is  
captured by the splitNodes command. Right now the split nodes command  
looks for a block-level element (div, p, li, etc.) and clones it,  
inserts the clone after the original, then splits all the nodes  
inside the block at the cursor position and moves all the nodes after  
the cursor into the clone. It should probably just insert a newline  
when inside a "white-space: pre" section.
	But the short answer is that we have total control over which events  
trigger which commands. The trick is deciding what the proper  
behaviour should be.
	Thanks for the ideas,

James