Re: [whatwg] Supporting feature tests of untestable features

Roger Hågensen <rh_whatwg@skuldwyrm.no> writes:

> Myself I have to confess that I tend to use caniuse a lot myself. I use 
> it to check how far back a feature goes in regards to browser versions 
> and try to decide where you cut the line In other words I'll end up 
> looking at a featyre and thinking that "OK! IE10 supports this feature, 
> IE9 does not, so minimum IE target is then IE10).
>
> Then I use that feature and test it in latest (general release) version 
> of Firefox, Chrome, IE, Opera, if it relatively looks the same and there 
> are no glitches and the code works and so on then I'm satisfied, if I 
> happen to have a VM available with a older browsers then I might try 
> that too just to confirm what CanIUse states in it's tables.
>
> This still means that I either need to provide a fallback (which means I 
> need to test for feature existance) or I need to fail gracefully (which 
> might require some user feedback/information so they'll know why 
> something does not work).
> I do not do use browser specific code as I always try to go for feature 
> parity.

Have you tried progressive enhancement instead of graceful degradation?
I usually build a simple HTML version of a page first, check that it
works using curl or elinks, then enhance it via polyfills and other
scripts that do their own user-interface enhancements. Of course I
consult caniuse in the process to see if features are supported.

For me, following a progressive enhancement workflow reduces the need
for testing, as the simple (“fallback”) version does usually work if a
script does not execute and I can always test it by turning of scripts.

Greetings,
-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>

Received on Thursday, 9 April 2015 09:43:51 UTC