Re: [css3-background] Issues open for feedback

2009/4/14 fantasai <fantasai.lists@inkedblade.net>:
> [...]
>
> 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?

I probably would keep the middle part of the images, because otherwise
I need to add a background-image (or background-color) to get the same
effects, ie I need two images. I prefer option C: while it would
prevent from using JPEG, it allows a greater freedom (you can cut just
a small part, not all the middle part) and doesn't pollute even more
the syntax of border-image (that is already complex enough)

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

I like the splitting, since I'm, generally speaking, in favour of
having properties that either a take a single value of a list of
values, anything else is difficult to remember and to understand.
It would probably be interesting to see the reasons that made all the
border image properties in
<http://www.w3.org/TR/2002/WD-css3-border-20021107/#the-border-image>
collapse into "border-image" alone.

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


Border-images have the ability to cast shadows (you just need to draw
them with an image editor) and thus should override the box-shadow,
always.
Option 2) is no more a box-shadow, it is a custom shadow, and thus
should be generated using an image editor or a SVG filter.

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

I think that a one-color background-image is still a background-image.
So my proposal is to add fallback images, instead of fallback colours.
The proposed syntax is "background-image: <image> [S+ <image>]* [,
<image> [S+ <image>]* ]*"
(that is, instead of one background-image per comma, you have a list
of space separated background-images)
The use cases are many, not just when the image is disabled: network
connectivity may off (and the fallback may be a data: uri), the server
may refuse to give the content (especially cross-site), the UAs may
not able to display the image (especially in formats like SVG, APNG or
VML), the user may have disabled only certain kinds of images
(scripted SVG for security, animated images for epilepsy)
Then you just need to extend the <image> type to build an image that
is completely one color, something like "color-image(<color>)". You
may also extend the <image> type to accept SVG paint servers or
gradients, but this is out of scope now.

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

I think it is useful if the image, despite being part of the
background, is something that you never want clipped, like a fancy
border not achievable with border-image, or, most important, the logo
of your company.
Anyway, I'm not sure of this feature, because if the image is part of
content, it should be introduced with "content:url()", else it is just
visual decoration and clipping is not that problem.

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

I liked more "block-progression", considering that the css3-linebox
consistently references "the block progression dimension", and we have
proposal for a completely different "flow" property.

Giovanni

Received on Tuesday, 14 April 2009 09:20:46 UTC