Bug 12248 - Apple-style-span class seems unnecessary
Summary: Apple-style-span class seems unnecessary
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Ryosuke Niwa
URL: http://www.fckeditor.net/nightly/brow...
Keywords: InRadar
: 18423 (view as bug list)
Depends on: 34564 66091
Blocks: 9177
  Show dependency treegraph
 
Reported: 2007-01-13 03:19 PST by webkit
Modified: 2011-08-12 14:43 PDT (History)
21 users (show)

See Also:


Attachments
fixes the bug (83.63 KB, patch)
2011-08-11 13:04 PDT, Ryosuke Niwa
no flags Details | Formatted Diff | Diff
removes Apple-style-span (86.08 KB, patch)
2011-08-11 21:42 PDT, Ryosuke Niwa
no flags Details | Formatted Diff | Diff
added Chromium and GTK rebaselines (87.09 KB, patch)
2011-08-11 22:26 PDT, Ryosuke Niwa
no flags Details | Formatted Diff | Diff
Updated WebCore/ChangeLog (86.52 KB, patch)
2011-08-11 22:32 PDT, Ryosuke Niwa
justin.garcia: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description webkit 2007-01-13 03:19:06 PST
The <span> tag is used for the basic formatting operations, like: Bold, Italic, Underline, Strike through, Subscript and Superscript. The problem, other than the different behavior with other browsers, is that an additional class="Apple-style-span" attribute is added to each of those <span>s.

