Note: There are a few cases of duplicates in user autocompletion which are being worked on.

mozilla does not handle background-position: <absolute> center

RESOLVED FIXED in mozilla1.7final

Status

()

Core
CSS Parsing and Computation
P2
normal
RESOLVED FIXED
14 years ago
14 years ago

People

(Reporter: Tomas Muller, Assigned: Christopher Aillon (sabbatical, not receiving bugmail))

Tracking

Trunk
mozilla1.7final
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [css2.1])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030916
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030916

Look at the URL demonstrating the problem. I was using ver 1.4b at first, but
when I read "Also, please do not file bugs on copies of Mozilla older than two
weeks." I downloaded the new rc of 1.5 and the problem is just the same. See
http://sklad.hujer.cz/mozbug/azlan/css/index.css for the css definition:
ul.whatsUp li. Please note that this is a bussiness page; I should not be
letting it out yet. I just don't have time at the moment to play around with
this bug :-/ The background- properties are split up here, if I defined them as
a shorthand backround: ... property, i have had problems with Opera7 and IE6
displaying the backround differently - horizontally centered and
12(whatever)pixels from the top and vice versa. Mozilla didn't display anything.

Reproducible: Didn't try

Steps to Reproduce:
1.
2.
3.
absolute lengths could not be mixed with keywords in CSS2.  I think they can in
CSS2.1, but that's a very recent decision and hasn't been implemented yet.
(Reporter)

Comment 2

14 years ago
Well you're right, I did not pay enough attention reading the specs. Sorry. I
just put 50% instead of 'center' keyword and it works fine.
(Reporter)

Comment 3

14 years ago
Therefore I resolve this "bug" changing its resolution to INVALID. But I think
that the spec-makers could allow this. They go like 'center' is the same as
'50%' and then people like me get confused :)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → INVALID
Reopening.  It is allowed by a revision of the spec that came out on Monday (but
is currently still a draft).  But we haven't exactly had a chance to implement
that yet.  However, this bug would be a good reminder to do so.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
(Reporter)

Comment 5

14 years ago
Fine :) Just note that I've deleted the example pages since we all know what's
going on.

Comment 6

14 years ago
Is this part of CSS2.1 stable enough that I'd be safe with implementing this?
I would guess yes. We discussed this at some length to get the current concensus
and I don't recall anyone raising an issue on it since then.
Well, I still don't like it, but whatever...
Actually, never mind.  I was thinking of something else.  Go ahead...

But note that the grammar is wrong and the prose is somewhat unclear.  ("If two
values are given" means "percentage or length values".)
Grammar issue noted as issue 228. I disagree with the prose issue, since the 
paragraph starts "If only one percentage or length value is given, it sets the
horizontal position only, and the vertical position will be 50%. If two values
are given, the horizontal position comes first." so IMHO it is clear that "two
values" still refers to "two percentage or length values".
See:
http://www.w3.org/TR/2004/CR-CSS21-20040225/colors.html#propdef-background-position
Assignee: dbaron → caillon
Status: UNCONFIRMED → NEW
Ever confirmed: true
http://www.hixie.ch/tests/adhoc/css/background/position/002.html
http://www.hixie.ch/tests/adhoc/css/background/position/003.html
Status: NEW → ASSIGNED
Created attachment 143314 [details] [diff] [review]
Patch
Attachment #143314 - Flags: superreview?(dbaron)
Attachment #143314 - Flags: review?(dbaron)
Comment on attachment 143314 [details] [diff] [review]
Patch

>+      PRInt32 xValue = values[4].GetIntValue();
>+      PRInt32 yValue = values[5].GetIntValue();
>+      if (eCSSUnit_Enumerated == xUnit) {
>         if (eCSSUnit_Enumerated == yUnit) {
>-          PRInt32 xValue = values[4].GetIntValue();
>-          PRInt32 yValue = values[5].GetIntValue();

I changed that to:

>+      if (eCSSUnit_Enumerated == xUnit) {
>+        PRInt32 xValue = values[4].GetIntValue();
>         if (eCSSUnit_Enumerated == yUnit) {
>           PRInt32 yValue = values[5].GetIntValue();

and added a local declaration of yValue in the |if (eCSSUnit_Enumerated ==
yUnit)| clause contained by the else portion of |if (eCSSUnit_Enumerated == xUnit)|.
Created attachment 143446 [details] [diff] [review]
Updated patch
Attachment #143314 - Attachment is obsolete: true
caillon: the issue you raised (what if only one keyword is given) is actually
already covered by the spec in the list of possible value combinations before
the paragraph you mentioned.
Attachment #143446 - Flags: superreview?(dbaron)
Attachment #143446 - Flags: review?(dbaron)
Attachment #143314 - Flags: superreview?(dbaron)
Attachment #143314 - Flags: review?(dbaron)
OS: Windows XP → All
Priority: -- → P2
Hardware: PC → All
Whiteboard: [css2.1]
Target Milestone: --- → mozilla1.8alpha
Summary: It seems that mozilla does not handle background-position: <absolute> center; value properly on li elements on this page. → mozilla does not handle background-position: <absolute> center
Comment on attachment 143446 [details] [diff] [review]
Updated patch

>   if (0 != (found & 0x30)) {  // found one or more position values, validate them
>     if (0 == (found & 0x20)) {  // x value only

This comment ("x value only") isn't correct (and never was).

>       else if (eCSSUnit_Inherit == values[4].GetUnit()) {
>         values[5].SetInheritValue();
>       }
>       else if (eCSSUnit_Initial == values[4].GetUnit()) {
>         values[5].SetInitialValue();
>       }

These are unnecessary.

r+sr=dbaron
Attachment #143446 - Flags: superreview?(dbaron)
Attachment #143446 - Flags: superreview+
Attachment #143446 - Flags: review?(dbaron)
Attachment #143446 - Flags: review+
(And sorry for the delay.)
Comment on attachment 143446 [details] [diff] [review]
Updated patch

dbaron suggested this would be good to land in 1.7, so seeking approval.
Attachment #143446 - Flags: approval1.7?

Comment 20

14 years ago
Comment on attachment 143446 [details] [diff] [review]
Updated patch

a=asa (on behalf of drivers) for checkin to 1.7
Attachment #143446 - Flags: approval1.7? → approval1.7+
Checked in 2004-04-09 22:08 PDT.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago14 years ago
Resolution: --- → FIXED
(this is in for 1.7final)
Target Milestone: mozilla1.8alpha → mozilla1.7final
You need to log in before you can comment on or make changes to this bug.