Re: [CSS3] border-radius, border-image and drawing order.

Sent from my iPhone

On Aug 15, 2009, at 1:28 PM, Andrew Fedoniouk  
<news@terrainformatica.com> wrote:

> Tab Atkins Jr. wrote:
>> On Sat, Aug 15, 2009 at 2:33 PM, Andrew
>> Fedoniouk<news@terrainformatica.com> wrote:
>>> Consider following style and markup:
>>>
>>> div
>>>   {
>>>     width:100px; height:100px;
>>>     border-width:4px;
>>>     border-color:red;
>>>     border-radius:50%; /* that means border is a
>>>                           perfect circle */
>>>     border-style:solid;
>>>   }
>>>
>>> <div>Some text</div>
>>>
>>> Shall border be drawn on top of the text or behind it?
>>> That is the question.
>>>
>>> If border is a part of background as current spec implies
>>> then text should be drawn on top of the border.
>> Borders are drawn above the background, but under the text.
>>> But what about border-image?
>>> If it is drawn behind the content layer then
>>> this border-image makes almost no practical sense.
>> Border-image is drawn on the same layer as borders.  Borders are
>> hidden while a border-image is in effect.
>> Could you elaborate on why the border-image being drawn below text is
>> a problem?  Is this also a problem for normal borders?
>
> Imagine that text in the third column here:
> http://www.bradclicks.com/cssplay/border-image/Alladins_Lamp_2.png
> will contain couple of more lines. For now they will be drawn on top
> of the lamp that is unexpected.

Not if I put enough padding at the bottom to prevent unwanted overlap.  
Not all border-images would have such a large pronounced picture as  
that, of course. Patterns, simple stretched lines, etc. would probably  
be more common, with more interesting things happening on the corners  
than on one side. Don't get too hung up on one particular sample.  
There are, and will be, more.

>>> Why not to use that multi-background feature and
>>> to drop this border-image completely then?
>> One of the original reasons multiple-backgrounds were used *was* to  
>> do
>> essentially the same thing as border-image is currently doing.  It's
>> rather nasty when you actually start writing the code, though.  The
>> actual property can get *really* long and complex, you have to design
>> a single image and then slice it into multiple separate images, and  
>> it
>> can cause up to 9 network requests.  Border-image solves all of that
>> by letting you create a single image, specify how to slice it in the
>> CSS, and wrap it all up in a relatively simple syntax.
>
> Why not to add such slicing/sectioning to any background image then?

For one thing, I think that would be much more complex. For another,  
as a border, it is more natural for it to supress any existing  
fallback borders, as it does now.

> I suspect that we need either
> 1) multi-background images or
> 2) single background image and the border-image
>
> But not both.
>
> We have multiple features that serve the same purpose -
> drawing image(s) on the background in various ways.
>
> Usually such feature redundancy is one of ringing bells of
> bad design.
>
>> Another benefit of the current border-image proposal is that it  
>> allows
>> you to paint outside of the actual box geometry.  The benefits of  
>> this
>> are clearly explain with a great example over at Brad's site:
>> http://www.bradclicks.com/cssplay/border-image/Thinking_Outside_The_Box.html
>
> "to paint outside of the actual box geometry"
>
> That simply means that borders of the element are drawn on top of  
> its siblings but not on top of its children. That makes the logic  
> even worse.

On top of previous children, but you can use z-axis to control that.  
Remember that you are declaring the border image in the same CSS where  
you can also control margin, etc. Obviously if you go outside the box,  
you'd want to consider how doing so may impact the neighbors.

>

Received on Saturday, 15 August 2009 21:33:03 UTC