Gem just seems to duplicate original CSS about css_splitter HOT 23 CLOSED

Could you provide a simple testapp that reproduces the issue? Or at least describe your setup, versions etc. and provide your stylesheet? Something along those lines would be necessary to help you further.

from css_splitter.

Facing the same issue. Followed instructions step-by-step. The two css files are identical.

So, initially working with less files - but as compiling these is a nightmare and includes where ignored, ending up with variables not being declared I used a less compiler to run it manually - which resulted in a css (in my case startup.css). This CSS is the reason why my application.css requires to be split eventually.

Ok, here's the setup:

Content of application CSS:

 *= require bootstrap
 *= require animations
 *= require flat-ui
 *= require startupdesign
 *= require custom-style
 *= require redactor-rails

Files in app/assets/stylesheets:

application_split2.css.split2
application.css
(and all others mentioned above)

I added the gem and run bundle.

The following has been added to my application.rb:

config.assets.precompile += %w(*.png *.jpg *.jpeg *.gif *.svg application_split2.css )

Since I added the gem, I use the following for my layout in the header section:

<%= split_stylesheet_link_tag "application", :media => "all" %>

which correctly outputs:

<!--[if lte IE 9]> 
<link href="/assets/application_split2.css" media="all" rel="stylesheet" />
<![endif]-->

Environment:

ruby -v
ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-darwin13.0.0]

gem list
...
css_splitter (0.2.0)
rails (4.1.0.beta1, 4.0.4, 4.0.3, 4.0.2)        # tested on different versions
...

Hope this helps,
George

from css_splitter.

PS: Happy to supply my stylesheet, if there's anywhere I can upload it.

from css_splitter.

In fact you can take a look at the live environment, but this might be updated tonight - so don't know how relevant it still is in the morning: http://nutseo.com

If you drop the following into the Google Console:

 function countCSSRules() {
    var results = '',
        log = '';
    if (!document.styleSheets) {
        return;
    }
    for (var i = 0; i < document.styleSheets.length; i++) {
        countSheet(document.styleSheets[i]);
    }
    function countSheet(sheet) {
        var count = 0;
        if (sheet && sheet.cssRules) {
            for (var j = 0, l = sheet.cssRules.length; j < l; j++) {
                if( !sheet.cssRules[j].selectorText ) continue;
                count += sheet.cssRules[j].selectorText.split(',').length;
            }

            log += '\nFile: ' + (sheet.href ? sheet.href : 'inline <style> tag');
            log += '\nRules: ' + sheet.cssRules.length;
            log += '\nSelectors: ' + count;
            log += '\n--------------------------';
            if (count >= 4096) {
                results += '\n********************************\nWARNING:\n There are ' + count + ' CSS rules in the stylesheet ' + sheet.href + ' - IE will ignore the last ' + (count - 4096) + ' rules!\n';
            }
        }
    }
    console.log(log);
    console.log(results);
};
countCSSRules();

You get the following:

File: http://nutseo.com/assets/application-abf433656cad444965645258af88f292.css
Rules: 4015
Selectors: 6756
-------------------------- VM101:28

WARNING:
There are 6756 CSS rules in the stylesheet http://nutseo.com/assets/application-abf433656cad444965645258af88f292.css - IE will ignore the last 2660 rules!

Oh, by the way on local I made sure I have a CSS that is verified and according to standards. On the live one, if you run it through the W3C validator it gives you a lot of errors. However, the issue still persists - just wanted to narrow down the issue.

from css_splitter.

I don't really have an idea on what my be causing that issue.

What is the content of your .split2 file?
How are you generating your application CSS? You are not using Sass, or?
If you want, you can just email me your source stylesheets. Or better, you could try to create a failing testcase in the gems test dummy app.

from css_splitter.

@jhilden I appear to be hitting a similar issue and debugged further to figure out where and how the splitter engine was being called.