Just open the URL and start applying some formatting. Than switch to Source view to see the results.
Comment 1 Justin Garcia 2007-03-08 13:39:05 PST
You can get WebKit to use HTML tags to specify font style information if you put the document into quirks mode.  Notice that using HTML tags looks less an less elegant than a wrapper span the more style that you apply to a run of text.  Closing.
Comment 2 webkit 2007-03-08 13:52:22 PST
(In reply to comment #1)
> You can get WebKit to use HTML tags to specify font style information if you
> put the document into quirks mode.  Notice that using HTML tags looks less an
> less elegant than a wrapper span the more style that you apply to a run of
> text.  Closing.

Sorry for the misunderstanding Justin.

I think it is ok to use <span>. Actually, I'm copying here the key phrase from the ticket description (removing the browser difference "comment"):

"The problem is that an additional class="Apple-style-span" attribute is added to each of those <span>s"

So, to conclude, ok for <span>, no ok for class="Apple-style-span".

Comment 3 Justin Garcia 2007-03-08 16:28:58 PST
Ah!  Thanks for clearing that up.  Does the Apple-style-span class adversely effect behavior while editing, or does it just seem unnecessary?
Comment 4 Dan POPA 2007-03-09 00:50:03 PST
(In reply to comment #3)
> Ah!  Thanks for clearing that up.  Does the Apple-style-span class adversely
> effect behavior while editing, or does it just seem unnecessary?

It is unnecessary.
Imagine the MSHTML editor leaving class="microsoft-style-span" in the source code...


Re: using the <span> for basic formatting: this will make the WebKit editor incompatible with IE's editor which uses tags.

You could add the 'styleWithCSS' commandid, like Gecko, so rich editors can choose the formmating model regardless of the mode, quirks or standard.

I cannot control the rendering mode of the pages edited by my HTML editor, user will choose that on page creation.

The editing experience should be the same cross browser. Content formatted with WebKit would not be editable in IE.

I really love the contentEditable implementation, it is robust and it ressemble the IE's implementation.
Make sure the edited tag cant be deleted, as it happens now if you press DELETE inside an empty editable LI: remove everything from the LI then press DELETE, the LI will dissapear.


<ul>
	<li id="edit1" contentEditable="true">Editable <b>li</b> containing a <a href="#somelink">link</a>.</li>
</ul>

Go to http://www.mister-pixel.com/ever/bugs/webkit/ for test page and playground.

Regards,
Dan POPA
Comment 5 webkit 2007-03-09 01:55:14 PST
(In reply to comment #3)
> Ah!  Thanks for clearing that up.  Does the Apple-style-span class adversely
> effect behavior while editing, or does it just seem unnecessary?

It seams that removing it doesn't make any impact in the editing capabilities of WebKit. I can't say anything about WebKit internals, not even the reason of this attribute existence, but in any case it is not desirable to have it in the output.
Comment 6 Dave 2007-07-07 02:22:06 PDT
i just walked into the same issues with the tinymce editor (included in wordpress blogs).
actually this kills your format, so effectively it's not possible to use wordpress with safari(3).

i wonder if i/we should file a bug in the apple bug reporter, too?
or is this a webkit only thing?
Comment 7 Dave 2007-07-07 02:37:31 PDT
damm bugzilla. i cant add the tag that is added, too (in addition to the apple-style-span thing) there is a special BR with a class webkit block placeholder.

sorry. i would have added the actual tag, but bugzilla blocks every whatsoever combination (even with html special chars).

not sure should we file a rdar bug, too?
Comment 8 webkit 2007-09-04 15:54:24 PDT
This one doesn't block FCKeditor anymore, as we have implemented a custom formatting system. Still a bug though.
Comment 9 Dave 2007-11-27 06:22:25 PST
(In reply to comment #8)
> This one doesn't block FCKeditor anymore, as we have implemented a custom
> formatting system. Still a bug though.

Is anyone actually working on this one?
This really sucks like hell, when for example trying to blog with Safari3, as it will kill the formating of every wysiwyg webeditor (like the one that is included in wordpress)
Comment 10 Anders Jenbo 2007-11-27 14:30:07 PST
Tags like this should be kept purely internerl, when trying to get the html javascript should only be handed the clean, like wise webkit should automatically generate theas when ever it is feed html in to an edit box. Mozila has tons of tags like this but as it handles things like i just described you don't se it in the output.
Comment 11 Danny Bloemendaal 2007-12-20 08:46:44 PST
It's absolutely a problem that safari adds spans. Spans have nothing to do with writing sane, semantically correct content. Spans are for webdevelopers, not for writers. Right now, webkit inserts so many wrong spans. And if you try to copy paste text inside the editor, so many wrong tags are inserted. The editor becomse completely useless for use inside a true CMS like this. 
Comment 12 Mark Rowe (bdash) 2008-01-12 19:02:04 PST
<rdar://problem/5685600>
Comment 13 Anders Jenbo 2008-01-12 21:08:57 PST
(In reply to comment #1)
> You can get WebKit to use HTML tags to specify font style information if you
> put the document into quirks mode.  Notice that using HTML tags looks less an
> less elegant than a wrapper span the more style that you apply to a run of
> text.  Closing.

Proper use of the html tags is still recomendted, besides if you have a specific style for bold text on your page there no way you can make a style sheet work with output that just sayes <span style="font-wight:bold"> rather then <b> or <strong> and it takes up more space.
Comment 14 Justin Garcia 2008-01-29 18:24:25 PST
I see several complaints here.  Let me try and separate them:

Styled spans don't let the author customize styles, like bold, italic and underline.  One commenter writes:

> if you have a specific style for bold text on your page there no way you can make a style
> sheet work with output that just sayes <span style="font-wight:bold"> rather
> then <b> or <strong> and it takes up more space.

This should be addressed by <http://bugs.webkit.org/show_bug.cgi?id=13490> Implement execCommand("styleWithCSS", ...).

WebKit inserts unnecessary spans:

> Right now, webkit inserts so many wrong spans. And if you try to copy paste text 
> inside the editor, so many wrong tags are inserted.

This is not yet filed.

If a custom class on markup created by editing is necessary, it should be hidden and not appear in output from methods like innerHTML:

> when trying to get the html javascript should only be handed the clean, like
>  wise webkit should automatically generate theas when ever it is feed html 
> in to an edit box. Mozila has tons of tags like this but as it handles things 
> like i just described you don't se it in the output.

This is what the title of this bug report describes, so lets let this bug report cover this issue.

There are problems with formatting in the Wordpress editor:

> i just walked into the same issues with the tinymce editor (included in wordpress blogs).
> actually this kills your format, so effectively it's not possible to use wordpress with safari(3).

This sounds like <http://bugs.webkit.org/show_bug.cgi?id=14350> WordPress: Editor strips paragraph breaks,
which is an evangelism issue (and frustratingly still unfixed).  Could those of you having problems with WordPress verify this?

So that leaves just one issue unfiled: that WebKit inserts unnecessary spans during some editing operations.  Danny Bloemendaal mentioned this one.  Danny, could you please file a new bug and provide steps to reproduce?

Let me know if I've left something out here.
Comment 15 Anders Jenbo 2008-01-30 02:56:42 PST
You summarized it nicely.
Comment 16 Adam Strzelecki 2008-02-12 03:08:45 PST
Any change to have this resolved before 3.1 release? Thanks.
Comment 17 Michael Brodie 2008-02-13 10:45:33 PST
> So that leaves just one issue unfiled: that WebKit inserts unnecessary spans
> during some editing operations.  Danny Bloemendaal mentioned this one.  Danny,
> could you please file a new bug and provide steps to reproduce?
> 
> Let me know if I've left something out here.
> 

I stumbled onto this thread while searching for any information on "Apple-Style-Span" and Apple's Mail.app interaction with MS Outlook. I work in a large company that has both Windoze and Macs. When I send rich text email from my Mac (Mail v2.1.1) to an Outlook client, Outlook doesn't know how to interpret the Apple-Style-Span, and renders the email font as default Times New Roman 12 - even if I send in Ariel. I've done a lot of looking, and it appears the Apple-Style-Span is the culprit. I absolutely love Mail, but I am embarrassed to see my nicely formatted emails end up looking crappy in Outlook.

Does anyone know (1) how to configure Mail.app to not send these tags within Rich Text; or (2) apply a script post-email to remove them? As the discussion appears to me, this is a bug in WebKit that isn't being addressed currently. I'd appreciate any guidance.

Thanks,
Michael  @
Genentech

Comment 18 Justin Garcia 2008-02-13 11:36:25 PST
> When I send rich text email from my Mac (Mail v2.1.1) to an Outlook 
> client, Outlook doesn't know how to interpret the Apple-Style-Span, 
> and renders the email font as default Times New Roman 12 - even 
> if I send in Ariel

It is not the presence of the Apple-style-span class that Outlook has trouble with (and removing the special class name is the only thing that *this* bug covers), but the fact that the content is styled with the css font-family property. Mail on Leopard and Mail on 10.4.11+ should use legacy tags to style text, <b>, <i>, <font>, etc.  What version of Tiger are you running?
Comment 19 Michael Brodie 2008-02-13 17:57:07 PST
> It is not the presence of the Apple-style-span class that Outlook has trouble
> with (and removing the special class name is the only thing that *this* bug
> covers), but the fact that the content is styled with the css font-family
> property. Mail on Leopard and Mail on 10.4.11+ should use legacy tags to style
> text, <b>, <i>, <font>, etc.  What version of Tiger are you running?

I'm running 10.4.11. Yes, I may be misguided by posts elsewhere I have seen that alluded to Apple-style-span. In fact I just upgraded to 10.4.11 and there does appear to have been a change in the way the html is rendered. However, it still shows up in Outlook as TNR 12 - unless I manually select the text after I have written the email, and choose a different font. Even then, it doesn't show up the way I expect. Is there a recommendation you could give me for how to compose email that might be compatible with Outlook? We can take this offline if you wish since it may be out of the context of this particular "bug". Thx. 



Comment 20 Justin Garcia 2008-02-13 18:27:39 PST
(In reply to comment #19)

> However, it still shows up in Outlook as TNR 12 - unless I manually select the text after I
> have written the email, and choose a different font. Even then, it doesn't show
> up the way I expect.

I'm working with Michael offline to get this filed as a separate bug report.

Justin
Comment 21 David Kilzer (:ddkilzer) 2008-04-17 13:16:56 PDT
*** Bug 18423 has been marked as a duplicate of this bug. ***
Comment 22 David Kilzer (:ddkilzer) 2008-04-17 13:18:30 PDT
See Bug 18423 Comment #4 for additional unexpected behavior.

Comment 23 Graham Perrin 2008-05-27 00:59:55 PDT
Issues with 
Apple-style-span
also noted at 
http://dev.plone.org/plone/ticket/7446
and at 
http://dev.plone.org/plone/ticket/8085 

Comment 24 Graham Perrin 2008-05-27 03:08:11 PDT
… and http://dev.plone.org/plone/ticket/8086
Comment 25 Justin Garcia 2008-05-27 11:58:06 PDT
(In reply to comment #24)
> … and http://dev.plone.org/plone/ticket/8086

As I mentioned before, this bug is only about removing the class="Apple-style-span" from spans, not about changing the way we achieve inline style changes.  The bug that tracks that is here:

https://bugs.webkit.org/show_bug.cgi?id=13490
Comment 26 Alan Heywood 2010-11-16 14:59:15 PST
When copying and pasting text within CKEditor using webkit based browsers <span class="apple-style-span"> is being incorrectly pasted.  This does not occur with other browsers.  I've stopped using webkit based browsers for all CMS editing due to this bug.
Comment 27 Ryosuke Niwa 2011-08-11 13:04:13 PDT
Created attachment 103658 [details]
fixes the bug
Comment 28 WebKit Review Bot 2011-08-11 13:28:33 PDT
Comment on attachment 103658 [details]
fixes the bug

Attachment 103658 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/9351329

New failing tests:
editing/pasteboard/data-transfer-items.html
fast/events/ondrop-text-html.html
editing/inserting/5994480-2.html
editing/pasteboard/onpaste-text-html.html
Comment 29 Ryosuke Niwa 2011-08-11 13:28:52 PDT
Comment on attachment 103658 [details]
fixes the bug

Per Tony's suggestion, I'm separating the refactoring I'm doing in ApplyStyleCommand into a separate patch.
Comment 30 Ryosuke Niwa 2011-08-11 21:42:57 PDT
Created attachment 103732 [details]
removes Apple-style-span
Comment 31 WebKit Review Bot 2011-08-11 22:07:17 PDT
Comment on attachment 103732 [details]
removes Apple-style-span

Attachment 103732 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/9358506

New failing tests:
editing/inserting/5994480-2.html
Comment 32 Ryosuke Niwa 2011-08-11 22:26:21 PDT
Created attachment 103736 [details]
added Chromium and GTK rebaselines
Comment 33 Ryosuke Niwa 2011-08-11 22:32:08 PDT
Created attachment 103738 [details]
Updated WebCore/ChangeLog
Comment 34 Justin Garcia 2011-08-11 23:17:03 PDT
Comment on attachment 103738 [details]
Updated WebCore/ChangeLog

-            if (isUnstyledStyleSpan(element.get()))
+            if (isSpanWithoutAttributesOrUnstyleStyleSpan(element.get()))

Typo: "isSpanWithoutAttributesOrUnstyle*d*StyleSpan.

r=me
Comment 35 Ryosuke Niwa 2011-08-12 08:07:11 PDT
(In reply to comment #34)
> (From update of attachment 103738 [details])
> -            if (isUnstyledStyleSpan(element.get()))
> +            if (isSpanWithoutAttributesOrUnstyleStyleSpan(element.get()))
> 
> Typo: "isSpanWithoutAttributesOrUnstyle*d*StyleSpan.
> 
> r=me

Thanks for the review!  Very excited to land this patch today.
Comment 36 Ryosuke Niwa 2011-08-12 14:43:05 PDT
Committed r93001: <http://trac.webkit.org/changeset/93001>