Last Comment Bug 778796 - execCommand with strikethrough does not render strike through line in center
: execCommand with strikethrough does not render strike through line in center
Status: NEW
: regression, testcase
Product: Core
Classification: Components
Component: Layout: Text (show other bugs)
: 14 Branch
: x86_64 Windows 7
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-30 11:08 PDT by Hiroyuki Okamoto
Modified: 2013-10-31 07:07 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
strikethrough.jpg (38.56 KB, image/jpeg)
2012-07-30 11:08 PDT, Hiroyuki Okamoto
no flags Details
Reporter's Testcase (641 bytes, text/html)
2012-08-01 08:31 PDT, (mostly gone) XtC4UaLL [:xtc4uall]
no flags Details

Description Hiroyuki Okamoto 2012-07-30 11:08:56 PDT
Created attachment 647220 [details]
strikethrough.jpg

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Build ID: 20120713134347

Steps to reproduce:

1. Create a simple editor code like this:
=================
<html>
<head>
<script>
function load() {
  document.getElementById('edit').contentWindow.document.designMode = "on";	
}

function fontsize(size) {
  document.getElementById('edit').contentWindow.document.execCommand('fontsize', false, size);
}

function strikethrough() {
  document.getElementById('edit').contentWindow.document.execCommand('strikethrough');
}
</script>
</head>
<body onload="load();">
<input type="button" value="72pt" onclick="fontsize('72pt');">
<input type="button" value="Strike through" onclick="strikethrough();">
<iframe id="edit" width="100%" height="200px"></iframe>
</div>
</body>
</html>
=================

2. Type text  in the html editor.
3. Select text
4. Press "72pt" button
5. Press "Strike through" button




Actual results:

The "Strike through" line is not rendered in center.  It looks like  underline.


Expected results:

execCommand('strikethrough') should render strike through line in center.  In the above example, it almost look like underline, unlike strikethrough.
Comment 1 (mostly gone) XtC4UaLL [:xtc4uall] 2012-08-01 08:30:20 PDT
Last good nightly: 2012-04-03
First bad nightly: 2012-04-04

Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7857c5bff017&tochange=f64f62213f61
Comment 2 (mostly gone) XtC4UaLL [:xtc4uall] 2012-08-01 08:31:05 PDT
Created attachment 647959 [details]
Reporter's Testcase
Comment 3 (mostly gone) XtC4UaLL [:xtc4uall] 2012-08-01 11:32:42 PDT
As of now I was able to reduce/bisect to http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7857c5bff017&tochange=4e515b6a5a41 with local building.

Bug 741734 may be a Candidate.

Btw, if you flip Steps 4 and 5 it's WFM.
Comment 4 (mostly gone) XtC4UaLL [:xtc4uall] 2012-08-02 12:50:11 PDT
Ok, I was able to reduce to http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7857c5bff017&tochange=40406a497a3f then I get Build Errors all the Time.

Seems to be caused by one of Aryeh's Editor Pushes.
Comment 5 Aryeh Gregor (:ayg) (next working March 28-April 26) 2012-08-03 07:55:52 PDT
This behavior is not new in any recent changes.  It's a basic consequence of how any HTML editor will work unless it makes elaborate special cases for text-decoration, since text-decoration works very weirdly in CSS.  Prior to 14, it might not have happened in this particular case, but something similar would have still been easily obtainable by a different sequence of actions.

The markup in this specific case is currently per the editing spec, I believe.  The new markup gets placed the outside of any existing tags.  So if you first apply font-size, then text-decoration (strikethrough/underline), you get

  <s><font size=7>foo</font></s>

Unfortunately, the position and thickness of text-decoration lines in CSS is mostly undefined:

"""
In determining the position and thickness of text decoration lines, user agents may consider the font sizes and dominant baselines of descendants, but for a given element's decoration must use the same position and thickness throughout each line box.
"""
http://dev.w3.org/csswg/css3-text/#line-decoration

So browsers do whatever they feel like.  In Gecko, position and thickness are (apparently?) determined by the font-size/etc. of the element applying the style, in this case the <s>.  Which is outside the <font> tag.  So the style drawn is appropriate to the default font size, which is much lower and thinner than expected.  Opera Next 12.00 alpha has the same problem; Chrome 22 dev and IE 10 Developer Preview both display the line at the same height and thickness as if the <s>/<font> tags were switched, i.e., at a level appropriate to the text.

Moreover, per the CSS spec, the line in the following markup snippet must be of the same height and thickness throughout, which does not match how word processors behave when you perform the expected series of commands:

  <s>foo<font size=7>bar</font>baz</s>

