在您的专业经验中,haml和sass是否被证明是有用的?以何种方式?
3 回答
Haml 很好,我经常使用它,但 Sass 值得单独使用,尤其是当您必须构建复杂的样式表时。例如,关于 CSS 的最糟糕的事情之一是在命名选择器时必须做多少冗余。在 CSS 中,你必须做
#navbar ul
#navbar ul li a
#navbar ul li a:hover
使用 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
您还可以使用变量
!border_color = #333
.box
border = 1px "solid" !border_color
你可以和他们一起使用数学
!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
你也可以分享代码
=rounded
-moz-border-radius: 4px
-webkit-border-radius: 4px
border-radius: 4px
border: 1px solid #000
.box
+rounded
这里面有这么多的力量,你应该自己去学习它。另外,最终结果是纯 CSS,因此可以转换。
不要忘记 css2sass 它将您现有的 css 转换为 sass 文件!
如果您愿意,可以在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
打字少了很多。如果您决定出于某种原因需要在所有这些内容周围添加一个包装器,只需将整个内容缩进一个新标签下即可。
希望有帮助。我 <3 萨斯。
我目前的网站有 800 多个 Haml 文件和 150 个 Sass 文件,让我告诉你,它对我的发展帮助很大。
最大的好处在于快速开发:创建 Haml/Sass 文件所需的输入要少得多,因此与使用 erb 模板相比,您可以用更少的击键来确定您的演示逻辑。
我还发现 Haml 文件更容易阅读,而且更不容易出错。
YMMV,但我已经到了不使用 Haml 感觉像是一件苦差事的地步。
TL;DR - 虽然很受欢迎,但我不喜欢使用 HAML 或 SASS,但我喜欢 SCSS。
似乎对 HAML 的普遍共识是压倒性地支持它,但我个人并不关心它。
如果我的意图是生成 HTML,那么我更喜欢模板语言尽可能接近 HTML。这避免了必须学习另一层间接性,这增加了混淆和错误的机会以及产生认知开销。
我发现 HAML 对我首选使用空格以提高可读性和换行的限制是繁重的,并且通常会导致语法难以阅读。
最近我在一个 HAML 模板中遇到了一个细微的错误,如果模板是 ERB,这个错误就会立即显现出来,例如:
.table
.thead
.tr
.tr
表格行不在THEAD 标记内,这是完全有效的 HAML,但相对于预期的 HTML 结构不正确。虽然页面似乎可以正确呈现,但 CSS 选择器失败,这导致一些 Javascript 代码静默失败。
我确信这种错误对于大多数 HAML 用户来说是显而易见的,如单独显示的那样,但在较大模板的上下文中,可能很难发现;特别是对于 HAML 的新手。
另一方面,如果这是 ERB 或 HTML:
<table>
<thead>
<tr>...</tr>
<tr>...</tr>
在我看来,由于 ERB 和 HTML 几乎总是缩进的方式,结构上的错误更容易被发现。
在花了将近 20 年的时间编写 HTML 之后,我必须承认我对编写格式良好的 HTML 感到自豪,我认为没有理由学习一种不同的方式来表示它并学习发现错误所需的所有新视觉模式。
另一方面,我非常喜欢 SCSS(相对于 SASS),因为 SCSS 本质上是 CSS 的超集。它并没有添加我需要在心理上翻译的全新的间接层。它仅在语法上添加了适度的更改,提供了更简洁(和 DRY)的 CSS 表示,我发现它非常易于阅读和理解。
事实上,我不喜欢使用任何强制执行严格语法的语言,比如我应该如何缩进或换行我的代码,例如 python。或仅用作底层语言(如咖啡脚本)之上的间接层的语言。
我并不是说我相信抽象和间接在编程语言中不好。只是我不想在此处讨论的特定语言中使用它们。