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

On 14/10/2013 9:04 AM, Kang-Hao (Kenny) Lu wrote:
> (2013/10/14 5:37), Tab Atkins Jr. wrote:
>> On Oct 13, 2013 5:15 PM, "Kang-Hao (Kenny) Lu" <kanghaol@oupeng.com>
> wrote:
>>>
>>> (2013/10/14 4:50), Tab Atkins Jr. wrote:
>>>> There's nothing particularly wrong with having a value that just
>>>> clips without the possibility of scrolling, so that it doesn't need
>>>> to establish a BFC, is just not what I'm going for with my draft.
>>>>
>>>> Assuming that clip-mask doesn't establish a BFC (I don't have easy
>>>> access to a real computer to check it right now) then it'll work
>>>> for your purposes, using the rectangle() function.

Tab, is the rectangle() function the same function as that that is in 
css-shapes [1]?

>>> I don't know if we can successfully extend 'clip' to non-abspos
>>> elements and you are right that 'mask' doesn't establish a BFC.
>>
>> I said clip-path, not clip. The former doesn't have the latter's
>> legacy works, but is otherwise identical.
>
> You said clip-mask :), but OK, this is
>
>    clip-path: rectangle(0, 0, 100%, 100%);

I confused. :-) Are you two now talking about something that it not 
overflow: clip (or whatever the desired behavior is) as proposed by Tab 
in this post and thread [2]?

>>> What I am asking is to make 'overflow: clip' (not this 'isolate'
>>> feature) a shorthand of 'mask: image(white)'. No new functionality, but
>>> I have doubts that the latter would take off. Also, with this, the
>>> fallback is easier:
>>>
>>>    overflow: hidden;
>>>    overflow: clip;
>>>
>>> I don't mean to conflate these two features, but I think this is worth
>>> sorting out.
>>
>> We try to avoid doing that kind of weird shorthanding unless there's a very
>> good reason, usually legacy related. It makes the language more difficult
>> to understand, and it's bad enough as it is.
>
> When I said "a shorthand of", I should have said "does what ... does",
> not in the sense of "shorthand in property expansion". CSS, as a
> powerful language, of course have lots of 'property A: value
> A'/'property B: value B' pairs that do the same things.

I will let Tab reply to this part. I'm somewhat lost at what is being 
talked about. :-)

> When a Web developer uses 'overflow: hidden', as far as I can tell,
> he/she has one of two possible intensions:
>
>    * clip-path: rectangle(0, 0, 100%, 100%) / mask: image(white) ;
>    * min-height: contain-floats;
>
> These two are both too long to type, I think. I am suggesting we replace
> the first with 'overflow: clip' and convey the message that we think
> it's better than 'overflow: hidden' (do we think so? why and why not?).
> I don't have a idea for the second. Perhaps it isn't a common case.

Sometimes you will use overflow: hidden on a child element since it may 
not need to be rendered (e.g. wide image). There is much misuse of 
overflow by exploiting the fact that certain values for overflow create 
a BFC.

> Actually, the first is not right because 'rectangle' refers to the
> border edge.

Is this the 'rectangle' of a containing block?

> I guess I agree with Alan in that the specs should be more coordinated.
>
> Cheers,
> Kenny

When I say something to that affect (being incomplete but yes, the specs 
should be somewhat coordinated), that is for the property 'overflow' and 
other properties and values in CSS2.1 and hopefully css3-overflow. 
Things are not quite defined so we don't have complete interoperability. 
Since I'm not sure what Tab is wanting in this spec, I can only answer 
your questions and give you a concept of what overflow is.

The best way to appreciate what overflow is is to consider what a 
veiwport is. A viewport or better a UA may render a scollbar and if it 
does, then the behavior is that of overflow: auto. It is also important 
to know that there is visible overflow and hidden overflow (not to be 
confused with overflow: visible or overflow: hidden). Visible overflow 
has a direction that is based on the writing mode and this is defined 
primarily in terms of its inline base direction and block flow 
direction. These two test series [5] [6] demonstrate this for 
writing-mode: horizontal-tb. There is now interoperability.

Alan


1. 
http://dev.w3.org/csswg/css-shapes/#relation-to-box-model-and-float-behavior
2. http://lists.w3.org/Archives/Public/www-style/2013Oct/thread.html#msg111
3. 
http://css-class.com/test/css/bidi/visible-overflow-containing-block-ltr.htm
4. 
http://css-class.com/test/css/bidi/visible-overflow-containing-block-ltr-ap-left.htm



-- 
Alan Gresley
http://css-3d.org/
http://css-class.com/

Received on Monday, 14 October 2013 09:57:33 UTC