[css-borders] accept "px" for pixel values in border-image-slice

[jsnkuhn]

Currently border-image-slice only allows pixel values to be used through unit-less number values. I'm guessing there was a reason for this but in practice I have found it just confuses people and leads to them not using border-image.

The only concern is that there might be border-image code lying dormant on pages because folks just couldn't figure out why it wasn't working with a "px" value on pages. If folks left in to deal with later it would just start working if "px" support was added. If all of the border-images values were not worked out because they couldn't get the image to show things might appear broken in these cases.

https://www.w3.org/TR/css-backgrounds-3/#border-image-slice

[meyerweb]

The original motivation for this syntax, if I remember correctly, was to be useful for image formats that might not use actual pixels, such as SVG. So the idea was that they were abstract coordinates, not a length of some unit type. That said, I think accepting px units makes sense and can’t think of a particular reason not to do so.

[tabatkins]

I don't recall the exact reasoning, but I'll note that SVG's "abstract units" are just px anyway in CSS, so yeah, we could just do that.

[SelenIT]

Will px mean CSS pixels rather than original image pixels for raster images on high-density (Retina-like) screens?

[fantasai]

If we allowed a <length> then my expectation would be that it represents that length at the image's native resolution. That means px units wouldn't correspond to image pixels, and that would probably be quite confusing. So I don't think we should do this.

[fantasai]

(Also css-backgrounds-3 is basically a REC that's just missing an implementation report so definitely anything other than an error correction goes in css-backgrounds-4.)

[jsnkuhn]

I'm still confused. What is fundamentally different about border-image-slice that it requires this unit less value? border-width: 1px; doesn't seems to cause any confusion. Even other instances where images are used, like spiriting background images, don't use the unit-less value and there doesn't seem to be an issue?

[SebastianZ]

I believe it makes sense to allow pixel values in that case as well. As @jsnkuhn pointed out earlier, the CSS pixels vs. image pixels applies in other situations as well, so authors should already be aware of that.

Sebastian

[dbaron]

The basic difference here, I think, is that these values are intended to be image pixels, not CSS pixels. These are fundamentally different thing.

The example of background image spriting using background-position is different -- in that case the use of background-size would scale the image and thus change what the background-position values mean in terms of image pixels. In this case things that scale the image do not change the offsets within the image because they are offsets of image pixels, not offsets in terms of CSS lengths.

[css-meeting-bot]

The CSS Working Group just discussed [css-borders] accept "px" for pixel values in `border-image-slice` , and agreed to the following:

• RESOLVED: Not going to use the pixel unit for the pixel value in border-image-slice

The full IRC log of that discussion

<Frances> Sebastian: Suggested to allow pixel unit for border-image-slice. For authors it is easier to express in pixel values.
<emilio> q+
<TabAtkins> q+
<Frances> Sebastian: Pixel unit is meant for CSS pixels, from an authors perspective it looks weird to have a unitless number for slicing. Would like to possibly introduce a pixel unit.
<astearns> ack emilio
<Frances> Emilio: Is there a use case for a non pixel length?
<Frances> Sebastian: Would just be pixels.
<kizu> q+
<astearns> ack TabAtkins
<Frances> Emilio: Either come up with a different unit and use calc() with it, or treat pixels as arbitrary lengths.
<Frances> Emilio: Slightly against
<emilio> emilio: it'd be unfortunate if e.g. the zoom property affected this
<Frances> Tab: Also slightly against. Pixels to allowed but not others, can put px at the end of a number but nothing else, could end up being confusing.
<astearns> ack kizu
<SebastianZ> q+
<Frances> Roman: For non pixels in any length is if using css gradient and slice using the same thing for the stop of the gradient.
<astearns> ack SebastianZ
<Frances> Roman: Might not be worth introducing a change.
<Frances> Sebastian: Are there other use cases other than border-image-slice? If other use cases for a new pixel unit, could introduce in border-image-slice, until then, we can resolve not to add the px unit.
<Frances> Alan: Let's resolve
<lea> As Roman said, I do think `border-image` is rotten at the core and needs a complete re-architecting, but no cycles to work on that rn. I would weakly support this change, but it doesn't make much of a difference
<Frances> PROPOSAL: Not going to use the pixel unit for the pixel value in border-image-slice
<Frances> RESOLVED: Not going to use the pixel unit for the pixel value in border-image-slice
<Frances> Alan: If we find other use cases for it, we could consider adding it to border-image-slice. Work on a replacement for border-images.

[astearns]

I am going to close this issue because it is not likely that we will introduce an “image pixel” value for this particular case only. But if there are other use cases for representing image pixels in CSS values we could re-open this discussion.