Last Comment Bug 491670 - text-decoration on inlines is not drawn on blocks inside of those inlines
: text-decoration on inlines is not drawn on blocks inside of those inlines
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Layout: Block and Inline (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla8
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
https://eyeasme.com/Joe/Firefox_bug.html
Depends on: 403524 403526
Blocks: css2.1-tests
  Show dependency treegraph
 
Reported: 2009-05-06 05:43 PDT by Joe Java
Modified: 2011-08-05 16:47 PDT (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Joe Java 2009-05-06 05:43:01 PDT
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090506 Shiretoko/3.5b5pre
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090506 Shiretoko/3.5b5pre

See https://eyeasme.com/Joe/Firefox_bug.html
Notice that the test in the box is not underlined, it should be

Reproducible: Always

Steps to Reproduce:
1. see https://eyeasme.com/Joe/Firefox_bug.html
2. notice that the text in the box is not underlined, it should be
3.
Actual Results:  
Text in box is not underlined

Expected Results:  
Text in box should be underlined

See Section 16.3.1 of CSS 2.1 specification:
http://www.w3.org/TR/CSS21/text.html#propdef-text-decoration

See the example in this section:

   blockquote { text-decoration: underline; color: blue; }
   em { display: block; }
   cite { color: fuchsia; }


   <blockquote>
    <p>
     <span>
      Help, help!
      <em> I am under a hat! </em>
      <cite> —GwieF </cite>
     </span>
    </p>
   </blockquote>

notice that the example shows the text "-Gwief" in the "cite" tag is underlined.


Look at EditorOverride.css (this is a file that Firefox uses to give default CSS value to tags) (the location of this file will vary with your operating system):

a:link {
  text-decoration: underline -moz-anchor-decoration;
  color: -moz-hyperlinktext;
}


Look at the XHTML code in https://eyeasme.com/Joe/Firefox_bug.html

  <a href="https://eyeasme.com/Joe/Firefox_bug.html"> 
     <span class="box">
        ... text here ..
     </span>
  </a>

the CSS code for the "box" is
     .box
      {
        height: 250px;
        width: 300px;
        background-color: red;
        color: black;
        float: left;
        padding: 10px;
        margin-right: 25px;
      }

Thus, following the example given in the CSS specification, I think that the text in the "box" span should be underlined.

Also note that included in https://eyeasme.com/Joe/Firefox_bug.html
is a table that shows how many of the latest browsers handle this example.
Comment 1 Joe Java 2009-05-06 08:43:28 PDT
Referring to Comment #1

I may be wrong about EditorOverride.css being the file that sets the default CSS values.  But I am somewhat sure that somewhere it is set similar to this.  I could not find the default setting for the link tag in html.css file.  It must be set somewhere else or hardcoded in.  Once it is confirmed that the default 
CSS declaration for the "a" tag is "text-decoration: underline", then the argument given above should lead to the same conclusion.
Comment 2 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2009-05-06 11:28:15 PDT
The issue in this testcase is that you have a block inside of an inline, and we don't propagate text-decoration on inlines to blocks inside of them.

That's correct per current CSS 2.1, as I already said in bug 491501 comment 2, but it's possible we should get the spec changed here.

I think this is likely a duplicate.
Comment 3 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2009-05-06 11:30:50 PDT
Er, sorry, I'm actually wrong about what the current spec says ... thanks for pointing out that example.  So we are wrong per the current spec.  The key piece of the spec is the last 6 words of:

  # When specified on an inline element, it affects all the boxes generated by
  # that element; for all other elements, the decorations are propagated to an
  # anonymous inline box that wraps all the in-flow inline children of the
  # element, and to any block-level  in-flow descendants.

But you are wrong about EditorOverride.css.  The default styles are in html.css, ua.css, and forms.css.
Comment 4 Joe Java 2009-05-06 14:50:03 PDT
In Reference to Comment #3:

I looked several times but could not find the default settings for the link tag "a".  If someone would be so kind as to point out the file where the default behavior for the "a" tag is defined, I would be grateful.  I tried looking in html.css, ua.css, and forms.css, but did not find the definition for the default values for the "a" tag specified in any of these.
Comment 5 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2009-05-06 14:59:07 PDT
You want to look for the ":-moz-any-link" or ":link, :visited" rules.
Comment 6 Joe Java 2009-05-12 10:28:20 PDT
In Reference to Comment #5:  I did.  It appears to be in either EditorOverride.css or contenteditable.css .
Comment 7 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2009-05-12 10:54:56 PDT
See also bug 403526 (and bug 428599, bug 202930).
Comment 8 Joe Java 2009-05-12 11:27:58 PDT
In Reference to Comment #7:

My advise to specifications writers and API designers is:
Don't do anything that surprises (i.e is non-intuitive to) the developer.

This bugs behavior was surprising.
Comment 9 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2009-05-12 11:46:06 PDT
I don't see how that's related to comment 7 (which wasn't particularly directed to you).
Comment 10 Joe Java 2009-05-12 12:32:36 PDT
In Reference to Comment #9:

<major rant>
No disrespect meant, but after reading the three bugs reports listed in Comment #7, it appears that the browser developers are asking the specifications writers about how the browsers should behave based on the standards.  All three bugs are roughly waiting for the behavior to be standardized before being fixed.  This is wrong.  When the standards are ambiguous the developer should make a decision on behavior and move on.  Specifications are written as to what is, not what is to be.  The specifications will be clarified to match the behavior chosen by the developer.  Some of these bugs and MANY YEARS OLD!  Why should a user bother posting a bug if the developers are going to spend YEARS deciding on what they are going to do to fix it?  This idea of leaving a bug open waiting for a committee to decide on a standard is wrong.  Just pick a non-surprising solution and fix the bug.
</major rant>

So how is my comment related?  Because the browser developers are waiting for the specification writers to chose a behavior for browsers to take.  I am hoping they chose a non-surprising behavior.  

I hope this bug is fixed within this decade.
Comment 11 Zack Weinberg (:zwol) 2009-05-12 13:05:22 PDT
> All three bugs are roughly waiting for the behavior to be standardized before
> being fixed.  This is wrong.  When the standards are ambiguous the developer
> should make a decision on behavior and move on.

We used to do that.  It was disastrous, because for every ambiguity, the Firefox (then Netscape) developers made a different choice than the MSIE developers.  I'm only exaggerating a little.  Running all decisions of this nature through the standards body *before* implementation is how we ensure that that doesn't happen anymore.
Comment 12 playmobil 2009-07-11 23:13:24 PDT
FYI, on the WebKit side, this issue is being discussed in 
https://bugs.webkit.org/show_bug.cgi?id=23804
Comment 13 Joe Java 2009-10-31 21:25:04 PDT
The website showing this bug has been updated to show the latest behavior of several web-browsers (Firefox, Opera, Internet Explorer, Safari, and Amaya)

https://eyeasme.com/Joe/Firefox_bug.html
Comment 14 Joe Java 2010-05-20 06:40:53 PDT
The website showing this bug 
https://eyeasme.com/Joe/Firefox_bug.html
has been updated to show the latest behavior of
several web-browsers (Firefox, Opera, Internet Explorer, Safari, and Amaya)

latest stable Safari and Amaya are correct.
latest stable Firefox, Opera, and Internet Explorer are NOT correct.
Comment 15 Joe Java 2010-06-24 11:04:38 PDT
I updated the webpage at 
https://eyeasme.com/Joe/Firefox_bug
so now it is a valid XHTML 1.0 Strict webpage.

Firefox 3.6.4 is the ONLY browser to NOT underline text in a span within a hyperlink.

The latest versions of the following browsers ALL correctly underline the text:
Amaya, Chrome, Internet Explorer, Opera, and Safari.
Comment 16 Joe Java 2010-11-23 05:19:16 PST
Any work being done on this bug?  It appears to be a pretty straight forward fix.
Comment 17 Joe Java 2011-02-02 05:05:38 PST
Updated 
https://eyeasme.com/Joe/Firefox_bug
to show this bug.  Would be nice to have fixed for FF 4.
Comment 18 Vitor Menezes 2011-08-05 16:47:09 PDT
Patch for bug 403524 causes underlines to be propagated to blocks inside inlines properly in all modes, and thereby resolves this issue.

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