The problem is that although we can now make pages fluid and adaptable to the browser/device width they are still just “pages.” There is a basic canvas on which we lay everything out, a paradigm still left over from the world of print. Things get better with a responsive grid but it needs to be more granular.

A case study
I have an item with an image and some text. The image is a particular width (or percentage) and is floated left. To the right is the related text which fills the remaining space and does NOT wrap.

This is fairly easy to make flexible:

<div class="item">
<div class="image"><img src="img.png" /></div>
<div class="text"><p>Bacon ipsum....</p></div>
</div>

.image {
   float: left;
   width: 19%;
   margin-right: 1%
}
.text {
   float: left;
   width: 80%;
}

The flaw here is that in order to create the layout that doesn’t wrap the text container must have a width. This means both the image and the text have to have percentage widths or the float will break.
Of course as the page gets thinner the 19% width image is going to get smaller and smaller and become unclear. So let’s add a media query. When things get too small let’s stack them but have the image fill the whole width:

@media only all and (max-width: 320px) {
    .image {
        float: none;
        width: 100%;
        display: block;
        margin: 0 0 4px 0;
    }
    .text {
        float: none;
        width: 100%;
        display: block;
    }
}

This is all well and good when the item fills the whole page. But this is not print. This is the web, and on the web we like to reuse code. So what happens when I want to put the same module here:

Or here:

Media queries only target the ‘media’ and therefore the browser window. When I put the same module into a smaller container I would like the media query to kick in, but unfortunately the browser window is still bigger.
Surely there is a need for context specific query. When this module is this size on the page, do this, irrelevant of the wider page.

This brings me onto the current debate around the Responsive Image Element

There is certainly a need to be able to swap out images for larger versions. This way when taking the mobile first approach you can set the img src to a low resolution, low kilobyte image by default and have a bigger one download instead when required.
The current proposal by WHATAG is the <picture> element:

<picture alt="">
<source src="mobile.jpg" />
<source src="large.jpg" media="min-width: 600px" />
<source src="large_1.5x-res.jpg" media="min-width: 600px, min-device-pixel-ratio: 1.5" />
<img src="mobile.jpg" />
</picture>

This uses recognisable syntax with the media attribute and elements similar to the <video> element. The issue is the use of media will put us into the same trap as before; the size of the browser is not necessarily related to the size of the image. Take a look at the layout of boxes on my homepage. As you make your browser window smaller the boxes adjust from three columns to one column. The images in those columns get smaller, then bigger, then smaller again. The <picture> element doesn’t cater for this scenario in a very scalable manner.
The alternative proposal is adding a set attribute to the <img> element:

<img src="face-600-200@1.jpg" alt="" set="face-600-200@1.jpg 600w 200h 1x, face-600-200@2.jpg 600w 200h 2x, face-icon.png 200w 200h"/>

Although the syntax is unusual, if the widths/heights declared in the attribute are the current width of the rendered element and are not relevant to the screen width then this could work out to be a more useful way of doing responsive images.

I shall be watching the outcome of the debate with much interest.

You’re probably well aware of responsive web design; a principle where you no longer build your website to a fixed 960 pixels wide, but allow it to adapt and flex to fit wherever it happens to be.

There is a massive range of screen sizes from phone to smart phone to tablet to desktop and even black and white devices like the Amazon Kindle. Each of these comes with their own set of challenges but it looks like there is a new kid coming up on the block.

Windows 8 offers a radically new desktop/tablet experience and will support a range of hardware devices. Application developers for windows 8 will need to be aware of scaling for different screens.

Note: At the time of writing Windows 8 is still in Consumer preview so any of this is subject to change before general release.

Internet Explorer 10

In testing Internet Explorer 10 on Windows 8 I noticed that when you snap a site to the side the page was simply zooming out making it unreadable. It was quite a challenge to discover why but it appears that Internet Explorer 10 zooms the page out when the width is less than 1024px. This may also affect portrait orientation but I am unable to confirm at present as I have the preview on my standard laptop.

