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

Jorrit Vermeiren wrote:
> 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.
>>

Ah, now I understand what Brad meant by his original comment.  (I 
thought he was saying that the scrollbar was literally 
obscuring/disrupting the overflowed content!)

> 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].
> 
> [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

Thanks; I had overlooked that section at the very bottom of Section 11.1 
[3], having stopped at the examples.

Once the used value of overflow-x is determined to be auto, the 
behaviour matches what we would expect from even CSS21, where overflow 
on the left-hand side or top is clipped whilst overflow to the 
right-hand side or bottom is reached by scrolling if necessary.

[Incidentally, whilst this is the traditional behaviour, is there a 
theoretical reason why scrolling should not be possible leftwards and 
upwards as well as rightwards and downwards?]

Certain combinations are hidden, I presume, because otherwise we would 
have rather odd situations in which overflowing content that was visibly 
displayed in one direction interfered with the scrollbar used to reach 
its extents in the other direction.  (And this was how I interpreted 
Brad's original comment.)  As Bruno notes in the page you cited, 
existing implementations limit other combinations which would not suffer 
from this problem (such as 'visible' together with 'hidden'); this 
limitation does not seem so desirable, however.

I don't think that the restriction of combinations is related to BFCs 
though. overflow:visible is not itself incompatible with being a BFC; it 
just doesn't itself cause it.  If it were possible for the used values 
of overflow-x and overflow-y to be visible and auto respectively, I 
imagine that the box would still be a BFC.

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Monday, 26 January 2009 19:01:23 UTC