W3C home > Mailing lists > Public > www-style@w3.org > January 2009

Re: [css3-background] does border-radius round the border-image ?

From: Jorrit Vermeiren <mercator+w3c@gmail.com>
Date: Sat, 24 Jan 2009 21:26:38 +0100
Message-ID: <bd6e15d00901241226g5fe6b10ct3daa42a3dde56581@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: Anton Prowse <prowse@moonhenge.net>, "www-style@w3.org" <www-style@w3.org>

On Fri, Jan 23, 2009 at 04:06, Brad Kemper <brad.kemper@gmail.com> wrote:
>
> On Jan 22, 2009, at 6:57 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>
>> On Jan 22, 2009, at 12:11 PM, Anton Prowse <prowse@moonhenge.net> wrote:
>>
>>>
>>> Brad Kemper wrote:
>>>>
>>>> 3) Even when the author may expect a scroll box to not obscure content,
>>>> there are cases where it does so anyway, already. I found such a case last
>>>> year, involving absolutely positioned contents [2].
>>>
>>>> [2] http://bradclicks.com/cssplay/scrolling%20lists.html (second to last
>>>> example on the page)
>>>
>>> Could you elaborate on this example a little?  In various browsers I see
>>> that the abspos markers are not rendered on the left.  However, this seems
>>> to me a bug
>>
>> Perhaps. But when I see the same thing in every browser I test with, it
>> makes me question if it is really a bug or if I just don't know why it's
>> doing it.
>>
>>> (after all, vertical overflow on the ancestor UL is set to visible) and
>>> not related in any way to the presence (or otherwise) of the scrolling
>>> mechanism.  Am I missing the point here?
>>
>> Well, the bug does not appear unless overflow is hidden, scroll, or auto
>> on the ancestor "UL" DIV. Thus my point that  "scroll" or "auto" does not
>> always mean the contents will be visible, even baring influence of ouside
>> elements.
>>>
>>>
>
> I forgot to add that even IE8 exhibits the same behavior, so I really tend
> to think it must be a "feature, not a bug". Or an unanticipated side effect
> of a feature.
>

I think that's according to the specs and is ultimately caused by
section 9.4.1 in the CSS 2.1 spec [1]. See also the other ongoing
thread about "Block formatting context and floats" [2]. Setting
overflow to something other than 'visible' creates a new block
formatting context. Since you can't both create a new BFC and not
create one, 'visible' can't always be combined with other values. In
fact, at the very bottom of section 11.1 in the CSS 3 box model draft
[3] it mentions that some combinations are not possible. The
'overflow-x' in your example gets a computed value of 'auto'. See also
Bruno Fassino's overflow tests [4].

Jorrit


[1] http://www.w3.org/TR/CSS21/visuren.html#block-formatting
[2] http://lists.w3.org/Archives/Public/www-style/2009Jan/0383.html
[3] http://www.w3.org/TR/css3-box/#overflow-x
[4] http://www.brunildo.org/test/Overflowxy2.html
Received on Saturday, 24 January 2009 20:27:20 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:15 GMT