Closed Bug 55104 Opened 24 years ago Closed 24 years ago

Remove support for 'position:fixed' in CSS parser and DOM

Categories

(Core :: Layout, defect, P1)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: ian, Assigned: pierre)

References

(
URL
)

Details

(Keywords: dataloss, helpwanted, Whiteboard: [branch only], [rtm++]) 

nsViewManager2 has many serious shortcomings. Although we have a comprehensive 
fix (in bug 39621), it is deemed too risky to make NS6. 

One of these major shortcomings is our total inability to handle transparent
fixed positioned views. This is a CSS2 feature not currently supported by any
browsers apart from Mac IE5.

I propose that we remove our DOM and CSS parser support for this value. 

   * Our support is useless. Authors can only use our fixed positioning
     support in some edge cases (transparent positioned views are by far
     the most common).

   * If we do not disable it, then we are preventing authors from using
     fixed positioning for as long as N6 is on the market. We should not
     be in the business of purposfully killing standard's features.

   * If we do not disable it, we are going to make it difficult for us
     to fix the problems in the future.

   * This is low risk -- removing support like this is a very well understood
     operation that we have already performed a few times in the past. No
     critical code is affected (in particular, the positioning code is left
     quite alone).

See bug 54043 for more details.

Nominating this for RTM. This is for the RTM branch only.
Keywords: correctness, rtm
Priority: P3 → P1
Whiteboard: branch only
Target Milestone: --- → M18
Does our chrome use fixed positioning at all? If so, we might have to make a
-moz-fixed value for the position property. CC'ing hyatt for a chrome/UI
perspective on this issue.

It is my understanding that XUL doesn't support positioning at all anyway.
If anyone _is_ depending on our fixed positioning support, I would be very
surprised, considering how broken it is without Robert's nsViewManager.
Assuming that we're certain this won't break the product, I support the proposal 
to remove functionality that's not working for the first release. However, we 
may need to find a mozilla community volunteer to implement the change given the 
demands on Netscape engineering staff. Or, Ian, Robert, is this something you 
could take on? Marking helpwanted.
Keywords: helpwanted
Not I; I've never done anything like this. dbaron has though.
What is broken exactly? Do you have a testcase? Why are transparent fixed 
positioned views so much more common than regular fixed positioned views?

I'm relunctant to answer the request of completely disabling fixed positioning 
without explanation.

If I understood Ian correctly, I thought he felt that our support for fixed 
positioning was broken in serious ways whether or not the positioned element 
happened to be transparent. Therefore he was arguing that we should take out 
all support for fixed positioning for the first release. I could have 
misunderstood, however. Ian?
I disagree with Ian that fixed positioned elements are much more common with 
transparent backgrounds. I would say the opposite: I think that almost all fixed 
positioned elements will have a non-transparent background and will not be 
impacted by this bug. In fact, this testcase is the first page I see with 
transparent fixed positioned elements. The other common test pages like Test11 
(resource:///res/samples/test11.html) or Ian's own page
(http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/position/fixed1.html) have 
non-transparent backgrounds.

In my opinion, fixed positioned elements will be mainly used to build floating 
buttons, toolbars or sidebars, headers or footers, and they will have their own 
background in order to make them stand out of the normal scrolling page.

So you are willing to prevent the use of transparent fixed positioned elements
on the web for as long as N6 is on the market? I did not know we were in the
business of creating yet another standards-incompliant legacy.
It appears that Pierre and I have differing opinions about how common
transparent fixed positioned elements are likely to be. This is not an arguable
point, on either side of the fence, since we have no data.

However, I do not really wish to play russian roulette (as it were) with the
standards -- there is strictly _no reason_ to support fixed positioning in 
this release, and our current support is very buggy for the default case. 
(That _is_ an arguable point: Background defaults to transparent, and we do not 
do this right for fixed positioned elements.)

Why should we keep this in the product? Is there any reason to do so? I posit
that any harm done in removing this support will be considerably less than the
harm done if we ship with this buggy feature enabled.
Changed the Summary line to "Fixed positioned elements should support transparent 
backgrounds" from "Remove support for 'position:fixed' in CSS parser and DOM". 
I'll look into it to make sure that the problem is indeed related to the 
ViewManager2 and bug 39621. It could be just a problem with the background custom 
rules.

In the meanwhile, if someone could think of a real-life application that:
1) has some use for transparent backgrounds in fixed positioned elements, and
2) would become relatively impaired if the backgrounds were not transparent...
I can't think of any right now.
Summary: Remove support for 'position:fixed' in CSS parser and DOM → Fixed positioned elements should support transparent backgrounds
The fixed positioned elements background could be the same one as the canvas 
background which has an unknown origin (see bug 19329).

