I'm very dubious about making the empty string falsey. That causes all sorts of trouble in JS... if you're looking for something to universally represent "no value", I think adding a null value would be a better step.
On Tue, Sep 15, 2009 at 11:54 AM, Chris Eppstein <[email protected]>wrote: > My convention in compass has been to use false to mean no value -- this is > primarily because it has the proper behavior with @if. > I think this would be a fine change, I don't think that Sass should > generate invalid CSS where it can be avoided. > > However, if we make this change, I think it should be the case that any any > value that evaluates to boolean false should have the same behavior. > Therefore, the convention would be that an empty string would be considered > boolean false. In the future, if we ever introduce the concept of "null", it > would fit nicely with this > strategy as well. It's important to note that zero is considered boolean true > in sass. > > Chris > > > On Tue, Sep 15, 2009 at 11:34 AM, Nathan Weizenbaum <[email protected]>wrote: > >> What I was suggesting was automatically removing any properties that had >> empty values. >> >> >> On Mon, Sep 14, 2009 at 5:56 PM, joneff <[email protected]> wrote: >> >>> >>> Firstly, yes, I could keep it in one line, but I do it on several for >>> the sake of readability (for other people in my company). >>> >>> On the other thing -- indeed, empty values have no meaning in CSS, but >>> they do add weight in the file size. And I wouldn't like to have a >>> file or files with empty values. >>> >>> That's the reason for coming up with the +property? mixin in the first >>> place. >>> >>> But since I have some user generated parameters, I later extended the >>> mixin and check for "none", "transparent" etc, since I didn't want >>> those to be duplicated. >>> >>> As a result I did reduce the final file size footprint by some 30 or >>> 40 %, if the user has not done any of the available customizations or >>> has explicitly set values like "transparent", "inherit" etc. >>> >>> I am not saying this is a "must have" feature -- I had an interesting >>> situation and solved it, I thought I'd share ;) In the worst possible >>> case, I get code refactoring and in any other ideas how to make my >>> snippet even better. >>> >>> I would attach a real life examples, but I did a bit of shortening in >>> my styles -- I now use 4 or 5 character mixins with up to 5 parameters >>> for the better part of the rules. So the my files are not exactly >>> readable and strait forward. >>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Haml" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/haml?hl=en -~----------~----~----~----~------~----~------~--~---
