Option to always inline image data [#1055544]

The 6.x-2.x and 7.x-1.x versions of this module create separate CSS files for the aggregated image data when it exceeds a certain threshold rather than inlining the data in the original CSS to prevent the image data from slowing down rendering of other site styles. Ultimately the user experience improvement by doing this is subjective. Add an option to disable this feature and always inline the image data.

See http://drupal.org/node/991356#comment-4041408 for the original request.

Comment	File	Size	Author
#9	css_emimage.module.patch	1.08 KB	vitok-dupe

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

threading_signals CreditAttribution: threading_signals commented 9 February 2011 at 02:29

The option would be good for mobile and dial-up users I would imagine.

Comment #2

vitok-dupe CreditAttribution: vitok-dupe commented 9 February 2011 at 09:23

sub

Comment #3

jcarnett CreditAttribution: jcarnett commented 11 February 2011 at 03:47

Status:

Active

» Fixed

Committed to CVS.

6.x-2.x
http://drupal.org/cvs?commit=498176

7.x-1.x
http://drupal.org/cvs?commit=498186

Comment #4

vitok-dupe CreditAttribution: vitok-dupe commented 11 February 2011 at 16:08

No no no! Now it's duplicate data for example from this code:

ul.rubriki-bloga li a.drupal {
	background: url('../images/icons.png') 5px 0 no-repeat;
	padding-left: 35px;
}

ul.rubriki-bloga li a.linux {
	background: url('../images/icons.png') 5px -40px no-repeat;
	padding-left: 35px;
}

ul.rubriki-bloga li a.web {
	background: url('../images/icons.png') 5px -153px no-repeat;
	padding-left: 35px;
}

Or if don't use sprites, just take one image and styling 2 different blocks by that image it's also duplicate data, look at my previous patch and you understand that I mean. needed option that allowed to copy $contents with background:none ...; into start of $datauri_css before save it.

Comment #5

jcarnett CreditAttribution: jcarnett commented 11 February 2011 at 18:33

ಠ_ಠ

I know what your patch does, and it's quite likely to result in a larger CSS file than putting the data URIs inside the original declarations. I don't recommend using sprites with this module as you end up referencing the image many times and it's almost never possible to merge those declarations to use a single data URI unless you go out of your way to make it possible. You can end up with the same large image transferred many times.

Because there are cases where appending the data URIs will save space, I committed a change that tests each approach and uses the more efficient one.

6.x-2.x
http://drupal.org/cvs?commit=498446

7.x-1.x (don't forget to manually delete your aggregated CSS)
http://drupal.org/cvs?commit=498452

Comment #6

vitok-dupe CreditAttribution: vitok-dupe commented 11 February 2011 at 23:15

and it's quite likely to result in a larger CSS file than putting the data URIs inside the original declarations

How is that? You solved the problem of duplicating data URI by splitting styles with rules and background-image into 2 different files, I propose just put $contents and $datauri_css into 1 file it's can't enlarge this 1 file to size bigger then those two separated files together. But duplicating data URI do this!
For example file size after features that I propose is 126 kb, after your new option 214 kb...
Feel the difference!
And sprites i think, i will use until the CSS Embedded Images can work with MHTML

Comment #7

threading_signals CreditAttribution: threading_signals commented 12 February 2011 at 12:12

Isn't it better to determine whether to inline or not, by the headers? If mobile, do not inline, all else inline...

Comment #8

jcarnett CreditAttribution: jcarnett commented 13 February 2011 at 06:44

How is that? You solved the problem of duplicating data URI by splitting styles with rules and background-image into 2 different files, I propose just put $contents and $datauri_css into 1 file it's can't enlarge this 1 file to size bigger then those two separated files together.

The problem is only solved in the very specific case you showed in your example CSS in #4. When you reference the same image in consecutive declarations I can merge it into one declaration. While convenient, it is not the norm, and I don't want people to have to think about this edge case just to use this module effectively. From what I've seen, it's rare for that optimization to occur, meaning that appending the image data is usually less efficient than directly inlining it because all the CSS declarations are repeated. However, that problem is solved now because the module will always choose the approach that results in a smaller file. But honestly we're talking about micro-optimization at this point.

I can't use any information about the request, such as the user agent or other headers, because the aggregated CSS is only processed one time. Even if I generated the files needed for every situation then just had some conditionals to determine which ones to use on each request, that would not be compatible with page caching. Finally, the significant factors that affect the decision (throughput and latency) can not be determined from request headers.

As for MHTML, it will probably be in the next release. I've got it implemented, but I need to do some more testing in IE7.