Re: hit testing and retained graphics

On Fri, Jul 8, 2011 at 12:15 PM, John Foliot <jfoliot@stanford.edu> wrote:
>> "angry birds"
>> I honestly have no idea. Suggestions welcome.
>
> (I think suggestions are coming forward, and are being rebuffed)

Can you provide links to this rebuffing?

>> "fancy checkboxes"
>> Ideal would be if CSS had more power here to make it possible to style
>> the checkbox directly, rather than having people use canvas. For
>> example if browsers would implement the 'content' property on
>> non-pseudo-element selectors this would likely go a long way. That way
>> people could do things like:
>>
>> input[type=checkbox]:not(:checked) {
>>   content: url(unchecked.png);
>> }
>> input[type=checkbox]:checked {
>>   content: url(checked.png);
>> }
>> input[type=checkbox]:not(:checked):active {
>>   content: url(activeunchecked.png);
>> }
>> input[type=checkbox]:checked {
>>   content: url(activechecked.png);
>> }
>>
>> For sites that didn't want to use a static image but rather a
>> generated canvas, something like the -moz-element value should work
>> quite nicely:
>>
>> input[type=checkbox]:not(:checked) {
>>   content: -moz-element(#checkboxchecked);
>> }
>> and so on. See [1] for a full feature description
>>
>> I believe webkit has a similar feature. Obviously all parties need to
>> agree on a single solution here so that we can deploy non-prefixed
>> properties.
>
> I think that this is all great, but even you admit that we don't have much
> if any of this today - so "people use canvas".

This sounds a lot like "browsers hasn't implemented feature X yet, so
I'm proposing we add feature Y to standards" which is an argument that
doesn't make a lot of sense to me.

>> "rich text editing"
>> I think that the only good solution here is to severely improve
>> contentEditable. Currently contentEditable is a pain for authors to
>> use because it doesn't provide a low level API, only high-level things
>> like execCommand. It also works dramatically different in different
>> browsers and with lots of different bugs in all browsers. It's really
>> quite terrible. It's not surprising that some developers have said
>> "screw it" and attempted to do better using canvas.
>
> And it seems then that this is a major itch that needs scratching right
> now - certainly not the only one, but a really big one. The fact that "...
> some developers have said "screw it" and attempted to do better using
> canvas" is the very reason why telling them "don't do it" has very little
> traction - they don't have other choices right now. So faced with this
> truth, the canvas accessibility folks are attempting to develop an
> "ARIA-like" solution: sure it seems bolt-on, more complex, less elegant,
> less intuitive... but solving the problem that needs to be solved, and
> hopefully in a framework type of way that can be used for the next
> unimagined cool thing in <canvas>.

We could spend time on specifying various bolt-on features and trying
to convince browsers to implement them. Then hope that authors add
these bolt-on techniques to their <canvas> based editors in hope of
getting them a little closer to a good editing solution, while still
being far from it due to lack of IME editing support, platform
integration, spell checking, undo/redo, etc.

Or we could spend time on specifying a decent editing solution based
on contenteditable which browsers already has expressed and showed a
lot of interest in supporting. Which would automatically be accessible
both to AT and support IME users and give pages automatic support for
spell checking, undo/redo and other nice editing features.

I personally prefer the latter approach.

/ Jonas

Received on Monday, 11 July 2011 19:47:16 UTC