Open Bug 312315 Opened 19 years ago Updated 2 years ago

Extra space after abbr/acronym text if closed with spaces before it -- there should be no spaces unless specified to preserve them.

Categories

(Core :: Layout: Block and Inline, defect)

1.0 Branch
x86
Linux
defect

Tracking

()

UNCONFIRMED

People

(Reporter: ldavison, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

An extra space is added on the end of the abbr or acronym tag if the closing tag
is not right up against the word at the end of your abbreviation or acronym. 

Here's the test:

<p>
  <!-- 1 space before and after, white-space normal -->
  <abbr title="abbr" style="white-space:normal;"> abbr </abbr><br />

  <!-- 2 spaces before and after default style -->
  <abbr title="abbr2">  abbr2  </abbr><br />

  <!-- 1 space before 4 spaces after
  <abbr title="abbr3"> abbr3    </abbr><br />

  <-- 1 newline before and after -->
  <abbr title="abbr4">
    abbr4
  </abbr><br />

  <!-- RESULTS FOR ALL OF THE ABOVE: no leading spaces, 1 ending space with
default style applied to it -->
</p>

This extra space continues to take on the style of that tag which means we have
a space with (default) thin dotted border on the bottom.  

All spaces I believe inside tags are suppose to be ignored unless we specify
spaces to be preserved, the leading spaces get trimmed successfully.  I haven't
tested all tags out yet, only abbr and acronym, however not all tags have
noticeable styles like this aswell, but the "a" element did not pick up the
extra space doing this test.

I write pages in 100% compliant XHTML 1.1 with application/xhtml+xml mime-type.
This however happens under normal HTML as well.

Reproducible: Always

Steps to Reproduce:
1.Code in Details
2.
3.

Actual Results:  
Extra space with style applied.

Expected Results:  
Removed extra space.
Severity: trivial → normal
Component: General → Layout: Block and Inline
Product: Firefox → Core
QA Contact: general → layout.block-and-inline
Summary: Extra space after abbr/acronym text if closed with spaces before it -- there should be no spaces unless specified to preserve them. → Extra space after abbr/acronym text if closed with spaces before it -- there should be no spaces unless specified to preserve them.
Version: unspecified → 1.0 Branch

*** This bug has been marked as a duplicate of 191699 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
I don't think this is a duplicate (the reporter is complaining about whitespace
handeling even in cases where "white-space" is not specified).

It's probably invalid, though.
Added a URL page to prove the situation. I don't think it's related to the other
bug reported.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
As far as I can tell, we implement http://www.w3.org/TR/CSS21/text.html#q8 correctly.  Specifically:

Per rule 1 in the second list, leading whitespace at beginnings of lines is removed.

Per rule 4 in the first list, given:

  <tag> text </tag> more text

the space that's removed is the space after </tag>.

Note that rule 3 allows newlines to become zero width spaces, and maybe that's what you're asking for here?  But that's optional, and in many cases would be wrong.
W3C contradict themselves, by saying designers should not write code as <span>Space in here </span><span>More Text </span> but write it as <span>No space in here</span> <span>More Text</span>.

Yet their Rule 3 for text is confusing non the less.

Opera seems to do what I would expect with how I wrote my code.

Basically if I did:

<p><span style="text-decoration: underline;">Underline This</span> <span style="text-decoration: underline;">And This</span></p>

I was hoping I could write that out like:

<p>
  <span style="text-decoration: underline;">Underline This</span>
  <span style="text-decoration: underline;">And This</span>
</p>

Without it appearing as if I just applied underline to everything including a space be it newline/tab/space.  I positive there's no space at the end of "Underline This" in there using that styling, so why does it affect it?
Sorry, I should also mention that I discovered it doesn't matter if I wrote it like:

<p>
  <span style="text-decoration: underline;">
    Underline This
  </span>
  <span>
    And this
  </span>
</p>

In which I would have understood if Rule 3 was being applied, but in my above, there's no spacing inside these elements, nor styling specified for them, which makes me wonder why styling was applied at all.

Lists, Table Cells, etc, all are affected by this.
> I was hoping I could write that out like:

You can.  That's not what your testcases are doing, however.

So maybe I misunderstood the problem?  Your problem is that given the markup:

  <abbr>
    text
  </abbr>

The box for the <abbr> includes a trailing space, right?  That's allowed by the spec (though not having a trailing space is maybe also allowed; that part of the spec is not clear to me).  In any case, not having a trailing space is very hard without screwing up the following markup:

  <abbr>
    text
  </abbr><abbr>
    text
  </abbr>

which needs to have a space inside the first abbr no matter what, it seems to me.

Am I misunderstanding the problem?
This is confusing, what I gather from the rules is that I believe Firefox is doing those rules correctly.

Rule 1)Any white space surrounding a linefeed should be removed.

test case:

<p>[\n]
<span style="text-decoration: underline;">[\n]
[indent]content[\n]
</span>[\n]
<span style="text-decoration: underline;">[\n]
[indent]more content[\n]
</span>[\n]
</p>

So are those newlines surrounded by whitespacing, [indent]?  That's removed right?

Rule 3)That linefeed should be converted to a space.

I guess that's how firefow interprets this rule, however SGML linebreaks after a  start tag and before an end tag should be removed (applies to all elements).  Not CSS specific but HTML (couldn't locate anything relevant in XHTML/XML on handling this, so I'm looking at http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#notes-line-breaks).

I notice the linebreaks after the start of <p> and before the end of <p> are removed, that's correct to me.

Then you've got the linebreaks after the start of <span> being removed, that's correct, however the newline on the end tag of <span> are converted into spaces, why?  In this case, you've made that more important than the rule.  E.g. if I write this:

<p><a href="#test">This </a> <a href="#test">Space</a></p>

You've actually rendered it so that the space next to "This " is more important than the space outside of it, in which you remove it (that I'm fine with as I haven't read anything in W3C that suggests anything different).  This makes it appear as a single link though.  It seems end tags are ignored and that these spaces would appear next to each other, which means converting it to a single space, that's quite correct I believe.  But what if I put a newline there instead of the space?  That would mean, the space surrounds a newline and therefore should be removed?  Then that space should be converted to a space, outside the styling, but it's not.

<p><a href="#test">This </a>[\n]
<a href="#test">Space</a></p>

This does the same as the above.  However the newline is removed and the space is kept, with styling, when I would think, the space is removed considering it surrounds a newline and the newline would be converted to a space?

Maybe you just ignore newlines?  and additional spacing just gets converted, I'm not sure, but it seemed it works in some areas, just not when applied to other areas.
> however SGML linebreaks after a  start tag and before an end tag should be
> removed

We don't really implement SGML; implementing this part of SGML would break all sorts of web content.

> You've actually rendered it so that the space next to "This " is more important
> than the space outside of it

Isn't that what the CSS spec I quoted says?  Ian, am I misreading it?  It could really use some examples.  :(
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.