- From: Bruno Racineux <bruno@hexanet.net>
- Date: Fri, 18 Oct 2013 15:46:43 -0700
- To: Alan Gresley <alan@css-class.com>, "Kang-Hao (Kenny) Lu" <kanghaol@oupeng.com>
- CC: www-style list <www-style@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
On 10/18/13 2:32 AM, "Alan Gresley" <alan@css-class.com> wrote: >On 18/10/2013 7:38 PM, Bruno Racineux wrote: >> >> On 10/17/13 2:57 PM, "Kang-Hao (Kenny) Lu" <kanghaol@oupeng.com> wrote: >> >>> (2013/10/18 5:35), Tab Atkins Jr. wrote: >>>> On Thu, Oct 17, 2013 at 2:23 PM, Bruno Racineux <bruno@hexanet.net> >>>> wrote: >>>>> Does this proposal address "clearing the float" at all? >>>>> >>>>> I would be ideal is there was a native solution for this by now, >>>>>rather >>>>> than the 'clearfix' hacks. >>>>> >>>>> And while 'overflow:hidden' helps, it's not a comprehensive solution >>>>>to >>>>> clear-fixing. >>>> >>>> This is basically a more powerful/comprehensive overflow:hidden, so it >>>> addresses float clearing as well as overflow:hidden does. >>> >>> I suppose this reads >>> >>> 'overflow: clip' doesn't address "clearing the float" >>> >>> ? I am not criticizing the proposal as the use cases might just be >>> parallel, >> >> I bring this due to the implications between overflow:hidden and >>"clearing >> the float". And for lack of introduction perhaps, I am curious to >> understand what overflow:clip intends to achieve or address. > >Why is it that when Tab attempts to start or continue this thread that >it get hijacked into being a thread about clearing floats? Alan, the words 'curious for lack of introduction', or asking a question as to whether this proposal includes something or not (which Tab says it does) are not anywhere near the semantics of 'hijacking' anything. Chill out. I am just asking question and presenting a use case I find problematic which is completely related. >I will quote Tab. > > > In particular, isolating the painting of an element seems like a big > > win - having some way to guarantee that the element can be > > hard-clipped to its boundary without losing anything important. > > overflow:hidden doesn't*quite* do this - abspos and fixpos elements > > can escape the bounds of the element. Ok, I admit I have initially overlooked his explanations. What I am trying to address is the following use case: <style type="text/css"> .row { width:100%; clear:both; margin-bottom: 10px; background-color: #bbb; } .cib { display:inline-block; width:30%; overflow: hidden; margin-left: 10px; background-color: #444; } b { display: block; color:#fff; text-align: center;} </style> </head> <body> <div class="row"> <div class="cib"><b>Cannot be contained by wrapper</b></div> <div class="cib"><b>Cannot be contained by wrapper</b></div> </div> <div class="row"> <div class="cib"><b>Cannot be contained by wrapper</b></div> <div class="cib"><b>Cannot be contained by wrapper</b></div> </div> Call it perhaps clearing the flow vs clearing the float... Basically the issue here is that inline-blocks with overflow: hidden; cannot be contained here, no matter what your wrapper has. i.e. I can't have the benefits of overflow: hidden; and prevent scrolling at the same time on the inline-blocks. In that, an overflow:clip that prevents scrolling would be useful. It would help clipping the overflow of an inline-block without the current caveat. Or I like François REMY' suggestion with "paint-limit: [ [ content-box | border-box | margin-box ] <paint-limit-padding>? ] | none" at the wrapper level. It could be a lot more flexible. Bruno >Test case. > ><style type="text/css"> >div { height: 100px; width: 100px; border: 5px solid black; } ></style> > ><div style="overflow:hidden"> ><p>Some text that will overflow</p> ><p>Some text that will overflow</p> ><p>Some text that will overflow</p> ><p>Some text that will overflow</p> ><p>Some text that will overflow</p> ><div style="position:absolute;right:0;bottom:0;background:lime">Where am >I located?</div> ></div> >Alan > > > >-- >Alan Gresley >http://css-3d.org/ >http://css-class.com/
Received on Friday, 18 October 2013 22:47:14 UTC