Re: [css3-background] What does 'border-image-slice: <number>' mean for SVG?

Sent from my iPad

On Sep 11, 2011, at 9:33 AM, "L. David Baron" <dbaron@dbaron.org> wrote:

> http://dev.w3.org/csswg/css3-background/#border-image-slice says:
>  # <number>
>  #     Numbers represent pixels in the image (if the image is a
>  #     raster image) or vector coordinates (if the image is a
>  #     vector image). 
> 
> I'm not sure what "vector coordinates" are, for example in the case
> of SVG.  I'm guessing that for SVG with a viewBox or with an
> intrinsic size, this means that the image is drawn at its intrinsic
> size and these "vector coordinates" are coordinates in the viewport
> coordinate system.  (But if it has both a viewBox and height/width
> attributes on the root, which win?  Is it CSS pixels on the root's
> container, or the viewport coordinate system?)  It might be good to
> clarify that, though.

I don't know the answer to that one, as I'm not clear where the term "vector coordinates" came from. Maybe fantasai knows. 

But what happens if the SVG doesn't have an intrinsic size or
> 
> doesn't have a viewBox?  What size is the SVG drawn at in order to
> determine the slices?

For images without an intrinsic size, please see this discussion at http://lists.w3.org/Archives/Public/www-style/2011Feb/0347.html

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