11089 2006-09-29 09:44:53 -0700 GoogleDocs: Subscript/Superscript text isn't the correct font size 2017-07-18 08:30:31 -0700 1 1 1 Unclassified WebKit HTML Editing 420+ All All NEW GoogleBug, InRadar P2 Normal --- 7712 1 c.petersen87 webkit-unassigned abob enrica jparent justin.garcia mjs rniwa tony oldest_to_newest 56786 0 c.petersen87 2006-09-29 09:44:53 -0700 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. 56802 1 c.petersen87 2006-09-29 11:29:11 -0700 This is covered in <rdar://problem/4757693> 285590 2 rniwa 2010-09-27 11:12:29 -0700 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. 285633 3 rniwa 2010-09-27 11:41:06 -0700 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. 285756 4 jparent 2010-09-27 14:42:05 -0700 IE also uses sup/sub, so changing WebKit to be consistent with both IE and FF sounds reasonable. 291334 5 rniwa 2010-10-07 17:01:59 -0700 (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.