Agree, this looks pretty cool. One thing I noted from my very limited reading was some browser limitations. Do we have an idea of browser support for this feature?
Cheers, Dave. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Nate Angell Sent: Tuesday, 24 April 2012 3:12 AM To: Nicolaas Matthijs Cc: OAE-Dev List Subject: Re: [oae-dev] An alternative to CSS sprites Thanks Nico! Consider my anxieties assuaged ;) = nate On Mon, Apr 23, 2012 at 10:04 AM, Nicolaas Matthijs <[email protected]> wrote: > Actually, the design definitely doesn't rely on a large set of small images > for it to work. We used to have a lot that were used for lay-out purposes > (rounded corners, gradients. etc.), but gradually we've been phasing those > out for CSS-only solution that tend to degrade gracefully as well. This > hasn't been completed yet, but would be completed during the architectural > work. > > The thing that's been increasing is the number of images outside of a sprite > (not necessarily the number of images) as the team was short on time to keep > adding/removing to the existing sprites, which is also why Christian's > solution is appealing. The main reasons for using images right now is for > icons, thumbnails, etc. In other words, things that images are supposed to > be used for. > > Therefore, I'm no longer very worried about a multi-device strategy, but it > will definitely still requires some work to get there. There's another > question as to whether it makes sense to expose the whole of OAE on a mobile > device, but that's a different discussion that we'll definitely be having > soon ... > > Hope that helps, > Nicolaas > > > >> I do take pause however at what Nico points out: that the OAE design >> relies on an increasing number of (small) images. While I generally >> think the OAE design work has been awesome, I wonder if a design that >> relies more on images will also serve a multi-device/multi-display >> strategy going forward. >> >> On one hand: clearly different output scenarios sometimes call for >> very different designs, and thus one should not have to hamstring one >> design just so it can play well with others. On the other hand, given >> that we have limited design resources, any time we can kill two pigs >> with one angry bird is a win. Would a more style-based, less >> image-based design help OAE deliver better to a wider variety of >> clients? >> >> Perhaps the existing design work is better suited to a variety of >> clients than I imagine. I would love to have my anxiety assuaged. >> >> = nate >> >> On Mon, Apr 23, 2012 at 8:46 AM, Nicolaas Matthijs >> <[email protected]> wrote: >>> >>> Hi Christian, >>> >>> I actually like this idea a lot, especially as we have a lot of smaller >>> images that we are using to support the design. >>> >>> During a previous performance sprint, we actually created CSS sprites for >>> the entire application, but as you say, they are hard to maintain and the >>> number of individual small images outside of sprites has increased >>> significantly since. So in terms of maintainability, this is potentially >>> a >>> great solution. >>> >>> Currently, 55.9% of our requests and 42.8% of all data traffic are >>> images. >>> This means that for an unprimed cache, this solution should actually make >>> a >>> huge difference. For a primed cache, it will matter a lot less though (as >>> they should be cached from that point on), but for the sake of >>> maintenance >>> it's probably still quite valuable. >>> >>> Once we get into the architectural work and have our measurement >>> environment >>> set up, we can properly evaluate it and hopefully use it as well ... >>> >>> Thanks! >>> Nicolaas >>> >>> >>> On 23 Apr 2012, at 03:41, Christian Vuerings wrote: >>> >>> Hey, >>> >>> >>> Over the last couple of days / weeks, I've been thinking a lot on how we >>> might improve our performance on the UI side. >>> >>> One of my previous suggestions was to use CSS sprites. >>> While it would be a good thing to have, it can be tedious to make and >>> it's >>> hard to maintain/update. >>> >>> An alternative solution would be to convert the images that we use in CSS >>> to >>> data URIs [1]. >>> There is currently a library which would do this for us, called CSSEmbed >>> [2]. >>> >>> Benefits: >>> - Doesn't need any extra request, the images are embedded in the CSS (A >>> sprite would still require a request) >>> - Since the CSS is cached, the images are cached as well >>> - Way easier to maintain >>> - We would find images that are referenced in the CSS but not exist >>> anymore >>> (found this while testing) >>> >>> I made a proof of concept (for the CSS files in /dev/sakai/css) on github >>> [3] which we could hook into our release build. >>> >>> Try it out by doing: >>> mvn clean install # will create the necessary folders >>> ant cssembed # replace the images in the CSS with data URIs >>> >>> Some extra features/comments: >>> - Browser support is ie8+ >>> - We can/should limit the size for which we allow generation of data >>> URIs >>> >>> >>> -- Christian >>> >>> [1] http://en.wikipedia.org/wiki/Data_URI_scheme >>> [2] >>> Repo: https://github.com/nzakas/cssembed >>> Usage: https://github.com/nzakas/cssembed/wiki >>> Article: >>> http://www.nczonline.net/blog/2009/11/03/automatic-data-uri-embedding-in-css-files/ >>> [3] https://github.com/christianv/3akai-ux/tree/cssembed >>> _______________________________________________ >>> oae-dev mailing list >>> [email protected] >>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev >>> >>> >>> >>> _______________________________________________ >>> oae-dev mailing list >>> [email protected] >>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev >>> > _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev Charles Sturt University | ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN | MELBOURNE | ONTARIO | ORANGE | PORT MACQUARIE | SYDNEY | WAGGA WAGGA | LEGAL NOTICE This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University (CSU) does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with CSU may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at CSU. The views expressed in this email are not necessarily those of CSU. Charles Sturt University in Australia http://www.csu.edu.au The Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 ABN: 83 878 708 551; CRICOS Provider Numbers: 00005F (NSW), 01947G (VIC), 02960B (ACT) Charles Sturt University in Ontario http://www.charlessturt.ca 860 Harrington Court, Burlington Ontario Canada L7N 3N4 Registration: www.peqab.ca Consider the environment before printing this email. _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
