10915 - overflow: hidden doesn't work on positioned elements

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Doyle Davidson]

In M8: Maybe this should be reports as two bugs but:

The "overflow:hidden" style for the outer DIV and SPAN is ignored.  The inner
content is not clipped.

The height or the outer SPAN (id=bands) is ignored as well. Making it a DIV or
a display=block fixes it.  In reading the CSS2, it appears that the "id=bands"
SPAN is a "non-replaced inline element" and therefore "height" does not apply
but "line-height" should.  Which I also set and it does seem to affect the
layout when I change it's value but I still don't see the background-color of
the outer SPAN (ie. pink).  Am I misunderstanding things?

Comment 1

[Doyle Davidson]

Attachment: Example page

Comment 2

[Peter Linss]

Troy, you played with overflow, can you take a look at this?

Comment 3

[troy]

There are several issues here.

As far as the 'height' property and the inline SPAN, yes, 'height' doesn't apply
to non-replaced inline elements.

'line-height' does, but the reason you don't see any pink background color is
that the width of the relatively positioned inline SPAN is 0, and hence there's
nothing to paint pink. The width is 0 because the only children of the SPAN are
the absolutely positioned elements, and they don't influence the span's width
(only the flowed children do).

Cc'ing Peter and David in case they have something to add.

Comment 4

[troy]

I just fixed a problem I recently introduced that was causing none of the
absolutely positioned SPAN elements to show up. Now I see alternating red and
blue boxes.

As far as "overflow:hidden" goes. I think you expect that the absolutely
positioned SPAN element (the last red one) that sticks out on the right will be
clipped. However, I think Gecko is correct and it should not be clipped.

This isn't very clear in the CSS2 spec, but my interpretation is that 'overflow'
applies to flowed content only, and hence doesn't apply to the absolutely
positioned children.

The CSS2 spec when talking about overflow just says "when the content overflows
the element's box", and it isn't clear whether they mean just flowed content or
both flowed and out-of-flow content.

However, everywhere in the spec they refer to "content" and "content area" they
mean flowed content. In particulat 10.6.3 when describing 'auto' height
block-level elements says:

"Only children in the normal flow are taken into account (i.e., floating boxes
and absolutely positioned boxes are ignored, and relatively positioned boxes are
considered without their offset)."

That means the computed value for the content height is for the flowed children
only, and so "content" should refer to the flowed children only as well.

Marking this FIXED, because I fixed the problem with the absolutely positioned
children not displaying correctly

Comment 5

[Peter Linss]

Regarding overflow, I have to believe that all content should be considered,
including relative and absolutely positioned children. This seems obvoius in the
case of 'overflow:scroll' so it should be consistent for 'overflow:hidden'

Comment 6

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

I agree with Peter and am reopening this bug.  Read the beginning of section
11.1 of CSS2: http://www.w3.org/TR/REC-CSS2/visufx.html#overflow-clipping ,
in particular, the fourth item in the bulleted list.

Comment 7

[troy]

This is why I hate the CSS2 spec, it's full of inconsistencies.

Looking at 11.1.2, it says this when talking about <shape>: "... The value
'auto' means that a given edge of the clipping region will be the same as the
edge of the element's generated box (i.e., 'auto' means the same as '0'.)"

The "generated box" isn't defined anywhere, but since the 'height' of a
block-level element is based on its flowed children only (the spec makes this
very clear) then one can assume that the generated box is defined by either the
content area, or border area. Either way that implies that the default clip is
based on the flowed elements only.

11.1 says that "Generally, the content of a block box is confined to the content
edges of the box". That also implies that the default clip is based on the
flowed elements.

Comment 8

[troy]

Marking this REMIND until the CSS2 spec very clearly (and to my satisfaction)
defines overflow and clip and how it relates to out-of-flow elements

Comment 9

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

The 'generated box' does bug me.  Replace it with content edge, I think.

The default clip can be the content edge - and it won't do anything in the
usual case because clip is ignored when overflow is visible.  So setting
overflow to hidden clips to the content edge.  I don't think what you describe
is much of a contradiction.

And don't expect anything to make the CSS2 errata list anytime soon...

What confuses me a little about clip is that clip also seems to be what defines
the size of the scroll region for overflow auto and scroll - which means the
scrollbar should probably be placed inside the padding in the usual case, which
I don't like.

