Re: [CSS] Expandable background images, proposal

Andrew Fedoniouk wrote:
> 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.

Note that 'border-image' also has the ability to change the border width
in the case that the border image is used. So the border width used for the
expandable image case can be tied to the border image declaration.

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

The latest version of the text is at
It incorporates some clarifications discussed back in June. If you have
any further suggestions for improvement, let me know. :)

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

This allows combining a border image with backgrounds, and it also allows
using a background image as a fallback for the expandable image.

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

(BTW, background-position isn't new.) 'background-size' can do things
that 'border-image' or the 'expand' keyword can't do. It can size images
in ems, for example, or percents. It's particularly powerful with SVG

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

Interesting. I imagine that snapping sizes to the nearest X units is useful
for more than just this case. I think the grid proposal may be looking into
this kind of functionality.

>> BTW, Andrew, I have a question about the CSS extensions you are 
>> implementing.
>> Are you using a vendor extension as specified in
>> ?
> 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.

How is it a different namespace? Is it a different file extension / MIME type?

> 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: 
> 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.

Ok, thanks for the explanation.

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

You wouldn't be able to use '%%', but I believe '-vend-fx' could work,
e.g. 50-vend-fx


Received on Monday, 26 November 2007 00:53:16 UTC