Kyle,
Let's see.
Le 8 avr. 2015 à 21:59, Kyle Simpson <get...@gmail.com> a écrit :
> as soon as a bug is around long enough and in enough browsers and enough
> people are working around that bug, it becomes a permanent "feature" of the
> web.
Yes this is a feature. It's part of the platform, even if not perfect, but you
already know that.
> The point is not whether this clipboard API has bugs or that canvas API
> doesn't or whatever.
The initial point you made was "please add an api to say it's buggy". What I
understood. Let's find your own words:
Can we add something like a "feature test API"
(whatever it's called) where certain "hard"
cases can be exposed as tests in some way?
I still think it's a mistake, because of the Web Compat horrors I see be UA
sniffing or other things. But maybe I entirely misunderstood what you were
saying because the point you seem to be making seems slightly different:
> The point I'm making is there will always be features the browsers implement
> that won't have a nice clean API namespace or property to check for.
If an implemented feature is not __currently__ testable, maybe we should just
make it testable to a level of granularity which is useful for Web devs, based
on what we see in the wild.
Example testing if a range of unicode characters is displayable:
https://github.com/webcompat/webcompat.com/issues/604#issuecomment-90284059
Basically right now the current technique is to use canvas for rendering the
character.
see https://github.com/Modernizr/Modernizr/blob/master/feature-detects/emoji.js
and http://stimulus.hk/demos/testFont.html
Here I would love to have a:
String.fromCharCode(0x1F4A9).rendered()
true or false
(or whatever makes sense)
The risk I see with the initial proposal is that we had another level of
complexity instead of just making it testable.
I may have missed what you wanted.
--
Karl Dubost 🐄
http://www.la-grange.net/karl/
