[css-overflow] A question about overflow-x and overflow-y

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[css-overflow] A question about overflow-x and overflow-y

Joe Gu
Hi,

According the spec, for the same element, the computed values of these two props cannot be visible+hidden at the same time. Does anybody know why it is designed this way? Or it's just because of compatibilities?

Thanks!

---

GU Yiling (Justineo)
Reply | Threaded
Open this post in threaded view
|

Re: [css-overflow] A question about overflow-x and overflow-y

Florian Rivoal-4

> On May 30, 2016, at 18:24, Justice <[hidden email]> wrote:
>
> Hi,
>
> According the spec, for the same element, the computed values of these two props cannot be visible+hidden at the same time. Does anybody know why it is designed this way? Or it's just because of compatibilities?

Besides history and compatibility requirements, I think the two main reasons are:

* overflow: hidden does more than just hide the overflow, it also makes turns the element into a Block Formatting Context (Floats don't escape, margins of children don't collapse with margins of parents...). Being a BFC in one dimension only is not a thing that exists.

* if an element could be overflow-x: visible and overflow-y: scroll, you would have a vertical scrollbar on the right (typically) side of the element, overlapping with the visibly overflowing content in the inline direction, which is terrible. Same for visible + auto. This isn't necessarily a problem for visible+hidden, but at least it explains why the other values cannot be combined with visible.

 - Florian
Reply | Threaded
Open this post in threaded view
|

Re: [css-overflow] A question about overflow-x and overflow-y

Joe Gu
Thanks Florian.

Any one of overflow-x and overflow-y being `hidden` will trigger BFC, which don't have to break anything of spec. "BFC in one dimension" doesn't have to exist here. So I don't think it's something prevents `visible` + `hidden`.

As you said, scrollbars actually don't break `visible` + `hidden` either (in this combination, we don't need scrollbars).

So I assume it's more of a history and compatibility issue?


On Tue, May 31, 2016 at 9:10 AM, Florian Rivoal <[hidden email]> wrote:

> On May 30, 2016, at 18:24, Justice <[hidden email]> wrote:
>
> Hi,
>
> According the spec, for the same element, the computed values of these two props cannot be visible+hidden at the same time. Does anybody know why it is designed this way? Or it's just because of compatibilities?

Besides history and compatibility requirements, I think the two main reasons are:

* overflow: hidden does more than just hide the overflow, it also makes turns the element into a Block Formatting Context (Floats don't escape, margins of children don't collapse with margins of parents...). Being a BFC in one dimension only is not a thing that exists.

* if an element could be overflow-x: visible and overflow-y: scroll, you would have a vertical scrollbar on the right (typically) side of the element, overlapping with the visibly overflowing content in the inline direction, which is terrible. Same for visible + auto. This isn't necessarily a problem for visible+hidden, but at least it explains why the other values cannot be combined with visible.

 - Florian

Reply | Threaded
Open this post in threaded view
|

Re: [css-overflow] A question about overflow-x and overflow-y

Tab Atkins Jr.
In reply to this post by Florian Rivoal-4
On Mon, May 30, 2016 at 6:10 PM, Florian Rivoal <[hidden email]> wrote:
> * if an element could be overflow-x: visible and overflow-y: scroll, you would have a vertical scrollbar on the right (typically) side of the element, overlapping with the visibly overflowing content in the inline direction, which is terrible. Same for visible + auto. This isn't necessarily a problem for visible+hidden, but at least it explains why the other values cannot be combined with visible.

It's also just bizarre in general. All the scrolling values have the
physical metaphor of a viewport into the underlying content, which
gives a good intuition about how the scrolling and clipping works.
Combining scroll+visible, tho, means that content that is overflowing
vertically would still be cut off horizontally; that doesn't make any
sense! It's already overflowing, why is clipping happening? But if it
doesn't clip horizontally, then what happens within the element's
bounds in the horizontal axis? It's all kinds of silly.

~TJ