Re: [css3-background] Issues open for feedback

1 - fill/clip keyword for center of border-image
================================================
Nearly all users of border-image will be producing these images in an
image-editting program (Photoshop, GIMP, etc) already, so making the
center transparent will *not* be a big hassle.  Hakon has previously
stated that he does his image manipulation on the command line (^_^),
but I think that's an extreme minority.  This property would be only a
tiny convenience, at the cost of complexifying the property even
further, so I'm fine with just leaving it out.


2 - Separating border-image into sub-properties
===============================================
The separation really does make the property easier to understand.  In
my experience the primary usefulness in sub-properties is when are
adjusting some property of them in a :hover or related rule.  Being
able to target a specific sub-property makes things much shorter and
more comprehensible, and reduces duplication and sync errors.
However, I don't imagine that will happen much with this property.

So, while it would be nice to have the sub-properties, I won't object
if they're not included (my opinion is quite different concerning
shadows, though...).


3 - Interaction between border-image and box-shadow
===================================================
Ignore box-shadow when border-image is in effect.  Brad and I made our
cases for this behavior previously, and with the current proposal
there's *really* no reason to do it.  Box-shadow is a simple property
for a simple effect.  Border-image is a complex property which
subsumes it.


4 - Fallback color when background image fails to load
======================================================
This is really quite necessary for accessibility purposes.  The
use-case is when you have an element with a dark, partially
transparent background and light text, over a lighter parent element
(or vice versa with light/dark).  The transparency prevents you from
specifying a normal background color, but if the images don't load you
have light text on a light background, which will be
difficult/impossible to see.

The current syntax (just specifying two colors, with the second being
the fallback) is easy to understand, and the fact that, in practice, I
believe it will always be "transparent -foo-" makes it obvious when it
is used.


5 - background-clip:no-clip
===========================
I'm curious as to what problems implementors expect to have.  I
believe the behavior of this property can be duplicated exactly with
border-image (border-image may introduce other unrelated unwanted
effects, though).

If the spilling out is an issue, how is this difficulty resolved for
border-image with an outset?


6 - Renaming block-progression
==============================
I am perfectly happy with the current name, as it matches up with
terms used elsewhere in the spec, which makes it easy to understand.
If it were to be changed, my vote's for block-direction, as it (paired
with the list of possible values) strongly suggests what it does
without even knowing the spec.  Block-flow seems somewhat opaque, and
clashes with some other proposals using the term 'flow'.

~TJ

Received on Tuesday, 14 April 2009 17:47:54 UTC