Closed (fixed)
Project:
Parallel CSS - AdvAgg Plugin
Version:
6.x-1.x-dev
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Reporter:
Created:
17 Jun 2011 at 15:26 UTC
Updated:
5 Jul 2011 at 17:21 UTC
http://drupal.org/project/parallel_css works great with advagg!
However when I included CSS Embedded Images -> http://drupal.org/project/css_emimage
the final output has broken methods for any CSS images - other than IE7 - or less (and 'anyhow' CSS Embedded Images disables itself for such old browsers <IE8)
Comments
Comment #1
Peter Bowey commentedSorry I have not included more succulent debug help for this, but it is way past my bed-time.
Basically, If I revert to not using parallel_css and doing my previous advagg mapping (as per http://drupal.org/node/1172012), css_emimage works fine.
Comment #2
chriscalip commentedhehe i also am interested if it was gonna fit with css_emimage. I thought having a heavier weight than css_emimage was enough. Apparently not.
I'll do a couple of drupal site scaffolds, test, debug then make necessary changes or request with css_emimage.
Comment #3
chriscalip commentedI know a lot of folks knows this already, probably the knowledge is left unsaid, and taken as an assumption. But for the purposes of everyone getting on the same page:
Read up on Data URL scheme http://en.wikipedia.org/wiki/Data_URI_scheme and it looks like http://www.drupal.org/project/parallel_css and http://www.drupal.org/project/css_emimage are meant to be mutually exclusive on a per image basis. "Data URIs are sometimes called Uniform Resource Locators, although they do not actually locate anything remote." Meaning css_emimage will only rewrite images that are in relative state:
It will not rewrite anything that is with a complete url.
For example css_emimage will and "should" ignore:
Having said that we can have a partial integration with css_emimage because in practice css_emimage most likely will only rewrite that "Only embed images less than 32KB Internet Explorer does not support embedded images larger than 32KB. If you are not concerned about IE support you can ignore this limitation; otherwise, it is best to leave this checked."
If we have done our jobs right we should have a proper working integration already by having parallel_css as heavier than css_emimage (meaning parallel_css fires after css_emimage). If there are any errors it might be the case that our replacement routines are still replacing the images that css_emimage has replaced. This should not be the case. I will take a look at this this tomorrow.
Pretty much on a data set of :
The result should be:
Comment #4
chriscalip commentedHeh, this got my attention. Confirmed, we have cases of http://domain.com/data:imageXXXXX.
What weird is that
should not be a match for
Peter how's your regex? we could probably add an exception of not (data)
Comment #5
Peter Bowey commentedRefer #4
Many thanks Chris @chriscalip
Yes, I think that is the area (regex) to look into!
Will checkout method's....
Here is a 'live capture' of how the current 'Parallel CSS + CSS Embedded Images' deals with data:
http://www.webpagetest.org/result/110618_PX_VQ5Q/1/details/
From the 'above' we can see this incorrect method:
Comment #6
chriscalip commentedYup, you confirmed my findings it the regex it's failing.
I gotta put in some time to figure out the right regex
http://www.regular-expressions.info/lookaround.html
http://www.solmetra.com/scripts/regex/index.php
Prolly take me half an hour.. since i don't do it as much. Cooking dinner. will fix tomorrow morning. or if you can i could use the right regex :)
Comment #7
Peter Bowey commentedMany thanks Chris @chriscalip
Here is the updated regex for Parallel CSS:
Note: Replace *both* instances of this 'regex' +patch in parallel_css.module.
I was inspired by reading this link -> https://github.com/ckorhonen/selectivizr/commit/e38598d3deccbdc971b6eb46...
The 'magick' is the regex part:
(?!data)The above code 'change' is still a bit 'primitive' - so I will enhance the regex - later!
Basically, we wanted 'proof of concept' first :)
*I note that there are some other CSS image types that the regex should process*
So expect a 'better regex' soon.... (smile)
A) Proof Concept: 'Live working Capture' using the new regex with Internet Explorer 9: -> http://www.webpagetest.org/result/110618_79_VR6R/2/details/
Comment #8
Peter Bowey commented*FIX*
@chriscalip - as promised, here is a improved (clean + tight) regex:
Improved our regex with some '\b' = 'word boundary' checks (on 'url' + 'src'), and better '\s' = 'white space' checks.
Bench Test Report: = "combined IE6-IE9, + FF4.x CSS url tests pass OK"
Comment #9
Peter Bowey commentedComment #10
Peter Bowey commentedComment #11
chriscalip commentedhey Peter,
Got redirected to other chores this last weekend. I am looking into this now. Looks like there are a couple of bugs introduced by the new regex and i realize some bugs in the currently code after looking into this more further.
Comment #12
Peter Bowey commented@chriscalip
No problems Chris, the new regex I posted here has been very heavily tested and is a good pass on everything I have processed (from IE6 - IE9 - FF4.01). Also, I am pleased to report the processing time has decreased for bundling CSS aggregates! I see about a 8% performance increase. :)
Yes #8 is the new regex!
Comment #13
chriscalip commentedYup the regex works it just changes the assumption I made during @ the replacement functions for example
The previous function is assuming an array of 2 elements $matches[0] and $matches[1], this changes it to 3 elements [0][1][2], had to rewrite code from $matches[1] to $matches[2]
One thing I found that I am not satisfied with the code is this:
thinking of changing to:
its a bit more expensive...
Comment #14
Peter Bowey commented@chriscalip
Thanks Chris, My poor [dead] mind is much too tired to comment on that 'possible' change - it is 3:08AM here!
I will leave that 'cool code' homework for you to ponder in your day-light :)
Comment #15
chriscalip commentedThanks Peter, ill get this done by the time you wake up. Have a good morning.
Comment #16
chriscalip commentedhttp://drupalcode.org/project/parallel_css.git/commit/791445c Done.
Here are the stuff included in the improved regex :
a. no "absolute urls" http://www.drupal.org/misc/1.png
b. no data uri
Comment #17
chriscalip commentedawaiting feedback then will release new version.
Comment #18
chriscalip commented@ comment #8
Improved our regex with some '\b' = 'word boundary' checks (on 'url' + 'src'), and better '\s' = 'white space' checks.
added improvements here:
http://drupalcode.org/project/parallel_css.git/commit/cf08bf0
:)
Comment #19
Peter Bowey commented@chriscalip, thanks Chris - looks good!
Will test and report!
Comment #20
Peter Bowey commentedRefer #16 + #18
@chriscalip, I like the 'good thought' you had for:
I did not even think of that code 'problem'. Well done!
Thanks for including the optimized 'regex'
Comment #21
chriscalip commentedI really like the idea of the word boundary and the better white space checks. thanks for that.