This effect is irritating for those who spent a fair bit of time and effort working on their responsively designed pages. You can see the effect on this demo page. A picture of what happens is shown below:

Excuse the photograph; I couldn’t get a screenshot in Windows 8 + Mac keyboard.

The site on the left is zoomed out and unusable.

Solution

As I discovered buried in the device adaptation page there is a simple solution that tells Internet Explorer 10 to disable its automatic scaling and adhere to your responsive designs. Simply add the following to your CSS file:

@-ms-viewport { width: device-width; }

You can see this in action in the second demo page. The change has produced the desired effect in a snapped window (on the left):

Update: necolas makes a good point that it is not optimal to have to do this and it should be considered an IE10 bug. Further discussion here

However I’ve been bitten by an interesting quirk when using transparency in gradients. You’d expect that to create a gradient which fades out from a certain colour you’d just use:

background: linear-gradient(top,#FFFFFF 0%,transparent 100%);

See Example 2 for a working demo.

The effect is not as desired as browsers do not treat the value [transparent] as you might intuitively expect. The CSS3 colour spec states that [transparent] can be considered a shorthand for transparent black, rgba(0,0,0,0).

Therefore the browsers are actually fading from white to black independently to fading from opaque to transparent. If you are not aware of this then it’s easy to end up with the ugly grey in the middle of your gradient. The CSS3 Images spec (Last Call Working Draft as of 11th Feb 2012) shows how this should not be the case. At present only Opera appears to use premultiplied values and behave correctly, fading out without going via black.

Update: IE10 (the first version of IE to support gradients) also behaves correctly for this. End Update

Workaround
Until the browsers support the correct implementation the simple (obvious) workaround is to resort to rgba. This isn’t too much of a drawback as rgba is supported in all the browsers that support gradient backgrounds. You just need to remember that the red,green and blue values are the same in both stops and the alpha value changes from 1 to 0.

background: linear-gradient(top,rgba(255,255,255,1) 0%,rgba(255,255,255,0) 100%);

See example 3 on the demo page for a live example

Therefore the safest idea is to truncate back to the nearest space. The code below is a Zend View Helper, constructed in a way to read cleanly in the page. It’s use in a Zend View is as follows:

< ?$string = 'Hello People';?>
< ?=$this->truncate($string)->toLength(10)?>
< ?=$this->truncate($string)->toLength(10)->withPostfix('--')?>
< ?=$this->truncate($string)->midword()->toLength(10)->withPostfix('--')?>

As each method returns itself they can be chained together. The above outputs;

Hello…
Hello--
Hello peop--

Methods

toLength($int) - the max string length to cut to
midword() - disable the safe truncation (probably not recommended) withPostfix($string) - replace the default postfix (...) with $string

Full class code

< ?php
class Zend_View_Helper_Truncate extends Zend_View_Helper_Abstract {
        private $_string;
        private $_length;
        private $_postfix;
        private $_cutatspace = true;

        public function truncate($string) {
            $this->_string = trim($string);
            $this->_defaultValues();
            return $this;
        }

        private function _defaultValues() {
            $this->toLength(100);
            $this->withPostfix('&#0133;');
         }

        public function midword() {
            $this->_cutatspace = false;
            return $this;
        }

        public function toLength($int) {
            $this->_length = (int) $int;
            return $this;
        }
        public function withPostfix($str) {
            $this->_postfix = $str;
            return $this;
        }

        public function render() {
            // Return empty string if max length < 1
            if ($this->_length < 1) {
                return '';
            }

            // Return full string if max length >= string length
            if ($this->_length >= strlen($this->_string)) {
                return $this->_string;
            }

            // Return truncated string
            if ($this->_cutatspace) {
                while (strlen($this->_string) > $this->_length) {
                    $cutPos = strrpos($this->_string, ' ', -1);
                    if ($cutPos === false) {
                        // no spaces left, whole string truncated
                        return '';
                    }
                    $this->_string = trim(substr($this->_string, 0, $cutPos));
                }
            } else {
                $this->_string = trim(substr($this->_string, 0, $this->_length));
            }
            return $this->_string . $this->_postfix;
        }

        public function __toString() {
            return $this->render();
        }
}

Update 11/02/2012: Steve noted an issue with this helper. I have updated the code above based on his suggestion. Thanks Steve.

Update 27th March 2012: The Google Maps Geometry library now contains a containsLocation method which will achieve the same thing as detailed below. I’d recommend you use that instead.

Discovering whether a point on a map is inside a polygon can be very useful, especially now that modern browsers and phones are location aware. If you can tell if your user is within a specific boundary then you can present them with immediately relevant information. An example I have used is telling the user they are in the coverage area of a local business (Gascall).

Assuming you’ve already set up your map, the Google maps API allows you to create polygons using simple code.

var path = [
    new google.maps.LatLng(51.73383267274113, -1.03271484375),
    new google.maps.LatLng(51.45400691005984, -1.4501953125),
    new google.maps.LatLng(51.83577752045251, -0.8843994140625)];
    var polygon = new google.maps.Polygon({path:path, clickable:false});
    polygon.setMap(map);

You can create a Google maps point from latitude/longitude values or the users location:

if (navigator.geolocation) {
    navigator.geolocation.getCurrentPosition(function(position) {
        var point = new google.maps.LatLng(position.coords.latitude, position.coords.longitude);
    });
}

Determining if the point is inside the polygon

The google maps api does not already provide a method for checking points in polygons. Some research has already been done on this, but I couldn’t find a complete solution in Google maps api v3 that also catered for crossing 180 degrees longitude. I would have done a straight translation into Google maps api v3, but decided to actually try to understand what was going on.

After researching a bit I stumbled across the Ray-casting algorithm which will determine if an X-Y coordinate is inside a plotted shape. This will translate to latitude and longitude. The following extends the google.maps.polygon.prototype to use this algorithm. Simply include this code at a point in the code after google.maps has loaded:

 google.maps.Polygon.prototype.Contains = function(point) {
        // ray casting alogrithm http://rosettacode.org/wiki/Ray-casting_algorithm
        var crossings = 0,
            path = this.getPath();

        // for each edge
        for (var i=0; i < path.getLength(); i++) {
            var a = path.getAt(i),
                j = i + 1;
            if (j >= path.getLength()) {
                j = 0;
            }
            var b = path.getAt(j);
            if (rayCrossesSegment(point, a, b)) {
                crossings++;
            }
        }

        // odd number of crossings?
        return (crossings % 2 == 1);

        function rayCrossesSegment(point, a, b) {
            var px = point.lng(),
                py = point.lat(),
                ax = a.lng(),
                ay = a.lat(),
                bx = b.lng(),
                by = b.lat();
            if (ay > by) {
                ax = b.lng();
                ay = b.lat();
                bx = a.lng();
                by = a.lat();
            }
            // alter longitude to cater for 180 degree crossings
            if (px < 0) { px += 360 };
            if (ax < 0) { ax += 360 };
            if (bx < 0) { bx += 360 };

            if (py == ay || py == by) py += 0.00000001;
            if ((py > by || py < ay) || (px > Math.max(ax, bx))) return false;
            if (px < Math.min(ax, bx)) return true;

            var red = (ax != bx) ? ((by - ay) / (bx - ax)) : Infinity;
            var blue = (ax != px) ? ((py - ay) / (px - ax)) : Infinity;
            return (blue >= red);

        }

     };

Then to check a point:

var point = new google.maps.LatLng(52.05249047600099, -0.6097412109375);
var polygon = new google.maps.Polygon({path:[INSERT_PATH_ARRAY_HERE]});
if (polygon.Contains(point)) {
    // point is inside polygon
}

I hope this proves useful. Let me know if you have any suggestions/comments. Test page.

#div {
    background: rgba(0,0,255,0.7);
}

