Open Bug 778796 Opened 12 years ago Updated 2 years ago

execCommand with strikethrough does not render strike through line in center

Categories

(Core :: Layout: Text and Fonts, defect)

Product:
Core
Component:
Layout: Text and Fonts
Version:
14 Branch
Platform:
x86_64
Windows 7
Type:
defect

Tracking

()

People

(Reporter: hokamoto, Unassigned)

References

Details

(Keywords: regression, testcase)

Attachments

(2 files)

strikethrough.jpg
38.56 KB, image/jpeg
Details
Reporter's Testcase
641 bytes, text/html
Details
Attached image 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.
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.
Status: UNCONFIRMED → NEW
Component: Untriaged → Editor
Ever confirmed: true
Product: Firefox → Core
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.
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.)
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.
(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...
Component: Editor → Layout: Text
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.
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.
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.
See Also: → 932743
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: