Closed Bug 20948 Opened 25 years ago Closed 24 years ago

overlapping textareas are incorrectly layered

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: ian, Assigned: kmcclusk)

References

(
URL
)

Details

(Keywords: css2) 

HOW TO REPRODUCE:
   Overlap two DIVs both of which contain TEXTAREAs. See test case:
   http://www.bath.ac.uk/%7Epy8ieh/m/pos-textarea-zindex.html

WHAT OCCURS:
   Where the textareas overlap, they fight for control over who is on
   top (the last one which was forced to redraw wins...).

WHAT SHOULD HAPPEN:

   What should happen is that in the background, there should be a red
   box and a blue box, overlapping. Each one should have a (white) box
   (with an inset border) at the top left corner, with scroll bars.

   The _text_ from the text areas should overlap the boxes.

   That is, the "this is the first text area" sentences should visibly
   overlap the "this is the second text area" text. But only over the
   area that the text area covers.

This is because the textareas are 'position:static' and all the boxes are
'z-index:auto', so there is only one staticking context, and all the boxes in
it are at the same z-positon, and within a stacking context, boxes with the
same z-index should be made to overlap with backgrounds below and text above.

The DIVs in the second section of that test case show that this is not happening
even for ordinary elements. This is probably due to 'position' implying some
sort of non-auto value for z-index, or just general bugginess in the 'z-index'
code. See bug 3502 and bug 7774. Note, however, that this bug is INDEPENDENT of
z-index bugs -- THE BUGS FILED HERE IS NOT A Z-INDEX BUG! It is a bug with how
TEXTAREAs negotiate "who should be on top".


Note: Once all that works, adding the following to html.css should make the
TEXTAREA behaviour slightly more sensible:

   textarea {
      position: relative;
      z-index: 0;
   }

...since it would then make textareas start their own stacking context and so
the text in them would not want to overlap anything.

I'm cc'ing David, he is bound to see at least a dozen errors in the above.
I'm also cc'ing the original reporter who posted to a mozilla ng with this.
Thanks Pascal!
This was something I was wondering about when looking at a previous bug.

Ian, it sounnds like you're saying that within a given stacking context _all_
backgrounds render first and then content is rendered in the next pass.

Looking at the DIV example, you _don't_ want to see the blue drawn along the top
because it should be displayed underneath the text in the red DIV?

I believe this is kind of what Kipp had done (not for absolute positioning
however), but where does the CSS2 spec say it should work this way?

I can't find the part of the spec that says this.
The spec doesn't say it, but it can be derived from the rules on stacking order
around floats given in 9.5 or 9.5.1 (although some people say that the spec
leaves it ambiguous).  I was unable to load Ian's test case, though, but I think
I can guess what it contains.  I think the rule he suggests for html.css is a
good idea.
It doesn't really jump right out at me when I read 9.5.1 and 9.5.2

At some point when I have some time I would like us to clarify exactly how
this should work. Kipp seems to have known, but now that he's gone I don't know
that anyone (including me) does
Status: NEW → ASSIGNED
Would a rule like

textarea:focus {
  z-index: 1;
  }

be bad?  It wouldn't make too much sense when other elements had z-indices,
though.
Troy wrote:
> Ian, it sounnds like you're saying that within a given stacking context _all_
> backgrounds render first and then content is rendered in the next pass.

Right.

Some www-style posts of relevance are:
   http://lists.w3.org/Archives/Public/www-style/1999Sep/0064.html
   http://lists.w3.org/Archives/Public/www-style/1999Sep/0067.html

David wrote them, so they will be a lot more coherent than any explanation
that I could come up with... ;-)

Basically, buried in the middle of section 9.5 is a line that says:

# A float can overlap other boxes in the normal flow (e.g., when a normal flow
# box next to a float has negative margins). When an inline box overlaps with a
# float, the content, background, and borders of the inline box are rendered in
# front of the float. When a block box overlaps, the background and borders of
# the block box are rendered behind the float and are only be visible where the
# box is transparent. The content of the block box is rendered in front of the
# float.

But if this is to happen, then when you remove the float then surrounding
blocks will have their backgrounds/borders drawn under their inline content.
(Or how else could you do it?) Look at the behaviour in the test case, and
try to see how a float would fit in between it all. It would have to have its
background above the background of the DIVs and the TEXTAREAs, but _below_ the
text that they contain. But if that happens, then when you remove the float the
text of the TEXTAREAs and the DIVs should still be above their backgrounds.

If we already do this for position:static, then it 'should' be a 'non-issue' to
get this to work with positioned elements with z-index:auto... getting the GFX
elements to do this correctly may not be so obvious though, if they have lots
of 'proprietary' code (by which I mean, not generic NGLayout box code).

Note, though, that all that will probably go away by itself the moment that
z-index is correctly implemented. The main issue being z-index:0 != z-index:auto
and we get this wrong. See bug 7774.


David: Yeah, that rule would be cool, but I have a feeling that it would
interact badly with any z-index rules in author stylesheets... Hmm...

In the test case (BTW, can you get it now?) the author would probably give a
value of z-index to both DIVs at once, so then z-index on TEXTAREA would be
absolutely no help. If they don't, then yeah, it would work... Hmm...

No, I think it would be better for the authors to include that rule. It would
probably annoy people in the same way as the explicit color and font rules on
table elements do. (Far fewer people, of course, but...)

I think the fewer exotic rules in html.css the better, basically.
Keywords: css2
Migrating from {css2} to css2 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...
Summary: {css2} overlapping textareas are incorrectly layered → overlapping textareas are incorrectly layered
Target Milestone: M15 → M17
pushed out to M19.  Windowless widget work is coming along slowly, not a top 
priority.
Target Milestone: M17 → M19
Reassigning to buster@netscape.com. Triaging Troy's bug list.
Assignee: troy → buster
Status: ASSIGNED → NEW
redistributing bugs across future milestones, sorry for the spam
Target Milestone: M19 → M21
Kevin: dup of one of your bugs, no?
Assignee: buster → kmcclusk
How often are we likely to see this problem in actual content on the Web? Do we 
need to fix this for FCS or can with live with this problem without fixing?
This was fixed when I removed the widget used by the ender-lite widget last 
week.

Marking fixed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Looks fixed in the July 14th builds.
Status: RESOLVED → VERIFIED
Looks fixed in the July 14th builds.
You need to log in before you can comment on or make changes to this bug.