As elegant as that is, it is not currently an acceptable solution in it’s own right. RGBA is not supported in Internet Explorer below version 9. Of course the BBC needs to support the majority of it’s visitors. The phrase “it doesn’t need to look the same in every browser” could be thrown about, but in this case the semi-transparent boxes are quite essential for the look desired.

So, as any good web developer does, I turned to Google. I thought it would be a simple query (expected it to use IE filters) but it took unusually long to find it. Eventually I arrived at this blog post which proved helpful.

Alpha-transparent background code (quoted)

.alpha60 {
	/* Fallback for web browsers that doesn't support RGBa */
	background: rgb(0, 0, 0);
	/* RGBa with 0.6 opacity */
	background: rgba(0, 0, 0, 0.6);
	/* For IE 5.5 - 7*/
	filter:progid:DXImageTransform.Microsoft.gradient(startColorstr=#99000000, endColorstr=#99000000);
	/* For IE 8*/
	-ms-filter: "progid:DXImageTransform.Microsoft.gradient(startColorstr=#99000000, endColorstr=#99000000)";
}

BUT

There appeared to be a problem with this once we saw it in the wild. First you have to add zoom:1 to make it work in IE6-7 but this isn’t unusual. Secondly IE8 didn’t seem to work. As IE8 does support rgb() as a background colour the result is a solid coloured box.

Therefore we need to set the background back to transparent after the rgb rule (just in IE8 and below). After more Googling the answer was the backslash 9 hack.

Using that and tweaking (a lot) produced the following block of code. Note the -ms-filter line supported as IE8+ has been removed as it unnecessary. We have to use the non prefixed version anyway (for IE6,7) so the code is no more valid by using it in this scenario

#div {
    background:rgb(255,0,0);
    background: transparent\9;
    background:rgba(255,0,0,0.3);
    filter:progid:DXImageTransform.Microsoft.gradient(startColorstr=#4cFF0000,endColorstr=#4cFF0000);
    zoom: 1;
}

This fixed the transparency problem but there was a new issue. Internet Explorer 9 is capable of displaying rgba AND the filter property. This creates a doubling up of the transparency and ruining it’s effects. It appears there is no CSS attribute hack that targets only IE8 or IE9 and not both (that has been discovered yet).

The ideal solution here is to not use the filter in IE9. The CSS filters are memory intensive and since IE9 is fully capable of rgba, it should be rewarded as such. IE9 is capable of many CSS3 selectors so we’ll use one here:

#div:nth-child(n) {
    filter:none;
}