However, both Chrome 22 dev and IE 10 Developer Preview ignore the spec and display a separate, higher strikethrough for "bar".


Personally, I think Gecko and the spec should follow IE/WebKit.  Yes, that makes text-decoration strictly less powerful, but I think it's much more important that we match user expectations here for the default behavior of <u>, <s>, etc.

So specifically, I propose that this be resolved by making each piece of text have its text-decoration's height and thickness determined based on that text's font-size, not the font-size of the ancestor that created the decoration.  (Color should still follow the ancestor, and I currently have no opinion on other things like line-height.)  This appears to match IE and WebKit, and all word processors.  Obviously, we should concurrently get the spec changed to allow (preferably require) this behavior, which shouldn't be hard if the three biggest engines all agree.  What do our CSS people think?

(Failing that, we could work around the problem in the editor, but to do so properly would be a whole bunch of special-case code, plus equivalent requirements in the spec.)
Comment 6 Aryeh Gregor (:ayg) (next working March 28-April 26) 2012-08-09 05:48:32 PDT
CCing fantasai also -- see comment 5.  I'm happy to bring this up on www-style, but first I want to know if Gecko actually wants to make this change.
Comment 7 :Ehsan Akhgari 2012-08-09 12:22:22 PDT
(In reply to comment #5)
> (Failing that, we could work around the problem in the editor, but to do so
> properly would be a whole bunch of special-case code, plus equivalent
> requirements in the spec.)

Let's not go down that route...
Comment 8 David Baron :dbaron: ⌚️UTC-10 (vacation, returning December 19) 2012-08-09 12:28:56 PDT
So I think the spec change you're proposing would probably be an improvement for strike-through and overline, but would make things worse for underline, which is by far the most common case.  There's a strong desire in the working group to avoid "ransom note" style underlining.
Comment 9 fantasai 2012-08-09 20:15:59 PDT
You also want to avoid "ransom note" style strike-throughs when there are subtler changes in the font, probably only changing the position if the font size itself changes, not if the font face changes and tweaks the ascent/descent with it. Subscripts and superscripts are another interesting case: do you want to break the strikethrough for them? Jump the overline up/down?

The only reason underlines seem exceptional is because we baseline-align text, and the underline is positioned relative to the baseline, so keeping it consistent always looks good. If we centered text (as they do in vertical lines in CJK), the same questions would come up for underlines, and not for strike-through.

I agree it's an issue, I don't know that there's an obvious good answer here. I'd say go ahead and post to www-style: regardless of what's discussed here, either the specs need updating somehow or the implementations that claim to support CSS2.1 do. Or both.
Comment 10 Aryeh Gregor (:ayg) (next working March 28-April 26) 2012-08-13 05:35:16 PDT
http://lists.w3.org/Archives/Public/www-style/2012Aug/0379.html

(In reply to fantasai from comment #9)
> You also want to avoid "ransom note" style strike-throughs when there are
> subtler changes in the font, probably only changing the position if the font
> size itself changes, not if the font face changes and tweaks the
> ascent/descent with it. Subscripts and superscripts are another interesting
> case: do you want to break the strikethrough for them? Jump the overline
> up/down?

IE and LibreOffice jump underlines down for subscripts, but not up for superscripts.  (I've noticed that IE not uncommonly behaves more like word processors than other browsers do.  Maybe they share code with Word, or at least expertise.)  WebKit jumps for both, Gecko/Opera for neither.

For strikethrough, IE, LibreOffice, and WebKit jump for both subscripts and superscripts.  Gecko/Opera don't.

It seems like there are three basic categories of behavior:

* Gecko/Opera mindlessly draw a single line according to the element that generates it, even if it's totally inappropriate to the contents.  (Even in a case like <s><font size=7>foo</font></s>!)
* WebKit mindlessly draws a different line whenever size/vertical-align/etc. changes, even if it looks pointlessly ugly.
* IE and LibreOffice (and Word?) are smart about things.  They try to draw the same line, but only in cases where it doesn't look unnecessarily ugly.

I think the third category of behavior is the one we want to track.  If we want something really simple, though, switching to WebKit's behavior for line-through/overline would be an improvement.

> The only reason underlines seem exceptional is because we baseline-align
> text, and the underline is positioned relative to the baseline, so keeping
> it consistent always looks good. If we centered text (as they do in vertical
> lines in CJK), the same questions would come up for underlines, and not for
> strike-through.

Good point.

Note You need to log in before you can comment on or make changes to this bug.