[Webkit-unassigned] [Bug 8374] New: Creation of HTML with webkit causes extraneous output - should better utilize css over inline style

[bugzilla-daemon at opendarwin.org]

http://bugzilla.opendarwin.org/show_bug.cgi?id=8374

           Summary: Creation of HTML with webkit causes extraneous output -
                    should better utilize css over inline style
           Product: WebKit
           Version: 420+ (nightly)
          Platform: Macintosh
        OS/Version: Mac OS X 10.4
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML Editing
        AssignedTo: webkit-unassigned at opendarwin.org
        ReportedBy: james at imajes.info


Using a content editable div, i entered text with varying styles from varying
sources. The output of each produces questionable HTML. Each case is identified
as follows:

new line white space. This is expressed as follows -

    <div>
      <br class="khtml-block-placeholder">
    </div>

whilst the div's are probably unnecessary, this code is OK but not XHTML.

Static, unstyled text:

This returns plain text with no HTML styling - 

"1. this is straight text"

bold text:

    <div>
      2. <span class="Apple-style-span" style="font-weight: bold;">this is
bold</span>
    </div>

the problem is then evident with -

    <div>
      <span class="Apple-style-span" style="font-weight: bold;"><br class=
      "khtml-block-placeholder">
      </span>
    </div>

the whitespace holder now implements bold. This span is not required here. The
editor knows that it is producing a whitespace linebreak, as evidenced by the
class on the <br />. 

Output copied and pasted from Pages.app has extra spans:

    <div>
      <span style=""><span class="Apple-style-span" style=
      "color: rgb(255, 179, 0); font-family: Calibri; font-size: 14px;
font-weight: bold;">
      This text is from Pages, pasted in. It has font, color and weight
      set.</span></span>
    </div>

the first span serves no purpose.

Overall, the latest nightly produces high quality HTML - but it could be
improved, especially when managing line breaks and cross styles. It'd be much
better to see an inbuilt chrome css file which was used over inline style. DIVs
should also be replaced by P tags.

The one example I have of very bad code is from a mail.app signature I pasted,
however I cannot use it as evidence since it is not using the latest nightly.

attached is a testcase with a contenteditable area - utilizes the prototype
library to handle html escape.


-- 
Configure bugmail: http://bugzilla.opendarwin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.