[whatwg] Canvas Shadows - Unnecessary Barrier to Entry - Summary

Summarizing my proposal and responses:

Against Shadows:

The HTML Canvas Shadow specification requires implementors to create a
procedural
shader hook. This added complexity is a significant cost in time, and
brings very little reward.
Further, the functionality can be implemented by the user, with the
ImageData API.
It clutters the namespace with unnecessary variables, it's in some ways
intended to gracefully
degrade, and that's a backward step from what Canvas has evolved to.

For Shadows:

Shadows are not in wide use, I don't think it's a very controversial
part of the specification,
for anyone but implementors. Philip Taylor brought up several points for
keeping shadows.
As of yet, I've seen no other responses.

 From Philip Taylor:

1) I don't expect anyone would object much if you released an
implementation without shadow support. None of the major browsers
implement the complete spec yet, so it's not a necessary or realistic
goal.

2) There's already three independent interoperable implementations of
canvas shadows (Safari 2+, Konqueror 4+, Firefox 3.5+), and it doesn't
seem to have been a major problem for them.

3) There's also some content that makes use of shadow support, so I'd expect
those browsers wouldn't want to remove the feature now. (I think
making shadows optional would be bad - it would prevent content
authors from safely relying on shadow support, but some will use it
anyway and so implementations will eventually have to support it
anyway, so it's best for the spec to provide a single consistent API
with all features being required.)

4) Do the APIs not provide enough features so you can implement shadows
yourself? e.g. Firefox uses Cairo which doesn't have any native
support for shadows; but it can draw shapes onto an alpha-only
surface, manually blur the pixels... I don't see what makes this
fundamentally harder than
implementing all the other required canvas features.


Counter-argument:

1) The point of releasing an implementation that follows the spec, is to
follow the spec
as fully as possible, and release something that can genuinely be said
to be compliant.
With a few prototype hooks, the spec is supported in Firefox 2.0.
Safari's only fault
is the ImageData API, which was delayed for (reasonable) security reasons.

2) Safari's canvas support was borrowed from GUI-land. Firefox 3.5 is
still an experimental
browser, and I'm sure it was quite difficult for them, having waited
since 1.5 to implement the standard.
They have a wonderful compositing engine, bringing amazing features to
Canvas, most are non-standard.

3) There is very little content making use of shadow support, and I'm
sure most of it
uses shadow support in a degradable fashion. Further, this point, of
making shadows optional,
conflicts with the first staement, of shadows not being a big deal. I
agree with the point,
that it's best to provide a single consistent API with all features
being required (or having the ability to prototype them in).
Shadow support would be very difficult to prototype in, under the
current Shadow API.

4) Most of the APIs in use, behind Java, behind ActionScript (flash 9),
behind .Net, Cairo,
are easy to use as a base layer, and have support for the vast majority
of the API spec. Creating
an intermediate composition mode, would be costly and inefficient,
unless necessary.

Until and unless the group is looking to formalize the application of
SVG filters (See Firefox 3.5 for examples),
I don't believe that procedural shading, beyond linear and radial
gradients, and patterns, should be included.

We'd love to build in support for Color Transform, Color Lookup Tables,
Convolution Matrix, and other common utilities.
but that isn't within the scope of this specification.


Summary:

Shadow support is costly, in time spent implementing, and in that they
are not natively
supported by most 2d APIs that are widely available. They offer very
little to the user,
and going down the path of procedural shaders should bring a greater
reward than
a little drop-shadow sugar.

If you have an interest in keeping shadows and/or redesigning the
specification to include
shadow support and/or degrade shadow support... If you have anything to
add to this discussion
please post to the mailing list, or contact me directly, and I will give
you feedback and attempt to moderate.


-Charles



Philip Taylor wrote:
> (Did you intend to send these messages only to me, not to the WHATWG
> list? They'd probably be more useful on the list so the arguments are
> seen by the people making decisions rather than by me :-) )
>
> On Sat, Mar 28, 2009 at 3:20 PM, Charles Pritchard <chuck at visc.us> wrote:
>   
>> [...]
>> I just feel that shadow is sitting half-way, and it hurts our ability to
>> implement
>> the spec, economically.
>>     
>
> I don't expect anyone would object much if you released an
> implementation without shadow support. None of the major browsers
> implement the complete spec yet, so it's not a necessary or realistic
> goal. Lots of people use the old ExplorerCanvas which is woefully
> incomplete, and seem to be capable of only using the subset of
> features that is supported by all the implementations they want to be
> compatible with, so it works alright despite missing features.
>
>   
>> I'm sure there are a lot of implementors,
>> shadows means that most of them won't have a full spec.
>>     
>
> There's already three independent interoperable implementations of
> canvas shadows (Safari 2+, Konqueror 4+, Firefox 3.5+), and it doesn't
> seem to have been a major problem for them.
>
> There's also some content that makes use of shadow support (e.g.
> http://media.liquidx.net/js/plotkit-tests/sweet.html), so I'd expect
> those browsers wouldn't want to remove the feature now. (I think
> making shadows optional would be bad - it would prevent content
> authors from safely relying on shadow support, but some will use it
> anyway and so implementations will eventually have to support it
> anyway, so it's best for the spec to provide a single consistent API
> with all features being required.)
>
>   
>> -Charles
>>     
>
>

Received on Wednesday, 8 April 2009 12:51:47 UTC