Re: [whatwg] Supporting feature tests of untestable features

On 2015-04-09 11:43, Nils Dagsson Moskopp wrote:
> 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).
>>
> 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

I have, but found that relying on polyfills is no different than relying 
on a work around or a 3td party framework.
It easily ads to code bloat, and I'm now moving more and more towards 
static pages with JS and CSS specific to a page are embed in the page as 
that support fast static delivery.

I don't mind waiting a few months or a year for a feature to be added 
and available among all major modern browsers. Once a feature is 
available like that then I make use of it (if I have use for it) to 
support the effort of it being added.
This does mean I end up going back to old code and stripping 
out/replacing my own code that do similar things.
Or to enhance/speed up or simplify the way my old code works.
I don't mind this, it's progress and it gradually improves my code as 
the browsers evolve.
If ten years from now my old pages no longer look/work as intended then 
that is on me or whomever do maintenance them.
If they are important enough then the pages will migrate to newer 
standards/features over time naturally.


I do miss HTML versioning to some extent though, being able to target a 
5.0 or 5.1 minimum (or lowest common denominator) would be nice.
Though this can possibly be missused.

I have seen another approach though to versioning that may be worth 
contemplating though...

Using Javascript one call a function and the browser if this version is 
supported. Example:
if (version_supported('javascript',1,2))

or
if (version_supported('css',3,0))

or
if (version_supported('html',5,0))


The browser could then simply return true or false.
True would mean that all features in the speced version is supported.
False would mean that they are not.

I'm using something similar for a desktop programming API I'm working 
on, the application simply asks if the library support this version 
(number hardcoded at the time the program was compiled) and the library 
answers true or false.
This avoids programmers from accidentally parsing a version number 
wrong, the library is coded to do it correctly instead.

There would still be a small problem where a browser may support for 
example all of CSS 2 but only parts of CSS3.
But in that case it would return True for CSS 2.0 but false for CSS 3.0
So "some" feature detection would still be needed to detect that.
But being able to ask the browser a general question if it will be able 
to handle a page that targets CSS 3, HTML5, JS 1.2 would simplify things 
a lot.

If actual version numbers is an issue. Why not use years, like so:

if (version_supported('javascript',2004))

or
if (version_supported('css',2009))

or
if (version_supported('html',2012))

Essentially asking, "do you support the living spec from 2012 or later?".

I think that using years may possibly be better than versions (and 
you'll never run out of year numbers nor need to start from 1.0 again).
And if finer granularity is needed then months could be added like so:
if (version_supported('html',2012,11))


The javascript can then simply inform the user that they need a more up 
to date browser to fully use the page/app.


-- 
Roger Hågensen, Freelancer, http://skuldwyrm.no/

Received on Thursday, 9 April 2015 18:18:40 UTC