Re: outline-radius

15.03.2012, 03:10, "Lea Verou" <leaverou@gmail.com>:
> I always liked the idea of the border properties becoming lists, and
> never agreed with it getting dropped from css3-background. I recall the
> reasons were "lack of use cases" and supposed overlap with border-image
> — which is like saying that gradients aren't needed because we have
> background-image.

Thank you for your support of the idea. For me, most often usecase for multiple borders is a design that has multiple-line separator. Currently, we are forced to use multiple nested blocks (each with its own border color and width) or (nowthat IE6/7 are not important to support) combination of border and generated content (:before/:after) if we don't want to use background image.

As for outline, it seems quite natural to generalize such extremely similar things as border and outline (just because any so closely similar things should be generalized). By the way, I've noticed that similarity back in 2005-11-30 in my russian-language blog-post about Firefox 1.5 where outline has been first (at least for Fx) implemented, and I has been suprised that new property has been invented instead of extending border syntax:

http://tanalin.com/blog/2005/11/firefox-1.5/

> Anyhow, about your proposal, how do you picture the following to behave?
>
> border: 1px solid;
> border-color: red, green, blue;
> border-affect: affect, none, affect;
>
> i.e. what happens when borders not affecting layout come before borders
> that do?

For my current (very simplified) proposal, all subvalues of border-affect(-size) before last 'affect' subvalue should not matter.

So if we have:

    border-affect: affect, none, affect;

it should be treated same way as:

    border-affect: none, none, affect;

or just:

    border-affect: affect;

One common value means that all borders (including last/outermost one) do affect element size.

Maybe there could be another, more appropriate syntax. For example, we could specify exact index of outermost affecting border-layer:

    border-affect-index: 3;

'3' here means that third of border layers should affect element size.

It maybe also may make sense to consider ability for borders to overlap each other, and then multiple border-affect values could have even more sense. It could be expressed, for example, via following syntax:

    border-origin-index: 2, 0, 0;

where each number is an index of border layer which should be origin for rendering corresponding border layer.

So if we have:

    border: 5px solid red, 10px solid green, 2px solid blue;

then green and blue borders are rendered from element's itself edge and are overlapped (border-origin-index is 0 for both), while red border is rendered from green border (border-origin-index is 2 which is index of second border layer).

It could be rendered like this:

http://tanalin.com/_experimentz/w3/css/2012/border-layers.png

There is, of course, no much sense to overlap _solid-color_ borders, but for semitransparent (rgba() in partucular) borders it's there.

It makes sense to take into account that these are just ideas, and if overlapping borders will seem too complicated right now for someone responsible for CSS speccing, then it's perfectly OK to start from my initial simplified proposal for multiple border without overlapping feature.

Thanks.


> On 12/3/12 14:32, Marat Tanalin | tanalin.com wrote:
>
>>  In general, indeed, it would be nice to have ability to round corners of outline similar to currently available rounding corners of element with border-radius.
>>
>>  However maybe it makes sense to get rid of outline itself in its current form, and make generalize and improve borders by making it possible to:
>>
>>       * specify _multiple_ borders for same element;
>>       * specify whether particular border "layer" should affect element size.
>>
>>  A possible multiple-borders syntax is simple (comma-separated list of regular border values):
>>
>>       .example {border: 1px solid #ссс, 2px solid #0a0; }
>>
>>  Whether border "layer" should affect element size, could be specified by property like border-affect-size:
>>
>>       .example {border-affect-size: affect, none; }
>>
>>  Here, first border (1px solid #ссс) do affect element size while second border is rendered, but does not affect element size (effectively behaving as outline).
>>
>>  By affecting element size, I mean whether visible size of element (together with particular border layer) is identical to size of element's area affecting positions of its sibling elements. For example, currently, border do affect element size while outline does not.

Received on Thursday, 15 March 2012 00:45:35 UTC