website try-out fails to conform to it's own spec

Pasting the following query into the box

```
locations[?state > 'N'].name | sort(@) | {WashingtonCities: join(', ', @)}
```

returns:

```json
{
"WashingtonCities": "Bellevue, Olympia, Seattle"
}
```

whereas of course according to [spec](http://jmespath.org/specification.html#ordering-operators) (and indeed the official `jp` utility) the answer should be:

```json
{
"WashingtonCities": ""
}
```

Now in an ideal world, you'd bump and fix the spec and the currently "correct" implementations, because not having the ability to compare strings makes common and trivially written filtering operations like `[?start_date > '2018-01-01']` essentially impossible. Which is particularly galling given that you already have opened the pandora's box of unicode string comparisons by allow `max` over strings (of course without giving any explanation of what the actual behaviour is -- are you comparing UTF-16 codepoints like javascript? UTF-8 bytes? UTF-32 codepoints?...).

In a less ideal world, you'd fix the spec by actually saying what max does on strings (or disallowing it) and making your try box conform to it.