Re: [Backgrounds/Borders] What to do when a border-image fails to load

Sent from my iPhone

On Apr 10, 2009, at 11:15 AM, fantasai <fantasai.lists@inkedblade.net>  
wrote:

> Brad Kemper wrote:
>> On Apr 9, 2009, at 6:15 PM, fantasai wrote:
>>> Ok, this is now in the Editor's Draft:
>>> http://dev.w3.org/csswg/css3-background/#the-border-image-property
>>>
>>> I think I addressed all the comments and suggestions here. Please
>>> take a look and let me know what you think.
>> By the way, thank you fantasai, for working these ideas into the  
>> draft.
>> Here are some thoughts and edit suggestions I came up with  
>> (additions in green, if you are reading this with rich formatting):
>
> Your formatting seems to be incorrectly applied. Anyway.

Blame Hyatt's company. I was using mail.app on a Mac and it sometimes  
does unpredictable things with pasted in HTML formatted text.

>>> If a slash is present in the property value, the one to four  
>>> values immediately after it specify the border-image widths:  
>>> offsets that are used to divide the border-image area into nine  
>>> parts. If the keyword ¡®border-width¡¯ is given after the slash in 
>>> stead of length values, then the image sections are scaled to th 
>>> e corresponding border-width. If a slash is not present or if th 
>>> ere are two slashes with no value between them, then the offsets 
>>>  are found from the intrinsic sizes of the image slices, with on 
>>> e CSS pixel per image pixel for raster images (resolution specif 
>>> ied in image is ignored). If a percentage is given instead, then 
>>>  the images slices are scaled by that amount from the intrinsic  
>>> size. If the image does not have the required intrinsic dimensio 
>>> ns, then the appropriate border-width is used instead.
>
> I disagree with these changes. Firstly, the resolution mapping of
> one px per image pixel should not be defined here. In general this is
> how images are rendered in CSS, but there are proposals out there
> that would allow an explicit resolution to be applied or the image's
> own resolution to be used, and this text would conflict with those.
> Secondly, if you want a higher-resolution image, using those proposals
> and true high-res images would be much better than applying a squeeze
> factor in border-image.
>
>> I think that if we are looking for ways of simplifying this, we  
>> should seriously consider discarding the 4 lengths after the slash  
>> idea. It seems to me that it would be exceedingly rare that authors  
>> would need anything other than 'border-width', intrinsic  
>> dimensions, or a single scaling value of either percentage (such as  
>> 50%) or factor (such as .5).
>
> I would prefer to wait until implementors complain that lengths are
> more complicated than they're worth. I'm not convinced that it's a
> good idea to take them out.

As an author it seems more complicated than it's worth. As to  
resolution, I'm OK with not having it be part of the spec, if it's  
generally understood that that's what happens outside of any  
resolution property. But it should be easy to scale the image with a  
single number or percentage, which would result in a change of image  
resolution. Explict length measurements, instead of just a keyord or  
scaling factor (percentage of intrinsic or your multiplier of border- 
widths), are just unnecessary, as are per-side values. When would you  
ever need that in practice, if you can base everything on the slice  
size or border-width?

>> And using the border-width is such limited usefulness (only for for  
>> thickness-scalable patterns, with corner sections no bigger than  
>> the border-width), that it should not deserve the word "auto",  
>> especially since there is automatic behavior for when the value is  
>> omitted (intrinsic dimensioning).
>
> There's no 'auto' keyword in the draft, there was just that snippet
> of a sentence I hadn't deleted yet.
>
> Instead of a 'border-width' keyword I added numbers. So if you just
> wanted to fill the border-width, you'd specify
>  border-image: url(...) 25% / 1;

That's fine with me.

>
> But if you had fancy corners, say, a looped corner that's twice as  
> thick
> as the border,like this:
>
>       ##
>       ##########
>        #
>        #
>        #
>
> you could make the border-image scalable like so:
>
>  border-image: url(...) 25% / 2 / 1;
>
> This says to make the border-image area twice as wide as the border- 
> width
> (so that the colored part of the image border is exactly as wide as  
> the
> border-width), and then to outset it by the border-width (which  
> places the
> loops outside the border box).

I understand now. That's a good argument for that.

>>> If two opposite border-image widths are large enough that they  
>>> overlap, then their used values are proportionally reduced until  
>>> they no longer overlap.
>> Does this mean that if the left width is 300px and the right width  
>> is 100px, that they are both reduced by the same percentage in  
>> order to maintain that 3:1 ratio? I was actually imaging that they  
>> would be reduced by the same number of pixels so that they would  
>> just meet in the
>
> Yes, they would maintain the 3:1 ratio. That is more likely to  
> preserve
> the intended effect: it only shrinks the end result, instead of
> distorting it. (Imagine in your example that the box is only 300px  
> wide.)
>
>> middle, but I'm not sure which way is better. In either case, we  
>> should be explicit, including what side an extra pixel should go on  
>> if the image is not evenly divisible that way.
>
> The CSS specs don't specify pixel rounding behavior.

OK.

>>> Negative values are not allowed for any of the border-image values.
>> It's occurred to me after watching the thread about animations/ 
>> transitions that a negative value could be useful for animated or  
>> transition effects, especially if the "overshoot and bounce back"  
>> effect is possible.
>
> Ok, but I'd like Hyatt's take on this before making a change.

Sure.

>
>
> ~fantasai

Received on Friday, 10 April 2009 20:35:38 UTC