Last modified: 2014-08-29 01:54:26 UTC
Created attachment 14517 [details] IE gradient that was given a #fff and exploded The shorthand makes IE explode sometimes, but it's a lot easier to use when writing/changing css. RL should automatically convert it in order to avoid explosions.
Created attachment 14518 [details] IE gradient that was given an #ffffff You may notice the top border is missing and the gradient doesn't line up properly with the tabs, but these are general IE and/or Vector problems. At least with the full colour the gradient didn't explode.
In general it probably shouldn't, or even should convert them the other way to make the code shorter… this only applies to old IE filters, as I understand.
After the css is gzipped the relative size should be the same. But the code itself would indeed be shorter because then there would be less reason for writers to use longhand... I agree it's a very minor thing, but we do try to support IE and this would simplify that, especially for modern skins.
(In reply to comment #2) > In general it probably shouldn't, or even should convert them the other way > to make the code shorter… this only applies to old IE filters, as I understand. It's not just filters. I just had IE7 get tripped up by a background-colour: #fff. #ffffff worked fine.
It would seem that it's possible to "normalize" color definitions with LESS functions: you can use something like `rgb(red(@c), green(@c), blue(@c))` (assuming the color is in the @c variable) to convert it to the canonical #rrggbb form. There's a bunch of related functions too, see http://lesscss.org/functions/#color-functions for details. (I've heard that the PHP version we're using is missing some, but the ones I tested worked.)
A major issue with LESS right now seems to be that there are many things that can be done with either LESS or RL directly. This leads to messiness and inconsistency, because there don't seem to be any standards as to which is better for what, despite each being better for some things than the other. I say this because while you can, using LESS functions for this would get very messy very quickly, and at that point it'd be far more practical to just write out the number. But this is something where RL could handle everything in the background, and neatly, without the user having to do anything special. It just happens and everything works. That's what we want - less to have to think about, not more.
(In reply to Isarra from comment #6) > A major issue with LESS right now seems to be that there are many things > that can be done with either LESS or RL directly. Such as? The only thing like this I'm aware of is that you can @import other stylesheets in LESS instead of putting them in the 'styles' array of a ResourceLoader module. > I say this because while you can, using LESS functions for this would get > very messy very quickly, and at that point it'd be far more practical to > just write out the number. But this is something where RL could handle > everything in the background, and neatly, without the user having to do > anything special. It just happens and everything works. If you create a mixin for this, then I don't really think that having to write `normalize-color(@color)` instead of `@color` is that much of a trouble, especially since there are very few cases where the color specification has to be provided in a specific format (just IE filters, no?). But yes, if you're not using variables or otherwise generate the color values dynbamically, it probably will be more practical to just write `#ffffff` instead of `normalize-color(#fff)`.
(In reply to Bartosz Dziewoński from comment #7) > (In reply to Isarra from comment #6) > > A major issue with LESS right now seems to be that there are many things > > that can be done with either LESS or RL directly. > > Such as? The only thing like this I'm aware of is that you can @import other > stylesheets in LESS instead of putting them in the 'styles' array of a > ResourceLoader module. Such as converting colours to six digits automatically without the developer having to worry about using some special mixin, and having to keep worrying about it. Indefinitely. > > I say this because while you can, using LESS functions for this would get > > very messy very quickly, and at that point it'd be far more practical to > > just write out the number. But this is something where RL could handle > > everything in the background, and neatly, without the user having to do > > anything special. It just happens and everything works. > > If you create a mixin for this, then I don't really think that having to > write `normalize-color(@color)` instead of `@color` is that much of a > trouble, especially since there are very few cases where the color > specification has to be provided in a specific format (just IE filters, no?). No. As I said, it appears it can apply to other things, including regular background colours. > But yes, if you're not using variables or otherwise generate the color > values dynbamically, it probably will be more practical to just write > `#ffffff` instead of `normalize-color(#fff)`. The whole point of this bug is that we shouldn't have to worry about when to use #fff or #ffffff in the first place. Because as a rule, nobody ever does - we write whatever, we check how it works cross-browser, and then if something goes wrong, we track it down and fix it. This bug is to make it so that slightly less can go wrong. That's all. By using RL as opposed to a mixin, we can ensure that it is all resolved such that nobody will ever have to worry this particular issue again.
If this bug is solely for the purpose of preventing the MS filter from blowing up, there are two thing that needs to be done: * expand CSS shorthands (#fff > #ffffff) * make it work with 'transparent' (must be converted to #00000000) I don't know if LESS has such capabilities, would be great if it does.
As I have already stated twice, this is not just for the filter.
Regardless, that is what needs to be done for the filter to work.
The filter already works. It may not work well, but that's doesn't mean it doesn't work at all.
I don't think it is within the scope of ResourceLoader (a framework to package and deliver modules) to correct bad input. If you want to use LESS to abstract browser bugs, that's fine. But ResourceLoader itself should play no part in changing the styles or scripts to address browser bugs. If CSSMin is optimising things (e.g. #ffffff, #FFF, white -> #fff) and that causing problems in IE, then it is within the scope of RL to not do that as it shouldn't introduce bugs, but certainly shouldn't (intentionally) fix them.
Bug as reported should imho be wontfix, but feel free to repurpose if desired. Or open a new one for that.
(In reply to Krinkle from comment #13) > I don't think it is within the scope of ResourceLoader (a framework to > package and deliver modules) to correct bad input. > > If you want to use LESS to abstract browser bugs, that's fine. But > ResourceLoader itself should play no part in changing the styles or scripts > to address browser bugs. > > If CSSMin is optimising things (e.g. #ffffff, #FFF, white -> #fff) and that > causing problems in IE, then it is within the scope of RL to not do that as > it shouldn't introduce bugs, but certainly shouldn't (intentionally) fix > them. If you wrote CSS that uses #fff in an IE-specific css property that requires #fffff, then don't write that CSS. If it's produced by a Less function, fix that. If it's written as #ffffff but optimised back to #fff by something (e.g. CSSMin) file a bug for that.
