On Wed, Apr 10, 2013 at 9:22 AM, Alex Harui <aha...@adobe.com> wrote:
> > > > On 4/9/13 11:39 PM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote: > > > >>> * My earlier approach of using each .svg file as a background of each > >>> button state has a major problem - it is not runtime scriptable because > >> of > >>> security restrictions. > >> If you don't need runtime scriptability, is separate svg files a better > >> solution? Maybe we need to support both? Especially because a quick > >> search > >> of "how-to" seemed to find the separate svg file approach. > >> > > > > > > I dont think separate svg files are better for any situation. For > example, > > when we use css and pseudo selectors, we are limited by the selectors > > themselves. If we need custom states, it is better if we have all states > > in one .svg file and use JavaScript to switch states. > Are you sure there isn't a way to extend the set of pseudo states? > These are they only supported selectors [1]. I havent seen any way to extend them today. The WebComponent/Shadow DOM draft seems to incorporate this idea, though. [2] > > > > Moreover, in the separate svg files approach, the svg for a state is > loaded > > only when that state is triggered, which causes an obvious flicker when > > loading for the first time. > I think I saw the flicker, but is that not solvable? If that's the state > of > the world for svg as background-images it seems like nobody would be using > it. > It is not a limitation of the SVG background-images. The same flicker happens when you use a .png or a .jpg as background. It seems like the images are lazy loaded and I am not sure if we can force the images to be loaded into memory without resorting to hacks. > > > > I am thinking that inert graphics (like backgrounds for panels, etc) can > be > > skinned using a single svg with no JS. Anything that is interactive is > > better off with a single svg with JS scripting. > I will have to look at your code someday. I still don't think a skin needs > code like that. The interaction should be in the control, not the skin. > > > >>> * The button's label and click callback function is injected into the > SVG > >>> file via the embed tag's attributes. > >> Why is the callback for click part of the "view"? > >> > > > > Because the embedded SVG eats all the mouse events. The approach I have > > taken seems to be the only way to add interactivity to a component > created > > in this fashion. I did quite a bit of research on this. I will be glad > to > > be proven wrong. > > > > I tried bubbling events, but it seems like the browsers create a new > > document context when rendering embedded SVG. > > > > There are other approaches we could try like positioning a transparent > div > > on top of each button, but I am not sure which approach is worse. What > do > > you think? > Either the browser manufacturers intended for SVG to be a valid button skin > or not. Maybe they only considered container backgrounds. We want to > identify the optimal pattern and then encapsulate it, if possible. > One obvious way around it would be to use inline SVG with HTML. If they are part of the same DOM, then we wouldnt have this problem. I was trying to encapsulate the skin into a separate file (with svg + JS) As a result, I had to use either the <object>, <embed> or <iframe> tags with a link to the embedded SVG. If we use inline SVG, we will lose the ability to share one button skin for different button instances. Another approach would be to keep the SVG in a separate file, but in the compilation step, copy them as multiple instances into the html. Maybe use javascript to create the <embed> elements? What do you think is ideal pattern? There are multiple ways to make this work. If you can draw some broad strokes, I can try to figure out a way to do it. Thanks, Om > > > > > [1] http://www.w3schools.com/cssref/css_selectors.asp [2] http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom-201/<http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom-201/>
