Although if we do limit it to compressed mode, hopefully debugging won't
be an issue... I assume no one develops with compressed output.
Olek Poplavsky wrote:
> I think that this feature will create difficulties in troubleshooting
> resulting css and will make sass much less transparent.
> And it will help only some people with particular style of stylesheets.
>
> Count me against this feature.
>
> regards,
> Olek
>
> On Apr 13, 2008, at 5:08 PM, Evgeny wrote:
>
>> It's all part of making the actual writing of the rules (in sass)
>> clear,
>> but not really care how it will look like in the final css.
>>
>> I guess it's something like "compiling sass into css", allowing sass
>> to be more detailed and clear to read - while not really caring how
>> the
>> final css will look like, since it's not the actual blue-print.
>>
>> There were request to make minimal html/css from haml/sass before,
>> where indentation and spacing is ignored in the final result to "save"
>> on the byte count. My idea is somewhat similar.
>>
>> Bye hey, I wont insist :)
>>
>> Regards,
>>
>> -- evgeny
>>
>> On Sun, Apr 13, 2008 at 9:27 PM, Mislav Marohnić
>> <[EMAIL PROTECTED]> wrote:
>>
>>> I agree with Nathan. If a CSS author wanted to minimize CSS blocks,
>>> he would
>>> have done it himself.
>>>
>>> - M
>>>
>>>
>>>
>>>
>>> On Sun, Apr 13, 2008 at 7:54 PM, Nathan Weizenbaum
>>> <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>> In general, I'm nervous about features that "shouldn't be turned
>>>> on by
>>>> default." It just seems like unnecessary feature bloat. Especially
>>>> since
>>>> this feature doesn't add any power... merging a block doesn't
>>>> cause the
>>>> result to change at all.
>>>>
>>>> I'm also confused why you'd want the CSS output to diverge so much
>>>> from
>>>> the Sass input. If it's clearer to write different body attributes
>>>> in
>>>> different places, then it'll probably be clearer to read it, too.
>>>>
>>>>
>>>>
>>>>
>>>> Evgeny wrote:
>>>>
>>>>> Hail Haml/Sass users,
>>>>>
>>>>> Sass is becoming more and more powerful with each feature, it's
>>>>> already way ahead from plain css and enables much more in the DRY
>>>>> department. I have yet another suggestion for you to consider.
>>>>>
>>>>> * Minimizing css blocks
>>>>>
>>>>> It is quite common to see the same element described with more than
>>>>> one block in css, for example one big list of font-descriptions for
>>>>> all the elements, and another for layout (things like margins,
>>>>> padding, etc). Currently Sass just outputs the blocks as-is and
>>>>> creates a css file that has the same blocks in the same order.
>>>>>
>>>>> What if you could still write separate blocks for different logical
>>>>> items (typography/layout/etc..) but get a merged block in css?
>>>>>
>>>>>
>>>>> Example:
>>>>>
>>>>>
>>>>> body
>>>>> :font-family Arial
>>>>> h1
>>>>> :font-family Helvetica
>>>>>
>>>>> body
>>>>> :background blue
>>>>> :color yellow
>>>>> h4
>>>>> :color white
>>>>>
>>>>> body
>>>>> :margin 0 auto
>>>>> #content
>>>>> :margin 0 auto
>>>>>
>>>>>
>>>>>
>>>>> Then when merged, there will be just one block for "body" in the
>>>>> css
>>>>>
>>>>> body {
>>>>> font-family: Arial;
>>>>> background: blue;
>>>>> color: yellow;
>>>>> margin: 0 auto;
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> Naturally something like this should not be turned on by default.
>>>>> And I'd also love to hear if you think it's a complete waste of
>>>>> time
>>>>> and obsolete even before starting to implement this ...
>>>>>
>>>>>
>>>>> Thoughts?
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>
>
> >
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