Sprockets appears to create a Sprockets::BundledAsset object for the requested asset file. This in turn creates Sprockets::ProcessedAsset objects for the file itself and each of its require dependencies.

The splitter engine appears to be called during the initialization of a Sprockets::ProcessedAsset object for the split2 version of the file. As instructed by this gem's README, the split2 file simply has an include directive to the original file.

Because the initialization of a ProcessedAsset does not evaluate any require statements before evaluating the file, the splitter ends up being run only on the CSS that is directly specified in that file. Being that the file only has require statements, the rendered result ends up being an empty string.

This (as expected) ends up being concatenated with the other require dependencies by BundledAsset. The result of this ends up being the same result as the original file. The splitter engine does not appear to be called again on the concatenated result because BundledAsset only executes bundle processors rather than any of the registered engines.

Unless I'm misunderstanding how the gem works, shouldn't the splitter engine be called when the Sprockets::BundledAsset object is created instead so that the logic is run on the full concatenated result? It appears bundle processors are registered by #register_bundle_processor rather than #register_engine; however, #register_bundle_processor takes in a MIME type rather than a file extension, so I don't see a way to properly register it for only the .split2 file type.

Is there something wrong with the setup I'm describing or my understanding of how the gem is supposed to work? It does not appear to me that the splitter engine is being called at the right point.

from css_splitter.

Given my above investigation, it looks like I was able to work around this problem by modifying the gem to do the following:

1. Register CssSplitter::SprocketsEngine as a bundle processor instead:

   app.assets.register_bundle_processor 'text/css', CssSplitter::SprocketsEngine

2. In order so that the bundle processor only processes split files rather than all CSS files, add the following line to the beginning of CssSplitter::SprocketsEngine#evaluate:

   return data unless scope.pathname.extname =~ /^\.split/

3. In order to make Sprockets process .split2 files in the first place though, I still needed to register an engine for it. This engine doesn't need to do anything though, so I ended up registering a no-op processor:

   noop_processor = Class.new(Sprockets::Processor) do
     @name      = "NoopProcessor"
     @processor = lambda { |context, data| data }
   end
   app.assets.register_engine '.split2', noop_processor

Once these changes were made, the expected CSS was passed into the splitter engine. Incidentally, this happens to also address the prohibition against using require_self and require_tree . in the asset files because what is passed into the splitter engine has already been properly compiled.

@jhilden This appears to address the problem, but being that I just picked up this gem, I could be totally misunderstanding how it's supposed to be used. Does my evaluation and workaround look right to you?

from css_splitter.

@Umofomia thank you so much for all the investigation. My knowledge of the inner workings of Sprockets are limited, but it all sounds quite plausible to me.

I myself have only ever used the gem with Sass files that don't acutally make any use of the Sprockets include/require directives (which I would still recommend to anybody btw), so I could never notice this issue myself.

I don't think your proposed changes would break using the gem for Sass files, so I would definitely merge a PR with those changes. It would be great if a change to the README and a test case could be included.

from css_splitter.

@jhilden Cool, I'll look into creating a pull request for this. The tests may take a little longer to set up since the current tests don't appear to make use of the Sprockets pipeline, but I'll see if I can have something up by next week.

from css_splitter.

@jhilden

I don't think your proposed changes would break using the gem for Sass files

BTW, I noticed a minor case where the change would break existing Sass compilation. Because the engine would be run after the required assets have been compiled and bundled together, you must name the split file with .css.split2 and not .css.sass.split2. The latter would have worked before, but would no longer work after the change.

from css_splitter.

@Umofomia sounds great.

Concerning "tests" with sprocket integration: I think in the past I just created different stylesheets inside the test/dummy app and checked if a rake assets:precompile would produce the correct output. Not automated yet, but a good starting point.

Concerning Sass support: I guess I would just release a new major version, then it should be OK. It would be great if the engine could raise a meaningful error message if a user uses a wrong file extension.

from css_splitter.

