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

[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 20:31:54 +0000
To: Rik Cabanier <cabanier@gmail.com>
CC: Jet Villegas W3C <w3c@junglecode.net>, Dean Jackson <dino@apple.com>, "liam@w3.org" <liam@w3.org>, Brad Kemper <brad.kemper@gmail.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>, Simon Fraser <simon.fraser@apple.com>
Message-ID: <822D60B2-6044-4487-9960-1008F9E753B2@adobe.com>
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.

Greetings,
Dirk

[1] http://dev.w3.org/fxtf/masking/#box-masks
[2] http://www.html5rocks.com/en/tutorials/masking/adobe/#toc-the-mask-box-image-property

On Jul 30, 2013, at 4:44 AM, Rik Cabanier <cabanier@gmail.com> wrote:

> 
> 
> On Mon, Jul 29, 2013 at 4:14 PM, Jet Villegas W3C <w3c@junglecode.net> wrote:
> Adobe Flash had 9-slice graphics for many years. The user adoption to code complexity/bug ratio was so poor that I wish we never had it.
> 
> I believe Flex was using it with pretty good results. It did introduce quite a bit of complexity in both the player and the tool.
>  
> It sure looked good on paper :)
> 
> and on screen :-D
>  
> 
> On Thu, Jul 25, 2013 at 11:55 AM, Dean Jackson <dino@apple.com> wrote:
> 
> On 25/07/2013, at 8:54 AM, Liam R E Quin <liam@w3.org> wrote:
> 
> > On Wed, 2013-07-24 at 11:14 +1000, Dean Jackson wrote:
> >> On 24/07/2013, at 11:07 AM, Liam R E Quin <liam@w3.org> wrote:
> >>
> >>> On Wed, 2013-07-24 at 04:40 +1000, Dean Jackson wrote:
> >>> [...]
> >>>> It's more than backgrounds. As Tab mentions, the idea is a single
> >>>> image resource that can be used anywhere that accepts an image.
> >>>
> >>> Is there a reason why they are restricted to 9 and not also 16 (giving
> >>> centre pieces on the edges)?
> >>
> >> Two reasons come to mind:
> >>
> >> - Designers typically work with 9-part images.
> >
> > I don't think that's true for print.
> 
> Can you give examples?
> 
> >> - The syntax for 9 part border images is already borderline confusing
> >> (get it? borderline!). Adding any more slices will likely explode
> >> brains.
> >
> > Possibly, but the nested HTML div markup for centred decorations on a
> > border is a pain to get right too,
> 
> Really? It's only one level of nesting.
> 
> Also, if they want truly centered inner borders, I expect they want 5x5 images, not 4x4. I think once you get to that level of syntax complexity you're going to be better off with nested elements.
> 
> > and you can't rely on polyfills for
> > print engines that likely don't have JavaScript.
> 
> 
> That's true. Again, I think we need examples from the print community. I don't follow this list completely, but I can't remember any requests for this.
> 
> Dean
> 
> 
> 
> 
> 
Received on Wednesday, 18 December 2013 20:32:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:17 UTC