W3C home > Mailing lists > Public > www-style@w3.org > October 2013

Re: [css-overflow-clipping] would 'overflow: clip' affect the layout of surrounding elements?

From: Kang-Hao (Kenny) Lu <kanghaol@oupeng.com>
Date: Mon, 14 Oct 2013 00:37:50 +0800
Message-ID: <525ACC5E.4070104@oupeng.com>
To: Alan Gresley <alan@css-class.com>
CC: WWW Style <www-style@w3.org>
(2013/10/14 0:09), Alan Gresley wrote:
>> I've since wondered if we can have a 'overflow: hidden' equivalent that
>> has no layout but painting effect (and that floats can intrude into it).
> 
> Can you clarify what you mean by no layout.

s/layout/layout effect/

It means this:

  When you specify 'overflow: <hidden-no-layout-value>' on an element,
  all elements stay where they were (layout-wise, or in other words,
  .clientTop/Left/Height/Width all stay the same, like what
  'visibility: hidden' does).

>> Perhaps 'clip' was meant to achieve this but that property seems to
>> already fail largely.
> 
> Clip only works with absolutely position elements.

Yes, which makes it useless and voloates the 'no-layout effect'
requirement when you specify 'position: abosolute' on it.

>> Before reading into the draft, I thought this
>> draft is about this, but the draft doesn't mention BFC...
> 
> Well I guess it should. I believe it's more to do with css-overflow
> being so incomplete.

If the draft says nothing then your are right, according to CSS 2.1, it
would create a BFC (because CSS 2.1 always says 'overflow' that's not
'visible') and has all those consequences: different 'height: auto',
margin collapsping, float-BFC positioning behavior and such.

>> So... can we make 'overflow: clip' not establish a BFC, or is this
>> already planned? The fact that 'overflow: hidden' affects layout is just
>> really very confusing to Web developers. This behaivor has been the main
>> way how Web developers get to known what a BFC is, I believe :)
> 
> If it doesn't create a BFC, then it's not a 'containing block'. Please
> read the spec [3] and note the use of the term 'containing block'.

Well, note that 'position: relative' doesn't establish a BFC but yet it
makes the element a containing block root.

This is a very fake example, but it might illustrate it:

  data:text/html,<style>div { border: red solid; } p { float: left;
  height: 5em; }</style><div><p></p></div>

  data:text/html,<style>div { border: red solid; overflow: hidden;} p {
  float: left; height: 5em; }</style><div><p></p></div>

  data:text/html,<style>div { border: red solid; position: relative; }
  p { float: left; height: 5em; }</style><div><p></p></div>

  where the third looks like the first.

I am asking 'overflow: clip' to behave like the first and the third.

>> I don't know if spec-wise or implementation-wise not establing BFC
>> contradicts the requirement to make the element a containling block
>> root.
> 
> Are you referring to the initial containing block?

Sorry for introducing a new term. By "make the element a containing
block root", I meant to refer to the 'position: relative' behavior. I'll
ask Tab to introduce a term here so that I can use it :)

>> If that's the case, I would like to requst another
>> overflow-clipping value.

Now that I think about this, I think "make the element a containing
block root" is already violating the 'no-layout effect' requirement for
decendents. I guess I'll ask for something like

  'visibility: content-box;'

instead. But this property-value combination is less intuitive to the
point that I don't think it can kill 'overflow: hidden' ;)



Cheers,
Kenny
-- 
Web Specialist, Opera Sphinx Game Force, Oupeng Browser, Beijing
Try Oupeng: http://www.oupeng.com/
Received on Sunday, 13 October 2013 16:38:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:03 UTC