There is already at least one bug for "fixed position elements should support 
transparent background", bug 4209. I already investigated, found the problem 
(it's in the view maanger), and produced a fix, but the fix was rejected for 
NS6, so now we're here trying to figure out what to do for NS6.
So Pierre, please change the summary back.
Ok, restored the summary and marked the dependencies.
Depends on: 4209, 39621
Summary: Fixed positioned elements should support transparent backgrounds → Remove support for 'position:fixed' in CSS parser and DOM
Ok, a real life example: the W3C have a fixed positioned links bar on their 
pages (see, for example, http://www.w3.org/Style/ ). It used to have rounded 
corners, but this caused Mozilla to display white instead of being transparent,
because of bug 4209. The rounded corners were removed.

This is the only REAL LIFE (non-demo, non-test) use of fixed positioning I am 
aware of, and it ran into this bug!!!

So on a basis of past real life cases, 100% of uses of fixed positioning are 
going to run into this problem.
URL: http://www.w3.org/Style/
Typical example of what I was saying... The fact that the bits of background near 
rounded corners are not transparent doesn't impair the interface to the extent 
that justifies to cut the feature. On the contrary, the interface would have been 
seriously impacted if 'position:fixed' had been ignored.

If we cut the feature, we'll force everybody who needs fixed positioned elements 
to sniff the browser ("6.01, yes - 6.0, nope"). If we leave the feature, only 
those whose pages are relatively impaired by the lack of transparent backgrounds 
on fixed elements will have to do it, but the fact is: I can't think of any 
practical cases.

This leads to an additional question besides the previous one about relatively 
impaired real-life interfaces: if we decide to ignore 'position:fixed', what 
alternative do we offer to those (IMO: close to 100%) who need fixed elements 
with a non-transparent background?

> Typical example of what I was saying... The fact that the bits
> of background near 
> rounded corners are not transparent doesn't impair the
> interface to the extent 
> that justifies to cut the feature. On the contrary,
> the interface would have been 
> seriously impacted if 'position:fixed' had been ignored.

No, it wouldn't, since no other browser (except Opera) supports fixed 
positioning. I used to use

div.foo { position: absolute; top: something; left: something; }
div.foo { position: fixed; }

And it worked fine in all browsers (and would work fine in a CSS 2 browser), 
but had to remove the last rule because of Mozilla (this bug). If fixed 
positioning isn't working, remove the buggy support. Please ...
All I'm asking for is a real-life application that is impaired by a non-
transparent background. Everything I have seen so far are academic scenarios and 
authoritative requests. Let's try to solve real problems for real people, please?

Pierre: THERE ARE NO REAL LIFE SITUATIONS. The only browsers that do this 
right have marginal market share. (MacIE 5, Opera). Web authors have not yet
tried to implement this except at the very bleeding edge (W3C's site, which was
changed after seeing our bug, proving my point!).

At the moment, authors can use fixed positioned and absolute positioning safely,
without any problems, by doing

   position: absolute; position: fixed;

This will work fine on Opera and will work fine on MacIE and will work fine in 
Windows IE, some of which support fixed positioning and some of which do not.

HOWEVER. If we leave our buggy support in, then people will have to special-case
around NS6. The *only* time people will have to browser-sniff is if we leave
this in!

This is not a new argument! We used the same argument for renaming 'outline' to
'-moz-outline', for removing 'inline-table' support, for removing support for
the 'counter' functions, for removing 'run-in' and 'compact' support, etc. 

Why is this any different?!


> if we decide to ignore 'position:fixed', what alternative do we offer to 
> those (IMO: close to 100%) who need fixed elements with a non-transparent 
> background?

Absolute positioning, just like in Windows IE and N4.


> If we cut the feature, we'll force everybody who needs fixed positioned 
> elements to sniff the browser ("6.01, yes - 6.0, nope"). 

No we won't, because CSS is designed to work in this forward compatible way. 
We will only force people to browser-sniff if we leave this buggy feature in.


> All I'm asking for is a real-life application that is impaired by a non-
> transparent background. 

I have given you one! The only case of fixed positioning I am aware of on the
entire web had a problem with this and was changed!

Ok, here are more examples:
   * Overlaid decorations, such as a transparent MNG of a flying butterfly.
     This has never before been possible, and will be as soon as we use the
     fixes to the bugs with nsViewManager. 
   * Overlaid watermarks, such as a big 'SPECIMEN' sign.
   * The default cause of just positioning some text without specifying a 
     background (this is the default!).
   * Positioning a title at the top of the window, like this:
        body { margin-top: 3em; background: green; color: white; }
        h1 { position: fixed; top: 0; left: 0; right: 0; font-size: 3em; }
     Oops, this just became a perceived dataloss bug (white on white text!)

What more examples do you want?
Keywords: dataloss
I'll give you another "real life" example: Viewer test #11. If you make the 
window narrow, the links at the top wrap around, and because their container is 
"overflow: visible" (the default), they stick out over the body. It's still 
quite usable with the working view manager, but in NS6 the overhanging links get 
a white background so you can't read the text underneath them.
All I was asking for were compelling reasons to cut a feature because the extra 
pixels at rounded corners don't justify it, and absolute positioning doesn't 
always replace fixed positioning. You gave me two which are valid and are likely 
to get that bug approved:
- overlaid decorations and watermarks,
- fixed positioned elements over a colored background result in a ugly display, 
an possibly a data loss.


Index: nsCSSProps.cpp
===================================================================
RCS file: /m/pub/mozilla/layout/html/style/src/nsCSSProps.cpp,v
retrieving revision 3.37
diff -r3.37 nsCSSProps.cpp
509c509,510
<   eCSSKeyword_fixed, NS_STYLE_POSITION_FIXED,
---
> //  bugs 55104 and 4209: remove fixed positioning from the RTM branch 
> //  eCSSKeyword_fixed, NS_STYLE_POSITION_FIXED,


Marked rtm+. PDT, please approve.
Status: NEW → ASSIGNED
Whiteboard: branch only → [branch only], [rtm+]
Thanks Pierre.

Marc: Could you review please?
Robert: Could you super-review please?

PDT: As explained above, this is a serious forwards compatibility issue, and has
the blessing of the module owner and ekrock.
The patch looks fine for the CSS parser, but what are we doing about the DOM?
sr=roc

You'll need a different super-reviewer for the DOM, I know nothing about it.
[rtm-]. Time to focus on crash and data loss bugs (yes, I read the part about
perceived data loss)
Whiteboard: [branch only], [rtm+] → [branch only], [rtm-]
I find some decisions from the PDT team arbitrary and rather infuriating. This 
bug is a typical example: I knew it would be a 1-line fix with no risk so I 
played the devil advocate and insisted that the proponents of cutting the fixed 
positioning give the proof that it would have a real impact on web designers with 
no workaround, not to mention the standard compliance aspect of it.

Back to rtm+ for reconsideration. Seriously, any time saved by not checking in 
this 1-line fix may very well be outweighted by additional appeals of the 
decision and the growing exasperation of the persons who participated to the 
debate on that bug (well... not me, of course: I think I already made my point 
quite clearly :-P ).

There is no problem with the DOM: if the property/value pair can't be parsed, the 
DOM can't change it (see nsDOMCSSDeclaration::SetPosition).
Whiteboard: [branch only], [rtm-] → [branch only], [rtm+]
There is also the fact that any time saved by not checking this in will probably
be far out-weighed by the amount of time that will have to be spent in the 
future clearing the resulting mess up -- just look at the amount of time we've
spent trying to clear up the browser sniffing problems for this release, and
now project that to the next release. Ouch.
Pierre, given your comment re: the DOM, r=attinasi
Marking rtm-minus.  Sorry... it is too late for NS 6 branch.  We are having to
clear too many critical crashers and regressions at this point.
Whiteboard: [branch only], [rtm+] → [branch only], [rtm-]
I don't see the relation between the bugs they're talking about and this one but 
what else can I do? Closed as WontFix.

IanH, Dbaron & Roc+Moz: your status of external contributors, invited experts 
and/or web standards watchers may give you a freedom and especially a leverage 
that I don't have to insist on having that fix checked into the Netscape branch. 
You may want to contact brendan@mozilla.org who is a more poised person when it 
comes to purely technical decisions, and then lobby jar@netscape.com and 
phil@netscape.com. Try a petition from the CSS Samurais
(http://www.webstandards.org/css/members.html)... After all, you already have the 
support of Netscape's own CSS WG reps!
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
ekrock: Do you want to escalate this one at the PDT mtg along with bug 53974?
This was deemed rtm++ at Friday's PDT meeting -- reopening, marking as such and
cc'ing jar and phil to make sure that's ok.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Whiteboard: [branch only], [rtm-] → [branch only], [rtm++]
Right, we agreed rtm++ on this, but any future changes will need to be
topcrash/data loss.
There aren't many examples of people using this in the wild, but it isn't for
lack of trying.  As a page author, I would *love* to use position: fixed to keep
my navigational controls in view without resorting to frames.  Other uses are
clearly obvious.
Which is exactly why we should disable it -- if we leave it in then you won't
be able to use it (without browser sniffing) for as long as N6 is on the market,
since it is so broken, but if we take it out then you'll be able to use it
safely the moment we release the next (fixed) version. (jwb: ask me on #mozilla 
if you want to discuss this...)
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Checked into the RTM branch only. Must not be fixed into the trunk.
Marking fixed.

I'll notify Jud that this should be fixed in his branch too.

Changing QA contact
QA Contact: petersen → chrisd
Status: RESOLVED → VERIFIED
This was verified on both branch and trunk (to make sure it wasn't checked in)
by almost the entire Mozilla community after I got everyone to check the testcase
under false pretenses. VERIFIED on all platforms. Mwuhahahahahahaha!

Thanks again for checking this in, Pierre.
You need to log in before you can comment on or make changes to this bug.