When dragging a linked text, the following attribute is appended to the <a> element: --- style="color: rgb(0, 0, 255) -webkit-text-decorations-in-effect: underline; " --- 1. Open the FCKeditor test page in the provided URL; 2. Select the text "using FCKeditor."; 3. Drag it to somewhere else in the text; 4. Switch to Source view to see the results.
The styles don't effect correctness in the editor. They could conceivably effect correctness in an editor that let the user adjust the default link style.
Update on this: There was some changes on the resulting style addition. The nightly and Safari 3 Beta now adds the following to the <a>: --- style="color: rgb(0, 0, 255) !important; " --- It doesn't happen to Safari 3 for Windows, so it seams to be OS dependent.
More info... it happens only when selecting "text + link", like "You are using <a href="http://www.fckeditor.net">FCKeditor</a>.". If you double click the link, it is dragged as an object instead, and no styles are appended to it.
(In reply to comment #1) > The styles don't effect correctness in the editor. They could conceivably > effect correctness in an editor that let the user adjust the default link > style. It is not a matter of presentation inside the editor. Actually nobody would be using an editor to read things. The problem here Justin is that the editor is used to produce content, which will be used somewhere else. Then, we have two issues: - Developers, which will be unhappy to have the editor producing unneeded HTML. They get really disappointed with such things; - Incorrect link styles when placing the contents inside a page (the common case). The page could (and usually) have styles completely different from those used inside the editor. Also, the same content can be targeted to different pages or even sites, with style completely different.
I agree this is a bug, not sure why the current behavior exists as it does. Probably to maintain good color fidelity when copying/pasting between a site and a mail message for instance. We'd need to understand why the current behavior exists before we could come up with a solution.
(In reply to comment #5) > I agree this is a bug, not sure why the current behavior exists as it does. > Probably to maintain good color fidelity when copying/pasting between a site > and a mail message for instance. That's the conclusion I had too. But it assumes that the content will always be used inside a non-styled page. There are two things that could be considered here to solve it: - Copy the link as is if the source is the same document as the target. I mean, if I copy and paste a link inside the same FCKeditor document, I should not have changes to it. - Implement a way to configure it. Maybe something similar to Firefox's execCommand('styleWithCSS',true|false,null). In this way we instruct WebKit on whether maintaining the link color on pasting, or leaving it intact. Maybe a generic thing like execCommand('autoCorrect',true|false,null) would be even better, if WebKit is doing also other things automatically, not limited to the link color thing.
I believe this bug has been fixed now because of my fixes in ApplyStyleCommand and various other parts of editing code.
Closing the bug because the described behavior is no longer present on TOT.