695442 - strike style not correctly applied to sub and sup elements

Status: RESOLVED INVALID

Description

[John A. Bilicki III]

Created attachment 567840 [details]
test_strike.xhtml

User Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Build ID: 20110928134238

Steps to reproduce:

When a s (strike) element contains a sub or sup element the text is not correctly striken.


Actual results:

The sub element is effectively styled with an overline.

The sup element is effectively styled with an underline.


Expected results:

The strike should appear across the middle of the text itself; it should not strike through ignoring the character positioning.

This bug also occurs in Opera 12, it does not effect IE8 or Safari 5.1.

Comment 1

[Boris Zbarsky [:bz] (vacation Aug 14-27)]

I believe that our behavior is in fact the correct one for CSS line-through decorations and our implementation of sub/sup.

IE seems to do this for line-through in general, not just for <s>.

Specifically, the relevant text at http://www.w3.org/TR/CSS21/text.html#lining-striking-props is:

  In determining the position of and thickness of text decoration lines, user agents may
  consider the font sizes of and dominant baselines of descendants, but must use the same
  baseline and thickness on each line. 

In particular, vertical-align changes (which are what sub and sup do) do NOT affect the position of decorations.  There should be a single line in that testcase, with no breaks, per spec as far as I can see.

Now there is also this bit:

  Some user agents have implemented text-decoration by propagating the decoration to the
  descendant elements as opposed to preserving a constant thickness and line position as
  described above. This was arguably allowed by the looser wording in CSS2. SVG1,
  CSS1-only, and CSS2-only user agents may implement the older model and still claim
  conformance to this part of CSS 2.1. (This does not apply to UAs developed after this
  specification was released.) 

It seems that's what WebKit and Trident are doing.

So as far as I can tell, this is wontfix, since implementing the desired behavior means that either <s> or <sub>/<sup> need to be implemented in a non-CSS way or that we have to violate the spec.

Comment 2

[John A. Bilicki III]

Created attachment 567850 [details]
Stricken text ineffectively contrasting overlined/underlined text.

Then from what you've told me the problem is the spec then; visually the strike appears as an underline to sup text and an overline to sub text. What the user perceives should be taken as precedence for what should be implemented.

The second attachment 'test_strike2.xhtml' demonstrates that the styling is too similar. Consider asking the opinions of non-technical people of which paragraph contains text that is stricken and which contains text that is overlined and underline. Then ask them showing the same test case in IE or Safari.

Also my attachments are served as application/xhtml+xml.

Comment 3

[Boris Zbarsky [:bz] (vacation Aug 14-27)]

> What the user perceives should be taken as precedence for what should be implemented.

Not unless the spec gets changed in the process.  Purposefully violating specs without actually getting them updated just leads to non-interoperability and grief.

> Also my attachments are served as application/xhtml+xml.

Then set that type on them when uploading them?  It's right in the dropdown menu....

Comment 4

[David Baron :dbaron: ⌚️UTC-7]

I agree with Boris that we're implementing the spec correctly.

I also think the spec itself is correct.  I think this is the expected behavior for normal uses of sub and sup.  For example, given the markup: <s>The answer is x<sup>2</sup>.</s>, you don't want the line to move around.  Yes, you can construct testcases that look funny, but those testcases don't reflect typical usage of subscripts and superscripts.

Comment 5

[David Baron :dbaron: ⌚️UTC-7]

Created attachment 567858 [details]
... and if all you want to strike out is the sub/sup

I'd also note that if, like in the examples you attached, all you want to strike out is the contents of the sub/sup, then you probably want the s element inside the sub/sup element (or just style the sub/sup with CSS).

Comment 6

[John A. Bilicki III]

David, the problem with your test case is that Gecko only allows people to redact the sub or sup text alone; it's much more likely that when someone redacts something that it would include text that references the sub/sup text as well. So essentially numerous s/strike elements are required for a single effective strike.

In an English analogy I could say I have three movie genres in my collection, action, mystery and science-fiction. I could then strike out the entire mystery collection with a single stroke or I could individually strike each one out one at a time though the latter makes no sense.

I'm working on an advanced text editor...when selecting text should I tell my users that they have to manually strike out two or more sets of text that are directly next to each other? I shouldn't. Then should I spend extra time to interpret the code for a browser/spec bug? Why should I? <s><sub>text</sub></s> and <sub><s>text</s></sub> have the exact same context, all the text has been redacted.

So essentially you just displayed that Gecko inconsistently applies the styling based on which element is the parent. Why should this case be different when considering the elements 'a' and 'em' in example?

I have sent the test case and a link to this bug to the W3C CSS mailing list for consideration.

Comment 7

[Gérard Talbot]

> if, like in the examples you attached, all you want to
> strike out is the contents of the sub/sup, then you probably want the s
> element inside the sub/sup element (or just style the sub/sup with CSS).

striken (line-through) text style versus sub and sup elements
http://www.gtalbot.org/BrowserBugsSection/MozillaBugs/bug695442-line-through-versus-sup-sub.html

There should be a testcase in CSS 2.1 test suite reflecting this.

regards, Gérard

Comment 8

[Gérard Talbot]

(In reply to Boris Zbarsky (:bz) from comment #1)

> (...) relevant text at
> http://www.w3.org/TR/CSS21/text.html#lining-striking-props is:
> 
>   In determining the position of and thickness of text decoration lines,
> user agents may
>   consider the font sizes of and dominant baselines of descendants, but must
> use the same
>   baseline and thickness on each line. 
> 
> In particular, vertical-align changes (which are what sub and sup do) do NOT
> affect the position of decorations. (...)

CSS Test: text-decoration with inline children
http://test.csswg.org/suites/css2.1/latest/html4/text-decoration-087.htm

Firefox 7.0.1, Opera 11.52 and Konqueror 4.7.2 pass such text-decoration-087 test. 

Chrome 14.0.835.202 fails such test.

IE9 Implementation Report claims (!) to pass such text-decoration-087 test.

Chrome 6.0.472.63 and Safari 5.0.2 respective Implementation Report of CSS2.1 test suite both claim to pass such text-decoration-087 test but this is most likely an error when doing the test, when reading/understanding the pass condition.


I have done more testcases on 'text-decoration: line-through' versus 'vertical-align' . I will probably submit a few later next week.

regards, Gérard

Comment 9

[Gérard Talbot]

Submitted tests at CSS 2.1 test suite related to this bug report:

http://test.csswg.org/suites/css2.1/nightly-unstable/html4/text-decoration-position-001.htm

http://test.csswg.org/suites/css2.1/nightly-unstable/html4/text-decoration-va-length-001.htm

http://test.csswg.org/suites/css2.1/nightly-unstable/html4/text-decoration-va-length-002.htm

http://test.csswg.org/suites/css2.1/nightly-unstable/html4/text-decoration-va-sub-super-001.htm

http://test.csswg.org/suites/css2.1/nightly-unstable/html4/text-decoration-va-sub-super-002.htm

http://test.csswg.org/suites/css2.1/nightly-unstable/html4/text-decoration-va-sub-super-003.htm

http://test.csswg.org/suites/css2.1/nightly-unstable/html4/text-decoration-va-sub-super-004.htm

If there is a problem with one of those tests, then you must explain it in
W3C public CSS test suite mailing list
[e-mail] (registration required)

I am merely listing the tests here as a followup to comment #7 and to the resolution of this bug.

Gérard