On Mon, Mar 30, 2009 at 8:22 PM, Brad Kemper <brad.kemper@gmail.com> wrote: > On Mon, Mar 30, 2009 at 5:56 PM, Tab Atkins Jr. <jackalmage@gmail.com> > wrote: >> On Mon, Mar 30, 2009 at 7:21 PM, David Hyatt <hyatt@apple.com> wrote: >> > I'm actually inclined to disallow negative offsets for the border-image >> > box >> > now that I've thought about it some more, since there is no way an inset >> > box >> > can actually respect the original border shape. By disallowing negative >> > offsets, we'd help make that clear, i.e., that the intent of expansion >> > is >> > for visual frills outside the original border shape, and not to just >> > draw >> > some arbitrarily different shape. >> >> Eh, I disagree. A negative offset is effectively identical to just >> adding extra transparent space around the edge of the image, and >> increasing the slice depths appropriately. I don't know if the >> 'lesson' here is important enough to drive home that we need to >> disable an ability and force authors to hack around it when required. > > The transparent pixels might be used as a sort of hacky way of inserting > some extra fake non-collapsing margin (kind of like you can with a > transparent border-color), but I think you could easily get exactly the same > effect by having some transparent pixels on the outside of your image. I've > tried to imagine some other reason to have negative offsets, generally > subscribing to the notion of some future unimagined use being a good thing > for solving unusual problems, but I can't really see a compelling reason to > have negative offset. You can still create cool "inside border" effects, > like inner shadows or 3-d effects, without it. Well, that's basically what I'm saying. Negative offsets are effectively identical to just adding more transparent space around your image. Unless handling a negative offset is difficult programatically, I'm not seeing why it should be disallowed - if it *is* disallowed, the author can get around it trivially. Might as well make it available more easily, then. ~TJReceived on Tuesday, 31 March 2009 01:48:46 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 18:16:07 GMT