Posts from Wednesday, January 26th, 2011

Reset v2.0

Published 14 years, 5 months past

Earlier today, I updated the CSS Tools: Reset CSS page to list the final version of Reset v2.0, as well as updated the reset.css file in that directory to be v2.0.  (I wonder how many hotlinkers that will surprise.)  In other words, it’s been shipped.  Any subsequent changes will trigger version number changes.

There is one small change I made between 2.0b2 and 2.0 final, which is the replacement of the “THIS IS BETA” warning text with an explicit lack of license.  The reset CSS has been in the public domain ever since I first published it, and the Reset CSS page explicitly said it was, but the file itself never said one way or the other.  Now it does.

Thanks to everyone who contributed their thoughts and perspectives on the new reset.  Here’s to progress!


Border Imaging Redux

Published 14 years, 5 months past

To follow up on my border-image post from Monday, it turns out that as currently written, border-image literally cannot take an image of a single symbol and repeat it around the border of an element.  Instead, you have to create an image with at least eight copies of the symbol in a 3×3 grid pattern.

Note that allowing a 3×3 grid pattern for border-image is potentially very useful, as it permits the creation of sophisticated border ‘frames’ with a single image.  The objection I have is that it’s required, even in simple cases like the one I described in the previous post.

The reason this 3×3 pattern is required is found in the description of border-image-slice, which states:

The regions given by the ‘border-image-slice‘ values may overlap. However if the sum of the right and left widths is equal to or greater than the width of the image, the images for the top and bottom edge and the middle part are empty, which has the same effect as if a nonempty transparent image had been specified for those parts. Analogously for the top and bottom values.

That means that if you specify, for example, a slice distance of 100% (the default) then the top, bottom, and side portions of the border will be completely empty.  Only the corners will get the image.  The same thing will happen in any case where the sum of two slices along the same axis exceeds the dimension of the image along that same axis.  In other words, if the defined left and right slice distances add up to more than the width of the image, then both slices are made completely transparent.  Ditto for top, bottom, and height.

It seems to me that the easy way to make it possible to repeat a single-symbol image is to change that bit to instead say something along these lines:

The regions given by the ‘border-image-slice‘ values may overlap.  Values greater than the intrinsic dimensions of the image are “clipped” to the intrinsic dimensions of the image.  Values greater than 100% are treated as 100%.  Negative values are treated as 0.

Or maybe going beyond 100% or the image dimension means filling the remainder with transparency—I’m not sure yet which would be better.  I’d be interested to know if anyone has a compelling use case for the “fill transparent past 100%” behavior.

Anyway, when I raised the beginnings of this as a possibility on www-style, I was told that an “older and less mature” draft did exactly that, but it was at some point changed to the current behavior.  My inquiry as to the reasons for that change have so far been met with silence, so if necessary I’ll raise it again in a few days.

Commenters found that WebKit browsers can be made, with a very specific value pattern, be made to repeat a single-symbol image all the way around a border.  It turns out that’s only because WebKit implements the earlier version of the specification and it hasn’t since been updated.  Personally, I hope it retains its behavior (with improvements to make it less finicky) and the other rendering engines change to match it, not the other way around.  But to make that happen, I suspect the spec will need to be changed.  Here’s hoping.


Browse the Archive