rubberflat

July 11, 2010
In CSS

IE7 Gradient Filter Ignored on Block Elements

The fancy CSS3 properties available in webkit and firefox (such as border-radius, text-shadow, box-shadow and browser generated gradients) that people seem to want so much on their sites tend to make an identical user experience across all browsers near to impossible without bringing unnecessary images (unnecessary for modern browsers) back into the layout. If an identical experience is not desired, or perhaps not in the budget, a reasonable degradation of the eye-candy is expected and, for the most part, can come out usable and in good taste.

IE (<=8), naturally being the most common cause of acute sharp pain, is the browser to suffer most from new features of modern browsers. Surprisingly, however, the browser has been outfitted with a gradient generator since version 5.5 (circa June 2000.) It is not robust, by any means, but can help smooth some of the irregularities between the intended layout and the IE rendering of it.

To the point: IE7 does not render gradient elements properly in some cases. The gradient filter (and perhaps other filters as well – will need to test that) is not rendered for bock elements, <div>, <h1>, <p> tags, that do not have an explicit width set in CSS. Both IE7 and IE8 will not render a gradient on an inline element, but will for an inline-block.

If, for whatever masochistic reason, you are using IE7 or have it on hand you can look at a gradient demo that shows the IE7 gradient issue and a potential solution.

June 14, 2010
In Javascript

Refresh jQuery UI Droppable Area After Shifting Position

I’ve recently been adding drag and drop functionality, using jQuery UI’s draggable and droppable interactions, to a website with a potentially large number of listings on each page. In order to provide a good user experience it was decided that the drop area should be moved when a drag operation starts so our users aren’t left dangling the draggable at the top of the page as it slowly scrolls upwards to the drop area.

This worked great from a UI and UX perspective, but given that the drag and drop was initialized with the drop area at the top of the page the drop only worked properly if the top of the drop area lined up with the top of the drop receiver [Fig. 1]. Shifting the drop area after the fact left the drop receiver unaltered, causing it to appear inactive [Fig. 2]. Or worse, if the shift was minimal, the drop area would overlap the drop receiver in an incorrect area and cause improper results (if there are a number of distinct listeners in the drop receiver area.) [Fig. 3]

An attempt to destroy and re-initialize the drop zone using both $(droppables).droppable('disable');$(droppables).droppable('enable'); and $(droppables).droppable('destroy');$(droppables).droppable(); did not have the desired effect – the position of the drop receiver had not been refreshed.

An option would be to use refreshPositions on a draggable object, but refreshing the positions on every mouse move would be a little much. However, peeking under the hood in refreshPositions reveals a $.ui.ddmanager.prepareOffsets function that takes two parameters. The first is either a collection of elements returned by a jQuery selector (ones already initialized for dragging) or a set of elements internal to the drag and drop plug-ins. Since the function is called externally, we’ll make use of the former:

$('.drag-elt').draggble({
    start: function(e, ui) {
        $.ui.ddmanager.prepareOffsets(
            $(e.target).data('draggable'), e
        );
    }
});