-
Notifications
You must be signed in to change notification settings - Fork 3k
Undetectables
jdalton edited this page May 13, 2011
·
80 revisions
These things cannot be feature detected. They must rely on either:
- UA sniffing
- Browser inferences
- Providing the same (slow) fix to everyone
-
registerProtocolHandler()
support (existed in webkit but doesnt do anything, still live in iOS/Android likely.) - File Drag 'n Drop (webkit doesnt expose a global DataTransfer constuctor to inspect) issue 57
- webforms UI: datepicker, colorpicker UIs cannot be detected, only the associated constraint validation
- inability to edit things in contenteditable/designMode in mobile Webkit browsers
-
timeupdate
video/audio event fires inconsistently across webkit and moz - HTML5 video
readyState
is inconsistent across webkit(4) and moz(3) -
canPlayType()
results on mobile are unreliable -
preload
attribute support, can't be tested without bandwidth-consuming tests (Chrome has implemented the preload-IDL, but not the feature) -
loop
attribute support, can't be tested without bandwidth-consuming tests (support for this attribute is practically non-existent)
-
script
tag onload/onerror/onreadystatechange actual behaviour (atomicity, order, etc etc) -
link
tag / stylesheet onload actual behaviour (exists in webkit / ff but never fires) - Network related metrics, a la the Browserscope Networking Results (|| script, css, etc)
- Support for ­ or <wbr>
- ClearType disabling during opacity changes
- FOUT behavior of Gecko's @font-face support
- font rendering (like smoothing, anti-aliasing, font-weight diffs among browsers/platforms)
- consistent rendering ( in the page and alert() dialogs) of HTML entities
- proper handling of CSS
text-overflow:ellipsis
behavior on text
- keyboard event bugs, especially related to the
keydown/keypress
events, and thekeyCode/charCode
event properties.- Best documented and fixed by the Google Closure guys
- the order (and reliability) of mousedown, click, and mouseup events (especially if a mousedblclick is happening)
- especially when fired on a form element like a checkbox, reliability of state update of the element compared to when the events fire
- whether a scroll wheel event is coming from a continuous device like a trackpad or the Magic Mouse or from a traditional clicking scroll wheel (in webkit).
-
onhashchange
is case insensitive in IE8 (maybe 9 too?), all others are case sensitive (HTML5 requires case sensitivity). Can't be detected without actually triggering a hashchange event. - IE8 in compatibility view mode has
onhashchange
, but doesn't support it. Workaround is to test fordocument.documentMode && document.documentMode >= 9
. - support for
DOMContentLoaded
.- You can add an event listerner and hope, fall back to
document.readyState
orwindow.onload
or in IE, thedoScroll
hack.
- You can add an event listerner and hope, fall back to
-
<select>
display in IE6 - PNG alpha transparency
- The look of the various *-resize cursors is very different across browsers and platforms.
- IE6 css bugs like duplicate characters bug
- IE display transparency bug on height > 4096px
- CSS Generated Content support
- (Updated) Solution: using generated content to alter the width or height of an element (Dirty example (updated)) [example now checks for partial CSS2 support, .e.g, Firefox < 3.5, and CSS3 support]
- modernizr test for gencontent
- False positives for
box-shadow
,border-radius
, etc (happens in Aurora/Midori/etc) issue 169 -
pointer-events
false positive in Opera -
position:fixed
support in iOS and Android
- IE CSS bug where certain types of positioning of an
<input type=text>
element can cause that element's autocomplete box to not render at the same location as the actual input box. - strange treatment of
<!-- -->
comment nodes in the DOM (in IE)... like in some cases, a comment node will be moved to be a child of the previous element even though it's not a child proper. Can cause things like:empty
to fail differently. - resize event firing rate. e.g. you can't keep an element's position smoothly updated in response to resize or scroll.
- Memory leaks
- DOM/JS performance (e.g.: innerHTML vs. DOM manipulation)
- Testable, but typically not feasible to test just to avoid code forking.
- Hardware Acceleration
- Whether a CSS transition can use (or did use) accelerated compositing. If an effect isn't going to be hardware-accelerated, then a setTimeout animation is often more performant than a non-accelerated CSS transition. No reliable way to measure the framerate of a CSS transition.
Add to the list if you know more Undetectables. Likewise, link to possible solutions if you think an item listed here can be feature-detected.
Contributors: paulirish, jaubourg, rwaldron, zachleat, snover, devongovett, rgrove, savetheclocktower, getify, garann, jdalton, michaelbrundage, necolas, mislav