@jhilden The compilation will end up breaking in the Sass compiler before it ever reaches the splitter engine so unfortunately we don't have any control over the error message in this case. However, the error that the Sass compiler raises does hint at what the problem is (it will show a snippet of the CSS and say that it's invalid Sass syntax). I haven't tried ERb, but I suspect it will behave similarly.

I'll be sure to add tests for Sass and ERb in my pull request, and update the README too to indicate this behavior.

from css_splitter.

@jhilden I got a little busy so I didn't get a chance to work on this until now, but I will put up a pull request shortly.

I just wanted to note that while working on this, I realized that the no-op processor that I previously mentioned is no longer necessary if we simply just drop the need to use the .split2 extension. The filename itself already requires the _split2 suffix, so the extension was redundant anyway; the bundle processor now simply looks for this suffix rather than for the extension.

This change opened up the possibility of easily supporting CSS files that span more than 2 files as well. You'll see this in the pull request that I'm about to open.

from css_splitter.

@JoeyParshley @keferboeck maybe you could give the new solution a spin and let us know if it works for you.

from css_splitter.

@jhilden I hate to chime in late, and I can open another issue, but I'm having this same issue, of the split files being identical to the original. I just updated my Gemfile to point to the master branch on this gem. As far as I can tell, I've followed the README to a T. Here are the relevant files:

-# application.html.haml
    -### STYLES
    = stylesheet_link_tag "application", media: "all"
    /[if lte IE 9]
      = stylesheet_link_tag "application_split2", media: "all"
      = stylesheet_link_tag "application_split3", media: "all"

I also tried the split_stylesheet_link_tag…split_count: 3 syntax there to no avail:

-# application.html.haml
    = split_stylesheet_link_tag "application", split_count: 3, media: 'all'

And here are my CSS files:

/* application_split2.css */
/*
 *= require 'application'
 */

/* application_split3.css */
/*
 *= require 'application'
 */

And my application.rb:

# config/application.rb
 config.assets.precompile += %w(
...
application_split2.css
application_split3.css
)

Both application_split2.css and application_split3.css are identical to application.css. I could paste that into a gist, but it's 31k lines long, so I wonder if that'd even be helpful.

from css_splitter.

@thenickcox looks to me like your issue is probably that debug: false is not set when you include the stylesheet. as described here: https://github.com/zweilove/css_splitter#empty-_split2css-file
but if you use the latest version and the split_stylesheet_link_tag it should normally work.

can you try setting debug: false manually?

from css_splitter.

@jhilden So sorry for the delay! A colleague of mine gave this a shot and apparently in the split files, the only difference from my version was that in the *_split.css files, he had put = require 'application.css' (with the file extension), which I thought was weird, but that worked. Would that make any sense to you?

from css_splitter.

It definitely sounds weird that the file extension should have an influence on the content of your split stylesheets. We had cases where the file extension made a different because of file loading issues with application.css vs. application.js, but doesn't sound like this is a problem in your case.

from css_splitter.

I had the same problem as @thenickcox where application_split2.css was identical to application.css and solved it the same was, by changing *= require 'application' to *= require 'application.css' which, I suspect, gets around pulling in our application.scss somehow.

from css_splitter.

Thanks for your report @thenickcox

It would be really good to have a failing testcase for this exact scenario (like other test we have in https://github.com/zweilove/css_splitter/tree/master/test/dummy/app/assets/stylesheets) if anybody could contribute that.

from css_splitter.

@jhilden I don't know how you'd want to set up a failing test case for this scenario. The failing case I ran into involved not having an application.css file at all in the project, only an application.scss, and the *spit?.css files using *= require 'application'. Your test cases include an application.css which I suspect would prevent the problem from occurring regardless of what else you added.

from css_splitter.

just make a branch and change the whole setup so that it reproduces your issue. we can worry later how to merge it back into master

from css_splitter.

I'm having this same problem and even switching the _splitN.css files to require 'application.css' instead of just require 'application' doesn't seem to be helping.

Any further suggestions?

from css_splitter.