I like the idea of a null value. Won't argue with adding one to sass.
I think the original example is handled in this case by setting the default
value of the mixin arguments to null and only adding special handling for
null values. Maybe sass should produce a warning if emitting an empty string
as a property value.
I would encourage joneff to not convert "none", "transparent" and "inherit"
to nothing. That seems very wrong. I would
start by looking at how the solution can be solved at the user-input
side of his generated stylesheets instead of on the output side. But
if he persists, he could assign the variable to null explicitly in these
cases:
=property?(!property, !value)
@if !value == "inherit" or !value == "transparent" or !value == "none"
!value = null
#{!property} = !value
Without the need to convert these values to null, this mixin become
pointless and can be omitted in entirety.
Chris
On Tue, Sep 15, 2009 at 12:12 PM, Nathan Weizenbaum <[email protected]>wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
