778137 - Applied border-image property value does not contain "stretch"

Status: NEW

(Core :: CSS Parsing and Computation, defect)

Description

[daniel.wagner]

User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.2 (KHTML, like Gecko) Chrome/22.0.1215.0 Safari/537.2

Steps to reproduce:

Create a new Div element:
var el = document.createElement("div")

Set the border-image style property, specifying "stretch" as the border-image-repeat value:
el.style.borderImage = 'url("foo.png") 4 4 4 4 fill stretch';

Query the applied value:
console.log(el.style.borderImage);


Actual results:

Console output reads:
url("foo.png") 4 4 4 4 fill


Expected results:

Console output should read:
url("foo.png") 4 4 4 4 fill stretch

Comment 1

[Loic]

Mozregression range:

m-c
good=2012-05-31
bad=2012-06-01
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3aa566994890&tochange=73783bf75c4c

m-i
good=2012-05-30
bad=2012-05-31
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8f8639307984&tochange=ff2ad97929e8

Suspected bug:
Bug 713643 - [css3-background] fix followup issues from bug 497995 and unprefix border-image property

Comment 2

[Boris Zbarsky [:bzbarsky]]

"stretch" is the initial value of border-image-repeat.  So the values

  url("foo.png") 4 4 4 4 fill

and

  url("foo.png") 4 4 4 4 fill stretch

mean exactly the same thing, and serialization will typically choose the shortest serialization that produces an equivalent result.

Is this being a problem in the wild for some reason?

Comment 3

[Tobias Tost]

At least our framework is using this check to test if the background-image-repeat property of CSS is standard or not - all browser up to FF 16 were "echoing" the value "stretch" even if it was default and http://www.w3.org/TR/css3-background/#border-image-repeat proposes that this values has to be treated "as specified" which might mean "if there's stretch specified it should be shown even if it is the default value".

Comment 4

[Boris Zbarsky [:bzbarsky]]

That's not what "as specified" means, for what it's worth.  It just means that the computed value is the same as the specified value.  Which is irrelevant here, because you're reading the specified value, not the computed value.

How widely deployed is this framework?  What happens when it doesn't see the "stretch" there?

Comment 5

[Tobias Tost]

If stretch can't be read back, the qooxdoo framework does assume that the browser has non-standard background-image-repeat implementation and thus skips the property (which results in background-images not filling the elements as intended). 

I'm just curious why this particular element CSS behaves different with FF 16 (current Aurora) and if it is intended. 

I know that this issue applies at least for some of our inhouse products (C&C Tiberium Alliances and Lord of Ultima) - Daniel might give more insight from a 1&1 perspective? Since it only happens related to background images it might not appear as often in the everyday web app.

Comment 6

[Boris Zbarsky [:bzbarsky]]

I assume you meant "border", not "background"?

The behavior is different because the old behavior wasn't the one all other CSS properties have, and it was very much intended.  The first patch in bug 713643 changed the behavior.

Why is the framework basing something on value serialization (which is undefined in CSS in general, so far, and should never be relied on) instead of just checking whether the property is implemented unprefixed? :(

Comment 7

[Tobias Tost]

Yes, I meant border - sorry about that. The framework-question might hopefully be answered by Daniel - I just rely to it to some degree. ;)

Comment 8

[daniel.wagner]

Unfortunately, we can't assume a standards-compliant implementation just because an unprefixed property is supported. Standards change and we need to support a wide range of browsers. In this case, at some point earlier this year both WebKit and Gecko supported border-image unprefixed but one of the two (I forget which) wouldn't draw the image if the "fill" keyword was used for border-image-slice.

If we can't rely on the serialized border-image value, could we use getComputedStyle and check the individual properties like border-image-slice, border-image-repeat etc. instead? That would solve the problem on our (and Tobias') side.

Comment 9

[Boris Zbarsky [:bzbarsky]]

We unprefixed the border-image property after we made the change to serialization.  In fact, that change was a prerequisite for unprefixing, as you can see in bug 713643.

So there hasn't even been a final release of Gecko with the property unprefixed so far.

> If we can't rely on the serialized border-image value, could we use getComputedStyle and
> check the individual properties like border-image-slice, border-image-repeat etc.
> instead? 

You don't even have to get computed style.  If all you care about is whether border-image-repeat is specified as "stretch", then just check the specified value of that property.

That said, it sounds like you're using that as a proxy for some totally different thing (support for "fill" as a value of border-image-slice?  Hard to tell, because the previous claim about both WebKit and Gecko having the property unprefixed is wrong as far as I can tell).  Can you directly test the thing you actually care about?

And again, how widely is this framework deployed?  Even if you fix things now, if this is widely used we might have to break the implementation to deal with the hackery going on.  :(

Comment 10

[daniel.wagner]

(In reply to Boris Zbarsky (:bz) [In and out Aug 1 - 10, out Aug 11-20] from comment #9)
> That said, it sounds like you're using that as a proxy for some totally
> different thing (support for "fill" as a value of border-image-slice?  Hard
> to tell, because the previous claim about both WebKit and Gecko having the
> property unprefixed is wrong as far as I can tell).  Can you directly test
> the thing you actually care about?

You're right, I misremembered. Aurora 12 implemented changes in the border-image spec but kept the prefix. So we added that check to deal with the discrepancies between -moz-border-image and -webkit-border-image. Of course since the changes were rolled back, that check is no longer necessary and we can use the same values for all prefixed implementations. For non-prefixed implementations, we can test the individual properties as you suggested.

> 
> And again, how widely is this framework deployed?  Even if you fix things
> now, if this is widely used we might have to break the implementation to
> deal with the hackery going on.  :(

That shouldn't be necessary. We're going to publish a patch release of the qooxdoo framework in mid/late September to address this and probably some IE10-related issues.

I have no way of knowing how widely qooxdoo is used. It's OSS and it doesn't phone home or anything.

Comment 11

[Lukas Blakk [:lsblakk] use ?needinfo]

Boris, what do you think we should do if we've only got 2 weeks left to deal with this?

Comment 12

[Boris Zbarsky [:bzbarsky]]

David is probably a better choice to ask, but my gut feeling is to not change anything here....

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Yeah, I agree we shouldn't change anything here.

(Also see http://dbaron.org/log/20120612-border-image , which describes what authors should have to change in response to unprefixing.)

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to daniel.wagner from comment #10)
> That shouldn't be necessary. We're going to publish a patch release of the
> qooxdoo framework in mid/late September to address this and probably some
> IE10-related issues.

mid/late September seems problematic, though.  Firefox 15 is expected to ship on August 28; it would be good if users of the framework had the chance to update it *before* then.

Comment 15

[Lukas Blakk [:lsblakk] use ?needinfo]

Untracking if there's nothing we're going to change here.