The only things that make me think it is the content edge are the first line in
11.1 and the parenthetical comment in the first sentence of 11.1.1

Comment 10

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

You know, I'm not so sure anymore that it's the content edge rather than padding
edge or border edge.  The intro to 10.1 really doesn't say - it only says that
normally, things don't go past the content edge, possibly only because saying
padding edge or border edge would be a weaker statement.

I think I personally prefer padding edge because of what it says about the
default behavior of overflow: scroll or auto when clip is left to the default.
Legacy UAs might do border edge, but that may be partly because they do what you
do in bug 11559.

Comment 11

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

Removing "  / also SPAN [line-]height is odd." from the end of the title.  CSS2
forgot to say, but CSS1 did, that increasing the line-height doesn't increase
the area colored by the background - you need the padding to do that, which is
drawn around the height given by the font-size.  Inline elements really  have
two properties equivalent to 'height':
 * line-height is used to determine the height of line boxes and thus line
spacing - i.e., how much room the inline element needs
 * font-size is used for backgrounds (plus padding) and borders

Also adding "on positioned elements" to end of title.

Comment 12

[troy]

I think I agree with you that it's the padding edge. That's consistent when
'overflow' is 'scroll' or 'auto' (as you pointed out), and that also seems to
be what the CSS2 spec wants. If you look at the picture in 11.1.1 the content
goes all the way up to but doesn't cover up the red border

Comment 13

[troy]

While we're trying to define 'clip', maybe one of you can explain to me exactly
how 'clip' should work for 'overflow' of 'scroll'? It seems fine to say that the
'clip' defines the visible area when considering the default clip, but what
happens if the user sets the 'clip' property.

I guess it's fine if they reduce the clip and make it smaller. That means the
viewable area is smaller. But if they make it larger so it sticks outside of the
border area, then does that mean that no content is displayed at all, even if
the user scrolls? I would think so

Comment 14

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

Re: comment at 20:47

The figure in 11.1.1 doesn't have any padding.  Don't use it as evidence.

Re: comment at 21:00

From the few hints in the spec, I would have thought that clip defined the
region to be scrolled - that it, its size and what is initially displayed
within the scrollable region.  My biggest problem with this is the bit that
says (roughly): "Note:  future versions of CSS may allow non-rectangular
clipping regions."

I don't know what you mean by "But if they make it larger so it sticks
outside of the border area, then does that mean that no content is
displayed at all, even if the user scrolls?"

Comment 15

[troy]

The figure in 11.1.1 does have a border, though, and that's what I was referring
to. In their picture the border is visible which imples the clip is not relative
to the border edge.

As you point out, it doesn't help answer the question of whether it's padding
edge or content edge relative

Comment 16

[troy]

What I meant by the clip sticking outside the box is this kind of case:
  clip: rect(5px, -5px, 10px, 5px);

Where the right edge of the clip box extends outside of the scrolled element's
right edge. Just lkike the picture in 11.1.2

The P's block box is still the gray area. That's defined by the usual CSS2 rules
for widths of block-level elements. I don't clip should change that. The
scrollbar is within the gray area as well (between the border and the padding)

I wouldn't expect any content to be displayed in the part of the clip region
that extends outside of the gray area.

That was my question

Comment 17

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

Is the scrollbar still within the gray area?  I'm not so sure.  Of course, if it
isn't, how would you explain that the content doesn't overlap the scrollbar in
the normal case?

That is, if the clip is the padding edge by default, then overflow: scroll could
mean "put a scrollbar just inside the clip rect() and then move the padding edge
in to make room for the scrollbar."  But then how is room made if it isn't the
padding edge?  What if it's just a little off?  What if CSS3 includes
non-rectangular clipping regions.

I guess I think the definition of clip should be changed from:

The 'clip' property applies to elements that have a 'overflow' property with a
value other than 'visible'.

to

The 'clip' property applies to elements that have an 'overflow' property with a
value of 'hidden'.

Or is there some way it can apply to overflow: scroll and overflow: auto without
actually forcing the repositioning of the scrollbar (which means that there is
no way to flow text *around* the scrollbar).  Or perhaps should
clip(auto,auto,auto,auto) and clip(0px,0px,0px,0px) be different when overflow
is scroll or auto (and the same when it is 'hidden'), so that 'auto' allows for
reflow around a scrollbar?

