Bri*_*gan 43
Haml很好,而且我经常使用它,但Sass是值得的,特别是如果你需要构建复杂的样式表.例如,CSS最糟糕的事情之一是命名选择器时需要做多少冗余.在CSS中,你必须这样做
#navbar ul
#navbar ul li a
#navbar ul li a:hover
Run Code Online (Sandbox Code Playgroud)
使用Sass,您可以自然地将这些后代嵌套.
#navbar
ul
margin: 0
padding: 0
list-style: none
width: 100%
li
margin: 0
float: left
margin-right: 10px
border: 1px solid #000
a
text-decoration: none
&:hover
color: red
Run Code Online (Sandbox Code Playgroud)
您也可以使用变量
!border_color = #333
.box
border = 1px "solid" !border_color
Run Code Online (Sandbox Code Playgroud)
你可以和他们一起使用数学
!measure = 18px
!text_size = !measure / 1.5
body
font-size = !text_size
line-height = !measure
h1
font-size = !measure
margin-bottom = !measure
h2
font-size = !measure + 2
#wrapper
width = !measure * 50
Run Code Online (Sandbox Code Playgroud)
您还可以共享代码
=rounded
-moz-border-radius: 4px
-webkit-border-radius: 4px
border-radius: 4px
border: 1px solid #000
.box
+rounded
Run Code Online (Sandbox Code Playgroud)
这有很大的力量,你应该自己去学习它.另外,最终结果是纯CSS,因此可以转换.
不要忘记将现有的css转换为sass文件的css2sass!
如果您愿意,可以在http://rendera.heroku.com/上播放一些示例.这是我为帮助人们学习HTML5和CSS3而建立的网站,我支持HAML和SASS.
另外,请查看StaticMatic(staticmatic.rubyforge.org),了解使用HAML和SASS进行静态网站工作的惊人方法.它生成可以上传到静态主机的网站,并具有类似于Ruby on Rails的布局和模板系统.
为了解决你所问的直接问题,通过"是否值得",答案是肯定的.能够使用变量,通过选择器轻松分组,并通过模块共享代码,使复杂的样式表变得更加容易.构建样式表并不需要很长时间,您可以使用优秀的Compass框架更进一步.例如,您可以使用960.gs或Blueprint模块将这些框架混合到现有样式表中.这样您就不必更改代码的标记.在你的所有标记中添加960.gs及其"grid_12"和"container_12"类可能是不可能的,但是使用Compass和Sass这是一件轻而易举的事.
Sass还可以更轻松地为开发模式提供多个样式表,并为生产生成单个样式表,从而提高客户端性能(减少页面加载时对服务器的调用.)
HAML有自己的好处,虽然它们不像Sass那么明显.HAML确实能够非常容易地嵌套元素并声明DIVS ...例如使用常规的960.gs很容易使用HAML:
#header.container_12
.grid_12
%h1 Welcome!
#middle.container_12
.grid_8
%h2 Main content
.grid_4
%h3 Sidebar
Run Code Online (Sandbox Code Playgroud)
打字少得多.如果您因某些原因决定需要在所有内容中添加包装器,只需在新标签下面缩进整个内容即可.
希望有所帮助.我<3 Sass.
我目前的网站有超过800个Haml文件和150个Sass文件,让我告诉你它对我的开发有很大帮助.
最大的好处在于快速开发:创建Haml/Sass文件需要更少的输入,因此您可以使用比执行erb模板少得多的击键来确定您的表示逻辑.
我还发现Haml文件更容易阅读,并且更不容易出错.
YMMV,但我已经达到了不使用Haml感觉像是一件苦差事的程度.
小智 5
TL; DR - 虽然很受欢迎,但我不喜欢使用HAML或SASS,但我喜欢SCSS.
似乎对HAML的普遍共识绝大多数赞成它,但我个人并不关心它.
如果我的目的是生成HTML,那么我更喜欢模板语言尽可能接近HTML.这避免了必须学习另一层间接,这增加了混淆和错误的机会以及引起认知开销.
我发现HAML对我的首选使用空格的限制因为可读性和换行而变得繁重,并且经常会导致难以阅读的语法.
最近我在HAML模板中遇到了一个微妙的错误,如果模板是ERB,这个错误很明显,例如:
.table
.thead
.tr
.tr
Run Code Online (Sandbox Code Playgroud)
表行不在 THEAD标记内,这是完全有效的HAML,但对于预期的HTML结构不正确.虽然页面似乎正确呈现,但CSS选择器失败,导致某些Javascript代码无声失败.
我确信这种错误对于大多数HAML用户来说是显而易见的,如隔离所示,但在较大的模板环境中,很难发现; 特别是对HAML新手的开发人员.
另一方面,如果这是ERB或HTML:
<table>
<thead>
<tr>...</tr>
<tr>...</tr>
Run Code Online (Sandbox Code Playgroud)
在我看来,由于ERB和HTML几乎总是缩进的方式,结构中的错误更容易被发现.
花了将近二十年的时间编写HTML,我必须承认我对编写格式良好的HTML有一定的自豪感,我认为没有理由学习不同的表示方式并学习发现错误所需的所有新视觉模式.
另一方面,我非常喜欢SCSS(而不是SASS),因为SCSS本质上是CSS的超集.它没有添加我需要精神翻译的全新间接层.它只增加了语法上的适度变化,它提供了CSS的更简洁(和DRY)表示,我发现它非常容易阅读和理解.
实际上,我不喜欢使用任何语言强制执行严格的语法,如何缩进或换行我的代码,如python.或者仅作为基础语言(如coffeescript)上的间接层的语言.
我不是说我相信编程语言中的抽象和间接是坏的; 只是我不喜欢在这里讨论的特定语言中使用它们.
| 归档时间: |
|
| 查看次数: |
8310 次 |
| 最近记录: |