Re: [CSS] Expandable background images, proposal

fantasai wrote:
> Andrew Fedoniouk wrote:
>> fantasai wrote:
>>> Andrew Fedoniouk wrote:
>>>> fantasai wrote:
>>>>> Andrew Fedoniouk wrote:
>>>>>>
>>>>>> background-repeat:expand; is defined here:
>>>>>>
>>>>>> http://www.terrainformatica.com/wiki/doku.php?id=h-smile:expandable-backgrounds 
>>>>>
>>>>>
>>>>> How is this different from the current 'border-image' proposal?
>>>>>   
>>>>> http://www.w3.org/TR/2005/WD-css3-background-20050216/#the-border-image 
>>>>>
>>>>
>>>> Differences are:
>>>>
>>>> First of all: my proposal does not require new attributes like 
>>>> border-image you have mentioned.
>>>
>>> But it significantly complicates existing properties, so I think 
>>> that's a
>>> non-issue.
>>
>> Beg my pardon but what exactly complicates existing properties?
>> In any case I believe that complexity is far less than the-border-image.
> 
> It's the same feature. 'border-image' uses a new property, your proposal
> adds new keywords. 'border-image' is less prone to unexpected changes 
> through
> the cascade, it avoids complicating the background properties (which are
> already complicated enough in CSS3), and it has a better fallback story for
> browsers that don't support the feature.
> 

Yep, this is the only reason (at least for me) that makes 'border-image' 
somehow better than background-repeat:expand; so far.

But if we would have something like

@has-feature( background-repeat-expand )
{

}

then background-repeat:expand become better than border-image.

I think that we have no such an option in CSS to have two feature sets 
with  overlapping scopes. Beside of other things this will be a source 
of logical conflicts in future versions of CSS.

In principle each new attribute adds new *dimension* in the attributes 
dependency matrix. Ideally each attribute has to be self-sufficient 
(orthogonal). In this case we can "collapse" the whole dimension.

In case of border-image that is not so. It interacts both ways with 
border-width at least and re-implements again some features of 
background-image.


>> Hmm...
>> http://www.w3.org/TR/2005/WD-css3-background-20050216/#the-border-image
>> tells us that border is drawn over the place defined by 'border-width' 
>> attribute. As far as I understand middle section of the source image 
>> is always stretched to fill padding box. Am I right? If yes then to be 
>> practically useful this border image will have transparent middle 
>> section. In most cases.
>>
>>>> Usually such expandable borders and background is really a single 
>>>> entity from graphical design perspective so it is better to define 
>>>> them as a single image.
>>>
>>> Right, and that's how border-image works as well.
>>
>> Not exactly. In my case middle section can be tiled or stretched.
> 
> The middle section isn't always stretched. It is stretched or tiled
> depending on the keywords specified in the 'border-image' property.

This is not clear from the text. At least for me.

I suggest to reformulate the whole border-image section as it is too 
fuzzy in my opinion. I can help with illustrations there - let me know.

> 
>> These are two basic usages of such background images.
>> Last two cases at: 
>> http://www.terrainformatica.com/htmlayout/images/image2.png
>>
>> I prefer sole and simple mechanism that allows to cover both cases 
>> rather than halved solutions.
> 
> 'border-image' can do both.

That is the point.

Together with existing background-*** set we will have border-image that 
as it appears will overdraw background image in almost all use cases.

> 
>>> How is it limiting? What use cases do you have that does it not address?
>>
>> background-repeat:expand does not disable any existing style feature 
>> available in CSS - it only extends opportunities.
>>
>> I've seen cases when borders (like: 1px solid red) were used 
>> additionally to the background image. E.g. different colour schemas 
>> that use same background with border shadows.
> 
> If you're making the shadows with an image on the same element, you can't
> use the CSS border properties because they'll draw the border around the
> shadow instead of around the virtual box that's being shadowed.

See very first image in article:
http://www.terrainformatica.com/wiki/doku.php?id=h-smile:expandable-backgrounds

I mean that kind of backgrounds. Imagine that it is strictly rectangular 
  and borders are defined by border CSS attributes on this figure.
That is quite popular case. Multiple style sheets use the same 
background but with different colors of borders.

> 
> Also, CSS3 has an expanded set of background properties. You can stretch
> the background with 'background-size' and then still use the border
> properties for your 1px border.

I believe that if we provide background-repeat:expand feature then
this new bunch of background attributes (-size, -position, etc.) will
not be needed at all. At least I've never heard that anyone needed
things like "background-size" in more of 3 years of the 'expand' 
exploitation.

> 
>>>> The same thing with the 'round' modifier. To be used practically 
>>>> such roundness shall be implemented as a constraint of dimensions of 
>>>> border box of the element. In the way it is defined in the 
>>>> border-image it is not useful at all.
>>>
>>> Why is it not useful at all?
>>
>> Because it assumes scaling of bitmap image with scale factors close to 
>> 1. The worst case designer can imagine.
> 
> I think you need to reread the definition. The author can provide a 
> high-res
> image: it will be scaled down to fit the border image before it will be
> stretched to match the 'round' requirements. In such a case the scaling
> factor could vary between 0.3 and 0.31 rather than between 1 and 1.1.

Yep, 0.3 factor is better. But this means following: you need bitmap 
image three times bigger in each direction than needed. Your memory 
consumption for all operations will be 9 times more and so on.

And all this can be solved by something simple as:

#fancy-borders
{
   width: 20em/6px;  /* multiple by 6px nearest to 20em */
   background-repeat: expand;
}

and use 1:1 bitmap images with it.
Simple and ideal for resource consumption and effectiveness of execution 
and implementation.

> 
> BTW, Andrew, I have a question about the CSS extensions you are 
> implementing.
> Are you using a vendor extension as specified in
>   http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords
> ?

That is not the case for the embeddable-only-engine.

CSS we use is close to what is used for styling web but is in different 
namespace. Due to specifics of DOM implementation and the whole domain 
of XHTML-as-UI-language, CSS declarations that host application uses for 
styling its UI are not applicable for publishing and so has very little 
chance to be loaded/viewed in the Web wilderness.

E.g. QT (TrollTech) has also CSS alike style sheets in QT4.2 and they 
also do not use vendor extensions. See: 
http://doc.trolltech.com/4.3/stylesheet-syntax.html

Host applications that uses our engine may extend set of CSS attributes 
for its own needs. These attributes to be accounted *must* start from 
'-'. And this is physical enforcement hardcoded in the engine.

If we will decide to publish engine to be used as a core of common use 
UA then we will move all extensions to the vendor specific namespace.

But I still don't know what to do with flex units we use. There simply
no mechanism for such thing as vendor-specific-length-units.

So for us things like @has-feature(flex-units) to be supported by 
official CSS is a must. For now absent of this prevents the engine to be 
published in Open Source where we cannot control its use cases.

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Sunday, 25 November 2007 21:41:57 UTC