first inline(-block?) child of an inline element rendered with a +4px margin-right

RESOLVED INVALID

Status

()

RESOLVED INVALID
10 years ago
10 years ago

People

(Reporter: a.dead.trousers, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

24.00 KB, image/jpeg
Details
334 bytes, text/html
Details
(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3

Hard to explain! I will attach a example-file!


Reproducible: Always

Steps to Reproduce:
1. Just download the attached file and see for yourself!
2. Try to variate the lines in the style-sheet I commented out. 
Actual Results:  
Looking at the red-outline I provided you will see that there is a gap at the first picture while there is none at the other two.

Expected Results:  
No gap at the first picture and also no gap at the others.

I don't know if this problem is already reported. It's hard to find something that specific ;)
I also don't know if I did somthing wrong, but IMHO I don't expect this behaviour is right.

I think you can imagine that english is not my native language, so if there something unclear just ask for a better explanation.
(Reporter)

Comment 1

10 years ago
Created attachment 345143 [details]
A sample HTML file with CSS-Stylesheet
(Reporter)

Comment 2

10 years ago
Created attachment 345144 [details]
screenshot of false rendering

Just in case for you to see if you aren't able to reproduce!

Comment 3

10 years ago
Thanks for reporting. However, this is no bug. You're using a very complex markup and style for a rather easy task.

Here's the problem: From a CSS piint of view you got 
<inline>
 <inline-block/>
</inline>

In this case, the white space (the line break) between <inline-block/> and </inline> collapses and "becomes" part of the content the inline-block. Because there's another inline-block in the element (240px wide) the white space is rendered next to it which eventually results in additional right space.
Selecting the text would've shown you the issue ;)

A workaround is to use inline-block as well for the picture class or to remove the linebreak between </a> and </div>.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
Daniel, it sounds like the reason you marked this bug as worksforme is really because you're claiming it's invalid, not because you're claiming it works for you.

Based on your explanation, I'm not entirely sure that it is invalid.  A simpler testcase would probably be useful, though; I haven't downloaded and opened up the zip.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---

Comment 5

10 years ago
Created attachment 357495 [details]
small testcase

(In reply to comment #4)
> Daniel, it sounds like the reason you marked this bug as worksforme is really
> because you're claiming it's invalid, not because you're claiming it works for
> you.

Sadly that'd be typical for me. 

> Based on your explanation, I'm not entirely sure that it is invalid.  A
> simpler testcase would probably be useful, though; I haven't downloaded and
> opened up the zip.

The reporter used the span here as container for image and text. The only difference is that he had a line break between </a> and </span>.

Our behaviour is consistent with IE(quirks+strict), Safari and Opera. CSS 2.1 says:

 "If a space (U+0020) at the end of a line has 'white-space' set to 'normal', 'nowrap', or 'pre-line', it is also removed."

I simply didn't think of the space in front of </span> as end of a line.
Attachment #345143 - Attachment is obsolete: true

Comment 6

10 years ago
(In reply to comment #5)
> CSS 2.1 says:
> 
>  "If a space (U+0020) at the end of a line has 'white-space' set to 'normal',
> 'nowrap', or 'pre-line', it is also removed."
> 
> I simply didn't think of the space in front of </span> as end of a line.

Ditch that. Of course </span> wasn't even the end of the line.
(Reporter)

Comment 7

10 years ago
hi!

(In reply to comment #5)
> Our behaviour is consistent with IE(quirks+strict), Safari and Opera. CSS 2.1
> says:

When I open the file in IE (7.0) the gap isn't rendered, that is why I reported this "bug". I allways do a double (or tripple with Opera) test of the webpages i create to be sure they look (nearly) the same.

The main problem with the output is that its not as easy to control:
The whitespace between </a> and </div> is rendered by a XSLT-Processor using hierachical-indent.

I understand that this is not that "big" kind of a bug and I also found a workaround for this but compared with IE the output looks different...
...Ok, it'll allways look different ;)

wkr
ADT

P.S.: I don't know if the "bug" now can be considered "closed" so I leave it open. Maybe someone dares to fix this. If not, any admin is free to close the bug.

Comment 8

10 years ago
(In reply to comment #7)
> When I open the file in IE (7.0) the gap isn't rendered, that is why I
> reported this "bug". I allways do a double (or tripple with Opera) test of
> the webpages i create to be sure they look (nearly) the same.

I was referring to my testcase. In your case, IE differs, but that is a bug with IE, that will be fixed in IE8.

> I understand that this is not that "big" kind of a bug and I also found a
> workaround for this but compared with IE the output looks different...
> ...Ok, it'll allways look different ;)

Well, as I said you're using rather complex code. Maybe you should consider to remove one or two classes.

> P.S.: I don't know if the "bug" now can be considered "closed" so I leave it
> open. Maybe someone dares to fix this. If not, any admin is free to close the
> bug.

David, my explanations were horribly complex, sorry.
The problem is simply that there are only inline(-block) elements concerned here. The problematic white space here is the same that'd appear if you write "a
b" in your source and get "a b" (instead of "ab").

So I'd say Invalid with your approval.
Yeah.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.