[Building Sakai] sprited portal

[Aaron Zeckoski]

I think it is worth considering some of the articles like these ones
that point out some of the pros and cons of sprites rather than
assuming they are good or bad.

http://coding.smashingmagazine.com/2010/03/26/css-sprites-useful-technique-or-potential-nuisance/
http://sixtypixels.net/the-pros-and-cons-of-css-image-sprites/
http://blog.vlad1.com/2009/06/22/to-sprite-or-not-to-sprite/

Also, I with Steve on the TCC decision making. If someone went in and
replaced Spring with Guice or Maven with Ivy in trunk (without
previous discussion and consensus) I would have a problem with it and
I think that any tech swaps/introductions should be discussed before
they become part of trunk.
-AZ



On Sat, Apr 13, 2013 at 9:06 PM, Steve Swinsburg
<steve.swinsburg at gmail.com> wrote:
> If the TCC is not the decision maker on a fairly significant technical
> change that impacts just about everyone, then what's the point of it? I
> guess we are still in trunk dev so its fine at this point, merging would be
> a diff story though.
>
> This change affects anyone with a custom skin, ie almost everyone. And the
> gains here are imaginary. Browsers cache requests for images. The only place
> you may see a gain here is on the first load with an empty browser cache.
> However as noted in the Jira, the combined download size of this sprite is
> far bigger than the combined size of the individual image requests since not
> all images are used. So it will take longer on first load using this method.
>
> In addition, unless all tools, current and future, are modified to use the
> sprite and not refer to individual images, the number of http requests go
> back up and you've gained nothing.
>
> IMO this is a change for change sake. Any perceived and minimal gains are
> outweighed by the increased time spent on skin maintenance. I do like and
> appreciate the experimentation and work done on this, but don't believe it
> is necessary to be implemented.
>
> Cheers
> Steve
>
> Sent from my iPhone
>
> On 14/04/2013, at 0:08, Charles Severance <csev at umich.edu> wrote:
>
> I agree with Matt here - casting the TCC as an uber-judge panel on all
> things is a mistake.
>
> If someone does not like an idea they should just say so on this list.
> There is no need to push things to a committee right away.  This dev list is
> where we work things out.
>
> If there is severe disagreement on this list that seems to have no chance of
> converging after a good chunk of talk, the TCC is there to "unstick" us.
>
> But so far - it seems that most on the dev list support this new direction.
>
> /Chuck
>
> On Apr 11, 2013, at 9:45 AM, Matthew Jones wrote:
>
> Anything committed to trunk doesn't need explicit TCC approval. The TCC can
> provide advice or direction but doesn't need to be consulted on every issue.
>
> This came up last month on the dev list.
> http://collab.sakaiproject.org/pipermail/sakai-dev/2013-February/021176.html
> and it looks like Gonzalo decided to try it out. It's possible that the
> negatives of this change mentioned may outweigh the positives so it would be
> worth reverting. There shouldn't be anything wrong with reverting any change
> that doesn't improve the code.
>
>
> On Thu, Apr 11, 2013 at 1:01 AM, Steve Swinsburg <steve.swinsburg at gmail.com>
> wrote:
>>
>> I'm a bit concerned about local skins and needing to change the icons.
>> Right now its a simple matter of dropping in a new icon and adjusting the
>> CSS. With this sprite change, you'd either need to change the sprite or
>> change the CSS to refer to a standalone image, thus adding back in the HTTP
>> requests.
>>
>> And browsers cache the images anyway, so wouldn't the HTTP requests be
>> eliminated anyway (except for first page load)? Maybe we should put in more
>> aggressive cache settings if that is an issue.
>>
>> Also, did this change go through the TCC? IMO this is a fairly major
>> change that impacts everyone with a custom skin.
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"



-- 
Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile