Re: [css3-ui] 'overflow-x' 'overflow-y' properties (was Re: [css3-selectors] What's the point of :empty?)

Apologies for top-post (blame Blackberry feature deficiency).

I did consider it (would prefer what you suggested actually) and the problem is that overflow-x and overflow-y are more than syntactic sugar - they enable new functionality.

In particular, from what I can tell, the ability to turn on scrolling only in one direction potentially affords some interesting (but needing to be defined) behaviors, e.g. scrolling only horizontally, perhaps in combination with multicolumn support.

Suffice it to say the "scroll only in one direction" use-cases and processing/formatting/display/interaction model can use specific examples demonstrating their utility and expectations of implementation. 

Defining overflow-x/y without those would shortchange (and likely under-specify) the feature, which I'd rather not do (we've had enough historical CSS headaches from underspecified overflow and its cousin clip in the past).

Thanks,

Tantek


 
-----Original Message-----
From: fantasai <fantasai.lists@inkedblade.net>
Sender: www-style-request@w3.org
Date: Fri, 01 Jul 2011 11:12:31 
To: <www-style@w3.org>
Subject: Re: [css3-ui] 'overflow-x' 'overflow-y' properties (was Re:  [css3-selectors]  What's the point of :empty?)

On 06/30/2011 09:09 PM, Tantek Çelik wrote:
> On Tue, Mar 1, 2011 at 15:36, Tantek Çelik<tantek@cs.stanford.edu>  wrote:
>> On Tue, Nov 2, 2010 at 20:11, David Hyatt<hyatt@apple.com>  wrote:
>>> On Nov 2, 2010, at 7:44 PM, Robert O'Callahan wrote:
>>>
>>> On Wed, Nov 3, 2010 at 11:39 AM, David Hyatt<hyatt@apple.com>  wrote:
>>>>
>>>> Really the sticking point is overflow:hidden, which is commonly used in
>>>> conjunction with text-overflow to truncate content in the inline direction.
>>>> In the vertical direction nothing is clipped.  Think of a button built using
>>>> inline-block that clips/truncates its content horizontally (with ellipses).
>>>>   If you force the baseline to be the bottom margin edge just because
>>>> overflow:hidden was specified, then you can no longer baseline align this
>>>> control.
>>>>
>>>> What the spec says makes sense to me for overflow:auto/scroll, and we
>>>> could change that in WebKit I think, but there's a problem with what is
>>>> specified for overflow:hidden.
>>>
>>>
>>> Sounds like what you really want is overflow-x:hidden, overflow-y:visible
>>> ... with the baseline behavior depending only on overflow-y.
>>>
>>> Yeah, that would be an acceptable solution.  Unfortunately CSS2.1 doesn't
>>> define overflow-x and overflow-y and only talks in terms of overflow.
>>>   That's really what creates the problem here.  Maybe the language could be
>>> modified to state overflow in a particular direction without naming the
>>> specific properties?
>>
>> I've accepted this an issue for CSS3-UI, that is, that CSS3 UI should
>> define 'overflow-x' and 'overflow-y' properties.
>>
>> http://wiki.csswg.org/spec/css3-ui#issue-19

>
> Update:
>
> After having looked at what it would take to properly define
> overflow-x and overflow-y, the related text that would need to be
> borrowed/copied from CSS 2.1, I'm convinced this is too big/risky of a
> change to introduce into CSS3-UI at this time.
>
> While I still think that CSS-UI (perhaps CSS4-UI) would make a fine
> home for overflow-x and overflow-y, I'm also open to them remaining
> instead in the CSS3 module: The box model [1].
>
> In fact, the CSS3 Box Model Module could use an update to incorporate
> all the changes/fixes that went into CSS 2.1 (which would probably be
> better than effectively only updating the section on overflow for
> CSS3).

Have you considered, instead of redefining overflow, just defining
overflow-x and overflow-y as a split of the CSS2.1 overflow property,
i.e. relying on CSS2.1 for most of the definition?

~fantasai

Received on Friday, 1 July 2011 19:13:31 UTC