Re: [whatwg] Supporting feature tests of untestable features

On Wed, 08 Apr 2015 14:59:34 +0200, Kyle Simpson <getify@gmail.com> wrote:

> A lot of the "untestable" bugs have been around for a really, really  
> long time, and are probably never going away. In fact, as we all know,  
> 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. And we both think it's a bad situation. Let's work to avoid new bugs  
when adding new features, by writing tests, and considering feature  
testability when designing new features (this is being done already). Old  
bugs would be good to fix, too, but it is not without risk since Web pages  
might use the differences for browser sniffing or otherwise rely on them.

> So to shrug off the concerns driving this thread as "bugs can be fixed"  
> is either disingenuous or (at best) ignorant of the way the web really  
> works.

We have different perspectives for sure.

> Sorry to be so blunt, but it's frustrating that our discussion would be  
> derailed by rabbit trail stuff like that. The point is not whether this  
> clipboard API has bugs or that canvas API doesn't or whatever.
>
> Just because some examples discussed for illustration purposes are bug  
> related doesn't mean that they're all bug related.

I didn't say that. <link rel> is an example already brought up, and I've  
proposed a fix. I've asked for other examples.

> There **are** untestable features, and this is an unhealthy pattern for  
> the growth/maturity of the web platform.
>
> For example:
>
> 1. font-smoothing
> 2. canvas anti-aliasing behavior (some of it is FT'able, but not all of  
> it)
> 3. clamping of timers
> 4. preflight/prefetching/prerendering
> 5. various behaviors with CSS transforms (like when browsers have to  
> optimize a scaling/translating behavior and that causes visual artifacts  
> -- not a bug because they refuse to change it for perf reasons)
> 6. CSS word hyphenation quirks
> 7. ...

Thanks. Can you elaborate on these, why you think it makes sense to  
feature-test them? Do you know of existing pages that would benefit from  
being able to feature-test these (that currently use UA sniffing or so  
instead)?

> 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. And many or all of those will be things developers would like  
> to determine if the feature is present or not to make different  
> decisions about what and how to serve.
>
> Philosophically, you may disagree that devs *should* want to test for  
> such things, but that doesn't change the fact that they *do*. And right  
> now, they do even worse stuff like parsing UA strings and looking  
> features up in huge cached results tables.
>
> Consider just how huge an impact stuff like "caniuse" data is having  
> right now, given that its data is being baked into build-process tools  
> like CSS preprocessors, JS transpilers, etc. Tens of millions of sites  
> are implicitly relying not on real feature tests but on (imperfect)  
> cached test data from manual tests, and then inference matching purely  
> through UA parsing voodoo.

I don't disagree here. I just don't come to the conclusion that we should  
have an API to test everything under the sun. I don't mind changing or  
adding things to help feature-test things that are not currently testable  
in compliant implementations.

-- 
Simon Pieters
Opera Software

Received on Thursday, 9 April 2015 07:51:24 UTC