Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
It turns out that when you run this call:
drupal_add_css($css, 'inline');
Nothing happens. This is because the type is converted to an options array in drupal_add_css like this:
if (!is_array($options)) {
$options = array('type' => $options);
}
$options += array(
'type' => 'file',
'group' => CSS_DEFAULT,
'weight' => 0,
'every_page' => FALSE,
'media' => 'all',
'preprocess' => TRUE,
'data' => $data,
'browsers' => array(),
);
Note that preprocess defaults to TRUE.
As far as I can determine, inline CSS is inherently not preprocessable.
Changing my call to this works:
drupal_add_css($css, array('type' => 'inline', 'preprocess' => FALSE));
But that's bad DX. Patch to make inline force to preprocess FALSE is forthcoming.
Comment | File | Size | Author |
---|---|---|---|
#12 | 961518-inline-css-preprocess-12.patch | 7.62 KB | effulgentsia |
#1 | 961518-inline-css-no-preprocess.patch | 816 bytes | merlinofchaos |
Comments
Comment #1
merlinofchaos CreditAttribution: merlinofchaos commentedHere is a simple patch
Comment #2
andypostLooks reasonable! Could we have a test for this?
Comment #4
merlinofchaos CreditAttribution: merlinofchaos commentedI am very confused by these test results. I am not going to be able to work on this. It's like the current broken behavior is actually what is being tested for. That makes no sense. :/
Comment #5
andypostCurrent behavior is not documented so should be changed.
Comment #6
effulgentsia CreditAttribution: effulgentsia commentedSubscribe. I'm surprised that allowing the default TRUE makes it not work. Will investigate further when I have a chance.
Comment #7
rfaysubscribe
Comment #8
effulgentsia CreditAttribution: effulgentsia commented@merlinofchaos: what do you mean by "nothing happens"? When I enable a test module with the following code:
My HTML includes the following:
And my breadcrumb links turn red. The margin on the body is ignored, because Seven's reset.css undoes it, since it is a theme css file, and therefore, at higher group weight.
Changing my code to:
results in this markup:
in the exact same weight relative to the other STYLE tags as the first example, so no visual difference from the 'preprocess' flag: breadcrumb still red, body margin still reset by Seven.
So the effect of 'preprocess' is whether to strip whitespace, and perhaps do other things, like inline @import statements. I suppose one could argue that this should default to FALSE for the 'inline' type, but to me it's not obvious that it should, and at any rate, seems like a different discussion than "broken" and "nothing happens".
Can you clarify the bug you're experiencing?
Comment #9
merlinofchaos CreditAttribution: merlinofchaos commentedIn Panels, I do a lot of work with adding CSS inline when necessary, particularly with the flexible layout.
After a cvs up, my flexible layouts started breaking, and I discovered that the 'preprocess' flag was causing the inline CSS to not appear.
Did you try this with both CSS aggregation on and off?
Comment #10
merlinofchaos CreditAttribution: merlinofchaos commentedOne note: CSS aggregation is currently OFF on my test site (with a pretty recent cvs up, I'll add).
This works:
This does not:
However, the plot thickens. I turned CSS aggregation on for my test site, and it is completely broken. Plus I get a bunch of this:
Maybe I've been looking at this all wrong. Maybe that preg_replace() is the real culprit here.
Comment #11
merlinofchaos CreditAttribution: merlinofchaos commentedOkay, playing with this leads me to believe that the real problem is that CSS preprocess is completely broken for me, because that regex is failing.
So it looks to me like there are two problems:
One is #962318: Require PCRE Version >= 7.2 -- the regex is failing causing preprocess to fail.
Two is: It's trying to preprocess inline CSS when preprocessing is not on.
Turning back to active for two. That behavior sounds wrong to me.
Comment #12
effulgentsia CreditAttribution: effulgentsia commentedThe remainder of this issue (#11.2) seems like it could be demoted to normal, but leaving it at major, because it's unclear how #11.1 will be resolved in the other issue. Hopefully, we don't have to debate the priority though, since I think this is the right fix for this issue, and as an extra enticement to commit it, it strengthens our test coverage.
Comment #13
catchThe patch and tests look good to me, the other issue was fixed though, so I'm downgrading to normal and generally fixing status here.
Comment #14
catch#12: 961518-inline-css-preprocess-12.patch queued for re-testing.
Comment #16
sun#12: 961518-inline-css-preprocess-12.patch queued for re-testing.
Comment #18
Wim Leers#352951: Make JS & CSS Preprocessing Pluggable fixed this in D8: when the side-wide "aggregate CSS files" setting on the "performance" admin page is unchecked, then it is guaranteed zero preprocessing will happen. This was indeed extremely confusing.
I doubt this will be fixed in Drupal 7 since this has been open for 2.5 years already. So, just closing.