RE: Use case for SVG + HTML : Making puzzle

If you feel up to it... could you reduce the demo to the least amount of code that demonstrates the problem?  (maybe as 3 separate examples)  .... or if you blog has it, maybe translate?
 
And I do mean.... only if you feel up to it... as it doesn't really matter whether I understand it or not.  I just thought I might take a look and see if there are any similarities to other issues I'm studying.
 

 


Date: Thu, 9 Sep 2010 00:40:42 +0200
From: jeremie.patonnier@gmail.com
To: www-svg@w3.org
Subject: Use case for SVG + HTML : Making puzzle

Hello,

I would to show you this demo I made in July :

XHTML : http://jeremie.patonnier.net/experiences/svg/inline/puzzle.en.xhtml
HTML 5 : http://jeremie.patonnier.net/experiences/svg/inline/puzzle.en.html

(for those of you who speak French, I have write a full article about this demo : http://jeremie.patonnier.net/post/2010/07/26/SVG-et-HTML5-font-bon-menage-avec-Firefox)

Right at the moment, this demo only work with Firefox 4 beta and Firefox 3.6 (in XHTML mode only)

This demo allow you to turn any image or video into a Jigsaw Puzzle. Basically, each pieces of the puzzle is a SVG element that embed a canvas element, cut off by a SVG clipPath. 

What's failing in Opera and Chrome (I have not tested with IE9 yet)

1. Black pieces

Opera and Chrome display black pieces. This is because of Firefox bug 265894. Firefox does not follow the spec on how CSS have to be handled with the SVG 'use' element. So my CSS rules are bad but work with FF.

2. Filters on HTML elements

If you activate the option "Show hint", with Firefox, you'll see a grayed version of the image/video. With other browser you'll see the normal image/video. This is because only Firefox support SVG filters on HTML element (I apply a color matrix over a canvas element). This use case (a filter applied to a canvas) is very useful because you can change the output rendering of the canvas without touching its pixels definitions and keep it clean for further manipulation.

3. Pointer-events handling

Pointer-events allow me to make the piece dragable only when you click on a visible part of a piece thanks to the way clipPath handle pointer events.

Unfortunately, no browser handle pointer-events property the same way.

With Firefox, I have to disable the pointer-events on the main SVG element and re-enable it on the canvas element. If I don't do this, FF does not honor the clipPath rule for the pointer events and fire a pointer event even on none visible part of the image.

The problem with Opera is that it does not re-enable the events on the canvas, so you can't drag the pieces (I guess that it's because it does not handle pointer-events property on HTML elements... I have not tested it in detail yet)
The problem with Chrome is that even with this disable/enable trick it does not honor the clipPath rule for pointer events so you can start draging a piece even on a invisible par of it.


Those three points are the main problems I have to deal with to make this demo truly cross-browser. But there are other concerns. For example, at that moment, I must create a canvas for each piece which has a serious hit on performance, especially with video. It is a true use case where using the SVG 'use' element to duplicate a single canvas context among multiple "fake" canvas element could be really helpful. Another tricky point (which is not SVG nor HTML related) is the DOM getElementsByTagName property which is buggy (or simply inconsistent) in almost every browser : Opera does not understand "getElementsByTagNames('svg:svg')" (I have to use getElementsByTagNameNS instead) ; Firefox and Chrome have problems with SVG camel-case Tags in a HTML5 context (but I know they are working on it)

Best regards
Jeremie Patonnier 
web : http://jeremie.patonnier.net
Twitter : http://twitter.com/JeremiePat