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
-~----------~----~----~----~------~----~------~--~---
