NielsLeenheer/html5test — Issue #120: False negative on datetime-local test, or why testing html5 input user interfaces are really, really hard.
Author: miketaylr
Created: 2012-01-18 02:17:52+00:00
State: open

The code in question:

```javascript
group.setItem({
id: 'ui',
title: 'Custom user-interface',
passed: baseline.field != getRenderedStyle(element.field) || baseline.wrapper != getRenderedStyle(element.wrapper),
value: 2
});
```
The assumption here seems to be that the if an html5 input widget is supported natively, it won't share the same `width` as a native ``. Seems like a pretty solid guess, but not bulletproof.

Using Opera Mobile (which has a native datetime-local input widget) on a Galaxy Nexus that has a zoom of 225%, this test returns a false negative:

![Zoom Comparisons](http://miketaylr.com/post/91d0aaeb.png)

Totally weird.

I tried doing some similar a few years back at http://miketaylr.com/code/html5-forms-ui-support.html, but I made the assumption that if a html5 input UI was supported, the UA would perform input sanitization (http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#value-sanitization-algorithm). I think Modernizr took this approach as well. For now it seems to be reliable, but it's probably just a matter of time before some this assumption is broken as well.

I'm not sure what the best approach is here, but the current one isn't quite working.