Jump to content
Search Community

What is your layout technique for GSAP?

emmanuelulloa test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

Can you share your methodology for HTML and CSS when working banners.  You know, the non-GSAP part?

I usually chop up the PSD to get my images. I name images as I will reference them on CSS, HTML and JS; so product.png will be <div id="product" class="animated"><img src="product.png" /><div> then on CSS I will have

.animated { display: block; position: absolute;}

#product { left: 10px; top: 35px;}

Then when the layout is done I start the GSAPing from there.


Link to comment
Share on other sites

  • 3 weeks later...

I think a popular method is to export your assets from Photoshop including the whitespace. So all your assets have the same size as your stage and are positioned at top: 0px and left: 0px. Most simple animations will work and with a bit of luck you just have to export the new assets for the size adaptions.

Link to comment
Share on other sites

I don't do banners, so maybe I missing something obvious here,  but after exporting everything with the whitespace, couldn't you use a texture packer? 


You assets will packed like sardines...



But's that fine because the json file has all the information needed to restore your images to their original position, so figuring out a transform origin for rotation shouldn't be a problem.


See the Pen bqEamV by osublake (@osublake) on CodePen



Link to comment
Share on other sites

This is a fine solution but, some adServers wont' allow .json files so the data must be embedded in the html.
Other problem is when you pnquant an image, the size of the transparent area and the colors of the various packed images affecting the overall quality of the 8bit .png as i noticed. ( can be fine with Christoph's transparent jpgs )

Since Google messed up the background-image displaying of Chrome I switched back to simple <img> tags, which means the only way to split up a spriteSheet is via js+canvas pixel manipulation, which can be slow, but possible. Because of these, it seems like the separate Base64 encoded, inline .pngs in <img> elements is the simplest way. This adds ~1.33% file size overhead, but removes all the asset http requests and the quality of the .pngs are the maximum possible.

  • Like 1
Link to comment
Share on other sites

2 hours ago, Oliver16Years said:

This is a fine solution but, some adServers wont' allow .json files so the data must be embedded in the html.


By json, I just meant the data. The format doesn't matter. I'm using a regular JavaScript object in that demo. This is where the frames variable comes from.



I haven't looked at optimizing a sprite sheet with with pnquant. I uploaded some sprite sheets for @Christoph Erdmann to look at to see what he would recommend.


And I honestly had no idea that using a background image was a common practice until @Web Dizajner asked a question about it.

But you don't need to use a background image to split an image up, nor do you have to do any pixel manipulation. Just draw the sprite on a canvas using the context.drawImage() method, and then convert it to image data using the canvas.toDataURL() method. It's really fast and simple.





  • Like 2
Link to comment
Share on other sites

As I see now transparent .jpg sprite sheets could be an optimal solution to store all the graphical elements of an ad.
If we could automatically add more quality to red areas ( they are often blocky ). Then we export all the assets in raw 32bit .png format, pack them into a single spritesheet, separate it's transparency into a grayscale .jpg and it's rgb values into a non transparent .jpg, load them in the ad, reassemble the rbg values with alpha values, split them with canvas and json data, and finally put them into <img> || <canvas> elements.

Link to comment
Share on other sites

I just guessed the mechanism of compress-or-die. It can be really helpful for most people. The .jxs uploader is really a nice and generous part Christoph. :) The downside for me is: i can only use MIT/free licensed binaries or .js code in my engine. So If I decide to use .tjpg spirtesheets, I have to write the exporter from the available free and offline parts.

Link to comment
Share on other sites

I used to do spritesheets and then use backgrounds within divs.

Now I'm using img's inside divs, I found this easier to update assets and create resizes.

I must point out though that the spritesheets were updated manually and not using any good workflow (like SASS).

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...