W3C home > Mailing lists > Public > www-style@w3.org > April 2009

[css3-background] Issues open for feedback

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 13 Apr 2009 16:10:01 -0700
Message-ID: <49E3C649.1070903@inkedblade.net>
To: www-style@w3.org
Hello www-style,
I've posted a summary of the major open issues we've been discussing
here on css3.info: http://www.css3.info/border-image-issues/

Feel free to comment here, there, or in the appropriate threads. :)

~fantasai


====== Full text of the blog post below ======

CSSWG RFC: border-image Issues and Other Topics
-----------------------------------------------

So, the CSS Working Group is trying to wrap up the CSS3 Backgrounds
and Borders Module and prepare it for Last Call. However, there are
still some open issues weíd would like to get comments on.

Most of the open issues revolve around border-image. Brad Kemper
knocked down several with his proposal [1] and the CSS Working Group
has adopted it in principle. (You can find it drafted into the latest
unofficial Editorís Draft [2] on the W3C site.)

[1] http://www.bradclicks.com/cssplay/border-image/Thinking_Outside_The_Box.html
[2] http://dev.w3.org/csswg/css3-background/#the-border-image-property

Weíre still ironing out the details on that, but there are a few
others still open:

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).
Received on Monday, 13 April 2009 23:10:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 03:46:58 GMT