On Wed, 08 Apr 2015 14:59:34 +0200, Kyle Simpson <get...@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
