Re: [css3-background] Issues open for feedback

I agree in principle with most of what Giovanni said, and I'v  
commented on some of these before, so I'll just summarize my views on   
these below.

1st issue: Authors will need to deal with transparency nearly as much  
on the edges as in the middle part, and will therefore already use an  
image format with transparency that they edit, or settle for faking it  
with a solid background like white. So no, I do not think another  
keyword for that is strongly needed.

2nd issue (arcane syntax):I don't feel strongly about this one, but  
don't think the syntax is that bad for the commonest cases (with no  
second set of numbers or just a single value in that spot). The offset  
numbers would be common, but many pictures would not need it, so that  
would still be simple. I would consider multiple properties as a "nice  
to have", but not critical.

3rd issue: I strongly feel that box-shadow should only be for when you  
know that there is a strongly rectangular box shape to apply it to,  
which you don't have for border-image (but you do have for the no- 
image fallback). I do not want the UA to guess at where the shadow  
should go ( whether it should also be on unadorned parts of the  
padding box, wether it should extend under each part of the image with  
varying transparency or get cut off at 50% or something, or if all  
parts are the image are places where I want a shadow). See some of my  
Aladdin sample, where I gave the lamp a shadow but not the smoke. This  
should be in the artist's hand when creating the image, where he can  
have shadows of different strength, color, size, opacity, etc. The  
biggest argument against this was that the shadow images took up space  
outside the natural dimensions of the box, but with the offset numbers  
this is no longer an issue.

4th issue: The most confusing part of the way fallback color is  
currently spec'ed is that it looks like it is a fallback for the  
background-color, instead of the background-image. It should be part  
of background-image somehow, with perhaps multiple fallbacks (so an  
author could say that if SVG is not supported then it falls back to  
PNG, and if that's not supported it could fallback to GIF, and if  
that's not supported it could fall back to a color). I do think that  
falling back to a color when the image isn't available is very  
helpful, and I have run into this before.

5th issue (no-clip): I can envision some things, and could probably  
whip together an illustration of the desired effect. That said, all  
the things I can think of could be accomplished with '::before' and  
absolutely positioned 'content', so it is not critical to have this in  
backgrounds for tiling, etc.

Off-topic Issue: I'm OK with 'block progression' and 'inline  
progression'. Once I learned what was meant by these terms, I  
remembered and understood them pretty quickly and easily.


On Apr 13, 2009, at 4:10 PM, fantasai wrote:

>
> First Issue: Several people have commented that they would like a way
> to clip out the center part of the image. There are two options for
> this:
>   A) Keep the middle part by default (current behavior). Add an
>      empty keyword that clips out the middle part.
>   B) Make the middle part clip out by default. Add a fill keyword
>      that keeps it. (It’s needed for stretch-tiling things like aqua
>      buttons.)
> Of course we might also just keep the current solution,
>   C) have authors make that part of the image transparent.
> Comments? What would you use?
>
> Second Issue: The syntax is particularly arcane. One commenter
> suggested breaking up border-image into multiple properties,
> leaving border-image itself as a shorthand. For example,
>
>  border-image: url(...) 20% 40% / 10% 4em 20% / 0 1em;
>
> would be equivalent to
>
>  border-image-source: url(...);
>  border-image-slice: 20% 40%;
>  border-image-widths: 10% 4em 20%;
>  border-image-outset: 0 1em;
>
> This would also allow the values to cascade independently, making
> it easy to e.g. swap just the image. There’s an overhead cost to
> more properties, however, so if we do this there needs to be a
> significant and useful advantage. Thoughts on this idea, or any
> other ideas for making border-image easier to understand?
>
> Third Issue: There’s still an open question of how border-image
> should interact with box-shadow. The two proposals on the table
> are:
>  1.) Ignore box-shadow when border-image is in effect.
>  2.) Use the border-image as a mask to draw a shadow, but only
>      draw the shadow where it appears outside the padding edge
>      (inner border edge). Comments? Preferences?
>
> Fourth Issue: The next topic is fallback colors: the current draft
> has a feature that lets you specify a background color to use only
> if the bottommost background image fails to load. The WG wants to
> know, is this feature something authors really want? Several WG
> members have posted comments saying that it’s too hard for authors
> to understand, that it’s not useful, and that the proposed syntax
> doesn’t make sense. What do you think?
>
> Fifth Issue: The last issue is, the current draft specifies a
> background-clip: no-clip feature that lets a background image spill
> out of the border box. Implementors are concerned that it’s tricky
> to implement, and aren’t convinced that it would be useful. If this
> is something you want, show off a realistic example or two that
> demonstrates why it is needed.
>
> Off-topic Issue: While I’m here, the WG wanted me to ask what people
> thought of renaming the block-progression property to block-flow and
> whether it was more understandable (or if anyone had better ideas).
> The property changes the direction of block layout, and the values
> are tb (horizontal lines stacked top-to-bottom, like English text),
> rl (vertical lines stacked right-to-left, like traditional Chinese
> text), and lr (vertical lines stacked left-to-right).
>