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

Re: [css3-background] Issues open for feedback

From: François REMY <fremycompany_pub@yahoo.fr>
Date: Tue, 14 Apr 2009 11:19:56 +0200
Message-ID: <755F9C2754F54C1B964BBDE568095380@FREMYCOMPANY>
To: "fantasai" <fantasai.lists@inkedblade.net>, <www-style@w3.org>
From: "fantasai" <fantasai.lists@inkedblade.net>
> 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?

I've no preference about that question.

> 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 strongly agree that the 'one-property' syntax is very obscure.
Having different properties can really help developers !

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

I really prefer 2).

Box-Shadow and Border-Image are not the same thing, and have different

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

It should be included in the <image> definition type, not in the background 
    <image> : url(...) | <color>
                       | (url(...) <color>) // If you want to provides 

I had a proposal to solve such problems, but it needs to be implemented at a 
wided level,
so I doubt it can help in the current context. Maybe it can be implemented 
in CSS 4 [:-)

firstOf(<expression> [, <expression>]*)
    Returns the first valid & usable value in the given expressions.

And so, we can have
    background-image: firstOf(url(404.png), rgba(50%, 33%, 25%, 75%))

Anyway, if you really want to provide this, make the use of parenthesis 
necessary :
    background: (url(404.png) rgba(...)) white ...;

But I prefer no solution for CSS3 and a wider solution for CSS4 than a sort 
of 'hack' for CSS3
and no wider solution for CSS4.

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

Sorry, no sample here... Maybe it can be useful, though, but I don't
see practical use cases here....

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

block-progression seems good. But if you want to rename, why not.
As I think there's no implementation as of now, we can safely rename.
If there's, we need to ask the implementor, though.

The problem is 'Is it really clearer ?'

I can't say for English speaker, because I speak French, but for my
'progression' is easier to understand than 'flow'.


That's all. Hope my remarks will provide you some help.

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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:35 UTC