W3C home > Mailing lists > Public > www-style@w3.org > February 2011

Re: 'border-image' confusion [css3-background]

From: Brad Kemper <brad.kemper@gmail.com>
Date: Thu, 10 Feb 2011 23:30:00 -0800
Message-Id: <A067F7D3-FF36-4A44-8A86-4A577FB1AB32@gmail.com>
Cc: Simon Fraser <smfr@me.com>, "Eric A. Meyer" <eric@meyerweb.com>, "www-style@w3.org" <www-style@w3.org>
To: "Tab Atkins Jr." <jackalmage@gmail.com>

I'd like this to be made clear in in CSS3 B&B, so as not to have a dependency on an working draft when we take it to CR. 

On Feb 7, 2011, at 10:03 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> On Mon, Feb 7, 2011 at 9:55 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> On Feb 7, 2011, at 9:18 AM, Tab Atkins Jr. wrote:
>>> On Mon, Feb 7, 2011 at 8:26 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>>>> Actually, I'm not seeing anything in Backgrounds & Borders 3 that says how to dimension an image that has no intrinsic dimension. It should be the same size as the border image area[1]. Maybe we need to say that somewhere, or say it more explicitly if it is implied in there somewhere and I'm just missing it.
>>> The Images spec says what to do.
>> But only in the working draft and editor's draft, right? I'm thinking that BB3 is likely to hit PR sooner than Image Values spec. In BB3, it is made clear, with exacting language, what to do for 'background-size' if the image has no intrinsic dimensions. But it does not have that same sort of clear language within the same spec about using such an image as a border image.
> Sure, sounds reasonable.  Just make sure we're consistent, then.  ^_^
> (Personally, I don't see anything particularly wrong with an
> informative note that the treatment of dimensionless images is handled
> in another spec.  It just means that it's not testable in B&B, but
> will be testable in Images.  But I don't object to specifying the
> behavior in B&B, either.)
>>>> I have a concern about 'border-image-slice'. It doesn't seem to say anything about images without intrinsic dimensions if a <number> is the value. The spec says that "Numbers represent pixels in the image (if the image is a raster image) or vector coordinates (if the image is a vector image)." I don't think that gradients have vector coordinates, and counting pixels from all four sides also doesn't make sense. I think that what would make the most sense for dimensionless images (such as border-image-width) is to make any 'border-image-slice' <number> or <percentage> ignored, and just make it automatically the same as 'border-image-width'.
>>> Sounds good for <number>s.  I don't see any reason to ignore
>>> <percentage>s, though - they seem to be sufficiently well-defined in
>>> both the properties that allow them (-slice and -width).
>> Well defined, but not useful. Anything that causes the 'border-image-slice' to be different from the 'border-image-width' results in a distorted  gradient. It's hard for me to say if it would be useful for some other hypothetical dimensionless image without vector coordinates.
>> I'd be OK with leaving percentages alone, I guess. But there doesn't seem to be a compelling reason for them to work that way on gradients, other than consistency with dimensionful image percentages (instead of consistency with dimensionless <numbers>s if we change that).
> Okay.  I don't have a strong opinion, I just wanted to make sure I
> wasn't missing anything.  If it's an aesthetic judgement, and you
> don't feel there's a strong use for the other way, then that's cool.
> ~TJ
Received on Friday, 11 February 2011 07:30:40 UTC

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