This is a valid CSS selector that will match all elements in the same way as if it was not here. More detail on how nth-child works.

This page shows various test scenarios

Full code

#div{
    background:rgb(255,0,0);
    background: transparent\9;
    background:rgba(255,0,0,0.3);
    filter:progid:DXImageTransform.Microsoft.gradient(startColorstr=#4cFF0000,endColorstr=#4cFF0000);
    zoom: 1;
}
#div:nth-child(n) {
    filter: none;
}

So that’s the code required. I’ve put it here as a complete solution to save other developers having to search and test as much as I had to. Of course it’s recommended to use conditional classes instead but sometimes that’s just not possible.

The only other thing that slows down creating alpha transparent backgrounds is the conversion from hex -> rgba and opacity -> hex so below is a handy converter. Enter a hex colour and opacity value and it’ll spit out the code in the form seen above.

I’ll accept any tweaks/improvements in the comments.

Who am I?

I am David Jonathan Marland and I am a web developer. My plan is to use this blog to put up snippets of code that may be of interest to others. I will also put up bits of photography as I like to play every now and then.

As you can tell this blog is quite plain at the moment and may even be slightly broken in places. I intend to over time evolve it by building a wordpress theme from scratch that is HTML5, responsive design (mobile first). I will document what I learn as I go, so keep following to see the changes.