Announcement: New plug-in SuperSizer

[nicmare]

there a more solutions to solve this.
when your image is wrapped by a link, you could give it a rel name an then select the link:

[JeremyBASS]

I this case I would aggree with nicmare since it would not validate now or in the future and you should use the rel in the a link (thou I don't suggest lightbox anyways -- Colorbox thats the wam bam one )

http://dev.w3.org/html5/spec/text-level ... mg-element
http://www.w3.org/TR/REC-html40/struct/ ... l#edef-IMG

Now I'm more then happy to add the rest in there if it's wanted, but I don't think anyone cares about  ismap,usemap ,longdesc, or name...

Those are the 4 I didn't do that I will if someone wishes... I hate give the path to bad coding practices...    Cheers -Jeremy

[kendo451]

Hi Jeremy,

SuperSizer needs to output the width and height attributes as part of the output image.  This helps to make sure the image doesn't jump in the browser.

When you are resizing an image to one dimension, usually the width, you don't know what the height is going to be, so this is important.

Thanks!
Ken

[JeremyBASS]

it's there.. you use

tagWidth (XXXpx)
tagHeight (XXXpx)

[kendo451]

Right, but that seems to do the same thing (almost) as width or height params.  It sets the tag width or height to the param value, not to the actual width/height of the generated image.

I'm adding this myself to the version of SS that I'm using.  But I suggest it should be included in the "official" version.

When you resize an image, keeping proportion, you don't know what the resultant dimensions will be.  So using tagWidth or tagHeight is only useful if you already know the width and height.

Outputing an image without width & height params results in browser jump as the page is renderered first, the image fetched, the size determined and then the page resized to fit the image.  If you specify the correct width and height to begin with, the browser doesn't have to resize the page after the image downloads.

I would think that the default behaviour of the supersizer should be to output an image like this, unless tagWidth or tagHeight params are set:



Thanks,
Ken

[JeremyBASS]

ok.. this si how it works...

{supersizer path=".." tagWidth=200 tagHeight=100 width=300 height=150}

outputs

<<--where the image is 300x150 and no squeezing the img since the element attribute is not set.

Hope that makes more sense...


So it's in there.. I added it the first time you ask, in fact that day IIRC

Cheers -Jeremy

[kendo451]

I understand how it works. But you are not understanding what I am saying.

If you do this:

{supersizer path="..." width="200"}

You get this:



There is no width and height attribs.

So the browser doesn't know the dimensions.  And I don't know what the height dimension is going to be because this thing is being resized, so I can do tagHeight='xxx' because I don't know what the actual image height will be.

What I would like to see is if you do this:

{supersizer path="..."}
or
{supersizer path="..." width="xxx"}
or
{supersizer path="...height="yyy"}
or
{supersizer path="..." percentage="zz"}

You get this:

[JeremyBASS]

Hmmm.. I’ll want to think on this.. if I do add that it’ll be a param you need to turn on.. I don’t believe in mixing styles with structure and I am not going to want to have to trun it off all the time..  The issue is that I do want to keep the tagWidth which would need to over ride the width of the image of the resized so I don’t break the tagWidth params…  I think that is way more important in order of preference…. It's fine to add if the logic takes up very little as to much there would be a hit in how fast it works and that it upmost that what I want to protect.

For now, till it’s added, one could do this….

{supersizer path="..." percentage="zz" URL=true assign=’URL’}
{assign var=size value=$URL|getimagesize}


I still need to change the alt now that I think of it.. alt="" should always be outputed to validate... Anyways, I'll see what I can cook up that is light and to the point. Cheers -J

[JeremyBASS]

it's done.. fillHW=true

I got it in with ~0 processing overhead on resize.  I'll publish it a little later as I want to see if there is more I can tighten up.  Cheers -J

[kendo451]

Nice!

[JeremyBASS]

well nice ..

So is there any others?  I think It's near the end and ready for a STABLE ... Cheers -Jeremy

[nicmare]

vote for stable!

imho it would be better if the dimensions are automatically added to the new image instead of using a new parameter?! not?

[JeremyBASS]

I want and image to be as close to 0 processing without params and using the param does cause a very slight hit when checking for the cache image and then needing to run the size option.  So in this case I will leave it the way it is on that.  -J

[kendo451]

If you make the output of the height and width attributes the default behavior.  But overwrite them if tagHeight or tagWidth param is set, it seems you would have less processing.  The only if statements would be if ( isset($params['tagHeight'])), which you have to do anyway.

The question is whether there are situations where you would want no height/width attributes on an image at all.  I would think using urlonly in that case would be easier.

[JeremyBASS]

This is how I see this, if I pull the cached image, it doesn't know what the size is... on the resize it does, and at that I recycled the data that I was outputting, but the rest of the time it does not have that information requiring a getimagesize() on needs to be run on each image.  The goal is to be near 0  on a cached file as this is geared for bulk creation.  If one can think of a better way I'm more than willing to hear it but I don't want to add more processing to the bare call with only the path param.

So since one school of thought in site construction is to break out all style based attributes to CSS ,and as far as I'm concerned I view this to be a valid practice, I am fine with following the w3c footsteps in having width and height attributes being an option you have to add.

Hope this makes clear why I'm vetoing this one.  I have thought about it a lot, and fully understand your position.  Cheers -Jeremy