W3C home > Mailing lists > Public > www-style@w3.org > December 2013

Re: [css-masking][css4-background][css-images] 9-part sliced images (was: [css4-background] 9-part slicing images in background-image)

From: Dirk Schulze <dschulze@adobe.com>
Date: Wed, 18 Dec 2013 21:01:37 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: Rik Cabanier <cabanier@gmail.com>, Jet Villegas W3C <w3c@junglecode.net>, Dean Jackson <dino@apple.com>, "liam@w3.org" <liam@w3.org>, Brad Kemper <brad.kemper@gmail.com>, www-style list <www-style@w3.org>, Simon Fraser <simon.fraser@apple.com>
Message-ID: <4AEABA71-9D37-445A-A25F-AC59E08DF2CB@adobe.com>

On Dec 18, 2013, at 9:44 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Wed, Dec 18, 2013 at 12:31 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>> Hi,
>> On the CSS call today, Simon brought up the 9-part slicing images proposal from Dean as an alternative to 'mask-box' (implemented as '-webkit-mask-box-image' in WebKit and Blink and shipping by default)[1].
>> The proposal is more of an idea and far away of a concrete draft. I fully agree with Tab that such an intend should be done as a property independent CSS image rather than a part of background.
>> There are some parts on 'border-image' and 'mask-box’ (which both are a way to do 9-part sliced images today) that are very useful. One of them is the repetition of individual tiles rather than stretching. This is very useful and practical with the named properties and allows some useful effects like the stamp effect that people try to imitate. An example can be found at the end of the document here [2].
>> I wonder if a sliced-image() function (or however we would name it) can provide all the possibilities without getting too complex itself. Just as comparison: 'border-image' and 'mask-box' have 5 longhand properties. All the functionality needs to be placed in such a function.
>> I would like to hear the opinion of web developers if they prefer 9-sliced images or individual properties.
> I believe that things like this should first be attempted as
> functions, and if they end up too complex (which it probably will), we
> just give up and try to add it to SVG instead.  The only problem there
> is that we don't have an easy way to embed SVG in CSS, which is a
> problem we can and should fix separately.

I interpret your mail that you would like to see the image function before we introduce new properties (introduce in specifications since they are already there).

I am generally fine with that but fear that a mockup, the draft and the final implementation would take a lot longer than specifying the implementation we already have. I can be convinced though.

We can start from what we have in 'border-image' and take a look what is needed to take over:

* border-image-source: <image> | none

This on is kind of obvious, we need to reference the <image>: sliced-image(<image> …)

* border-image-slice: [<number> | <percentage>]{1,4} && fill?

This is the important part that defines the regions to slice the image. ‘fill’ removes the middle part. I do not think that we need ‘fill’. sliced-image(<image> [<number> | <percentage>]{1,4} …)

* border-image-width

This defines the regions in which we draw the 9 sliced image parts.

* border-image-outset

How much does the border image area extend the border box. Again, useful but not necessarily helpful within the image function.

* border-image-repeat

Shall a tile be repeated, stretched, repeated as long as it fits, repeated as long as it fits into the border image area but with equal space?

I think it gets clear that we can represent the first two properties in the sliced-image() function. The last three are important for the actual visual output. Currently I am unsure how they can be represent in the image itself. It feels more like this needs to be done by the property using the sliced-image() function.


> ~TJ
Received on Wednesday, 18 December 2013 21:02:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:38 UTC