Last modified: 2012-11-28 21:56:30 UTC
There are some css declarations that will not work properly across all browsers if minified, e.g. @font-face in Internet Explorer (where line breaks seem to be vital). It would be nice if one could mark certain declarations not to be minified. The only workaround that I know of is to include an extra css for anything that should not be compressed, which is a pity.
I just struck me that using @media queries within a css loaded through the Resource Loader would mean serving nested media queries, which is still not supported by all browsers, so this would not be very helpful after all. Better then to work on media query support for RL then.
It'd probably be easiest to modify the behavior of the CSS Minifier so that it does not strip newline in cases where it is known to be significant. What are those cases, though? Are they documented by a reliable source?
The minification issue is often mentioned, though it MIGHT be a factoid. I have experiences it myself, but I'm not an expert, an can not say for sure that there were not other factors involved. Some mentions: * http://spigotdesign.com/2011/06/dont-minify-on-the-fly/ * http://www.fontspring.com/blog/fixing-ie9-font-face-problems (and in regards to sepcific minifying systems: * http://code.google.com/p/minify/issues/detail?id=210 * http://code.google.com/p/cssmin/issues/detail?id=52 )
(In reply to comment #1) > I just struck me that using @media queries within a css loaded through the > Resource Loader would mean serving nested media queries, which is still not > supported by all browsers, so this would not be very helpful after all. Better > then to work on media query support for RL then. Nested @media rules aren't relevant here. I know CSS3 supports nested @media blocks, but ResourceLoader is not using that. In ResourceLoader the media query is declared in the module definition. If you're writing @media rules within your module, you're doing it wrong. Don't do that. When ResourceLoader was written we didn't even consider CSS3's support for nested @media blocks. The fact that it works there is a pure coincidence. If you want to pursue this further though, please open a separate request for that. [1] http://stackoverflow.com/questions/11746581/nesting-media-rules-in-css
https://www.fontspring.com/blog/fixing-ie9-font-face-problems says "This was based on anecdotal evidence and may be incorrect. Any confirmation one way or the other would be appreciated." So some more reliable and exact details would be appreciated. (In reply to comment #0) > The only workaround that I know of is to include an extra css for anything that > should not be compressed, which is a pity. Can you explain what you mean by this? How are you including that css?
>Nested @media rules aren't relevant here. Sorry, I wasn't making myself very clear there. As far as I understand it, browsers having trouble with @media inside @media will not understand @font-face inside @media either, so loading @font-face blocks through RL will fail for the same reasons as you pointed out above. That's why I suggested this bug report should just be ignored in my second comment (couldn't find a way to delete it myself, though). >https://www.fontspring.com/blog/fixing-ie9-font-face-problems says >"This was based on anecdotal evidence and may be incorrect. Any confirmation one way or the other would be appreciated." > >So some more reliable and exact details would be appreciated. I might definitely be wrong, but for the reason above, it wouldn't be much help to solve the problem even if it existed... >> The only workaround that I know of is to include an extra css for anything that >> should not be compressed, which is a pity. >Can you explain what you mean by this? How are you including that css? Simply like this: $out->addStyle( 'myStyle.css' ); Is there a better way?
Oh, there, now I found the dropdown menu for changing the bug status.
Please do feel free to re-open this if you confirmed the issue in IE. We could try to maybe keep the @font-face outside the @media rules (given proper documentation). Or perhaps abstract font-face away from the modules an auto-generate those statements at a global level (like we do for messages).
