On Wed, Apr 10, 2013 at 3:02 PM, Alex Harui <aha...@adobe.com> wrote:
>
>
>
> On 4/10/13 2:39 PM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote:
>
>
> >>> 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.
> >> Again, we want to identify the best implementation and encapsulate it.
> >> Howe
> >> are other frameworks skinning buttons?
> >
> >
> >
> > The widely acceptable solutions seem to be:
> > a) Preload the images using in an onLoad javascript function
> > b) Use a sprite sheet. So, it would look something like (copy-pasta from
> > [1]):
> >
> > /* "rollover-sprite.png" file contains images for both states side by
> side. */
> > A {
> > background: url(rollover-sprite.png) no-repeat;}
> > /* Width of image for each state is supposed to be 100px here
> > (sprite will be ~200px wide). */A:hover {
> > background-position: -100px 0;}
> >
> >
> >
> > What I am doing is a modification of the sprite sheet solution. Except
> > that I am toggling visibility of states instead of translating the sprite
> > sheet.
> >
> > Again, I wouldn't want to go this route because it limits us to built in
> > pseudo-selectors/states. For example, we wont be able to do a
> three-state
> > checkbox (selected, unselected, partially selected) with this approach.
> >
> > [1]
> >
> http://stackoverflow.com/questions/13015603/css3-background-transition-flicker
> > s-on-first-hover
> Well, if sprite-sheets are the best practice, why not use the same
> technique
> for SVG? Otherwise, how does the designer express what they want without
> code?
>
Sprite sheets are a good option for raster based backgrounds, but wont work
for vectors like SVG. If you look at the SVG skin that were made from FXG,
there are no hardcoded pixel values. Everything is relative i.e. specified
in terms of percentages.
Moreover, this whole exercise is to ensure that we continue to support FXG
while we target HTML5. I have not seen any FXG skins that uses spritesheet
concept.
And when I say spritesheet approach in HTML/CSS, I mean simple translation.
There is no way to grab certain portions of a skin to display as
background like we do in Flash based games.
>
> I'm not clear that spritesheets truly have a psuedo-state limitation. CSS
> usually allows for extensibility in most places, and/or you might alter the
> class selector name. How would you do a toggle-button bar if there weren't
> separate hover visuals for selected-and-hovered?
>
Yes, you can alter the class selector name, but that has to be done through
JavaScript in reaction to any mouse or keyboard events. You cannot do a
lot with CSS's built in pseudo selectors.
I agree that it is possible to use separate visuals for selected and
hovered, except that I dont think that we should use CSS to switch the
states. If we use JavaScript like in my current example, we can support
unlimited number of states and not be restricted by the few
pseudo-selectors that CSS supports.
On that point, I dont think that the current practices in the HTML5 are
necessarily the "best" practices. A lot of them involve hacks and browser
specific rules, etc. If we see an opportunity to avoid those practices and
bring in practices from the Flex world, we should.
Thanks,
Om
