First time for a while that I’ve had a go at one of these – got a silver in about 10 minutes but couldn’t immediately see how to improve the memory usage / running time to get a gold so went for certification. I think I did have a lead though, so I’m planning on taking it again soon.
While doing my research to get custom attributes to validate correctly, I found out the HTML5 will support custom attributes as long as they start “data-“. No more validation vs. ease of use issues.
More details here.
So I return to our “unit” tests (which do HTML validation through a locally installed w3 validator service, ssh, it’s useful if not fast) and I find that loads of stuff isn’t validating any more. One of our custom bits of JavaScript has been responsible for liberally splashing a custom “track” attribute over a lot of our links and buttons on so-on.
Dig around the internet and I get to this useful and ancient article on A List Apart about custom DTDs.
Upshot – add this to the beginning of your page when validating – a quick check on Firefox suggests you can’t really have it on your live site. Ho hum.
<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"
[
<!ATTLIST a track CDATA #IMPLIED>
<!ATTLIST input track CDATA #IMPLIED>
]>
<html xmlns="http://www.w3.org/1999/xhtml">
Useful bit of info that it took me a little while to find – there’s a new meta tag “viewport” that you have to know about.
The short story
Take this and play with it – note width can also be a pixel value, just replace with a number:
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
The long story
So if you had a nice, simple website with a heading and some text you would expect the mobile browser to find a sensible scaling for that wouldn’t you? Nope – the left is my artist’s rendition of what happens if you just have some HTML and you don’t specify any sizing information at all (and you haven’t got the above meta tag either).
OK, you think, it must have some sort of width that it expects the html element to be – let’s resize that (or body or something) so that we only have 320px worth of content. What happens then?
Well you get this – the mobile browser is basically wasting a lot of space.
This is because mobile browsers are assuming that your website needs somewhere between 800-1000px (depending on device) to display properly, it then renders the page according to that width and then does a pixel-by-pixel scale down so that all the page comes up on the screen. But tiny.
Now when you take out the CSS forcing body / html / top-level div width and replace with a meta viewport tag saying that your site has been designed for (say) 320pixels or to be fluid at small resolutions (device-width) it won’t need to scale it’s calculated website down so far, or at all. And you get the result you’re looking for lovingly rendered by myself to the left.
There’s a very detailed breakdown of what’s going on at quirksmode.
There’s a problem with automatically submitting a form with javascript – by just calling the submit() method – you break the back button. We can use the fact that browsers remember form values to prevent this from happening.
<input type='hidden' id='submitted' name='submitted' value=''>
<script>
if (document.getElementById('submitted').value == '') {
document.getElementById('submitted').value = 'yes';
document.getElementById('wp_form').submit();
}
</script>
UPDATE: Forgot to test in IE. This doesn’t work in IE6 at least, but I could do with fixing the code so look for updates.
I’ve noticed over the past couple of weeks that the sales and service teams almost always refer to customers by their names instead of their customer id.
Of course, we’ve moved the search facility for surnames out of the way but judging by how often it’s used we should bring it front and centre and add an index on that column. We should even produce a search-as-you-type style interface for it as most surnames do bring up a fair few choices.
I can only think it’s a good thing that the customer-facing teams think of the customers by names rather than numbers and we should remember that not everyone thinks like a techie. We’ve bandied around the idea of letting customers upload photos for their account and perhaps displaying these in the CMS would re-inforce the concept that there are people behind the list of numbers and settings. Even more useful, perhaps, is finding a way to put our service and sales teams photos in front of the users – reminding them that they are also talking to a person.