303558 - [pixel-rounding] improper rendering (a:hover position:relative left:0.05em)

Status: RESOLVED WORKSFORME

(Core :: Layout: Positioned, defect)

Description

[Ivan Ičin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050803 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050803 Firefox/1.0+

Using the following CSS rules cause troubles in many cases:

a:hover {
position: relative;
left:0.05em;
top:0.05em
}

Generally speaking, some links doesn't move at all to right or to down. Links
with anchor text that spreads accross several lines acts wierd on hover, so that
every line moves at its own direction.

It is fairly hard to make code that causes this. I have a simple testcase for
the first mentioned case. For the multiline case I can't make simple testcase,
and the page that doesn't work is currently on my disk, I can upload it here if
you want.

Reproducible: Always

Steps to Reproduce:
see the case.



This is very sensitive. For example, changing left to 0.1em may remove some
artifacts. Also, changin anchor text may remove artifacts.

Comment 1

[Ivan Ičin]

Attachment: testcase for the bug

Comment 2

[Adam Guthrie]

I think this is the expected behavior according to the specs:
http://www.w3.org/TR/CSS21/visuren.html#propdef-left

I'm guessing that if there's not enough room to the right of the element, it's
not going to move.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I don't see how this has anything to do with the spec URL in comment 2.

In any case, this seems like a rounding "bug".  For me, the second link is the
one that doesn't move at all, but none of the links move vertically.  If you
want the links to move 1 pixel, you should specify 1px, not something that
rounds to a little less than 1px and therefore sometimes means 1 pixel of
movement and sometimes none.  Potentially we could round all 'left',etc. values
to the nearest pixel before adding them to other (unrounded) values, but that
would only work if this were the typical use case.  That would cause serious
problems with other use cases, like percentages that are supposed to add up to
100%.  So I think this is probably WONTFIX.

Comment 4

[Ivan Ičin]

(In reply to comment #3)
> I don't see how this has anything to do with the spec URL in comment 2.
> 
> In any case, this seems like a rounding "bug".  For me, the second link is the
> one that doesn't move at all, but none of the links move vertically.  If you
> want the links to move 1 pixel, you should specify 1px, not something that
> rounds to a little less than 1px and therefore sometimes means 1 pixel of
> movement and sometimes none.  Potentially we could round all 'left',etc. values
> to the nearest pixel before adding them to other (unrounded) values, but that
> would only work if this were the typical use case.  That would cause serious
> problems with other use cases, like percentages that are supposed to add up to
> 100%.  So I think this is probably WONTFIX.

Internet explorer and Opera do this correctly, so it is possible to render it
correctly. Probably you should keep it NEW, at least until you are sure that
there is no reasonable way to fix this.

Just to note that in testcase I didn't include top:0.05em as it has no effect
for this testcase, it could be buggy, but in other cases.

(In reply to comment#2)
> I think this is the expected behavior according to the specs:

If what you say is true then this is more serious bug, as it is much easier to
make testcase where the last element moves to the right.

Comment 5

[klonos]

I see this fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090420 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090420041629

In the testcase, the forth link also moves slightly to the right like the other 3. So, fixed then?

Comment 6

[Ivan Ičin]

(In reply to comment #5)
> I see this fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> rv:1.9.2a1pre) Gecko/20090420 Minefield/3.6a1pre (.NET CLR 3.5.30729)
> ID:20090420041629
> 
> In the testcase, the forth link also moves slightly to the right like the other
> 3. So, fixed then?

I agree

Comment 7

[Jason Bassford]

No bug or patch referenced as the code fix.