Comment 18

[troy]

I think I would be happy with constraining 'clip' so it only applies to
'hidden'. At least in the short term until the many details of how it would work
with 'scroll' and 'auto' are defined

Comment 19

[Hixie (not reading bugmail)]

[Don't mind me, just setting up a radar...]

Comment 20

[Hixie (not reading bugmail)]

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...

Comment 21

[Joe Hewitt]

What is going on with this bug? It makes absolutely no sense not to clip 
positioned children.  I just spend a good 30 minutes digging through specs 
trying to find out why my custom scrollbar class isn't clipping the content, 
only to find this bug.  You guys haven't discussed it in months, and the last 
few posts strayed off topic.  Are you going to fix this bug so that positioned 
elements get clipped, pretty please?

Comment 22

[Hixie (not reading bugmail)]

joe: overflow clipping is a CSS2 issue. We are mainly focussing on CSS1 issues 
for beta1. This is unlikely to get fixed before beta2 unless there is a strong
requirement for this from UE/UI or rendering of legacy content.

UE/UI: User Experience/User Interface team.
legacy content: The Web.

Comment 23

[troy]

joe, you're absolutely right that positioned children should get clipped as 
well. That issue was discussed at last week's CSS face-to-face meeting and it 
was agreed to work that way. This has been an open issue, and these kind of 
CSS issues do take a while to resolve

As far as why it isn't fixed, as Ian indicated, CSS2 is not something we're 
focusing on for beta 1.

The other reason is that the absolute positioning and clip issues are still 
being discussed in the CSS2 WG. There are a number of tricky issues involving 
baclwards compatibility and ambiguities in the spec

I have been waiting for these issues to be resolved before changing the Gecko 
code

Rest assured that no one has forgotten about this issue

Comment 24

[Joe Hewitt]

I'm not quite sure why this isn't considered an urgent issue. I am also 
confused as to why clipping didn't show up in the CSS1 spec.  It's a fairly 
important capability to have when you are talking about doing layout with 
DHTML.  NN4, IE4, and IE5 support clipping, and it is used heavily by just 
about everyone who uses DHTML, and who's to say you can only clip things if 
they are relatively positioned?  This seems painfully obvious to me, I don't 
know why it's a lingering issue in the W3C after all these years.  By the way, 
overflow: scroll does in fact clip the positioned elements, it's just overflow: 
hidden that lets them peek through.  Ok, sorry about all the complaining ;)

Comment 25

[Robert Crawford]

I would like to voice a note of urgency wrt this problem. Ihave read the
dicussion and understand that CSS2 issues are generally being delayed. But this
is such a critical bug!
Scrolling works so well, and hidden not at all! Going to beta while
http://127.0.0.1/lab/ex_css1b.html fails but http://127.0.0.1/lab/ex_css2a.html
works so well seems needless. Moving boxes around is CRUCIAL for basic DHTML...
If spec-clarification is needed, in the interim, could'nt somebody just clone
the clip:scroll code and just remove the scrolling? Provide the 'expected'
clipping behavior, while awaiting clarification of the actual spec? (Easy to
say, since I'm not a c-coder. Sorry if this seems like a rant.)

Comment 26

[Robert Crawford]

Um, make that
http://w3cdom.com/lab/ex_css1b.html   fails miserably..
http://w3cdom.com/lab/ex_css2a.html   works..
I'd also like to mention that box-sizing was implemented due to "spec trouble", 
and that is CSS-3.

Comment 27

[troy]

The clipping problem is now fixed so I'm marking this bug as FIXED

Comment 28

[Christine Hoffman]

Using the 3/15 testcases with the 7/18 build, verifying bug fixed. Overflow: 
hidden working on positioned elements

Comment 29

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ea329e4e7937
[fenix] For https://github.com/mozilla-mobile/fenix/issues/10915: Disabled failing UI tests in SettingsPrivacyTest
https://hg.mozilla.org/integration/autoland/rev/70f3934b1c2c
[fenix] For https://github.com/mozilla-mobile/fenix/issues/10915: fix tests by removing existing session