Bug 11089
| Summary: | GoogleDocs: Subscript/Superscript text isn't the correct font size | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Chris Petersen <c.petersen87> | 
| Component: | HTML Editing | Assignee: | Nobody <webkit-unassigned> | 
| Status: | NEW | ||
| Severity: | Normal | CC: | abob, enrica, jparent, justin.garcia, mjs, rniwa, tony | 
| Priority: | P2 | Keywords: | GoogleBug, InRadar | 
| Version: | 420+ | ||
| Hardware: | All | ||
| OS: | All | ||
| Bug Depends on: | |||
| Bug Blocks: | 7712 | ||
          Chris Petersen
          
          
          
          
        
        
      Summary:
After applying Superscript or SubScript styling to text, the text doesn't have the correct font size applied. The text should appear in a smaller font size but still has the original font size applied.
Steps to Reproduce:
1) With TOT Webkit r16622, login into writely.com
2) Create a new document ( Click New link)
3) Type some text in the document body and select a portion of this text
4) From the writely toolbar, select SuperScript or Subscript
5) Style is applied but text size is wrong
Expected Results:
Subscript or Superscript text should be displayed in a smaller font size but isn't.
    | Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. | 
          Chris Petersen
          
          
          
          
        
        
      This is covered in <rdar://problem/4757693>
    
          Ryosuke Niwa
          
          
          
          
        
        
      I think this bug is due to the fact we just add vertical-align: sub or vertical-align: up when applying subscript or superscript.  Firefox adds sub/sup even when StyleWithCSS=true to avoid this problem.
    
          Ryosuke Niwa
          
          
          
          
        
        
      Sorry my comment wasn't clear.  Firefox adds sub/sup elements as supposed to adding vertical-align: sub or vertical-align: super, which is what WebKit currently does.
I think Firefox's behavior is the best we can do because if we were to add font-size: small with vertical-align, we cannot tell whether the font-size is user-specified or the one assigned along with vertical-align.  We could introduce yet-another-class like WebKit-vertical-align-span to deal with this kind of situation but font-size could easily be pushed to other styles, and I don't think we can track all possible ways in which font-size can be propagated.
Modifying WebKit to always use sub/sup elements is an easy fix because we can just modify StyleChange to always extract vertical-align property regardless of the value of styleWithCSS.
    
          Julie Parent
          
          
          
          
        
        
      IE also uses sup/sub, so changing WebKit to be consistent with both IE and FF sounds reasonable.
    
          Ryosuke Niwa
          
          
          
          
        
        
      (In reply to comment #3)
> Modifying WebKit to always use sub/sup elements is an easy fix because we can just modify StyleChange to always extract vertical-align property regardless of the value of styleWithCSS.
Maybe this is not as simple as I initially thought.  It's quite possible that vertical-align is specified by itself and passed to ApplyStyleCommand for style preservation purposes.  If I make the above change, then we'll end up converting all of that to sub/sup, which seems wrong.  We could applyElement(sub/sup) to work-around this but then we'll fail to remove existing styles.  The only possible work-around I can think of right now is to pass both vertical-align and sub/sup element but I don't think this has never done before and it might have weird bugs.