Wednesday, August 13th, 2008
border-image: No more cutting up hell
>Remember when you wanted a growable area with rounded-goodness and you had to cut up the image into a million pieces to have the top corners and the sides? Since then we have gotten nice effects to help us, and John Resig just posted on how Firefox 3.1 will implement what WebKit already has in the border-image CSS 3 magic:
Now you can create the iPhone search button that iUI contains, using the simple CSS:
-
-
border-width: 0 5 0 5;
-
-webkit-border-image: url(toolButton.png) 0 5 0 5 stretch stretch;
-
-moz-border-image: url(toolButton.png) 0 5 0 5 stretch stretch;
-
Here you see the reusable button on the left, that will stretch and become the button on the right:
![]()
Next up, rounding the borders themselves in all browsers (border-radius!)
Related Content:











How is this “CSS3″ when the properties are mox and webkit specific?
Errr “moz”
@commadelimited: It’s part of the current CSS3 Background and Borders working draft. When the draft reaches status of Recommendation, the browser-specific prefixes can be dropped.
Hmm.. Seems to also stretch the colors lighter. Likely by a function of the stretch width, this will make all buttons with the same img but diff widths look inconsistent. Let’s hope I’m missing something or that they get that fixed.
Nice thing about targeting iPhone (as it appears the example does) is that it is a single platform. No worry about different browsers (though, you do have to worry about the difference between 1.0 and 2.0 software (though x2, 2.0 software, and future software updates, may become ubiquitous rather quickly due to Apple’s method of propagation)).
Very nice but this highlights a problem with the naming of non standard properties.
Firefox should simply recognize the -webkit-border-image one instead of forcing us to add another line to our css files for -moz-border-image.
In other words: the first browser to implement a property should get credit and give it the name it wishes. The other browser should use it and eventually drop the browser specific name when the property gets approved.
What I don’t want to see is css files like this
-webkit-border-image: url(toolButton.png) 0 5 0 5 stretch stretch;
-moz-border-image: url(toolButton.png) 0 5 0 5 stretch stretch;
-opera-border-image: url(toolButton.png) 0 5 0 5 stretch stretch;
-ie-border-image: url(toolButton.png) 0 5 0 5 stretch stretch;
It’s verbose, it’s redundant, it’s error prone: it’s a bad practice.
Why can’t both just support something like
-css3-border-imageinstead of making us type out the individual rendering engine? I understand theres some places where there might be overlap, but the webkit and mozilla teams should collaberate to eliminate those.There’s a reason for it. -vendor- are necessary because the draft versions might not behave like the final version and specifically might not even behave the same in different browsers. And we all want to avoid something like we have in HTML were we have totally different properties (i.e. -msie-width vs width) that have the same name.
The reason for the -vendor- prefix, as Hans Schmucker sort of explained, is that it is a vendor-specific implementation even if it conforms to the draft, until the spec is out of draft. If FF 3.1 implements this as it is described in the draft, and the draft is edited and made official tomorrow, then 3.1 has a non-standard implementation until it is updated to the new spec and takes 3.1′s market share.
As a matter of fact, webkit and firefox implementations of border-radius are different. There are some (obscure) combinations of parameters that are interpreted differently.
border-width does not take integer values, fwiw. (With a no-quirks parser that rule would be ignored.)