So now we need to define levels of graphic burden? and at what level
of burden does the quality suffer? Seems just as hard to define.
Having the author explicit say "this has to be as high quality as
possible" or "less can be low quality" seems better and we have
examples of other specs offering the same kind of control.
No. The whole point is that the UA is in the best position to
identify what the tradeoffs are, not the author -- if you want a flag
to specify the quality to be used then that would require you to
determine what the tradeoffs were yourself, with no substantial
knowledge of what combination any given user was actually using. You
need to realise that different UAs and different platforms have
substantially different performance characteristics.
And that said how would you make the decision yourself anyway? Your
decision will almost always hurt *some* portion of your userbase,
either through lower quality than would otherwise be possible, or by
making a page that is unusable for someone with a lower powered device.
And then, after you've made that decision you will start getting some
people saying UA1 looks better than UA2 because you underestimated
performance of the UAs, and UA1 ignores the flag. Or you'll get
people saying UA1 is unusable because you found it was slow in UA2, so
you dropped the quality setting -- which UA1 ignores, but then a year
later you get people saying UA1 looks better again because hardware is
faster so it now do its higher quality rendering without any problem
-- but UA2 is still using the low quality path. Finally you test on
UA1 and UA2, and find your site looks good in one, but is too slow in
the other, do you now lower the quality in both so that your site is
usable in both, or do you try and make the decision in JS at runtime?
If the latter you now have quite a bit more work to do. How do you
determine the performance of a particular UA/platform combination? JS
performance is not the same as canvas, so you have to manually test
canvas performance, so you are now trying to hand code what could
already be built into the UA. Alternatively you could just try to
take the lazy path and do a UA check, and try to determine the
performance based on UA but now you have *all* of the standard UA
check problems, and you still can't test the real performance because
you don't know what hardware you're on.
If the UA makes its own decisions about performance, it can make a
decision based on a wide range of information that you do not have any
access to, in addition to being aware of the specific costs of certain
operations (eg. a UA could choose to lower the quality of only a
single operation, like image scaling, but leave other operations at
their standard fidelity -- trying to do this in a flag would be both
horrifically complicated for authors *and* would represent tremendous
over specification by the standard)
--Oliver
