Bug 12248 – Apple-style-span class seems unnecessary

• Component: HTML Editing
• Status: RESOLVED FIXED

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.

[Justin Garcia]

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.

(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".

[Justin Garcia]

Ah!  Thanks for clearing that up.  Does the Apple-style-span class adversely effect behavior while editing, or does it just seem unnecessary?

[Dan POPA]

(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

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

[Dave]

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?

[Dave]

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?

This one doesn't block FCKeditor anymore, as we have implemented a custom formatting system. Still a bug though.

[Dave]

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

[Anders Jenbo]

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.

[Danny Bloemendaal]

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. 

[Mark Rowe (bdash)]

<rdar://problem/5685600>

[Anders Jenbo]

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

[Justin Garcia]

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.

[Anders Jenbo]

You summarized it nicely.

[Adam Strzelecki]

Any change to have this resolved before 3.1 release? Thanks.

[Michael Brodie]

> 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

[Justin Garcia]

> 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?

[Michael Brodie]

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

[Justin Garcia]

(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

[David Kilzer (:ddkilzer)]

*** Bug 18423 has been marked as a duplicate of this bug. ***

[David Kilzer (:ddkilzer)]

See Bug 18423 Comment #4 for additional unexpected behavior.

[Graham Perrin]

Issues with 
Apple-style-span
also noted at 
http://dev.plone.org/plone/ticket/7446
and at 
http://dev.plone.org/plone/ticket/8085 

[Graham Perrin]

… and http://dev.plone.org/plone/ticket/8086

[Justin Garcia]

(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

[Alan Heywood]

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.

[Ryosuke Niwa]

Created attachment 103658 [details]
fixes the bug

[WebKit Review Bot]

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

[Ryosuke Niwa]

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.

[Ryosuke Niwa]

Created attachment 103732 [details]
removes Apple-style-span

[WebKit Review Bot]

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

[Ryosuke Niwa]

Created attachment 103736 [details]
added Chromium and GTK rebaselines

[Ryosuke Niwa]

Created attachment 103738 [details]
Updated WebCore/ChangeLog

[Justin Garcia]

Comment on attachment 103738 [details]
Updated WebCore/ChangeLog

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

Typo: "isSpanWithoutAttributesOrUnstyle*d*StyleSpan.

r=me

[Ryosuke Niwa]

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

[Ryosuke Niwa]

Committed r93001: <http://trac.webkit.org/changeset/93001>