Oops -- I thought I had an alias for mozilla-editor, but this ended
up going to [EMAIL PROTECTED] Here's the message:
From: Akkana <[EMAIL PROTECTED]>
To: Toastie <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]
Date: Mon, 24 Sep 2001 16:03:41 -0700
User-Agent: Mutt/1.2.5i
Subject: Re: HTML in Mozilla for X11 clipboard
Toastie writes:
> Currently, Mozilla exports the following "data formats" for a selection
> from a web page (in UTF16 encoding):
> text/html - with the contents of the selection
> text/_moz_htmlcontext - with surrounding of the selection (the need for
> it is unclear to me)
> text/_moz_htmlinfo - with some two integers who always seem to be 0,0
> (I'd be glad to hear an explanation of those values)
The other two are context information used by the editor for inserting
html fragments into an html document. Joe Francis is the expert on
the details of what they mean; I've cc'ed mozilla-editor since he isn't
likely to be on the unix or gtk groups.
> Since then, I implemented exporting of "text/html" format in KTHML
> (Konqueror's HTML engine) and noticed Mozilla's implementation got a
> thing which my simple HTML conversion of a DOM Range won't do;
> a selection such as "<b>one [two] three</b>" (where "two" is selected)
> in Mozilla would result in the clipboard containing "<b>two</b>" instead
> of just "two". That's a nice feature, especially for word processors
> (e.g. Composer) where the person expects to copy the text along with the
> format.
Right. The selection has to be smart about when to include parent
tags and when not to; the htmlcontext flavor in the selection is
there to provide the context information for the times when it's needed.
> I assume Mozilla implements this by keeping a list of formatting HTML
> tags (<b>, <i>, <font color=...> etc.) and traversing the HTML tree down
> from the selection, collecting those tags on the way.
I believe that's correct.
> I want to extend that feature. Instead of adding surrounding formatting
> tags to the HTML put on the clipboard, I propose adding a clipboard
> format called "text/css", which'll contain a getComputedStyle dump of
> the first textNode of the selections' DOM range. That way, we could pass
> on the actual style of the text, however complicated it might be.
We struggled with the question of what to do about CSS in selections.
If you don't include the css information when you paste, then you might
paste something that looks nothing like what the user selected. OTOH,
if you do include it, then you send a document that looks to some other
user different from the part of the document from which it was copied
(if a different style sheet is being used).
Making the CSS information available as a clipboard flavor, though,
sounds quite reasonable; then the pasting client can choose what it
wants to do, depending on the intended audience. I don't know if we'd
usually want our editor to apply the CSS to pasted text, but having it
available could be very useful.
> 1. Changing of the clipboard encoding. That is discussed in bug 44496.
> Since declaring formats in the X clipboard doesn't imply actual transfer
> (or even generation) of the data, we can easily offer multiple encodings
> without a performance penalty. UTF-16 makes interoperatibility a bit
> complicated, since it's contains NULLs and is not the usual encoding
> you'd expect to find on a clipboard. I propose that the clipboard would
> contain an:
> a) "text/html;charset=UTF-8" type in UTF-8 encoding.
> b) "text/html" type with all non-Latin1 values encoded as Unicode
I know Pavlov's been thinking more about issues like this, and
probably knows more about why we should or should not do this.
Mozilla does everything as ucs-2 (is utf-16 the same thing?)
internally, so we'd have to translate back to utf8 in order to
offer that format, but we probably should.
It would be so much easier if the X selection mechanism let us
separate encoding from mime type!
> 2. Base URI for objects. For objects embedded on the page (<IMG>,
Yes, I need this for some other bugs I've been working on as well
(bug 32768, which covers the same questions you ask about whether
pasted links should be relative or absolute), and there seems to be
no way to do it without adding another data flavor. I wish it
could be part of the context flavor.
> 3. An additional idea I had is a "text/html;version=3.0" type, which'll
> contain the closest possible approximation of the style by appending
> HTML formatting tags just like current Mozilla does. This format will be
> mostly for useful for things like GTKHTML, which have a limited HTML
> support, obviously without CSS.
One thing you should keep in mind: Mozilla is cross platform, not
just Unix; and some other platforms do copy all flavors into their
clipboards rather than delaying the copy until someone requests that
flavor. So adding several flavors which involve several different
copies of the whole page has to address this issue.
> On my side, I'll try to implement this into Mozilla (unless any of you
> more familiar with the beast will step forward) and I'll make sure KHTML
Great! It would be great to have help on the X selection mechanism/
mozilla clipboard interaction. I don't know as much as either Pavlov
or Joe about the current state of affairs, but I'll certainly help
where I can. And if we can come up with a model that works for
all apps, so we can have good html copy/paste between mozilla and
kde apps, that's a big improvement for everybody.
...Akkana
----- End forwarded message -----
